The other day, I had a problem.

I use GNOME Calendar quite a lot, and although it's not quite on par with online tools like Google Calendar or even the iOS Calendar, it's greatly improving every day, thanks to the nature of open source and the awesome contributors.

One issue that bugged me a lot, is that when you are creating a new event, you usually have a lot of calendars, and GNOME Calendar can be quite unintuitive when it comes to selecting the right one.

The base issue is that it doesn't separate calendars by source, which can lead to confusion.

[Insert Image Here]

Cloning

To get started, I had to clone the GNOME Calendar repository from GNOME GitLab:

git clone git@ssh.gitlab.gnome.org:GNOME/gnome-calendar.git

Note: apparently, this can be further simplified with foundry clone gnome:gnome-calendar

In the past, I would have needed to open the application in GNOME Builder or VSCode to be able to build and run the application with flatpak.

However, foundry promises that I can do the same with just the CLI. This would mean I'd theoretically be able to build and run the application with just the CLI. This is amazing, since I use the [Zed Editor][zed], and it doesn't support building and running applications with flatpak.

What is Foundry?

The creator of foundry describes it as a "tool aims to extract much of what makes GNOME Builder an IDE into a library and companion command-line tool.".

In practice, this means you can run language servers, build systems, etc... in a CLI. Basically an IDE without the GUI.

Building and Running

To build and run the application with foundry , I can simply run the following commands:

foundry init

This creates a .foundry directory in the current directory. I usually run this command to ensure it's never committed to the git repo.

echo "*" >> .foundry/.gitignore

Selecting the config

