<div dir="ltr"><div>Well, having read Jasper's comment, he has some valid points, the most important being in my opinion :</div><div> </div><div>> it matches user expectations. If the user clicks minimize on a window, they want it hidden</div>
<div> </div><div>It the logic of what should *really* happen when a window is minimized is implemented client-side, that means the UI experience will differ among client applications. Some may hide, some may iconify, some may just do nothing...</div>
<div> </div><div>One could object that the logic is to be implemented in the toolkit, so all applications using the same toolkit will end up doing the same. But that still means that if we have, for example, an application using GTK+, another one using EFL, another one using toytoolkit (weston-terminal), they'll behave differently.... ? We'd really like to avoid that.</div>
<div> </div><div>Maybe a middle ground can be found if :</div><div> </div><div>1) the desktop-shell-component can force a behaviour which WON'T touch any wl_surface nor wl_shell_surface state (i.e. no switch to any new MINIMIZED or whatever state, surface still considered fullscreen or maximized if it was before)</div>
<div> </div><div>2) the client application can still get the response back, and react the way it wants</div><div> </div><div>Which would imply, taking the case of Weston :</div><div> </div><div>- if no desktop_shell_taskbar or whatever manager plugin is present as a module, then client app just gets its response, and react the way it wants ;</div>
<div> </div><div>- if it is present, then this plugin communicates with the compositor to enforce some behaviour, BUT the client app still react the way it wants.</div><div> </div><div>What do you think of that ?</div><div>
</div><div>Regards,</div><div>Tarnyko</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-01-31 Manuel Bachmann <span dir="ltr"><<a href="mailto:manuel.bachmann@open.eurogiciel.org" target="_blank">manuel.bachmann@open.eurogiciel.org</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi Bill, and thanks a lot for sharing your thoughts,</div><div class="im"><div> </div><div>> You must allow a "toplevel" to become a non-toplevel and vice-versa</div>
<div> </div></div><div>That's true ; the current implementation doesn't address this case.</div><div class="im">
<div> </div><div>> My recommendation is that a surface has a "parent" that can be changed at any time to any other surface or to NULL</div><div> </div></div><div>So for an application having a "main" surface (let's say, the first that has been created) and child (transient ?) surfaces, the schema would be :</div>
<div>NULL -> shell_surface -> shell_surface -> shell_surface</div><div> |->shell_surface</div><div> </div><div>In that case, an implementation *could* just display a button for the first shell_surface on the left, and minimize it and all its children at the same time. Well, I suppose it's really something up to the actual implementation, so a sample impl. could just do it the easiest way.</div>
<div class="im">
<div> </div><div>> NO! The compositor must only send a "hide request" to the client. The client MUST be in final control over when and how it's surfaces disappear.</div><div> </div></div><div>Have just been reading the other (old) thread on this issue, so I get your objection :-).</div>
<div>I suppose I'll have to write a sample client application able to process such a request. GTK+ seems to have an impl, so I will check what it does.</div><div class="im"><div> </div><div>> I'm not clear on why the former api can't do this and you felt a new api had to be added.</div>
<div> </div></div><div>Well it's just a demo, I don't really feel like it should be merged in this state.In fact, I'd like to avoid adding any API.</div><div>----</div><div> </div><div>Taking your comments into account, here's what I think I should do next :</div>
<div> </div><div>- write a sample client able to send "xdg_shell_set_minimized()" requests, and process the responses to it ;</div><div>- write a minimal implementation for a "taskbar/main_shell_surfaces_list" (?) in the "shell" directory, and allow it to be built on demand ;</div>
<div>- make sure these 2 components communicate and react well.</div><div> </div><div>Thank you ; any further recommendation appreciated !</div><div> </div><div>Regards,<br>Manuel</div></div><div class="gmail_extra"><br>
<br>
<div class="gmail_quote">2014-01-31 Bill Spitzak <span dir="ltr"><<a href="mailto:spitzak@gmail.com" target="_blank">spitzak@gmail.com</a>></span>:<div><div class="h5"><br><blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote">
<div><br>
<blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote">
- When the compositor creates a shell_surface having the TOPLEVEL type,<br>
it sets a numeral ID for it, and sends a "map" event to the desktop_shell client ;<br>
</blockquote>
<br></div>
You must allow a "toplevel" to become a non-toplevel and vice-versa, otherwise useful api for rearranging windows is impossible. My recommendation is that a surface has a "parent" that can be changed at any time to any other surface or to NULL, the only restriction is that a loop cannot be created. In any case please do not make a "type" called TOPLEVEL.<div>
<br>
<br>
<blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote">
- if it should be hidden, then the compositor sends the shell_surface to a new<br>
weston_layer named "taskbar_layer". This layer is not displayed at all.<br>
</blockquote>
<br></div>
NO! The compositor must only send a "hide request" to the client. The client MUST be in final control over when and how it's surfaces disappear. This is to allow it to atomically remove child surfaces or to reparent them to other surfaces that are not being hidden.<div>
<br>
<br>
<blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote">
When their "minimize" button is pressed, they now call a taskbar_move_surface()<br>
function which will do the former, and additionally send a hint to the desktop_shell<br>
that this has been done (so the corresponding taskbar button stays tuned).<br>
</blockquote>
<br></div>
I'm not clear on why the former api can't do this and you felt a new api had to be added.<br>
</blockquote></div></div></div><br><br clear="all"><div class="im"><br>-- <br><div dir="ltr"><font>Regards,<br>
<br>
<i><b>Manuel BACHMANN</b><br>
Tizen Project<br>
VANNES-FR</i><br>
</font></div>
</div></div>
</blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr"><font>Regards,<br>
<br>
<i><b>Manuel BACHMANN</b><br>
Tizen Project<br>
VANNES-FR</i><br>
</font></div>
</div>