OK, I am sort of done with the XBoard dialogs. I condensed the work (in the "popups" branch of the hgm.nubati.net repository) into 17 commits, starting with "Make generic XBoard popup...", which group the changes by dialog, in so far they are not infrastructural.
Now we have to decide what to do with them. I want to propose the following: The first nine can go into the v4.5.x branch. They implement seven dialogs XBoard did not have before: Save Options, Load Options, General Options, ICS Options, Board Options, Sound Options and Match Options. Note that the last one is something even WinBoard does not have, and that the others in general also are more elaborate than their WinBoard counterparts. The General Options and ICS Options were partly covered by the items that used to be directly in the Options menu, but are not limited to Boolean options. In addition these commits redesign three dialogs that already existed: Common Engine Options, Adjudication Options and New Variant. The gain here is obviously less, but especially the Common Engine and New Variant dialogs contain a number of new options, and also use the more 'flashy' controls the Engine Settings dialog offered (+ and - 'spin' buttons on numeric inputs). The new New Variant dialog works more smoothly than the old one, making the selection directly, without the need to press an OK button. All in all I think that it is worth it to include these new-style dialogs in the stable version as soon as possible, also because this makes them trivial to expand (e.g. add a new variant), where expanding the existing dialogs always was a pain. This means "Make generic XB popup..." upto and including "Implement Machine Match..." would go into v.4.5.x. The commits after that represent more experimental work. Basically they are refactoring aimed at simplifying the code base, without much clear immediate benefits for the user. It is also a bit more dangerous, and I cannot exclude that it might have broke something (like window positioning). This because it involves the dialogs that are persistent, rather than transient. There is more interaction between these dialogs and the back-end, and several can be open at the same time. I redid the Edit Comment, Edit Tags popups, and ICS Input Box, which removed a vast amount of code (because they were all done by different routines cloned from each other, while their new implemetation basically uses no dedicated code at all). I also added an ICS Text Menu dialog as persistent dialog, to send user-configured commands to an ICS. The function is thus similar to the WinBoard ICS context menu, but it is not yet as advanced as that. I guess some more work has to be done on this to realize its potential (if only by defining a sensible default configuration for the -icsMenu option). So perhaps we should not push it to Savannah at all. I suppose the refactoring would be beneficial to the GTK port, as code that no longer exsists would not have to be ported. As far as I am concerned, any of these later commits we decide to push to Savannah could go into master. I have thought about it, and I think it is worth the trouble to maintain this internal forking between master and v4.5.x, to create a place where we can give exposure to some of the more speculative and immature development stuff, even if v4.5.x isn't strictly bugfixing.
