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

[klapaucius]

It's true only for some part of game, for example configuration, login window or something like editor should has consistent.

Still don't get this anger. But as I said, in this I'm a user more than a dev. Personally the only thing that I don't like about Mutter is that if it crashes, not often but it might, all Gnome crashes, while in the past I could just restart Metacity.

[Khrundel]

So what you are saying is:
- CSD-styled applications still guarantee they implement a button with the "always on top" functionality if I requested it? -> impact on functionality

I like this feature, as I like any feature you want to name. But SSD is not a solution. All you need for this is one wayland extension (or new version for old one) which will solve this same way as maximization button can be handled, or move/resize functionality. Just by sending a message as a reaction on user action. Right button click on CSD header bar may open DE's own context menu which will allow to do anything, always on top, always on active virtual desktop, save window size and position, switch from overlapping to tiling mode, maximise on several monitors, you name it.

- the buttons for maximize / minimize / close are guaranteed to be in this order and on the right side of the window? -> impact on user's workflow
- and are on the left side if I specified it? Guaranteed? By all applications? -> same
- and even then no "oh, I'm such a special snowflake" application draws their MacOS-buttons instead to be cute? -> impact on visual coherency, which is important for efficient work

Why should any sane person care about this? There are several CSD apps out there right now. There always were. Winamp was one of a first and was loved for its contempt for native toolkit. If "user workflow" would be a thing we should've seen people complaining about existing CSD apps, like Steam or vscode or browsers right now. It is always hard to be a pioneer. If nobody cares about "broken workflow" right now, when only couple of CSD apps exist, why would this can become worse when all apps will use CSD and nobody will expect "same buttons placement"?

So face it. There is no single reasonable argument for SSD. Only fear of losing something you have and not even sure you need it. Funniest thing is that SSD was never intended goal, it is just consequence of awful X11 design with decorator as separate process.

VirtualBox has an option to have the windows of Windows-Cient-VMs float between your native Linux windows. They look completely alien: different borsers, diffeent colors different fonts and everything. I mean, yeah, it works, but is this the desired standard? And then you not only have two design sets but one for every application/toolkit...

Well, at least they don't look like alien, crippled by SSD. What is suggested alternative? Sticking to Qt/GTK forever because your distro maintainers supplied theme only for 2 these popular toolkits? Not being able to use anything else like java's SWT or .NET whatever without pain in eyes?
Not being able to get decent dark theme support because DE doesn't know if this exact window supports dark theme and able to recognise that dark theme was selected?
Look for example to GNOME with default theming. Gnome terminal is white over black (usual for terminals) and it themed by adwaita dark, has black client area, dark gray header with light text on it. Gnome editor is black over white, as usual for simple text editors, has white client area, lightgray header with dark text on it. Window control buttons with same size and same color as another buttons on headers and same as within windows or as context menues. You may focus on this window, maybe maximise it and you will see same tone image, without senseless contrast. If you prefer white terminals you can switch theme within terminal's options dialog and you will get adwaita light decorartions, like gnome editor has. That is the perfect solution and it is possible because of CSD. If nobody messes with theme these window will look same even when launched from another DE, maybe even from some selfmade DS which supports basic protocols only.

[dragon321]

Even if I actually liked Gnome, I would probably run away as fast as I can from such a brainwashed crowd. Maybe braindead actually. Scares the bejesus out of me. Did I miss a zombie apocalypse?

What a nice way for expressing opinion - considering yourself as superior for some reason and calling other side "braindead".

[Mez']

What a nice way for expressing opinion - considering yourself as superior for some reason and calling other side "braindead".

Actually, it's because others think their opinions is superior and don't accept criticism of any kind that I used that word. It's basically the opposite of what you write. My opinion is just my opinion, not superior to anyone, I stress that every 2 sentences.

[oiaohm]

- CSD-styled applications still guarantee they implement a button with the "always on top" functionality if I requested it? -> impact on functionality
- the buttons for maximize / minimize / close are guaranteed to be in this order and on the right side of the window? -> impact on user's workflow
- and are on the left side if I specified it? Guaranteed? By all applications? -> same
- and even then no "oh, I'm such a special snowflake" application draws their MacOS-buttons instead to be cute? -> impact on visual coherency, which is important for efficient work

CSD styled does not guarantee buttons. This is true. But the reality is Windows is CSD by toolkit. Gnome/KDE under X11 are SSD/CSD hybrids so they don't guarantee the buttons.

VirtualBox has an option to have the windows of Windows-Cient-VMs float between your native Linux windows. They look completely alien: different borsers, diffeent colors different fonts and everything. I mean, yeah, it works, but is this the desired standard? And then you not only have two design sets but one for every application/toolkit...

This of having a unique theme per toolkit can be desired. Having different theming based on the security level of the application can also be desired . A fully secure design desktop has some very different requirements. Qubes what is Linux using virtual machines to split applications with Linux users at times will force intentionally different themes per application for security reasons.

i'm not saying there shouldn't be CSD, it just shouldn't be the norm.
Any application that is using it's own design, it's own UI paradigmns and strays away from the unified look of SSD should have a really good reason to do so, to disrupt the user's choices and workflows.
Surely there are such applications (I can't remember one now, though) and they should be able to do their CSD-stuff, but the default should be coherency, which is best achieved (one central authority to do this, low re-implementing-overhead for the applications) with SSD.
libdecoration could help here but I think of it as a bandaid to bridge the different opinions on this.

Really the problem with window appearance not matching up is way bigger than libdecoration and windows decorations. xdg portal has at long last giving means for common dialogs for items like file open and save.

Problem here there are two camps with valid reasons that directly conflit with each other.
1) The camp you are in who wants unified appearance.
2) The other camp who don't want unified appearance.