Usually foundry will auto-detect the way you build your application (it's called the config). You can check the current configs with:

foundry config list

Mine prints:

ID                               Active  Can Default  Priority  Build System  Name
flatpak:org.gnome.Calendar.json  Yes     Yes          100       meson         org.gnome.Calendar.json
buildconfig:default              No      Yes          0                       default

I think you could use foundry config add --flatpak path/to/your/app.json if it's not auto-detected.

Note: one issue is that you can't run foundry config add --help and expect to see the help text. Maybe this can be worked on in the next version.

Building

I would have expected running foundry build to just work, but it gives this error:

Project does not contain an active SDK

Interesting...

To fix this, I ran foundry sdk list and got a list of all the available SDKs:

ID                                                                Name                                               Arch    Kind       Active  End of Life  Installed  Extension
494aa38dcc2958e30e9c9671b6ad25ebaf7cb5f4a6e53b76f70934b94b83bd7e  alpine                                             x86_64  distrobox  No      No           Yes        No
8f8f79a03052fb2714f0ea0dffa03a6c8012d61614ee52a572352ec344723f71  fedora                                             x86_64  distrobox  No      No           Yes        No
b43b018589d226269eebc614717190934072bac11ca8402c0fda40c0f0209afd  arch                                               x86_64  distrobox  No      No           Yes        No
2a86e5fe8c026ddeba92b5fc0a7aced7ff69907995daaa1d282250f8a57c3e2d  mongo                                              x86_64  podman     No      No           Yes        No
21a0213cf6d6455a09147cefbd190dfbb95b379c07b2d88592283cfca8b9e52a  arch-waydroid                                      x86_64  distrobox  No      No           Yes        No
055e157c553825d0493a51cf4a5cf3e684c6d9d58ec85a1da71f4a0696d7daf1  echo_postgres_1                                    x86_64  podman     No      No           Yes        No
93ced2d53fe77016e986dfd616d63978d391b05b58fccb62b1aeb26cce74243d  echo_valkey_1                                      x86_64  podman     No      No           Yes        No
bca61df81aace8e3a70e1736829d1ad387936d34586689a3f16bd50e39edfc63  herbmadz-erp_rustfs_1                              x86_64  podman     No      No           Yes        No
no                                                                No SDK                                             x86_64  host       No      No           Yes        No
host                                                              My Computer                                        x86_64  host       No      No           Yes        No
org.freedesktop.Platform.VAAPI.Intel/x86_64/24.08                 org.freedesktop.Platform.VAAPI.Intel 24.08         x86_64  flatpak    No      No           Yes        No
org.freedesktop.Platform.VAAPI.Intel/x86_64/25.08                 org.freedesktop.Platform.VAAPI.Intel 25.08         x86_64  flatpak    No      No           Yes        No
org.freedesktop.Platform.codecs-extra/x86_64/25.08-extra          org.freedesktop.Platform.codecs-extra 25.08-extra  x86_64  flatpak    No      No           Yes        No
org.freedesktop.Platform/x86_64/24.08                             org.freedesktop.Platform 24.08                     x86_64  flatpak    No      No           Yes        No
org.freedesktop.Platform/x86_64/25.08                             org.freedesktop.Platform 25.08                     x86_64  flatpak    No      No           Yes        No
org.freedesktop.Sdk/x86_64/25.08                                  org.freedesktop.Sdk 25.08                          x86_64  flatpak    No      No           Yes        No
org.gnome.Platform/x86_64/48                                      org.gnome.Platform 48                              x86_64  flatpak    No      No           Yes        No
org.gnome.Platform/x86_64/49                                      org.gnome.Platform 49                              x86_64  flatpak    No      No           Yes        No
org.gnome.Sdk/x86_64/49                                           org.gnome.Sdk 49                                   x86_64  flatpak    No      No           Yes        No

It seems to include "SDKs" from various sources:

• distrobox containers I had created earlier
• podman containers
• flatpak runtimes
• running directly on the host

Since I'm building from the main branch of gnome-calendar , this means I will be needing the master version of the GNOME SDK (you can check in build-aux/org.gnome.Calendar.json ):

{
    "app-id" : "org.gnome.Calendar.Devel",
    "runtime" : "org.gnome.Platform",
    "runtime-version" : "master",
    "sdk" : "org.gnome.Sdk",
    "command" : "gnome-calendar",
    ...

The foundry docs mention that it should be possible to do this: foundry sdk install org.gnome.Sdk//master

but it spews an error:

No such sdk "org.gnome.Sdk//master"

Instead, I installed the SDK with the flatpak tool:

flatpak install gnome-nightly org.gnome.Sdk//master

Running foundry sdk list again now mentions it, and I can it gets automatically selected.

Now, I can finally build the app:

foundry build

Which fetches lots of the sources mentioned in the org.gnome.Calendar.json file, and then finally fails with:

Stopping at module gnome-calendar
error: org.gnome.Platform/x86_64/master not installed
Failed to init: Unable to find runtime org.gnome.Platform version master
Child process exited with code 1

Which I solved with:

flatpak install gnome-nightly org.gnome.Platform//master

Running foundry build again now succeeds. It will build all sources, then the app, so it will take quite some time the first time.

The nice thing is that when done, it won't need to be rebuilt again, as the sources are cached.

Running

foundry run

Tada!

It’s already a month since we were in Spain for GUADEC and I still haven’t gotten around to writing something, so before I completely forget here are a few quick impressions and photos!

Local-First

Similar to last year, my main focus was on local-first, since that’s what I’ve mostly been working on recently. Julian and I gave a talk about Reflection and the p2panda-gobject bindings , and more generally plans for making local-first sync part of the GNOME developer platform.

Julian showing off p2panda-gobject during the BoF on Sunday

We also had a local-first BoF to discuss system integration on Sunday, and a p2panda-goject workshop on Monday where we prototyped the Migrations app Jakub designed. Both were really well-attended, and it was super cool to see people starting to prototype their own little experiments that sync, including a collaborative Snake game, and a collaborative drawing app.

Blackboard at the local-first BoF with some notes on the Contacts and Sync portals

Our current thinking around system integration is that we wan to have two separate portals: one for Contacts, which would just manage P2P identities (so apps don’t have to each have their own identity system and contacts management), and a second one that actually syncs data on behalf of apps using a system API. For the former there is already a relatively detailed plan (see the talk linked above), and this will be prototyped as part of a p2panda NLnet grant.

This entire area is of course still experimental so all plans are subject to change, but it’s exciting to see things get more and more concrete over the past year.

Talks

Some of my favorite talks:

• Session Save/Restore by Adrian Vovk: Really cool to see the progress in this area, but also incredible how many moving parts are involved in getting this to just work . Kudos to Adrian and everyone else who’s helping to push this forward!
• Foundation Annual General Meeting by Allan Day: Really clear and concise overview of where the Foundation is at, what changes have been made to make it more financially sustainable, and what challenges still persist. The fellowship in particular is a very nice, tangible new thing and at least to me a sign that some things have changed for the better. I found this framing particularly interesting: the Foundation is a corporation, and the AGM is a meeting for “shareholders”, i.e. people who invest their time (rather than their money) in the Foundation, to assess whether the investment is well managed.
• The Future of Boxes by Felipe Borges: I’m very happy to see Boxes revived and modernized, it’s a secret gem of our app ecosystem. Kudos to Felipe for his work on this!
• A Brief History of Graphs by Sjoerd Stendahl: Very nice talk, and a great success story for how programs focused on the third-party app ecosystem like Circle can help to bring people into the community.
• GNOME OS Mobile lightning talk by Aberrahim Kitouni: Between this and the Mobile BoF it was very nice to see more people across the community pushing towards making mobile an official part of the GNOME release process.

Great to see new generations making old wisdoms their own :)

City and Venue

The logistics of constantly going back and forth between the Rialta dorms, the University building, and the city center made the social side of the conference more difficult than in other years, especially because public transit stopped relatively early in the evening. As usual, the smart move would probably have been to stay in the city center, but that only goes so far if everyone else is staying at the official accommodation, which is far away. More generally, the A Coruña city center was cute, but other parts of the city felt really car-centric and not very fun to be in.

The view from the hill was pretty cool though :)

Meta

I found it a bit sad that once again, we didn’t manage to use the fact that so many people were together in person to make progress on resolving the conflicts of the past few years. I didn’t see it as my responsibility to take care of this, and I assume everyone else felt the same way. But here’s an idea for next year: An official “Conflict Resolution BoF”, chaired by a trained mediator.

If there’s any interest I’d be happy to co-organize something like this, but I wouldn’t want to be solely responsible for it.

More Photos

Local-first workshop on Monday Philipp at the Design BoF The Mobile BoF People hacking at the university Traditional GUADEC dinner

See you next year!

Earlier this month, I published a post about the future of Boxes where I detailed the huge technical rewrite I have been doing, porting to GTK4, Libadwaita, and replacing our SPICE display widget with Libmks. Today, I want to share a structural decision that aligns with that vision and sets up the project for long-term health/sustainability.

I have formally submitted a proposal to remove Boxes from the core-developer-tools set in gnome-build-meta and transition it towards becoming an independent application (with the ultimate goal of applying for GNOME Circle once all criteria are met).

I want to dive into why I am making this move, what it means for users and maintainers, and why I believe this is the right path forward.

There is No Drama Here

First off, let’s get this out of the way: there is zero drama between Boxes and the GNOME project.

Boxes continues to be built by the same core set of contributors, fully committed to the GNOME Human Interface Guidelines (HIG) and deeply integrated into our ecosystem. We aren’t stepping away from GNOME. We are simply right-sizing how Boxes is categorized, distributed, and maintained.

Why Boxes Shouldn’t Be “Core” (and Why Versioning with the OS is Outdated)

The desktop Linux landscape is shifting toward image-based operating systems with atomic updates and immutability. In this model, the underlying operating system provides a slim, reliable base, while applications live on top and update independently at their own pace.

Tying a complex application like Boxes to the biannual GNOME release schedule is not useful anymore. It forces us to hold back features and bug fixes for months just to align with the OS cadence, when users should simply get updates when they are ready and stable.

Furthermore, virtualization isn’t an essential utility that needs to be pre-installed on every single user’s machine by default. Boxes fits much better as a targeted application users explicitly choose to install when they need it.

