* Integrate ICS input box and add functionality: mostly copy the functionality from Winboard. Perhaps we want to get rid of using the terminal alltogether?
This is indeed what WinBoard did. So far our inability to colorize messages in Xt has prevented we could do the same in XBoard. So as soon as the GTK version can colorize messages, we could do away with the xterm completely. I must admit that the xterm for me is often a very useful debugging tool. It is much easier to ustthrow in a few printfs andlookat what they do in real time, than making debug files all the time. For this reason I usually do most of the backend development on Linux now.
* Add theme support: Instead of specifying all the details on the command line or the ini-file we could have a small xml file (or other format like our own ini-file) where we specify the background images and pieces. This way it would be easy to distribute different themes and it would be easier for users to switch between different settings. The theme could then just be a zip file which has to include a theme.ini file and the svgs...
Not sure how this offers anything different from what we already have. We can distribute a zipfile with textures and piece bitmaps, and a theme.ini file with it, so that people can run the theme by simply starting with the option @theme once. Because all these settings are persistent, XBoard will then use that theme until you specify differetly (perhaps through running with @theme2, or just specifying individual textures or pieces. I distribute WinBoard with several such 'theme' files. E.g. xq.ini, which loads the xiangqi board as texture, and the oriental-style pieces.
* Too many windows? At the moment XBoard can clutter the workspace with tons of windows, perhaps we can reduce the number of windows used for preferences and also include some other windows into the main window? Perhaps use dockable windows to maintain the freedom to place the windows where you want them?
I have always thought the large number of windows was one of the most attractive features of WinBoard. What you are not interested in, you simply close, and it will no longer bother you. I am not sure what exactly you mean by 'dockable'. Is this different from what WinBoard does now with the -stickyWindows option?
* I'm also for using only scalable graphics for the pieces (e.g. svg) and make the window scalable and get rid of all the size option for xboard.
In principle the scalability is great, but it breaks backward compatibility for people who have designed their own piece sets. I don't know how easy it is to make SVG pieces compared to making pixmaps. The font-based rendering of WinBoard is equivalent to SVG, but it is a pain to make fonts. I imagine many people would make pieces by simply taking a screenshot of a diagram they like, and cutting it to pieces with a program like MS Paint or GIMP. I doubt there exists an easy way like that to make SVG pieces. So getting rid of the -size options is fine by me, but I think many people would be very grateful if we kept supporting the possibility to use a set of pixmaps (of any size, the size then locking the board to the size that belongs to it).
* Do we want to think about adding the ability to open multiple game windows for playing simul games or observing multiple games? I guess this would mean a big change in the code, but this might be a good time to add this?
From a programming point of view this will be a nightmare, and I don't see any upside of handling several games in the same process. Much better, andconceptually easier to have multiple XBoard instances open, one for each game. E.g. what would you have to to when a user clicks 'Save Game' on the menu? Ask him which game? If making multiple connections to an ICS is problematic, I think the best technical solution is to let XBoard handle a single game like it does now, but create a child process running XBoard for every foreign board it receives during its own game, and forward the boards there through a pipe. Then every game is processed fully independently, and can be controlled through the user through its own menu bar, etc. All this needs is an option to run XBoard in ICS mode, not creating a socket to communicate to the ICS, but using stdin/stdout in stead. That would make the slave windows do exactly what you want them to do. And the master window should get some extra code to dispatch the foreign boards (which the -backgroundObserve option now just puts in a buffer).
* Better help menus: get rid of the info and man links and add links to platform specific help files generated from the texinfo files. just some ideas... feel free to add to it As far as timeline goes: In general I think that as soon as we can turn off all the X-code and are able to cross-compile for windows, we should move master to gtk and only do bugfix-releases for the 4.x.x branches. What do you think?
It depends on the quality of the gtk. Getting rid of the X-code is not the same as having the gtk do everything that the X-code does now, or do it equally well, and certainly not that it does it equally well as WinBoard. So my main development will remain in whatever branch the version is in that is my main GUI in everyday life. Last time I looked at the GTK version, there was still a very long way to go before it would be acceptable for using. E.g. *) animate dragging *) animate moving *) using the xiangqi board pixmap as background *) displaying any non-orthodox pieces are all major things that do not work at all,and highly non-trivial to program. And I haven't tried things like the seek graph yet.
