[PATCH] protocol: Add wl_shell_surface_set_notification

[Pekka Paalanen]

On Fri, 04 Jan 2013 15:27:55 +0100
Quentin Glidic <sardemff7+wayland at sardemff7.net> wrote:

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

I agree on the above points.

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

It seems wl_shell_surface does not have protocol for a destructor, so
the server cannot know when the client releases it. We also meant
wl_shell_surface as an additional interface into the wl_surface object,
not an object of its own.

But, maybe you could hook into the unmap action, i.e.
wl_surface.attach(NULL, 0, 0); wl_surface.commit. I wonder how easy it
is to keep the old surface contents around for the animation... it
might need a little work.

To the client it will only be visible as the wl_buffer.release event
coming much later than right after unmap, and the client can destroy
the wl_surface on that event.

Or, maybe we should just let clients to destroy the wl_surface, and
inside Weston decouple struct wl_surface from struct weston_surface.
That would allow closing animations in general, and not affect the
protocol at all. I might actually prefer this.

So, on wl_surface.destroy, the struct wl_surface gets released, but
struct weston_surface stays until the closing animation ends.
weston_surface may hold a reference to the wl_buffer as needed, and the
client is allowed to destroy the wl_buffer after receiving
wl_buffer.release, so the surface contents can be assumed to stay
around long enough.

Yeah, I believe this is how it should be done, and not complicate the
protocol with it nor require anything special from the client.

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

The client (i.e. notification daemon) can ask for a frame callback when
it first maps a surface. The compositor triggers the frame callback
when the surface hits the screen. Maybe the client could start the
timeout on receiving the frame callback?

This way, the first 4 notifications hit the screen, and the 5th just
gets into a queue in the compositor. Eventually at least one of them
gets dismissed, and then the 5th can finally be shown. This would also
work, when notifications appear when the desktop is locked, and they
are not shown while locked; they will get shown as soon as the user
unlocks the desktop.

Would that work?


Thanks,
pq