Flathub-First: Moving Fast and Ending Distribution Bottlenecks

As a maintainer, maintaining separate code paths and stable branches for dozens of traditional distribution packages is simply not sustainable long-term. I can no longer afford to maintain multiple stable branches. Moving forward, I am simplifying maintenance down to one stable branch and one development/nightly branch. To make this sustainable, Flathub is our primary and only officially supported distribution method.

By bundling the virtualization stack in our Flatpak, we ensure that users get a much more tested, consistent, and working virtualization backend regardless of what operating system they are running.

Moving out of Core allows us to heavily discourage downstreams from individually packaging Boxes. Instead, distros should defer their users to the official Flatpak on Flathub . If you are filing bug reports or seeking support, the Flathub build will be the baseline.

Branding and Infrastructure Changes

To reflect this independent status, a few logistical changes are happening alongside this move. We are dropping “GNOME” from the user-facing app branding. Going forward, it will simply be named “Boxes”,  and we will soon be moving to a new website domain (which is currently being finalized). Importantly, our Flatpak application ID will remain org.gnome.Boxes for full continuity and compatibility. This means existing installations, user settings, and Flatpak configurations won’t break, and users won’t need to reinstall anything.

What’s Next?

This change gives us the flexibility to release updates whenever features are ready, iterate faster, and dramatically reduce maintainer burnout, all while delivering a more reliable and consistent user experience via Flathub. Once we settle into this new cadence and finalize our transition, we plan to apply for GNOME Circle .

To set clear expectations on timing: since Boxes currently uses GTK3 in its stable releases, we will soon submit an application for GNOME Circle review following our GTK4/Libadwaita rewrite.

If the Circle application is approved before the GNOME 52 Alpha deadline, the plan is to proceed with the removal from core-developer-tools and transition to Circle in time for the GNOME 52 release in March 2027.

For distribution maintainers wondering about upcoming distro releases: distros targeting GNOME 51 can continue to package the GNOME 50 release of Boxes, which will remain supported for the standard lifecycle of that release. If everything goes according to plan, GNOME 52 won’t include Boxes in the core set anymore. At this point, please don’t package Boxes anymore.

Week 29

This week's icon is for Deimos Hall 's project:
Metamorphosis : "Edit metadata"

Check out all weekly app icons created so far in the gallery and follow my icon creation adventures as they happen (including sketches) on the Fediverse .

Need icons?

I love designing icons and am happy to contribute them free of charge when your project is Free and Open Source . Funded by community sponsors (every little helps!).

Hello all! It’s my first blog ever, so please bear with me.

Recently I’ve been active in Engagement team and helping out with the reboot. Hopefully you noticed our social media accounts are a tad more lively!

Part of the reboot process was dropping all the unrelated activities the team accumulated over the years, like events and such, with the goal on focusing on social media purely. There’s still work to do, but since we started doing weekly meetings (Monday 16:00 CEST, if you’re interested please see our meeting pad !) progress has been steady.

But we need your help in this! Engagement team is quite small, and to properly expand our activities onto other social media we need more contributors. Do you know how to edit images, create graphics? We need YOU for Instagram! Do you know how to make videos (short form or long form)? Our YouTube and TikTok are waiting for you! And let’s not forget that we always welcome new ideas for posts or people sharing their posts on social media for us to boost.

Currently platforms we’re on include:
– Fediverse
– Bsky
– Reddit

We want to (potentially! nothing here is set in stone!) also expand on:
– Facebook
– TikTok
– Instagram
– Improve our LinkedIn
– Improve our YouTube

But this is currently out of reach for us due to not having enough volunteers. We welcome everyone who wants to make world think better about GNOME!

To help developers in reaching us we introduced new labels:

– Newsworthy, for when you want us to share something on social media
– Team: Engagement, for when you want to summon us to discuss something.

We also have an „Engagement Materials” label, when you have some assets for us to use.

Interested? Visit us in #engagement:gnome.org and #socials:gnome.org Matrix rooms.

