Agreed ; it makes a lot more sense this way. 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. Regards, Tarnyko 2014-02-10 16:54 GMT+01:00 Giulio Camuffo <[email protected]>: > 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 > <[email protected]>: > > 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 > > <[email protected]>: > > > >> 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 > > > > > > > > > > -- > > Regards, > > > > Manuel BACHMANN > > Tizen Project > > VANNES-FR > -- Regards, *Manuel BACHMANN Tizen Project VANNES-FR*
_______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
