[PATCH 2/2] protocol: add state set functions for maximized and fullscreen.
spitzak at gmail.com
Thu Oct 31 01:45:39 CET 2013
Rafael Antognolli wrote:
> I'm sorry, but I fail to understand how a user could choose between
> click to focus, or sloopy focus, if that's up to the client to
> implement it. Wouldn't this lead to something like: if I use this
> video player A, but it only implements sloopy focus, and I want click
> to focus, I have to change to some other video player B?
The clients are expected to pay attention to user configuration
settings. This is also how they all use the same fonts and colors, etc.
> For a subsurface, there's no big reason to grab mouse pointer and so.
Actually there is if the subsurface is being managed by a different
client and it wants all the events even if the subsurface was created by
the parent client.
> On the other hand, it wouldn't make sense to synchronize the commit of
> a transient window with the one from a toplevel surface. At least from
> our toolkit point of view (EFL) it would make things more complicated
It would be useful for making lines connecting the transient windows or
when they are arrows pointing at something in the main window.
> Of course they could all be merged, but then we would just end up with
> a big generic one surface to rule them all. Not sure if this is
That is my intention. I believe this will simplify Wayland considerably
by merging two different implementations of what is actually, as far as
a compositor is concerned, two identical things.
More information about the wayland-devel