---

Written by Victoria Niedzielska. Thanks to other Engagement team members for proofreading the blog post!

Most of GNOME 51 is now packaged for Fedora 45. Starting today and running through the end of the week, we will be running our traditional Fedora Test Day for GNOME . If you are a Fedora user, you can help us find last-minute integration issues and iron out what’s going to become the stable Fedora 45 release.

You can either boot the latest Fedora 45 image (nightly) in a virtual machine or update an existing test setup. Follow our guided test matrix , try out different features, and record your results. Even testing for 15 minutes and reporting a single issue makes a huge difference.

Visit https://fedoraproject.org/wiki/Test_Day:2026-08-17_GNOME_51_Desktop for more info. You can join the Fedora Workstation Matrix chat channel if you have more questions.

I wholeheartedly dislike GMail (ethically, technically, and UX), and for my personal email I have always run my own server. But for work email I don’t have a choice. I am using isync/mbsync to make it usable for me and mutt. Until now I’ve used a Google app password to authenticate, but they are a security nightmare. OAuth2 is a better way. Sadly the interwebs have only scarce, outdated, or buggy recipes, so I finally spent the better part of an afternoon and moved OAuth2.

For the past few months, we’ve been developing all kinds of features for the future GIMP 3.4 release. We noticed recently that our changelog was getting quite long - a good problem to have!

While there’s been a lot going on internally, it’s been a while since we made a public progress report. So we want to share details on some of the new features and UX improvements that’ll be available in the first development release, GIMP 3.3.2 . This won’t be an exhaustive list (we have to save at least some news for the release itself!) but hopefully it will give you some insight into the current direction and progress of GIMP ’s development.

New Project File Format ¶

The big focus for maintainer Jehan recently has been developing a new project file format for GIMP .

XCF has been GIMP ’s primary project format since 1997 , and it has served many users well. Over time however, we’ve observed more and more limitations of the binary XCF format. Among other issues, it does not easily support very large or complex projects, such as the multi-page and animation features currently planned for GIMP 3.6.

The new project file format will follow a more common “zipped XML ” structure. While the technical details are still being designed and implemented, this change will allow for faster saving since we’ll only need to update parts of the file instead of the whole thing each time. It will also set the stage for much desired features such as auto-saving, which will now be much more feasible.

That said, XCF is not going away! Backwards compatibility is important to us, and we will continue to support loading XCFs in all future versions of GIMP . (For instance, we’re quite proud that a XCF file made by a small company for their logo in 1998 still renders the same way in the latest version of GIMP )

However, going forward we will only add support for saving/loading new features in the new project file format once it is finalized.

MyPaint Brush: Spectral Blending ¶

During GIMP 3.2’s development, we upgraded to a newer version of the MyPaint brush engine. While this brought new brushes and canvas interactions to the MyPaint Brush Tool , one feature that was left out was Spectral Blending .

Spectral Blending simulates the effects of blending physical pigments in digital art. For example, blending yellow and blue will produce a green color instead of darker yellow, and blending red and yellow will create an orange mix.

Fortunately, new contributor Cassidie Grogan picked up the slack and implemented this feature. There is now a Spectral Blending checkbox in the MyPaint Brush Tool Options. If checked, the new blending method is used. You can control the strength of the blending with the Pigment slider.

In addition, maintainer Michael Natterer improved the MyPaint Brush preview code to display at their full size instead of 48x48 pixels. This fixes an issue where the previews appeared blurry on larger screens.

Non-Destructive Editing ¶

Alx Sa has continued making updates to our non-destructive filter code. To list a few:

You can now apply filters non-destructively to Layer masks ! To go along with this, the filter popover has been redesigned by Reju to show the active filters for both the layer and its mask, so you can interact with both on the same screen.

The Gradient Tool can now be used non-destructively! If you check Editable Gradient in the Tool Options, the gradient you create will be added to the filter stack like any other effect. You can toggle its visibility, rearrange its position in the filter stack and delete it. You can also edit the gradient, which will switch back to the Gradient Tool to let you make further changes.

