Re: Proposal for a smarter behavior for raising windows on mouse click (#2)

[Elijah Newren <newren math utah edu>]

On Mon, 2004-04-26 at 16:59 +0200, Lubos Lunak wrote:

> > I was hoping you didn't mean sloppy/mouse focus. :-)  The patches I
> > submitted for Metacity check the focus mode and do nothing if it isn't
> > click-to-focus. Also, with the patches, metacity still raises on frame
> > clicks. There's no consensus among sloppy/mouse focus users as to when a
> > window should be raised. Some say raise on focus, others say raise on any
> > click, and others say raise only on frame click.

This may be going off topic, but let me attempt to shed some light on
this issue.  I have spent considerable time using sloppy/mouse focus and
have forced myself to learn/relearn habits three or four times in
switching between raise-on-click and do-not-raise-on-click environments
and then using the new environment for several months/years.  (I haven't
used auto-raise or raise-on-focus or whatever you want to call it, but I
believe people already understand the issues surrounding it anyway)

I believe what you are noticing is merely a really noisy minority that
actively and vocally protests a certain raise choice, and because of
their vocalness, appears to be a much larger group than they really are.
Let me attempt to explain:

Clicking on a window is a way of signifying that the user wants to
interact with a window.  Most users, especially beginners, would find it
confusing to interact with a partially obscured window, and thus would
find it unintuitive to have clicking on a window not raise it.

However, do-not-raise-on-click, though unintuitive, allows for a certain
type of efficiency.  Often there is only a certain part of a window that
is interesting or needed in order to work with it.  Users can thus
heavily overlap windows with an aim to minimize the amount of distance
the mouse has to travel between windows when working.  This also allows
a greater number of windows to be used simultaneously and makes the
screen feel bigger.  This probably sounds crazy to anyone who hasn't
used it, but it becomes second nature to someone after using it for a
while.

Now, the reason people get so noisy about this option is that people
learn subconcious habits about how to place their windows.  With
do-not-raise-on-click, people are aggressively overlapping windows.
With raise-on-click, people tend to overlap windows far less and
sometimes don't overlap at all.  Put someone used to a
do-not-raise-on-click environment in a raise-on-click environment and
they'll be really frustrated because their placement of windows will be
extremely sub-optimal for working and switching between windows.  They
will have to relearn habits, and, even worse, they won't even realize
that they have habits to relearn.

> > Only this last policy works with the WM_TAKE_FOCUS method.
> 
>  There's a silent yet convincing voice in my head telling me that the option 
> more benefiting my personal safety is the one that prefers the existence of 
> mouse focus policies over working WM_TAKE_FOCUS. As such, I'm afraid I have 
> to consider your solution as insufficient and go with my proposal, unless 
> there's something better.
> 
>  What's the opinion of others on this?

Personally, I plan to implement your proposal in Metacity after some
other things clear off my plate--unless someone else does it first.
Without commenting on your reasons (I'm not that familiar with
WM_TAKE_FOCUS and am still a newbie to window managers), I really think
that this capability should be offered for all focus modes and Gregory
has stated that his proposal will not support this capability for
anything but click-to-focus.  (Also, for what it's worth, Rob appears to
agree on the implement-for-all-focus-modes point, or at least he did in
his last comment to http://bugzilla.gnome.org/show_bug.cgi?id=80984)

> > >  That sounds too much like potentially breaking WM's focus policy. If the
> > > focus policy will be e.g. focus under mouse, this will either break it,
> > > or the WM will have to try hard to fix it (sadly there's no redirecting
> > > of SetInputFocus a'la MapRequest).
> >
> > This is where sloppy/mouse focus conflicts with the way GUIs have been made
> > for almost 20 years. When Apple found that sloppy/mouse focus would more
> > often than not cause user mistakes, that lead them to certain design
> > elements which more or less depend on click-to-focus - e.g., the Mac menu,
> > floating palettes, and dialog modes that constrain user interaction with
> > the applications to one its windows. Since every GUI since has copied some
> > of these elements - often without understanding - they all have a more or
> > less weak dependence on click-to-focus - whether or not that's acknowledged
> > by anyone.
> ...
> > If there is a way to make sloppy/mouse focus usable, then I believe we're
> > so far from discovering it and making the necessary design changes that
> > it is not worthwhile for the major free desktop projects to pursue it.
> > Whatever it is, it will almost certainly be radically different from
> > everything we've used for the last 20 years and would have very little
> > appeal to most people as they tend to prefer stasis over even an obvious
> > improvement. The preference for stasis itself makes it hard to convince
> > current sloppy/mouse focus users to switch - it took me a few months to
> > switch and I still wonder whether there's a way to make sloppy/mouse
> > focus work.
> 
> I wonder if I'd manage to find a single user of mouse focus policies who'd 
> admit that they're broken in design. Yes, I know a couple of issues with 
> them, but I guess people using them would consider them normal bugs rather 
> than design problems. And while I'm a click-to-focus person myself and don't 
> have much love for mouse focus policies, I currently don't see any reason for 
> removing (or anything similar) of the mouse focus policies, at least the 
> somewhat reasonable sloppy focus one.

I'm only aware of two issues, and I consider them to be very minor.  But
maybe I'm not aware of other issues.  I'm willing to admit sloppy/mouse
focus is broken in design if someone can provide me with specifics about
inherent problems that this choice causes.  The two things that I am
aware of are:

1) Sloppy focus (meaning focus on mouse entry but do not defocus on
mouse exit) suffers from a little bit of a discoverability problem for
users.  Mouse focus (meaning the same thing as sloppy focus with the
exception of also defocusing on exit) solves this problem.  However,
users that have experience using another computer windowing environment
are accustomed to being able to move their mouse outside the window and
still work with it, which conflicts with mouse focus.

2) Sloppy/mouse focus doesn't work well when used simultaneously with
keynav, because there tend to be race conditions.  Of course, I think
the whole point of keynav is to not use the mouse, so it's pretty easy
to keep the two separated by a long enough time that these issues don't
arise.

The first issue can't be cleanly solved because one can't assume that
new users haven't used previous windowing environments.  However, it's
not an especially steep learning curve in either case and presents no
problems to anyone already familiar with either.

I believe the second issue could be solved by enforcing at least a short
time separation between the two kinds of uses and by providing a cue to
the user.  The best cue I can think of would be making the mouse
disappear when keynav is used and then have it reappear when the user
starts using the mouse.  Can anyone see any problems with this approach
(I have only looked into it a little bit)?

> BTW, there's one more thing I don't like much about WM_TAKE_FOCUS (and your 
> proposal). I see focus as one of the shared resources handled by the window 
> manager. Letting the apps to decide when and how they'll set the focus moves 
> the responsibility for this resource away from the window manager.

I have to agree with you there.


Elijah