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

[stalkerg]

None of the above is something I care about at all as a user. If you want to develop your application using some specific technology, you should make sure that technology supports drawing borders if you like your application to have borders. I understand that the developers of said technology may have opinions about these kind of things, but that is pretty far down the stack from users.

That technology just not exists for a lot of types of software at least yet (games, CADs and etc).
As developer I shouldn't spend time to support weird GNOME decision, much easier say please use KDE/Sway or push on Gnome to implement SSD .

[oiaohm]

That technology just not exists for a lot of types of software at least yet (games, CADs and etc).
As developer I shouldn't spend time to support weird GNOME decision, much easier say please use KDE/Sway or push on Gnome to implement SSD .

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.

[Anvil]

i don't think F34 will be exciting as Michael claims, Fedora35 will be the exciting one with DNF5 being the default an a fully complete gnome40 .

[getaceres]

Sounds to me like you are talking about several different issues here.

4K 30Hz - You didn't mention what cable you use, but according to Intel's product page, your iGPU only supports 4K 60Hz on DisplayPort. Make sure you have a decent DisplayPort cable, there are many that claim to support 4K but don't support 60Hz. Then it should allow you to choose 60Hz. If that doesn't work, open a bug report against the Intel graphics driver.

It's connected by DisplayPort and it is NOT a problem with the cable. With the same cable, the same PC and the same monitor, it runs perfectly at 4K 60Hz in Windows. When it doesn't in Linux then the problem is with Linux not with the cable.

Fractional scaling - I agree with you that fractional scaling implementation is less than ideal. I also use a similar display as yourself, and what I do is I set the font scaling factor in Gnome Tweaks to 1.15 (you might want to try 1.2 or 1.25 or even more). This makes it convenient for my eyes. I know this is not exactly what you asked for, but I thought I'd share in case it is helpful.

Note that browsers have their own setting for this, eg. in Firefox you set layout.css.devPixelsPerPx and that will do the trick. (On my system this is also 1.15)
So, browsers implement their own fractional scaling, you don't need to worry about system-wide fractional scaling for them.

Fractional scaling is much more than bigger fonts. It helps to have it but it's not useful if the widgets and icons continue to be tiny. However, as a workaround it might help but it's not a solution to the problem

Poor browser performance - There can be several different reasons behind this, perhaps your browser doesn't use HW graphics acceleration. It is also possible that the 30Hz display makes it look sluggish. I suggest to ask for help in the browser's community, eg. open a bug report.

As I said I don't always get 30Hz, just sometimes for unknown reasons. I only get 60Hz consistently in Windows.

Anyway, I tested a Fedora 34 live ISO and it looks promising:

- It booted directly at 4K 60Hz.
- Performance seems to be much better at native resolution and with fractional scaling enabled.
- Performance in Firefox and Chrome seems much better with scrolling

It's no at Windows level yet but it's a step in the right direction. I hope that with Fedora 35 or 36 we get similar peformance for 4K and fractional scaling as in Windows as today 1080p performance is on par and sometimes even better.

[Khrundel]

So much intolerance. We're back to the dictatorship of the one-track thinking, very much in line with the Gnome mindset.

Being self-proclaimed freedom fighter you are spending too much efforts to convince people that we should recreate a system prone to oligopoly. SSDs are to blame for linux qt+gtk world. SSD is a first step to "consistent look and feel", goal and it requires a second one: same looking theme for app's toolkit. If toolkit doesn't support DE's theme, SSD will make window look even worse. This creates unfair advantage to DE's native toolkit and most time, closest competitor, Qt or GTK. For any other toolkits, even if they support theming, nobody will bother to create themes, so developers have to choose one of these two just to be sure their program won't look like crippled alien. This prevents new toolkits and new DE's from conquering share.
On the other hand CSD windows always look excelent, nobody cares when some window doesn't have "native" borders. So, instead of reinventing ugly x11 architecture, sane people have chosen right way: CSD. Unfortunately, several miserly developers who don't want to throw away a little code trying hard to slow down progress. They will lose eventualy, but will bring much harm before.

[reba]

