[Wayland] Use libdecor for window decorations

[RushingAlien]

Important Information

Provide following Information:

• mpv version : 0.35.1
• Linux Distribution and Version : Arch Linux rolling
• Source of the mpv binary : Flatpak
• If known which version of mpv introduced the problem
• Window Manager and version : Mutter 44.1
• GPU driver and version : Mesa 23.0.2

Reproduction steps

1. Use Weston(reference wayland compositor) or GNOME
2. Use MPV as a native Wayland client
3. See missing window decorations

Expected behavior

1. For there to be window decorations

Actual behavior

1. No Window decorations

   Log file

mpv.log

Additional Information

libdecor is a library for apps to easily draw CSDs for Wayland and has been implemented in

• Blender
• SDL2
• FLTK
• GLFW

libdecor also has a GTK plugin that allows libdecor window decorations to use GTK and Cairo to render itself, thus utilizing GTK themes as well, making the CSD look uniform

Qt plugin is also possible, but no one worked on that yet

[Dudemanguy]

libdecor is a relatively hefty dependency for something I would consider fairly minor. Is there something insufficient about the window decorations drawn by default via the osc?

[RushingAlien]

OSC?

[Dudemanguy]

When you hover the mouse over the window, there should be windowcontrols at the top by default where you can close, minimize, etc.

[RushingAlien]

Functionally, no, MPV's OSC decorations are fine Just that libdecor with GTK plugin would allow for a uniform look in GTK-based desktops

[CounterPillow]

What if I don't use GTK-based desktops?

Do you ask every non-GTK application to use libdecor instead of finally implementing SSD in M*tter? Is that how you infect all software with your disgusting GIMP-derived toolkit?

[RushingAlien]

libdecor isn't GTK, it is its own thing

libdecor has a GTK plugin to look like GTK decorations and also render the decorations with GTK Qt plugins and similar will also be possible, but no one wrote those yet

[CounterPillow]

because they don't need to exist on non-fascist compositors because those implement SSDs.

Live in the hell you yourself have created, GNOMElets.

[Artoriuz]

libdecor isn't GTK, it is its own thing

libdecor has a GTK plugin to look like GTK decorations and also render the decorations with GTK Qt plugins and similar will also be possible, but no one wrote those yet

I'd just like to say that this is false. Libdecor depends on GTK to draw GTK decorations. It's literally listed as a dependency: https://gitlab.freedesktop.org/libdecor/libdecor

[RushingAlien]

It's listed as an optional dependency so the GTK plugin can be and used and the plugin is a runtime plugin too.

you can split the plugin into a seperate package too from readme of libdecor

Optional

• egl (to build EGL example)
• opengl
• xkbcommon (to build cairo demo)
• gtk+-3.0 (for GTK plugin)

[Artoriuz]

I mean, sure. But you still need GTK to draw GTK decorations. Libdecor is pretty much useless without the GTK plugin, you don't need it anywhere else to get decorations as pretty much all compositors properly implement XDG decoration.

Don't get me wrong, I'd love to get these stupid decorations to work on Gnome without having to force XWayland too, but from a a design perspective it just doesn't make sense to demand third-party applications to include an extra dependency just to accommodate for a single compositor.

If there's only a single compositor creating problems for multiple applications, then it's obvious that it's the compositor that's at fault. If Mutter doesn't want to draw decorations, it could at least provide them and delegate all the rendering to the actual application (which is conceptually better than having multiple distinct processes responsible for painting the same window, gnome devs are right in this aspect).

[RushingAlien]

I think it's fine if it's a runtime linking/soft dependency instead of a build time/hard dependency which is how the projects I mentioned above such as SDL does it.

and libdecor can draw decorations without GTK, it would just look bland tho

And despite all compositors implementing xdg-decorations, Doesn't change that the reference compositor, weston, which is what apps should target, does not implement xdg-decorations either

[Dudemanguy]

weston, which is what apps should target

Not really, you should target the wayland spec. Ideally, compositors also target the spec and everyone works (yay). Implementation details vary across compositors and I've run into them a few times.

Anyways as for this request, it's probably not going to happen. It's a big dependency for something that's purely cosmetic and a better solution already exists that's pure wayland (xdg-decoration).

[ht990332]

When you hover the mouse over the window, there should be windowcontrols at the top by default where you can close, minimize, etc.

The problem with these is that they scale with the video dimensions. Small video dimensions make them difficult to see. The controls become too tiny.

[Dudemanguy]

Enforcing a minimum height on the windowcontrols is probably reasonable.

[ht990332]

Enforcing a minimum height on the windowcontrols is probably reasonable.

It would be the reasonable approach. Perhaps a maximum size as well if necessary?

Off the record, feel free to take my comments with a different tone than ones made by others. I'm in no way an "open source fanatic" nor do I care for X11 vs Wayland shortcomings or anything related to online communities. I have no opinion about any of that. My concern is mostly for usability. Thank you!

At most, I can compile mpv with -Dwayland=disabled and it should use X11/Xwayland instead. I'm very flexiable.