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

[Lubos Lunak <l lunak suse cz>]

On Saturday 24 of April 2004 19:47, Gregory Merchan wrote:
> On Fri, Apr 23, 2004 at 09:29:47AM +0200, Lubos Lunak wrote:
> > On Friday 23 of April 2004 05:31, Gregory Merchan wrote:
> > > On Thu, Apr 22, 2004 at 06:21:48PM +0200, Lubos Lunak wrote:
> >
> > [snip]
> >
> > > > - How does the WM exactly know whether to also raise on FocusIn or
> > > > not? It obviously can't do that everytime.
> > >
> > > It's only a subset of FocusIn events that count - whichever would
> > > ordinarily lead to highlighting the window; i.e., to making the window
> > > look active. (I'm not sure which offhand. I think it's
> > > mode=NotifyNormal and detail = {NotifyInferor|NotifyNonlinear})
> >
> >  You mistunderstood. I know this one of course, I'm a WM developer after
> > all :). What I mean is: What if the WM policy is focus follows mouse, no
> > autoraise, clickraise? Then if the mouse enters the window, there will be
> > eventually FocusIn, which shouldn't cause raising, while FocusIn caused
> > by clicking should raise, according to your proposal.
>
> 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.

 And that's why there's the configuration option for it.

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

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

 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.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l lunak suse cz , l lunak kde org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/