<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div>Hello all,<br></div>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:<br>
<br></div> 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?<br><br></div> 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.<br>
<br></div>3. Transient shell surfaces.  Is it relative to all of the parent surface's views or just the primary?<br><br></div>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)<br>
<br></div>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.<br>
<br></div>Should we have a concept of a preferred output?  If so, how do we implement it?<br></div><br>I can think of three ways that views could work:<br><br></div>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.<br>
<br></div>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.<br>
<br></div>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).<br>
<br></div>I'm open to suggestions and look forward to your feedback,<br></div>--Jason Ekstrand<br></div>