Planet GNOME

Jonathan Blandford asked me to do an icon set for Crosswords. What started as a request for a small group of symbolics, turned into a more flexible set of colourful sidebar icons.

Crosswords has been in the process of joining GNOME Circle for a while and hopefully this is another step in the right direction.

Icons for "Welcome", "Add Sources", and various puzzle kinds. Metaphors

We narrowed down the main categories of puzzle sources to newspapers, collections, and custom. Together with unique recolourable overlays for each kind of puzzle, it creates a cozy, rich, yet scannable sidebar to easily pick the right puzzle for the moment.

Have fun puzzling!

Introduction

The Linux desktop has an upstream maintenance problem due to many reasons for it, such as the lack of paid work. No one is entitled to a volunteer’s free time apart from the volunteer themself. This is especially true to volunteers working on upstream projects, as they are at the mercy of downstream distributions, who have the final say.

As an upstream contributor, you have no choice but to meticulously plead for any reasonable request to be granted by difficult downstreams, treating them as if they are some kind of deity. Not doing so with the utmost respect can get you on their naughty list, which they can then use against you just because the license ‘allows’ it and they can get away with it; even shamelessly use the ‘you chose the wrong license’ card when they have nothing else to add.

We have seen several instances of downstreams misusing their power while simultaneously abusing upstreams’ generosity and free time to do whatever they want. This was especially true with XScreenSaver and Debian in the past, which Debian has since changed its policies to communicate better with upstreams, and more recently Bottles, OBS Studio, and Fedora. This article is specific to an even more recent incident we at GNOME Calendar have had with Linux Mint.

Technical Definitions

There are a few technical definitions that should be understood before reading the rest of the article:

• Upstream: A group of individuals authoring software, for example GNOME Calendar.
• Downstream: A group of individuals building, curating, and redistributing these software to end users, for example Linux Mint.

The distribution model works until it impacts upstream

Distribution model refers to an established model that the Linux desktop has been practicing for decades, where an end user is expected to report issues to downstream, and, if necessary, downstream relays said issue to upstream.

The adage that users report issues to downstream holds true up until these users start reporting them to upstream without reporting to downstream beforehand. In reality, many distributions advertise themselves as user-friendly. Users of these distributions are unaware of the distribution model, so, in good faith, they report issues to upstream without ever knowing that they should be contacting downstream.

Often, downstream issues have already been resolved in previous releases; however, since these issues are being reported to upstream, upstream has to regularly triage and close these invalid issues. This creates an additional burden for them because they end up spending their limited volunteer time managing these issues when it should have been downstream’s responsibility to ensure that the user is reporting to them first.

Contacting downstream is a burden in itself

Whenever the upstream project reaches out to the hostile downstream and asks for a change, the response is usually met with the downstream bluffing by pretending to look for a solution for a nonexistent request, such as adapting the issue tracker with the implication that upstream will have to write the template(s) themselves, and then regularly update when the message is misinterpreted, just so downstream can avoid doing any actual work. That is called moving the goalposts.

If upstream objects to these ‘suggestions’, this is usually done with a shift in tone, as these one-sided discussions occur in the span of weeks, if not months, if not years, which quickly drains upstream’s remaining energy. When it shifts to a harsh(er) tone, the hostile downstream takes the easy way out by making remarks on that tone and acting like they are the only one being dignified; when they can, they end the discussion just because they do not like the tone and can use that tone to justify their (lack of) decision, without taking any appropriate action to remedy the underlying request.

As a result, they continue to mislead users into reporting issues to upstream, but this time intentionally and out of spite simply because free software licenses do not disallow abusing people’s generosity and free time. However, you will see later that this has nothing to do with free software.

Linux Mint and GNOME Calendar

For years, we have been dealing with users reporting Linux Mint’s broken packaging of GNOME Calendar to us, that were either never present or addressed releases ago.

To name a few examples:

