In the past two weeks, I worked on two things:

• Squashing a rebus bug.
• Combine the two suggested words lists into one.

The rebus bug

A rebus cell is a cell that contains more than one letter in it. These aren’t too common in crossword puzzles, but they do appear occasionally—and especially so in harder puzzles.

Our word suggestions lists were not working for slots with rebus cells. More specifically, if the cursor was on a cell that’s within letters in rebus - 1 cells to the right of a rebus cell, then an assertion would fail, and the word suggestions list would be empty.

The cause of this bug is that our intersection code (which is what generates the suggested words) was not accounting for rebuses at all! The fix was to modify the intersection code to correctly count the additional letters that a rebus cell contains.

Combine the suggested words lists

The Crosswords editor shows a the words list for both Across and Down, at the same time. This is different from what most other crossword editors do, which is to have a single suggested words list that switches between Across and Down, based on the cursor’s direction.

I think having a single list is better, because it’s visually cleaner, and you don’t have to take a second to find right list. It also so happens that we have a problem with our sidebar jumping, in large part because of the two suggested words lists.

So, we decided that I should combine the two lists into one. To do this, I removed the second list widget and list model, and then I added some code to change the contents of the list model whenever the cursor direction changes.

More bugs!

I only started working on the rebus bug because I was working on the word suggestions bug. And I only started working on that bug because I discovered it while using the Editor. And it’s a similar story with the words lists unification task. I only started working on it because I noticed the sidebar jumping bug.

Now, the plan was that after I fixed those two bugs, I would turn my attention to a bigger task: adding a step of lookahead to our fill algorithm. But alas, as I was fixing the two bugs, I noticed a few more bugs. But they shouldn’t take too long, and they ought to be fixed. So I’m going to do that first, and then transition to working on the fill lookahead task.

It’s been a while, so here’s an update about Aardvark, our initiative to bring local-first collaboration to GNOME apps!

A quick recap of what happened since my last update :

• Since December, we had three more Aardvark-focused events in Berlin
• We discussed peer-to-peer threat models and put together designs addressing some of the concerns that came out of those discussions
• We switched from using Automerge to Loro as a CRDT library in the app, mainly because of better documentation and native support for undo/redo
• As part of a p2panda NLnet grant, Julian Sparber has been building the Aardvark prototype out into a more fully-fledged app
• We submitted and got approved for a new Prototypefund grant to further build on this work, which started a few weeks ago!
• With the initiative becoming more concrete we retired the “Aardvark” codename , and gave the app a real GNOME-style app name: “Reflection”

The Current State

As of this week, the Reflection (formerly Aardvark) app already works for simple Hedgedoc-style use cases. It’s definitely still alpha-quality, but we already use it internally for our team meetings. If you’re feeling adventurous you can clone the repo and run it from Builder, it should mostly work :)

Our current focus is on reliability for basic collaboration use cases, i.e. making sure we’re not losing people’s data, handling various networking edge cases smoothly, and so on. After that there are a few more missing UI features we want to add to make it comfortable to use as a Hedgedoc replacement (e.g. displaying other people’s cursors and undo/redo).

At the same time, the p2panda team (Andreas, Sam, and glyph) are working on new features in p2panda to enable functionality we want to integrate later on, particularly end-to-end encryption and an authentication/permission system.

Prototype Fund Roadmap

We have two primary goals for the Prototype Fund project: We want to build an app that’s polished enough to use as a daily driver for meeting notes in the near-term future, but with an explicit focus on full-stack testing of p2panda in a real-world native desktop app. This is because our second goal is kickstarting a larger ecosystem of local-first GNOME apps. To help with this, the idea is for Reflection to also serve as an example of a GTK app with local-first collaboration that others can copy code and UI patterns from. We’re not sure yet how much these two goals (peer-to-peer example vs. daily driver notes app) will be in conflict, but we hope it won’t be too bad in practice. If in doubt we’ll probably be biased towards the former, because we see this app primarily as a step towards a larger ecosystem of local-first apps.

To that end it’s very important to us to involve the wider community of GNOME app developers. We’re planning to write more regular blog posts about various aspects of our work, and of course we’re always available for questions if anyone wants to start playing with this in their own apps. We’re also planning to create GObject bindings so people can easily use p2panda from C, Python, Javascript, Vala, etc. rather than only from Rust.

