The GNOME Shell user interface has mostly seen minor refinements and quality of life updates in recent cycles, but on the design side we’ve explored a lot of longer-term things we’d like to do. Some of these we have relatively complete plans for, others are more vague ideas that need more research and prototyping. As always, getting things like these implemented depends on developer capacity and interest (and sometimes funding).

While each of these ideas may require additional discussion, prototyping, and testing, we (the design team) have collected them all together here to share our longer-term vision and to give each idea more visibility.

Search

The coherent and fluid spatial model was one of our proudest achievements with GNOME 40. When you navigate GNOME Shell, interface elements always come from somewhere, and exit to somewhere else, in a way that’s semantic and predictable over time.

However, there are a few areas we’ve never been able to fully extend this ethos to. This includes GNOME Shell search, which just replaces the entire overview with search results when you start typing, with no animation or spatial model. We’ve long had the idea to switch to a more semantic layout for this, namely a search results overlay which spawns out of the search entry, above the rest of the overview. Very recently there has been some movement towards implementing this, and it’s likely that it will ship in 51 this fall.

In addition to the layout change, we’d also like to update the search results with richer types of content and actions. Other OSes and various third-party apps (Alfred, Raycast, etc.) have search with built-in file previews, multiple actions per search results, search filters, and more.

Some of this would probably require new APIs and apps to be ported to them, but there is a lot we could do here by just redesigning the existing UI.

Overlay Search Results Mockups

Editable Quick Settings

The Quick Settings pattern has seen wide adoption across all OS interfaces over the past decade, for obvious reasons: It puts a few essential pieces of information at your fingertips, and makes it easy to toggle some frequently needed system settings without going to the Settings app.

We’re quite happy with our implementation, but as we’ve added more features (dark style, night light, power modes, keyboard backlight, etc.) the quick settings menu has grown larger and larger. And there’s more: There are a number of additional, even more niche things people would like in this area, such as a way to stop the computer from sleeping (the “Caffeine” extension adds a toggle for this).

In order to accommodate all these cases, Android and iOS allow customizing this menu, allowing people to add or remove the more niche quick toggles depending on personal use. We would like to do something similar, with an inline editor as part of the menu in GNOME Shell.

Editable Quick Settings Mockups

Simplified Calendar Popover

The Calendar Popover in the top center has always been a a bit of an odd mix of things. It contains several loosely related elements that can each have wildly different amounts of content: Sometimes there are lots of notifications, but no calendar events or clocks. Some people have lots of world clocks but don’t get many notifications. Until a few releases ago we even had the Do Not Disturb switch in this popover, despite functionally being a quick setting.

Other systems (e.g. Android, Chrome OS) solve this by having the most important part of this menu (notifications) grouped with quick settings. This leaves only smaller, and less important items, which are also thematically better aligned: Calendar, events, world clocks, and weather.

This move would also group the most frequently accessed systems status items (notifications and quick settings) in a single location, rather than having them spread across two separate ones.

Notifications in Quick Settings Mockups

Simplified Calendar Popover Mockups

Drag & Drop Window Organization

During the process of experimentation and user testing leading up to GNOME 40 we also played with alternatives to the mini-workspaces in the overview. One particularly interesting concept revolved around drag & drop: Instead of having to target one of the tiny workspaces at the top, the real workspaces would scale down when you start dragging a window, allowing for larger, richer drop targets and simplifying the spatial model to a single set of representations for windows in the overview.

The specific interactions would need some refinements, but the testing we did leading up to GNOME 40 was promising, so we feel it would be worth giving this another try. In recent weeks, Cleo Menezes Jr. put together an extension testing this idea. We’re hoping to iterate on the design in the extension, and see where things go from there.

Window Drag & Drop Mockup

Mosaic & Tiling

More powerful tiling is something we’ve long wanted, but which has never quite materialized for technical reasons. More generally we’re interested in improving window management as a whole though, making it a lot less manual and fiddly. A while back we designed a concept called “Mosaic”, which auto-resizes windows to fit new windows, negotiating space between different windows’ optimal sizes. This blog post describes the concept in more detail.

