2013/5/15 Pekka Paalanen <[email protected]> > On Wed, 15 May 2013 14:20:21 +0200 > Alexander Preisinger <[email protected]> wrote: > > > Hello, > > > > I thought a bit about it and like to present my ideas. > > I mainly thought about it from the shell/compositor site when I like to > > minimize, maximize surfaces from keybindings, like in some window > managers. > > > > For example the client can still request minimize, maximize, fullsrceen > and > > toplevel actions, but now the compositor responds with an state_update > > event. > > The compositor can also send this state_update when the compositor likes > > change the window on it's own (like some task bar or compositor key > > bindings). > > The client can then save the state and act accordingly (like hiding same > > menus if maximized or fullscreen). > > > > diff --git a/protocol/wayland.xml b/protocol/wayland.xml > > index 3bce022..e0f2c4a 100644 > > --- a/protocol/wayland.xml > > +++ b/protocol/wayland.xml > > @@ -811,6 +811,14 @@ > > <arg name="output" type="object" interface="wl_output" > > allow-null="true"/> > > </request> > > > > + <request name="set_minimized"> > > + <description summary="minimize the surface"> > > + Minimize the surface. > > + > > + The compositor responds with state_update event. > > + </description> > > + </request> > > + > > <request name="set_title"> > > <description summary="set surface title"> > > Set a short title for the surface. > > @@ -867,6 +875,30 @@ > > <arg name="height" type="int"/> > > </event> > > > > + <enum name="state"> > > + <description summary="different states for a surfaces"> > > + </description> > > + <entry name="toplevel" value="1" summary="surface is neither > > maximized, minizized or fullscreen"/> > > + <entry name="maximized" value="2" summary="surface is maximized"/> > > + <entry name="minimized" value="3" summary="surface is minizimed"/> > > + <entry name="fullscreen" value="4" summary="surface is > fullscreen"/> > > + </enum> > > + > > + <event name="state_update"> > > + <description summary="update surface state"> > > + Tells the surface which state is has on the output. > > + > > + This event is sent in respons to set_maximized, set_minimized or > > + set_fullscreen request to acknowledge the request. The client can > > update it > > + own state if it wants to keep track of it. > > + > > + The also compositor sends this event if itt wants the surface > > minimized or > > + maximized. For example by clicking on a task list item or compositor > > key > > + bindings for fullscreen. > > + </description> > > + <arg name="state" type="uint" summary="new surface state"/> > > + </event> > > + > > <event name="popup_done"> > > <description summary="popup interaction is done"> > > The popup_done event is sent out when a popup grab is broken, > > > > > > I don't know about multiple window applications and maybe missed some > other > > use cases, but I hope this isn't too wrong of an idea. At least this > should > > hopefully not break the protocol too much. > > If I understood right, here you have the client asking the compositor > for permission, and then the compositor orders the client to be in a > certain state and will compose it as such, regardless of what the client > actually draws. > > This won't work, fixing the races it causes will complicate the > protocol and cause roundtrips. > > The client draws its window, hence the client is in charge of how it > looks, and the compositor cannot force that. > > Hence, it must be compositor proposing to the client that it should > e.g. maximize. It the client does that at some point, perhaps first > sending a few new frames since it was animating, the client will tell > the compositor it will now go maximized, and then the very next frame > it draws will be maximized. This avoids flicker. > > Yes that seems logical. So the update_state should then be a request/suggest_state event? It seems I am tainted by using tiling window managers, where they sometimes forces the size.
> Minimize is a little special, since the client does not need to react > specially for it to look right. For everything else it will need to. > Actually, if you think about a multi-window application, minimize needs > to work the same way, so that application can hide all relevant > windows (but maybe not *all* windows). > > My Idea is that the client gets notified per shell surface and the client can hide all windows (for example we want to minimize the main window) or just the requested/proposed window. I will try get some basic implementation done, maybe I can reuse soreaus code for this. > > Deja vu, > pq > Thank you for your time Best Regards. Alexander Preisinger
_______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