Designs for various states of the connection popover

We aim to release a first basic version of the app to Flathub around August, and then we’ll spend the rest of the Prototype Fund period (until end of November) adding more advanced features, such as end-to-end encryption and permission management. Depending on how smoothly this goes, we’d also like to get into some fancier UI features (such as comments and suggested edits), but it’s hard to say at this point.

If we’re approved for Prototype Fund’s Second Stage (will be announced in October), we’ll get to spend a few more months doing mostly non-technical tasks for the project, such as writing more developer documentation, and organizing a GTK+Local-First conference next spring.

Meet us at GUADEC

Most of the Reflection team (Julian Sparber, Andreas Dzialocha, and myself) are going to be at GUADEC in July, and we’ll have a dedicated Local-First BoF (ideally on Monday July 28th, but not confirmed yet). This will be a great opportunity for discussions towards a potential system sync service, to give feedback on APIs if you’ve already tried playing with them, or to tell us what you’d need to make your app collaborative!

In the mean time, if you have questions or want to get involved, you can check out the code or find us on Matrix .

Happy Hacking!

The usage of Large Language Models (LLMs) has become quite popular, especially with publicly and "freely" accessible tools like ChatGPT, Google Gemini, and other models. They're now even accessible from the CLI, which makes them a bit more interesting for the nerdier among us.

One game-changer for LLMs is the development of the Model Context Protocol (MCP), which allows an external process to feed information ( resources ) to the model in real time. This could be your IDE, your browser, or even your desktop environment. It also enables the LLM to trigger predefined actions ( tools ) exposed by the MCP server. The protocol is basically JSON-RPC over socket communication, which makes it easy to implement in languages like Rust.

So, what could possibly go wrong if you gave portions of your desktop to this ever-growing AI octopus?

The implementation details

Over the weekend, I decided not only to explore building an MCP server that integrates with the GNOME desktop environment, but also to use Anthropic’s Claude Code to help implement most of it.

The joyful moments

The first step was to figure out what would be simple yet meaningful to give the LLM access to, to see:

• if it could recognize that an MCP server was feeding it live context, and
• how well it could write code around that, lol.

I started by exposing the list of installed applications on the system, along with the ability to launch them. That way, I could say something like: "Start my work environment" , and it would automatically open my favorite text editor, terminal emulator, and web browser.

Overall, the produced code was pretty okay; with some minor comments here and there, the model managed to fix its mistakes without any issues.

Once most of the basic tools and resources were in place, the LLM also did some nice code cleanups by writing a small macro to simplify the process of creating new tools/resources without code duplication.

The less joyful ones

You know that exposing the list of installed applications on the system is not really the important piece of information the LLM would need to do anything meaningful. What about the list of your upcoming calendar events? Or tasks in your Todo list?

If you’re not familiar with GNOME, the way to achieve this is by using Evolution Data Server’s DBus APIs, which allow access to information like calendar events, tasks, and contacts. For this task, the LLM kept hallucinating DBus interfaces, inventing methods, and insisted on implementing them despite me repeatedly telling it to stop — so I had to take over and do the implementation myself.

My takeaway from this is that LLMs will always require human supervision to ensure what they do is actually what they were asked to do.

Final product

The experience allowed us (me and the LLM pet) to build a simple yet powerful tool that can give your LLM access to the following resources:

• Applications list
• Audio and media status (MPRIS)
• Calendar events
• System information
• Todo list

And we built the following tools:

• Application launcher
• Audio and media control (MPRIS)
• Notifications, allowing sending a new notification
• Opening a file
• Quick settings, allowing the LLM to turn on/off things like dark style, Wi-Fi, or so
• Screenshot, useful for things like text recognition, for example, or even asking the LLM to judge your design skills
• Wallpaper, allows the LLM to set you a new wallpaper, because why not!
• Window management, allows listing, moving, and resizing windows using the unsafe GNOME Shell Eval API for now, until there is a better way to do it.

One could add more tools, for example, creating new events or new tasks, but I left the exercise to new contributors.

The tool is available on GitHub at https://github.com/bilelmoussaoui/gnome-mcp-server and is licensed under the MIT License.

Caution

