Weston : ideas about xdg_sell, and implementation for a taskbar

[Manuel Bachmann]

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( ... ) { .... }

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*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140210/d7d8bab3/attachment.html>