Weston : ideas about xdg_sell, and implementation for a taskbar

Mon Feb 10 07:54:49 PST 2014

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