Update on what happened across the GNOME project in the week from February 20 to February 27.

GNOME Core Apps and Libraries

Calendar ↗

A simple calendar application.

Hari Rana | TheEvilSkeleton (any/all) 🇮🇳 🏳️‍⚧️ announces

Georges livestreamed himself reviewing and merging parts of merge request !598 , making the month view easier than ever to navigate with a keyboard!

This merge request introduces a coordinate-aware navigation system in the month view, which computes the coordinates of relevant event widgets and finds the nearest widget relative to the one in focus when using arrow keys. When tabbing, focus moves chronologically, meaning focus moves down until there are no event widgets overlaying that specific cell, which then moves focus to the topmost event widget found in the next cells or rows; tabbing backwards goes in the opposite direction.

To illustrate the sheer complexity of navigation in a calendaring app, here is Georges’s live reaction:

“Wow, congratulations, this is looking INSANE, Hari… The hell is going on here”

— Georges, maintainer of GNOME Calendar - https://youtu.be/smofXzVwNwQ?t=1h24m6s

Blueprint ↗

A markup language for app developers to create GTK user interfaces.

James Westman says

Blueprint 0.20.0 is here! This update includes a ton of features from many contributors. Most significantly, this release includes a linter thanks to Neighborhoodie and the STA grant. The linter catches common mistakes that go beyond simple syntax and type checking. Due to the nature of these checks, it may still have some rough edges, so please file an issue if you see room for improvement.

Also of note are a number of new completion suggestions while editing, improved type checking in expressions, and support for newer GTK features like Gtk.TryExpression.

GNOME Circle Apps and Libraries

Tobias Bernard says

Sudoku by Sepehr Rasouli was accepted into Circle! It’s what it says on the tin: A dead-simple, polished GNOME app for playing Sudoku. Congratulations 🥳

Tobias Bernard reports

Gradia by Alexander Vanhee was accepted into Circle ✨️

Edit and annotate screenshots, draw on them, add a background, and share them with the world.

https://apps.gnome.org/Gradia

Third Party Projects

Anton Isaiev says

RustConn 0.9.3 is out!

This release cycle was all about closing the gap between “it works” and “it works exactly how you’d expect.” I successfully closed every single open issue and feature request from this period, delivering major quality-of-life and security upgrades for anyone who lives in a terminal.

Highlights from this release:

