On Thu, 27 Dec 2012 11:36:43 -0200 Tiago Vignatti <[email protected]> wrote:
> Hi. I'm afraid that notification windows and tooltips are quite similar. > > I've built tooltip on toytoolkit using set_transient surface type, using > the inactive method (for not giving focus on it). So instead creating a > new surface type for notification windows, I think you can create a > dummy surface with output's size, create transient surface on it > (set_transient) and setting as inactive. Then for its configuration > (corner, order, etc), instead relying on the config file, we'd need to > create transient methods on the protocol for dealing with it (just like > the 'inactive') so windows could be configured independently. I guess > this gives a cleaner solution. I don't think so, because: - notifications do not have an obvious parent, semantically - to position the parent you propose, would need to actually map it, which makes it subject to floating window management rules, unless you add yet another shell surface type for it - you would be adding a lot of protocol for positioning notifications - all notification clients would need to agree on positioning by their own means, and they could not really avoid obscuring each other I really prefer the simple protocol of "set_notification", with which: - the compositor decides positioning according to user desktop preferences - positioning configuration is centralized to the compositor (the shell) - it is easy to show, say, the latest 3 notifications still open, to avoid obscuring the desktop too much, i.e. arranging all open notifications is simple and not tied to any protocol nor inter-client communication - notifications from several notification clients can easily be arranged well, without fighting Btw. "a notification client" here means a notification daemon the foremost, not usually an application issuing a notification (both ways are possible). From the IRC conversations I got that it would be good to allow several notification daemons to co-exist, and to me it seems quite trivial to do. > On 12/26/2012 03:59 PM, Quentin Glidic wrote: > > Notification surfaces are special surfaces that the user should > > always be able to see. The compositor is in charge of displaying > > them to be visible without disturbing the user workflow. > > --- > > protocol/wayland.xml | 12 +++++++++++- > > 1 file changed, 11 insertions(+), 1 deletion(-) > > > > diff --git a/protocol/wayland.xml b/protocol/wayland.xml > > index 0ce68ef..199f14f 100644 > > --- a/protocol/wayland.xml > > +++ b/protocol/wayland.xml > > @@ -527,7 +527,7 @@ > > </request> > > </interface> > > > > - <interface name="wl_shell_surface" version="1"> > > + <interface name="wl_shell_surface" version="2"> > > > > <description summary="desktop style meta data interface"> > > An interface implemented by a wl_surface. On server side the > > @@ -729,6 +729,16 @@ > > to the client owning the popup surface. > > </description> > > </event> > > + > > + <!-- Version 2 additions --> > > + > > + <request name="set_notification"> > > + <description summary="make the surface a notification surface"> > > + Notification surfaces are special surfaces that the user should > > + always be able to see. The compositor is in charge of displaying > > + them to be visible without disturbing the user workflow. > > + </description> > > + </request> > > </interface> This is a good start. There are some further questions, which might affect the needed protocol, just food for thought for the future: - is it the compositor or the client who will dismiss the notification on timeout? - is it the compositor or the client who will animate the notification to and from screen? - do these require further events, like "notification was hidden" due to timeout or new notifications pushing old ones out? - what happens to the hide animation, if the notification wl_surface gets destroyed? (i.e. how does the client need to behave, so that the animation can complete) Thanks, pq _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
