Stories of a KDE programmer

Just a quick notice for anyone out there who builds Palapeli from SVN: It does now officially require Qt 4.6. I’m in the process of cleaning up the animation code, and esp. the new QGraphicsObject class in Qt 4.6 helps me very much in this regard.

Update: I’ve also updated the Palapeli compilation guide. If you’ve used this guide to build a Palapeli from SVN, please do the following in the “build” directory:

sudo make uninstall

Then delete everything and use the guide to create a new checkout. Stuff has changed too much. Please note that the new guide makes you install Palapeli into the standard system directories. This should work around the problems people are having with slicers not found etc.

2nd update: By the way, I’ve also changed the puzzle file format. Instead of BZip2 compression, I’m now using GZip because this reduces loading time on my system by about one second for a medium-sized puzzle. (File size is about the same.) If you’re having problems with puzzles that don’t load (sorry for the missing messagebox that tells you when a puzzle file is broken), rerun the make-puzzles script and “sudo make install” everything again. This should fix your problems.

In the last two weeks, I’ve added quite some features to Palapeli which are hard to impossible to show with screenshots, so I’ve decided to make a screencast for the very first time. recordmydesktop worked quite well, and I found a microphone in one of my junk boxes.

Hm, it seems like WordPress.com does not like embedded flash objects, so you’ll have to use the link to the 1st Palapeli screencast.

I’m searching for possible ways to improve the user experience of Palapeli’s puzzle table. Problem: I do not know which features would help the users. Solution: Ask them (i.e., you).

After all, Palapeli is about replicating in virtuality a game that exists in reality. Everybody who plays a jigsaw puzzle on his PC will automagically try to use the same techniques and tactics which he uses to solve jigsaw puzzles in reality. For example, it is very common to search for edge pieces first.

Do you have other techniques? If yes, please don’t be shy, and leave a comment. I want to map as much as possible of your techniques to convenience features in Palapeli.

Update: A first summary. Most people say that, apart from searching for edges, they’re looking for pieces with similar colors and by level of detail. As one commenter puts it, “it all boils down to divide-and-conquer”.

Also, there has been quite some feedback on the puzzle table. Because quite some stuff occurs multiple times, I find it easier to answer them once here:

• People are concerned about how zooming is implemented, and how pieces are limited to an certain area. I’m concerned, too. It’s becoming more and more obvious that we need a better solution, and I’ll see what I can do about this.
• An annoying “feature” of Palapeli is that pieces are spit out randomly at the beginning, and one has to clear a part of the puzzle area to get some space for the actual image. I’ve made a quick hack-style fix for this: The pieces are now distributed only on one half of the puzzle table. A better solution will appear when the zooming stuff improves.
• Some people would like to change the background texture. That’s possible: Right-click on the puzzle table. As you see, this is extremely non-obvious, I’ll put this interface into the Settings menu very soon.
• The request for rotating pieces has occurred quite often. I’m generally positive towards it, because it gives a nice and easy way to introduce a difficulty parameter.
• Some want a preview of the picture. I have a nice idea for this, but this will strongly correlate with some other features which I cannot add before KDE 4.5.

Thanks for your input. I’m currently collecting input from various sides (the kde-games-devel mailing list is also quite active currently), and evaluating possible solutions to your requests.

Since starting to rewrite Palapeli (three weeks ago), it was not possible anymore to create new puzzles. This last and most important feature is now back again.

Proof that the last missing feature has been added

And here’s a call for participation: The layout of the puzzle creator dialog (which comes up when you click that button) is far from optimal. Please try Palapeli, create some puzzles, and if you can come up with a better design for this dialog, please write back. Thanks in advance!

I was uncomfortable with the current way of starting puzzles for quite a long time. The old list view had a play button and the piece count displayed at the right, so if you had the Palapeli window maximised (which is a good idea for playing), the play button is very far away from the description and thumbnail. Fitt’s law says that’s not a good idea. I hope that the new way is a good idea: The thumbnail turns into a play button when you hover the puzzle item.

New Palapeli puzzle list (first item is selected, second item is hovered, i.e. the mouse cursor is over it)

Because people always ask when I forget to make it clear: Palapeli is a jigsaw puzzle game which I’m preparing for KDE 4.4. Now that we have that out of the way:

Today, I’ve spent hours to break Palapeli, put the pieces together again (puzzle pun intended), and take care that it does the same things as before. Such activities appear quite senseless to outsiders, but programmers know that this is necessary from time to time.

They call it “refactoring”.