• https://pouet.chapril.org/@parrot_33/116374864921983890(Archive)
• https://vmst.io/@doctroid/116542487573304110 (dead link)
• https://gitlab.gnome.org/GNOME/gnome-calendar/-/work_items/300
• https://gitlab.gnome.org/GNOME/gnome-calendar/-/work_items/1562
• https://gitlab.gnome.org/GNOME/gnome-calendar/-/work_items/1535
• https://gitlab.gnome.org/GNOME/gnome-calendar/-/work_items/1526
• https://gitlab.gnome.org/GNOME/gnome-calendar/-/work_items/1429
• https://matrix.to/#/!koZzDOwNHEzEoeuNok:matrix.org/$174759788212004HiyFg:gnome.org?via=gnome.org&via=matrix.org&via=fedora.im

There were a couple of discussions regarding this in the past, in chat and without my involvement, but none of them ended up being productive. Eventually, we got fed up by it and I opened ticket #1 on Linux Mint’s “gnome-calendar” repository, asking them to remove all links pointing to upstream GNOME Calendar and rebranding the app:

Remove/replace links pointing to GNOME Calendar, and update branding

Being one of the core developers of GNOME Calendar, we do not support any of the versions provided and held back by Linux Mint. We would really appreciate if you could remove or replace every link, especially support links, targeting to GNOME Calendar, as well as rebranding the app icon.

Mind you, this is the first issue ever opened in the history of Linux Mint’s package repository (8 years ago)! Based on the links above, I think it is safe to say that the app was broken throughout these years despite the lack of tickets.

This ticket had no response for six months, in other words half a year, all the while we were still getting bug reports about their broken package.

We eventually got fed up (again!) and pinged the packager. The packager replied and asked which modifications we did not like, conveniently ignoring our actual request.

So, I stated that we do not have the time to look through the code just to pinpoint specific issues, so I loosely said “everything”; then followed up by stating that the only solution to this is to rebrand or drop the package.1 (Of course, it should not be our responsibility as an upstream to pinpoint issues to downstream’s mispackaging.)

Then, the packager responded with “I reviewed the changes. None of them are problematic.”, ignoring the essence of my comment once again, and followed with a whataboutism:

[…] [GNOME Calendar] 46 and 48 are used by millions of people right now in Ubuntu LTS and Debian Stable. Are you going to request Debian and Ubuntu stop shipping GNOME apps?”

In other words: “what about Ubuntu LTS and Debian Stable?”, essentially roping Ubuntu and Debian into Linux Mint’s problem. As a bonus, they also twisted my words and changing the subject from “GNOME Calendar” to “GNOME apps”.

So, once again, I reminded that this is not what the issue is about, and Debian and Ubuntu LTS have nothing to do with this.

As a side note: no, never would we go after Debian or Ubuntu over this. If the distribution in question is doing its job properly by simply not bothering the people writing the software that they package, then why should we go after them? They are not the ones misleading users into opening in the wrong place, so there is no reason for us to be upset about. In this case, Linux Mint is leeching off of Debian, pushing their responsibility onto us, and roping Debian into their problems.

The packager then explained the following:

If we were to stop packaging GNOME Calendar, Mint users would end up with the exact same version 46 as now. You understand that? It wouldn’t magically upgrade their version of GNOME Calendar to 50+.

Very clear signs of strawman to make points against a proposal/demand that was never made, by arguing against ‘stop packaging GNOME Calendar’ rather than the original ‘rebrand GNOME Calendar’.1

Then:

Mint 22.x is built on top of Ubuntu 24.04 LTS. Packages come from both repositories. If there’s no gnome-calendar in Mint 22.x repositories, Mint 22.x users get it from the Ubuntu 24.04 repositories. The version in both repositories is 46. Removing gnome-calendar from our repositories would basically make our users switch to Ubuntu’s version, which is 46 as well.

Same goes for LMDE and Debian Stable, same principle, same bug fix, with version 48.

The only way to make it so Mint doesn’t have a frozen version of gnome-calendar would be to remove it from Debian. It would then disappear from future versions of Ubuntu and Mint which are based on it. If you got it removed from there we’d obviously oblige with your request not to re-add it and wouldn’t do so.

