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 TryThinking 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.
and were originally created as a part of kdebase.
(stock_notebook) for engnines, and I figured that it would be fun to merge the flags and the notebooks.
The operation was mostly like the previous, only without the translation as the rectangle image had the same size as the notebook image. 
