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 <ofour...@redhat.com >>> <mailto:ofour...@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@lists.freedesktop.org >>> <mailto:wayland-devel@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@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/wayland-devel >> > _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel