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).
