XDG-Decoration support

[Sunderland93]

Hello. Is there any plans to support xdg-decoration-unstable-v1 protocol?

[AlanGriffiths]

I'm aware of xdg-decoration-unstable-v1, and know there's at least one downstream project (Unity8) that would benefit it. So, yes, it is something we should support.

However, it is not something we've currently scheduled work on. If it is important to you, we'd be happy to see a PR.

I also have some thoughts about making it easy for shell developers to add and configure Wayland extensions. But that is currently something that informs any design work we do, not an active task.

[fabrizioiannetti]

Hi Alan,

this extension only allows clients to toggle on/off windows decorations on the server side.
Further APIs are required to allow the shell to specify the windows decorations, assuming Mir
itself does not want to provide that.

I haven't seen a wayland protocol that would allow to define that. I also understand that wayland protocols are targeted at compositor <-> client (i.e. an application) communication and it is assumed the shell is part of the compositor itself.

Have you had already some thoughts on a Mir API towards the shell, here specifically to decorate windows (wl_surfaces declared as shell windows via the xdg_shell)?

[AlanGriffiths]

I think you are misunderstanding the protocol.

If a client supports this protocol it should respect the configuration events sent by the server:

The configure event asks the client to change its decoration mode. The configured state should not be applied immediately. Clients must send an ack_configure in response to this event. See xdg_surface.configure and xdg_surface.ack_configure for details.

A configure event can be sent at any time. The specified mode must be obeyed by the client.

The client is allowed to request it's preference, but the server is in control.

[AlanGriffiths]

Oops, that's what comes of replying from a phone.

[RAOF]

This can now be prototyped outside of Mir proper using the bespoke Wayland extensions support if someone wanted to.

We are still interested in PRs providing this in Mir proper.

[mariogrip]

I have a TMP branch that implements this, maybe this would be better fit for upstream? https://gitlab.com/ubports/core/qtmir/-/commit/92397aa061bc868cad4d16fd8b4b3044226d371d

[RAOF]

That looks like a good start for a Mir PR!

I'm not sure how it would want to be exposed to Mir shells; it probably requires some new miral API - a window property, and some mechanism for setting the shell's preferred mode?

[wmww]

I don't think all that would be required, at least not for the simple case. We already have a server_side_decorated property on SurfaceCreationParameters (which is used for XWayland windows). These sorts of decorations are added by AbstractShell. To decorate or underrate a window after creation a SurfaceSpecification might need to be added, but no changes would be needed to Miral.

[AlanGriffiths]

@mariogrip we'd need a PR against the Mir source tree, not QtMir. The non-autogenerated code in this branch is mostly Qt (and QtMir) specific, so it's hard to know what would be usable. (I guess refactoring this so the QtMir support could be layered on top of miral or miroil would be a useful step.)

[AlanGriffiths]

closed by #3425