<div dir="ltr">Hello, <br><br>I thought a bit about it and like to present my ideas.<br>I mainly thought about it from the shell/compositor site when I like to minimize, maximize surfaces from keybindings, like in some window managers.<br>
<br>For example the client can still request minimize, maximize, fullsrceen and toplevel actions, but now the compositor responds with an state_update event.<br>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).<br>
The client can then save the state and act accordingly (like hiding same menus if maximized or fullscreen).<br><br>diff --git a/protocol/wayland.xml b/protocol/wayland.xml<br>index 3bce022..e0f2c4a 100644<br>--- a/protocol/wayland.xml<br>
+++ b/protocol/wayland.xml<br>@@ -811,6 +811,14 @@<br>       <arg name="output" type="object" interface="wl_output" allow-null="true"/><br>     </request><br> <br>+    <request name="set_minimized"><br>
+        <description summary="minimize the surface"><br>+    Minimize the surface.<br>+<br>+    The compositor responds with state_update event.<br>+    </description><br>+    </request><br>+<br>
     <request name="set_title"><br>       <description summary="set surface title"><br>        Set a short title for the surface.<br>@@ -867,6 +875,30 @@<br>       <arg name="height" type="int"/><br>
     </event><br> <br>+    <enum name="state"><br>+      <description summary="different states for a surfaces"><br>+      </description><br>+      <entry name="toplevel" value="1" summary="surface is neither maximized, minizized or fullscreen"/><br>
+      <entry name="maximized" value="2" summary="surface is maximized"/><br>+      <entry name="minimized" value="3" summary="surface is minizimed"/><br>
+      <entry name="fullscreen" value="4" summary="surface is fullscreen"/><br>+    </enum><br>+<br>+    <event name="state_update"><br>+        <description summary="update surface state"><br>
+    Tells the surface which state is has on the output.<br>+<br>+    This event is sent in respons to set_maximized, set_minimized or<br>+    set_fullscreen request to acknowledge the request. The client can update it<br>
+    own state if it wants to keep track of it.<br>+<br>+    The also compositor sends this event if itt wants the surface minimized or<br>+    maximized. For example by clicking on a task list item or compositor key<br>+    bindings for fullscreen.<br>
+    </description><br>+        <arg name="state" type="uint" summary="new surface state"/><br>+    </event><br>+<br>     <event name="popup_done"><br>       <description summary="popup interaction is done"><br>
        The popup_done event is sent out when a popup grab is broken,<br><br><br>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.<br>
<br><br>Best Regards,<br><br><br>Alexander Preisinger<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/5/14 Kristian Høgsberg <span dir="ltr"><<a href="mailto:krh@bitplanet.net" target="_blank">krh@bitplanet.net</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Tue, May 14, 2013 at 2:30 AM, Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com">ppaalanen@gmail.com</a>> wrote:<br>

