Weston : ideas about xdg_sell, and implementation for a taskbar

[Manuel Bachmann]

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