xboard-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[XBoard-devel] Comment and Tags windows


From: h.g. muller
Subject: [XBoard-devel] Comment and Tags windows
Date: Wed, 09 Mar 2011 10:25:10 +0100

I have been looking a bit into the XBoard front-end code for the
Comment and Tags windows. This is really unnecessarily complex.
For one, there are really four different popups here, as each comes
in two versions: an editable one (with OK, cancel and clear buttons),
and a non-editable one (with close and edit buttons). This distinction
is disguised for the user, as popping up one will pop down the other
first, so that it seems like they are the same dialog. When the
non-editable version is up, clicking the Edit button in it will close it,
and then open the editable one.

Is there really any need to make this distinction? It seems to me
that only having the editable version would be good enough.
It could have OK, cancel and clear buttons always. If you don't
want to edit, you should simply not type in the box, and if you
accidentally do (or accidentally hit 'clear') you can always press
'cancel' to get out without damage. An 'edit' toggle button could be
added to enable the 'clear' button and typing, but it does seem
like overdoing it to me. Especially since the only way to pop up
these windows from the menu will give you the editable version
anyway; the non-editable versions only appear spontaneously
when /autoDisplayComment or /autoDisplayTags are on,
and a commented move is encountered or a game is loaded.

Currently CommentPopUp and EditCommentPopUp rely on
the same dialog-creator CommentCreate, the 'mutable' parameter
to the latter specifying which buttons to add (all in xboard.c).
There are clones of these routines for the Tags window in
xedittags.c. I think all this stuff could be simplified into one.
In fact when the GenericPopUp dialog creator is enhanced
(made reentrant) to allow popping up of persistent dialogs
(as it seems we would have to do for the XBoard equivalent
to ICS text menu anyway), we could use it to generate the
Edit Comment and Edit Tags windows as well, so that stuff
could be simplified into zero. Note that in WinBoard I also
use the edit Tags window for editing the lists of engines
(-first/secondChessProgramNames) and ICS (-icsNames),
while it couldalso be used to edit the -icsMenu setting.
(XBoard so far had none of these, as the frst three are startup-
dialog related, and the ICS context menu popped up by clicking
the console window, which we cannot do with an X-term. But
a menu item for the latter in XBoard does create a sort of alternative,
so we mght want to include an edit function for that.)

A related question: All the 'persistent dialogs', like Edit Comment,
are treated such that when you close them, their window is hidden,
but not destroyed. So that when it is reopened, the dialog does
not have to be recreated, but can be simply showed again.
Is this important? (E.g. is there much overhead in creating
a new dialog? I would guess the main work is actually drawing it
on the display. Or is this an X-server vs client thing?)
The only behavioral effect I can imagine is that when you were
editing something and close the dialog window without having
OK'ed or cancelled it, reopening it would show you the altered
but unsaved text..




reply via email to

[Prev in Thread] Current Thread [Next in Thread]