GNOME 48 Released (9to5linux.com) 32
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
HDR support (Score:2)
Re:HDR support (Score:4, 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: (Score:3)
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, 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:2)
> 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: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: (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:2)
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)
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
Sigh, Everything But Desktop Work? (Score:3)
Re:Sigh, Everything But Desktop Work? (Score:5, 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)
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:3)
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 :)
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.
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
I read that as "dynamic tripe buffering" (Score:2)