On July 1st, the very first round of GNOME Fellowships started. This program finances contributors within the GNOME project through your donations . We, the fellows, will be giving you monthly updates about our work. This is the very first update from me.

Short Introduction

Hey, I’m Sophie. I have been working with GNOME technology for eight years. While I’m a physicist by trade, I have been programming for more than 20 years. You might have used apps like Pika Backup , Image Viewer , or Key Ring , which I developed, or used websites like apps.gnome.org or welcome.gnome.org that I created.

Among my goals for this fellowship are to get the image library glycin into the state that we can deprecate its predecessor gdk-pixbuf, establish new governance structures like an RFC process in the GNOME project, and explore better integration of Rust in the GNOME ecosystem.

Glycin

Glycin has already seen relatively fast adoption. One of the major reasons is that media processing code written in C is a major attack surface. In this year alone, five security issues have been reported against the gdk-pixbuf project. In the future, glycin-exclusive features like higher color-depth support, proper color space management, and HDR support will become even more relevant.

Gdk-pixbuf has switched to using glycin as the default backend on Linux for a while. This way, the attack surface is already largely reduced. However, not all distributions have adopted the option yet, and on other platforms like Windows and macOS libglycin hasn’t been available to begin with.

One feature missing from glycin that is supported by gdk-pixbuf has been support for reading and writing pixel densities from images. This feature is now available for JPEG, PNG, and TIFF images. I have also created a merge request to support this feature in gdk-pixbuf via the glycin backend.

I already added basic support for macOS and Windows, as well as other operating systems, to glycin before the beginning of the fellowship. To address a few remaining build issues on Windows and macOS for libglycin, I explored fixing them by switching the complete build process from cargo to meson. However, it turns out that the meson main branch is still lacking features to make this work. Instead, I landed a patch by Felix to work around the issues. There are still some issues remaining on Windows with the GCC instead of the MSVC compiler. If someone has experience with that, fixes are very welcome.

Here is a quick list of all the smaller changes that have landed in glycin over the last month:

• • OpenEXR images that use half-precision floats now use the same memory format in glycin, saving half of the memory compared to the previously used single-precision floats.
  • Support for the Radiance HDR format has been added.
  • The lcms2 C-library has been dropped in favor of moxcms, which is written in safe Rust and improves the performance for images with ICC profiles noticeably.
  • Internally, there is now a mechanism for a loader to report if ICC profiles or CICP (HDR instructions) should be preferred, since this differs between image formats.
  • There is now an option to disable the glycin sandbox by setting the environment variable GLYCIN_DISABLE_SANDBOX=i-know-the-risks . There is now also a test_disable_sandbox meson option to disable the use of sandboxes when running tests for build servers that don’t support sandboxing.
  • Glycin’s seccomp filter now uses a blocklist instead of an allowlist. This simplifies the feature a lot and should be sufficient since the seccomp filters are only a second line of defense behind guards like namespaces. It should also fix an issue with 32-bit apps, like Steam, calling 64-bit loaders.
  • When creating new images, glycin now supports automatically converting the provided texture memory format to a format supported by the targeted image format. This feature can be controlled via Creator::set_transform_memory_format . As a result, glycin is now aware of the supported memory formats for all image formats. This information is now available via ImageEditorConfig::creator_memory_formats .
  • Metadata support has been extended by also loading XMP data for GIF, TIFF, and WebP images.
  • On request of the Inkscape project, a new API to disable the automatic conversion of textures to sRGB if an ICC profile is present has been added, along with a new API to fetch ICC profiles. This gives apps optional manual control over color management.

Image Viewer (Loupe)

The Image Viewer is showing some of the new information that is available via the new glycin features.

If pixel density metadata is available, it is shown in DPI, as well as the calculated physical size of the image. One example where this is particularly useful is scanned photos where the information is automatically added.

The used color profile, either ICC profile or CICP data, will also be shown.

RFC Proposal Draft

I have posted my first draft of a proposal for an RFC process within the GNOME project. Previously the document went through several iterations with the goal of striking a balance between making the decision process robust and avoiding stalls, while also not making it too complicated and bureaucratic. The initial discussion about the proposal is now taking place. For more information on why we are working towards better governance structures, I suggest reading Emmanuele’s original post .

Support the GNOME Project

The GNOME Fellowships are funded by our community. If you would like to help the GNOME project to stay sustainable, please consider donating .

C API and Introspection

I spent some time cleaning up the Rust C extension and the FFI layer to make it easier to consume from C and through GObject Introspection. One of the biggest changes was exposing the PitiviTimelineRuler instance type in the public headers instead of treating it as a generic GtkWidget. That gives GIR enough information to generate proper bindings automatically.

I also fixed an issue that only showed up in headless CI environments. The widget was previously relying on gtk::init() during type registration, which doesn't work well without a display server. Switching to set_initialized() solved the problem and made the test suite much more reliable.

Rendering Improvements

