I didn't try the new dialog, so I'm not sure how much better it looks. I agree the GhostView one is kind of sucky. It reflects ideas people had about file browser dialogs a long time ago and looks rather strange and confusing today.
However, I did get the GhostView one working again, with full internationalization. So we could keep it, unless you really want to put more work into the new one to fix up all the cosmetic problems, etc. Presumably the future will be the GTK file chooser dialog, though, so there doesn't seem much benefit in working on a new one in Xaw. On Fri, Jun 10, 2011 at 12:13 AM, h.g. muller <[email protected]> wrote: > 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 > changing it...) > > 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? > > > _______________________________________________ > 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