These are, again, unrelated problems to the essence of the request, as the request is about rebranding, not dropping the package altogether.

So, I again reminded them that this is not our responsibility as an upstream to fix their problems.

They then ‘suggested’ us to add code to check if the user is running an outdated version, and then ‘offered’ that they will patch their existing packages and potentially Debian’s and Ubuntu’s as well, essentially moving the goalposts once again. They’re expecting us to either phone home or somehow keep track of releases every six months.

If we were to phone home, we would need to cover more cases, such as bothering designers to find an appropriate way to display a warning to the user when they are not connected to the network or when the “gnome.org” domain is unreachable. This adds another dependency on the network for no reason.

This also adds more burden to translators: this is not a typical string where one needs to translate one word into another; the tone and vocabulary of a warning depends on the region, so translators need to adapt the vocabulary to ensure that the underlying meaning is not misinterpreted. In any case, I think it is fair to say that this is an absurd suggestion to a problem that has nothing to do with the upstream.

I lost my patience; I hostily replied that we as upstream do not care about how distributions operate, and, once again, reminded that all we want is for them to rebrand; a very simple request that was continuously red herred with bikeshedding, strawmen, whataboutisms, and moving goalposts.

When I posted that comment, I misinterpreted the message as I thought their ‘offer’ was them asking us to do their work, hence me stating that we do not care about how distributions operate.

The packager then replied: “If you don’t care, then neither do we.”; here, they are explicitly confirming that they do not care about Debian and the situation altogether. In a later comment, they stated: “probably requires GNOME Calendar to move away from free licenses” and locked the issue, which, once again, completely ignored the essence of this entire issue, but this time concluding with the ‘you chose the wrong license’ card.

Now, they were explicitly told what the problem was, have refused to act on it by continuing to shove their responsibilities onto us. The attitude went from doing something ‘just because they can’ to ‘that should show upstream for hurting my feelings!’, never mind the fact that we and Debian are the ones doing the hard work, which they are leeching off.

Note

If you read through the entire ticket, you may notice a part where the packager makes a comment regarding some serious accusations. This is a response to a banned user’s comment that is now deleted, who originally made these accusations.

Trademark and free software

As explained above, this actually has nothing to do with free software; rather, this is a question about trademarks: Linux Mint is allegedly2 (mis)using GNOME’s name by redistributing unsupported builds while pretending that they are supported by us, and is actively misleading users to avoid supporting them.

Offending distributions use the ‘you chose the wrong license’ card because it is simultaneously very difficult to correct them as a non-lawyer, while being looked positively throughout the free software community. However, they know very well that looking at the situation from the perspective of trademark usage rather than software licensing would make it significantly harder to defend themselves, so naturally they opt into using (the incorrect) free software licensing as a gotcha.

Tone is irrelevant

The issue itself was originally calm and straight to the point. Half a year passed by and there was no response. Then, the packager was pinged, they chimed in, and changed the subject immediately. The tone shifted, and they took the easy way out by locking the issue and misleadingly stating that this is an upstream problem for choosing the wrong license.

In other words, you have two choices:

1. You kindly ask, and nothing happens apart from your own time and energy getting wasted for a considerable amount of time, with constant red herring or silence.
2. You start acting like a ‘dick’, and now they use this as an excuse to no longer communicate with you, all the while still refusing to address the underlying issue.

As an upstream, it is a lose-lose situation with hostile downstreams such as Linux Mint and Fedora. Once they start packaging your software, they immediately burn their bridges implicitly. In order to show that they are ‘good’, they only pretend to care about the problem, and keep proposing ‘solutions’ that 1. have nothing to do with the underlying problem, and 2. put on significantly more burden to upstream without putting an equal amount of effort themselves.

The reason there are so little undocumented cases is because many maintainers who deal with hostile downstreams are usually indie-developers that have very little resources and energy to deal with these problems, and have very little to no understanding with trademarks and legality.