The rendering code also received a fairly large cleanup. Previously, the widget stored several pieces of drawing state separately, including adjustments, cached Pango layouts, and font descriptions. These have now been grouped into a single DrawingState struct protected by one RefCell.

Besides making the code easier to reason about, this reduces unnecessary borrow checks during rendering and avoids situations where only part of the drawing state could be updated while signals were being emitted.

I also introduced a labels_dirty flag so timeline labels are only recalculated when they're actually needed during the snapshot phase. That removes quite a bit of redundant layout work while scrolling and zooming.

Timeline Marker API

The custom layout manager is nearly finished, and with it comes a much simpler way to place widgets on the timeline.

I am currently wrapping up an add_marker() API that will allow attaching any GTK widget to the ruler at a specific timestamp. The PitiviTimelineLayoutChild now exposes the widget's timestamp as a GObject property.

I'm looking forward to getting this merged, as it should make timeline overlays and markers much easier to implement.

Stability Fixes

I also addressed a few smaller edge cases along the way. One of them involved enforcing a minimum value for min_tick_spacing_px, preventing potential divide-by-zero errors when calculating the tick spacing.

Week 28

This week's icon is for René Fouquet 's project:
Stencil : "Rename batches of files"

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!).

Hey, I’m Philipp. I’m a GNOME Design Team member and I have been contributing to GNOME design as a volunteer for several years. I’m excited to share with you that I have joined the Sovereign Tech Agency as a fellow for GNOME Design & Community Management. Check out the other fellows in the official announcement .

Introduction

I originally started contributing to GNOME to improve the software I use myself. However, what motivates me to stay involved long-term are my political values. Our modern lives, from communication and education to political discourse, are shaped by digital tools, and I believe that it’s essential for a free and democratic society to ensure free and independent access to these technologies. To achieve this goal, end-user devices based on free and open-source software are key, and the GNOME desktop and its app ecosystem offer a powerful alternative to proprietary platforms.

In recent years, I have had the privilege of joining the exceptionally skilled and motivated GNOME community as a volunteer, and have experienced how rewarding it is to contribute to a project with such a broad societal impact. At the same time, it’s been a challenge to find a balance between my job, my contributions to GNOME, and my personal life. I’ve contributed to GNOME in my free time, in the evenings, and during vacations. This two-year fellowship is a great honor and marks a significant change in my life. It is a unique opportunity for me to devote my skills and experience entirely to a project I strongly believe in.

Activities

During my two-year fellowship, I will support GNOME maintainers and developers with design feedback and reviews, create mockups, and coordinate efforts to standardize design patterns. My other activities focus on lasting improvements through two strategic initiatives: expanding the design community to increase capacity and enhancing our design tooling to reduce overhead and simplify onboarding. The following activities may change over the course of the two-year fellowship, as I will adapt them to the needs of the community.

Community growth

I know from my own experience that it is hard to get started with GNOME design. While code contributions are often contained within the boundaries of a single app, design activities spread across multiple projects and often lack a clear entry point or primary contact. Also, not all tasks are newcomer friendly and many require cross‑project knowledge or historical context. I want to make design work more discoverable, simplify onboarding with clear contribution paths and approachable tasks, and retain contributors long term by integrating them into the community.

To attract new contributors, I will increase the visibility of design work by writing regular blog posts, giving presentations, and running workshops at conferences and hackathons. New contribution opportunities for newcomers will be created with clear instructions for independent activities such as collecting state‑of‑the‑art examples, running accessibility and user tests, and creating mockups. Design reviews will be used as mentorship opportunities, pairing regular design contributors with experienced designers for peer review and knowledge sharing. I plan to improve our team governance with clear membership criteria and focus areas, and integrate sustained contributors into the team and its processes. Finally, I want to provide grant writing support to enable contributors to sustain their contributions long-term.

Tooling improvements

User interface mockups are an important tool to communicate with developers. Outdated mockup templates, incomplete documentation, and non‑specialized software create unnecessary overhead, especially for newcomers. Therefore, I will extend and update the mockup templates for our current tool, Inkscape, and evaluate the open‑source UX design tool Penpot for managing our design system. If it proves suitable, I will build a component library to simplify mockup creation and keep assets synced with our stylesheet.

What’s next

I want to blog about my fellowship activities and design work in general, so expect regular updates here. If you’re interested in contributing to GNOME design, check out the Design Team page on the Welcome to GNOME website, familiarize yourself with the Human Interface Guidelines , and join our Matrix channel . If you’re a GNOME developer feel free to reach out to me via Matrix and involve me in design reviews.

Week 27

This week's icon is for Zach Leytus 's project:
KawaiiFi : "Wi-Fi scanner and analyzer"

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!).

Week 26

This week's icon is for Sjoerd Stendahl 's project:
Lockpicker : "Recover passwords from their hash"

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!).

I’m pleased to announce that NVIDIA is now supporting the LVFS as a premier sponsor .

The rollout of the NVIDIA DGX Spark firmware using fwupd is going very well indeed, with downloads continuing to increase every day.

