A proposal to switch Fedora Workstation's desktop [LWN.net]

A proposal to switch Fedora Workstation's desktop

Posted May 8, 2024 0:41 UTC (Wed) by atai (subscriber, #10977)
In reply to: A proposal to switch Fedora Workstation's desktop by numgmt
Parent article: A proposal to switch Fedora Workstation's desktop

>At the same time, I can see the value in defaulting to Plasma.

This is doing something at someone else's expense.

Do not do to others what you don't want others doing to you.

to post comments

A proposal to switch Fedora Workstation's desktop

Posted May 8, 2024 0:49 UTC (Wed) by numgmt (guest, #167446) [Link] (17 responses)

In the same way I think Wayland has the potential to be a better experience than X11, I think Plasma has the potential to be a better experience than GNOME (largely driven by its Wayland story). Switching to it now would shorten the gap.

Personally, I could use either, and I'd actually like to see Plasma be the default in more distributions. Once it matches its release cycle with distributions like Ubuntu and Fedora, that will be one more reason.

A proposal to switch Fedora Workstation's desktop

Posted May 8, 2024 1:09 UTC (Wed) by intelfx (subscriber, #130118) [Link] (16 responses)

> I think Plasma has the potential to be a better experience than GNOME (largely driven by its Wayland story)

> Plasma is a more mature choice for Wayland right now

Is it? I can't see how would that be.

A proposal to switch Fedora Workstation's desktop

Posted May 8, 2024 1:32 UTC (Wed) by numgmt (guest, #167446) [Link] (15 responses)

Have you tried Plasma 6? I was surprised coming from GNOME. The initial Fedora change proposal mentions a few specific protocols if you're interested.

Plasma has been far more willing to work with the wider community (wlroots, Smithay, Weston, application developers) on protocols. Here's a good example: https://gitlab.freedesktop.org/wayland/wayland-protocols/...

It's not necessarily a knock on GNOME, because they want to make sure the protocol is perfect before implementing it (or see no reason for it to exist at all), but it does mean protocols take quite a big longer to develop. This is only an issue because of the push to abandon X. Or they implement something completely different, like CSD instead of SSD and make application developer's lives difficult if they live outside of the GNOME/GTK ecosystem.

This isn't related to Wayland, but Plasma lets you set the permissions of Flatpak applications inside the System Settings application.

I actually like GNOME more, mind you! It changed my workflow significantly. I would have continued using it if it were possible to use Krita on GNOME, but sadly it isn't, so I had to switch to Plasma. Maybe part of this is just that Plasma seems to have more people working on it, but they've made amazing strides with Wayland.

A proposal to switch Fedora Workstation's desktop

Posted May 8, 2024 2:45 UTC (Wed) by adam820 (subscriber, #101353) [Link] (2 responses)

> I would have continued using it if it were possible to use Krita on GNOME, but sadly it isn't, so I had to switch to Plasma.

What? I use Krita on GNOME on Wayland all the time.

A proposal to switch Fedora Workstation's desktop

Posted May 8, 2024 2:54 UTC (Wed) by numgmt (guest, #167446) [Link] (1 responses)

Ah, I made it sound like there was an issue with it not starting at all. That's not the case.

The issue is with GNOME's multi-monitor handling. I have a 4K display scaled to 200%, and then a graphics tablet (with a screen) that I also want scaled to 200%, but if I do that, I can't fullscreen Krita anymore. I also can't shrink it down to the degree that the entire window fits on my graphics tablet. If I remember correctly, it either wasn't possible for me to chose 100% for the graphics tablet (I had to choose 100% for both monitors), or it was and the Krita window *would* fit, but all of the tools were tiny so it was unusable.

This was about half a year ago.

Anyway, it's also broken on Plasma's X session in the same way, but Plasma's Wayland session was the only thing that worked for me. The multi-monitor handling is great in that respect. I tried three different distributions with GNOME & KDE, FWIW.

On the other hand, Plasma's multi-monitor handling is an absolute pain in terms of handling workspaces, which at least GNOME gets right.

A proposal to switch Fedora Workstation's desktop

Posted May 10, 2024 7:58 UTC (Fri) by daenzer (subscriber, #7050) [Link]

> Anyway, it's also broken on Plasma's X session in the same way, but Plasma's Wayland session was the only thing that worked for me.

It sounds like Krita is using Qt's X backend in GNOME, try running it with the environment variable QT_QPA_PLATFORM=wayland .

A proposal to switch Fedora Workstation's desktop

Posted May 10, 2024 7:48 UTC (Fri) by daenzer (subscriber, #7050) [Link] (11 responses)

> Plasma has been far more willing to work with the wider community (wlroots, Smithay, Weston, application developers) on protocols.

GNOME & Plasma developers are involved to similar degrees in discussions on the most important protocols.

> It's not necessarily a knock on GNOME, because they want to make sure the protocol is perfect before implementing it (or see no reason for it to exist at all), but it does mean protocols take quite a big longer to develop.

It's not really fair to blame "protocols take quite a big longer to develop" on GNOME alone. Even if GNOME devs were the only ones raising issues in protocol discussions (which isn't the case), issues which are only discovered after a protocol has landed are far more painful for everyone.

> This is only an issue because of the push to abandon X.

Xorg upstream development was abandoned years ago, no push was needed for that.

> Or they implement something completely different, like CSD instead of SSD and make application developer's lives difficult if they live outside of the GNOME/GTK ecosystem.

The core Wayland protocol has always been CSD only. SSD is an optional extension not supported by all compositors.

The reality is that every general-purpose Wayland client has to support CSD.

> This isn't related to Wayland, but Plasma lets you set the permissions of Flatpak applications inside the System Settings application.

So does gnome-control-center's Apps panel.

A proposal to switch Fedora Workstation's desktop

Posted May 13, 2024 6:01 UTC (Mon) by immibis (subscriber, #105511) [Link] (2 responses)

Everything in Wayland is an extension. *Putting a window on the screen* is an extension to the core Wayland protocol. Without any extensions, you can stream pixels to the compositor, but you can't tell the compositor what you want it to do with the pixels.

(Which is pretty weird, IMO. Where X11 has a window-centric model, Wayland has a pixel-stream-centric model.)

A proposal to switch Fedora Workstation's desktop

Posted May 13, 2024 10:07 UTC (Mon) by daenzer (subscriber, #7050) [Link] (1 responses)

I suspect the reason for leaving that out of the core protocol was that there can be special-purpose Wayland compositors which don't support "normal" windows.

However, some kind of shell protocol for creating "normal" windows is obviously required for any application which uses "normal" windows. A compositor which doesn't support any such protocol can legitimately be considered unusable for general-purpose applications.

That's different from SSD, which isn't strictly required for any kind of application.

A proposal to switch Fedora Workstation's desktop

Posted May 16, 2024 22:19 UTC (Thu) by immibis (subscriber, #105511) [Link]

Every protocol is an agreement among parties which makes tradeoffs for the sake of consistency and interoperability. A sensible window system protocol involves operations like "create window" and "set window title". Because of this, Wayland is not a sensible window system protocol.

Some cases always sit outside of the protocol design goals and have to be bodged in. For example, there may be a server which intends to display only one window, but runs the multi-window protocol anyway because that's what the client is using because the client normally runs on multi-window systems. In this case the first "create window" request can set "the" window, and "set window title" can be ignored because there is no title bar. Alternatively, "the" window might be selected based on its title. This is the server's implementation choice. Most of the windows on my desktop don't have title bars because I use a tiling WM which doesn't show title bars; "set window size" is also ignored in many cases. These are also my server's implementation choices to deviate from the specification.

However the tail cannot wag the dog. Excluding "create window" because "what if the server only supports one window?" and excluding "set window title" because "what if it's a tiling WM?" are very silly and create more friction for everyone.

A proposal to switch Fedora Workstation's desktop

Posted May 14, 2024 18:03 UTC (Tue) by Conan_Kudo (subscriber, #103240) [Link] (7 responses)

>> Or they implement something completely different, like CSD instead of SSD and make application developer's lives difficult if they live outside of the GNOME/GTK ecosystem.
> The core Wayland protocol has always been CSD only. SSD is an optional extension not supported by all compositors.
> The reality is that every general-purpose Wayland client has to support CSD.

The Wayland "core protocols" (for some definition of core protocols that includes the extensions "necessary" for a desktop) do not specify decorations at all. You can't really infer whether that means CSDs or SSDs based on that alone. What you can infer is that window decorations is another extension. And indeed, that's what xdg-decoration does.

It's a very annoying misnomer to say that Wayland is "CSD-only" or prefers CSDs, when in reality, Wayland doesn't even support a desktop in the core protocol at all.

A proposal to switch Fedora Workstation's desktop

Posted May 15, 2024 7:55 UTC (Wed) by daenzer (subscriber, #7050) [Link] (6 responses)

> The Wayland "core protocols" [...] do not specify decorations at all. You can't really infer whether that means CSDs or SSDs based on that alone.

It means only CSD is possible (with some limitations, if the compositor doesn't know where the decorations & drop shadows are).

> What you can infer is that window decorations is another extension.

Then we agree that Wayland originally supported only CSD.

> And indeed, that's what xdg-decoration does.

From the top of https://wayland.app/protocols/xdg-decoration-unstable-v1:

"This interface allows a compositor to announce support for server-side decorations.

[...]

A client can use this protocol to request being decorated by a supporting compositor.

If compositor and client do not negotiate the use of a server-side decoration using this protocol, clients continue to self-decorate as they see fit."

That's quite clear: CSD is the default, the compositor may optionally support SSD. A general-purpose Wayland client has to support CSD.

It's revisionism trying to blame GNOME for CSD in Wayland, when it was there from the very beginning, long before GNOME supported Wayland.

A proposal to switch Fedora Workstation's desktop

Posted May 15, 2024 11:23 UTC (Wed) by Conan_Kudo (subscriber, #103240) [Link] (4 responses)

I think it's fair to say that GNOME is the only desktop that reinforces this expectation, as all other desktops and even most independent Wayland window managers expect or force server-side decorations (regardless of the xdg-decoration protocol extension).

However, I do think it is revisionist to say Wayland forces CSDs when the core protocol forces nothing. If applications do nothing, there's nothing, and "Wayland" is fine with that. And there are applications that do that. There's an implication that you need CSDs for window decorations, but it is not explicitly stated in the core stuff at all. The xdg-decoration protocol definition is really the first explicit mention of one way or another.

A proposal to switch Fedora Workstation's desktop

Posted May 16, 2024 8:09 UTC (Thu) by daenzer (subscriber, #7050) [Link] (2 responses)

> all other desktops and even most independent Wayland window managers expect or force server-side decorations (regardless of the xdg-decoration protocol extension).

Per the parent posts, a Wayland compositor can't force SSD: The client may ignore the xdg-decoration protocol, in which case only CSD is possible.

> If applications do nothing, there's nothing, and "Wayland" is fine with that.

"Nothing" is really CSD: Since there's no SSD, the client is responsible for drawing decorations as needed.

A proposal to switch Fedora Workstation's desktop

Posted May 16, 2024 10:32 UTC (Thu) by Conan_Kudo (subscriber, #103240) [Link]

A Wayland compositor can do whatever it likes. And tiling window managers have generally had some kind of SSD to support their workflows.

A proposal to switch Fedora Workstation's desktop

Posted May 16, 2024 22:45 UTC (Thu) by immibis (subscriber, #105511) [Link]

> Per the parent posts, a Wayland compositor can't force SSD: The client may ignore the xdg-decoration protocol, in which case only CSD is possible.

Not true. The compositor could simply render decorations around every window. Especially if it doesn't advertise the xdg-decoration protocol, which means that it makes no promises about decorations one way or the other.

A proposal to switch Fedora Workstation's desktop

Posted May 17, 2024 11:51 UTC (Fri) by Wol (subscriber, #4433) [Link]

> However, I do think it is revisionist to say Wayland forces CSDs when the core protocol forces nothing. If applications do nothing, there's nothing, and "Wayland" is fine with that. And there are applications that do that. There's an implication that you need CSDs for window decorations, but it is not explicitly stated in the core stuff at all. The xdg-decoration protocol definition is really the first explicit mention of one way or another.

Sounds like Nikon cameras when they went digital. The old film cameras were all "AF in the camera". The cheap new cameras were "AF in the lens".

ALL Nikon guaranteed was "the physical mount is compatible. The electronic connectors won't fry your kit".

Stick an old lens on your new camera, and despite both being AF-compatible, you had no AF. I had to buy a top end amateur camera to get my old AF lenses to AF. That sounds like Wayland to me - bear in mind it is a PROTOCOL, it cannot do ANYTHING itself. If the *implementation* of Wayland (client or server) don't implement something, you don't get it. So if both your client and your server expect *the*other*side* to implement decorations, bingo! No decorations! Nothing to do with Wayland!

Cheers,
Wol

A proposal to switch Fedora Workstation's desktop

Posted May 16, 2024 22:39 UTC (Thu) by immibis (subscriber, #105511) [Link]

As I already said a day and a half before you, *everything* in Wayland is an extension. *Putting a window on the screen* is an extension. The fact that SSD is an extension has absolutely no relevance to whether it's a requirement or not. Every other display system in existence has SSD, because it is the sane choice for a toolkit-agnostic window server, and GNOME is the *only* Wayland stakeholder which doesn't want it to be mandatory, because they want to force people to use their toolkit alongside their window server.

It's very important, so let me repeat it again: **EVERYTHING in Wayland is an extension.** Without extensions, you can do nothing. Conan_Kudo made a good point that the core protocol doesn't specify decorations at all, which means neither CSD nor SSD are specified. One might reasonably guess that there will be no decorations at all, which means if you render your own decorations, there will be one set of decorations, which will be the ones you render. But that's not actually specified by the protocol. As it happens, things did evolve that way, which is the so-called "CSD default". But that isn't specified by the protocol. Decorations are undefined behaviour.

If the application renders its own set and then gets two sets because the server also rendered them, the server isn't wrong to do that -- *unless* the server claimed to advertise the xdg-decoration protocol, in which CSD is the default, and the client noticed the protocol and did not request SSD because it wanted CSD, and the server did SSD anyway.