On Tue, Apr 17, 2018 at 05:37:48PM -0400, Simon Ser wrote: > (Re-sending the message because I forgot to reply to the list) > > On April 13, 2018 2:56 PM, Jonas Ådahl <[email protected]> wrote: > > Another thing to consider is whether non-toplevels ever want a similar > > kind of protocol? It is not something we need to go into much further > > details now, but it would be easy to add into this protocol by just > > renaming the directory under unstable/ and the XML file to > > "xdg-decorations" or something. Would we have another type of surface > > that needs similar functionality, we could add that as a separate pair > > of interfaces. > > I'm not sure it's a good idea to add decorations to non-toplevel surfaces. I > can't think of a use-case for popups. We don't know yet what kind of > xdg-surface will be added later, so I think we can't really design a protocol > that would work for this unknown use-case and we'd better create a new > protocol > instead.
That's not what I suggested. I just suggested to make room for potential future xdg_surface based surface types by renaming a directory and a file. We should indeed not bother with adding any more complexity to popups and not-yet-thought-of surface types. > > > Is this the consensus as well? Because if it should be possible, there > > are those things I mentioned to consider regarding capabilities. A > > potential mode could for example be to outsource drawing shadow or > > something. > > As Drew, I think the complexity isn't worth it. Compositors wanting to draw > shadows around clients will get into more issues (e.g. getting the shape of > the > window). > > > Ignoring that for a bit, I guess the reason for allowing the compositor > > to disregard the set mode to be that a client might not know whether > > request ssd or csd? Especially in the example you gave above. Then what > > is the purpose of the set_mode request at all? > > The set_mode request allows the client to communicate its preference, but > still > allow the compositor to override it. For instance, a GTK+ client with a > titlebar > containing widgets might prefer CSD, but could still accept to use SSD by > turning the titlebar into a toolbar. While I don't think it makes sense to do this in GTK+ (we can't just mess around with applications widget trees however we want) but I can accept that it may be a theoretical possibility for a theoretical toolkit. > > That would work well in tiling compositors when moving a window between a > tiled > container and a floating container: the compositor could accept the set_mode > request in floating mode and enforce SSD in tiled mode. We could imagine > another > compositor letting clients decorate themselves if they want to in tiled mode, > in which case the compositor would send preferred_mode events when switching > between tiled and floating containers. How do you imagine avoiding state transitions that don't result in incorrect intermediate state? If a compositor changes the preferred mode, does it wait some arbitrary time to see if client replies with a new set_mode request? Or how else would one avoid sending a new configuration given the changed tiled-ness without knowing what the client prefers? For example, I imagine this could happen otherwise: Cmp: -> preferred mode(B) Cli: -> set_mode(B) Cmp: -> configure(B) Cli: -> draw+commit assuming B *draw as B* (wanted) Cmp: -> preferred mode(A) Cmp: -> configure(B) Cli: -> set_mode(A) Cli: -> draw+commit assuming B *draw as B* (temporary unwanted state) Cmp: -> configure(A) Cli: -> draw+commit assuming A *draw as A* (wanted) Wouldn't it be better to have actual clients that'd actually use this part of the protocol before writing it down? We could still move forward with a vastly simpler protocol without the set_mode and set_preferred, and just have the mode enum and configure (so that the compositor can switch between csd and ssd when tiling/untiling or whatever) that works with the all available clients we have today. Jonas _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