User interface with a live Gradient filter on the layer, and a live filter on the layer mask

Filters without dialogs (such as Invert) can now be applied non-destructively on non-raster layers such as layer groups and link, text, and vector layers.

PSD Support Improvements ¶

Normally we list all file format updates in a combined section, but there has been so much work done on PSD support (and by so many people) that we wanted to highlight it in more detail.

First, new contributor Frank Teklote has been busy improving our compatibility with PSDs. His big project for this release was creating a PSD metadata export procedure for TIFFs and JPEGs. This complements our existing PSD metadata import procedure , meaning that if you import a JPEG with paths or a TIFF with layers (or create one in GIMP ), that information can now be retained in the exported image.

Another great thing about Frank’s work is that as we continue to improve our PSD compatibility, the TIFF and JPEG export features will automatically get those updates too!

Related to that, Jacob Boerema has implemented PSD Descriptor import support. Most of our current PSD support has been based on the public Adobe specification . This document was last updated in 2019 however, and modern PSDs use a relatively undocumented text format called Descriptors to store many features.

Now that GIMP can read descriptors, we’ve begun drastically improving our PSD import support. To list just a few updates: text layers are now editable, a number of adjustment layers and modern layer styles appear as their GEGL equivalents, and solid color shapes are imported as vector layers. This is an active area of development, including by two of our GSoC students Akascape and Waris Maqbool . We hope this work will make it easier for GIMP users to interact with existing PSD projects!

Editable PSD text layers in GIMP

Native File Chooser Dialogs ¶

We have always used the file chooser dialog provided by the GTK GUI library for people to find, load, and save files in GIMP . While the file chooser does the job, it often works differently than the “native” file chooser on non- GNOME platforms like Windows, macOS, and KDE . Additionally there have been some changes to the UI of this dialog in GTK3 , which has inspired some strong feedback in our issue tracker!

Therefore, Alx Sa has begun porting GIMP ’s file choosers to the “native” option provided in GTK3 . This means that when you open or save a file, you will see your platform’s standard file chooser dialog instead of the GTK dialog (unless your platform uses that already, in which case there will be no change!)

Example of native file chooser on macOS, by Bruno Lopes

Many of the simple dialogs have already been converted. Those with more complex additional features will require some workflow redesigns, which we’re still developing.

User Experience and Interface Updates ¶

A lot of new and existing contributors have submitted improvements to GIMP ’s user interface and its user experience. We wanted to highlight their efforts, and encourage you all to continue sharing your feedback on our design issue tracker .

Designer Denis Rangelov has been hard at work updating GIMP ’s UI icons. He recreated our layer lock icons to create a more consistent look.

He also took on the monumental task of converting all 78 of our cursor icons to SVG , which will allow us to scale them for higher resolution displays without losing quality!

Original Raster Cursor	Denis’s Vector Cursor

There have been reported performance issues when drawing or zooming into the canvas when the canvas view was rotated. New contributor woot000 diagnosed the problem and created a fix. Now the “checkerboard” transparency pattern no longer rotates when the canvas does, which significantly boosts performance when painting or editing. They also fixed a related issue where the checkerboard pattern would disappear when zooming into the canvas past a certain point.

Gabriele Barbero implemented a redesign of the Search Action UI which was designed by Denis Rangelov . The new layout makes the associated shortcut key more visible, and is more consistent with the menu layouts.

Bruno Lopes has been working to fix issues with pop-up dialog displays on macOS. Since traditionally we have fewer macOS developers compared to other platforms, we’re really happy to see improvements for these users!

New contributor Andreas Vukman improved our Pattern dock display. Now smaller patterns tile to fill the available space, creating a consistent preview for all patterns instead of having some patterns display with odd amounts of padding. We think it makes the dock look much nicer!

Richard Gitschlag has updated the on-canvas text editor to allow selections when you Shift +Click in the text. It should now work similar to what you can do in a word processor like LibreOffice.