This now takes us to 4 OEMs sponsoring LVFS, which means we’ve successfully reached the funding target we set for ourselves last year. More exciting announcements coming soon!

I have spent the last two years rebuilding GNOME Boxes from the ground up, driven by three main factors. I spoke extensively about this effort in my recent Linux App Summit , GUADEC 2025 and 2026 talks , but today I am excited to share the result for general testing.

First, shifting to a Flatpak -first (and only) model. As a solo developer, maintaining code paths for countless distributions isn’t sustainable. Since Boxes acts as a frontend for libvirt/qemu, its functionality relies heavily on the backend configuration. Flatpak lets me bundle the entire virtualization stack, giving me the control I need to fine-tune it for our specific use cases.

Second, migrating Boxes to GTK4 and Libadwaita. Beyond the obvious benefits (a modern UI, better responsiveness, and tighter desktop integration) this makes the codebase significantly easier to maintain. This transition required moving away from the GTK3-based SPICE display widget, which was too tightly coupled to older input and drawing methods. We’ve replaced it with Libmks , which has proven to be a solid alternative.

Lastly, modernizing the codebase to make it sustainable for new contributors. That meant adopting modern GNOME app design patterns and rethinking our underlying architecture.

I am now ready to share this work with a wider audience. However, please keep in mind that this is a Beta release meant for testing, not for production environments. If you plan to try it out, make sure to back up any important data in your virtual machines first.

If you want to test this new implementation of GNOME Boxes, you can set up the GNOME Nightly Flatpak Repository and install it with:

flatpak install org.gnome.Boxes.Devel

This new version already covers most of what the classic Boxes could do: creating virtual machines from ISO media and disk images ( qcow2 ), configuring VM resources, sharing clipboard content, sending files to the guest, and more.

It can install Windows 11 without any manual workarounds . Boxes configures Secure Boot and a virtual TPM device automatically. Everything required to pass the Windows 11 hardware compatibility checks out of the box. This was the most requested feature for the classic version, so I am particularly glad it is fully functional in this rewrite.

As distributions shift toward image-based OSes, this Flatpak-only approach becomes even more valuable. Most other virtual machine managers rely on host services or privileged daemons that are difficult to configure on immutable systems. While hardware and host combinations vary, bundling the backend stack directly inside the Flatpak gives us a controlled baseline that we can actively support, configure, and refine over time.

Accessing VM contents used to be tricky due to Flatpak sandboxing. This version addresses that by introducing a VSOCK device to the box, allowing guests with systemd v256 or newer to be accessed directly over SSH. It also adds initial support for port forwarding , letting you reach services running inside the VM from your host.

All of this and more is detailed on our new website, nightly.gnomeboxes.org , where you can also learn how to help by testing and reporting issues.

Please keep in mind that I am working on this in my free time alongside maintaining GNOME Settings and my day-job responsibilities at Red Hat. I ask for your patience with issue responses , but I will do my best to address bugs and keep pushing feature development forward as time allows.

I love building GNOME Boxes, and I am constantly motivated by the positive feedback from our community. People appreciate Boxes because it lets them set up a VM quickly and get straight to work without needing deep knowledge of virtualization or operating system internals. That remains the core mission, and that is the user experience I want to continue building for.

A lot of this implementation will still change as I gather feedback and it matures. I have also drafted a series of follow-up blog posts to this one, which will describe and elaborate a bit more on the new features, explaining how to use them and how they have been implemented. Stay tuned!

Comments

We just merged the visual signature UI into Papers (GNOME Document Viewer), developed by Malika Asman during her Outreachy internship (funded by the GNOME Foundation ).

Compared to digital signatures, visual signatures do not require a cryptographic certificate. As such, they do not really guarantee the authenticity of a signed document, but they are still widely accepted or required (e.g. in administrative documents).

Here are a few screenshots, the two first ones are context menus that are shown when doing a right click on the document, the third one shows the drawing dialog.

It is possible to import an image file instead of drawing the signature in Papers. Malika implemented a background removal step so that signatures don't look like a plain picture on the document. This is done using the imageproc crate which implements Otsu's method (for those wondering, there is no neural networks or models involved). This gives good results on our test files, let's take for instance this cute GNOME contributor by Jakub : Once it is imported, the background is correctly removed and we can add this perplexed GNOME contributor to our PDFs:

Note that this is still a rather simple method, so we don't expect it to work in every case. If you have a file that can not be imported properly, please open an issue!

And digital signatures?

These new visual signatures cannot be used directly with digital signatures, but there are plans (and code) to extend the existing digital signature dialog to let users customize the way the signature is drawn on documents, including using one of the visual signatures.

There are other features that did not make it into this release, including the ability to copy/paste visual signatures, those will be for the next cycle!

Papers 51.beta

This is part of Papers 51.beta, there are a few other improvements and bug fixes, including a fix for fractional scaling taking advantage of latest GTK snapping API, read the news here .