GNOME 48 Released (9to5linux.com) 59
prisoninmate writes: GNOME 48 desktop environment has been released after six months of development with major new features that have been expected for more than four years, such as dynamic triple buffering, HDR support, and much more. 9to5Linux reports:
"Highlights of GNOME 48 include dynamic triple buffering to boost the performance on low-end GPUs, such as Intel integrated graphics or Raspberry Pi computers, Wayland color management protocol support, new Adwaita fonts, HDR (High Dynamic Range) support, and a new Wellbeing feature with screen time tracking.
"GNOME 48 also introduces a new GNOME Display Control (gdctl) utility to view the active monitor configuration and set new monitor configuration using command line arguments, implements a11y keyboard monitoring support, adds output luminance settings, and it now centers new windows by default."
"Highlights of GNOME 48 include dynamic triple buffering to boost the performance on low-end GPUs, such as Intel integrated graphics or Raspberry Pi computers, Wayland color management protocol support, new Adwaita fonts, HDR (High Dynamic Range) support, and a new Wellbeing feature with screen time tracking.
"GNOME 48 also introduces a new GNOME Display Control (gdctl) utility to view the active monitor configuration and set new monitor configuration using command line arguments, implements a11y keyboard monitoring support, adds output luminance settings, and it now centers new windows by default."
lack of info!? (Score:2)
No link? No screenshots? Are we expected to google this ourself? /s
Re: (Score:2)
HDR support (Score:2)
Re:HDR support (Score:5, Informative)
What does Gnome need to do to support High Dynamic Range?
Seriously?
What do you think HDR is?
I thought that would be the job of X (or Wayland, if you like crappier rewrites of crappy legacy software).
Only that "crappier rewrite of crappy legacy software" supports it. There is no HDR support in Xorg, and likely never will be.
But now I understand- you don't know what Wayland is, do you?
Wayland isn't an Xorg rewrite.
Wayland is a specification.
Valve added the protocol support for HDR to Wayland, and support in their compositor, now GNOME has added support in their compositor.
Re: (Score:2)
There is no HDR support in Xorg, and likely never will be.
Xorg supports 30 bit colour and has for ages.
But now I understand- you don't know what Wayland is, do you?
It's primarily an excuse to to complain at users an yell "that's out of scope" when something formerly working broke.
Wayland is a specification.
Like X11, but unfortunately in their zeal to rewrite, they didn't learn a lot of the old lessons of the X protocol, Xorg's implementation and you know every single desktop system out there in existence al
Re:HDR support (Score:4, Interesting)
Xorg supports 30 bit colour and has for ages.
10bpc is not HDR.
It's primarily an excuse to to complain at users an yell "that's out of scope" when something formerly working broke.
Like X11, but unfortunately in their zeal to rewrite, they didn't learn a lot of the old lessons of the X protocol, Xorg's implementation and you know every single desktop system out there in existence already.
So, on top of not knowing what HDR is, you also don't know what Wayland (or apparently X11) is.
X11 and Xorg are both specifications, and implementations.
Wayland is literally just the protocol.
The display server is the compositor, and it is not part of Wayland (though there are some relatively featureless reference implementations authors can use for a base)
Re: (Score:2)
10bpc is not HDR.
https://en.wikipedia.org/wiki/... [wikipedia.org]
X11 and Xorg are both specifications, and implementations.
X11 is the protocol. Xorg is an implementation of the protocol. There are others, though none particularly high profile these days.
The display server is the compositor,
Re: (Score:2)
https://en.wikipedia.org/wiki/... [wikipedia.org]
If you had asked how you were wrong in good faith, this'd be so much easier.
I'll repeat myself: 10bpc is not HDR.
I'll ask you a question to help you learn this yourself (though you could have just read the fucking article you linked):
How much visual dynamic range do you think there is in 8 bits with a linear transfer function?
HDR can work with any amount of bits, though the more the better. That includes 8.
X11 is the protocol. Xorg is an implementation of the protocol. There are others, though none particularly high profile these days.
X11 is both the protocol and the implementation.
Ah yes, the Shaggy defense for why stuff doesn't work in Wayland. The compositors are essentially limited by the protocol.
What the fuck are you talking about?
Are you fucki
Re: (Score:2)
SDR is linear, 8 bits.
10 bits linear has bigger dynamic range, so it is high dynamic range. You cannot make Wayland better by angrily attacking people who point out inconvenient facts
Anyway, no X11 is not the implementation, that's not even wrong.X11 describes the whole shebang, which is clients, the protocol, the server and usually the wm, ICCCM and some extra bits to boot.
The X protocol is just that, a protocol. If you disagree, I would offer to mail you my old X protocol reference from O'Reilly, but we b
Re: (Score:2)
10 bits linear has bigger dynamic range, so it is high dynamic range. You cannot make Wayland better by angrily attacking people who point out inconvenient facts
You seem to like calling falsehoods facts.
10 bits do indeed have a larger dynamic range than 8 bits. It is still not high dynamic range, because even 10 bits, linearly encoded, only has a dynamic range of about 10 stops, which is far under the capabilities of human vision.
You are trying to re-define what HDR is. That makes you disingenuous or stupid.
Anyway, no X11 is not the implementation, that's not even wrong.X11 describes the whole shebang, which is clients, the protocol, the server and usually the wm, ICCCM and some extra bits to boot.
X11 is the name of the protocol, and also the reference implementation (X.org)
That's why X11R[fill-in-the-blank] includes the X.org X server.
The term "X11"
Re: (Score:2)
There is so much confused thinking in that I don't even know where to begin, so I shan't.
Re: (Score:2)
You tried to claim that 10bpc is HDR. It is not. It is, in fact, not even close.
HDR can be 8 bits (but why?) or it can be more.
SDR can be 8 bits (also arguably, but why?) or it can be more.
10bpc in X11 is only, and can only, ever be SDR.
Admit that you conflated these two things in your ignorance, and then you can try to handwave away my responses.
You tried to claim that X11 was merely a protocol, when in actuality, the reference distribution of X11 is its implementation- X.or
Re: (Score:2)
https://en.wikipedia.org/wiki/... [wikipedia.org].
10 to 12 bits is considered HDR. This:
> 10bpc in X11 is only, and can only, ever be SDR
is complete bullshit you've invented.
It's also worth mentioning that if 12 bits per pixel were critical, and X11 was still under development instead of having its developers moved to Wayland, it'd be trivially easy to extend it to support that.
> A common example of this misunderstanding is those that claim "Wayland doesn't support network transparency". Sure it doesn't. That's not i
Re: (Score:2)
I'm surrounded by fucking morons.
How is someone with a UID as low as yours so fucking stupid?
Bit depth and dynamic range are only loosely related.
Read:
While SDR uses a bit depth of 8 or 10 bits
HDR uses 10 or 12 bits
Weird... there's an overlap.. I wonder if that means that the dynamic range doesn't equal the bit depth...
All current codified HDR specifications require 10 or 12 bits. That doesn't mean everything with 10 or 12 bits is HDR.
This is elementary fucking reading, Watson.
Extending the dynamic range is about the transfer function, not the bits.
Stand
Re: (Score:2)
I don't think he understands what dynamic range is, i.e. the ratio of the smallest to largest representable intensity and has confused dynamic range with linearity.
He also thinks that ever more frothing rage improves the integrity of his points.
Re: (Score:2, Flamebait)
Xorg supports 30 bit colour and has for ages.
Leaving aside 30bit not being sufficient for HDR standards, X.org doesn't "support" colour management at all. Colour management is up to the application to support and correctly translate to real colours in Linux.
It's primarily an excuse to to complain at users an yell "that's out of scope" when something formerly working broke.
Oh look, someone else who pretends the entire world should bow to their edge case. Do everyone a favour and use your "network transparency" system while leaving the rest of the world out of it. Open Source exists to meet the needs of users with a wide range of packages. If you are so important then
Re: (Score:2)
Leaving aside 30bit not being sufficient for HDR standards
You should, because that's false. 10 bit color is often used for HDR. Is it as good as 12 bit, no. Is it no better than 8 bit, also no. However, you can also do HDR with 8 bit color [wikipedia.org]. What that will get you is a lot of banding... in images where that's a problem. Consequently, the technique is usually used for images where it isn't, like nature photographs.
X.org doesn't "support" colour management at all.
That part is true. GNOME and KDE each have their own color management, the gnome-settings-daemon color plugin and colord-kde respectively. You can also us
Re: (Score:3)
> Colour management is up to the application to support and correctly translate to real colours in Linux
Hearing "Oh X11 doesn't implement this feature I've suddenly decided is vital, it can only be implemented somewhere else" from a Wayland apologist will never not be funny.
X11 doesn't implement a tiny handful of features that can easily be implemented at other layers without too much difficulty: BAD.
Wayland doesn't implement many, many, critical features that can't be implemented at some other layer of
Re: (Score:2)
Leaving aside 30bit not being sufficient for HDR standards
False.
Oh look, someone else who pretends the entire world should bow to their edge case. Do everyone a favour and use your "network transparency" system while leaving the rest of the world out of it.
Ah yes, after the Shaggy defense of "it wasn't me" when Wayland breaks something fails, the next defense it to yell at users about how they are wrong and shouldn't want that feature anyway. And then end up with directly insulting the user.
False. X11 is f
Re: (Score:2)
Re: (Score:2)
Re:HDR support (Score:5, Informative)
HDR uses higher 10-12 bit depths to increase the colour gamut. So I assume Gnome has to detect and set the display manager and monitor into a mode that does it and also provide that info to apps interested in using it.
As for Wayland, no it is not a "rewrite". It is a protocol between an application and a display that allows the application create and render into a surface (using hardware acceleration if available) and tell the display when it is done, as well as receive input in the other direction. Implementations of the respective sides underpin QT, GTK and the display manager. It means sweeping away decades of crud, bottlenecks, security holes, extensions and other bullshit in X and enjoying a fast desktop experience. If you have X11 apps, then Xwayland runs on top of it.
Re: (Score:2)
It means sweeping away decades of crud, bottlenecks, security holes, extensions and other bullshit in X and enjoying a fast desktop experience.
So why isn't it faster?
https://discuss.kde.org/t/wayl... [kde.org]
https://www.phoronix.com/revie... [phoronix.com]
Any improvement is within the margin of error, and X is sometimes faster.
Claiming Wayland offers better performance than X is lying.
Re: (Score:2)
This is a silly argument. Wayland is a protocol. The whitepaper should convince anyone that it cuts down the amount of context switching required for an application and the display manager to composite and show a scene. But it means the things either side that implement the protocol and render surfaces such as the graphics driver, application, widget lib, and display manager must be 100% optimized to capitalize on that experience.
But even the links you provide show it is no worse than X and usually better.
Re: HDR support (Score:2)
My system is way too fast to watch anything render, it's a 5900X with a 4060 Ti 16GB which is pretty middle of the road now but everything is super fast and "fluid". Those links showed exactly what I said, the performance difference is negligible.
Re: (Score:2)
Re: (Score:2)
It means sweeping away decades of crud
Crud? That usually means the drawing code. I mean I get some people are still sore about the code space taken up on their Sun 3/60, but it's 2025 now, that's not a problem anymore.
security holes
X11 has security protocols now and has for quite a long time now. Trouble is no one uses them and if they major desktop developers refuse, that's a problem because no one will enable them just to break gnome.
extensions
You can always spot a Wayland fanboi from this one word alone.
Re: (Score:1)
The majority of X is obsolete. Modern apps are pushing around pre-rendered pixmaps, not using primitives, fonts, damage etc. And X sucks in every way imaginable. Even the people who worked on X have commented extensively about the effort to lock it down, or extend it, or simply to maintain it.
Are you claiming that once the first version of the Wayland protocol was finished it was set in stone and nothing was added ever? No? Then why do you criticise X for adding new APIs?
No I'm not. That's you putting some
Re: (Score:2)
Ah yes this is Wayland fanboiism at it's finest
Insult the user. Make claims. Pretend you didn't make claims. Insult the user again. Them claim that even though things aren't working as well with Wayland, none of that had anything to do with Wayland.
I am not putting words in your mouth, you specifically complained about X having newer API calls. Either you think nothing else should ever get new APIs or you are being very inconsistent and faulting X for something that Wayland adds too.
That's what extensions a
Re: (Score:2)
It's funny you whine about "insults" when you call someone "fanboi" to dismiss what is obvious to anyone paying attention and then throw strawmen around like so much confetti.
I am not putting words in your mouth, you specifically complained about X having newer API calls.
You have serious reading comprehension problems. The issue is not that the protocol can be extended, the issue is that so much of the protocol is obsolete that it's all extensions. Disgusting hack extensions with a bunch of workarounds, all
Re: (Score:2)
The issue is not that the protocol can be extended, the issue is that so much of the protocol is obsolete that it's all extensions
Right... I get it, you really don't like it that you don't like that X didn't stay set in stone in 1987.
Disgusting hack extensions
Uh huh.
No thicko, I said "As for Wayland, no it is not a "rewrite".
I know, it's the usual Wayland switcheroo. Wayland solves all the problems. Wait it doesn't well it's just a protocol, that's out of scope! Nothing to do with Wayland! There is a massiv
Re: (Score:2)
There is no "switcheroo" dummy, this is a plain statement of what Wayland is, what unfixable faults X11 had, why it had to be replaced and what changes happened to make that a reality. I honestly don't know why you're so sore about it quite honestly. You clearly didn't watch the video explaining why X11 sucks by a person who actually developed and maintained X11. You clearly know more than they do. Maybe YOU go and maintain your precious windowing system and quit whining that the rest of the Linux world is
Re: (Score:2)
quit whining
Only in Walyand Fanboi world, pointing out facts is "whining". If wayland is as good as you say then surely those facts should not matter and do not need to be shouted down?
Re: (Score:2)
Wide Color Gamut increases the gamut.
Both benefit from (but don't require) 10-12 bits to do their work.
All current HDR codified standards do require 10-12 bits and a WCG.
HDR addresses the fact that with a linear mapping, you're throwing away a lot of bits in differences that you simply cannot see.
For example, the difference in luminosity from 254 to 255, and 1 to 2 in 8-bit linear space.
You have 8 bits of luminosity values, but really, only like 6
Re: (Score:2)
What does Gnome need to do to support High Dynamic Range? I thought that would be the job of X (or Wayland, if you like crappier rewrites of crappy legacy software).
No. In Linux all colour management is the role of the client application. If the Gnome UI wants to display the correct colours it needs to set them appropriately. This includes understanding the protocol requirements (such as higher bit depth for HDR support) as well as what the colour profile is.
Windows is very similar in that regard by the way. It offloads colour management to the applications while providing a rubbish API to tell the application what to expect, and even then it can only tell the applicat
Re: (Score:2)
Sigh, Everything But Desktop Work? (Score:3)
Re:Sigh, Everything But Desktop Work? (Score:4, Interesting)
Gnome 3 and Unity lost me forever with their new paradigms. Client side window decorations, hamburger menu, tabs in title bars.
And maybe it's having to use Windows 11 for work but XFCE works well enough without changing the metaphors for the, um, whims of the few.
That said, I don't own any touchscreen devices not running Android so maybe there's a niche in mobile for freaky.
Re: (Score:2)
Gnome 3 and Unity lost me forever with their new paradigms.
I fought it for a while, but now I'm over it.
There are only a few plugins required to make GNOME3 as functional as GNOME2 was, and frankly some of them are even better than that.
Client side window decorations
Was needed to implement the below.
GNOME was just playing catchup with other popular windowing systems.
tabs in title bars.
I'm with you here. I fucking hate that goddamn new paradigm in UI design. It's fucking everywhere, now.
But one can't argue that it isn't popular.
Even the Plasma guys lament their ideological problem with it, because they think i
Re: (Score:2)
Was needed to implement the below.
In X, the WM could create a subwindow in the title bar for clients to use for widgets, and offer it to the host. Then the WM could do the decorations and the program could if it wished do everything else. This is more or less how the system tray in X works.
Re: (Score:3)
The limitation isn't X- in this case, it's the WM/decorator.
Plasma, for example, doesn't allow DWD on app windows, and neither did GNOME. GNOME has since switched to full CSD now that Gtk supports it.
Re: (Score:2)
Ah nice! You know I had never heard of that, just speculating on the obvious implementation.
Shame really we could have had both server side decorations and programs optionally messing with the title bar, but never mind.
Re: (Score:2)
Gnome 3 and Unity lost me forever with their new paradigms. Client side window decorations, hamburger menu, tabs in title bars.
I just want you and everyone on Slashdot to remember this when they say people should switch from Windows to Linux. Forget people, even Slashdotters are highly resistant to even simple UI changes.
Every system is capable. It's the people who lack capability. Fortunately on Linux you are spoiled for choice.
Re: (Score:2)
Forget people, even Slashdotters...
Re: (Score:2)
Well, yes, I believe the default desktops from Red Hat and Canonical don't make any sense for a Windows-switcher.
That *is* a turn off.
Re:Sigh, Everything But Desktop Work? (Score:4, Informative)
Well, then there are good news for you - try a recent GNOME - there's no "Activities" label in sight at all!
PS: What really works well with GNOME shell is a keyboard. You hit the Windows key, then type term + RET and get a terminal. Or fire + RET and get Firefox. There's visual feedback so you can see what's going to be launched.
Re: (Score:2)
PS: What really works well with GNOME shell is a keyboard. You hit the Windows key, then type term + RET and get a terminal. Or fire + RET and get Firefox. There's visual feedback so you can see what's going to be launched.
We had that a decade ago with gnome-do [wikipedia.org]. Is that supposed to be GNOME's big innovation? You can do the same thing on KDE, XFCE... though to be fair it's actually really irritating on XFCE, because for some reason XFCE does it on key down instead of key up. This is broken by design, because if you hit Win+something you will get whatever that does PLUS the menu will open. KDE gets this right. Finally I found something about XFCE that I don't like :)
Re: (Score:2)
Yeah, one of the great things about Linux is the variety.
I don't think GNOME is very innovative, but it's a pretty clean interface, keyboard launching works well, it even has some simple window tiling behavior built in. The built-in workspaces work pretty well.
I'd say for most people coming from more rigid OSes (Windows or MacOS), it's a nice upgrade and easy to get started with.
If you love one of the previous paradigms, obviously you're not going to be satisfied, but that's the great thing about Linux, the
Re: (Score:2)
Found that there is a solution to my XFCE problem, upgrade libxfce4ui to 4.18.6 or later. (this was fixed in 4.18.5 but a new bug was also created, solved in .6)
Now I have to figure out how to actually do this, I swear making a deb gets more irritating every time I do it
Decreased Stability Without a GPU? (Score:2)
Re: (Score:2)
On my laptop with a dGPU, it works fine.
TFA (Score:3)
TFA: https://release.gnome.org/48/ [gnome.org]
Still prefer old Gnome, use MATE (Score:1)
Reasonably light. Totally function. Lots of customization options. Not bloated with useless crap.
JMHO.
Re: Still prefer old Gnome, use MATE (Score:3)
Mate is affected by gnome's antics, because it uses gtk. I got bitten by it when they switched to gtk3 and lost some functionality because some gnome dev had a sensitive mouse and decided to unilaterally remove the "scroll on tabs to switch them" functionality...
Still spinning its wheels (Score:2)
Re: (Score:2)
More than 20 years after its conception the Gnome desktop has yet to gain any significant traction even with the endorsement of Red Hat.
GNOME supplanted CDE as the standard UNIX desktop. GNOME 2 was also by far the commonest desktop of its day. That's significant traction by definition. It has waned sharply since the introduction of GNOME 3 because of the direction it went in, which as you allude was towards being touch-oriented first and foremost and letting the desktop experience go to hell, in anticipation of Linux taking over mobile devices because it was free of licensing costs.
in the mobile space, which was its ultimate goal, it remains practically nonexistent
We had a mobile GNOME, called GPE [wikipedia.org]. I used it on my iPaq H2
Re: (Score:2)
It has waned sharply since the introduction of GNOME 3 because of the direction it went in
No, it waned sharply because Ubuntu hard-forked GNOME2.99 to create their own in-house Unity desktop. Which they have since abandoned in favor of GNOME 3 + a couple of extensions.
Gnome was, and still is, overwhelmingly the "standard linux desktop" (I'd argue that based on sheer numbers, MacOS is the "standard UNIX desktop" as it is (or was) an actual UNIX..)
in the mobile space, which was its ultimate goal, it remains practically nonexistent
The GNOME folks have gone on the record numerous times stating that mobile (and touch) was *not* a consideration in the GNOME3 design. (To the contrary, it was, and still is, a very keyboard-centric design, which translates *horribly* to touch input)
I read that as "dynamic tripe buffering" (Score:2)
Dynamic Triple Buffering? (Score:2)
My heart sings