This release brings a grid view in the file chooser, improved settings panels forDevice Security, Accessibility, etc, and refined quick settings in the shell. The Softwareand Files apps have seen improvements, and a whole slew of new apps has joinedthe GNOME Circle. The release notes have all the details. The grid view in the file chooser alone would be worth a major version bump, considering how long it took them to implement it.
After nearly six months of development, the GNOME 43 “Guadalajara” desktop is finally here and introduces a few interesting changes, the most prominent one being the Quick Settings menu that can be accessed from the system top bar, very similar to those you probably saw on Android devices or the latest Windows 11 and macOS systems. Nautilus has also been improved considerably, and Epiphany (GNOME Web) now supports WebExtensions, instantly making the browser a lot more useful. The move to GTK4 continues, too, of course, and there’s countless other improvements.
Variable rate refresh (VRR / FreeSync / Adaptive-Sync) support for GNOME’s Mutter compositor is closer to being merged. The native back-end support for VRR that has been in development the past two years is no longer considered a work-in-progress and it’s believed there are no longer any blocking issues that would prevent this code from landing. Every modern compositor should support this.
As part of the design process for what ended up becoming GNOME 40 the design team worked on a number of experimental concepts, a few of which were aimed at better support for tablets and other smaller devices. Ever since then, some of us have been thinking about what it would take to fully port GNOME Shell to a phone form factor. Say about GNOME what you want, but this looks kind of amazing. Of course, the issue will always be application support – or lack thereof – but as a UI for a true Linux smartphone, this is totally workable.
After six months of development, GNOME 42 is here and it’s packed with some cool new features and enhancements for fans of the GNOME desktop environment. The biggest change in this major release is the porting of almost all default GNOME apps to the latest GTK4 toolkit and the libadwaita 1.0 library for a more modern look and faster performance. This is a very odd release. There’s tons of great, valuable new features and improvements in here, and if it wasn’t for libadwaita, I’d be quite excited to upgrade my various GNOME installations the moment Fedora 36 becomes available. A new screenshot UI, updates to all the core applications, a ton of performance improvements, and a lot more. Sadly, libadwaita is incredibly problematic. Virtually all of GNOME’s core applications now use libadwaita, which means they cannot be themed. They will all use the default refreshed Adwaita theme, and no matter what Gtk+ theme you install, you can’t change that. What makes matters worse, is that the various applications not yet ported over to libadwaita, such as Nautilus, will still use the old, pre-libadwaita Adwaita theme, meaning that even on a default installation without any custom themes, you’re going to have to deal with a very inconsistent user interface. Even when all of GNOME’s core applications have been ported over to libadwaita, your desktop will still make use of countless regular Gtk+ applications that will look out of place compared to all the GNOME applications. The GNOME team of course hopes that every Gtk+ developer will adopt libadwaita – Cinnamon, Xfce, Cosmic, MATE be damned – but the odds of that happening are slim. Libadwaita knowingly and willingly makes using GNOME a far less pleasurable experience, and the fallout of this boneheaded move will take years to recover from – if at all.
Libadwaita 1.0 has been released, just at the end of the year. Libadwaita is a GTK 4 library implementing the GNOME HIG, complementing GTK. For GTK 3 this role has increasingly been played by Libhandy, and so Libadwaita is a direct Libhandy successor. Libadwaita is quite controversial, as aside from dark mode and a (promised) colour API, applications that use Libadwaita cannot be themed. It’s all the result of developers being unhappy us pesky users get to decide what our computers look like, so they decided to prevent users from theming their systems at all. GNOME’s own applications will surely transition to it, and it remains to be seen if the wider Gtk developer community will opt for it as well. Libadwaita hjas already led to two major departures from GNOME, and other Gtk-based desktop environments, such as Cinnamon and Mate, may follow.
If you’ve been paying attention to recent chatter in the GNOME and surrounding communities, you may have noticed there’s a lot of disgruntled developers within certain communities that rely on parts of the GNOME stack, such as Pop!_OS and Budgie. I’ve been trying to follow most of these discussions and have been itching to write about it, but with the discussions still ongoing and my own lack of knowledge on the intricacies of the interplay between distribution maintainers, desktop environment developers, application programmers, and GNOME itself, I figured I should stay away from it until someone with more knowledge stepped in. Well, thanks to Joshua Strobl, experience lead of Solus and one of the main developers of Budgie, I now have a great in-depth story to link to. I urge you to read the whole article, but here’s Strobl’s conclusions: 1. GTK4 has not met our expectations since its release in December of 2020, nor have we been satisfied with its state as of the writing of this post. 2. Current plans by GNOME for changes to how theming works is viewed as regressive for desktop Linux, developers, and user choice. 3. We do not believe that GNOME is treating its community, from individual users to entire operating systems, in a manner that is equitable and respectful of their choice on how they want to curate their own experience. 4. Budgie 11 will not be written in GTK4. 5. For Budgie Edition: we will be working on replacing software developed by GNOME with that of alternative software developers as well as “in-house” solutions. These will not necessarily be under the GetSolus organization nor will they be associated with Budgie. Adopting Budgie going forward (at least until 11, when we have our own control center) does not and will not require using our own apps. This has even remained true even for Budgie Desktop View, we support alternatives like Desktop Folder as alternative “desktop” implementations in Budgie. 6. GNOME Edition will be demoted to a non-curated edition and moved to a lesser position on our Downloads page in a future release of Solus. There are various problems non-GNOME GTK developers are running into, but as a user, my biggest problem is GNOME’s adoption of libadwaita. GNOME is going to ship a library, libadwaita, that when used by an application, will force it to use the default light Adwaita theme, with no option to change it to dark mode or a different theme. The end result is that if you use GNOME, you’re going to start seeing applications – both from GNOME itself as well as from third parties – that do not respect your choice of GTK theme, and instead always default to light Adwaita. But of course, this problem extends beyond GNOME itself, as other popular GTK desktops, such as MATE, Cinnamon, and Budgie, also make use of both GTK applications, as well as components and applications from GNOME. On top of that, countless popular distributions, such as Linux Mint, Ubuntu, and Pop!_OS, all use custom themes. Their desktops will be severely broken since GNOME and GTK applications will no longer use their custom themes. As a result, Solus and Budgie will start transitioning to using EFL instead of GTK for various components, which is a pretty big shift. As far as I know, other distributions, such as Ubuntu, Linux Mint, and Pop!_OS, have not made any plans yet as to how to handle this new reality, but I would assume they, too, will start to replace any offending applications and components, or hack GTK altogether as a workaround. This is a shitty situation, and the GNOME developers are causing a lot of bad blood and rifts here that really could have been avoided. Theming and customisation are a core aspect of the Linux desktop, and breaking it like this is going to make a lot of non-GNOME developers as well as users very, very unhappy.
We are proud to announce the release of GNOME 40. This release is the first to follow our new versioning scheme. It brings a new design for the Activities overview and improved support for input with Compose sequences and keyboard shortcuts, among many other things. Improvements to core GNOME applications include a redesigned Weather application, information popups in Maps, better tabs in Web, and many more. A very big release, and I can’t wait to try it out and see how many extensions I need this time to make GNOME usable. Snark aside, I greatly respect the GNOME team for having a vision about how they want GNOME to work, feel, and look, and sticking to it. It may not be to everyone’s liking because of it, but there’s more than enough alternatives in the Linux world – this isn’t the take-it-or-leave-it world of macOS and Windows, after all – that finding something you do like shouldn’t be too hard.
If you’ve been following this blog, you’ll know that a team has been working on updated designs for the Activities Overview. (Previous posts on this topic covered our initial motivations and design goals, as well as the results from some early exploratory research that we conducted.) This initiative has been the subject of significant activity over recent months, and we’re now at a point where we can share more details about what we’ve been doing. My feelings on GNOME are very double. On the one hand, I love the fact that the GNOME team really seems to have a solid plan of what it wants, and it sticks to this plan to a fault. On the other hand, I just do not like this plan. It doesn’t mesh with what I want from a desktop computing experience. The fact I have to mess around with shaky extensions through a web interface to make GNOME halfway usable to me just isn’t a great user experience. But that’s fine – this isn’t the Windows or macOS world where we have to take it or leave it. We have tons of other options to choose from (Cinnamon for me), exactly so the developers and users of GNOME can build what they want.
If you’re looking for a fancy new way to launch your favourite apps in GNOME Shell the awesomely innovative GNOME extension featured below should appeal! It’s called Fly-Pie and despite being at an early stage in its development (i.e. expect bugs, missing features, possible death, etc) it’s already looking pretty functional as this YouTube video ably demonstrates. Neat. Not sure if it’s for me – the mouse movements seem slow, and not as fast as simply using something like uLauncher – but at least it’s a little bit different.
GNOME OS has traditionally been a virtual machine image for testing, but with the work done by Codethink and other GNOME developers it’s becoming possible to run GNOME OS on bare metal hardware. Additionally, thanks to the likes of Flatpak and OSTree, it’s becoming more like a working Linux distribution in terms of package availability. GNOME OS is part of the project’s continual testing investment and can be booted on real systems with UEFI via systemd-boot, systemd is leveraged throughout, Flatpak is available for a broad application base, Wayland and XWayland are utilized, the latest Mesa drivers are present, and OSTree provides atomic updates. GNOME OS seems similar to KDE Neon, and I think it’s a great idea. It allows GNOME developers and users to easily test the latest and great versions of their software, without being dependent on distributions.
The lock screen work that we landed in 3.36 was the outcome of a long-running programme of UX work, which we first put together at the GNOME UX hackfest in London, back in 2017. There are still some outstanding pieces of the login/unlock experience that need to be filled in, and this is something that we hope to work on over the coming development cycle. However, we are also turning our attention to other aspects of the shell, which we have wanted to update for some time. In the rest of this post, I’ll describe some of the areas that we’re hoping to improve, before going on to talk about how we’re going to do it. An overview of what to expect from upcoming GNOME releases.
A work-in-progress patch series was posted over the weekend for adding variable refresh rate support into Mutter for X.Org and Wayland. This includes checking for VRR support from connected monitors using the DRM properties, support for activating VRR, and the ability to toggle the VRR support via a DBus API. The VRR support isn’t advertised to Wayland clients at the moment for the lack of an upstream Wayland protocol around VRR. I can’t wait for Mutter and Kwin to adopt and integrate support for variable refresh rates, so seeing these first patches is good news.
We are pleased to announce the official release of GNOME 3.36: “Gresik”. Version 3.36 contains six months of work by the GNOME community and includes many improvements, performance enhancements, and new features. Highlights from this release include visual refreshes for a number of applications and interfaces, particularly noteworthy being the login and unlock interfaces. The release notes provide a more detailed overview of the changes.
The latest version of GNOME 3 has been released today. Version 3.34 contains six months of work by the GNOME community and includes many improvements, performance improvements and new features. Highlights from this release include visual refreshes for a number of applications, including the desktop itself. The background selection settings also received a redesign, making it easier to select custom backgrounds. They have a video highlighting the changes too.
We are developers and designers making apps for the GNOME platform. We take pride in our craft and work hard to make sure our applications are a great experience for people. Unfortunately, all our efforts designing, developing, and testing our apps are made futile by theming in many cases. This is insanity – even if they claim it only applies to distribution makers. Their argument basically comes down to certain themes making certain applications look bad, and that theming removes branding from applications. First, theming making applications look bad is either an issue with the theme that needs to be fixed or an issue with Gtk+/GNOME being bad at theming, and second, your branding is irrelevant on my computer, or on my distribution. I use KDE, and one of the main reasons I do so is to ensure I can make my desktop and its applications look exactly the way I want them to look.
GNOME 3.32 is the latest release of the most popular Linux Desktop Environment (Interface+Apps) that is used by Ubuntu, Fedora and many other Linux distributions as their default experience (with or without changes). GNOME 3.32 packs itself with new niceties such as a refreshed theme and icon set, many much-needed performance fixes, updated apps, etc. However, GNOME continues to have key areas that stick out like a sore thumb in terms of intuitiveness or convenience. I have laid them down below with links to bug reports, please treat my feedback as constructive criticism of a project that I respect, but find confusing. As a former heavy user of GNOME 2.x, I find GNOME 3 wholly unpleasant – unlike its predecessor, it seems to want to force a certain way of working on me that I just can’t wrap my head around. Add to that the numerous problems – many of which are highlighted in this article – and I just don’t see myself ever returning to the world of GNOME any time soon. KDE all the way for me.
But I'll be honest: GNOME is huge and kind of bloated, and it's hard to disable various unwanted components. GNOME Shell is amazing, but a lot of the other components of GNOME are simply unwanted. This is what turns a lot of power users away from GNOME, which I think is a shame given all of the other amazing things about GNOME. While you won't find these instructions in the GNOME manuals, if you know what you're doing modern GNOME releases make it very easy to lobotomize a lot of the unneeded and unwanted features.
Daniel Aleksandersen writes:
Jonas Ã…dahl from Red Hat has been busy adding new D-Bus APIs to libmutter. Mutter is the GNOME window manager and Wayland compositor. The two new APIs, org.gnome.Mutter.RemoteDesktop and org.gnome.Mutter.ScreenCast, expose a PipeWire stream containing the contents of the system's screens. The new APIs can create full-screen streams, or streams for individual windows. Only the former has been implemented.
These new APIs finally allows for services such as RDP and VNC servers and screen recording under Wayland. Once again, Mr. Ã…hdahl delivers! He has also created GNOME Remote Desktop, a new user-level systemd service daemon that is built on the new RemoteDesktop API in libmutter, plus VNC support from libvncserver. The new service can be used to connect up a remote VNC client to your local screen’s session. GNOME Remote Desktop appears to be a drop-in replacement for Vino server.
GNOME has been without its own Remote Desktop option since the switch to Wayland, and this work fills that gap.
GNOME 3.16 brings a brand new notification system and updated calendar design, which helps you to easily keep track of what’s happened, and includes useful information like world times and event reminders. Other features include overlaid scrollbars, updated visuals, improved content views in Files, and a redesigned image viewer.
Major additions have also been made to the GNOME developer experience: GTK+ support for OpenGL now allows GTK+ apps to support 3D natively, a new GLib reference counting feature will help with debugging, and GTK+ Inspector has also had a major update.
Also released: GNOME Builder, an IDE for GNOME.