Being self-proclaimed freedom fighter you are spending too much efforts to convince people that we should recreate a system prone to oligopoly. SSDs are to blame for linux qt+gtk world. SSD is a first step to "consistent look and feel", goal and it requires a second one: same looking theme for app's toolkit. If toolkit doesn't support DE's theme, SSD will make window look even worse. This creates unfair advantage to DE's native toolkit and most time, closest competitor, Qt or GTK. For any other toolkits, even if they support theming, nobody will bother to create themes, so developers have to choose one of these two just to be sure their program won't look like crippled alien. This prevents new toolkits and new DE's from conquering share.
On the other hand CSD windows always look excelent, nobody cares when some window doesn't have "native" borders. So, instead of reinventing ugly x11 architecture, sane people have chosen right way: CSD. Unfortunately, several miserly developers who don't want to throw away a little code trying hard to slow down progress. They will lose eventualy, but will bring much harm before.

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
- 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

Can you?

Can you not? Then name a way this can be done without saying "SSD", please.

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...

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.

[C8292]

Fedora is and continues to be an excellent distribution.

I appreciate their work a lot. And they keep to push the perfect balance between rolling and fixed releases.

[Mez']

Being self-proclaimed freedom fighter you are spending too much efforts to convince people that we should recreate a system prone to oligopoly. SSDs are to blame for linux qt+gtk world. SSD is a first step to "consistent look and feel", goal and it requires a second one: same looking theme for app's toolkit. If toolkit doesn't support DE's theme, SSD will make window look even worse. This creates unfair advantage to DE's native toolkit and most time, closest competitor, Qt or GTK. For any other toolkits, even if they support theming, nobody will bother to create themes, so developers have to choose one of these two just to be sure their program won't look like crippled alien. This prevents new toolkits and new DE's from conquering share.
On the other hand CSD windows always look excelent, nobody cares when some window doesn't have "native" borders. So, instead of reinventing ugly x11 architecture, sane people have chosen right way: CSD. Unfortunately, several miserly developers who don't want to throw away a little code trying hard to slow down progress. They will lose eventualy, but will bring much harm before.

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. Self-proclaimed auto conviction. That's just a viewpoint from hardcore vanilla gnome users, a minority. 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.... Like emotional ecologists (Vs long-term thinking ecologists), feminists (Vs egalitarians), black lives matter (Vs all lives matter). And all of these have in common that it ends up in dictatorships (of thoughts), an ill will to reverse the situation instead of leveling it and people with different approaches are burned at the stake for thinking differently, even if it is in a parallel/identical direction. Which is what is happening here too.

Also, progress is a very relative term. In my experience, a lot of the supposed self-proclaimed progress ended up in huge regressions. That's also why I call the progressists the regressists, half of what they do is inconsistent and end up leading back a century or the middle age (or for ecologists to pollute... more). Doesn't mean they're wrong at a high level, just the way they handle it sucks in my books.

Also, I'm not a freedom fighter (whatever the hell that is), I'm just giving my opinion, and I hate assumptions with no ground (the old ways). A lot of the new ways end up being scraped. 14 years ago, the compiz cube was all the rage, the new world of then. What's left of it? Let's keep a bit of distance, hindsight and open mind when talking about new worlds instead of just hammering it down with a strong wishful conviction. And let's be respectful of people with different ideas of what the world (old or just as new) could be.

[oiaohm]

It's connected by DisplayPort and it is NOT a problem with the cable. With the same cable, the same PC and the same monitor, it runs perfectly at 4K 60Hz in Windows. When it doesn't in Linux then the problem is with Linux not with the cable.

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.

[Mez']

Mez' Your arm chair comments haven’t discussed or solved the dominant problem. Economics.

Those with enough pooled resources (GNOME contributors) already decided against your vision.

You would lick a toxic waste dump if Gnome devs told you it's full of proteins, so don't act surprised if I'm not bothering with the opinion of a yes man glad to be force-fed. There's no nuances, no dark clouds, not a single ounce of challenging what is force-fed to you, and no other acceptable views in your little fantasy world. I'll gladly engage in a constructive conversation (possibly ending up having an impact on my opinion) if it isn't biased by assumptions or a self-proclaimed single version of the truth, which means you're out. Even if you keep tagging me.
Just to remind you.