Flags and ImageMagick

This day I was looking for some flags to use for chess engines. A quick locate flag |grep .png gave me a lot of lines like /usr/share/locale/ l10n/us/flag.png. The flags looked like this and were originally created as a part of kdebase.

I quickly colleckted the files by

for i in `ls /usr/share/locale/l10n/`
do
    cp /usr/share/locale/l10n/$i/flag.png $i.png
done

I found out however, that those flags were boring. They also didn't look enough like computers. I used to use this icon: (stock_notebook) for engnines, and I figured that it would be fun to merge the flags and the notebooks.

I tried out stuff in the gimp, and it worked well. Now the problem was that I had 229 flags for which I had to open in gimp, resize, copy to the notebook image and save. A quick calculation based on the amount of time spent on the first flag, showed me that this would take me 1.9 hours. If of course I ever managed to complete it.

This brought up ImageMagick to my mind. ImageMagick which is a command line utility for doing quite a lot of advanced image operations. I found the "Usage guide" and read these two parts of it: resize, composite, which described exactly the functions I needed: Resizing and merging.

In the beginning the guide was looking kinda messy, mostly because of the length of the command lines. However it quickly became clear that it was really very well built, with screenshots all over it, white made it easy to find what I was looking for.

The resize command looked like the following: convert in.png -resize 14x7\! out.png. The ! told ImageMagick that I didn't care about the original aspect of the image, which is necessary since all flags have different formats.

Next the scaled image had to be merged on the notebook image. The command for such an operation was: composite -geometry +5+6 2.png stock_notebook.png 3.png. The geometry option told how much to translate the upper image (2.png) on the lower.

At this point I already had a nearly perfect image. The only missing part was the border around the screen being too thin. To help this problem I decided to merge again with a half transparent white rectangle: The operation was mostly like the previous, only without the translation as the rectangle image had the same size as the notebook image. composite -geometry +0+0 light.png 3.png 4.png did its thing.

In the end I put down everything to these few lines:

for i in `ls`
do
    echo "doing $i"
    convert $i -resize 14x7\! $i
    composite -geometry +5+6 $i ../stock_notebook.png $i
    composite -geometry +0+0 ../light.png out.png out2.png
done

And in 10 seconds, ImageMagick did what would otherwise have taken me hours. Nice :)

engines.ini

I just found a file in the Arena chess client download section called engines.ini. The file is in 1264 lines, and contains a description of an engine for each line. For CECP engines as well as UCI engines.

A snip from the cecp part, looks like:

Gnuchess4=EMPO
Gnuchess5=EO
Faile=O

The letters right to the equal signs are keys to the options in the dialog at the right, which means the gnuchess 4 supports "Edit mode", "Move now", "Ponder" and "Opening Book". Gnuchess 5 on the other hand only supports "Edit mode" and "Opening Book". Faile won't even be able to load a game, as it supports no such feature.

Of course it is a a weakness that there is no field to tell if the engine supports "protover 2", which means that we still have to base the loading on timeouts.

But still there are a lot of good things. Now we've actually got _some_ information for those engines which does not support "protover 2", and we will be able to send a proper error message when trying to load a game, playing against Faile or similar.

Also the file can be used to identify engines at the users PATH. It might however require some smart text comparison algorithms, as I can see no absolute way to tell that the binname of "Gnuchess4" is "gnuchess" and the name of "Shredder Classic" is "ShredderClassicLinux". At least on linux ;)

I plan to convert the file into the engine xml format

An old post: Engine Managers

Intro: While working on a more recent post, I stumped upon an old draft from feb 07 that had seemingly never been posted. Perhaps because it describes an engine system for PyChess, that was in fact never implemented.

I thought it would be nice to post it now, as PyChess Staunton nears final, and work may begin on the new vision for PyChess 2. I can ensure you however, that the mockup named 'Final try' in the article, is miles away from what will find its way into PyChess 2 :)

In the past few days, I've been looking into creating better engine management in PyChess.

That this comes now, and not after FICS support is complete, is mostly due to the debian problems which have been reported in the last time. I hope that better engine management will make this problem easier to debug.

The engine management in preferences (which is still only glade template), looks like the image on the right. When the user wants to Add or Edit an engine, another dialog appears.

This new dialog is what has been causing troubles.

The dialog mainly let you specify the path of the engine, the (optional custom) name of the engine and the engine protocol.
It also lets you specify the engine difficulty at specific levels.

In the good old CECP days, this was easy: Everything user wanted to change for each level of difficulty was the maximum search level, and wether the engine should be allowed to think in the opponents' time.

Now in these UCI times engines has many more configuration parameters. And of cource some people might even want to change additional, engine specific parameters like hashsize.

In UCI engine parameters are given, and has to be set, at init time Example.
At first sight these options greatly appears like a target for an IDE/gnome-settings like treeview with the left column used for keys and the right one filled with the corresponding widget cellrenderer. Like gtk.CellRendererSpin, Combo, Text and Toggle.

First try

However a closer look at the pygtk specs, and a couple of hours af talking and coding with the great people at the pygtk irc channgel, it bekame clear to me, that I'd have to choose another path. The glade path.

I can almost hear people cry: "But the glade approcah looks so ugly!" And sure it does. So I did some research and I found Arena. Arena which seems like a great chess application, but is windows only.

I did the screenshot using wine. And I tell you: Don't try this at home - Arena is slow like eclipse when run under wine!

Arena has two dialogs for engine management (and some tabs): The one at the left and the UCI property configuration one above.