And inside those 2 camps there is another two camps using CSD and SSD to generate unified or not unified appearance. So there are 4 groups here who can all make valid reasons why they are doing it the way the are and all of them have cases where they can be overly stubborn with their point of view.

[getaceres]

Yes and no. The drivers under Linux and Windows send the data down cables with different timing with Intel. Capacitive issue in cable is timing sensitive. Think of this of hitting like the harmonic frequency of a glass and having it shatter expect in this case you hit key frequency of the cable you get poor data transmission though the cable.

Many people make the presume like you that the cable is fine when it works with windows and not linux that Linux has to be the problem not the cable. You also run in the case where people think the cable is fine when it works with Linux but not Windows again that its not the cable. The problem with these minor defective cable is you change monitors reuse that cable you now have a different frequency of data going down that cable it now have failures.

When its a 60Hz monitor in a particular mode and Linux/Windows will sometimes give you that and other times not. There is a handshaking issue that normally traces to cable problem. Every time you reboot you re run the hand shake so roll the dice if you get luck or not.

Sorry your arguement that its not the cable is based on a very big miss presume and not understand that defective cables can have a harmonic frequency to their defect that data transfer times down the cable effect if the fault displays it self or not. Windows and Linux have different data transfer timing patterns with intel so the result is a defective cable will work with Windows and not Linux or the reverse. The common symptom is under windows xor Linux ( yes I mean xor as in only one shows ) that the HZ of the monitor that is being detected every boot is not stable/predictable as in sometimes you will have 30HZ other times you will have 60HZ a stable quality cable every boot you get the same HZ from the handshake where a unstable cable as a cable with a issue you have this randomness.

I have displayport cables that under windows do 120 Hz at 1080p perfectly fine but completely screw up under Linux with random working HZ values and I have the reverse where I have cables that give 120Hz 1080p under Linux and are complete random Hz guess per boot with Windows. Yes I call all those cables defective. I have another cables that windows/Linux/mac work. I have some fun ones with HDMI that work perfectly with Windows/Linux but attempt to use them with Playstation 4 you are totally screwed its the same capacitative defect that only causes major problems with transfers based on the timing of the transfer operations.

So yes you are kind of right that the problem with video out is party because of Linux but you are also most likely wrong because that straight over looking the mechanical problem that causes it.

This is a very common incorrect presume you get that if something works with Windows or Linux that the bit of hardware cannot be defective when it has a problem with a different OS.

Yes if a person make a arguement that a bit of hardware works with Linux then it does not work with Windows for some reason that windows is defective can be just as wrong.

I had a motherboard for years I used that had a defective realtek audio on board worked perfectly with Linux yet with windows you would get no sound out at all. Yes it was serous-ally defective there was a complete part that had got broken off the motherboard that Linux kernel driver was not detecting as missing but windows driver was. This is when I first learned you cannot make the presume that something working under Linux that it was defective. Few years latter I came across another motherboard that the reverse was true. These were very important lessons you have not had yet and maybe this cable will be the part that teaches it to you.

I didn't know about this problems. So basically it's a lottery with cables that can show issues at random times depending on the OS and monitor.

I use this monitor with this mini-pc but also with a MacBook Pro that I use at work. Up until now I've been using the mini-displayPort to DisplayPort cable that came with the PC and an adapter from USB-C to Mini-DP for the Mac. But I have to plug and unplug the cable every time I change from one to another so given that the monitor supports 4K60Hz with HDMI 2.0 and DisplayPort I decided to order a USB-C to HDMI 2.0 cable for the Mac.

Yesterday I tested it and I was going to return it because the Mac (that always worked at 60Hz before with the USB-C to Mini-DP adapter) started at 30Hz. I rebooted and then it worked at 60Hz with the USB-C to HDMI cable so I guess that cable is defective too. Might be the monitor also?