In previous versions of GIMP , you imported or exported metadata from the Metadata Editor by selecting an option in a dropdown. Ahmed E. Yassin has made this process more intuitive (and more consistent with the rest of GIMP ’s UI ) by replacing the dropdown with two buttons instead.

Ondřej Míchal reviewed several portions of GIMP ’s UI and replaced many instances of the Spin Entry widget with Spin Scale . The Spin Entry widget is difficult to use when the width is shrunk, so this change improves usability in many areas of the UI .

Assorted Changes and Fixes ¶

Our four GSoC interns have been continuing their work since the midpoint update . Recently, Waris Maqbool ‘s Sharpen filter was merged into GEGL , so it’ll be available in the next GEGL release.

New contributor Dimitriy Ryazantcev has submitted several patches for improving our Windows ICO / CUR / ANI support. They’ve already fixed the rendering for certain 32bit ICO formats and made our loading and preview algorithms better match the Windows specification.

Estecka has fixed a rendering issue when applying NDE filters on passthrough layer groups, which made the image look different depending on whether the group had child layers or not.

New contributor Petr Vorel fixed a bug where pressing Alt + 0 did not open the tenth most recent image in your history.

Lloyd Konneker , our main Script-fu contributor, fixed a regression in third party scripts where the number range for certain parameters wasn’t shown in the GUI .

Jacob Boerema and Alx Sa have responded to and patched a number of security reports about potential flaws in some of our image plug-ins.

What’s Next ¶

There’s more in-progress work that we look forward to sharing with you all soon!

There is not an official 3.3.2 development release yet, as several roadmap items are still in-progress. If you’re feeling really adventurous and just can’t wait, you can try our “nightly” builds. Instructions are under the Automatic Development Builds header.

In the meantime, we are planning to release GIMP 3.2.6 in the coming weeks. It is a stable release so it won’t include many of the new features described here. However, it will have a number of important bug fixes and small improvements. We’ll discuss these more in the 3.2.6 release news post!

Update on what happened across the GNOME project in the week from August 7 to August 14.

GNOME Circle Apps and Libraries

Graphs ↗

Plot and manipulate data

Sjoerd Stendahl reports

This week we landed a minor update in Graphs, but with a major improvement for the user experience. In the new version, internal updates such as for the clipboard, view history and axis limits are calculated with a debounce. What this means is that these properties are no longer recalculated upon every single movement when panning or zooming the canvas, instead it will only be calculated after the motion.

The result is a major improvement in user experience on less overpowered hardware such as laptops or older PC’s. The latest update also comes with translation updates and some other bugfixes, such as the elimination of a performance regression after switching style multiple times. See the difference for yourself in the attached video, panning and zooming is significantly smoother now. Recorded on the same laptop!

GNOME Fellowship

Peter Eisenmann announces

I posted about what I did as a GNOME Fellow in July, read about it here :) https://blogs.gnome.org/p3732/fellowship-report-july-2026/

Sovereign Tech Fellowship

Philipp Sauberzweig says

I’ve completed the first month of my Sovereign Tech Fellowship for GNOME Design & Community Management. Check out my blog post for an update about what’s been going on.

Third Party Projects

Cleo Menezes Jr. reports

The new Serigy release makes your slots searchable from the overview. Press Super, type, and you get your text, images and files back as results, ready to copy without opening the app (it needs to be enabled in the Search section of GNOME Settings).

Clipboard monitoring is optional now, so you can leave it off and capture only when you press the shortcut. Copied files are kept as references and paste as files. Content marked sensitive never reaches a slot. The grid goes up to 24 slots, and a new option hides the window right after you copy.

There is also a good amount of fixing: global shortcuts survive a portal restart, saved images no longer live in the cache directory where the system could delete them, logs are rotated instead of growing until the app fell over, and clipboard capture is far more reliable.

Get it on Flathub: https://flathub.org/apps/io.github.cleomenezesjr.Serigy

Mikhail Kostin announces

