Generating a Palapeli puzzle requires one to slice the image into jigsaw pieces. I had no clue how to write a good slicing algorithm for Palapeli. Several tries showed that I am not particularly good at this stuff. Because of that (and because I want more puzzles with obscure piece shapes), I made the puzzle generation extensible: You can write your own slicing plugins for Palapeli. (There’s even a tutorial on Techbase, if you are interested.)

My evil plan worked out: Johannes Löhnert has implemented a Goldberg slicer (I’m not quite sure where the name comes from.) with a plethora of tesselation types and eyecandy. What follows is a shameless (though authorized) copy from the project page:


For KDE SC 4.6, we will work on including the Goldberg slicer as the new default in Palapeli. If this is too long time for you, head over to the project page to install the Goldberg slicer.¹ It works with Palapeli 1.0 and higher.

¹ The fine print: There are only source tarballs at the moment. I tried to make RPM packages with kdeobsgenerator, but it failed with weird linking errors which I could not reproduce outside OBS.


Season of KDE (SoK) 2010 is kicking off. SoK is an annual program which makes it easy for students to enter the world of open source development: You pick a project, write a proposal, and if it is good, you will get your personal mentor who will help you on your way to completing your project. Plus, you get a certificate some nice KDE swag.

Unlike its bigger brother, Google’s Summer of Code, the rules are less strict for SoK, which allows me to offer you a chance to do a Palapeli-related project for SoK.

Palapeli is KDE’s jigsaw puzzle game. It has just seen its first stable release three months ago as part of KDE SC 4.4, and as with every new software, it is still lacking some important features. Among the most requested features is what I call “puzzle piles”: a way to organise big puzzles into piles, which can be looked at separately. Implementing puzzle piles requires both work under the hood and in the interface, and is something which should be solvable in two to three months of work.

If you are not interested in puzzle piles, you can also come up with your own ideas how to make Palapeli rock. KDE’s Bugzilla has 21 open feature requests. I’m also perfectly fine with a project proposal that implements ten small features instead of one or two big ones.

If you would like to do a SoK project for Palapeli, do the following:

  • Grab the source code from svn://, and dive into it. (Ask me if you have a hard time with compiling.)
  • Write your proposal. You should include details about
    • how you want to implement the features in code
    • what you imagine how the user interface will look like
    • yourself (your previous experience with C++/Qt/KDE, how much time you will have to work on your project)
    • a timeline (I expect a total project duration of three or four months. Divide these into chunks of a few weeks, with some explicit target, like “read pile association from savegame”.)
  • Send your proposal to until the end of next week (i.e. Sunday, 9 May 2010). We will comment on your proposal, and you are allowed to improve it and resend it within the deadline.
  • The best proposal will be picked, and you can begin to work with your mentor (which would be me most probably).
  • If you complete your project successfully, the results of your work will be merged into trunk at the end of the SoK and released in Palapeli 1.2 as part of KDE SC 4.6.

Now, after having described in detail the application process, what are the requirements? Not much. You should be familiar with C++ and Qt. Experience with Qt’s Graphics View framework will greatly improve your chances, because everything about Palapeli’s puzzle table is based on that. Also, you should have enough time for hacking this summer.

For any further questions, you may ask me personally. You find my mail address in the copyright headers of Palapeli’s source code, or in Palapeli’s About dialog.

The fine print: Even if you are not considering to take on big projects and apply for SoK, the right time to start contributing to KDE in general and especially Palapeli is right now! Write to me or to the mailing list if you are interested in hacking on Palapeli.

Anyone remembers the configuration option “Left mouse button moves viewport” from Palapeli 1.0? It has been removed earlier this month, just to return on steroids in Palapeli 1.1 (which will ship with KDE SC 4.5):

I already spoiled this big change earlier this month: Any mouse interaction with the puzzle table can now be configured to arbitrary mouse buttons and keyboard modifiers. Just click on the button with the mouse icon, hold the right modifiers, and press the right button. And here is your favorite hidden feature: If you press the space key instead of a mouse button, the interaction is assigned to “No-Button”.

For example, the “Select pieces by clicking” interaction is assigned to “Ctrl+Left-Button”. That is, if you hold the Ctrl key and left-click on a piece, it will be selected. (Multiple pieces can be selected at once this way.) If you change the trigger to “Ctrl+No-Button”, the selection will be toggled with the Ctrl key only.

To test the strengths of this new framework, I’ve implemented some new interactors: The “mouse button” page in the first image shows an interactor which allows to toggle the lock state of the puzzle table area. (When I’m not taking screenshots of the default config, I have this configured to “Alt+No-Button” here.) The “mouse wheel” page in the second image shows wheel interactors to move the viewport.

Last week, when I added rubberband selection to Palapeli, I sacrificed the “Clicking with left mouse button moves viewport” option because it conflicts with the rubberband. Knowing that more mouse actions are yet to be added, I needed a scalable solution. I found inspiration in Plasma’s ContainmentActions:

