Re: [XBoard-devel] gtk-branch

[h.g. muller]

> * 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.