<div dir="ltr"> <div class="gmail_extra"> <div class="gmail_quote">2013/5/15 Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div><div>On Wed, 15 May 2013 14:20:21 +0200 Alexander Preisinger <<a href="mailto:alexander.preisinger@gmail.com" target="_blank">alexander.preisinger@gmail.com</a>> 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. </div></div>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. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> 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. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> 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. </blockquote><div> 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. </div> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> 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). </blockquote><div> 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. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Deja vu, </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> pq </blockquote><div> Thank you for your time Best Regards. Alexander Preisinger </div></div> </div></div>