They get burned out, stop developing and contributing to free software, and (rightfully) lose hope for the Linux desktop. They do not make any of it public or make a fuss about the situation because they do not feel comfortable to be in the middle of a conflict publicly. All they want is to just enjoy providing goods to the world, but are unfortunately bullied by repackaging fetishists whenever they raise a legitimate issue.

Conclusion

To summarize all this, hostile downstreams have already gone as far as to burn their bridges with upstreams. Any upstream is at a lose-lose position no matter how kind or unkind they are. If they are kind, they will be on the waiting list for as long as governments put patients on the waiting list for medical care. If they are ‘rude’, hostile downstreams will use this tone against them. If upstream sends out a cease and desist letter, the free software community will start seeing them as the Nintendo of free software and conflate volunteers who are fed up with hostile downstreams, with corporations that sue every sentient being that breathes.

1. While dropping the package was mentioned, the entire essence of the issue was about rebranding it ↩ ↩2

2. For some reason, “allegedly” is a common term used in legal contexts, even when there is all kinds of evidence pointing to something ↩

Since the release of GIMP 3.2.4, we’ve been hard at work behind the scenes. We’ve been making fixes that will be included in the upcoming 3.2.6 stable release and adding tons of new features for the first 3.4 development version.

In addition, we’ve been mentoring our four Google Summer of Code (GSoC) students as they’ve been working on their projects. Since we just completed their midpoint evaluation, we wanted to share their progress with you all!

In alphabetical order:

Akascape¶

Project Description

Akascape started off their early work for GSoC by creating a new Vibrance filter in GEGL. This filter combines the existing Hue-Chroma and Saturation filters to more selectively adjust the less saturated sections of an image without increasing others. It was released in GEGL 0.4.68, so you can use it right now in GIMP!

Their main focus has been on improving the user experience with the Keyboard Shortcuts dialog. They plan to both improve usability while also adding new features.

In-progress updates to Keyboard Shortcut UI, by Akascape

Akascape’s in-progress work already includes several big improvements such as a category list to quickly jump to relevant shortcuts, the ability to import and export shortcut “profiles”, and efforts to make the dialog more friendly for a future GTK4 port.

In addition, Akascape did some early work on adding more adjustment layers to our PSD import plug-in, building off in-progress work by several contributors. His work would allow for importing Vibrance, Black & White, Photo Filter, and Exposure PSD adjustment layers.

Blezecon¶

Project Description

Blezecon has taken on the task of building the online infrastructure for a GIMP Extensions platform. Originally planned as part of GIMP 3.0, the Extensions platform would allow users to download third-party themes, brushes, plug-ins, and more via a package manager directly in GIMP. The local infrastructure has been in place for several years - this GSoC project is about developing the online submission process.

Blezecon has been working in the Extension repository and making great progress. His initial work involved cleaning up and correcting issues with the initial YAML script.

He then created a comment-based approval system in the repo. This will allow community moderators to easily inspect and approve new extensions through the same interface they use for responding to issue reports and review merge requests. Blezecon next developed a scheduler script that will monitor pending extensions, and once they have received the required approvals, automatically merge them into the Extensions repository for user access.

While infrastructure work is often not as visible to end users, Blezecon’s GSoC project is an essential effort to getting the Extensions repository up and running for future releases of GIMP!

v4vansh¶

Project Description

v4vansh did some early bugfixes and improvements in GIMP beforehand. He fixed a problem where the thumbnail wouldn’t update after changing image modes, and he corrected missing information in our manual page generation.

Since the start of GSoC, he has been focused on improving text handling in GIMP. His current big project is grouping fonts by family in the text widgets. In addition to better organization (especially with the infamous Noto fonts which have hundres of variants), this patch significantly reduces lag on systems with large numbers of fonts, as v4vansh’s mentor Liam can attest. This feature is in final testing, and we hope it will be merged into the main codebase soon!

Early UI tests for OpenType fonts, by v4vansh

