Re: [XBoard-devel] Development release

[h . g . muller]

Op Wo, 9 maart, 2016 11:48 pm schreef Joshua Pettus:
>>>
>>> Perhaps I should, stop whining and make it happen ;).
>>>
>>>
>>
>> I would certainly encourage that! ;)
>>
>>
>
> Then I’m on it as soon as i can. :)  I’ve been itching to take on
> another HTML project and that’s a great idea.
>

One problem with using clicks on dialogs to get on-line help is that it
sort of forces you to open the web browser. We don't want to build a HTML
interpreter into XBoard. Opening a browser and accessing a remote website
with it is a pretty-long-latency operation, not at all like an imemdiate
XBoard popup based on local info only.

For on-line help it would be more convenient to have screen shots of the
various dialogs in the on-line manual, and then allow the user to click
the various controls on these, to either pop up a description of the
function of it in a separate window, or just fill a dedicated field next
to the image on the same page with the explanatory text. (That would be
more convenient than just sending the user to an always-displayed manual
section on the same page that discusses it, as this would usually scroll
the dialog screen shot out of view, so that he would have to scroll back
to get info on another control in it.)

Another way to do it could be to organize the manual text as a tree
widget, showing only the item headers, and allow you to click one open at
a time (collapsing any other section that might be open at that time again
to just its header line). I guess this could be made even hierarchical:
have a list of main menus, one of which can be expanded to an (indented)
list of menu items, those of which representing dialog again being
expandable to a more-indented list of controls next to a screen shot of
the dialog (and the others expanding directly to the explanatory text).
That keeps the entire manual on a single HTML page, while navigation
through it would be mostly local (and thus fast) after the screen shots
have been cached by the browser.

> Also, i sent another email  but you may have missed it, Is there any way
> we can hide passwords in our ICS/Chat box?

Ah yes. At the moment I have no idea how todo that. Typing text into a GTK
text edit is a standard function of the GTK widgets. We would have to
figure out if GTK supports some call for switching such widgets into a
mode where they do not echo the typed text. XBoard already decides when
this has to be done, and calls functions EchoOn/Off, which now only
control the xterm. The corresponding GTK functions should be calledfrom
there (probably meaning they have to be moved to gtk/xoptions.c).