Of course, I have a bigger aim. Currently, the only source of puzzles is the local library, but I want to make more sources accessible. “Within the reach of your fingertips”, like some people describe it. For this initiative, I’ve chosen the buzzword “social puzzling”. Actually, what I want to do, is quite similar to KNewStuff, but I’m not completely sure whether KNewStuff provides all the technical foundation that I need. (If it is the case, the current architecture of Palapeli allows to add KNewStuff integration later on.)

My plan: The current puzzle library is basically a list of puzzles (or, more detailed, a list of URLs to puzzle files and a metadata cache). A list of puzzles could be provided anywhere, also on remote sites, as a type of “puzzle feed” (similar to a RSS feed). Such puzzle feeds can already be read by the Palapeli::ListCollection class, but there is no interface yet to display and use them. This is because I’m not sure about the best way to present them to the user.

So what is certain by now? Palapeli 1.0 will ship with puzzle feed functionality, though it will be hidden a bit. It’s not sure how puzzle feeds will be generated on the server side. And it’s not clear yet for what we’ll be able to use this functionality at the end of the day. It’s a big experiment, and I’m quite excited about it.

Yet again, a commenter on my blog gave me a hint for a nice extra feature. Palapeli now has a new zoom widget, which allows to seamlessly adjust the zoom level.

Seamless zooming in Palapeli

Someone has already asked on this blog yesterday, and thereby pushed me to actually implement them: library transactions in Palapeli. These include import/export (copy puzzle files to and from the library), and deletion (remove puzzle files from the library). The screenshot below illustrates where you can find these actions:

Library transaction toolbar in Palapeli

Note though that knowing where these actions are won’t help you much currently. There are exactly 5 Palapeli puzzles in the world, and these are the default library. You cannot import those puzzles (because Palapeli uses puzzle identifiers, which need to be unique), and exporting/deleting puzzles from the default library is not allowed for obvious reasons (exporting default puzzles is pointless, and deleting default puzzles could damage the installation if you have write access to the install prefix).

The last missing piece in Palapeli (pun intended) is the puzzle creator, which will (like it once already was) allow you to create Palapeli puzzles from arbitrary images. I hope that I get this last piece done during the next week. This weekend, you can find me in the audience of this year’s Datenspuren (a conference on privacy and stuff, the name is German and means “data tracks”).

Because of Friedrich’s continued poking, I’ve looked into solutions for the “let pieces drop shadows” problem. Here is a first proof of concept:

New shadows and jigsaw pieces in Palapeli

I’ve decided against generating the shadows together with the puzzle, and saving them in the puzzle file, because this would have doubled the size of the puzzle files (which are already bigger than I wanted them to be). Unfortunately, the current algorithm needs about 4 seconds to render the shadows for the biggest puzzle of the current standard library (“European Honey Bee”, size of source image is 1620×1280). I have therefore decided to not enable shadows by default (they can be enabled in the config dialog) until the rendering performance for the shadows has been improved drastically.

Update 2: I’ve speed up shadow rendering by 75%. Shadow rendering is now enabled by default.

Also on above screenshot, you see the new jigsaw slicer in action. The previous slicer used a set of seven hand-drawn plug shapes, while the new one can generate millions of different plug shapes from random parameters.

Update 1: The ugly lines between connected pieces, which you can see in the above screenshot, are now gone in the development version.

Palapeli has reached about 2000 lines of code. Today, I combined both the puzzle library and the puzzle table into one window. This is how the application looks like now:

The Palapeli window, showing the puzzle library

The Palapeli window, showing the puzzle table

The new interface layout is based on two fundamental findings:

1. All actions (except for the standard actions like “Help” and “About…”) do only make sense when one of the two views (puzzle library, puzzle table) is visible. I’ve therefore decided to place the toolbars for those actions inside the tab pages.
2. With this change, the only remaining interface parts outside the tabs are the tab bar and the menu bar. Those are both concentrated at the left side, wasting much space at the top right corner. To save space, I’ve put the menu bar into the tab bar. After this change, I found that the new order is much more intuitive (at least to me): The tabs are at the place where the user expects menu items, and also feel much the same. The only difference is that they do not open a submenu, but another part of the application.

There are two problems left with this layout: The menu bar is now always at the right end of the window, while I would like it right next to the tabs to emphasize the altered role of the tabs. I’m still investigating on how to solve this issue. The other issue which I also couldn’t solve yet is that good ol’ “Configure toolbars” dialog does not work.

Update: Issue 1 is solved.

Apart from that, the next tasks are library management (i.e. import new puzzles, delete puzzles from the library, and KNewStuff integration).