Phew, so much traffic, so much misinformation, so much real work to
do, so many hunger pangs. Well, I'll just dig in and try to remain
calm... :-)
SR> A reasonable thing to do, but only if you ask the tens of
SR> millions of Windows and Mac users and billions of non computer
SR> users to vote too.
Ah, but do Mac and Windows users have a choice? You can't even ask
such a question if they don't. Here's one, of all the Windows users
that have tried Xmouse, how many like it and how many don't? It's
still probably a useless point to argue, unless you really don't care
about selling product to pointer-focus users.
SR> Actually, early research at Apple clearly showed that the
SR> opposite was more likely to be a problem, usually because a
SR> dialog opened. For example, the naive user's first reaction
SR> when a file selection dialog opens should be to attempt to
SR> type in a file name. This only works if the dialog gets the
SR> focus when it's opened.
I agree so far.
SR> Unless you want to head down the slippery slope of pointer
SR> warping, this means explicit focus.
Here's where I disagree (details to follow). And I think this
assertion is the crux of the current flamewar.
SR> Your confusion was undoubtedly due to the situation where
SR> you've got multiple xterm windows open, since the opposite
SR> problem occurs when you've got a modern GUI application (and
SR> by that I mean one that uses dialogs and palettes).
This is a red herring. Let's instead talk about multiple disjoint
applications, by which I mean separate processes in the Unix sense
each with their own window, and a single process that can display
multiple windows. So now we have two situations:
- Switching focus between processes requires the help of the window
manager. You can't solve this problem by advocating either focus
model without focus grabs, pointer warpage, complex IPC's or other
nasty things. I don't really see how explicit focus could make
anybody's life easier (or harder) in this situation.
- Switching focus between windows in a single, multi-window process.
This can be done under X with pointer-focus policy and no pointer
warpage or focus grabs. I have two existance proofs: 1. In XEmacs,
I can by way of keystrokes, create a bunch of new top-level window
(i.e. ones whose parent is the FVWM root window). By another couple
of keystrokes I can switch focus back and forth between any of these
windows. 2. In Grail, I can by way of keystrokes, pop up the
Bookmarks dialog. By another few keystrokes I can traverse around
in the bookmarks tree, opening and closing nodes, even triggering
Grail to visit a URL. I can popup further top-level windows which
allow me to change bookmark entries via a little form dialog. When
I hit return in the form dialog, my edits are applied and focus
returns to the bookmark dialog. I hit return again, my bookmarks
get saved, the dialog gets withdrawn, and focus returns to my main
browser window.
IN NEITHER CASE IS THE POINTER WARPING ONE MILLIMETER!
SR> It's still amazing to me that people who work primarily with
SR> the "stone age" version of GUI technology (xterms) have the
SR> nerve to stand up and say that pointer focus is superior and
SR> should be the default.
Oh, please. Come on, admit it, you're trolling! I'm going to ignore
those snide remarks from now on.
SR> Well, in *true* pointer focus there is no keyboard traversal
SR> at all, you have to move the mouse into each field in turn to
SR> fill out a form. I don't see too many people advocating we go
SR> back to *that*. Its about time we take the next step, or at
SR> least reduce the incidence of corruption of new users by
SR> making the default explicit focus.
How do you go from your "*true* pointer focus" to default explicit
focus? You're completely ignoring the model where pointer location
designates the application that receives keyboard events, and the
application is free to redirect window focus to any top level window
under its control. This is what XEmacs does. This is inherent in Tk,
and thus Grail gets it for free (I take no claim for doing anything
more than reading the manpage and playing with some Python code to
understand what's possible :-).
SR> No, you click on a button (or choose from a menu, or activate
SR> a menu item with a mnemonic or accelerator) and it opens a
SR> dialog that gets the focus. You then type whatever you want
SR> and then close it by pressing return, upon which the dialog
SR> closes and focus returns to the application window that had it
SR> before.
Sounds cool to me.
SR> This is the most standard operating method of modern GUI
SR> applications, and it just doesn't work very well with pointer
SR> focus.
I must really be misunderstanding you, because I have no problem with
this in properly written applications using pointer focus. I really
would like more detail on exactly what you think is the problem.
Me> and even as separate top level windows pop up and down
Me> (e.g. to interact with the Bookmarks, History, or File
Me> dialogs), focus is managed correctly to the subwindows without
Me> ever having to move the mouse (as long as its one of the
Me> application's top level windows), even with pointer-focus.
SR> How, by warping the mouse?
Nope. Tk has a number of focus management commands and it imposes its
own rational focus management policy on the toolkit. I won't
reproduce the entire Tk focus.n manpage here, since its free software
and you can get it and read it yourself. Suffice to say that if I
have a window `.w' I can redirect focus to it with `focus .w' (well I
think I've accurately translated the Python equivalent into Tcl :-).
In Python, if `frame' is a Tkinter.Toplevel instance, then
frame.focus_set() redirects focus into the window.
SR> XEmacs is a pretty poor example of good UI design IMHO. It's
SR> very efficient to work with (we use it here), but if you tried
SR> to sell it to a Mac or Windows user they'd laugh you right out
SR> of town.
First, we're not talking about overall UI design, and besides I think
XEmacs is well designed given what the application is. It (more so
than FSF's Emacs IMHO) is one of the few applications that works
pretty well for novices but adapts to users as they gain their power
through experience. And second, it sure is funny how many Mac and
Windows users I've heard, who need a such a powerful integrated
programming environment ask for Emacs on their platforms. Oh well,
that's all tangential to the discussion at hand.
Me> Nope, its just that not all applications manage active focus
Me> correctly. Its one of the main reasons why I can't stand
Me> Netscape on I hit Meta-O and the dialog that pops up doesn't
Me> get focus.
SR> I see, let's take the only decent UI that the vast majority of
SR> X users have ever used and ruin it because it doesn't work
SR> well with the environment that works well with xterm windows.
Netscape or MSIE are probably the applications that most inexperienced
computer users are familar with. I might argue about their decency,
but the specific problem I describe above is not inherent in the focus
policy. It's either present because the toolkit they use is buggy, or
the application doesn't manage focus properly, or it was an explicit
design decision not to support this, or they just haven't gotten
around to ironing out its use for power users (or all their internal
power users really use Grail instead, but won't tell anybody :-)
SR> Your argument goes *exactly* to my point: users new to
SR> computers are much more likely to use Netscape than they are
SR> to use xterms. Fvwm should come with the defaults set to take
SR> this into consideration.
Fvwm has nothing to do with it. If, when the Open Location dialog was
popped up, Netscape redirected its application's focus to that window,
the problem would be solved. It *can* be done with pointer-focus
policy, no pointer warping, no server grabs, and no need to pop the
window up under the cursor. Your application, or toolkit, just has to
provide the right kind of focus management policy. Maybe that's hard,
but that's an engineering problem, not made impossible by the design
of pointer-focus policy.
Me> It was nearly trivial for me to add this to Grail, *and* to
Me> move focus back to the original window when finished
Me> interacting with the dialog.
SR> How?
See the explanation above. Read the Tk manpages. Read the Tk source
or the XEmacs focus management source. I encourage you to download
Python, install and Tk and play with it, and see for yourself. As I
say, I'm not an Xpert so I can't tell you what's happening under the
hood.
SR> So you're saying that application vendors have no right to
SR> expect any sort of standardization of desktop environments?
SR> Hope you like hand building all your applications...
So are you saying users have no right to customize their desktops to
increase their productivity?
> This is commonly done using an application-modal keyboard grab
> so that you don't have to move the pointer to type in the
> window. It can also be done via warping the mouse or popping
> the dialog box up underneath the pointer.
SR> Neither of these are practical, the first because warping the
SR> pointer violates all GUI style guides (other than the finally
SR> obsolete OpenLook), and the second because it could result in
SR> the window opening partially off screen.
Agreed on both points.
SR> I wasn't trashing his app, in fact it sounds very well
SR> implemented. But I found it strange for him to be citing an
SR> app as an example of how things should be done when it
SR> obviously took considerable effort to make it work like
SR> Windows and OS/2 and Motif applications are *required* to, and
SR> have been for years. If he didn't have to spend so much time
SR> fighting with pointer focus, he could have implemented some
SR> really cool new features instead.
Funny. All I had to do was read the Tk manpages. :-) Ousterhout did
the fighting for me. Which is great because I (and the rest of the
Grail team) could implement lots of really cool new features.
SR> And I certainly wouldn't claim that Netscape is perfect, but
SR> it *is* Motif compliant which can't be said for xterm or most
SR> other apps (including most Tk apps) that X users end up using.
All I can say here is that if the Motif toolkit doesn't allow you to
manage focus as flexibly and rationally as the Tk toolkit does, then
either the Motif toolkit implementation is buggy, or the Motif
specification is broken. I suspect neither is the case, but I have
never written a Motif-toolkit based application so I wouldn't know.
It certainly isn't an inherent property of X, or other X-compatible
toolkits.
Not to say Tk is perfect, but at least for focus management it
provides exactly the abstration you need.
Time to go home. I'm hungry. :-)
-Barry
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Wed Oct 23 1996 - 20:03:40 BST