"Standardize" namespaces in layer-shell

[ammen99]

The namespace of a surface is meant to also indicate how it should be positioned with respect to other layer-surfaces in the same layer, right? A particular example would be lockscreen and virtual-keyboard. Now I don't think this is the right way to solve the problem (why not just add a few more layers?), but if we're going to use namespaces, then we should also have a publicly accessible list of standard namespaces, so that both compositors and clients know what to use. For example, we should have namespaces for:

1. Lockscreens
2. On-screen keyboards
3. Notifications (like mako)
4. Various "widgets" like volume slidebar, brightness slidebar, etc. Perhaps also dialogues like "shutdown/restart" or "suspend/lock" also belong here.
5. Panels

Some of them are pretty trivial (like "panel" or "lockscreen"), but some aren't. Of course there might be also other use-cases which we also need to clarify.

[emersion]

• Backgrounds (swaybg, oguri)
• File managers showing desktop icons
• Authentication dialogs (ala GNOME Shell)
• Screen region selection programs (slurp)

[ddevault]

When I put this in, I figured that new clients would look around at anything which does something similar and use the same namespace.

[ammen99]

@ddevault Even if an app developer can find the namespace names from other apps, the compositor should know them in advance. Plus some people like me won't even understand what the namespace is for, so we might want to clarify things a bit more (which I will try to send a PR for, once we decide how clients and compositors can know what to support)

[ddevault]

Honestly, in retrospect I regret adding the namespace. The original intention was to allow the compositor to resolve z-ordering issues with clients by magically knowing which one should go on top based on the namespace, but that's really just a big mess. The goal of e.g. putting the OSK on top of the lock screen are better served by e.g. using a different protocol to indicate which surface is an OSK. I'd be open to removing it in v2 of the layer-shell protocol.

[ammen99]

I am not sure that simply dropping it is the way to go forward. There are many other use-cases.

[ddevault]

What are some of those use-cases? I suppose it's useful in the same way app-id is useful, but there's little value in standardizing that.

[ammen99]

The use-cases @emersion and I outlined above? For example a brightness slidebar - I assume this will be a good thing to have on top of lockscreens as well.

[AdrianVovk]

@ammen99 Well in that case I think there should just be another layer above lockscreen. I'm unsure if this is the right solution; layers might be expensive. It seems easier though to just have another layer from the shell developer's perspective. Messing around with a set of standardized strings very much seems like a hack.

[emersion]

Related: swaywm/swaylock#77

[Pajn]

Is there a reason why a z-index isn't used? The values for the above listed categories could be standardized/recommended for compatibility reasons but compositors wouldn't need to explicitly add support for each new entry on the list.

[ammen99]

@Pajn With a Z index we still need standardised values.

[ddevault]

z-indexing only works if the person assigning the indicies already knows about everything being ordered.

[Pajn]

Yeah, we would need standardized values but completeness of that list is less dire as no one is affected by missing values being added.

Say for example that we standardized:

Various "widgets" like volume slidebar, brightness slidebar, etc. Perhaps also dialogues like "shutdown/restart" or "suspend/lock" also belong here.: 90000
Lockscreens: 80000
Authentication dialogs (ala GNOME Shell): 70000
Notifications (like mako): 60000
On-screen keyboards: 50000
Screen region selection programs (slurp): 40000
Panels: 30000
File managers showing desktop icons: 20000
Backgrounds (swaybg, oguri): 10000

And that we later wanted something like MS Clippy that should go above panels but below region selections, now we can just standardize clippy as 35000 and it will work on all compositors directly without first having to add "clippy support".
It also works to a degree if you do something that wont be standardized. If the clippy idea is so silly that its rejected as a standard value, I can still use 35000 and know that it will show in the correct z order compared to other clients using standardized values.

[AdrianVovk]

This could behave like the system of port -> application mappings. There are enough ports to support nearly any application. The compositor wouldn't have to do much of anything special to handle the z-index (it won't have to care that 30000 = panels, and 80000 = lock screens, just that 80000 > 30000). App developers could just look at the standard list of layer-shell z-indexes and decide where it wants to go. I think this could work

One catch: @ammen99 we'll need a different way for cSH-panel to ask wayfire to sanely handle keyboard focus.

[ammen99]

@AdrianVovk I don't think namespace is going away in this version of layer-shell. In the next, I think we will have a sane way to achieve what we want.

[emersion]

wlr-protocols has migrated to gitlab.freedesktop.org. This issue has been moved to:

https://gitlab.freedesktop.org/wlroots/wlr-protocols/-/issues/44