v4vansh has also begun experimenting with adding support for OpenType variable fonts. This would allow for much more sophisticated font and text work in GIMP. The initial work involves exploring both the functionality and the user interface to interact with it, and both will develop further as he continues to work with OpenType fonts.

Waris Maqbool¶

Project Description

Before GSoC began, Waris contributed some early work to GIMP. He updated our OpenEXR import code to load YUV images in color instead of in grayscale. The main focus of his project though has been with GEGL, our color processing engine.

His first project was implementing a GEGL version of the Sharpen filter. Sharpen is a simpler version of the Unsharpen Mask filter, a popular method of correcting blurry images. It was unfortunately removed from GIMP 3.0 due to it not being maintained and only working on 8 bit images. Waris has created a GEGL filter of Sharpen by doing comparisons with the 2.10 version. The recreated Sharpen filter will be non-destructive and will have an on-canvas preview, both improvements over the original.

Handwritten calculations to recreate the Sharpen Filter, by Waris Maqbool

You can see the in-progress merge request for comparison. We’re doing some final reviews for optimization, but we expect it to be ready for a future release of GEGL and GIMP.

Waris has also begun working on a new Inner Glow filter for our PSD support improvement project. While GEGL already has an inner glow feature, it was not designed to be compatible with how it looks in Photoshop. As part of his work, he is also creating a generic curve editing widget to use for editing the PSD Inner Glow’s settings.

We unfortunately had more great GSoC applicants than we were awarded available spaces. One student in particular continued contributing, so we’d like to highlight their work as well.

Harsh Verma¶

Harsh has been focusing on several different areas of GIMP. His initial proposal involved improving our unit testing suite. He is currently working to implement automated UI testing for GIMP. This is a challenging task, as interacting with the UI varies across platforms. He’s already developed several tests that work on Wayland, which you can see at his in-progress merge request.

He’s also improved our contributor infrastructure that integrating CI-Fairy into our pipeline. This feature checks to make sure contributor commits follow the proper format before merging, which makes our commit history easier to read and understand.

Harsh has also been working on more user-visible changes. He recently took on a user request to add more version information to our About dialog. This follows standard practice with other software, and makes it easier for users to find information that helps us troubleshoot problems. In addition, there’s a handy Copy feature to easily grab the information for sharing. The code and UI have gone through several revisions based on developer and designer feedback, and it will likely be merged soon!

About Dialog with additional version information, by Harsh Verma

We’ve very proud of our student’s contributions so far, both in code and in community! We’re looking forward to you all getting the chance to try out their work in future development releases of GIMP, which we hope to have more information to share soon.

We take advantage of loading systemd system credentials based on smbios type 11 strings and QEMU’s vsock feature. Here is the list of recognized system credentials.

The important bit passing down the following argument to qemu

$ qemu-system-x86_64 # ... -device vhost-vsock-pci,guest-cid=$cid \ -smbios type=11,value=io.systemd.credential.binary:ssh.ephemeral-authorized_keys-all=$base64_ssh_key

libvirt allows setting smbios11 as <oemStrings> and defining virtual sockets.

Under GNOME boxes, go to the VM configuration. The important bit is setting a smbios under os, adding a vsock device and the sysinfo domain. E.g.

<domain type="kvm"> <!-- ... other domains --> <os firmware="efi"> <!-- ... other os info --> <smbios mode="sysinfo"/> </os> <sysinfo type='smbios'> <oemStrings> <entry>io.systemd.credential.binary:ssh.ephemeral-authorized_keys-all=$base64_ssh_key</entry> </oemStrings> </sysinfo> <devices> <!-- ... other devices --> <vsock model="virtio"> <cid auto="no" address="$cid"/> </vsock> </devices> </domain>

Here $cid needs to be replaced by a numerical value bigger than 2 and

$base64_ssh_key is the base64-encoded public SSH key, we use $cid=3 here. One can encode a public SSH key via

<~/.ssh/id_ed25519.pub base64 -w0

Ensure you can decode it back before proceeding!!

