[PATCH wayland v2] protocol: define the concept of wl_surface role

[Pekka Paalanen]

On Tue, 19 Aug 2014 13:04:54 -0700
Bill Spitzak <spitzak at gmail.com> wrote:

> On 08/19/2014 12:29 AM, Pekka Paalanen wrote:
> 
> > +      Often, this
> > +      request also creates a new protocol object that represents the
> > +      role and adds additional functionality to wl_surface. When a
> > +      client wants to destroy a wl_surface, they must destroy this 'role
> > +      object' before the wl_surface.
> 
> Destroying the last protocol object for the role does not remove the 
> role, correct? The client can recreate a new protocol object for that 
> role and it still works?

Recreating the same role works, because that is kind of required with
cursors and drag icons.

> > +      Losing a role means losing all the role-specific state.
> 
> I'm not sure what you are saying here. I think maybe you are talking 
> about a surface that was used for drag & drop when the drag & drop ends?

No.

I mean that, for example, if you have a wl_surface, that has a
xdg_surface and is mapped at some location on screen with some window
state (maximized etc.), and you destroy the xdg_surface protocol
object, all the xdg_surface state will be lost, and the window
disappears from the desktop. If you then keep the wl_surface a re-create
the xdg_surface object for it, the outcome is the same as if you
destroyed the wl_surface all the way, and created a new one. You have
to set all xdg_surface state from scratch, which also means the client
cannot guarantee a floating top-level window shows up at the same
position where it left.

IOW, if you want to keep the role-related state, don't lose the role.
That is also something that protocol designers need to keep in mind.

> I thought in that case the surface must be destroyed: ie once a surface 
> "loses a role" it cannot be assigned any role, including the same one. 
> But in that case the "state" is irrelevant.

Yeah, but the cursor spec does not yet talk about roles and does not
exactly guarantee wl_pointer.set_cursor is always effective. That needs
more writing.

> Are you allowed to reuse the drag & drop surface for another drag & 
> drop? If the creation request also sets some state it is obvious that 
> portion of the state is not preserved. But it seems a lot easier on both 
> clients and compositors if other state is allowed to be preserved.

Yes, this wording allows re-using a wl_surface that once was a drag
icon, to be a drag icon again.

What other state, the role's or the wl_surface's? We have to be explicit
in any case about the role's state, because inconsistency between
implementations would be very bad, whatever the spec ends up.


Thanks,
pq