[PATCH] protocol: Add wl_shell_surface_set_notification

Quentin Glidic sardemff7+wayland at sardemff7.net
Fri Jan 4 06:27:55 PST 2013


On 04/01/2013 14:25, Pekka Paalanen wrote:
> This is a good start.
> 
> There are some further questions, which might affect the needed
> protocol, just food for thought for the future:

I’m not a big fan of animations but I understand people might want it
and it should be handled.


> - is it the compositor or the client who will dismiss the notification
>   on timeout?

The client should do that.


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

The compositor, since the client has no way to know where the surface is
and how it should appear/disappear (e.g. if the surface should slide
from/to the top or the bottom).


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

The client is in charge of knowing when the notification should
disappear (see the “persistence” hint of fdo notifications). So


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

Destroy the wl_shell_surface (which trigger the animation), wait for
some event, then destroy the wl_surface?


The only problem I see is when non-visible surfaces are destroyed. Say
the compositor will display only 4 notifications and that a client (or
multiple ones) wants to display 5 at the same time. They are likely to
be destroyed at the same time too, resulting in the last one not being
visible at all.
Currently, in eventd with the X11 backend, I just admit the user to
being smart enough to not ask for too many notifications at the same
time. It would “work” with Wayland too, but it is unsafe: eventd is
user-configuration-oriented, so it is fine to assume the user is smart,
but with multiple clients you cannot make such an assumption.

Informing the client that the surface is not yet visible is not an
option to me since existing daemon does not support such a behavior, afaik.
I have no idea how to handle that case gracefully.

Cheers,

-- 

Quentin “Sardem FF7” Glidic


More information about the wayland-devel mailing list