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

[Lubos Lunak <l lunak suse cz>]

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.

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

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