At 13:02 4-7-2012 +0200, [email protected] wrote:
Then I strongly vote for -autoBox true|false instead ;)
I already pushed the patch to the v4.6.x branch of the GNU repository. ( http://git.savannah.gnu.org/cgit/xboard.git/log/?h=v4.6.x ) If you want, you can download it, and install from source. (You would have to start with ./autogen.sh before the usual ./configure; make; sudo make install .)
Especially since the input box obviously steals the focus (without coming into foreground, at least with my window manager settings) so that the second letter I type isn't subject to evaluation as a shortcut for an ics command. E.g. I frequently type "q" for resign (too often I have to) and then "r" for rematch. Now I always wonder why there is no reaction by my opponent. But of course my "r" just sits in the input box doing nothing.
Indeed, I see the problem. Why windows that are given focus aren't raised to the foreground has always been a mystery to me. It seems it is really connected to some bug in the window manager. Sometimes it happens, sometimes it doesn't, and I cannot predict which of the two X-server calls that are supposed to do it will fail. This should be solved once and for all in XBoard 4.7 (now in the master branch of the GNU repository), where neither of the calls worked, and I could only raise windows by sending a request message to the window manager. But this at least always worked (so far), albeit with a noticeable delay. I have always had my doubts whether it would be wise to assign strongly irreversible commands like 'resign' to a single key.
Some additional thoughts: I never particularly liked the input box. In order for it to be useful it had better be part of a window which also displays the stuff coming from ics. But then there is a perfect way to achieve that without the input box and which I use all the time: rlwrap. It lets you use the readline library, e.g. it takes care of command line history in a much better way than the input box. Somehow it's not the unix philosophy to reinvent the wheel. I admit that the input box may have been around before rlwrap but rlwrap is a much cleaner and portable alternative. So there is no reason to now force the input box on everybody. Maybe it is needed for winboard but for xboard (which I use) it is definitely obsolete.
In WinBoard the 'input box' is actually part of the window that displays the ICS output, like you propose. But XBoard uses the terminal window from which it was started for this purpose, and it has no control over how it looks, where it is positioned, whether it has focus or whatever. As a result WinBoard's ICS context menu also cannot work on XBoard. I did have a patch where the ICS output was displayed in the Input Box, above the input line. That would allow XBoard to react on clicks in the text, as it does with WinBoard (e.g. open a chat window with the person whose name you clicked). But unfortunately the Athena widget set on which XBoard is based does not seem to allow line-by-line coloring of the text in text widgets, which kind of torpedoed the idea... I don't like rlwrap much, because it repeats the line you are typing many times if ICS output appears while you were typing. With a separate input field you can type much more quietly. The Input Box is not so bad if you make sure it is always in view, and position it directly below the terminal window, so that it looks like they are in the same window.
Okay it's unfortunately <Enter> instead of <Tab> on xboard. Is there any way to swap it? Holding the mouse with my right hand <Tab> is more conveniently typed with the left.
I must admit that I forgot about exactly why WB and XB are different here. I know I could not get it to work on one of them with a key used on the other. You could try to associate a KeyDown event on Tab with TempBackwardProc(), and a KeyUp event on Tab with TempForwardProc(). Regards, H.G.
_______________________________________________ Bug-XBoard mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-xboard
_______________________________________________ Bug-XBoard mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-xboard
