Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

XDG-Decoration support #664

Open
Sunderland93 opened this issue Dec 4, 2018 · 4 comments

Comments

Projects
None yet
3 participants
@Sunderland93
Copy link

commented Dec 4, 2018

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

@AlanGriffiths

This comment has been minimized.

Copy link
Member

commented Dec 5, 2018

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

This comment has been minimized.

Copy link

commented Feb 14, 2019

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

This comment has been minimized.

Copy link
Member

commented Feb 14, 2019

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

This comment has been minimized.

Copy link
Member

commented Feb 15, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.