There have been a number of extensions trying to implement parts of this concept over the years, but fundamentally the problem is that this would need better support in the compositor, so it can’t be cleanly done in an extension.

That said, Cleo Menezes Jr’s MosaicWM extension is currently actively maintained and implements most of the concept. As the design team we’re in touch with them, and want to continue collaborating to evaluate and refine the design further. At the same time, there is groundwork that could be laid that doesn’t depend on design (e.g. better tiling support in Mutter, richer min/max window size metadata).

Mosaic Blog Post

Window Switching

The Super+Tab / Alt+Tab switcher has long been an area we’ve wanted to improve. There is a tension between wanting to keep the list of items manageable (this is why windows are grouped by app), and the ability to switch to the last few windows quickly, regardless of what app they belong to. Most other systems either have our current app grouping approach (Apple platforms), or just expose all windows in one gigantic multi-row spread (Windows).

Our hypothesis is that there are two separate types of use cases for this UI: Quickly switching to one of the most recent windows, and switching to any arbitrary window easily with the keyboard. If this is the case, perhaps these could both be better addressed by mixing separate windows (for the most recent few windows) and grouping (for all older windows).

We have high level concepts for this, but it would need further refinements and iteration before we can say that this would be a clear improvement over the status quo. It’s potentially something that could be prototyped in an extension though, so if you’re interested in that please let us know!

Window Switcher Mockups

Login Screen Grid

This is almost a meme at this point, because it keeps almost happening every few cycles, but we still really want a more visual treatment for the login screen. The current list is not terribly ugly or problematic but it is a bit boring, and given that this is the first thing you get when booting up your computer we could do a better job welcoming people.

Login Screen Mockups

Dynamic Battery Icon

Over the years we’ve had many discussions on how to make the battery icon more expressive, and make it easier to read the status at a glance. Android and iOS both moved to a larger battery indicator that is wider than the standard square status icons. We’d like to do the same, both to be able to give people a clearer idea how much battery the device has, but also to e.g. be able to better integrate the percentage. This would be great on desktop, but especially also on GNOME Shell Mobile, where battery status is even more important and panel space is at a premium.

Dynamic Battery Mockups

Transparent Panel

Another long-awaited and discussed feature that never quite made it across the finish line is the transparent panel. The idea is simple, and most other OSes (particularly mobile ones) already do this: When the wallpaper is low-contrast and a single color, just don’t show the panel background and let the wallpaper shine through. It’s a small thing, but with the right wallpaper it’s delightful

There is a relatively complete implementation from a few years ago by Jonas Dreßler, but it needs testing, polish, and review.

Transparent Panel Mockups

How do we get there?

Some of these concepts are small and self-contained, others are huge and have been evolving for years, but they all share one thing in common: They need your help to come to life!

In some cases that’s mostly a matter of implementation. In others we’ll need more experimentation, iteration, and discussions with various stakeholders. For complex interaction changes it’s probably good to start with a rough prototype so people can try the behavior early and we can iterate on it. In other cases it would be good to first remove technical blockers to make the new designs implementable in the first place (looking at you, rounded clipping!).

In the past, GNOME Shell was significantly harder to contribute to and test than apps since you needed to use tools like jhbuild. This has changed in the past year: You can now easily build and test your branch in a nested session from Builder using Mutter Devkit. If you use GNOME OS, you can even build a sysext to install your branch on your host system. This allows daily driving experimental branches easily, which is super helpful for evaluating changes to everyday workflows.

As the design team we can only propose ideas and work with developers to make them happen. If you’re interested in helping with implementation, we’d be happy to point you to the right maintainers to talk to, and iterate on concepts together. In some cases we definitely also need to do more user research, so any help with that would also be very welcome. For any of the above, feel free to reach out in the #gnome-design channel on Matrix.

I honestly wasn’t sure I was going to make it to GUADEC.

For months, the travel committee and I had been going back and forth trying to get all the documents needed for my visa application. The visa took longer than expected. I even lost hope at some point, and eventually got it just four days before my travel date.

This was my first GUADEC, and I was really looking forward to finally meeting the GNOME community in person.

