[580] in Athena User Interface

home help back first fref pref prev next nref lref last post

focus

daemon@ATHENA.MIT.EDU (yak@MIT.EDU)
Thu Jan 4 17:36:35 2001

From: yak@MIT.EDU
Date: Thu, 4 Jan 2001 17:36:32 -0500
To: aui@MIT.EDU
Message-ID: <20010104173632.A2824@manatee.mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

When I was originally configuring sawfish, I was of the opinion that
click-to-focus was the right thing, and that "raise window" and "focus
window" should be the same operation.  This is how every non-X gui I
have ever seen handles things, and I think it makes the most sense.

Uhfortunately, I ran into some trouble getting click-to-focus to behave
itself.  One problem is the slow application startup thing, where your
keystrokes are unintentionally grabbed by a program you launched
sometime in the past.  MacOS solves this by doing a focus grab whenever
the execve(2) equivalent is called from the application with the focus,
so keystrokes may be lost while an app loads, but they will never end
up in the wrong place.  This is not a reasonable solution under unix
because the assumption that every process has a GUI is not a good one.

Sawfish does have some code to try to determine when a window should be
autofocused and when it should not.  For example, you can configure
sawfish to only give new windows focus when the new window is a
transient and its parent has the focus.  This will DTRT with properly
written "Save..." dialog boxes and the like.

Another problem I had was with zephyr handling.  If you do
click-to-focus, and link raising to focusing, and do autofocus, then if
zephyrs are stacked at depth 0 (the default), zephyrs will be
constantly stealing your focus away from you.  If you set dont-focus on
zephyrs, then the focused window will always be on top of your zephyr
stack.  If you set the depth to some number greater than 0, then
zephyrs wiill always float above your focused window.  I have not
figured out a solution to this problem; the recent traffic was rightly
critical of the unsatisfactory solution that I most recently left
installed.

My final conclusion was that X was simply not designed for
click-to-focus, and that attempts to force the issue would come off as
crude and confusing.  In the limited case of transients, sawfish does a
reasonable job of deciding when to give new windows focus, but in other
cases, to my disdain, I think that enter-exit or enter-only would be
superior.

yak

home help back first fref pref prev next nref lref last post