[PATCH] protocol: Add wl_shell_surface_set_notification

[Pekka Paalanen]

On Thu, 27 Dec 2012 11:36:43 -0200
Tiago Vignatti <tiago.vignatti at linux.intel.com> 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