I was also going to give a talk about my Outreachy project, which was probably something I should have been more nervous about than I was.

So between getting everything ready at the last minute, travelling from Kenya to Spain, and preparing for my talk, there was quite a lot going on.

But I made it to A Coruña.

Appreciation

I want to appreciate the people who made it possible for me to be there.

A big thank you to the GUADEC organizers and volunteers for all the work they put into making the event happen. I know there is a lot of work that goes on behind the scenes, and I really appreciate the time and effort that went into making everyone feel welcome.

I also want to especially thank the travel committee. I know the visa process wasn’t straightforward, and they spent months helping me get the right documents together and working through everything with me. Getting the visa just four days before my trip made the whole process even more stressful, so I really appreciate that they didn’t give up on it.

And of course, I want to thank my mentor, Lucas Baudin, for the support and guidance throughout my Outreachy internship. Having someone to learn from and ask questions along the way made the experience much easier.

Meeting the GNOME Community

This was probably the part I was most excited about.

For months, I had interacted with people through GitLab, Matrix, emails, and meetings, and it felt so nice to finally meet them in person.

I got to meet contributors from different parts of the GNOME community, and I loved hearing about what everyone was working on. Some conversations were technical, some were about the community, and some had absolutely nothing to do with GNOME.

I came to GUADEC wanting to meet the community.

I definitely did.

Sharing My Outreachy Experience

I also got the opportunity to speak about my Outreachy project during GUADEC.

During my internship, I had been working on Papers, improving its document signing features. Most of the work happened from my laptop in Kenya, so being able to stand in front of the GNOME community and share what I had been working on felt a little strange, in a good way.

Outreachy gave me the opportunity to contribute to a project I hadn’t worked on before, but it also taught me a lot about working in an open source community.

Giving the talk was definitely one of the highlights of GUADEC for me. I was a little nervous before getting on stage, but once I started, it felt much easier than I had expected.

What I liked most was the conversations afterwards. Different contributors came up to ask questions and share their thoughts, and it was really nice to continue those conversations outside the presentation.

Learning and Sharing

Throughout the conference, I attended talks covering a wide range of topics, including GNOME development, design, accessibility, and the future of the project.

I got to learn about projects I had never come across before, which was one of the things I really enjoyed. There was always something new to discover.

I also appreciated seeing how diverse the GNOME community is, and how much the community cares about making GNOME a welcoming and inclusive space for people from different backgrounds. Coming from Kenya, it was especially nice to see people from different parts of the world coming together around the same project.

Bringing the Experience Back to Kenya

Returning home, I wanted to ensure that the knowledge and inspiration I gained at GUADEC would benefit others as well.

I recently started the GNOME Kenya community, where we hope to introduce more people to GNOME and open source contribution. We are beginning with translation efforts while also encouraging contributors to explore development, documentation, design, and other areas that match their interests.

We are also having our first meetup soon, where we will officially introduce GNOME Kenya and GNOME to the community in Kenya.

My goal is to make GNOME more accessible to new contributors in Kenya and help build a sustainable local community that contributes back to the global project.

Looking Ahead

I came back from GUADEC with a lot to think about, and even more excitement to keep contributing to GNOME.

I look forward to contributing more, supporting new contributors, and hopefully attending future GUADECs, InshaAllah!

The timeline for Google Summer of Code is coming to an end, and us interns are piecing together the final touches to our projects for submission. Thanks to the help of my mentors, and the duck sitting on my monitor, the algorithm that beats the heart of Vocab Crosswords in GNOME Crosswords has been tremendous strides in accuracy and testability. The primary focus shifted to getting the algorithm landed by the end of the summer, and working on the frontend of the application post-GSoC.

Unit Tests

At GUADEC, with the help of Federico, I created unit tests to see how my functions reacted in a given circumstance. Jonathan and I worked on creating different circumstances for the run and helper functions.

Optimization

For user optimization, we don’t want to keep the board at a strict 30×30 grid and only allow for the first viable option. We decided to incorporate a new function to trim the dimensions of the generated grids based on the outermost edges of the letters, create a new board based on the newly calculated dimensions, trim that board down respectively, and copy the words over in the exact respective format. This is due to the libipuz grid’s origin point (0, 0) being fixed at the uppermost left corner cell. All in all, the trimming function essentially does this:

