[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [XBoard-devel] next steps after 4.4.3
Re: [XBoard-devel] next steps after 4.4.3
Mon, 05 Apr 2010 22:30:07 +0100
At 12:00 5-4-2010 -0700, Arun Persaud wrote:
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
* 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
* 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
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
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
from the RTF file) is the colorization of the text. I am not sure the texi
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
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
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
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
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
have made a table-driven dialog window (where the table is ultimately
the engine). It would be quite easy to adapt it to do the other dialogs as
basically by feeding it pre-cooked table of option names, types and
variables that should receive the result. This could in fact be useful for
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.