New WinBoard gimmick

[hgm]

I have implemented a new experimental feature in WinBoard, and I would like to know opinions about it. It is intended to offer a solution for the problem that you see all engines as a huge, unstructured pool, which makes it very hard to find the one you need if you have many. (I know, you could sort them alphabetically...)

The new fature allows you to group engines in the list of installed engines (in the ini file), by enclosing them in lines # NAME and # end .

Code: Select all

engine0.exe /fd=dir0
# GROUP NAME
engine1.exe /fd=dir1
engine2.exe /fd=dir2
...
engineN.exe /fd=dirN
# end
engineA.exe /fd=dirA

When you now select an engine in the Load Engine or Tournament Options dialog, (but not in the startup dialog!), the drop-down list will suppress listing of the enclosed engines, and will only list the group header. So you will see

Code: Select all

engine0
# GROUP NAME
engineA

Now if you select the item # GROUP NAME from the list, you won't really select anything (i.e. you could not press OK now in the Load Engine dialog without getting an error popup, and you would not add anything to the tournament participants in the Tournament Options dialog). But when you now open the combobox again, the drop-down list will list only the engines within the group:

Code: Select all

# GROUP NAME
engine1
engine2
...
engineN

This will continue until you close the dialog, or select the header # GROUP NAME again. In the latter case you will leave the group, and opening the combobox again will give you the top-level list (so you could open another group, or select an engine outside any group directly).

This can be applied recursively (i.e. groups within groups), so whole system looks a bit like the engines are grouped in folders, and you browse through those. So far the grouping can only be done through editing the engine list (which can be done through the Engine -> Edit Engine List menu item). And the # end lines are the only way to indicate where the groups end, so you cannot make a group named 'end'. But any other line starting with # is considered a group header.

Another new feature is that the Engine menu now contains a list of recently used engines in previous sessions. This only keeps tracks of engines loaded through the Load Engine dialog, or the first engine at startup. So not for engines in tournaments. When you click on such an engine menu item it loads the engine as first engine, like you would have opened the Load Engine, dialog, selected it from the list, and pressed OK.

The new version is at http://hgm.nubati.net/WinBoard-4.5TM.exe .
Please tell me what you think about it.

[hgm]

Some screen shots:



The top-level view of the engine list



View after opening the 'Xiangqi Engines' group



Recently used engines can be recalled directly from the menu

[JuLieN]

I'm surprised no Winboard user answered you, H.G., because despite I use Arena on a daily basis I think your new idea is very good!

[hgm]

Thanks! I guess some improvement could still be made, though. With these condensed lists, listboxes seem to have a definite advantage over comboboxes. When the list does not fit, scrolling through the listbox is almost as much work as opening the combobox: you have to go with the mouse pointer first to a place you don't want to be (the scroll thumb), and then have to return to the selection area. But when everything fits, it is annoying that the combobox closes after selecting the group, and you have to open it again before you can see what was inside. A listbox could have shown the group contents immediately.

Another issue I still have to solve is how to conveniently create and manage the groups. Currently this can only be done by direct editing of the list (for which there fortunately is a menu item).

Perhaps it would be an idea to allow people to select a group after they selected an engine (in stead of pressing OK), with as a result that the engine would be moved into that group. (I.e it would remember the last selected engine, and the last group selected after it, and when you OK at that point it would move it there.) On a new install you could select the group without ever having selected an engine (since you entered the dialog).

That only leaves the problem of how to create new groups.

[Giorgio Medeot]

Hi H.G.,

my two cents:
Regarding the engine grouping, it seems a very nice idea. The use of a combobox in this context is a little bit unnatural though, but I can understand that you don't want to revolutionize the gui, since the gtk port is arriving, sooner or later. A logical choice would be a treeview widget: that way browsing the nested groups would be quite more effective. In that scenario, a nice addition could be a text box in which one could type e.g "cr" and have the list shows all and only the partial matches (say some version of crafty and critter...). BTW, with such a "search bar", the need for a mean of grouping engines would be a lot less severe.

Back to the topic, from the post I didn't understand how to go back to a parent group, once you have entered one and you realized that what you were looking for was elsewhere (sorry I can't just try it right now, I'm at work).

Cheers,

Giorgio

[hgm]

A logical choice would be a treeview widget: that way browsing the nested groups would be quite more effective.

Indeed, this is sort of simulating a tree view. The important point to solve, though, was how to store the tree in the ini file without losing too much compatibility. The # GROUP and # end tags in between the engine lines are an effective solution for that, not interfering with other code that uses the engine lists.

Back to the topic, from the post I didn't understand how to go back to a parent group, once you have entered one and you realized that what you were looking for was elsewhere (sorry I can't just try it right now, I'm at work).

In the shown example, when you are in the Xiangqi group, the first item of the drop-down list is '# Xiangqi Engines', and you simply select that.

[Roger Brown]

Hi HG,

It seems to me the grouping has merit separating engines playing different variations. Otherwise I can't see a particular benefit; whenever I install a new engine I put it in its aphabetical place.

Hello Gabor,

Should you be someone who tests a particular engine against a set group of opponents then this would be especially useful.

You could run the Baron gauntlet over here on two cores and the Gaviota gauntlet over there on two cores with less clicks - hence less trouble - and reduce the likelihood of error.

Later.

Ps For gui developers, having a troublesome engines list might be indispensible!

[hgm]

It seems to me the grouping has merit separating engines playing different variations. Otherwise I can't see a particular benefit; whenever I install a new engine I put it in its aphabetical place.

Indeed, what organization is best depends a lot of on what you typically use WinBoard for. But even for doing engine tourneys in a single variant I see several applications:

For instance, you could group by rating classes, and within each class group alphabetically. Because it would probably be a waste of time to play engines against each other that differ by more than 500 Elo. So you could make classes 2000-2200, 2200-2400, 2400-2600, and then pull the engines for a tourney from two neigboring classes (or even a single one).

Another application would be if you have many old versions or tuned versions of the same engine. You could then condense the list, so you would not have to do excessive scrolling to traverse it, by collapsing all versions of the same engine to a single group.

Not everyone does only engine tourneys; as engine author I have an excessively large number of versions around of Joker, Spartacus nd micro-Max, which clutter my list of opponents for them in gauntlets. So I would group all Spartacus versions in a # Spartacus group. Then it becomes much easier to select opponents for it.

[hgm]

Btw, Guenther Simon just pointed out a bug that strikes when you have more than 1000 engines installed. I fixed that a few minutes ago, so people with many engines that want to try it had better download again.

[JuLieN]

@HG
The more I think about your idea, the more I think you should go directly to a relational database subsystem (there are so many libraries available for that!).

People would affect key-words (or categories) to engines, so the system would be much more flexible. For instance: "2200-2400 Elo", "Pascal Engines League", "2011 Engines" and so on, so an exe could be in several categories and be easily found and dispatched to tournaments.

The Interface would work with drag & drops and keyword fields.