Gnome Archive

GNOME OS is switching from OSTree to systemd-sysupdate

I’m pretty sure most of you are familiar with KDE Neon, the distribution KDE maintains to provide easy access to the latest KDE technologies. However, did you know GNOME has something similar, called GNOME OS? It’s been around for a while, but has a far lower profile than KDE Neon does, and it seems they want to change that and put more of a spotlight on GNOME OS. GNOME OS is an immutable distribution using OSTree, the same technology used by the various popular immutable versions from the Fedora family. It seems GNOME OS is working to leave OSTree behind, and move to systemd-sysupdate instead, which has been available since systemd 251, released in May 2022. The developers claim this will bring the following benefits: To complete the move from OSTree to systemd-sysupdate, a few things need to be completed. First, the boot process and root filesystem had to be migrated, which was done last year. Second, sysupdate needs to integrated into GNOME, as for now, you can only use it via the command line. This work is ongoing, and requires a new D-Bus service and polkit integration to allow GNOME Software to manage the update process. Of course, there’s more work that needs to be done to complete this migration, but these are the main tasks. All of this work is part of the project’s goal to make GNOME OS nightlies viable for daily-driving for quality assurance purposes, and I’m sure all this work will also make GNOME OS more attractive to people outside of the developer community. It’s basically GNOME/systemd taken to the extreme, and while that will surely make quite a few people groan, I personally find it great that this will make GNOME OS a more capable choice for everyone. That’s what open source is all about, in the end.

GNOME Foundation in financial trouble

As you may be aware, the GNOME Foundation has operated at a deficit (nonprofit speak for a loss – ie spending more than we’ve been raising each year) for over three years, essentially running the Foundation on reserves from some substantial donations received 4-5 years ago. The Foundation has a reserves policy which specifies a minimum amount of money we have to keep in our accounts. This is so that if there is a significant interruption to our usual income, we can preserve our core operations while we work on new funding sources. We’ve now “hit the buffers” of this reserves policy, meaning the Board can’t approve any more deficit budgets – to keep spending at the same level we must increase our income. ↫ Robert McQueen Learning that the GNOME Foundation can barely scrape by financially makes me irrationally angry. As much as I’ve grown to dislike using GNOME and thus switched all my machines over to KDE, GNOME is still the most popular desktop environment and used extensively by pretty much all the big corporate Linux distributions. How is it possible that this hugely popular and important open source project has to beg individual users for donations like they’re running an independent tech website or something? Where’s all the financial support from Red Hat, IBM, Oracle, Canonical, and so on? If not even an insanely popular project like GNOME can be financially stable, what hope is there for the countless small, unknown open source projects that form the basis of our entire computing world?

Just how much faster are the GNOME 46 terminals?

Over the GNOME 46 cycle, VTE has seen a lot of performance improvements. Christian Hergert mentioned some of them in his blog posts about VTE and about his work in GNOME 46. But how much did the performance actually improve? What should you, the user, expect to feel after installing a fresh Fedora 40 update and launching your favorite terminal? Let’s measure and find out! ↫ Ivan Molodetskikh The short version is that the improvements are definitely noticeable during genera use – for the long version, read the actual article.

Writing GNOME applications with Swift

Swift is well-suited for creating user interfaces thanks to the clean syntax, static typing, and special features making code easier to write. Result builders, combined with Swift’s closure expression syntax, can significantly enhance code readability. Adwaita for Swift leverages these Swift features to provide an intuitive interface for developing applications for the GNOME platform. ↫ The Swift blog It seems the Swift project is actively trying to move beyond being the ‘Apple programming language’.

GNOME 46 released

GNOME 46 has been released, and its packs a ton of new features and improvements. One of the headline improvements is the new global search feature. Files comes with a new global search feature in GNOME 46. The feature is simple: activate it by clicking the new search button, or by using the Ctrl+Shift+F shortcut, then enter your query to search all your configured search locations. Global search is a great way to jump directly into search, without having to think about where the items you want are located. The new feature also leverages GNOME’s existing file search capabilities, including the ability to search the contents of files, and filter by file type and modification date. ↫ GNOME 46 release notes GNOME 46 also brings experimental support for variable refresh rate in Mutter, GNOME’s window manager, the Files application has seen a lot of work to drastically improve performance, the Settings application has been reworked, OneDrive support has been added to online accounts, and much more. Remote login has also been greatly improved. GNOME’s remote desktop experience has been significantly enhanced for version 46, with the introduction of a new dedicated remote login option. This allows remotely connecting to a GNOME system which is not already in use. Connecting in this way means that the system’s display can be configured from the remote side, resulting in a better experience for the remote user. GNOME 46 will make it to your distribution of choice over the coming weeks and months.

GNOME 46 to introduce headless remote logins via GNOME Display Manager

The alpha version of the GNOME 46 desktop environment should be out for public testing any day now for early adopters and enthusiasts who want to get an early taste of the newly implemented features, one of them begin support for headless remote logins via GDM (GNOME Display Manager). This is one of the highly requested features for GNOME and it is achieved through the gnome-remote-desktop component, which provides a remote desktop server for the GNOME desktop to allow you to connect to your machine remotely using PipeWire. ↫ Marius Nestor The final release is planned for late March.

A new accessibility architecture for modern free desktops

