[RFC weston] Views: Should we have a concept of "primary"?

[Jason Ekstrand]

Hello all,
Last night, I sent a set of patches to the list to split the geometry
information off of the weston_surface structure so that we can have a
single surface in multiple locations at the same time.  With this, comes an
interesting question: Should a surface have one view that is denoted the
"primary" or "default" view?  There are a number of places where this comes
up:

 1. In XWayland, we need to be able to update the client with its position
in global coordinates.  If it is in multiple locations, which location do
we give it?

 2. For frame callbacks, we need a concept of "primary output" for a
surface.  As of the patches I sent last night, this is chosen based on the
view with the biggest intersection with an output.  However, if there is a
primary view, we would probably want to use that view's output.

3. Transient shell surfaces.  Is it relative to all of the parent surface's
views or just the primary?

4. There are several other places such as black surfaces, input panel
surfaces, cursor surfaces, etc. where it would be convenient to have a
"primary" view.  However, in most of these cases, what we want isn't so
much a "primary" view as exactly one view.  For now, I'm dealing with this
case by storring the view and not the surface (see the commit message for
the drag-and-drop patch for details)

The problem is that there are also cases where "primary" view doesn't make
sense.  For instance, in my fullscreen shell, I am explicitly allowing a
client to specify that a particular surface goes on two different outputs
at the same time.  Neither of these outputs is preferred above the other in
any way, so it's hard to say that one output is "preferred".  For this
reason my current implementation does not provide a preferred output but
leaves that up to the shell.

Should we have a concept of a preferred output?  If so, how do we implement
it?

I can think of three ways that views could work:

1. Have a copy of weston_view as a "view" field in weston_surface.  For the
initial refactor, I did this.  However, it makes for some interesting
edge-cases (You can't, for instance, iterate over all of the views and
destroy them).  It does have the advantage that you're always guaranteed at
least one view and you know which one is primary.

2. Give the weston_surface structure a primary_view pointer which is
intended to be set by the shell and may be null.  This would allow the
shell (or pointer cursor or whatever else) to set a primary view to be used
for the above purposes.  However, we still have to deal with the
surface.primary_view == NULL case.

3. Not have a primary view at all.  Personally, I prefer this one.  This
way it is completely up to the shells how they want to handle views.  In
the patched version of desktop-shell, it stores a view in the shell_surface
structure and that's the primary one.  The problem with this is that it has
to pass that to XWayland (not a big deal) and there's no way it can force
which output fires the frame callbacks (bigger deal).

I'm open to suggestions and look forward to your feedback,
--Jason Ekstrand
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20130914/899be714/attachment.html>