echo -n "output from above" | base64 -d

Then inside of the VM, verify the smbios 11 key is visible,

$ run0 systemd-analyze smbios11 io.systemd.credential.binary:ssh.ephemeral-authorized_keys-all=$base64_ssh_key… 1 SMBIOS Type #11 strings passed.

on the guest’s journal one should see:

$ run0 journalctl -b -g 'ssh.ephemeral-authorized_keys-all' Jun 18 00:11:06 gnomeos-11e6-75db systemd[1]: Received regular credentials: ssh.ephemeral-authorized_keys-all

and one can verify it via:

$ run0 systemd-creds --system list NAME SECURE SIZE PATH ssh.ephemeral-authorized_keys-all secure 97B /run/credentials/@system/ssh.ephemeral-authorized_keys-all $ systemd-creds --system cat ssh.ephemeral-authorized_keys-all

Now that everything is set, and the sshd service is running inside the VM:

systemctl enable --now sshd.service

one can ssh into the VM via:

ssh $user@vsock/$cid

where $user is the username inside of the VM and $cid as above, in my example:

ssh msandova@vsock/3

This requires systemd-ssh-proxy on the host, should be included in v257 or newer.

Note that scp has a slightly different syntax, e.g.

scp $FILES msandova@vsock%3:$PATH

Greetings!

Time for a new Crosswords release. This is a massive one with over 1,000 changes from 18 different contributors, and is the biggest release I’ve done to date! This features major improvement to the appearance of the Player, and to the usefulness of the grid filling code in the Editor.

Player: Artwork and Appearance

I made a real push this cycle to improve the appearance for GNOME Circle inclusion (tracking bug). We made almost too many usability and appearance improvements to mention! The artwork also got a major improvement with a great intro screen, new icons, and a fabulous looking “How to Play” screen. Take a look:

https://blogs.gnome.org/jrb/files/2026/07/new-art.webm

The artwork also is responsive to the libadwaita accent colors. Thanks a ton to Tobias, Hylke, and Gnoman for their fantastic work on this. It makes the game look so much more professional.

Update: Also, I have to plug Hylke’s fantastic work on improving icon’s across the whole ecosystem. I’d encourage people to sponsor him if you have the means!

Mobile mode

As part of all the work for Circle we adopted more of the recent libadwaita widgets. This basically gave us “mobile mode” for free. It’s not perfect: we’re missing some gesture support and the behavior has some quirks. I could also use more support in GTK as well — we’re missing a chunk of the expected mobile API. But for something that wasn’t worked on intentionally it’s really impressive at how well the adaptive widgetry works in libadwaita.

https://blogs.gnome.org/jrb/files/2026/07/adaptive2.webm

In addition, sp1rit did a GTK Android build of Crosswords as a proof of concept. It’s missing some crucial elements — namely python for the import pipeline — so you can’t play many games with it. But it’s amazing that it works at all.

Android version of Crosswords Magnifier

I’ve been jealous of a feature that exists in the fabulous Typesetter app, namely right clicking on the output it will bring up a magnifier. I mentioned this to Toluwaleke (of Mutter GPU Reset fame), and he quickly wrote the same for Crosswords. It looks great, and cleverly reuses the ::snapshot() method to do the zoom. It will work with the mouse, or can be toggled by the keyboard. Take a look:

https://blogs.gnome.org/jrb/files/2026/07/mag.webm Editor: Layers and the AC3 Solver

For this release, we closed one of the biggest gaps the Editor had by adding information layers to the grid. This is a little hard to explain, so a demo might help. The layers are used to indicate different challenges in building a grid, and are required for any serious crossword editor. We support the following layers:

• Spell Check: Indicates when the word in a slot isn’t in the dictionary
• Unchecked Cells: Indicates slots that are 1 or 2 cells long
• Heatmap: Warns of cells that are hard to fill
• Unfillable Cells: Indicates that there are no dictionary words that fit a slot

https://blogs.gnome.org/jrb/files/2026/07/layers.webm

