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

[Gregory Merchan <merchan phys lsu edu>]

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. Only this last policy works with the WM_TAKE_FOCUS
method.


> > > - Say the click leads to opening a new window. How will you make sure
> > > it's the new window that will be the new active window, given that the
> > > situation with timestamps will get somewhat odd? The WM will have older
> > > timestamp than the application, because MapRequest etc. don't have a
> > > timestamp and the WM won't see the mouse events for this action. This
> > > actually looks like a problem of the globally active input mode itself -
> > > am I missing something basic?
> >
> > I think the simplest way would be for the app to focus its new window; that
> > should be familiar to Windows programmers. It would use the timestamp from
> > the ButtonRelease or KeyRelease that caused it to open the window. As it
> > uses one of the active input models, that's OK by the ICCCM. Similarly, it
> > should set focus back to the parent window before withdrawing something
> > like a dialog by using the timestamp from the event that dismisses the
> > dialog; from what I've read, this has to be done on Windows or else the
> > locked-in WM of GDI will activate whatever is on top of the stack.
> 
>  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.

GUIs might be designed in such a way that they do not depend on click-to-focus,
but to my knowledge there has never been such a design. Even if there were,
that design would have to have some outstanding benefit to lessen the impact
of the errors caused by sloppy/mouse focus - or it would have to make such
errors impossible. They obvious way - well, the only way I know - to eliminate
those errors is to eliminate what user's might recognize as windows. Every
application would be fullscreen and dialog modes would be handled in the
window, maybe like emacs's mini-buffer does. Panels (modeless dialogs) could
be done in a sidebar, like mozilla's, or as alternative screens. Floating
palettes could be done in sidebar, like MSPaint, or toolbar, like MSOffice.
To view documents side-by-side you'd split the view . . . but then you
might as well be using a tiling window manager and the focus mode problem
returns: do you move focus within the application by clicking or pointing?

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.


Cheers,
Greg