Re: outstanding issues (widgets and keyboard focus)

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