Re: [XBoard-devel] next steps after 4.4.3

[h.g. muller]

At 12:00 5-4-2010 -0700, Arun Persaud wrote:
> Hi
>
> here are some thoughts about the next versions of XBoard/Winboard. At
> the moment we have 3 branches:
>
> * 4.4.x (stable): mostly for bugfixing and perhaps small new features...
> * master: lots of new features, trying to close the gap between Winboard
> and Xboard
> * gtk: not usable yet
>
> For the next steps I would say we should perhaps do another 4.4.x
> release with only bugfixes, but mainly focus on unifying XBoard and
> Winboard and then branch 4.5.x from master.

Well, if another 4.4.x release would be needed will be mainly determined
by if we or others discover important new bugs. Lately not many new bugs
have surfaced. Most bugs that were fixed in 4.4.3 were bugs related to the
Chat Windows, which were a new feature in 4.4.1.

> HGM already made a lot of changes towards moving things from Winboard to
> XBoard and the other way around... areas we still need to work on are
> for example
>
> * unifying the documentation and have everything in a .texi file (and
> generate windows compatible html-help files from there) or perhaps a RST
> file from where we can produce .texi and the windows html help files.

Indeed, not having to duplicate or triplicate the effort of updating the 
help would
be great. But this obviously would only be possible when XBoard and WinBoard
in fact need the same docs. For the command-line options this is 
practically the
case. But the menu descriptions are currently much more elaborate for WinBoard,
simply because virtually all menu dialogs are still missing in XBoard.

Another problem (which currently prevents automatic generation of the HTML 
help
from the RTF file) is the colorization of the text. I am not sure the texi 
file supports
colorization; in any case the current one does not have it. We might of course
decide to completely drop colorization of the docs. It was introduced mainly
because there was no satisfactory alternative to point out the new features.
Distributing better NEWS files with the releases that really describe new
features in a tutorial manner (somewhat like 
http://hgm.nubati.net/news.html ),
or even referring to such info in on-line web pages, would be superior even in
the absence of colorization in the manual / help files.

> * unifying key-bindings. Use standard gtk key-bindings for things like
> save, quit, preferences, so that users in 4.5.x won't have to change
> habits again when we move to gtk. Have windows and unix use the same
> keybindings for everything.

Can you give me an overview of the standard GTK bindings? It is a bit difficult
for me to imagine what actually could be used in XBoard that would be
considered standard enough for GTK to recognize it. 'Quit' would probably 
qualify,
but 'Save' is already a non-standard thing in XBoard, as it needs to know if it
has to save a position or a game. A distinction GTK is probaby not used to.
Selecting does not mean anything in the main window, copy again needs
to know if it is for game or position. So the XBoard menus do not look very
much like that of the typical applicaton, and I don't see how GTK could 
bind keys
to menu items for which we have not defined any function, or why it would be
a problem to requisition those keys for non-standard functions we do have,
even if usually they have a different meaning in typical GTK applications.

> * unify menu entries

I think this is already pretty much the case, exept that WinBoard has many
more items in the Options menu, which call up dialogs where option parameters
can be set. In XBoard, the corresponding dialogs are not implemented yet, so
it also does not need these menu items. I already added a few such dialogs
(Time Control, Adjudications, Engine Settings, Game List), but many are still
missing (ICS, Save Game, Load Game, Sounds, Fonts, Board, Communication).

I agree that it would be bad strategy to invest much time in the XBoard 
front-end
if we are going to abandon it when the GTK version matures. OTOH, there might
be a relatively cheap way to supply the menus. For the engine settings I 
already
have made a table-driven dialog window (where the table is ultimately 
supplied by
the engine). It would be quite easy to adapt it to do the other dialogs as 
well,
basically by feeding it pre-cooked table of option names, types and 
corresponding
variables that should receive the result. This could in fact be useful for 
the GTK
version as well, which could use the same table of option descriptions to drive
a universal dialog handler.


> What do you all think?
>
> If people want to help out with any of this, or have other agendas they
> would like to see developed in XBoard/Winboard...  let us know.
>
> ARUN