Fedora Workstation 34 Should Be Very Exciting With GNOME 40, PipeWire Default

[Sonadow]

No word on whether Plasma Wayland as default is go or no go for Fedora 34?

I've been using Plasma Wayland entirely since the 5.21 beta and its been entirely usable, with only a few papercuts

https://fedoraproject.org/wiki/Changes/WaylandByDefaultForPlasma

[ermo]

So much intolerance. We're back to the dictatorship of the one-track thinking, very much in line with the Gnome mindset.
They and you have decided unilaterally that it's the old world or a broken paradigm. That's very random. Could you explain on what grounds? Or more probably it's just an opinion in your mind you're trying to give more strength than it actually has... Of course, you have no clue except it's how you see it, so it must be true.

I'm actually not a fan of GNOME or GNOME Shell.

My comments were made on the basis that the Wayland protocol was ostensibly created (by long-time Xorg maintainers) to fix the shortcomings of X11 in their view. Some of these people contribute to GNOME Shell and seem to have made an engineering decision early on that takes the stance that XYZ needs to be done a different way than it used to be done for presumably sound and valid reasons (otherwise, why bother?!). These people then pour years into writing code around that outlook while the rest of the world continues writing code against the older Xorg way of doing things because that's what they've always done and it is where they can reach the largest target audience.

I then read through the entire thread related to the referenced bug and tried to understand what the GNOME Shell people were saying and why. And the strongly held opinion of the GNOME Shell people that they aren't willing to fundamentally rewrite and/or throw away their investment into better underpinnings is what stood out to me.

If you want to cast me as someone who's here to agree with everything the GNOME developers do, go right ahead.

As it happens, you'd be wrong and you conveniently appear to have ignored me making the argument that something that actually solves the problem that the rest of the ecosystem is facing is sorely needed, even if it won't be at the protocol level for reasons that you're better off asking the relevant Wayland and GNOME Shell developers about directly.