When users want to add an engine they can use the left dialog or a Wizzard. When later the engine is started (like in the analyzing panel) the user can bring up the UCI properties dialog and will afterwards of cource have to restart the engine.

As you see, Arena uses a modified glade approach. As in glade they don't use a treeview, but use real widgets. As a change however, they display the data in two columns, which is actually a good idea, when looking at how wide glade streches its property widgets.

Based on the Arena screenshot, I crafted the following glade template.
While it looks kinda okay, it has to major problems: It is not homogen in width, and more important: It will require 3 of those dialogs to support the three difficulty levels.

And what is perhaps most important: I found another interesting approach, and this time even a mac one.

Second try

This screenshot I found from the sigma chess user manual. And as all good sources of inspiration for gnomeapplications: It's a mac application.

The most interesting thing about this dialog is the way the data in the treeview is edited. This is neiter the gconf-editer method nor the glade approach, it is an entirely new one.

When an item in the list is selected, the lower label and control changes, to mach the content in the selected row.
On the shot a int is selected, and the dialog shows a slider.

Based on this new idea, I went to back to gazpacho to craft a new version.

Personally I find this version much more pleasing. It is not as crowded, and it takes up less space.

However there is still one major issue left to solve: Applying different values for each level of difficulty.

Final Try

Thinking of the different difficulty boxes (I didn't want to use tabs or simmilar) I came to think of those user iterfaces with a lot of lists and arrows to move arround values.
That was when I came to think of a very well known user interface, which does exatcly the same thing as I need: The adwanced email contact selection dialogs.

From the left list you can choose contacts and place them in one of the three receiver boxes. In PyChess gazpacho templates this method, combined with the value editing approach from sigma chess, this looks the following:

Well, this of cource is to be put into that dialog from before. Probably in some extender.

Designing the perfect Internet Chess GUI

In the last few days I've spent a lot of time thinking on how the perfect GUI for Internet chess should be made.

I've taken inspiration from eboard, jin and most of all knights on how this could look.

First for the log on dialog, this is what I've come up with.

Good Points:

• I like the fact that you have easy access to creating new accounts.

Concerns:

• Users should probably not need to set the port, as it can be loaded from XML. The server "item" just looks so empty without it.
• There are no buttons in the lower right corner. The "Log On" button is in the middle..
• You have to open a website to create new accounts. Sadly, as far as I know, no servers offer a web service for this, which would make pychess able to have its own GUI for this.

Next for the actual game browsing dialog. This is a screenshot of the console hidden.

I'm not yet sure if this should be put inside a pychess game tab, like in knights and eboard, or it should be a window of its own, like the current "new game" dialog.

When you choose to join or observe a/some game(s) we will either replace the current tab (if we chose the tab way) or open a new tab. In both cases with a console sidepanel. This sidepanel can til we get gdl-dock implemented have a "show in window" button, for to view a full 80 column width console.

On the right you see the fully expanded edition. In the eventual version, there will be more icons on the buttons.

Good Points:

• I'm very glad with the current simple look, that should make people able to join a game in one or two clicks.
• Power chess gamers still have full console access.

Concerns:

• Currently when you want to create/seek a new game with a special time setting, you choose -> Advanced -> Time -> Custom, which will bring up a dialog for you. This is perhaps a little to many clicks.
• The join button is not in the lower right corner..

Stupid epd opcodes

I've been rather angry at the fen format for a while. As the broadest used format for storing chess positions, it is used in the UCI chess engine protocol, and in the PGN format as a header tag.

To store a chess position, it takes more than just storing the location of the pieces. You also have to store the castling state, the cord which can be attacked by enpassant, the number of moves since last capture or pawn move (to judge draw on the fifty moves rule) and last, but very importantly, you have to somehow store the position repetition state.

In chess a game can be declared a draw if the same position has been repeated three times in a row. This rule can sometimes be used to force your opponent, which is in head of the game, to a draw.

A typical fen string could look like: nbqkbnr/pp1ppppp/8/2p5/4P3/8/PPPP1PPP/RNBQKBNR w KQkq c6 0 2 which is the board position, the castling state, the enpassant square, the fifty moves counter and the full move number.

The fen format nicely takes care of the first 4 parts, but it has no way of storing the repetition count. This might not sound as a big deal to most people, but imagine that a certain move will draw a game, and the engine is being told of the position using fen, then, if the move was good, the engine will play it, totally unaware of the draw danger.

Now, you can perhaps imagine how interested I was when I saw that the epd format, which is very much like the fen format, contains a so called opcode for storing the repetition count.

An epd string may look something like: r1b1kb1r/pppp1ppp/8/1nN5/1n1p2Pq/5P2/PPPPP2P/R1BQKB1R w KQkq - hmvc 1; fmvn 7; rc 1; The two last fen fields have been moved to opcodes, and we have added a field called rc.

The repetition field is good, but it only solves half the problem. Consider this case:

Initial position # Repetition count is now 1
1. Nf3 # Repetition count is now 1
... Nf6 # Repetition count is now 1
2. Ng1 # Repetition count is now 1
... Ng8 # Repetition count is now 2
3. Nf3 # Repetition count is now 2
... Nf6 # Repetition count is now 2
4. Ng1 # Repetition count is now 2
... Ng8 # Repetition count is now 3

You see, we've got four positions with repetition count 1 and four positions with repetition count 2. How the heck is a software program going to decide whether a move is going to put it in repetition count 3 and there by a draw?