[PATCH] xdg-shell: add draw states for xdg_surface

Tue May 31 22:03:19 UTC 2016

Hello Derek,

Maybe I fail to explain my point of view:

I propose to have only one state array, I also propose that client
provide hints about which optional state he support. This is somehow
similar to EWMH - _NET_WM_STATE and EWMH - _NET_WM_ALLOWED_ACTIONS
respectively.

my arguments are:
 - state flags and draw flags are the same things, even if they look
different.
 - separating optionals and mandatory state has no benefit, the client
and the compositor can ignore them, even if they are mandatory.
consequently that make them /de facto/ optional. I do not mean it's a
good things, I mean separating them does not improve the situation.
Keeping them together just avoid long discussion on which side they must
go state or drawing state?

On 31/05/2016 23:04, Derek Foreman wrote:
> On 31/05/16 02:31 PM, Benoit Gschwind wrote:
>> Hello mike,
>>
>> Thank for your clarification, I try to summarize the issue/need:
>>
>> A compositor may want to draw a client without the shadow. In particular
>> if the window is integrated to a GUI component, I can imagine tilling.
> 
> Tiling seems only tangentially related to this proposal, since it's just
> one reason why a compositor might want to turn off drop shadows.
> 

Just tried to get a tangible definition of the issue/need to not discuss
hypothetical cases.

>> Taking your issue, the drawing state look very similar to the state
>> flags. You wrote: "[the draw state is] specifically related to drawing
>> only". Actually, removing the shadow may have side effect related to
>> behavior, in particular for client that use shadow as resize handlers,
> 
> The spec mentions that removing the drop shadow may interfere with
> interactive resize - from my reading it seems the intent is just to tell
> the client not to render drop shadows (not to draw something else in
> their place).  Perhaps that could be clarified in the next revision.
> 

My intension wasn't to get this clarified ;)

>> those client may replace shadow by plain borders. In that case the
>> difference is very thin. In the oposite way, the most expected changes
>> of fullscreen or maximized state is the client layout.
>>
>> You wrote: "[the draw state has] negotiation", I agree, but I will use
>> the wording "hint" because look more appropriate. Why do not add state
>> hint ? Some will argue that state are mandatory, to that I reply: ok,
>> how do you enforce it? You have no way to check that a client do not
>> draw a shadow while maximized or in fullscreen state, or basically
>> ignore the state. Thus just consider that those mandatory hints are
>> always included. States hints are similar to EWMH [1] or the WM_PROTOCOL
>> of ICCCM.
> 
> I'm not sure I understand your point, but I think you just successfully
> shot it down yourself?
> 

I don't know where I shot myself, I re-explained my point of view above.

> Moving right along then... ;)
> 
> Indeed states are mandatory and the compositor has to assume they've
> been obeyed - any app that doesn't is buggy.  Adding optional behaviour
> to that mechanism seems like a really bad idea.
> 

Please add arguments why it is a bad idea, I don't see why. The proposal
was basically to add optional drawing states. I do not see why optional
drawing states is better idea than optional states, moreover, I do not
see the *real* difference between states and drawing states.

> The negotiated method presented here seems less bug prone, and allowing
> toolkits not to have to implement all states seems less onerous.
> 

This match my proposal, but it look like I failed to explain it
properly. Or maybe I misunderstood the proposal.

> PS: When we're done re-inventing EWMH for wayland, can we have xatoms
> too?  Hmm, maybe not everything from the old days needs a direct mapping
> to wayland. :)

I agree, and the opposite apply, not all old stuff are broken. Analyzing
old stuff and picking what working save time. In that particular case I
do not say please add vertical_maximized state, I just says the old
stuff did the job and I propose a similar things, thus it's not insane,
thus please consider it as an (better) alternative.

Best regards,
Benoit Gschwind

> Thanks,
> Derek
> 
>> About the state enum, you are correct, the current spec. has reserved
>> ranges. My opinion still the same, this ranges are basically anti-standard.
>>
>> Best regards.
>>
>> [1]
>> https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html#idm140200472593792
>>
>> On 31/05/2016 17:40, Mike Blumenkrantz wrote:
>>> After a long weekend of not reading mails, I've read some mails; I'll
>>> try to make comments to everything in this reply.
>>>
>>> On Tue, May 31, 2016 at 7:38 AM Olivier Fourdan <ofourdan at redhat.com
>>> <mailto:ofourdan at redhat.com>> wrote:
>>>
>>>     Hey
>>>
>>>     ----- Original Message -----
>>>     > On Tue, May 31, 2016 at 05:24:35AM -0400, Olivier Fourdan wrote:
>>>     > > [...]
>>>     > > If we considered and dismissed them, fine.
>>>     >
>>>     > They are not "actively" considered in this patch, but as I mentioned
>>>     > earlier, I think tiling states can later be added to the window state
>>>     > enum.
>>>
>>>     Just a quick note before my main power source goes down here, my
>>>     comment are not about tiling, as stated before, I just tool tiling
>>>     as an example of where we eanted to have a value per edge.
>>>
>>>     FWIW, I don't think tiling is a "draw state", I reckon it's a plain
>>>     state just like "maximized" or "active". But tiling is worth its own
>>>     thread :)
>>>
>>>     Cheers,
>>>     Olviier
>>>     _______________________________________________
>>>     wayland-devel mailing list
>>>     wayland-devel at lists.freedesktop.org
>>>     <mailto:wayland-devel at lists.freedesktop.org>
>>>     https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>>>
>>>
>>> * Range allocations were added only because it was created in a similar
>>> way to the configure state enum, which has such allocations. I don't
>>> care much about them and I had no plans to use them at this time.
>>>
>>> * This patch is solely about implementing the basic idea of "draw
>>> states"--a method for negotiating and controlling the manner in which
>>> the client draws its windows. I don't see a need to "define the issue"
>>> further than "this is a new display server protocol, let's ensure
>>> there's a standard way to negotiate/control drawing between the server
>>> and clients". This is clearly different from window states due to 1)
>>> negotiation, and 2) specifically related to drawing only, not behavior.
>>> ** The initial value of "no shadow" exists because it's a useful thing
>>> to have in some cases (e.g., flat ui theme in compositor+toolkit,
>>> compositor wants to draw special shadow effects, ...) and is not
>>> controversial--moreover, it's trivial to implement compared to other
>>> potential states.
>>>
>>> The concept of draw states is easy to envision extensions for when
>>> provided with this base example, and these extensions can be discussed
>>> at a later time and in a separate thread if everyone can agree on the
>>> premise. A tiled state is certainly something worthwhile to consider at
>>> that time and place.
>>>
>>>
>>>
>>>
>>>  
>> _______________________________________________
>> wayland-devel mailing list
>> wayland-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>>
> 