Agentless Remote Monitoring: A MobaXterm-style bar now sits below your SSH, Telnet, and Kubernetes terminals, parsing /proc/* over the existing session to show live CPU, memory, disk, and network stats.

Lightning-Fast Navigation: A new Command Palette (Ctrl+P) brings VS Code-style fuzzy searching for connections, tags, and commands. I also added full support for Custom Keybindings, letting you remap 30+ actions.

Visual Organization: Tame massive connection lists with pinned Favorites, custom GTK icons or emojis, and protocol-colored tabs with group indicators (e.g., “Production” or “Staging”).

Modernized UI: Eight dialogs were migrated to modern adw::Dialog with adaptive sizing, and I’ve added screen reader support to password and connection dialogs.

Rock-Solid Security: A massive backend overhaul! Stored credentials now use AES-256-GCM with Argon2id, and the entire codebase was migrated to SecretString to prevent memory leaks. I also added full support for SSH port forwarding (-L, -R, -D).

pass Backend: A huge shoutout to community member @h3nnes for contributing a pass (passwordstore.org) backend with full GUI and CLI support!

Under the Hood: Migrated to the Rust 2024 edition, added smart protocol fallbacks for RDP/VNC to gracefully handle negotiation failures, and reached 100% translation coverage across 15 languages.

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

Haydn Trowell says

Typesetter, the minimalist, local-first Typst editor, gets some quality of life updates with version 0.11.0:

• New app icon
• The preview now automatically sizes itself to fit the window and your display without needing a manual PPI setting
• Invert lightness option for the preview when using dark mode
• The ability to simulate different forms of color blindness in the preview to test document accessibility
• Performance improvements, including reduced memory usage

Install via Flathub ( https://flathub.org/apps/net.trowell.typesetter )

Bilal Elmoussaoui announces

oo7-daemon, the server side of the Secret Service provider, has received a new release featuring KDE support. Making it compatible with both GNOME and KDE.

GNOME Websites

federico announces

The Code of Conduct page is now generated from the original sources with a beautiful stylesheet. Thanks for Bart for the web app and the design team for the updated look!

Shell Extensions

storageb reports

Build your own custom menu for the GNOME top bar!

Custom Command Menu is a GNOME extension that lets you build a custom menu to run commands directly from the top bar. Launch apps, run scripts, execute shell commands, and more through a simple, intuitive interface.

Version 13 introduces support for submenu creation, increases the maximum number of entries allowed, and adds compatibility with GNOME 50. This release also includes additional translations for Japanese, Chinese, Portuguese, and Polish.

More information can be found on the project’s GitHub page .

Miscellaneous

Sophie (she/her) reports

As a cost-saving measure, git traffic like git clone https://gitlab.gnome.org/GNOME/<repo> is now redirected to our mirror under https://github.com/GNOME/<repo> .

Peter Eisenmann says

Last week the long unmaintained support for Google Drive in gvfs was dropped. If you ever needed motivation to switch to a more privacy-respecting cloud provider, now is as good a time as any.

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!

There are a lot of prime classes, such as left truncating primes, twin primes, mersenne primes, palindromic primes, emirp primes and so on. The Wikipedia page on primes lists many more. Recently I got to thinking (as one is wont to do) how difficult would it be to come up with a brand new one. The only reliable way to know is to try it yourself.

The basic loop

The method I used was fairly straightforward:

1. Download a list of the first one million primes
2. Look at it
3. Try to come up with a pattern
4. Check if numbers from your pattern show up on OEIS
5. Find out they are not
6. Rejoice
7. Check again more rigorously
8. Realize they are in fact there in a slightly different form
9. Go to 2

Eventually I managed to come up with a prime category that is not in OEIS. Python code that generates them can be found in this repo . It may have bugs (I discovered several in the course of writing this post). The data below has not been independently validated.

Faro primes

In magic terminology, a Faro shuffle is one that cuts a deck of cards in half and then interleaves the results. It is also known as a perfect shuffle . There are two different types of Faro shuffle, an in shuffle and an out shuffle . They have the peculiar property that if you keep repeating the same operation, eventually the deck returns to the original order.

A prime p is a Faro prime if all numbers obtained by applying Faro shuffles (either in or out shuffles, but only one type) to its decimal representation are also prime. A Faro prime can be an Faro in prime , a Faro out prime or both. As an example, 19 is a Faro in prime, because a single in shuffle returns it to its original form. It is not an Faro out prime, because out shuffling it produces 91, which is not a prime (91 = 7*13).

The testing for this was not rigorous, but at least OEIS does not recognize it .

Statistics

I only used primes with an even number of digits. For odd number of digits you'd first need to decide how in and out shuffles should work. This is left as an exercise to the reader.

Within the first one milllion primes, there are 7492 in primes, 775 out primes and 38 that are both in and out primes.

The numbers with one or two digits are not particularly interesting. The first "actual" Faro in prime is 1103. It can be in shuffled once yielding 1013.

For the first out shuffle you need to go to 111533, which shuffles to 513131 and 153113.

The first prime longer than 2 digits that qualifies for both a Faro in and out prime is 151673. Its in shuffle primes are 165713, 176153 and 117563. The corresponding out shuffle primes are 151673, 617531 and 563117.

Within the first one million primes the largest in shuffle prime is 15484627, the largest out shuffle prime is 11911111 and the largest in and out prime is 987793.

Further questions

As is typical in maths, finding out something immediately raises more questions. For example:

Why are there so many fewer out primes than in primes?

How would this look for primes with odd number of digits in them?

Is it possible to build primes by a mixture of in and out shuffles?

Most of the primes do not complete a "full shuffle", that is, they repeat faster than a deck of fully unique playing cards would. For any number n can you find a Faro prime that requires that many shuffles or is there an upper limit for the number of shuffles?

In my last post on this  topic, I explained the history of SVG in GTK, and how I tricked myself into working on an SVG renderer in 2025.

Now we are in 2026, and on the verge of the GTK 4.22 release. A good time to review how far we’ve come.

Testsuites

While working on this over the last year, I was constantly looking for good tests to check my renderer against.

Eventually, I found the resvg testsuite, which has broad coverage and is refreshingly easy to work with. In my unscientific self-evaluation, GtkSvg passes 1250 of the 1616 tests in this testsuite now, which puts GTK one tier below where the web browsers are. It would be nice to catch up with them, but that will require closing some gaps in our rendering infrastructure to support more complex filters.

The resvg testsuite only covers static SVG.

Another testsuite that I’ve used a lot is the much older SVG 1.1 testsuite , which covers SVG animation. GtkSvg passes most of these tests as well, which I am happy about — animation was one of my motivations when going into this work.

Benchmarks

But doing a perfect job of rendering complex SVG doesn’t do us much good if it slows GTK applications down too much. Recently, we’ve started to look at the performance implications of SVG rendering.

We have a ‘scrolling wall of icons’ benchmark in our gtk4-demo app, which naturally is good place to test the performance impact of icon rendering changes. When switching it over to GtkSvg, it initially dropped from 60fps to around 40 on my laptop. We’ve since done some optimizations and regained most of the lost fps.

The performance impact on typical applications will be much smaller, since they don’t usually present walls of icons in their UI.

Stressing our rendering infrastructure with some more demanding content was another motivation when I started to work on SVG, so I think I can declare success here.

Content Creators

The new SVG renderer needs new SVGs to take advantage of the new capabilities. Thankfully, Jakub Steiner has been hard at work to update many of the symbolic icons in GNOME.

Others are exploring what we can do with the animation capabilities of the new renderer. Expect these things to start showing up in apps over the next cycle.

Future work

Feature-wise, GtkSvg is more than good enough for all our icon rendering needs, so making it cover more obscure SVG features may not be big priority in the short term.

GtkSvg will be available in GTK 4.22, but we will not use it for every SVG icon yet — we still have a much simpler symbolic icon parser which is used for icons that are looked up by icon name from an icontheme. Switching over to using GtkSvg for everything is on the agenda for the next development cycle, after we’ve convinced ourselves that we can do this without adverse effects on performance or resource consumption of apps.

Ongoing improvements of our rendering infrastructure will help ensure that that is the case.

Where you can help

One of the most useful contributions is feedback on what does or doesn’t work, so please: try out GtkSvg, and tell us if you find SVGs that are rendered badly or with poor performance!

Update: GtkSvg is an unsandboxed, in-process SVG parser written in C, so we don’t recommend using it for untrusted content — it is meant for trusted content such as icons, logos and other application resources. If you want to load a random SVG of unknown providence, please use a proper image loading framework like glycin (but still, tell us if you find SVGs that crash GtkSvg).

Of course, contributions to GtkSvg itself are more than welcome too. Here is a list of possible things to work on.

If you are interested in working on an application, the simple icon editor that ships with GTK really needs to be moved to its own project and under separate maintainership. If that sounds appealing to you, please get in touch.

If you would like to support the GNOME foundation, who’s infrastructure and hosting GTK relies on, please donate .

Its moments of change that remain striking in your memory when you look back. I feel like i’m in a long period of change, and if like me you participate in the tech industry and open source then you probably feel the same. It’s going to be a wild time to look back on.

As humans we’re naturally drawn to exciting new changes. Its not just the tech industry. The Spanish transport minister recently announced ambicious plans to run trains at record speeds of 350km/h. Then two tragic accidents happened, apparently due to careless infrastructure maintenance. Its easy (and valid) to criticise the situation. But I can sympathise too. You don’t see many news reports saying “Infrastructure is being maintained really well at the moment and there haven’t been any accidents for years”. We all just take that shit for granted.

This is a “middle aged man states obvious truths” post, so here’s another one we forget in the software world: Automating work doesn’t make it go away. Lets say you automate a 10 step release process which takes an hour to do manually. That’s pretty great, now at release time you just push a button and wait. Maybe you can get on with some other work meanwhile — except you still need to check the automation finished and the release published correctly. What if step 5 fails? Now you have drop your other work again, push that out of your brain and try to remember how the release process worked, which will be hazy enough if you’ve stopped ever doing release manually.

Sometimes I’ll take an hour of manual work each month in preference to maintaining a complex, bespoke automation system.

Over time we do build great tools and successfully automate bits of our jobs. Forty or fifty years ago, most computer programmers could write assembly code and do register allocation in their heads. I can’t remember the last time I needed that skill. The C compiler does it for me.

The work of CPU register allocation hasn’t gone away, though. I’ve outsourced the cognitive load to researchers and compiler teams working at places like IBM / Red Hat, embecosm and Apple who maintain GCC and LLM.

When I first got into computer programming, at the tail end of the “MOV AX, 10h; INT 13h” era, part of the fun was this idea you could have wild ideas and simply create yourself piece by piece, making your own tools, and pulling yourself up by your bootstraps. Look at this teenager who created his own 3D game engine! Look at this crazy dude who made an entire operating system! Now I’m gonna do something cool that will change the world, and then ideally retire.

It took me the longest time to see that this “rock star” development model is all mythology. Just like actual rock stars, in fact. When a musician appears with stylish clothes and a bunch of great songs, the “origin story” is a carefully curated myth. The music world is a diverse community of artists, stylists, mentors, coaches, co-writers, producers, technicians, drivers, promotors, photographers, session musicians and social media experts, constantly trading our skills and ideas and collaborating to make them a reality. Nobody just walks out of their bedroom onto a stage and changes the world. But that doesn’t make for a good press release does it ?

The AI bubble is built on this same myth of the individual creator. I think LLMs are a transformative tool, and computer programming will never be the same; the first time you input some vaguely worded English prompt and get back a working unit test, you see a shining road ahead paved with automation, where you can finally turn ideas into products within days or weeks instead of having to chisel away at them painfully for years.

But here’s the reality: our monkey brains are still the same size, and you can’t If your new automation is flaky, then you’re going to spend as much time debugging and fixing things as you always did. Doing things the old way may take longer, but the limiting factor was never our typing speed, but our capacity to understand and communicate new ideas.
“The future belongs to idea guys who can just do things”. No it doesnt mate, the past, present and future belongs to diverse groups of people whose skills and abilities complement each other and who have collectively agreed on some sort of common goal. But that idea doesn’t sell very well.

If and when we do land on genuinely transformative new tool — something like a C compiler, or hypertext — then I promise you, everyone’s going to be on it in no time. How long did it take for ChatGPT to go from 0 to 1 billlion users wordwide?

In all of this, I’ve had an intense few months in a new role at Codethink. It’s been an intense winter too — by some measures Galicia is literally the wettest place on earth right now — so I guess it was a good time to learn new things. Since I rejoined back in 2021 I’ve nearly always been outsourced on different client projects. What I’m learning now is how the company’s R&D division works.

You all know that librsvg is developed in gitlab.gnome.org , not in GitHub. The README prominently says , " PLEASE DO NOT SEND PULL REQUESTS TO GITHUB ".

So, of course, today librsvg got its first AI slop pull request and later a second one , both in GitHub. Fortunately (?) they were closed by the same account that opened them, four minutes and one minute after opening them, respectively.

I looked.

There is compiled Python code (nope, that's how you get another xz attack).

There are uncomfortably large Python scripts with jewels like subprocess.run("a single formatted string") (nope, learn to call commands correctly).

There are two vast JSON files with "suggestions" for branches to make changes to the code, with jewels like:

• Suggestions to call standard library functions that do not even exist. The proposed code does not even use the nonexistent standard library function.

• Adding enum variants to SVG-specific constructs for things that are not in the SVG spec.

• Adding incorrect "safety checks". assert!(!c_string.is_null()) to be replaced by if c_string.is_null() { return ""; } .

• Fix a "floating-point overflow"... which is already handled correctly, and with a suggestion to use a function that does not exist.

• Adding a cache for something that does not need caching (without an eviction policy (so it is a memory leak)).

• Parallelizing the entire rendering process through a 4-line function. Of course this does not work.

• Adding two "missing" filters from the SVG spec (they are already implemented), and the implementation is todo!() .

It's all like that. I stopped looking, and reported both PRs for spam.

Welcome to another GNOME Foundation update post, covering highlights from the past two weeks (this week and last week). It’s been a busy time, particularly due to conference planning and our upcoming audit – read on to find out more!

Linux App Summit 2026

We were thrilled to be able to announce the location and dates of this year’s Linux App Summit this week . The conference will happen in Berlin on the 16th and 17th of May, at Betahaus Berlin. More information is available on the LAS website .

As usual, we are very pleased to be collaborating with KDE on this year’s LAS. Our partnership on LAS has been a real success that we hope to continue.

Travel sponsorship for LAS 2026 is available for Foundation members through the Travel Committee, so head over to the travel page if you would like to attend and need financial support.

February’s Board meeting

The Board of Directors it’s regular monthly meeting last week, on 9th February. Highlights from the meeting included:

• We finally caught up on our minutes, approving the minutes from a total of nine meetings . This was a big relief, and hopefully we will be able to stay on top of the minutes now that we’re caught up.
• The Board was thrilled to formally add Nirbheek Chauhan as a member of the Travel Committee. Many contributors will know Nirbheek as a longstanding GStreamer hacker, and he’s already been doing some great work to help with travel. Thanks Nirbheek!
• The Board approved a new document retention and destruction policy , which is something that we are encouraged to have by regulators.
• I gave an update on the operational highlights from the last month, including fundraising, conference planning, and audit preparation.
• The Board considered a proposal for an exciting new program that we’re hoping to launch very soon. More details to follow soon.

The next Board meeting is scheduled for March 9th.

Audit submissions

As I’ve mentioned in previous updates, the GNOME Foundation is due to be audited very soon. This is a routine occurrence for non-profits like us, but this is our first formal audit, so there’s a good deal of learning and setup to be done.

Last week was the deadline to submit all the documentation for the audit, which meant that many of us were extremely busy finalising numbers, filling in spreadsheets, and tidying up other documentation ready to send it all to the auditors.

Our finance team *really* went the extra mile for us to get everything ready on time, so I’d like to give them a huge thank you for helping us out.

The audit inspection itself will happen in the first week of March, so preparations continue, as we assemble and organise our records, update our policies, and so on.

GUADEC 2026

Planning for this summer’s conference has continued over the past two weeks. In case you missed it, the location and dates have been announced, and accommodation bookings are open at a reduced rate. In the background we are gearing up to open the call for papers, and the sponsorship effort is on its way. Now is a good time to start thinking about any talk proposals that you’d like to submit.

Membership certificates

A cool community effort is currently underway to provide certificates for GNOME Foundation members. This is a great idea in my opinion, as it will allow contributors to get official recognition which can be used for job applications and so on. More volunteers to help out would definitely be welcome.

That’s it for this week. Thanks for reading, and feel free to ask questions in the comments.

For a few days leading up to FOSDEM 2026, the GNOME OS developers met for a GNOME OS hackfest. Here are some of the things we talked about!

Stable

The first big topic on our to-do list was GNOME OS stable. We started by defining the milestone: we can call GNOME OS “stable” when we settle on a configuration that we’re willing to support long-term. The most important blocker here is systemd-homed : we know that we want the stable release of GNOME OS to use systemd-homed , and we don’t want to have to support pre-homed GNOME OS installations forever. We discussed the possiblity of building a migration script to move people onto systemd-homed once it’s ready, but it’s simply too difficult and dangerous to deploy this in practice.

We did, however, agree that we can already start promoting GNOME OS a bit more heavily, provided that we make very clear that this is an unstsable product for very early adopters, who would be willing to occasionally reinstall their system (or manually migrate it).

We also discussed the importance of project documentation. GNOME OS’s documentation isn’t in a great state at the moment, and this makes it especially difficult to start contributing. BuildStream , which is GNOME OS’s build system, has a workflow that is unfamiliar to most people that may want to contribute. Despite its comprehensive documentation, there’s no easy “quick start” reference for the most common tasks and so it is ultimately a source of friction for potential contributors. This is especially unfourtunate given the current excitement around building next-gen “distroless” operating systems. Our user documentation is also pretty sparse. Finally, the little documentation we do have is spread across different places (markdown comitted to git, GitLab Wiki pages, the GNOME OS website, etc) and this makes it very difficult for people to find it.

Fixing /etc

Next we talked about the situation with /etc on GNOME OS. /etc has been a bit of an unsolved problem in the UAPI group’s model of immutability : ideally all default configuration can be loaded from /usr , and so /etc would remain entirely for overrides by the system administrator. Unfourtunately, this isn’t currently the case , so we must have some solution to keep track of both upstream defaults and local changes in /etc .

So far, GNOME OS had a complicated set-up where parts of /usr would be symlinked into /etc . To change any of these files, the user would have to break the symlinks and replace them with normal files, potentially requiring copies of entire directories. This would then cause loads of issues, where the broken symlinks cause /etc to slowly drift away from the changing defaults in /usr .

For years, we’ve known that the solution would be overlayfs . This kernel filesystem allows us to mount the OS’s defaults underneath a writable layer for administrator overrides. For various reasons, however, we’ve struggled to deploy this in practice.

Modern systemd has native support for this arrangement via systemd-confext , and we decided to just give it a try at the hackfest. A few hours later, Valentin had a merge request to transition us to the new scheme. We’ve now fully rolled this out, and so the issue is solved in the latest GNOME OS nightlies.

FEX and Flatpak

Next, we discussed integrating FEX with Flatpak so that we can run x86 apps on ARM64 devices.

Abderrahim kicked off the topic by telling us about fexwrap , a script that grafts two different Flatpak runtimes together to successfully run apps via FEX. After studying this implementation, we discussed what proper upstream support might look like.

Ultimately, we decided that the first step will be a new Flatpak runtime extension that bundles FEX, the required extra libraries, and the “thunks” (glue libraries that let x86 apps call into native ARM GPU drivers). From there, we’ll have to experiment and see what integrations Flatpak itself needs to make everything work seamlessly.

Abderrahim has already started hacking on this upstream.

Amutable

The Amutable crew were in Brussels for FOSDEM, and a few of them stopped in to attend our hackfest. We had some very interesting conversations! From a GNOME OS perspective, we’re quite excited about the potential overlap between our work and theirs.

We also used the opportunity to discuss GNOME OS, of course! For instance, we were able to resolve some kernel VFS blockers for GNOME OS delta updates and Flatpak v2.

mkosi

For a few years, we’ve been exploring ways to factor out GNOME OS’s image build scripts into a reusable component. This would make it trivial for other BuildStream-based projects to distribute themselves as UAPI.3 DDIs . It would also allow us to ship device-specific builds of GNOME OS, which are necessary to target mobile devices like the Fairphone 5.

At Boiling the Ocean 7 , we decided to try an alternative approach. What if we could drop our bespoke image build steps, and just use mkosi ? There, we threw together a prototype and successfully booted to login . With the concept proven, I put together a better prototype in the intervening months. This prompted a discussion with Daan, the maintainer of mkosi, and we ultimately decided that mkosi should just have native BuildStream support upstream.

At the hackfest, Daan put together a prototype for this native support. We were able to use his modified build of mkosi to build a freedesktop-sdk BuildStream image, package it up as a DDI, boot it in a virtual machine, set the machine up via systemd-firstboot , and log into a shell. Daan has since opened a pull request , and we’ll continue iterating on this approach in the coming months.

---

Overall, this hackfest was extremely productive! I think it’s pretty likely that we’ll organize something like this again next year!

It’s time for another Crosswords release. This is relatively soon after the last one, but I have an unofficial rule that Crosswords is released after three bloggable features. We’ve been productive and blown way past that bar in only a few months, so it’s time for an update.

This round, we redid the game interface (for GNOME Circle) and added content to the editor. The editor also gained printing support, and we expanded support for Adwaita accent colors. In details:

New Layout

GNOME Crosswords’ new look — now using the accent color

I applied for GNOME Circle a couple years ago, but it wasn’t until this past GUADEC that I was able to sit down together with Tobias to take a closer look at the game. We sketched out a proposed redesign, and I’ve been implementing it for the last four months. The result: a much cleaner look and workflow. I really like the way it has grown.

Initial redesign

Overall, I’m really happy with the way it looks and feels so far. The process has been relatively smooth ( details ), though it’s clear that the design team has limited resources to spend on these efforts. They need more help, and I hope that team can grow. Here’s how the game looks now:

I really could use help with the artwork for this project! Jakub made some sketches and I tried to convert them to svg, but have reached the limits of my inkscape skills. If you’re interested in helping and want to get involved in GNOME Design artwork, this could be a great place to start. Let me know!

Indicator Hints

Time for some crossword nerdery:

Indicator Hints Dialog Main Screen

One thing that characterizes cryptic crosswords is that its clues feature wordplay. A key part of the wordplay is called an “indicator hint” . These hints are a word — or words — that tell you to transform neighboring words into parts of the solutions. These transformations could be things like rearranging the letters (anagrams) or reversing them. The example in the dialog screenshot below might give a better sense of how these work. There’s a whole universe built around this.

Indicator Hint Dialog with an example

Good clues always use evocative indicator hints to entertain or mislead the solver. To help authors, I install a database of common indicator hints compiled by George Ho and show a random subset. His list also includes how frequently they’re used, which can be used to make a clue harder or easier to solve.

Indicator Hints Dialog with full list of indicators

Templates and Settability

I’ve always been a bit embarrassed about the New Puzzle dialog. The dialog should be simple enough: select a puzzle type, puzzle size, and maybe a preset grid template . Unfortunately, it historically had a few weird bugs and the template thumbnailing code was really slow.  It could only render twenty or so templates before the startup time became unbearable. As a result, I only had a pitiful four or five templates per type of puzzle.

When Toluwaleke rewrote the thumbnail rendering to be blazing fast over the summer, it became possible to give this section a closer look. The result:

Note: The rendering issues with the theme words dialog is GTK Bug #7400

The new dialog now has almost a thousand curated blank grids to pick from, sorted by how difficult they are to fill. In addition, I added initial support to add Theme Words to the puzzle. Setting theme words will also filter the templates to only show those that fit. Some cool technical details:

• The old dialog would load the ipuz files, convert them to svg, then render them to Pixbuf. That had both json + xml parse trees to navigate, plus a pixbuf transition. It was all inherently slow. I’ve thrown all that out.
• The new code takes advantage of the fact that crossword grids are effectively bitfields: at build time I convert each row in a grid template into a u32 with each bit representing a block. That means that each crossword grid can be stored as an array of these u32s . We use GResource and GVariant to load this file, so it’s mmapped and effectively instant to parse. At this point, the limiting factor in adding additional blank templates is curation/generation.
• As part of this, I developed a concept called “ settability” ( documentation ) to capture how easy or hard it is to fill in a grid. We use this to sort the grids, and to warn the user should they choose a harder grid. It’s a heuristic, but it feels pretty good to me. You can see it in the video in the sort order of the grids.

User Testing

I had the good fortune to be able to sit with one of my coworkers and watch her use the editor. She’s a much more accomplished setter than I, and publishes her crosswords in newspapers. Watching her use the tool was really helpful as she highlighted a lot of issues with the application ( list ). It was also great to validate a few of my big design decisions, notably splitting grid creation from clue writing.

I’ve fixed most of the  easy issues she found, but she confirmed something I suspected: The big missing feature for the editor is an overlay indicating tricky cells and dead ends ( bug ). Victor proposed a solution ( link ) for this over the summer. This is now the top priority for the next release.

Thanks

• George for his fabulous database of indicator words
• Tobias for tremendous design work
• Jakub for artwork sketches and ideas
• Sophia for user feedback with the editor
• Federico for a lot of useful advice, CI fixes, and cleanups
• Vinson for build fixes and sanitation
• Nicole for some game papercut fixes
• Toluwaleke for printing advice and fixes
• Rosanna for text help and encouragement/advice
• Victor for cleaning up the docs

Until next time!