Winboard Forum

Hi there;
I have xboard set to initialize with a script for internet use,which includes bringing up the ics input box. I have 2 questions regarding this. First is it possible to have the layout remembered? As it is, I have only to reposition the input box and terminal windows, but it would be nice if xboard could remember my ics setup. Second I noticed the input box cuts off the message if it is longer than a small sentence. Would it be possible to have the input wrap around and continue according to the size of the window? Thank you

The problem is that the ICS output is in a terminal window that was not created by XBoard, but used to start it. So XBoard has no control over that window. It can just send text to it for printing (with embedded escape sequences to affect the font color).

I have tried to replace the use of the terminal by a dedicated window, basically adding an output field above the input line in the ICS Input Box (which can be controlled by XBoard). But unfortunately the Xaw text widgets do not support inhomogeneous font coloring, and this seemed unacceptable.

As to the line length: The Input Box by default also has only room for a single line. You can resize it, but you can also resize the width so that the line fits. Do you really think vertical resizing would be better?

Thanks for making it more clear to me how xboard and the terminal are separate programs. I just re sized the terminal and changed the colors and it works just fine now. To your point of resizing the ICS Input Box (wider instead of longer). I have tried but with a long sentence or paragraph what I am typing still gets cut off before I have finished and I no longer see what has been written. So yes a longer box with text that wraps around as you type is what I think would be best. I understand that the terminal is not part of xboard , but is the ICS Input box something you could tweak when time and inclination allowed?

Indeed, the ICS Input Box is a window created by XBoard. In principle I could control size and position of such windows, and store those in the settings file. For some windows this is already done (e.g. Engine Output, Move List). The problem is that this does not seem to work reliably: if I let XBoard ask the X-server where a window is, and then later order it to pop up in the same location, it does not pop up in the same location! These seems to be an unpredictable random displacement of a few pixels. This makes the persistent windows wander around.

In the case of the ICS Input Box, the logical place to put it would be just under the terminal window (like in the WinBoard ICS Interaction window). But XBoard cannot even inquire where the terminal window is. (At least, I would not know how.) And if the terminal in general will be positioned in a place where you don't want it, it would be pointless to base the positioning of the Input Box on it, as it would only mean you now have to move both. So perhaps I should simply make an attempt to remember the Input-Box position in the settings file, and approximately pop it up in the location where it was before. You can then just move the terminal window to just above it.

I would in fact like every persistent dialog to remember its screen location across sessions, and reposition together with the main window, like they do with WinBoard when -stickyWindows is on. But the fact that the X-server does not obey the repositioning commands exactly makes it impossible to do something like that of acceptable quality.

So perhaps I should simply make an attempt to remember the Input-Box position in the settings file, and approximately pop it up in the location where it was before. You can then just move the terminal window to just above it.

Yes that would work. Also is possible to make the Input Box scroll the text as it is written. Like the engine output window?

That depends on what exactly you mean. The ICS Input Box happens to be generated by XBoard's generic dialog generator, which also generates, for example, the Move List. So making the text field in there higher and making it autowrap is just a matter of setting a few flags in the table that specifies what should be in the dialog.

But I don't think it would be feasible to keep lines you have already sent to the ICS in there. Once you type enter, the text should be automatically sent, and the box cleared to accept the next command. So there never can be more than a single 'logical line' in the box, although because of auto-wrap it might be displayed as multiple lines. You can recall old lines in the box anyway by using the arrow keys.

Btw, if you feel adventurous, you might want to have a look to the version that does away with the console and also sends the output to the ICS input Box (which in other respects is very obsolete now). It can be found as the last snapshot in the 'chat' branch of my on-line repository: http://hgm.nubati.net/cgi-bin/gitweb.cg ... heads/chat . I abandoned it at the point where I discovered it was impossible to colorize the text selectively in that window. It would have many advantages, though: XBoard could in principle size and position it, but also react on mouse-clicking in the window by selecting the word you click, and using it in the text-menu commands. (None of this implemented yet in that version, but I know how to do it.)

That depends on what exactly you mean. The ICS Input Box happens to be generated by XBoard's generic dialog generator, which also generates, for example, the Move List. So making the text field in there higher and making it autowrap is just a matter of setting a few flags in the table that specifies what should be in the dialog.

But I don't think it would be feasible to keep lines you have already sent to the ICS in there. Once you type enter, the text should be automatically sent, and the box cleared to accept the next command. So there never can be more than a single 'logical line' in the box, although because of auto-wrap it might be displayed as multiple lines. You can recall old lines in the box anyway by using the arrow keys.

Yes this is what I had in mind. Not to keep old conversation but just to be able to view ones complete sentence/paragraph before the enter button is pressed so as to be able to check spelling,edit etc before I push send. The only thing that would be of concern is the minimum size of the new box. It should still be re sizable and be able to be placed under the terminal window.

I had a look at your attempt to do away with the terminal. I think you made the right call. Not being able to colorize the messages is losing too much. Even though an interactive Input Box opens up a lot of possibilities for shortcuts one can work with the terminal comfortably enough (just my own feel).

Perhaps you can try if this does what you want (my Linux machine is a bit flaky due to a bad contact in the power plug):

In the file xoptions.c, change the second line of the code

Code: Select all

Option boxOptions[] = {
{   0, 30,  400, NULL, (void*) &icsText, "", NULL, TextBox, "" },
{   0,  3,    0, NULL, NULL, "", NULL, EndMark , "" }
};


to

Code: Select all

{   8, 100,  400, NULL, (void*) &icsText, "", NULL, TextBox, "" },


and re-compile.

The 8 as first number would specify the text has to wrap. (An added 4 there (so 12 total) would specify auto-fill, but I am not sure what that means, and don't think you would need it.) The second number specifies the initial height of the text box, so I increased it from 30 to 100, to give you about 4 lines by default. Of course you can always re-size if you need more.

I made the changes to xoptions.c and recompiled. The result was just what I was looking for. Thank you!