Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
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 AppearanceI 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.webmThe 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 modeAs 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.webmIn 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 MagnifierI’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 SolverFor 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:
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 WidgetI have a number of planned features for next time:
Thanks for reading!
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
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.
Read more of this story at Slashdot.
Read more of this story at Slashdot.