[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-XBoard] [bug #33241] xboard quits with 'Unable to create font s
Re: [Bug-XBoard] [bug #33241] xboard quits with 'Unable to create font set.'
Fri, 10 Jun 2011 09:13:42 +0200
OK, the new browser dialog seems to work now. I added path browsing to it.
The reason it crashed before was that I had broken the comment popup,
which I moved to another dialog number to 'make space' for a second
transient dialog (so that 0 and 1 could be transient), which was needed
because the browser has to be up at the same time as other transient
dialogs calling it through their 'browse' buttons. So the browser worked
fine, but as soon as I had loaded games, and they had comments in them,
the -autoDisplayComment caused XBoard to crash at te first commented
move. I guess such is the risk of the bad practice of using hard-coded
numbers rather than macos/enums. (But it was not designed for ever
Anyway, it works now, both for filling filename and path fields in the
other dialogs, and directly from the File menu for Load Game/Position etc.
There are some minor cosmetic problems:
*) It does not sort the files in the dir listing
*) clicking a file or folder in the listing to select it / move there,
sometimes causes spurious selection of a group of characters there.
*) For reasons I don't understand the window manager wants to
give focus back to the main XBoard window after you close the
browse dialog, rather than the dialog that called it, even though I
do give focus to a field in the latter on closing the browser window.
(And that field does get the cursor, so I assume it worked.)
*) What I also don't understand is that when I use the browser a second
time, it pops up _behind_ the dialog where I operated the 'browse' button
from to summon it. Again, popping it up involves focus to a text widget
in the browser dialog.
*) I actually had to change focus to another widget than that was initially
put in focus during popup, (namely the extension-filter field, being the
lower-most text widget), or the event handler I added to that widget
(for reacting to <Return> and <Esc>) was not initially operational. Fishy...
*) I did not add yet the responses to <Return> and <Esc> (for OK and cancel)
in the filename field that I had added to the old browser. In fact I want to
check if I cannot make that a general feature of all single-line text widgets
in the dialogs. And then perhaps also add <Tab> to move focus the next
text widget in the dialog.
*) I also did not implement double-clicking a file in the listing as an OK
equivalent, or use of the mousewheel to scroll the listing. I felt less need
for that here, as the OK button is not in such an awkward place as it was
in the GhostView dialog, and the scroll bars seem to work much less
erratic too (perhaps because the Xaw implementation of them is better).
Please tell me what you think! Is this an improvement over the GhostView
browser, or do we better stick with the latter?