[PATCH] xdg-shell: add draw states for xdg_surface
gschwind at gnu-log.net
Tue May 31 22:03:19 UTC 2016
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
my arguments are:
- state flags and draw flags are the same things, even if they look
- 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
>> 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  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.
>> 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.
>> 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:
>>> ----- 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 :)
>>> wayland-devel mailing list
>>> wayland-devel at lists.freedesktop.org
>>> <mailto:wayland-devel at lists.freedesktop.org>
>>> * 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
More information about the wayland-devel