<div dir="ltr"><div><div><div><div>Hi Guilio, In fact, the client will be hidden anyway, because in order to keep some consistency, the compositor will hide it : "set_minimized()" function in "shell.c" : <a href="https://github.com/Tarnyko/weston-taskbar/blob/1.4.0-taskbar/desktop-shell/shell.c#L3385">https://github.com/Tarnyko/weston-taskbar/blob/1.4.0-taskbar/desktop-shell/shell.c#L3385</a> </div>What the client does, here, is that it knows it has been mimimized, and will handle in a specific way (slowing its rendering down, e.g.). </div>It seemed like a good compromise between some opinions expressed before : server-side or client-side. Here the server-side will hide the window, but the client-side *may* do some useful stuff. I may be wrong of course, and in that case we could just handle this server-side (the code just did this before). </div>Regards </div>Tarnyko, <div class="gmail_extra"> <div class="gmail_quote">2014-02-10 16:33 GMT+01:00 Giulio Camuffo <<a href="mailto:giuliocamuffo@gmail.com" target="_blank">giuliocamuffo@gmail.com</a>>: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">2014-02-10 17:25 GMT+02:00 Manuel Bachmann <<a href="mailto:manuel.bachmann@open.eurogiciel.org">manuel.bachmann@open.eurogiciel.org</a>>: <div class="">> Hi Bill, hi Jasper, hi everybody again, > > I just updated my taskbar code to make it work against Weston 1.4.0 : > <a href="https://github.com/Tarnyko/weston-taskbar/tree/1.4.0-taskbar" target="_blank">https://github.com/Tarnyko/weston-taskbar/tree/1.4.0-taskbar</a> > > And with regards to our former conversation, I added a logic that allows the > client to "know" when it has been minimized : > <a href="https://github.com/Tarnyko/weston-taskbar/commit/7b456ef103e9dd0e37d7cf74e55d87f7ffa64be9" target="_blank">https://github.com/Tarnyko/weston-taskbar/commit/7b456ef103e9dd0e37d7cf74e55d87f7ffa64be9</a> > > Here is how it works : > > - there are 2 new compositor-to-client requests in "xdg_shell.xml" (not > upstream, added them for the demo) : > xdg_surface_request_set_minimized > xdg_surface_request_unset_minimized > > - when a client using toytoolkit (weston-terminal for instance) wants to be > minimized, he asks the compositor : > xdg_surface_set_minimized(xdg_surface); > > - the compositor handles this with its own logic. In my current > implementation, he hides it from view, but the code is in #ifdef > HAVE_TASKBAR and he could very well do anything else ; > > - when the compositor is done, he tells the client surface it has been > minimized by sending : > xdg_surface_send_request_set_minimized(shsurf->resource); > > - the client gets its answer in : > xdg_surface_request_set_minimized( ... ) { .... } </div>I don't think that's a good idea. If i click on the taskbar I want the client to hide, even if it doesn't call the xdg_surface_request_set_minimized for any reason (it's frozen, it's broken, ...). It may make sense to send an event telling the client it has been minimized, thought it should not mean the client can stop rendering. <div class="HOEnZb"><div class="h5"> > > and in the specific case of toytoolkit, decides to suspend the redraw with : > > window_defer_redraw_until_configure (window); > > So it doesn't consume too much CPU until it's unminimized again. > > - if later, the surface would be un-mimimized, then the client would get the > answer with "request_unset_minimized()" and redraw its surface with : > window_schedule_redraw (window); > > So a video player, for example, could cpntinue playing sound but avoid > decoding some frames. > > BTW, if you remove the last commit of my code, the logic is compositor-only, > but with this commit, it becomes a kind of communication : > "client->compositor->shell" / "shell->compositor->client". > > What do you think of this ? > > Regards, > Manuel > > - > > > 2014-01-31 7:11 GMT+01:00 Bill Spitzak <<a href="mailto:spitzak@gmail.com">spitzak@gmail.com</a>>: > >> >> >> Jasper St. Pierre wrote: >> >>> A toolbox over a painting program that has two documents open. >>> >>> So, what is the expected behavior here exactly? There's a minimize button >>> on both of the content window's decorations, and clicking on one should >>> minimize all three windows? >> >> >> Clicking minimize of one of the documents makes only the document >> disappear. But then clicking on the minimize of the other document makes >> both the document and toolbox disappear. >> >> >>> What should using the "minimize keyboard shortcut" functionality of your >>> compositor do? Should it differ from using the button in the UI? What does >>> it do right now on X11 or other platforms? >> >> >> It should do EXACTLY the same thing as a minimize button. Any different >> behavior is a bug. >> >> >>> A client can ignore attempts to close it with the close box. >>> >>> Are you talking about simply having a minimize button in the server-side >>> decoration that does nothing? Or are you talking about the compositor >>> forcibly minimizing a window with e.g. a keyboard shortcut? >>> >>> The former is an application bug (the button does nothing because it was >>> wired to do nothing), and while it's certainly frustrating from a user >>> perspective, the compositor can still forcibly minimize or close the window. >> >> >> I would expect that a compositor shortcut key to close a window would >> first try sending a message to the app saying it wants to close, and the app >> can decide to not close (ideally by asking the user if they are sure, and >> the user says no). If it just killed the app or destroyed the window that >> could be very user-unfriendly and I am rather suprised anybody would suggest >> that. >> >> If an app is non-cooperative the compositor can do some stuff. For close >> it can kill the client if it is not responding to pings. Minimize probably >> should also force-hide the surface after a timeout even if the client is >> responding to pings. However this fallback stuff should not be part of the >> Wayland api and can be left up to the compositor writers to decide. >> > > > > -- > Regards, > > Manuel BACHMANN > Tizen Project > VANNES-FR > </div></div><div class="HOEnZb"><div class="h5">> _______________________________________________ > wayland-devel mailing list > <a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a> > <a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a> > </div></div></blockquote></div> -- <div dir="ltr">Regards, Manuel BACHMANN Tizen Project VANNES-FR </div> </div></div>