[Mez']

Well, if X11 paradigm isn't broken you and like-minded people can fork xorg and continue to support it. Many people will appreciate.

I'm really not worried about that.
Ubuntu 20.04 will be supported for 4 more years.
There are not many plans yet for Mate, Cinnamon, Budgie, XFCE, LXDE regarding wayland and their timeframe is probably on the long run. They will take care of small fixes in the meantime and X will be alright for a long time.
Enough time to iron out all the issues of wayland, which is unusable for me at the moment. So I'll switch when it's ready. An opinion that has been expressed by a crapton of users for similar reasons, yet all different.
Also, I hope to have gotten rid of Gnome by then, which will bring me to a newer world with a more advanced paradigm (I can do that as well).

[Minority or not, doesn't matter. The point of democracy isn't finding truth, but sharing responsibility (for elites) and emergency brake (for citizens). That is why politicians try hard to lure more unwilling to vote people into voting, they want controlled uneducated votes to dilute opposition while they will use uncontested power in their corrupt interests.
Gnome developers don't listen to your opinion because they've taken full responsibility. Your emergency brake is libertarian one: vote with your legs.

Actually, Gnome devs rarely take responsibility, it's always someone else's fault, or on 3rd parties through extensions to take responsibility for the many trivial features they don't want to offer as options, even if massively requested. Same with wayland, when an app works perfectly with Xorg but doesn't with wayland, it's always the app dev fault or Mesa or the driver, never with Mutter. Although it should have been transparent, it never was. If the wayland compositor makes it so that the app doesn't work anymore on some level, for me the responsibility is not at app level. Sorry, not sorry. Doesn't mean it doesn't require changes on the longer run for cleaner support, but still should be transparent on the short run.

I've used term "progress" not in meaning of something right or good, but something which inevitably will come.

OK for your use of "progress", it's just hijacked randomly these days for some ecologists/feminists/LGB-friendly/supposedly-anti-racists-but-actually-more-racists (the extremist within these categories) purposes with subjectivity of meaning, so it becomes a sensitive term.

Arguing about masses doesn't change your own intellectual responsibility for consequences of ideas you are defending. SSD creates additional costs and additional obstacles for new toolkits and wayland servers. Imagine some rust fanboy who wants to recreate some app with Rust (that is what Rust fanboys always do) and can't because to look good in his beloved KDE he should use Qt, but this framework is tightly coupled with C++ and Rust alternatives (assuming they exist) don't support KDE theming. So you're supporting GNOME/KDE duopoly.

CSD will win. GNOME devs won't budge, they've created too many fancy CSD headerbars. And some minor DSes will not support xdg-decorations too, because they have no resources to create something better than basic decorations. And there is no way for server and app to determine which of them can draw better decorations. Right now many developers waiting for this conflict to resolve one way or another, they can wait with X11 for some time more. But this won't long forever. Wayland sessions becoming default with more and more distos. Looks like xwayland on nvidia will not get GLX support, to have GPU-assisted rendering apps will have to switch to wayland. Some of loud CSD opponents (mpv) have already implemented CSD. In couple of years CSD support will mature and developers will start to think, why we're supporting two code paths? Why we limit ourselves with UI layout and wasting screen space because of ugly SSD? More and more apps will become CSD-only, after some time KDE will not be able to rely on SSD presence with their own fancy functionality. There will be to few SSD headers to contain additional buttons. After some time KDE will remove SSD support, as they already removed "window in a tab" feature. Being stubborn morons they just prolonged confusion for 2 or 3 years.

CSDs will win in Gnome, sure. And as a corollary on impacted GTK DEs, to some extent.

SSDs are consistent. CSDs are not. We've strived for consistency for many years and CSDs are breaking it entirely now. Shiba has posted a couple of times how 4 different apps have 4 different look and feels with wayland because of CSDs.
Also, if compared side by side although Nautilus (CSD) top bar looks better than Nemo's (SSD), the latter looks clearly more professional, more refined, because it's not stripped down to an amateurish feel for the rest of the window through CSDs). Of course the fact that Nautilus lacks basic features doesn't help in making it a serious file manager to use as a daily driver... But that doesn't have to do with CSDs, it's just become an app with a nice top bar and an empty shell for which you go to Nemo whenever you want to actually do stuff.
Note here that I didn't argue that CSDs (the top bar, not the whole window) look better. They're just usually less functional, and give the rest of the window a bland and amateurish empty look.

Also, SSDs allow a proper use of the Unite extension on Gnome or Pixel-saver-applet on Budgie, which on 16:9 or 16:10 screens is 1. a vertical win and avoids the CSD blatant waste of space 2. easier to grab (for moving or unmaximizing) by throwing your cursor at the top and clicking instantaneously rather than take time and precision to target a specific area not close to the screen border. Also, some content of CSDs is in the way to grab the window and move or unmaximize it, which is a nightmare on some Gnome apps, and on browsers with the tab bar on top and full of tabs (with no titlebars). Fortunately, Firefox is just a click away to convenience.
On Gnome, it's a nightmare to move and unmaximize CSD windows on the 1st screen (which is the most used especially when mobile). Secondary screen has no top panel (if no extension for it) so it's similar to Unite/Pixel Saver and a bit more convenient except for browsers). In dual display mode, I barely use the first one (with the panel) with CSD windows, it's just too horrible to use and there's not enough content left to be displayed vertically anyway.
If the new world is less convenient, why should we support difficulty of use? I don't get it. So yes, it makes for frustrated people for valid reasons. You can't bypass that entirely and expect half the people to be happy with something that doesn't suit them (contrary to the happy other half). There's just no way. The only way is to make it possible by offering options to offer both worlds to some manageable degree even if one is just 2nd class (maintenance included). Less backlash, once again. Up to 80% happy people (100% is impossible), leaving a much less vocal unhappy 20%.
I've been using Linux for 15 years (with no Windows installed ever since), but if the future is (cleaner but) more limiting with wayland + difficult of use and vertical waste of space with CSDs, I'll have to look elsewhere. That's another thing for which Unity had the paradigm better implemented in my view and more suited to my workflow and use. I can't wait for Canonical to break even and have the financial means to invest back in the desktop. They were definitely pulling their design from users (their satisfaction in mind), instead of pushing it from developers to users like Gnome (sitting on their satisfaction). I could identify with that, but not with the current direction of Gnome+wayland, it just doesn't work for me in most ways.
Solus devs also discussed about creating their own compositor for Budgie 11 instead of the rigid Mutter, there could be a brighter future for me over there if they get rid of the Gnome dead weights and pursue their approach much more open to feedback and options, with the users' interests in mind, not just developers' interest.

