Weston : ideas about xdg_sell, and implementation for a taskbar

[Giulio Camuffo]

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
>