My name is Matt Campbell, and I’m delighted to announce that I’m joining the GNOME accessibility team to develop a new accessibility architecture. After providing some brief background information on myself, I’ll describe what’s wrong with the current Linux desktop accessibility architecture, including a design flaw that has plagued assistive technology developers and users on multiple platforms, including GNOME, for decades. Then I’ll describe how two of the three current browser engines have solved this problem in their internal accessibility implementations, and discuss my proposal to extend this solution to a next-generation accessibility architecture for GNOME and other free desktops. No clever quips or snarky nonsense – just read the proposal, and contribute if you can.

GNOME merge requests opened that would drop X.Org session support

A set of merge requests were opened that would effectively drop X.Org (X11) session support for the GNOME desktop and once that code is removed making it a Wayland-only desktop environment. Going along with Fedora 40 looking to disable the GNOME X11 session support (and also making KDE Plasma 6 Wayland-only for Fedora), upstream GNOME is evaluating the prospect of disabling and then removing their X11 session support. This surely won’t be controversial.

GNOME 44.5 released

GNOME 45 may have just been released, but that doesn’t mean GNOME 44 will be buried right away. GNOME 44.5 has just been released, packed with bugfixes and small tweaks – nothing groundbreaking. Reading through the changelog, it’s a long list of squashed bugs, so it should be an uneventful upgrade for most GNOME users who aren’t upgrading to 45 quite yet.

GNOME 45 released

The GNOME project is excited to present the latest GNOME release, version 45. For the new version we’ve focused on refining your daily interactions, enhancing performance, and making the overall experience smoother and more efficient. From subtle design tweaks to functional upgrades, GNOME 45 is all about refining the core desktop environment you rely on. GNOME 45 comes with a new Activities indicator, which replaces the “Activities” button with workspaces indicator, letting you know at a glance which workspace you’re on. A lot of work has gone into improving search performance, and they’ve added an indicator to let you know when your camera is in use. The image viewer has been replaced by an entirely new application, and there’s a new camera application as well. Of course, this is just a small selection – there are countless improvements and fixes in all the core GNOME applications. GNOME 45 will find its way to a distribution near you.

GNOME this week: Libadwaita 1.4 released

Update on what happened across the GNOME project in the week from September 08 to September 15. It wasn’t a massive week for the GNOME project – at least when it comes to easily digestible improvements that fit neatly on a blog post – but there’s still a few notable points. First and foremost, the release of Libadwaita 1.4, which brings UI breakpoints, which allows developers to create arbitrary layouts for their applications at different sizes. It also comes with new adaptive widgets, which should fix a whole slew of problems that crop up when resizing an application. For the rest, a whole bunch of GNOME applications have been updated, as well as a number of extensions.

GNOME 45 to break extensions more than usual

GNOME is going to change the way extensions are loaded in GNOME 45, and that’s going to be a bit of a nuisance for both users and developers. Extensions that target older GNOME versions will not work in GNOME 45. Likewise, extensions that are adapted to work with GNOME 45 will not work in older versions. You can still support more than one GNOME version, but you will have to upload different versions to for pre- and post-45 support. I guess the upgrade from GNOME 44 to 45 is going to be even more of a hassle than GNOME upgrades normally are due to broken extensions. Outstanding.

GNOME: rethinking window management

While most of us are used to this system and its quirks, that doesn’t mean it’s without problems. This is especially apparent when you do user research with people who are new to computing, including children and older people. Manually placing and sizing windows can be fiddly work, and requires close attention and precise motor control. It’s also what we jokingly refer to as shit work: it is work that the user has to do, which is generated by the system itself, and has no other purpose. Most of the time you don’t care about exact window sizes and positions and just want to see the windows that you need for your current task. Often that’s just a single, maximized window. Sometimes it’s two or three windows next to each other. It’s incredibly rare that you need a dozen different overlapping windows. Yet this is what you end up with by default today, when you simply use the computer, opening apps as you need them. Messy is the default, and it’s up to you to clean it up. There are a lot of interesting ideas in what GNOME is working on to address these issues, and it includes a lot of new thinking and new approaches to windowing. I have a lot of reservations, though. I do not like it when windows do something out of their own volition. A window should be where I put it, and manipulating one window should not make any changes to the shape or position of other windows, unless I’m specifically asking the window manager to do so (e.g. using the side-by-side snap feature, which I never do). There’s nothing I hate more than my UI deciding what’s best for me. Windows should be where I put them – until I explicitly instruct my window manager to put them somewhere else. I also do not understand this obsession with fullscreen windows. I just don’t get it. Unless it’s a video or a game, none of my windows ever go fullscreen, whether it be on a small 13″ laptop display, or on my 28″ 4K desktop monitor. I find fullscreen claustrophobic, and it almost never makes any sense anyway since virtually no application actually makes use of all that space. You just end up with tons of wasted space. Designing a UI with fullscreen as a corner stone absolutely baffles me. As such, some of these ideas for GNOME worry me a tiny bit, since they go against some of the core tenets I hold about my UI. I’ll see how it works out when it ships, but for now, I’m cautiously worried.

GNOME 44 released

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.

GNOME 43 released

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.

GNOME’s Mutter variable rate refresh support closer to being merged

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.

Towards GNOME Shell on mobile

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.

GNOME 42 released

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 released

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.

GNOME to prevent theming, wider community not happy

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.