<div dir="ltr"><div><div>Agreed ; it makes a lot more sense this way. </div>BTW, I'm not sure we *really* need to add things to xdg-shell. We'd just need it if we want to have client-side logic. A pure server-side logic just needs modifications in desktop-shell. I think my question is really what a Weston implementation should do. Currently, the code can do it both ways. </div>Regards, Tarnyko </div><div class="gmail_extra"> <div class="gmail_quote">2014-02-10 16:54 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">If the client will be hidden anyway the naming of request_set_minimize() seems odd to me, then. It should be like notify_set_minimize(), after which the client is not required to call set_minimized(), since it is so already. Giulio 2014-02-10 17:45 GMT+02:00 Manuel Bachmann <div class="HOEnZb"><div class="h5"><<a href="mailto:manuel.bachmann@open.eurogiciel.org">manuel.bachmann@open.eurogiciel.org</a>>: > Oh, and I forgot to add, the taskbar has its own logic asking the compositor > to hide, so clicking on the taskbar will do this, too. Sorry for the > additional noise. > > Regards, > Manuel > > > 2014-02-10 16:43 GMT+01:00 Manuel Bachmann > <<a href="mailto:manuel.bachmann@open.eurogiciel.org">manuel.bachmann@open.eurogiciel.org</a>>: > >> 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" target="_blank">https://github.com/Tarnyko/weston-taskbar/blob/1.4.0-taskbar/desktop-shell/shell.c#L3385</a> >> >> 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.). >> >> 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). >> >> Regards >> Tarnyko, >> >> >> 2014-02-10 16:33 GMT+01:00 Giulio Camuffo <<a href="mailto:giuliocamuffo@gmail.com">giuliocamuffo@gmail.com</a>>: >> >>> 2014-02-10 17:25 GMT+02:00 Manuel Bachmann >>> <<a href="mailto:manuel.bachmann@open.eurogiciel.org">manuel.bachmann@open.eurogiciel.org</a>>: >>> > 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( ... ) { .... } >>> >>> 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. >>> >>> > >>> > 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 >>> > >>> > _______________________________________________ >>> > 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> >>> > >> >> >> >> >> -- >> Regards, >> >> Manuel BACHMANN >> Tizen Project >> VANNES-FR > > > > > -- > Regards, > > Manuel BACHMANN > Tizen Project > VANNES-FR </div></div></blockquote></div> -- <div dir="ltr">Regards, Manuel BACHMANN Tizen Project VANNES-FR </div> </div>