Weston : ideas about xdg_sell, and implementation for a taskbar

Mon Feb 10 08:21:05 PST 2014

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 <giuliocamuffo at gmail.com>:

> 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
>

-- 
Regards,

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