Additionally, it is pretty ideal to have some leeway of choice on how you want your puzzle to look. Some puzzles might generate lanky, while others extensively branched out all the way to the maximum borders, and the rest perhaps condensed together. The ability to rearrange the ordering of the words is already a feature in Crosswords thanks to PuzzleTask. But, it is for known grids of typically 15×15 sandwiched together. What is different with the vocab puzzle is that the rearrangement must still respect the same constraints of intersecting at a single letter nodal point, words cannot be on top of nor right next to each other (edge of nodes must respect space), and no islands (all words must share at least one node with another word). For instance, grids A and B here pertain the same words 1 through 6, but these words can connect differently on the graph, producing two options to choose from.

Tested, I achieved these 3 different versions of grids based off the same word bank:

Island Checking

The final component I will implement within GSoC’s timeline is checking for islanding words. Say a user provides a list of words and one word absolutely cannot intersect with any other word, it shares no node. The backtracking algorithm will spend a lot of time trying to place it, or invalidate any graph generation at all. We want to check beforehand if a word would not belong along the rest, and warn the user about it. Because there are many alphabets that exist, we are going to analyze the sets of characters as guint64 bitsets and GHashTable. Every unique character gets its own bit-slot, and every word’s 64-bit mask is compared to available words using bit operations.

I’m happy to announce that the SparkleShare project will receive a grant from the NLnet Foundation ’s NGI0 Commons fund!

Sync files with Git

SparkleShare is a Free and Open Source collaboration app. It allows people who are not software developers or otherwise technical (designers, lawyers, students, academics, etc.) to work together and share files in projects that use the Git version control system .

SparkleShare provides an automatic sync algorithm and a friendly user interface to review changes and restore files from history.

What happened?

SparkleShare has been around since 2010 . I guess that makes it an “old” project now… Since then, the Mono/C# community active around that time has all but disbanded. The platform underneath slowly started to rot.

Eventually the app had to be removed from Flathub, also due to my own maintainer burnout. Providing maintenance and support next to a full-time job proved too much.

But that’s no longer an issue .

Now I have an opportunity to rebuild and address long-standing issues and feature requests. I have renewed energy to bring back the project better than ever!

The work

The funding proposal is to finish porting to Rust , bring SparkleShare in line with modern security and privacy practices, and design a fresh user interface informed by years worth of community feedback .

The goal is to get a Linux release back on Flathub . I’m planning to post frequent updates, so subscribe or follow me on GitHub or the Fediverse .

In these turbulent times, one frequently needs to run some tooling in a sandbox. The goal is mainly to reduce the blast radius: make it so programs within the sandbox cannot damage the host system (e.g. delete or overwrite something unintended), but also, to a lesser extent, to hide most of the filesystem to avoid exfiltrating sensitive data.

Recently, Bartosz Taudul (of Tracy fame) showed how to use systemd-nspawn for this purpose. He creates a container configuration, installs a distro inside, and bind-mounts some cache and project folders from the host. The mounts have an overlayfs on top, so within the container, tools can write over the files, but those writes do not affect the host filesystem.

I also want to share my sandboxing approach. My goal was to make it easy to use and reduce friction as much as possible, so that I always have a sandbox at my fingertips.

The result boils down to spawning a container-like environment, sharing enough of the host filesystem read-only to make all host binaries runnable, and sharing the current working directory read-write. Within this sandbox, you don’t need to install a separate distro—everything from your host just works, while the filesystem is kept mostly isolated (except for the folder where you run the sandbox).

For example, I’ll run the script in a Tracy checkout.

┌ ((8c8d451a)) ~/s/c/tracy
└─ box fish
Welcome to fish, the friendly interactive shell
Type help for instructions on how to use fish
yalter@sandbox ~/s/c/tracy>

I can run the build since all my host binaries are accessible:

