Category: Uncategorized

Ongoing Work

Back in March, I started to tackle this MR for GNOME Crosswords. It allowed me to learn a lot about navigating the codebase, adhere to naming conventions, and collaborating with others involved in Crosswords.

Crosswords Editor features a section for users to input metadata, such as author name, puzzle URL, and date. Originally, the MR was to convert and store the user’s manually typed date to ISO8601. This means storing the entered date in the form YYYY-MM-DD, while the user just needs to type in a date using the GDate struct.

Upon code review, the scope expanded to move from manual typing to selecting a date on a drop-down GTK calendar widget. I was able to implement this concept by following the architecture of an existing widget (edit-shapebg.c/h/blp) which placed shapes on the crossword puzzle. Then I connected the new calendar widget to the metadata so the chosen date from the now drop-down calendar will be stored in ISO8601 format yet display respective to the locale of the person using g_date_strftime.

Project Start

With the start of GSoC, I have spent a lot of time this week reading, white-boarding, and began setting up some structure to adding vocab-style crosswords to the libipuz library.

The basic constraints and workflow that I mapped are:

• A user can input up to 30 words (strings), with a 25 character capacity.
• Upon hitting enter or a button to generate, a Depth-First Search (DFS) algorithm starts to piece the words together on a blank grid. The algorithm can backtrack to tear apart words and rearrange them until a valid graph is formed
  • I’m going with DFS at the moment to prioritize the longest-to-shortest word seeding the graph in order to increase possibilities of connections
• Every time the user generates the graph, it will be treated like its own isolated creation, recalculating the layout from scratch to allow for cleaner undo/redo states and easier addition/deletion of words
• I don’t want words being placed right next to each other unless it was intentional for a 2+ word answer, which each word would be separated by thick lines
  • Words should only connect through intersections
    • The frontend does not mutate the grid but will be able to pass actions to the backend and return a new state
    • For instance: say a user starts off their grid by typing “CAT” and then “DOG.” These words don’t have common characters, so they cannot be connected. However, instead of erasing the user’s desire to incorporate “DOG,” the string gets tucked away and saved in a GArray

• • • Now our user types and enters “CADET.” The UI takes our list and passes it to the algorithm to start chewing on and deal onto the board anew. This time, allowing for “CAT,” “DOG,” and “CADET” to appear, without the user having to retype “DOG”

I went back and forth with myself on how to represent the puzzle’s state in memory and disk. To write a custom GObject, or not.

The Argument Against: Standard IpuzCrossword objects have a handle on grids and JSON saving, and one could write a new function that takes an array of strings and return a standard IpuzCrossword.

The Argument For: Revisiting the “CAT,” “DOG,” and “CADET” conundrum; say an educator is creating a puzzle for his/her/their class, and they have just one word out of 20 that don’t connect to current existing possibilities of intersecting words. If they save their puzzle, it transforms to a standard IpuzCrossword, and the floating word are permanently abandoned.

At the current moment, I want the puzzle to be its own vocab-style workspace. Therefore this would allow for the floating word to instead sit in the sidebar and wait for further instruction for a future inserted word that works, or to get deleted.

Of course, as I gain more insight about the library, states, and optimization within the codebase, this approach is subject to refinement.

May 13th, 2026

My name is Laureen Caliman, and I am a contributor for GNOME Crosswords with Google Summer of Code 2026. Crosswords are a stimulating challenge that promotes engagement in education. Computing systems are now an indelible factor of daily life, which has raised concerns on maintaining attention, long-term memory, and reinforcement of knowledge in K-12. One study was performed in Indonesia to teach students English using crosswords. A measurable improvement in the students’ coherence to the foreign language material was seen, demonstrating benefit to their education.

Unlike traditional crossword grids which are rigidly defined, vocab-style puzzles are fitted using algorithms to shape them together. Users will have the option to edit their crossword in the Editor, and open it in Crosswords. My project entails adding the proper backend and frontend support to create vocab-style crossword puzzles.

My mentors are:

• Jonathan Blandford
• Federico Mena Quintero

About Me:

I am an incoming Computer Engineering student at Rose-Hulman Institute of Technology. I also teach K-12 computer science, so I really relate to this project’s mission about bridging software with education.

I am eager to contribute to this community and learn more about the inner workings of GNOME. I intend to continue contributing to GNOME for a long time after this project finishes!

GNOME Crosswords:

Jonathan Blandford presented an in-depth overview of the history of GNOME at GUADEC 2017, which is available to watch here. Blandford also presented Crosswords to the 2024 GUADEC here.

Crosswords consists of two domains:

• The Crosswords Editor, which is a tool to create and edit crossword puzzles.
• The Crosswords Game, which is where the user plays crossword puzzles.

My project will see to both: the editor for a user to create the puzzle, and the game platform to play it. They will also have the option to print their game in black and white using Cairo Graphics.

Technical Challenge:

Traditional crosswords have a stable grid ready for play; the vocab-style crossword will be weaving words together in the most logical way upon a blank canvas. My project focuses on building the algorithm which will take in words and distribute them to form a connected puzzle.

The biggest challenge is ensuring the program doesn’t get stuck. As it places words on the board one-by-one, it has to follow strict rules:

• The words must be interlocked and aligned.
• The whole puzzle must be connected as a single piece.
• Words cannot form gibberish with their connecting path or neighboring words.
• The grid must also not enter a permanent hangup trying to fit clashing words together.

Approach:

I will be splitting the work across the backend logic and frontend UI to make a presentable and functional puzzle.

This program will use an algorithm to deal words. Upon a rule violation, it will backtrack to find an adequate fitting by reversing itself, deleting unideal portions of the current layout, and reseeding words differently. Essentially, it places a word on the grid, tests the board with another word, and if it hits a wall, the board cleanly undoes that path until it finds another valid one. This will continue until all words are fitted together and simultaneously satisfies the constraints.

The frontend will contain stateless widgets that render with the flow of the grid. The widgets should simply read the state without mutating any data.

This trial-and-error approach will afford the program the ability to test combinations until it finds a perfectly fitting, playable crossword puzzle!

 

Currently, we are in the “Community Bonding Period” (May 1st-24th), and I have been communicating consistently with Jonathan Blandford to refine the approach and implementation. To gain practice, I have been working on this merge request for applicable practice towards my GSoC project.