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