Giving an external LLM access to real-time information about your computer has privacy and potentially security implications, so use with caution. The built tool allows disabling specific tools/resources via a configuration file; see https://github.com/bilelmoussaoui/gnome-mcp-server?tab=readme-ov-file#configuration

Conclusion

The experimentation was quite enriching as I learned how MCP can be integrated into an application/ecosystem and how well LLMs ingest those resources and make use of the exposed actions . Until further improvements are made, enjoy the little toy tool!

I am a long time user of the Fedora operating system. It’s very good quality, with a lot of funding from Red Hat (who use it to crowd-source testing for their commercial product Red Hat Enterprise Linux).

On Fedora you use a command named dnf to install and remove packages. The absolute worst design decision of Fedora is this:

• To install a package: dnf install
• To uninstall a package: dnf remove

If I had a dollar for every time I typed dnf uninstall foo and got an error then I’d be able to stage a lavish wedding in Venice by now.

As a Nushell user, I finally spent 5 minutes to fix this forever by adding the following to my ~/.config/nushell/config.nu file:

def "dnf uninstall" […packages: string] {
    dnf remove …$packages
}

(I also read online about a dnf alias command that might solve this, but it isn’t available for me for whatever reason).

That’s all for today!

June has been a month of deep technical work and architectural progress on my GSoC project with GNOME Papers. Here’s a summary of the key milestones, challenges, and decisions from the month.

---

�️ Architecture Overview

To better illustrate the changes, here are diagrams of the current (unsandboxed) and the new (sandboxed) architectures for GNOME Papers:

Current Architecture (Unsandboxed):

Target Architecture (Sandboxed):

---

️ Early June: Prototyping, Research & First Meeting

Note: D-Bus is a system that lets different programs on your computer talk to each other, even if they are running in separate processes.

## Flathub / Flatpak

I’ve been chatting with various folks about Flathub and Flatpak for a while now, but this week was my first chance to catch up with Sebastian Wick. It was really helpful to hear the history of Flatpak tech, understand where we sit today, and discuss how we might grow Flatpak in the near future, if we can find some funding for it.

Flathub continues to be the Linux App Store and I’ve never once experienced a Flathub failure, as a user… but I would love to see the Foundation support it more directly with acute financing. It’s such a valuable service and we need to ensure that it has the resources it requires.

## Digital Wellbeing Grant

Allan and I spent a big chunk of this week reviewing applications and interviewing candidates for the Digital Wellbeing role. We will have an announcement of the new contractor next week.

Thank you to everyone who applied! It was great to meet you all (a nice excuse to chat with some of our seemingly-infinite contributors), learn what projects you’re working on, and understand what you hope to see in the future of GNOME. There will always be more grants and the wider the base of applicants for each one, the more we can ensure we’re finding the best paid work for each contributor. So please never hesitate to apply for a role if you think your skills and experience are a good match.

## GIMP

I had a couple long and lovely conversations with Jehan, the lead of the GIMP project. The GNOME Foundation is a fiscal host for GIMP, and we’re quite happy to be. The two projects have a long and valuable history together.

We spoke about how we can improve some of our processes with respect to supporting GIMP and how GNOME and GIMP can share a little more love — in social media, in presentations (“Made with GIMP!”), and so on.

## KDE

Speaking of sharing love! I keep bumping into KDE folks here and there. They also want to spend a little more time online developing the KDE/GNOME friendship… and I’m all about it. Two great desktops, each with their own vision, providing beautiful freedom of choice to our users.

Watch this space.

## libxml2

I had a quick chat with Nick about libxml2 and the possibility of onboarding a new maintainer. If you are keen to pick up some work on serious, universally-consumed f/oss infrastructure, please do reach out.

## Framework

I got a chance to speak with Matt Hartley again (we missed our regular call when I was in New York). Maaaan, what an awesome dude. I asked him a bunch of annoying questions. He said maybe we could get some Framework laptops into the hands of GNOME devs. I told him to install GNOME OS. He had some pretty good fundraising ideas. Uh… some other stuff. Matt’s great.

## Python Foundation

I had a chance to speak to Deb Nicholson of the Python Foundation. If you ever bump into her or Loren Crary (ED and Deputy ED, respectively) please know that they have the backs of the entire f/oss community. They are both so rad, I have no words. They’ve already helped me with so many things and I’m massively grateful.

## New Treasurers

