Weston : ideas about xdg_sell, and implementation for a taskbar

Mon Feb 10 07:45:41 PST 2014

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 <
manuel.bachmann at open.eurogiciel.org>:

> 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 <giuliocamuffo at gmail.com>:
>
> 2014-02-10 17:25 GMT+02:00 Manuel Bachmann
>> <manuel.bachmann at open.eurogiciel.org>:
>> > 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 <spitzak at gmail.com>:
>> >
>> >>
>> >>
>> >> 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
>> > wayland-devel at lists.freedesktop.org
>> > http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>> >
>>
>
>
>
> --
> Regards,
>
>
>
> *Manuel BACHMANN Tizen Project VANNES-FR*
>

-- 
Regards,

*Manuel BACHMANN Tizen Project VANNES-FR*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140210/5555a0b0/attachment-0001.html>