[RFC] mir-shell #3166
[RFC] mir-shell #3166
Conversation
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #3166 +/- ##
==========================================
- Coverage 77.81% 77.47% -0.34%
==========================================
Files 1062 1066 +4
Lines 74645 75297 +652
==========================================
+ Hits 58083 58340 +257
- Misses 16562 16957 +395 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
I've focused on the protocol definition here, a chunk of questions / tweaks inline.
FWIW I don't think we should be referring layer_shell, even if they share concepts. We don't want to introduce a dependency.
Or are we saying that these could replace layer shell? E.g. since Freestyle is documented with "It should be rarely used and require unusual steps to enable" - should it be a separate interface, or mediated somehow?
Agreed.
I'm happy to drop freestyle for the time being. It is (even in the old design docs) under-specified, it was here as a placeholder in case review identified a reason to fill that design out. |
There was a problem hiding this comment.
A global question: the archetype presumably wants to be double-buffered state, so that both client and server can have a consistent view of things. Should get_*_surface require the wl_surface to be committed before taking effect?
Since the surfaces we're talking about here are almost certainly also xdg_toplevels, how does this integrate with the xdg_surface mapping/configure dance?
|
|
||
| <request name="destroy" type="destructor"> | ||
| <description summary="destroy the normal surface"> | ||
| This request destroys the mir surface. |
There was a problem hiding this comment.
I think the correct thing to say here would be that this removes the archetype.
| <description summary="assign the mir_regular_surface_v1 archetype"> | ||
| Create a mir_regular_surface_v1 archetype for the given surface. This assigns | ||
| the archetype of regular_surface to the wl_surface, or raises a protocol error | ||
| if another archetype is already assigned and the transition is disallowed. |
There was a problem hiding this comment.
How does a client know what transitions are allowed?
There was a problem hiding this comment.
I need to document a lot more of this section of "Mir and Unity: Surfaces, input, and displays" somewhere. I put off doing that because I felt it more urgent to get this discussion going.
There was a problem hiding this comment.
Ah, good. I wasn't sure if the plan was to dump a bunch of that in here.
dd447e6 to
1cecbef
Compare
There was a problem hiding this comment.
Top level question: we need to document how this interacts with xdg_wm_base. Particularly: The archetype of a window is going to potentially change client-visible state - we'll want to send different initial configure events for a regular window vs a satellite positioned near the edge of the screen. It will definitely influence the xdg_wm_base events we send out - for example, a dialog is not mimimisable, so we'll want to not send minimized in the wm_capabilities event for such a window, but a normal window is minimisable, so we need to include minimized in wm_capabilities for such a window.
Likewise, changing archetype is likely to generate client-visible xdg_surface or xdg_toplevel events.
This suggests that these state changes need to double-buffered state bound to wl_surface.commit() and be tied in to the xdg_surface configure/ack_configure dance.
I'd suggest that we specify that an archetype SHOULD be set in the initial buffer-less configure of the xdg_surface construction dance, and that it behaves as xdg_surface-role state.
Because we need to specify in such detail how this interacts with xdg_wm_base, I think that there's little point in having this act on wl_surfaces rather than explicitly on xdg_toplevels. wl_shell is dead to the point that major compositors (at least GNOME Shell) no longer advertise it at all, and should any other shell interface come along we would likewise need to specify how mir_shell_v1 interacts with the new shell system, which would need a protocol revision.
| </request> | ||
| </interface> | ||
|
|
||
| <interface name="mir_positioner_v1" version="1"> |
There was a problem hiding this comment.
I'm still not sure why this cannot just be xdg_positioner by reference rather than by copy.
All of the interfaces of xdg_positioner appear to be sensible to me; indeed, the v3 addition (particularly set_reactive) seem to be almost designed for mir_satellite here - while it's very uncommon that the parent of a popup will be moved (as that will usually imply an out-of-popup input event, that will usually trigger the popup to be closed) it's going to be quite common for parents of satellites to be moved.
| Therefore, the dialog and all of its ancestors should be presented as a single entity | ||
| in any window switcher. | ||
|
|
||
| Partly because of that last behavior, a window should only ever have one dialog child at |
There was a problem hiding this comment.
Since dialogs are used for information that needs to be explicitly acknowledged or responded to, maybe trying to add a second dialog should be a protocol error instead? There's not necessarily an obvious way to choose what happens when closing a dialog.
(I know this is from the doc; I'm suggesting we revisit that decision in light of the new context)
That ignores the possibility of changing archetypes (that's more text I need to incorporate) |
No, you'd still be able to change archetypes (although we should also mention what dance should be done to do that). My suggestion is that the initial archetype should be set in the initial |
| <description summary="create surface archetypes that are recognised by the desktop"> | ||
| Clients can use this interface to assign an archetype to wl_surfaces. | ||
|
|
||
| An archetype is like a `wl_surface` role: a surface may have at most one |
There was a problem hiding this comment.
Oh! New question: what happens if you try and apply an archetype to a wl_surface that has the wl_subsurface role, or wl_cursor role, or xdg_popup role?
There was a problem hiding this comment.
Or setting a role on a window that has one of these archetypes? A protocol error, I guess.
| There are some `wl_surface` roles that conflict with the archetypes described | ||
| here. Attempting to set both an archetypes and such roles on a surface is a | ||
| protocol error. In particular, `wl_subsurface`, `wl_cursor` or `xdg_popup` may | ||
| not be combined with an archetype. |
There was a problem hiding this comment.
Since the behaviour of “you tried a bad combination” is “your application crashes” and there's no other way than reading the protocol of discovering what combinations are bad I don't think we can be anything but exhaustive in enumerating the valid combinations here.
What wl_surface roles should be supported? xdg_toplevel, and…? Maybe layer shell surfaces, but they're already pretty special and I don't think any of this window management applies to them. wl_shell is dead dead dead and no client is going to use it in new code.
This does further suggest that the correct object type for this extension to act on is xdg_toplevel rather than wl_surface.
There was a problem hiding this comment.
This does further suggest that the correct object type for this extension to act on is
xdg_toplevelrather thanwl_surface.
I don't, at this stage, want to tie mir-shell to xdg-shell. As specified here it is compatible with wl-shell. I know wl-shell is deprecated, but I want to be open to a hypothetical alternative (for AR perhaps?) and it still exists.
In future we will likely want to propose something based on experience to wayland-protocols, that is the time to think more closely about integration with (or extension of) xdg-shell.
Relying on xdg_toplevel and xdg_positioner is clearly a plausible change if we choose that.
There was a problem hiding this comment.
What
wl_surfaceroles should be supported?xdg_toplevel, and…? Maybe layer shell surfaces, but they're already pretty special and I don't think any of this window management applies to them.wl_shellis dead dead dead and no client is going to use it in new code.
An alternative is to include the other archetypes Mir currently deduces from the xdg-shell role & attributes. And document how that happens. Then we need only talk about archetypes?
Layer-shell, is something orthogonal
|
The last comment aside, I think this is pretty good to go. We can refine the protocol over time, but I think the foundations are solid enough here to usefully start on a spike. |
… archetypes to be expressed when windows are created or modified
30e87e8 to
29d10d4
Compare
|
Flipping for CI verification. |
Welcome to Codecov 🎉Once merged to your default branch, Codecov will compare your coverage reports and display the results in this comment. Thanks for integrating Codecov - We've got you covered ☂️ |
Prototype implementation of mir-shell prototcol extension.
This includes a demo client:
mir_demo_client_mir_shell.The client can windows from the "regular", "satellite", "dialog" and "floating_regular" archetypes.
Ctrl-QCtrl-T(for "toolbar"), press again to create on another edge, closed byescCtrl-D, closed byescCtrl-F, closed byesc