Vinyl - music player with the best lyrics support, has been updated on v1.6.0! There is a lot of changes and fixes since v1.5.0. I tried to do as much work as possible on the optimization of the player, especially I did a lot for reduce RAM consume, since last version RAM consumes reduced almost 3 times. Also not unimportant to say about new selection mode for remove tracks from main playlist.

Changes and fixes include in this release:

• Added selection mode for remove tracks from main list
• Added preferences dialog for introduce more features
• Added opportunity to auto restore playlist immediately after opening the app
• Improved restore playlist, currently Vinyl saves host paths for directories to which it has access
• Improved playlist optimization: large playlists no longer consume a lot of RAM
• Fixed settings not being saved after re-opening the app
• Fixed an issue where Vinyl wouldn’t read cover images from folders
• Fixed minor localization problems
• Fixed minor UI issues
• Added Occitan localization language

Today you can see the new version of the Vinyl on Flathub

For Void Linux users Vinyl also distributes on Community-driven repository blackhole-vl in native xbps package

Rat Cornu says

ratic music player comes back after a little break with new features!

The past few weeks have seen versions 0.3.0, 0.3.1 and 0.4.0, introducing a beginning in playlists support, grouping musics by album in artists view, cover and tags export and a lot of other small features and fixes.

You can find it on flathub , or directly on gitlab for rust or nix users.

The current state of ratic stills lack a lot of features I want to see in it, but it will progressively arrive in the next releases.

Thanks to all the people that helped with the localization on weblate and the constructive issues on the repo!

Sjoerd Stendahl announces

This week I also released an update to Lockpicker, a tool to recover passwords from their hash. In the new version a notification is sent when any password is cracked, or when the application is finished. The most exciting part of the new update is a completely new logo thanks to Hylke Bons .

I also started working on a rule designer/tester for Hashcat rules. Which hopefully will be added somewhere in the upcoming weeks. You can get Lockpicker at Flathub .

Anton Isaiev announces

RustConn 0.20.0 is out - connection manager for SSH, RDP, VNC, SPICE, Telnet, Web and Zero Trust (GTK4/libadwaita).

This covers the whole 0.19.x->0.20.0 cycle since the last post. Main new features: detachable session windows, split view improvements (remove from split, local shell in pane), cluster tab groups, floating auto-hide toolbar for RDP/VNC/Web with an option to hide it entirely, GTK renderer chooser (Automatic/GPU/Cairo), session logging with rotation and redaction, automatic login for Telnet/Serial, session restore on startup, terminal history across reconnects, and signed SLSA build provenance.

Fixes: embedded RDP reconnects after sleep (TCP keepalive), X11 clipboard crash resolved, RDM/Royal TS import reworked, credential keyring handling fixed across all backends, FreeRDP 3.26+ compat, macOS tray icon preserved.

Thanks to everyone who uses RustConn, reports bugs, contributes or supports the project. I made it for myself and I’m glad it helps others. If you’d like to support development - the repo has a Sponsor link.

https://github.com/totoshko88/RustConn https://flathub.org/apps/io.github.totoshko88.RustConn https://snapcraft.io/rustconn/

Shell Extensions

🇧🇷️ Fabito02 announces

The ChromaLeon GNOME Shell extension has received updates bringing new features, bug fixes, and improvements.

Among the recent changes are:

• Stability improvements and bug fixes: Several fixes were made, improving the overall experience and compatibility (a huge thanks to everyone who took the time to submit reports!).

• Even more customization: You can now adjust the accent color tint level in tinted style, tweaking the interface to fit your exact taste.

• More robust Hot Reload: Previously, Hot Reload for wallpaper colors was fixed and, while efficient, caused some bottlenecks in certain cases. ChromaLeon now defaults to a much safer method, while also giving you the option to disable it or switch back to the legacy method.

• Enhanced compatibility (Blur my Shell, PaperWM and others): Extensions like these apply their own styles to the panel, which ended up being overridden by tinted mode. Panel tinting is now optional to prevent these conflicts.

That’s all for this week!

See you next week, and be sure to stop by #thisweek:gnome.org with updates on your own projects!