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" : https://github.com/Tarnyko/weston-taskbar/blob/1.4.0-taskbar/desktop-shell/shell.c#L3385 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 <[email protected]>: > 2014-02-10 17:25 GMT+02:00 Manuel Bachmann > <[email protected]>: > > Hi Bill, hi Jasper, hi everybody again, > > > > I just updated my taskbar code to make it work against Weston 1.4.0 : > > https://github.com/Tarnyko/weston-taskbar/tree/1.4.0-taskbar > > > > And with regards to our former conversation, I added a logic that allows > the > > client to "know" when it has been minimized : > > > https://github.com/Tarnyko/weston-taskbar/commit/7b456ef103e9dd0e37d7cf74e55d87f7ffa64be9 > > > > 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 <[email protected]>: > > > >> > >> > >> 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 > > [email protected] > > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > > > -- Regards, *Manuel BACHMANN Tizen Project VANNES-FR*
_______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
