[PATCH] protocol: Add wl_shell_surface_set_notification

[Bill Spitzak]

Pekka Paalanen wrote:
> 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 don't think so, because...

It sounds like the important difference is that the compositor positions 
these windows.

Therefore I would like to see any sample implementation concentrate on 
this so that people do not confuse this with any "layer" system, which I 
feel would be very counter-productive. Perhaps attach them to the panel, 
so full screen windows remain above them, so the sample compositor makes 
it clear that this is not a "layer".

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

The client is responsible for this. Perhaps the event that caused the 
notification happens again, which should reset the timeout. Perhaps 
there is a display saying how long ago it happened, or you want to blink 
a lot before vanishing, etc.

> - is it the compositor or the client who will animate the notification
>   to and from screen?

The compositor is going to be limited to only doing animations that can 
be achieved using the image of the window (including it's alpha channel 
and the shadow area) and it is also going to have information like the 
opaque area, the input area, and also my proposed "non-edge area". This 
does mean it can't perfectly do things like a distortion of the window 
that still has a fixed-size "shadow".

Still it seems the compositor can do a lot, can make multiple clients 
animate together in sync, and this is a lot easier on the clients, so I 
feel it is better to have the compositor do it.

Animation should apply to normal windows, too. There is nothing special 
about notifications!

> - do these require further events, like "notification was hidden" due
>   to timeout or new notifications pushing old ones out?

Doesn't the actual mapping of a surface already cause an event to the 
client? I would reuse that, or if it is missing add it to *all* surfaces.

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

The client does not get the buffer-release event until after any 
animation using the current contents of the buffer finishes.

You have to do something if the client crashes in such a way that the 
shared buffer memory is lost. Or perhaps this is not possible in current 
shm solutions? If it is a problem the animation will have to be cancelled.