Our new Treasurer and Vice-Treasurer met our bookkeepers! It was a great meeting! I was totally useless because I’m not an accountant but I had fun listening in, in awe! haha I’m not sure if we’ll make a formal announcement for the Treasury roles, which is why I’m not naming anyone here yet.

Huge thanks to Rosanna for organizing this and getting everyone on-board. I’m really excited to see the new Finance Committee knock this out of the park.

## OSU-OSL

Oregon State University’s Open Source Lab recently had a scary financial moment, not unlike the moment the GNOME Foundation currently finds itself in. They also have a messaging challenge that’s not unlike GNOME’s: “How do you explain what the OSL is to someone who doesn’t already know?”

I had a lovely conversation with Lance from their team about how they can structure their communication such that they will find repeat revenue, year after year. They met their fundraising target for this year, but they provide services to a colossal number of free software projects and it’s essential that they don’t find themselves in the same financial position next year.

## Fundraising

It’s very important that I’m not the only one pounding the pavement and doing fundraising. You, GNOME, have a new Board on the way in. Legally, it’s part of their job (all nine of them) to help fundraise for the benefit of GNOME. I encourage you to encourage them: help them get on a podcast, a YouTube channel, in the news with your local OSPO, giving a talk at a local meetup, anything. We need more people out there in the world, talking about the maintenance and development of GNOME — and to let users know that we need their help.

We’re in this togeher. But thankfully we have a team of 10 people to get cracking, now that we have a beautiful new donation page. Thanks again to Bart, Jakub, Sam and Allan for all your help over the past few weeks.

Until next week!

Some links for technical articles on various topics I read.

std::mem is... interesting - Explore some of the functionalities in the std::mem module of the Rust standard library.

How much code does that proc macro generate? - Nicholas Nethercote tells us how you can answer this question with new tooling in the Rust toolchain.

PNG is back - A quick overview of the PNG spec 3. Spoiler: Animated PNG, HDR support and Exif support.

JavaScript broke the web (and called it progress) - How the JavaScript ecosystem is over complicated for no reason with only making the user facing stuff worse.

QtWayland 6.6 Brings Robustness Through Compositor Handoffs - Improvements in Wayland support in Qt 6.6, brought to kwin (KDE compositor), fixing some stuff that Wayland should better at than X11, but ended up being worse.

jemalloc Postmortem - jemalloc from its inception to the end.

We have a new donation page . But before you go there, I would like to impress upon you this idea:

We would vastly prefer you donate $10/mo for one year ($120 total) than $200 in one lump sum. That’s counter-intuitive, so let me explain.

First of all, cash flow matters just as much to a non-profit as it does to a corporation. If a business only saw revenue once or twice a year — say, in the form of $300,000 cheques — it would need to be very careful with expenses, for fear of one of those cheques disappearing.

And so it is with non-profits. A non-profit built on chasing grants and begging for large cheques is inherently fragile. Financial planning that is based on big, irregular revenue sources is bound to fail sooner or later. Conversely, financial planning based on monthly recurring revenue trends close to reality. The organization is more stable as a result.

Second, if your monthly donation is negligible, you probably won’t worry too much about whether you keep your donation going or not. Maybe you decide $10/mo is such a small number (the price of two coffees in any country where I’ve lived over the past 15 years) that you’re happy to keep on donating at the end of one year? Great! If not? No hard feelings. The consistency still made the $120 figure extremely valuable to us.

We want your donation to represent a number that is very comfortable for you. Personally, I make two larger (for me) donations every month. Out of my bank account in India, I donate $50/mo to a charity in Sikkim. Out of my Canadian bank account, I donate $100/mo to a charity in Nova Scotia. I have enough money available in both countries that these donations will not run out before I die. These are the two most important charities I donate to… but I’m not putting myself at risk by donating to them.

If you value GNOME, we would appreciate your support. But your comfort is essential. $50/mo is too much? Don’t stretch yourself! $25/mo or $15/mo still makes a massive difference. We’re asking all GNOME users, developers, and fans to consider supporting us in this way. (If you’re not sure if you run GNOME, it’s the default desktop on Ubuntu, Fedora, openSUSE, Debian, and Red Hat.)

GNOME brings incredible value to the world. This is how you ensure that it continues to exist.

Donate less.