Re: outstanding issues

Andy> I'll see if I can implement focusable soon. But the holidays Andy> are over and I just ran out of hacking time. Always dropping Andy> focus is defitinely the wrong default option. I think something must be missing here. I find it hard to imagine a _button_ that should retain focus after activation _by default_. Buttons normally invoke actions; it's unusual (though plausible, see below) that you would want to invoke the same action twice in succession, with no intervening actions in other widgets. I would assume the button's _parent_ should then get focus. AFAICT, this is actually what happens in MS Windows (after 5 minutes of experimenting with the file browser, and it's been years since I actually used MS Windows). It seems to me that rather than implement a "focusable" property, buttons should relinquish focus by default, and if they want to keep it, they should have to explicitly call a function to warp it back to themselves as part of their action. "Always dropping focus is definitely the right default action." :-) The only scenario I can come up with would be something like: open a VM folder, use tab traversal to give focus to the "next page" button, hammer on return until done reading. But note that in this scenario the button was _already_ focused when it was activated, so when it returns focus to the "previously focused widget", it amounts to keeping focus. OTOH, if I _click_ on that button, and want to repeat, why would I switch from the mouse to the keyboard? IMHO, retaining focus for this purpose is far less useful than relinquishing it. Note further that in this kind of application, the text widget invariably provides keyboard equivalents for the button. Finally, if a button is part of a dialog, then I agree that the dialog should retain focus if the activation of that button does not pop down the dialog. The dialog may very well choose to assign focus to the last clicked button. But shouldn't that be decided according to the policy of the dialog, and not be hard-coded into button behavior? For example, in a file selector dialog, when I hit the "parent" button, I do not want the parent button to have focus. I want to be able to type into the text field. Try this: enter the windows file browser. go down two directory levels anywhere. click on the parent button. now hit return. What happens? _nothing_, because you haven't selected anything in the browser window yet. You definitely don't go to parent again. I can't believe that this is somehow left up to programmer discretion in the MS Windows interface. Surely Microsoft forces some policy, which the programmer can override. It's certainly arguable that the real problem is the excessively flat widget tree that XEmacs presents. But I think it's a bad idea to try to make single widgets embedded in an XEmacs frame emulate the behavior of deeply hierarchical Windows/Motif/GTK structures. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."