[Mez']

I'm actually not a fan of GNOME or GNOME Shell.

My comments were made on the basis that the Wayland protocol was ostensibly created (by long-time Xorg maintainers) to fix the shortcomings of X11 in their view. Some of these people contribute to GNOME Shell and seem to have made an engineering decision early on that takes the stance that XYZ needs to be done a different way than it used to be done for presumably sound and valid reasons (otherwise, why bother?!). These people then pour years into writing code around that outlook while the rest of the world continues writing code against the older Xorg way of doing things because that's what they've always done and it is where they can reach the largest target audience.

I then read through the entire thread related to the referenced bug and tried to understand what the GNOME Shell people were saying and why. And the strongly held opinion of the GNOME Shell people that they aren't willing to fundamentally rewrite and/or throw away their investment into better underpinnings is what stood out to me.

As it happens, you'd be wrong and you conveniently appear to have ignored me making the argument that something that actually solves the problem that the rest of the ecosystem is facing is sorely needed, even if it won't be at the protocol level for reasons that you're better off asking the relevant Wayland and GNOME Shell developers about directly.

I perfectly understand the need for wayland.
I don't question the need itself, but once again the way it is designed and implemented. I just don't like the developer-centric approach Red Hat always takes instead of a user-centric approach. It's their money so it has to serve their financial purposes, sure. But then don't expect users to be happy when they have not been taken into consideration at any moment.

This also leads to suboptimal workflows for users designed by devs with irrelevant to users workflows, some important stuff left out and a crapload of use cases impacted negatively with people left unable to do stuff the way they prefer to do it. And it doesn't have anything to do with resistance to change. Changing naturally is easy to come to, by trying, liking and moving on. Being forced to lose efficient workflows is a different story, as it leads to frustration and is of course more roar-prone.

In addition, the limited set of dev-centric workflows break from all sides whenever they face a broader base of users. As we will soon discover with Ubuntu 21.04 (mainstream) compared to Fedora (dev-oriented) that has a supposedly working wayland (in Mutter) with its similar profiles user base. I might laugh a bit when wayland (through the compositors) explodes from all sides because it can't face the coming flood of diverse use cases. Not because I'm against it, just because all the abovementioned dev-oriented profiles claiming it's ready will discover how much it's not and how their design will lead to "now I can't do that anymore".
I wouldn't be surprised if Ubuntu backpedals to X at the last minute though, when more testing shows the obvious.

If you want to cast me as someone who's here to agree with everything the GNOME developers do, go right ahead.

Don't take it too personally. You might just have been the one too many that refers to "new world" and "paradigm". Although the problem for some can be the paradigm, for many others it's the implementation of it and that biased shortcut of a confusion is starting to get me annoyed. Because it serves the wishful thinking of some that wayland, Gnome Shell, CSDs are some kind of new world* when it's just a parallel world with not enough hindsight to know if it will last or in its current form.
I'm getting tired of people extrapolating their opinions as an immutable truth or their assumptions as facts.
That's also why I'm advocating so hard for options because I like users to feel confortable the way they want to, and be empowered in chosing that way, not being forced to. I don't think a limited set of people can decide for an entire base AND make many happy at the same time. Sure, there needs to be design decisions otherwise you never settle on the way forward, and I'm fine with that! But options for obvious and recurring patterns of response towards some features should be a virtuous goal. Or when the feedback is heavily negative, it might be time to stop being stubborn and burying your hand in the sand and accept the criticism can be relevant, then act on it to tackle how to solve these (especially through a limited set of options first).

* understand "single version of the truth that needs to be imposed to everyone as the only acceptable vision"

[oiaohm]

There are not many plans yet for Mate, Cinnamon, Budgie, XFCE, LXDE regarding wayland and their timeframe is probably on the long run. They will take care of small fixes in the meantime and X will be alright for a long time.

The reality is X11 on bare metal from the x.org server is not going to be alright for very much longer on bare metal without a new lead maintainer. There is a problem coming HDR monitors bare metal X11 server currently does not support HDR monitors properly and will not unless someone takes over maintainer ship. XWayland will support HDR.

The X11 DE and WM that are not making plans to move to Wayland are also not making plans to take over X11 x.org on bare metal development are going to find themselves in a progressively reducing pool of users.

The end of road is really coming up fast.

Please note Hardware Enablement (HWE) team on Ubuntu 20.04 have already said for hardware support being forced to use Wayland may come. So the 4 years of support on 20.04 Ubuntu may not include X11 on bare metal depending on how things go.

Basically Mez' you have made a lot of presumes. X11 on bare metal is getting really close to having no road(as in no hardware support) so coming completely not usable on new hardware.

The reality is a lot of X11 WM and DE will not make the transition to Wayland in time and will basically have to die if nothing changes. There is no point being a Luddite about this. New technology is coming in displays plus the fact the Linux desktop cannot be a insecure mess any more means there is going to be a transition. The transition is going to be brutal.

[Mez']

The reality is X11 on bare metal from the x.org server is not going to be alright for very much longer on bare metal without a new lead maintainer. There is a problem coming HDR monitors bare metal X11 server currently does not support HDR monitors properly and will not unless someone takes over maintainer ship. XWayland will support HDR.

The X11 DE and WM that are not making plans to move to Wayland are also not making plans to take over X11 x.org on bare metal development are going to find themselves in a progressively reducing pool of users.

The end of road is really coming up fast.

Please note Hardware Enablement (HWE) team on Ubuntu 20.04 have already said for hardware support being forced to use Wayland may come. So the 4 years of support on 20.04 Ubuntu may not include X11 on bare metal depending on how things go.

Basically Mez' you have made a lot of presumes. X11 on bare metal is getting really close to having no road(as in no hardware support) so coming completely not usable on new hardware.

The reality is a lot of X11 WM and DE will not make the transition to Wayland in time and will basically have to die if nothing changes. There is no point being a Luddite about this. New technology is coming in displays plus the fact the Linux desktop cannot be a insecure mess any more means there is going to be a transition. The transition is going to be brutal.

I think you're a bit too optimistic.
Plus I'm not even sure Ubuntu 21.04 will actually go on with wayland. They said they were trying for wayland, they never guaranteed it. As we are nearing release, negative feedback will most certainly start to kick in and I wouldn't be surprised by a last minute rollback.

Regarding HDR, even if X doesn't support it, I've noticed my monitor does active and local dimming itself to some extent for deeper and darker black, and it's good enough for me.
For actual high quality movies, I have the TV anyways with the likes of Netflix offering better HDR support than any ripped movie played on a computer would.

I didn't say someone would take over the entire X maintenance. Just that I believe it will be enough for the next 5 years with just ad hoc fixes, especially since many DEs have barely any plans to switch once again and the pool of users will still be substantial (just Mint has a much bigger user base than Fedora). They won't die and will man up and provide the fixes, like they've always done.

Finally, I'll switch to wayland on Gnome when they decide to provide an "alt + f2 + r" replacement for the 5-6 recurring cases I need to refresh Gnome because it's already unstable after half a day into a session (2-3x the initial RAM, Gnome apps might be randomly not responding, not exhaustively, stuff like these that a refresh solves), and even quite horrible after 3-4 months of uptime.
If I have to log out every time and lose my current workflow, the next log in will likely be in Budgie out of frustration.
I could also mention the very handy xkill for unresponsive apps. Life saver.

I know they won't implement that in Mutter, and that's my point.
Wayland (as in the Mutter compositor at least) is just too limiting for me in its current form while X works very well despite all its design flaws. So I'll stick to it as long as it's realistic to. And hopefully by then Budgie will have dropped Mutter and developed their in-house compositor or Lomiri with Mir will be mature for wayland.
So yeah, I'm not worried, by the time I have to give up (2-3-5 years from now), there might already be another project coming up (in the same way pulseaudio is being replaced by pipewire only 13-14 years later) or better alternatives (to Gnome/Mutter) should have made the leap and maybe even have matured.

[oiaohm]

Regarding HDR, even if X doesn't support it, I've noticed my monitor does active and local dimming itself to some extent for deeper and darker black, and it's good enough for me.

This is you not understanding the HDR problem. We are getting now HDR panel in laptops that required 10bit per channel or they display nothing. These do not at all support bar metal X11. Yes we do expect monitor to appear that don't have 8bit per channel graphics support.

I didn't say someone would take over the entire X maintenance. Just that I believe it will be enough for the next 5 years with just ad hoc fixes, especially since many DEs have barely any plans to switch once again and the pool of users will still be substantial (just Mint has a much bigger user base than Fedora). They won't die and will man up and provide the fixes, like they've always done.

Sorry there is need core work how to support 8bit per channel graphics on 10bit per channel displays that will not take a 8bit per channel signal. Next 5 years ad hoc fixes not going cut it. Some of the reason to cut back to just Xwayland is the amount of workload IBM/Redhat saw coming.

Mint may have a bigger user base but that user base for core part development has been depending on Redhat and other big companies. I am not seeing any sign of them into their pockets to fix this problem.

Something to remember is both Pulseaudio and Pipewire development was Redhat funded.

[stalkerg]

Really this is being stupid with the idea to push Gnome.

https://github.com/Plagman/gamescope

There is absolute no reason why SSD could not be implemented like gamescope here as a proxy Wayland compositor. This is the thing that gets me is if SSD is so wanted why has no one implemented a proxy compositor to provide it on wayland compositors that don't provide it. This is exactly how you have a system tray that is X11 windows manager neutral.

Lot of games do in fact support CSD even when it was not supported at there release because their toolkit was updated being SDL. There is a very short list of applications that don't use one of the major toolkits there is already over 95% application coverage for CSD from the toolkit updates.

https://github.com/wayland-project/weston

Does the reference wayland compositor Weston support Server Side Decorations the answer is no it does not. This is the problem with the idea of push Gnome to implement SSD is that Gnome has implemented what the reference for Wayland has and technically does not have to implement any more.

Gnome does not need to implement SSD in the first place. Your application is meant to check that it works with the reference compositor for broad support between wayland solutions not Gnome or KDE or Sway. The reference is Weston. If you need to push something to support SSD because you want it everywhere its Weston not Gnome.

Remember weston supports running as a Wayland application inside another wayland compositor this is really the first example of a proxy compositor. Weston being a proxy compositor if it supported SSD and the user compositor did not you really could say use it without any major problems.

Big question here were is the reference implementation of SSD on wayland. Please note to reference it would have to be part of the main Wayland project.

SDL support only primitive CSD without any integration. Weston working like this just because CSD simpler and better for an example implementation.
The gamescope maybe a good answer but it's a GNOME task to integrate with gamescope.

[stalkerg]

Why should any sane person care about this?

You just try to say to a Rock music fan that disco only has sense because nobody cares about hard guitar sound. It's not working like this. Also, even in this thread, you can find at least 4 people who care about consistent UI/UX between applications.
I believe, developers making applications for PEOPLE and should care about their opinions, even if it's open-source/free software.

[stalkerg]

My comments were made on the basis that the Wayland protocol was ostensibly created (by long-time Xorg maintainers) to fix the shortcomings of X11 in their view. Some of these people contribute to GNOME Shell and seem to have made an engineering decision early on that takes the stance that XYZ needs to be done a different way than it used to be done for presumably sound and valid reasons (otherwise, why bother?!). These people then pour years into writing code around that outlook while the rest of the world continues writing code against the older Xorg way of doing things because that's what they've always done and it is where they can reach the largest target audience.

It's not true because:
1. KWin started to implement Wayland in a similar time
2. GNOME not only one DE and WM solution for Linux desktop, before deciding XYZ they should find consensus with other teams.

The main issue here, GNOME developers trying to project their decisions to all Linux Desktop but GNOME not alone here!!! Now that KDE/GNOME solution became much better for Wayalnd and users and developers started a migration to it all this issue raised up. As a user and developer, I can say only - WTF!? Why you can't discuss with each other to make a consistent approach?
Anyway, this situation makes pain for users, developers, the KDE team, and even the GNOME team.