>>>> "Andy" == Andy Piper
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
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
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."