yalter@sandbox ~/s/c/tracy> meson setup build
The Meson build system
Version: 1.11.2
Source dir: /home/yalter/source/cpp/tracy
Build dir: /home/yalter/source/cpp/tracy/build
Build type: native build
Project name: tracy
Project version: 0.13.1
C++ compiler for the host machine: /usr/bin/ccache c++ (clang 22.1.8 "clang version 22.1.8 (AerynOS)")
C++ linker for the host machine: c++ ld.lld 22.1.8
Host machine cpu family: x86_64
Host machine cpu: x86_64
Checking if define "_MSC_VER" exists: NO
Run-time dependency threads found: YES
Found pkg-config: YES (/usr/bin/pkg-config) 2.5.1
Build targets in project: 1

Found ninja-1.13.2 at /usr/bin/ninja
yalter@sandbox ~/s/c/tracy> ninja -C build
ninja: Entering directory `build'
[2/2] Linking target libtracy.so

The home folder contains the working directory, and is otherwise mostly empty:

yalter@sandbox ~/s/c/tracy> ls -l ~
total 0
drwx------ 4 1000 1000 80 Aug  9 20:20 source/

I can write into the home folder, but the write will go into a tmpfs, and will not affect the host system:

yalter@sandbox ~/s/c/tracy> touch ~/evil
yalter@sandbox ~/s/c/tracy> ^D
┌ ((8c8d451a)) ~/s/c/tracy
└─ cat ~/evil
cat: /home/yalter/evil: No such file or directory

Only changes to the Tracy folder, where I ran the sandbox, persisted on the host, all with correct user ID and everything:

┌ ((8c8d451a)) ~/s/c/tracy
└─ ls -l build/
total 28K
drwxr-xr-x 1 yalter yalter   48 Aug  9 20:21 libtracy.so.p
drwxr-xr-x 1 yalter yalter  496 Aug  9 20:21 meson-info
drwxr-xr-x 1 yalter yalter   56 Aug  9 20:21 meson-logs
drwxr-xr-x 1 yalter yalter  310 Aug  9 20:21 meson-private
drwxr-xr-x 1 yalter yalter   40 Aug  9 20:21 meson-uninstalled
-rw-r--r-- 1 yalter yalter 5,3K Aug  9 20:21 build.ninja
-rw-r--r-- 1 yalter yalter  545 Aug  9 20:21 compile_commands.json
-rwxr-xr-x 1 yalter yalter  14K Aug  9 20:21 libtracy.so

The box script #

I use Bubblewrap to spawn the sandbox. This is an unprivileged sandboxing tool used by Flatpak (though, I hear there are plans to replace it with something else).

The script itself composes a long bwrap invocation. Let’s look at some of the parts.

#!/usr/bin/env bash
set -euo pipefail

# Export ALLOW_NET=0 to disable network access inside the sandbox.
#
# Keep in mind that if your X11/Xwayland doesn't check Xauth,
# then network access lets the sandbox connect to your X11
# via an abstract Unix socket. This is quite dangerous.
ALLOW_NET="${ALLOW_NET:-1}"

# The current folder that we're binding read-write.
REPO="$(readlink -f .)"

BWRAP=( bwrap
  --die-with-parent
  # Unshare (isolate) a bunch of things inside the sandbox.
  --unshare-pid
  --unshare-uts
  --unshare-cgroup-try
  --unshare-user-try
  --cap-drop ALL
  # Create/mount important folders.
  --proc /proc
  --dev /dev
  --tmpfs /tmp
  --tmpfs /var
  --dir /run
  --dir /etc
  --hostname sandbox

  # Warning: this script shares all environment variables.
  # If on your system the environment can contain secrets,
  # you may want to clear them:
  # --clearenv

  # Bind the current folder read-write and chdir there.
  --bind "$REPO" "$REPO"
  --chdir "$REPO"
)

# --- Read-only system binds ---
SYS_RO_BINDS=(
  # Folders with binaries and libraries.
  /usr
  /bin
  /sbin
  /lib
  /lib64
  # Random configuration files that programs tend to need.
  /etc/alternatives
  /etc/nsswitch.conf
  /etc/hosts
  /etc/localtime
  /etc/timezone
  /etc/pki
  /etc/ca-certificates
  /etc/ssl
  /etc/crypto-policies
  /etc/fonts
  # I fill these as I bump into problems, more or less.
  /etc/java
  /etc/texlive
  /var/lib/texmf
  /usr/lib/jvm
  /usr/share/java
)
# Bind all of them read-only.
for p in "${SYS_RO_BINDS[@]}"; do
  [[ -e "$p" ]] && BWRAP+=( --ro-bind "$p" "$p" )
done

BWRAP+=( --ro-bind-try /etc/ld.so.cache /etc/ld.so.cache )

# resolv.conf is fun because it's a symlink into /run,
# a folder which we do not want to expose.
RESOLV_REAL="$(readlink -f /etc/resolv.conf 2>/dev/null || true)"
if [[ -n "$RESOLV_REAL" && -f "$RESOLV_REAL" ]]; then
  BWRAP+=( --ro-bind "$RESOLV_REAL" /etc/resolv.conf )
fi

# Unshare the network if needed.
if [[ "$ALLOW_NET" -eq 0 ]]; then
  BWRAP+=( --unshare-net )
fi

# Create a fresh home directory.
# The username and the path is the same as on the host
# so that everything keeps working.
BWRAP+=( --setenv HOME "$HOME"
         --dir "$HOME" )

# --- Home read-only binds ---
HOME_RO_BINDS=(
  .cargo/bin
  .cargo/config.toml
  .local/bin
  .local/lib/node_modules
  .rustup
  .fonts
  .local/share/fonts
  .local/share/nvim/site/parser
  .gitconfig
  .config/git
  .config/tmux
  .cache/ms-playwright
  .cache/corepack
)
for rel in "${HOME_RO_BINDS[@]}"; do
  [[ -e "$HOME/$rel" ]] && BWRAP+=( --ro-bind "$HOME/$rel" "$HOME/$rel" )
done

# --- Home overlays ---
# The sandbox can write here, but the changes
# will not affect the host filesystem.
HOME_TMP_OVERLAYS=(
  .cache/fontconfig
  .cargo/registry
  .cargo/git
  .gradle
  .npm
  .cache/npm
  .local/share/pnpm/store
  .cache/yarn
  .cache/cpm
  .texlive2023
)
for rel in "${HOME_TMP_OVERLAYS[@]}"; do
  [[ -d "$HOME/$rel" ]] && BWRAP+=( --overlay-src "$HOME/$rel" --tmp-overlay "$HOME/$rel" )
done

# Set up $PATH with the paths that we have inside this sandbox.
BWRAP+=( --setenv PATH "$HOME/.cargo/bin:$HOME/.local/bin:/usr/local/bin:/usr/bin:/bin" )

# Execute our big commandline and pass it
# the rest of the arguments (the command to run).
CMD=( "${@:-bash}" )
exec "${BWRAP[@]}" "${CMD[@]}"

Many lines, but most of them are just listing directories to mount.

If you want to run GUI apps in the sandbox, you’ll need to create an XDG_RUNTIME_DIR and mount a Wayland socket:

# Export PASS_WAYLAND=1 to enable Wayland access.
# Warning: it is currently NOT SANDBOXED (e.g. with security-context protocol).
# See https://niri-wm.github.io/niri/Security-Model.html#unsandboxed-clients
# for an example of what that implies.
PASS_WAYLAND="${PASS_WAYLAND:-0}"

# Export PASS_DRI=1 to enable DRI (GPU) access for hardware acceleration.
PASS_DRI="${PASS_DRI:-0}"

# Export PASS_X11=1 to enable X11 (Xwayland) access.
PASS_X11="${PASS_X11:-0}"

if [[ "$PASS_DRI" -eq 1 && -d /dev/dri ]]; then
  BWRAP+=( --dev-bind /dev/dri /dev/dri )
fi

# EGL complains without this.
BWRAP+=( --ro-bind /sys /sys )

# Wayland: bind only the socket into a fresh runtime dir.
XDG_RT="${XDG_RUNTIME_DIR:-}"
WAYLAND_SOCK="${WAYLAND_DISPLAY:-wayland-0}"
if [[ "$PASS_WAYLAND" -eq 1 && -n "$XDG_RT" && -S "$XDG_RT/$WAYLAND_SOCK" ]]; then
  BWRAP+=( --dir /run/user
           --dir /run/user/1000-sbox
           --bind "$XDG_RT/$WAYLAND_SOCK" "/run/user/1000-sbox/$WAYLAND_SOCK"
           --setenv XDG_RUNTIME_DIR /run/user/1000-sbox
           --setenv WAYLAND_DISPLAY "$WAYLAND_SOCK" )
else
  BWRAP+=( --unsetenv WAYLAND_DISPLAY )
fi

# X11.
DISPLAY_VAR="${DISPLAY:-}"
if [[ "$PASS_X11" -eq 1 && -n "$DISPLAY_VAR" && -d /tmp/.X11-unix ]]; then
  BWRAP+=( --ro-bind /tmp/.X11-unix /tmp/.X11-unix
           --setenv DISPLAY "$DISPLAY_VAR" )
else
  # Make it harder for accidental X11: unset DISPLAY.
  BWRAP+=( --unsetenv DISPLAY )
fi

That’s about it for the script. If needed, it’s easy to mount more folders by adding them into one of the arrays. The script doesn’t require elevated privileges to run.

Just remember that the folder where you run it is mounted read-write with the sandbox. When I want to run a dangerous command without affecting the files in the repository I’m working on, I just make a temporary copy:

project > cd ..
> git clone project project2
> cd project2
project2 > box fish
project2@sandbox > ...some dangerous command...
...
project2@sandbox > ^D
project2 > cd ..
> rm -rf project2

Another trick I recently did: I created a read-only GitHub personal access token, and automatically put it into $GH_TOKEN in the sandbox. This way, commands like gh pr list work in the sandbox without having any write access.

Conclusion #

This is very much not a polished tool, but rather a script I’ve been adding on to here and there for several months. I wanted to share it because I think it’s fairly generic (works on both Fedora and AerynOS at least), and avoids a number of pain points with other sandboxing approaches:

• no extra setup required, just one command
• no separate distro installation, uses the host system binaries and libraries directly. As a corollary, anything you build inside this sandbox will work on the host
• no manual folder binding, passes through the current folder
• paths and UID match the host, no broken file permissions
• no sudo needed

One limitation is that I haven’t been able to make podman run inside this sandbox yet. I tried once briefly, but kept hitting weird errors. Maybe it needs some capabilities exposed; not sure.

This is also obviously not intended as a bulletproof sandbox for running fully untrusted code, in fact I wouldn’t be too surprised if I left some gaping holes by mistake (please let me know if I did).

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

GNOME Core Apps and Libraries

File Previewer ↗

A previewer companion for GNOME Files.

Peter Eisenmann announces

Since its “revival”, sushi, the previewer companion for nautilus, has seen a lot of activity. This wouldn’t have been possible without the contributions and support of Tau Gärtli, who very recently also became a maintainer 🎉

Additional changes for version 51 since the last report :

• Revamped plugin API to easily expand sushi’s capabilities
• Smoother transitions between files, especially noticable for images
• Protected HTML previews with optional web content loading
• Simplified headerbar layout
• Reduced memory usage with fixed memory leaks
• Many additional bug fixes and added little niceties

You can test these changes in GNOME OS or by installing sushi and nautilus from the gnome-nightly Flatpak repository.

Peter’s work is funded by the GNOME Fellowship program. You can support the fellowship program via a donation .

Document Viewer (Papers) ↗

View, search or annotate documents in many different formats.

Lucas Baudin announces

With Papers 51.beta, it is now possible to add visual signatures to PDF documents! This was part of Malika’s internship, read more about it here .

GNOME Development Tools

Felipe Borges announces

A new implementation of GNOME Boxes (beta) is now available for general testing. It has been reworked from the ground up and has a bunch of new features in the works. You can find more about it on Felipe’s “Future of Boxes” blog post .

GNOME Fellowship

Sophie (she/her) reports

I have completed my first month of my GNOME Fellowship. You can read my full report for July 2026 on my blog.

Sovereign Tech Fellowship

Philipp Sauberzweig announces

I’ve started a blog about my design work in GNOME. Check out the introductory post , and follow the blog for regular updates on my activities during the Sovereign Tech Fellowship.

Third Party Projects

seja-arctic-fox says

Hello! This week, I released a new version of VidCom , a simple app for archiving and compressing videos.

Changes in version 0.83 include:

• Prevent logout/suspend while encoding
• Page for results reflects the encoding status better
• You can now select multiple videos in the queue by holding the Shift key
• ‘Select all’ button is no longer a toggle and can also deselect videos
• Added support for AVC (H264) encoding
• You can now open videos with VidCom. It will automatically import them into the queue upon doing so
• Custom default options can be set, such as the target size, export folder, all the exposed codec parameters and more
• bugfixes and improvements

Vidcom is currently available on Flathub and AUR. Detailed release notes can be seen here

Alexander Vanhee reports

Bazaar got its 0.9.2 update, mostly improving what happens when you’re not actively using the app. Instead of keeping the full app running, Bazaar now uses a lightweight background daemon process to handle the GNOME Shell search provider and the brand new auto-update system. This reduces the background memory footprint by at least 10 times!

Please donate to Kolunmi if you like these changes.

Ronnie Nissan reports

Hello. This week I updated two of my apps, Sitra to v0.1.3 and Embellish to v1.1.0.

Sitra:

• Installed fonts are now sorted first and have a badge indicating they are installed.
• Added Turkish translations thanks to episutv

Embellish:

Updated to NerdFonts v3.5.0, and as a consequence:

• Added two new fonts: Annotation Mono and Google Sans Code
• New icons like Obsidian and Zsh.

For now, you will have to reinstall all your fonts (expect custom fonts) to update them to the latest version, will think of a better mechanism for the next release.

Concessio is also being rewritten in Vala, making the code very clean and easier to add features and the app very fast.

See some other week hopefully 🤞

Tanay Bhomia reports

Whisp v1.4.0 - OCR Text Extraction and French Translation

Whisp is a frictionless, gesture-driven note-taking application designed natively for the GNOME desktop. It eliminates file management and save buttons entirely, acting as a rapid-capture scratchpad for passing thoughts, code snippets, and daily tasks.

This week, Whisp released version 1.4.0, introducing a powerful new feature called “Smart Paste”. By copying an image or taking a screenshot of unselectable text—like a paused video tutorial or a system dialog—and pasting it into Whisp, the app instantly extracts the embedded text. The on-device OCR engine not only grabs the words, but mathematically reconstructs the original indentation and paragraph spacing. The release also includes official French localization and several keyboard workflow refinements.

This update is perfect for developers, students, and researchers who frequently need to digitize structured text from YouTube videos, scanned PDFs, or locked interfaces without ever breaking their keyboard workflow.

github - https://github.com/tanaybhomia/Whisp website - https://tanaybhomia.github.io/Whisp/ donate - https://tanaybhomia.github.io/Whisp/donate.html

Shell Extensions

Disk_MTH reports

I’ve released Tailscale for GNOME 1.0.1, a Shell extension that brings the Tailscale VPN into the Quick Settings menu: connect and switch accounts, pick an exit node (with a panel warning when the node you picked stops routing), send and receive files over Taildrop, and publish local services with Funnel. It stays close to the platform: the file picker is the XDG portal, revealing a received file goes through org.freedesktop.FileManager1, and there’s a “Send with Taildrop” entry in the Nautilus right-click menu. With no tailscale installed it goes inert instead of breaking, and it comes back on its own once the package is there, with no reload. Available on extensions.gnome.org for GNOME Shell 49 and 50, in English, French, German and Italian. Source

Cleo Menezes Jr. says

A new version of Static Workspace Background extension is out, and now it’s even smoother. Fast switches between workspaces get a nice little bounce.

Get it on EGO: https://extensions.gnome.org/extension/8505/static-workspace-background

Events

Brage Fuglseth says

The talks from GUADEC 2026 are now available as individual clips on YouTube . Feel free to engage with the videos and share them with anyone who may find them interesting.

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!

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