The idea for Palapeli: Separate the triggers (mouse buttons or mouse wheel orientations, and keyboard modifiers) from the actions (e.g. move piece, zoom viewport, resize scene). This was essentially what I have implemented over the last two days. This is not visible because there is no nice configuration interface such as the one shown above yet, but you can already change the hard-coded triggers in src/engine/interactormanager.cpp.

The only problem with this new approach is that I have to bypass QGraphicsView’s mouse event handlers nearly completely.

Besides that, I have greatly improved the speed of puzzle loading, and the rendering performance for big puzzles. When pieces snap together, their pixmaps are combined into one, so only one pixmap needs to be drawn. Again, this change is not visible, though I hope you notice it. 🙂

The only visible change is the new look of what is called “ConstraintVisualizer” internally: The size of the puzzle table can be changed by dragging its edges. In Palapeli 1.0, the only way to discover this feature is to notice that the mouse cursor changes into double-headed arrows near the puzzle table edges. The area where this interaction is possible is now visible as a transparent dark shade.

Nothing happened in Palapeli land since the 1.0 release together with KDE SC 4.4. The wishlist was slowly growing, but today I’ve started to implement some smaller items on the todolist. The big ones (GHNS integration, puzzle piles and rotateable pieces) are still left, but now I present you the first new features that will appear in Palapeli 1.1 (KDE SC 4.5):

This screenshot shows two closed wishlist items: Instead of a background texture, one can now also select a solid color. Also, the puzzle name is displayed in the window title. (The code is a one-liner, which I unfortunately forgot to add before the 4.4 feature freeze.)

It is now possible to select multiple pieces at once, either by holding Ctrl and clicking on the pieces, or by dragging a rubberband around the pieces. All pieces will then be moved at once when you drag one of them. The selection state is indicated by a colored shadow (according to the color scheme), which might be hard to recognize in this screenshot because the rubberband has nearly the same color.

As you might have noticed, the first nine years of this millenium are over. From a programming perspective, my last year has not been overly productive: KDiamond¹ is in maintenance mode, Kolf¹ 2 could easily win the “Most biggest KDE Vaporware” award because another major rewrite is due, only Palapeli¹ is about to have a first release after yet another major rewrite. 😉

I hope that this year turns out better. Perhaps a first version of Kolf 2 can ship with SC 4.5 (more likely 4.6), after I have cut away the 3D stuff. Palapeli 1.1 (KDE SC 4.5) will definitely bring diverse improvements in handling big puzzles, as well as lower memory and CPU time consumption. Apart from that, I have three top-secret projects for which I hope to produce first code over the next year.

Now you are probably waiting for me to tell you about my very personal move to Git. Some fellow students and I are writing our lectures in LaTeX. (Through this experience, I have become quite comfortable in writing AMSLaTeX formulas and creating TikZ drawings in near real-time.) We use Gobby during the lecture, and also synchronized and backed up our working copys through a self-written CMS on a joint webserver (LAMP config).

This solution has worked well for about two years, but has been retired this Monday, because it has some architectural issues:

  • Synchronizing the working copy with the server essentially meant downloading some tar-like archive files which contain a plain snapshot of the server’s master version. Everyone of us has written extensive Bash scripts to unpack these archives, and sort and merge the contents with the working copy.
  • Every file needed to be uploaded by hand. No mass uploading, over even a command line client. (The interface was copied heavily inspired from MediaWiki.)
  • It’s centralized and has linear version numbering. This is so 90s.
  • There were lots of funny ways to lose files, e.g. by renaming them to inaccessible names.

Enough reasons for me to finally make the switch to Git. I quickly hacked together a 200-lines QtSql application to convert the database into a Git repo, and after five minutes, I have my repo right away. Since the webserver upgrade to a vServer has not yet been ordered to host the origin/master, it currently resides elsewhere:

Myself posing with my new Git "jewelry"

If you’re interested in some sample code that shows how to convert a simple CMS database into a Git repo, post a comment. Apart from that, I’m now working on a Makefile generator for LaTeX files and SVG drawings (which I need to convert to PDF for usage with PDFLaTeX). More on that coming soon.

¹ For those who do not know it: KDiamond is a simple three-in-a-row game, Kolf is a minigolf game, Palapeli is a jigsaw puzzle game.

This is an important message to people using SVN to checkout the latest Palapeli. (All others can just skip this article.)

Before you do the next “svn update”, go to your checkout directory, delete the “*.puzzle” files in the puzzles/ subdirectory (i.e., the five ones created by You do not have to call anymore, the puzzles are now on the SVN server again.

Second, I have changed the configuration format for a last time. You know, when we say “playground”, we mean it. (Also, it’s easier to change it now when I don’t have to write complicated update scripts to keep compatibility.) So what does that mean to you?

  • Before installing the updated Palapeli version, you should do a “sudo make uninstall” to avoid orphaned data files in your system directories.
  • If you want to keep your savegames or own puzzles, do the following:
 cd $(kde4-config --localprefix)
 mv share/config/palapeli-{libraryrc,collectionrc}
 mv share/apps/palapeli/{puzzlelibrary,collection}
 sed -i 's/puzzlelibrary/collection/g' share/config/palapeli-collectionrc

Update: Thx to Matthew for reminding me of the fourth command which I forgot in the first run.