Anyway, since you seem to have faced this issue in the past, do you know any high quality mini-displayPort to DisplayPort and usb-c to HDMI 2.0 cables that I can use for this configuration?

[oiaohm]

I didn't know about this problems. So basically it's a lottery with cables that can show issues at random times depending on the OS and monitor.

I use this monitor with this mini-pc but also with a MacBook Pro that I use at work. Up until now I've been using the mini-displayPort to DisplayPort cable that came with the PC and an adapter from USB-C to Mini-DP for the Mac. But I have to plug and unplug the cable every time I change from one to another so given that the monitor supports 4K60Hz with HDMI 2.0 and DisplayPort I decided to order a USB-C to HDMI 2.0 cable for the Mac.

Yesterday I tested it and I was going to return it because the Mac (that always worked at 60Hz before with the USB-C to Mini-DP adapter) started at 30Hz. I rebooted and then it worked at 60Hz with the USB-C to HDMI cable so I guess that cable is defective too. Might be the monitor also?

Anyway, since you seem to have faced this issue in the past, do you know any high quality mini-displayPort to DisplayPort and usb-c to HDMI 2.0 cables that I can use for this configuration?

The bad news I have it hardware loto. The more parts you have between monitor and computer the higher the risk of winning the loto of this problem. Worse is some cables/adaptors come out the box work perfect on day one and after a month or more of usage start playing up this way.

When you have cable playing up this way bad rendering performance can also be a direct side effect and this is bad rendering that can appear on Windows, Linux and Mac OS depending on how bad the cable is for that solution.

I have had one case where it was the monitor but I I have had 300 cases where its just the cable/adaptor being screwed. The cable is the most likely part screwed.

There is another thing that happens generally with this form cable fault/adapter. At first windows/Linux/mac os alone displays the problem but over time as you use the cable the problem in the cable progressively gets worse until no OS works. Unstable HZ choose by a OS is sign of hell to come. So that display port cable may have just degenerate far enough to fail with Mac OS now. If it degenerating the cable in time will fail with windows as well.

Hardware bugs like this make it really easy to blame a OS/solution for a problem that the OS/solution is not really the problem at all other than being the unlucky party to kick toe on and display the fault.

[verude]

There always were. Winamp was one of a first and was loved for its contempt for native toolkit.

Winamp was loved for its customization, users could make their own themes and there was a huge selection of themes, hardly comparable with CSD in the linux world.

Regarding steam, yeah I really don't like the client, and wish that steam would provide an api to facilitate thrid party clients for it, I don't use vscode, and have a patched firefox which provides a normal menu bar. With this setup I have globalmenu working as well as plasma-hud working, on the other hand, even though there's nothing stopping CSD programs from exporting a menu through dbus, it doesn't seem to be done often, which makes globalmenu and and plasma-hud non functional for said programs.

[Khrundel]

Winamp was loved for its customization, users could make their own themes and there was a huge selection of themes, hardly comparable with CSD in the linux world.

Yes, but winamp 2.x (version was loved) has very limited customization support. Themes were allowed to change appearance of buttons, and they also could define window region, ie punch some holes in winamp main window. They couldn't change buttons size or place them somewhere else, this was done by winamp 3, which wasn't popular. Even Gnome, officialy lacking theming support, has more theming options.
More important for this topic is that no skin or option of winamp could restore native windows 9x look and feel. According to SSD proponents, at the time of coherent and beautiful windows 98 gradiented headers, users should have hated winamp. Instead they loved it, winamp started a fashion for skinnable interface. Now that time has gone. Forget about linux for a minute, even more controlled UI like on windows can't guarantee same look and feel everywhere, mostly because of web and css. So why bother? Are same borders around windows with differen buttons worth dying for?

Regarding steam, yeah I really don't like the client, and wish that steam would provide an api to facilitate thrid party clients for it, I don't use vscode, and have a patched firefox which provides a normal menu bar. With this setup I have globalmenu working as well as plasma-hud working, on the other hand, even though there's nothing stopping CSD programs from exporting a menu through dbus, it doesn't seem to be done often, which makes globalmenu and and plasma-hud non functional for said programs.

Well, as you can see, all these ugly hacks like global menu will never work as intended. That is the other reason not to go that way.

[Khrundel]

Well, I wasn't talking about CSD/SSD (except for screen ratios). I was replying to the "old world and broken X11 paradigm" in general.

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

That's just a viewpoint from hardcore vanilla gnome users, a minority.

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.

Most others have a different idea (either what you call the old world or a different new world). But it's the kind of minority that thinks it has all the rights to impose everything to a majority, because they got it all figured out for everyone....

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.

Also, progress is a very relative term. In my experience, a lot of the supposed self-proclaimed progress ended up in huge regressions.

I've used term "progress" not in meaning of something right or good, but something which inevitably will come. 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.