The spell check and unchecked cells jobs were straightforward to implement, but the heatmap/unfillable cell jobs are not. Fortunately, GSoC student Victor wrote a Design Doc last summer to propose a way to calculate these. He ran out of summer to implement it, so I picked it up this past Spring. It took some time, but I’m really happy with the results. It’s not fast enough to be synchronous, but does run in ~200msec, which means we can run it every change. Given that some other apps we surveyed took seconds or even minutes to complete, I’m really pleased with the performance.

Additional Editor Features

EditDateRow Widget

• As part of her GSoC project, Laureen wrote EditDateRow modeled after AdwComboRow. This is much more convenient than a raw entry. We’re adding more  custom data entry rows that go with the libadwaita set. Let me know if you find this one interesting and want to use it and I’ll clean it up for general consumption.
• I had a user testing surprise, as it turned out the histogram was actually useful for setters. Certain sites won’t allow too many three letter words, and want a good letter distribution. As a result, I cleaned it up and made it more prominent.
• I’ve had a skip list for the WordList for quite some time, but it was only used for autofill. It’s now used more widely, and can save/load from disk.

Histogram What’s next?

I have a number of planned features for next time:

• I need to give the word list code a refresh. I added support for word removals but need to let users add them as well. In addition, I want a custom word list import feature.
• We will land code for the vocab puzzle GSoC project.
• There are two new GTK features I’m really looking forward to adopting: Snapping and animated SVGs. The latter is going to be amazing!
• And hopefully, I really hope that the next release is the release where we finally get into GNOME Circle. Fingers crossed.

Thanks for reading!

I am implementing a new type of crossword puzzle in GNOME Crosswords this summer. The current options are static crosswords of ‘known’ location. My project does the opposite, where it takes the words and places them wherever we can get the maximum amount of connections between the words. The pinnacle of this is a DFS backtracking algorithm because we want the words on the grid to be malleable in their placements in order to include the next word going down the list.

Previously, what I had done was attempt to erase the word letter-by-letter recursively writing NULL to each cell. However, this removed every element in the string, including the letter shared at a node between two words, leaving a gap in the word left in place.

My most current version instead focuses on state preservation. Before we even write a new word to the grid, we read the existing state of cells with focus on those connections. Now when the recursive function attempts to place a word that ends up being impossible to connect with the current setup, we look for those ‘?’ characters, erase the string, and rewrite the cushioned letter to leave the other word fully intact.

Imagine a board with CAT written across the center, and we want to place MACAW on the grid vertically. Before the algorithm writes MACAW, it inspects the board at the calculated intersection point(s) and reviews the cells of the string length.

Cell 1: Empty, Cell 2: Empty, Cell 3: C, Cell 4: Empty, Cell 5: Empty.

The board saves this state in memory using a ‘?’ in place of the empty cells as ‘? ? C ? ?’. Hypothetically this makes our board look temporarily like this in memory:

?

?

C A T

?

?

MACAW is written to the grid and then checked in the next recursive function call to ensure if it can be kept or not in that hypothetical place. If it runs successfully, we leave it as is:

M

A

C  A  T

A

W

If it returns false, we need to backtrack and erase MACAW. Rather than totally erasing the word like before, we send the ? ? C ? ? state back to our overlay function – which is responsible for writing to the grid. If it sees a ‘?’, it empties the cell. If it sees a letter, it rewrites it. That way we are only backtracking and erasing the word creating an obstacle in our program. MACAW is erased, CAT remains there for the next word to be attempted.

• Sync Miklos, Mohit, some more admin. Content marketing review, sync with Naomi, Pedro & Eloy.
• Deeply irritated to miss another appointment due to there being no possible way to get Thunderbird to actually remind you that an appointment starts ~now. Not helped (somehow) by GNOME notifications also turning up quarter of an hour+ late - completely unclear why. Spent some time writing the world's worst Thunderbird extension actually notify you of meetings.
• Out for a run with J. relaxed in the evening.