John A. Turner writes: another one: faces bold, italic, bold-italic don't react to size changes

AP> Could you try all these again, they should be fixed. ok, I did a cvs update this AM and rebuilt... I still see this problem - thought I should probably update the dired pkg as well, so did that (updated to dired-1.08), but no change was their something else I needed to do? this is still there as well - after Set or Save, focus is lost, and I have to either move the mouse out of the frame and back in or click in the frame to regain focus this one does seem to be fixed -- John A. Turner, Ph.D. Senior Research Associate Blue Sky Studios, 44 S. Broadway, White Plains, NY 10601 http://www.blueskystudios.com/ (914) 259-6319

Andy Piper <andy(a)xemacs.org&gt; writes: I wonder... Is that really "correct" in Emacs? I would hope to be able to just start typing after I've used the button. If the focus doesn't serve anything useful for the button, why not relinquish it?

AP> Sorry, someone elses bug - I haven't done anything towards this. yes, those interested can review the thread from 10/2000 starting here: http://www.xemacs.org/list-archives/xemacs-beta/200010/msg00264.html AP> This is correct operation - when you click on a button, the button gets AP> focus as it should do. You should then be able to tab around buttons AP> (although this is only implemented in MS-Windows). What is fixed is the AP> focus being dropped when the button goes away. It might be "intended", but I'm not sure about "correct". It certainly fails the "least surprise" test, at least in my opinion. Let's say I'm changing the foreground color of a face. I type in the name, hit Set, and then want to try a different color. I can't just hit backspace and start editing - I have to click (or move out of the frame and back in) to regain focus before typing. That just ain't right. -JT

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

-- Andy Piper <andy(a)xemacs.org&gt; spake thusly: <snip> <snip> I was wondering whether this ongoing discussion is related specifically to behavior under windows, or whether you were proposing that this should be the behavior for XEmacs on all platforms. If the former, I agree completey. In dialogs, Windows always leaves focus on the last button clicked. I agree with Stephen that this is foolish behavior, but it makes sense to me to remain consistent with the rest of the platform. I don't see a need to bring that behavior over to X, though.

At 14:18 06/01/01 +0900, Stephen J. Turnbull wrote: So to get the behaviour that John wants I have to do some very XEmacs-specific kludging. This indicates to me that the behaviour of custom is wrong rather than the behaviour of the widgets. I am not a GUI expert so I am happy to see a standards document indicating otherwise, however, I am wary of putting kludges in just because it "seems right" or "used to work that way" - neither of these will be true for new users. We must try and comply with GUI standards as much as possible. I can put a kludge in to change this for custom - but this mustn't be the default because then dialogs will behave very weirdly. But then IMHO custom should behave like dialogs. What you suggest will not affect whether a widget gets focus when you click on it. Ben wanted :initial-focus and :focusable. This seems ok to me - but yes waiting for Ben is probably a reasonable thing as he already has strong opinions on this. andy -------------------------------------------------------------- Dr Andy Piper Principal Consultant, BEA Systems Ltd

Andy> I'm confused. I am not doing *anything* to bring this Andy> behaviour to X - it is simply the *default* behaviour. If it Andy> wasn't the default behaviour on both platforms then I would Andy> be less worried about doing XEmacs-specific kludges. *Sigh* Andy is absolutely, 100% correct. IMHO, the standards are just plain broken, but he _is_ implementing the standard (by accepting the default behavior of the components). I can't speak for MS Windows, but here's what the Motif Style Guide (v 1.2) says about the matter (http://www.premier.sco.com/guide/MotifStyleGuide/en_US/Mouse-Based_Naviga...): Mouse-Based Navigation In mouse-based navigation, the mouse is used to move the focus among controls. If an implicit focus policy is in use, the keyboard focus simply follows the mouse pointer, and no other explicit action is required to change the focus. With an explicit focus policy, pressing BSelect on a component must move focus to it, except for components that are used to adjust the size and location of other elements, such as ScrollBars. Pressing BSelect on these components need not move the focus. If not, after the mouse has acted on the component, the focus should remain on the component that previously had it. Pressing BSelect will also generally perform some selection or activation operation. Clicking [CTRL] BSelect on an activatable component can move focus to it without any other effect. The only exception to the simple model of pointer navigation is a Menu system.... Note that "implicit policy" is Motif-ese for "focus-follows-mouse", "explicit policy" means "click-to-focus." BSelect is Button 1. "Component" clearly does refer to things as small as buttons. (Unfortunately, I'm actually going to have to _buy_ anything more recent than that---this alleged leading national university in computing research doesn't have a single book on CDE or CUA, and nothing on Motif or X more recent than 1994, in its library system.) Neither GTK nor GNOME apparently has a style guide. However a little experimentation with standard dialogs in apps like The GIMP and Gnumeric has convinced me that they all behave in the same way: buttons hog focus. To Andy and Custom implementors: some food for thought. It seems to me that a general rule in interface design for Ye Olde Emacser is to avoid isolated buttons like the plague. All of the modern components (combi boxes, toolbars, option menus, ...) _give up focus_ (or reassign it from a button subcomponent to a text subfield) when used. I don't notice these. You see the same behavior in MS Windows; the more modern, complex widgets (like the filesystem Explorer) integrate their buttons and widgets with a complex keyboard interface. Isolated buttons (Apply, Cancel, the rename button in the GTK file selector dialog, etc) do hog focus, and irritate the hell out of me. The point is that apparently modern widget designs are using the "menu exception" provided by the Motif Style Guide wherever possible. -- 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."

Andy> I'm confused. I am not doing *anything* to bring this Andy> behaviour to X - it is simply the *default* behaviour. If it Andy> wasn't the default behaviour on both platforms then I would Andy> be less worried about doing XEmacs-specific kludges. SJT> Andy is absolutely, 100% correct. IMHO, the standards are just plain SJT> broken, but he _is_ implementing the standard (by accepting the SJT> default behavior of the components). I can't speak for MS Windows, SJT> but here's what the Motif Style Guide (v 1.2) says about the matter SJT> (http://www.premier.sco.com/guide/MotifStyleGuide/en_US/Mouse-Based_N SJT> avigation.html): my apologies, Andy - thanks for finding that, Stephen [snip] SJT> It seems to me that a general rule in interface design for Ye Olde SJT> Emacser is to avoid isolated buttons like the plague. All of the SJT> modern components (combi boxes, toolbars, option menus, ...) _give up SJT> focus_ (or reassign it from a button subcomponent to a text subfield) SJT> when used. I don't notice these. You see the same behavior in MS SJT> Windows; the more modern, complex widgets (like the filesystem SJT> Explorer) integrate their buttons and widgets with a complex keyboard SJT> interface. SJT> SJT> Isolated buttons (Apply, Cancel, the rename button in the GTK file SJT> selector dialog, etc) do hog focus, and irritate the hell out of me. SJT> SJT> The point is that apparently modern widget designs are using the "menu SJT> exception" provided by the Motif Style Guide wherever possible. I agree with this assessment -JT