Muffin appears to lack the XDG_DECORATION extension #25
Comments
dominichayesferen
changed the title
|
The problem is really big, because GNOME not want to include some protocols in Mutter, that other Linux compositors want to have. The inclusion of new protocols probably means change a lot of things in Muffin and make the process of fork Mutter again really hard. On the other hand, not including some of these protocols means abandoning the path that Mint chose for Cinnamon, of running some features outside of the compositor thread. Also means make hard the creation of the desktop components, to the external developers. Here are some other interesting protocols that Mutter not have: Also, this will be really interesting: My best recommendation would have been to use sway https://swaywm.org/, but unfortunately this is not entirely easy, since Cinnamon is not really a Gtk desktop. So, at the end I don't see clear what will be the best path to take. Mint developers should analyze that carefully and take a decision before go in a direction. |
|
It's not really feasible to switch compositors without writing glue to bridge the Mutter APIs with another compositor. It might be worth seeing if folks like @jadahl or @fmuellner would be open to contributions to Mutter for features GNOME doesn't want to use for the benefit of the other Mutter consumers so that the delta between Mutter and Muffin could be reduced, but who knows. |
|
We're aware of the additional protocols out there -
I'd rather not hang my hopes on that. We've never been a fan of a single process desktop, even less so with a wayland session, and this eventual transition opens an opportunity for us to consider other compositors or pare down how we use muffin/mutter. What we've done so far has been fairly 'low-hanging fruit' - we wanted to see where Cinnamon itself stood. It's important for us to be able to keep our xlet system stable no matter what. |
|
It might be worth talking to @serebit and @JoshStrobl then, they're looking at the same problem for Budgie. |
Elementary's Gala is being ported to Wayland and uses libmutter, and aims to be multi process (e.g. out of process panel, etc), so don't consider that a blocker; it implements custom Wayland protocols in their compositor. GNOME Shell itself allows extensions to outsource things it wants to external processes as well, that is e.g. how the drop-down terminal is implemened on Wayland, with a GTK/libvte client that gets treated differently in the compositor. |
Yes, it's possible create more process. This is for example, what desktop icons is doing (also directly in gjs) and you also helped to make it possible. You also are helping to make the Gala attempt possible (example: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3092). Thanks for that @jadahl. However, the problem here is that Mint has no way of dealing with the amount of work that any of those options would represent. I wonder if it is possible in some way, probably with some type of Mutter extension or plugin, to access the internal implementation of Mutter without having to modify the upstream code directly, in order to be able to implement the missing Wayland plugins from the outside. Maybe this will make it easier for Mint to center in what they need, without having to face everything that maintaining a project like Mutter represents. You know, I read somewhere that you were one of those who thought that the possibility to implement Wayland for small projects, was that they will be affiliate with the large ones (Like GNOME, KDE, Sway). The problem is exactly this, that joining many times means giving up the very things that made them different. I have seen many of your arguments for not including a certain Wayland plugin and the truth is that the reasons seem valid to me, as do the reasons opposite to yours. I wish that instead of so much justification, the center of the discussion revolved around achieving consensus, rather than the interests and visions of each particular projects. I know, I'm asking too much... |
@Conan-Kudo, No. What i said was fully abandon Mutter and fully modify Cinnamon to run inside a different compositor. So, in that case, the Mutter API not need to be honored anymore and probably also you will need to abandon Clutter in favor of Gtk3 and... But my idea is a lot of work anyway. My real point is that I think that the sway project is really the generic Linux compositor with all externals projects should be affiliate. The other projects are, in my opinion, very specific and closed to a very particular environment and therefore external projects should avoid them at all costs and favor the inclusive options, not sides ones. |
|
Sway is not the right point of interaction for what you're talking about. The right point of interaction is wlroots. Sway is specifically a tiling window manager, and that is incompatible with Cinnamon too. You'd need to build a new compositor tailored for Cinnamon's gnome-shell-like interfaces using a library like wlroots, Mir, or Louvre. |
|
Yes, sure, but use wlroots and implement all the rest is also a lot of work. Sway have something more close to something usable and is the implementation that have more useful protocols already implemented and is more open to included more protocols. Is my opinion ofcourse. |
"internal access" is only possible with GNOME Shell, since it's written in Javascript, and that allows such "monkey patching". For something like libmutter which is a C library, you need to expose API that makes it possible to achieve what you're intending to do. With that said, making it possible to implement "missing" Wayland protocols outside is still in scope, not only for e.g. Gala, but potentially for future GNOME Shell uses as well, and that potentially needs new libmutter API to make that possible. There has to be users to add such API though.
Not sure what you mean by this, not sure I've uttered much opinions in this space. With that said, "small" projects should arguably use a ready made general purpose compositor, or a compositor library that does the bulk of the work. What path you take to some degree tell you the amount of work you end up having to do, or how much control you have. For example by using wlroots you have a lot of control, but you also have to put the compositor together yourself, which is still not trivial, even if a lot of of the building blocks are there for you to put together, for better or worse. In contrast, with libmutter you're expected to write the shell, where libmutter tries to stay out of any "UI" decisions. As it is, libmutter does have some somewhat opinionated window management style, but in general, the direction taken is to try to more and more allow staying out of that, allowing the "shell" to have more control. The other thing to take into account is that libmutter, when used for a "DE" (or rather, a multi tasking graphical environment, no matter if its a phone, desktop, ...), is that it expects some other components to be there to "complete" it, e.g. a coupled portal backend, gnome-settings-daemon for power management, gnome-control-center for poking at the monitor configuration API, and so on. In other words, there are different "levels" of how much a compositor library does for you. There are more options than wlroots and libmutter (libweston, smithay, Mir, ...), and what is "right" for you, you'll have to decide for yourself, despite what people tell you is "right". |
Layer shell should be implemented outside of libmutter, with libmutter providing API to make it possible. It's a poor fit for OSK though, eventually a OSK protocol should hopefully be constructed, that doesn't allow hacks like using layer shell.
GNOME Shell has this kind of functionality, so it should be possible to implement that outside of libmutter already. https://wayland.app/protocols/kde-appmenu: For the global menu (or the more general implementation: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/52).
This one is also something that could be added to libmutter itself, and currently has there is a libmutter user that would make use of it. |
|
And what about |
|
xdg-decoration hooks up synchronized complex drawing tied to surface state; it's out of scope for mutter for various reasons, one being that Wayland primarily assumes clients provide a complete graphical state. I'd rather avoid yet another CSD vs SSD discussion. Manipulating how windows are drawn can already be done (e.g. one of the alt-tab modes GNOME Shell supports draws a solid color frame around the selected window), but to hook up something like xdg-decoration, one need to manipulate the "window geometry" etc. If it can be done externally in a way that doesn't reintroduce the mess that this brings with it on X11, then perhaps it can be done, but only experiments will say if it will. |
It's not about one verses the other, but rather that Cinnamon expects SSDs. Their applications are designed for server side decorations, and so there needs to be a way to handle that. This is also the case for most of the other Linux desktops that may consider using Mutter as its compositor. That's why it's important to determine whether it can be supported in Mutter despite GNOME not using it. |
|
Whether it's critical Mint's own applications to not draw decorations (which they do just fine of course, it's GTK after all), I'll leave for Mint developers to determine; this bug seems to be about Chromium based apps etc. Whether it's possible to do it externally can only be answered if someone tries. |
|
Thanks @jadahl. Your opinion on the missing protocols is critical, so that the Mint developers would have a context which to make their decisions. I hope they find a way for Cinnamon to continue alive in Wayland. |
That must be taken with a grain of salt, not everyone in GNOME is aligned with the idea of give to much power to all types of clients: |
If you take the context and the rest of the discussion into account, you'll see that it was about not just forwarding the X11 |
|
@jadahl all this is my opinion, of course. Cinnamon was born as an extension of GNOME and couldn't continue being one, just because Mint devs did not have control of many things they need to modify the shell. Those limitations have mainly been the responsibility of a single person: The maintainer of the shell. Is really not a single and punctual opinion. It is already a position sustained over time very similar to the one GTK developers have unfortunately. It's my opinion, of course. I think that you have a different opinion, also i think that the current maintainer of gjs have a different opinion. I knows that you do personally promote the inclusion. |
|
I don't really know the history of Mint and GNOME, but I'd recommend opening issues to discuss how to make something specific possible from a libmutter user point of view in an issue, if that is something you eventually want to consider. |
|
For those interested, I have opened up a discussion post to talk about wlroots in cinnamon: https://github.com/orgs/linuxmint/discussions/268 CC: @mtwebster |
|
As Muffin is a fork of Mutter, another possibility is just only add a plugin service to Muffin after the fork and then implement the Wayland plugins using that service and outside the original Mutter code. In that way, the change required by the Mutter code should be few (only the necessary to add the plugin capability) while this will allow to add any other implementation from outside using the plugin services and making a hijack of the original code. Of course, this technique is highly prone to breaks due to changes in Mutter's internal code, but since Mint has control of when it wants to update Muffin, it wouldn't really be such a critical point. |
|
Some other relevant previous discussions to take on account: |
Distribution
Linux Mint 21.3
Package version
6.0.1
Graphics hardware in use
No response
Frequency
Always
Bug description
Muffin, and in the process Cinnamon, on Wayland appears to lack the XDG-DECORATION protocol extension, likely as a result of your upstream, Mutter, refusing to implement it currently.
This, in the process, leads to programs being forced to render their own fallback decorations at all times when in the Wayland version of Cinnamon, with the sole exception of XWayland applications.
This, additionally, causes programs to restrict some of their options, such as all Chromium-based browsers disabling the option to use system titlebars since they don't exist without the aforementioned protocol extension.
Steps to reproduce
Just open any non-XWayland application expecting to be able to provide server-side decorations and enjoy client-side decorations instead of native ones.
Expected behavior
If XDG-DECORATION is present in the compositor, applications will be able to use native decorations drawn by Cinnamon itself, just like it has always been on X11 Cinnamon.
Additional information
https://wayland.app/protocols/xdg-decoration-unstable-v1
The text was updated successfully, but these errors were encountered: