Please strip out the patch that brings up applications behind gnome-terminal

[Jeff Spaleta]

On 2/1/06, Jonathan Corbet <lwn-fedora-test at lwn.net> wrote:
> When I type "ooffice file.odt &" it doesn't mean I want to stop all work
> on anything else until openoffice gets around to talking to me.  if I
> type "gthumb image.jpg &" it means I want to see the image, but I don't
> necessarily want to type at it.  I have to say that the new focus
> behavior has improved my life considerably.  I hope it doesn't go away.

No, it shouldn't go away.  It addresses the fundamental problem that
its trying to address... sadly it seems to treat the terminal as a
special sort of window... which is a hack. The problem is that its
impact situations it wasn't designed for.  Metacity just needs to get
a weebit smarter when trying to determine if/when to engage the
automatic focus protection.  With it strictly on  or with it strictly
off, this feature (or lack of the feature depending on your pov) has
usability issues.  Why is that? because the terminal does not fit in
Gnome's usability model at all..and it will never fit. The terminal is
a square peg in gnome's round hole.  I think its absolutely pointless
for gnome to be spending any cycles trying to shoehorn terminal
interaction into its usability model as a special case. Just leave the
terminal alone and go back to focusing on keeping your target users
out of the terminal all together. Once a user drops into a terminal to
do anything they are outside the design scope of Gnome's target and
Gnome needs to recognize that and stop trying to special case the
terminal.  Keep the implemented features inside the scope of the
design target and stop over-reaching into cli interaction as a special
case.

If there is a way forward as the terminal as a special case, and I'm
not sure their should be, I think the way forward is trying to train
metacity to understand if the terminal is in "active" use. The
protection afforded by the focus stealing protection makes a lot of
sense when you narrowly define the problem as making sure that
actively typed input for the terminal doesn't get stolen by a newly
mapped window.

But once you start dealing with situations where you launch an
application and the terminal recieves absolutely no keystrokes from
the moment the new application launch is initiated in the terminal,
the feature is outside of its original design scope and gets in the
way of how some terminal users expect things to work.   Again I will
note that users who prefer the terminal to get crap done are NOT the
target audience for the gnome desktop at large.

In my perfect world, this protection feature would have some sort of
built in activity metric to try to make sure that focus stealing
protection would only engage if the terminal was in active use.  If I
lauch openoffice from a terminal and I don't send the terminal an
input for several seconds.. why should focus protection engage?  Why
exactly should the terminal stay on top?
The terminal is a very flexible interface that is outside the scope of
the Gnome design target and making assumptions about "typical" usage
of the terminal by people who prefer to use the terminal instead of
desktop centric methods can not justified inside the scope of gnome's
overall design focus.

I can imagine making metacity smarter two different ways. One way is
to have it keep a time measurement of time since last input to the
focused window and if the time is "too short" the window keeps focus
when a new window is mapped. "too short" would have to be fine
tunable.  The problem here is if "too short" isn't long enough, you
won't be solving the original problem of protection. The newly mapped
window might show up too quickly for this method to be effective at
preventing focus stealing.

The other way around it is to have the focused terminal window always
keep focus when a new window is mapped and then let metacity start
watching for input into the focused window. If there isn't input for
"long enough" after the mapping of the new window then metacity gives
focus to the newly mapped window (a short pre-defined time after its
mapped).  "too long" would have to be fined tuned.  If a new window is
mapped quickly this method doesn't have a problem... metacity waits a
pre-defined amount of time to switch focus to that window. Example
assuming metacity waits 2 seconds looking for input to the terminal:
*using a terminal and you launch vncviewer from the terminal but there
is no input into the terminal window from the moment vncviewer is
lancuhed
*the vncviewer password window is mapped in under a second and pops
under the focused terminal window, hidden from view
*metacity is configured to wait a 2 seconds before switching focus so
the terminal window and holds focus on the terminal window for 2
seconds seeing if there is any keyboard input into the terminal.
*seeing no keyboard input, metacity changes focus to the newly mapped
password entry window appears

This allows the terminal to keep focus if and only if its being
actively used for input in the pre-defined amount of time after a new
window is mapped. newly mapped windows will not get in the way of
active terminal input AND just as importantly terminal users expecting
newly mapped input windows won't have to go hunting for them if they
aren't actively using the terminal. All they have to do is wait a
short amount of time and the inactive terminal loses focus and goes
down in the stack.  Any keyboard press while the terminal is in focus
during that short period of time will cause metacity to retain focus
for the terminal.. so users who want to retain focus simply have to
ping the keyboard with a keystroke.  Everyone wins.. without touching
the mouse.

if we want the terminal to always stay on top... metacity can
re-impliment the per-window "stay on top" feature which it had at one
point (which many window managers have). Always keeping the terminal
on top regardless of input activity into the terminal is a
preferential abuse of the focus stealing protection feature to mimic
"stay on top" stacking behavior just for the terminal. If "stay on
top" is going to be implemented...implement it in a more general way
so ALL input windows can make use of it.  I think its rather
short-sighted to suggest that terminals are the only things which
deserve the "stay on top" protection as compared to other types of
input spaces.  Considering that Gnome is focused on keeping their
target users away from the terminal as much as possible..
preferentially targetting terminal behavior with window manager
features seems very much outside of the design priorities for Gnome to
me. Stop overreaching beyond Gnome's design. If the terminal
interaction is not the focus of the Gnome desktop.. stop trying to
half-ass constrain how terminal interaction works but instead
implement features which apply equally well to ALL windows which can
take text input.


-jef"the key is respecting the limitations of the design model and not
trying to special case how you treat everything outside of that design
goal... just let the terminal exist and accept the fact that the
details of terminal interaction is not inside the Gnome design
focus"spaleta