Gnome Archive
A new image loading machinery, called glycin, has been in the works for a while. It is already used by GNOME’s default Image Viewer (Loupe), as well as by a bunch of other apps. Glycin provides many security benefits over existing solutions due to the use of the Rust programming language and sandboxing. Distributions will now be able to use the security benefits and broader format support of glycin for other GNOME apps, thumbnailers, and GNOME Shell, whithout changing any existing software. This is made possible by a new option for GNOME’s legacy image-loading library, GdkPixbuf, to use glycin internally. ↫ Sophie Herold Clearly, this is an improvement over the previous image loading library, but there’s a bit of a catch that is in line with GNOME’s increased reliance on systemd features: glycin only works on Linux due to its sandbox mechanisms and how it communicates with its loaders. However, there’s no need to fret this time, and that’s why I’m posting this item – you just know this tiny little tidbit will find their way into internet discussion forums and social media as another example of GNOME not caring about non-Linux users. While some of the sandboxing and communication features in glycin can be made to work on the BSDs and perhaps macOS, it won’t be perfect. As such, great care has been taken to ensure non-Linux platforms can continue to use GdkPixbuf just fine, since support for other platforms is part of the goals of this change before traditional loaders are removed. As a general solution for other platforms, I am planning a mechanism to compile the loaders into the library. This will not provide sandboxing and format extendability without recompilation. But since most loaders are written in Rust, this is still a huge step-up security wise. Contributions for support on other platforms are welcome. For GdkPixbuf users, this will not pose an immediate issue since traditional gdk-pixbuf loaders are not going away until all platforms it supported, are supported by glycin. ↫ Sophie Herold There are a few other issues, as any change like this tends to cause, like the list of supported images formats. Glycin supports AVIF, BMP, DDS, Farbfeld, QOI, GIF, HEIC, ICO, JPEG, JPEG XL, OpenEXR, PNG, PNM, SVG, TGA, TIFF, and WEBP out of the box, but some of the subformats within each of these might potentially not work entirely correctly due to incorrect implementations by, say, camera manufacturers. A special case here is the TIFF format, which apparently still has a number of issues and might end up relying on a fallback. Glycin brings a ton of benefits, such as improved colour support for things like HDR and wider colour gamut displays, better metadata support, basic image editing functions out of the box, increased performance, as well as the benefits inherent in using a memory-safe language like Rust.
GNOME has announced it’ll be increasing its dependency on systemd, the popular init system used by most (popular) Linux distributions. While GNOME already had a few relatively inconsequential dependencies on systemd, it was effectively not a huge problem to run GNOME on operating systems that don’t have systemd, which most notably includes the various flavours of BSD. That’s going to change. There’s going to be two changes, one of which is relatively minor, and one of which will pose much bigger problems. The minor change involves GDM becoming dependent on systemd’s userdb infrastructure in order to clean up a lot of GDM’s code involved in multi-seat setups and remote login. Currently, this works through a series of hacks that the GDM developers are going to clean up, switching to using systemd-userdb to “dynamically allocate user accounts, and then runs each login screen as a unique user”. To aid non-systemd environments during this transition, GDM will get a temporary alternate code path that enables you to run GDM without systemd-userdb. So if you compile GDM against elogind, GDM will use an alternative trick to enable multiple graphical sessions under the same user. This trick will remain in place at least until GNOME 50, but its future after that is uncertain. The second change is much more involved. Next, the bigger change. Since GNOME 3.34, gnome-session uses the systemd user instance to start and manage the various GNOME session services. When systemd is unavailable, gnome-session falls back to a builtin service manager. This builtin service manager uses .desktop files to start up the various GNOME session services, and then monitors them for failure. This code was initially implemented for GNOME 2.24, and is starting to show its age. It has received very minimal attention in the 17 years since it was first written. Really, there’s no reason to keep maintaining a bespoke and somewhat primitive service manager when we have systemd at our disposal. The only reason this code hasn’t completely bit rotted is the fact that GDM’s aforementioned hacks break systemd and so we rely on the builtin service manager to launch the login screen. Well, that has now changed. The hacks in GDM are gone, and the login screen’s session is managed by systemd. This means that the builtin service manager will now be completely unused and untested. Moreover: we’d like to implement a session save/restore feature, but the builtin service manager interferes with that. For this reason, the code is being removed. ↫ Adrian Vovk Mitigating this change will be a lot more involved for operating systems that don’t use systemd, and the blog post goes into detail into what, exactly, needs to be done in systemd-less environments. There’s quite a few systemd components and other little tidbits that you will need to find or create alternatives for, and considering you’ll need to have all of it in place roughly by GNOME 50, roughly a year from now, I can imagine this causing quite a few headaches for platforms like the BSDs and Linux distributions using init systems other than systemd. With these changes, GNOME further solidifies itself as a Linux desktop only – and lest anyone forget, that’s entirely within their right to do. Systemd haters can jump up and down all they want, but in the end, they have no right to demand that GNOME developers spend precious time and resources testing GNOME on and developing it for platforms that they themselves do not use. They’re clearly targeting the trifecta of Linux, system, and Wayland, and that’s their choice to make, not anyone else’s. Still, if operating systems like OpenBSD and FreeBSD, or Linux distributions without systemd intend to continue offering a fully functional GNOME desktop, they’re going to have some work to do.
While it’s still early days and it’s not recommended for non-technical audiences, GNOME OS is now ready for developers and early adopters who know how to deal with occasional bugs (and importantly, file those bugs when they occur). ↫ Tobias Bernard This is great news, and means GNOME OS is progressing nicely. I’m a proponent of this and KDE’s equivalent project, because it allows the people working on GNOME and KDE to really showcase their work in optimal, controlled conditions. While I don’t see myself switching to a Flatpak-based, immutable distribution because they tend to not align with what I want out of an operating system, they’ll serve as great showcases. There is a risk associated with these projects, though, as I highlighted the last time we talked about them. Once such “official” GNOME and KDE Linux distributions exist, the projects run a real risk of only really caring about how well GNOME and KDE work there, while not caring as much, or even at all, how well they run everywhere else. I’m not sure how they intend to prevent this from happening, but from here, I can already see the drama erupting. I hope this is something they take into consideration. We’ll have to wait and see if my worries are founded or not.
This week’s This Week in GNOME mentions that Blueprint will become part of GNOME. Blueprint is now part of the GNOME Nightly SDK and is expected to be part of the GNOME 49 SDK. This means, apps relying on Blueprint won’t have to install it manually anymore. Blueprint is an alternative to defining GTK/Libadwaita user interface via .ui XML-files (GTK Builder files). The goal of blueprint is to provide UI definitions that require less boilerplate than XML and are easier to learn. Blueprint also provides a language server for IDE integration. ↫ Sophie Herold Quite a few applications already make use of Blueprint, and even some Core GNOME applications use it, so it seems logical to make it part of the default GNOME installation.
One of the two major open source desktop environments, GNOME, just released version 48, and it’s got some very big and welcome improvements. First and foremost there’s dynamic triple-buffering, a feature that took over five years of extensive testing to get ready. It will improve the smoothness and fluidity of animations and other movements on the screen, as it did for KDE when it landed there in the middle of last year. GNOME 48 also brings notification stacking, combining notifications from the same source, improvements to the new default image viewer such as image editing features, a number of digital well-being options, as well as the introduction of a new, basic audio player designed explicitly for quickly playing individual audio files. There’s also a few changes to GNOME’s text editor, and following in KDE’s recent footsteps, GNOME 48 also brings HDR support. Another major change are the new default fonts. Finally, Cantarell is gone, replaced by slightly modified versions of Inter and Iosevka. Considering I absolutely adore Inter and installing and setting it as my main font is literally the first thing I do on any system that allows me to, I’m fully behind this change. Inter is exceptional in that it renders great in both high and low DPI environments, and its readability is outstanding. GNOME 48 will make its way to your distribution’s repositories soon enough.
In late June 2024 I got asked to take over the work started by Jerry Wu creating a systemd-sysupdate plugin for Software. The goal was to allow Software to update sysupdate targets, such as base system images or system extension images, all while respecting the user’s preferences such as whether to download updates on metered connections. To do so, the plugin communicates with the systemd-sysupdated daemon via its org.freedesktop.sysupdate1 D-Bus interface. I didn’t know many of the things required to complete this project and it’s been a lot to chew in one bite for me, hence how long it took to complete. ↫ Adrien Plazas This new plugin was one of the final pieces of moving GNOME OS – which we talked about before – from OSTree to sysupdate, which in turn is part of GNOME OS’ effort to have a fully trusted boot sequence. While I’m not sure GNOME OS is something that will find a lot of uptake among the kind of people that read OSNews, I think it’s a hugely important effort to create a no-nonsense, easy-to-use Linux system for normal people to embrace. The Steam Deck employs similar implementations, and it’s easy to see why.
It seems the GNOME team is getting quite serious about turning GNOME OS into an end-user focused Linux distribution, similar to a project KDE is working on. GNOME OS is GNOME’s development, testing, and QA distribution. It’s not designed to be useful as a general-purpose system, and so it hasn’t been the center of attention. However, that makes it a convenient place to experiment, and ultimately through sheer coincidence the GNOME OS team ended up developing something that follows my vision using the same technology that I was. The only real difference was intent: carbonOS was intended for mass adoption, and GNOME OS was not. In essentially every other aspect, the projects had the same roadmap: following Lennart Poettering’s “Fitting Everything Together” proposal, providing a stock GNOME experience, and even using the same build system (BuildStream). ↫ Adrian Vovk The goal with GNOME OS is to showcase the best GNOME has to offer, built on top of an immutable base system, using Flatpak as the means to install applications. Basically, we’re looking at something very similar to the immutable Fedora GNOME variant, but probably with even less modifications to stock GNOME, and perhaps with few more newer things as default, like perhaps systemd-boot over GRUB. KDE also happens to be working on a very similar project, with many of the same design choices and constraints. I think this is an excellent idea, for both GNOME and KDE. This allows them to offer users a very focused, simple, and resilient way of showcasing the latest and greatest the two desktop environments have to offer, without having to rely on third-party distributions to not make silly choices or mess things up – for which GNOME and KDE developers then tend to take the heat. Systems like these will, of course, also be a great way for developers to quickly spin up the latest stock versions of GNOME and KDE to test their applications. Still, there’s also a downside to having official GNOME and KDE distributions. If users find bugs or issues in these desktop environment when running other distributions, like Fedora or Ubuntu, GNOME and KDE developers may be tempted to just shrug them off and point them to the official GNOME and KDE distributions. It works there, so obviously the cause of the bug lies with the unofficial distribution, right? This may be a tempting conclusion, but may not be accurate at all, as the real cause could still lie with GNOME and KDE. Once such “official” GNOME and KDE Linux distributions exist, the projects run a real risk of only really caring about how well GNOME and KDE work there, while not caring as much, or even at all, how well they run everywhere else. I’m not sure how they intend to prevent this from happening, but from here, I can already see the drama erupting. I hope this is something they take into consideration. Immutable distributions are not for me, since I prefer the control regular Fedora and RPM gives me, and I don’t want to give that up. It also doesn’t help I really, really don’t like Flatpak as it exists today, which is another major barrier to entry for someone like me, and I assume most OSNews readers. However, there are countless Linux users out there who just want to get stuff done with whatever defaults come with their operating system, and for them, this newly proposed GNOME OS and its KDE counterpart are a great choice. There’s a reason Valve opted for an Arch-based immutable KDE distribution for the Steam Deck, after all.
The GNOME project has released their newest major version, GNOME 47, and while it’s not the most groundbreaking release, there’s still a ton of good stuff in here. Two features really stand our, with the first one being the addition of accent colours. Instead of being locked into the default GNOME blue accent colour, you can now choose between a variety of colours, which is a very welcome addition. I use the accent colour feature on all my computers, and since I run KDE, I also have this nifty KDE feature where it’ll select an accent colour automatically based on your wallpaper. No, this isn’t a groundbreaking feature, but considering GNOME’s tendency towards not allowing any customisation, this is simply very welcome. A much more substantial feature comes in the form of brand new open/save file dialogs, and I’m sure even the GNOME developers themselves are collectively sighing in relief about this one. GNOME’s open/save dialogs were so bad they became a meme, and now they’re finally well and truly fixed, thanks to effectively removing the old ones and adding new ones based on the GNOME Files file manager. GNOME 47 comes with brand new file open and save file dialogs. The new dialogs are a major upgrade compared with the previous versions, and are based on the existing Files app rather than being a separate codebase. This results in the new dialogs having a much more complete set of features compared with the old open and save dialogs. With the new dialogs you can zoom the view, change the sort order in the icon view, rename files and folders, preview files, and more. ↫ GNOME 47 release notes And yes, this includes thumbnails. There’s tons more in GNOME 47, like a new design for dialog windows that look and feel more like they belong on a mobile UI, tons of improvements to Files, the Settings application, GNOME Online Accounts, Web, and more. GNOME 47 will make its way to your distribution of choice soon enough, but of course, you can always build and install it yourself if you’re so inclined.
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.
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?
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.
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 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.
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.
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.
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 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.
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.
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 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 extensions.gnome.org 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.