> On Mon, 13 May 2013 17:26:28 -0500<br>
> Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> wrote:<br>
><br>
>> On Mon, May 13, 2013 at 4:14 PM, Rafael Antognolli <<a href="mailto:antognolli@gmail.com">antognolli@gmail.com</a>>wrote:<br>
>><br>
>> > Hi Jason,<br>
>> ><br>
>> > On Wed, May 8, 2013 at 9:26 PM, Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>><br>
>> > wrote:<br>
>> > > Hi Rafael,<br>
>> > ><br>
>> > ><br>
>> > > On Wed, May 8, 2013 at 6:04 PM, Rafael Antognolli <<a href="mailto:antognolli@gmail.com">antognolli@gmail.com</a>><br>
>> > > wrote:<br>
>> > >><br>
>> > >> Hello,<br>
>> > >><br>
>> > >> I've been looking the Weston code relative to maximized windows, and<br>
>> > >> it seems that the respective code for minimized windows wouldn't be<br>
>> > >> hard to implement.<br>
>> > >><br>
>> > >> The questions are: are there any plans to add it? Is there someone<br>
>> > >> already working on it? If not, would it be OK if I start submitting<br>
>> > >> patches to try to add support for this?<br>
>> > ><br>
>> > ><br>
>> > > A month or two ago, Scott Morreau was working on it.  However, his work<br>
>> > > never made into weston for a variety of reasons.  Personally, I'm glad to<br>
>> > > see someone interested in working on it again because it's something that<br>
>> > > wayland will need eventually.<br>
>> > ><br>
>> > > The place to start on it is probably with the following e-mail and the<br>
>> > long<br>
>> > > string of replies:<br>
>> > ><br>
>> > ><br>
>> > <a href="http://lists.freedesktop.org/archives/wayland-devel/2013-March/007814.html" target="_blank">http://lists.freedesktop.org/archives/wayland-devel/2013-March/007814.html</a><br>
>> > ><br>
>> > > There was quite a bit of discussion about how to handle it from a<br>
>> > protocol<br>
>> > > level, but Scott never made an actual version 2.  I'd suggest you start<br>
>> > by<br>
>> > > reading the chain of e-mails (it goes into April, not just March).  There<br>
>> > > were quite a few suggestions in there that could be incorporated.<br>
>> > > Hopefully, you can pick through the e-mail discussion and figure out what<br>
>> > > the consensus was.  It'd be good to have a pair of fresh eyes look at it.<br>
>> ><br>
>> > Thanks for pointing that out. I just went through the chain of<br>
>> > e-mails, but I don't think there was a consensus there.<br>
>> ><br>
>> > It also seems that the minimize implementation is a little more<br>
>> > complex than just hiding surfaces and marking some flags. Which makes<br>
>> > me not so comfortable doing an implementation without a consensus<br>
>> > about what should be implemented, and with some orientation.<br>
>> ><br>
>> > That said, I'm not sure I'm really going to take this task.<br>
>> ><br>
>><br>
>> I didn't intend to scare you off.  Honestly, I don't know for 100% certain<br>
>> how much weston machinery is needed to implement it.  It would require some<br>
>> sort of set of flags to keep the compositor and shell plugin in sync.  That<br>
>> said, I don't know if its quite as difficult as Scott made it sound.<br>
>><br>
>> As far as direction goes, the first thing is to think through use-cases and<br>
>> settle on a protocol.  Unfortunately, the discussion I linked you to seemed<br>
>> to go nowhere.  However, a lot of that was Scott saying, "This is the way I<br>
>> want to do it and I'm not going to change."  If you look at the other<br>
>> comments, I think there was some consensus in there (at least in a general<br>
>> direction).  Feel free to throw some XML together and we can re-start the<br>
>> discussion.  For that matter, if you can come up with a way to do it as a<br>
>> weston extension for now (with the hopes of putting it in wayland core<br>
>> later), things can be a lot more flexible and we can play around with<br>
>> protocol concepts as we go.<br>
>><br>
>> Once a basic protocol is in place, then the client-side needs to be<br>
>> implemented in tinytk (window.c) and the server-side needs to be<br>
>> implemented in weston.<br>
>><br>
>> I'm sorry "I want to add X feature" isn't simpler.  Basically every new<br>
>> major protocol piece goes through a long mailing list discussion and a lot<br>
>> of revision.<br>
><br>
> Also worth noting, that there are actually two different pieces of<br>
> protocol involved with minimized windows:<br>
><br>
> - the public protocol, likely part of wl_shell_surface, which all<br>
>   applications use to communicate with the server. This is the<br>
>   important part that will go under strict review, but it is probably<br>
>   also the simpler of the two. You could also check what DE<br>
>   projects have done on this (Gnome/gtk, KDE/Qt, EFL, ...).<br>
><br>
> - the private protocol between Weston and weston-desktop-shell<br>
>   specifically. As we have chosen to let weston-desktop-shell client do<br>
>   all the GUI drawing, and minimized windows will need some GUI (a task<br>
>   bar button, a menu list of windows) to be able to get them back, we<br>
>   need protocol to inform weston-desktop-shell about the windows so it<br>
>   can draw the GUI.<br>
><br>
> But these should not be complicated, once you understand how the basics<br>
> of a Wayland protocol work. And you don't need to have any complex<br>
> foreign surface passing protocol to get window thumbnails by hovering<br>
> the pointer over a taskbar button. Thumbnails can be added later, as it<br>
> does not concern the public protocol at all.<br>
<br>
</div></div>We don't need even need to pull that complexity in in the first step.<br>
We can simply allow mod-tab to select minimized windows and unminiized<br>
if they're selected.<br>
<span class="HOEnZb"><font color="#888888"><br>
Kristian<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br>
</div></div></blockquote></div><br></div>