Image 01


Graeme Gott
Various Games
Office Apps

Various Games 7 comments

Score 67.1%
Apr 21 2020
I'm glad to hear it! - Oct 09 2016
I can't recreate that. I uninstalled tanglet, removed my PPA, installed tanglet 1.3.1-2 from Ubuntu, then added back my PPA and upgraded. No issues. - Oct 09 2016
I had not realized the Tanglet packages in Debian (and therefore Ubuntu) had split the data files into a separate package. I have updated my PPA packages to do the same, which now allows for clean upgrades from the distro-provided packages. Thanks for letting me know! - Oct 09 2016

Office Apps 4 comments

Score 81.1%
Apr 21 2020
Thanks, I'm glad you like it so much! - Jun 13 2012

Board 4 comments

Score 63.3%
Apr 21 2020
Thanks, I'm glad you like it! - Jun 10 2012
I'd be happy to add your changes upstream if you want to email them to me (as either a patch or a source tarball would be fine). - Nov 15 2010

Various Games 5 comments

Score 63.3%
Apr 21 2020
Interesting! I have just created a git repository (, and I am working on merging some of your changes upstream. - Dec 22 2010
Thanks for the feature suggestions! I will add them to the next version. - Jan 01 2010

Various Games 5 comments

Score 63.3%
Apr 21 2020
Could you provide some screenshots of what you mean? - Jun 13 2008
I am unable to reproduce this bug. It doesn't even seem possible, because I clear the OpenGL surface before rendering the pieces every time you move or rotate a piece. If instead you are referring to the fact that when you are holding a piece, rotating it doesn't shove the other pieces away, that was a gameplay decision: if the piece you are holding belongs on the opposite side of another one, you would have to circle around it to connect it, because trying to move over it would push it away.

1.) I will see what I can do. Qt 4 is good about threading, but as far as I am aware things relating to the GUI (such as creating OpenGL textures) have to be done in the GUI thread. However, I should at least be able to create the pieces in a new thread.

2.) It already does calculations on the fly when resizing the window--it keeps the pieces the same size. I view resizing as a way to get a larger play area, not a way to change the play area zoom. If you want to zoom in or out, there's the mouse wheel, the statusbar slider, and the "+" or "-" keys.

3.) The starting size is calculated to show you every piece of the board. Because zooming is so easy, I think when starting a new game it is more important to see the entire puzzle than it is to zoom in on it.

4.) It already tracks what images you have added to play puzzles with. Do you mean some kind of category system?

5.) KSnapshot, gnome-screenshot, xfce-screenshoter-plugin, Gimp's acquire screenshot ability, etc, already allow for screenshots of specific windows or the whole desktop, so I figured that adding in my own version would be a little redundant.

Also, I understand that your game uses xjig and imagemagick, but mine uses neither, so some of your suggestions (while appreciated) wouldn't really work with my code.

Thanks for the input! - May 22 2008