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

[Gregory Merchan <merchan phys lsu edu>]

On Thu, Apr 22, 2004 at 06:21:48PM +0200, Lubos Lunak wrote:
> On Thursday 22 of April 2004 16:36, Gregory Merchan wrote:
> > On Thu, Apr 22, 2004 at 02:41:44PM +0200, Lubos Lunak wrote:
> > >  Hello,
> > >
> > >  ok, this took same time :-/ (releases, releases). But now I have a fully
> > > working (I hope) implementation. The kdelibs+KWin patches are already in
> > > KDE CVS HEAD, attached is a Qt patch that might be useful to you, and a
> > > patch for the spec.
> >
> > If you just use the WM_TAKE_FOCUS protocol and the globally active input
> > model
> 
>  Hmm. This could explain why I originally modelled it after WM_TAKE_FOCUS 
> while now it doesn't resemble it much, I guess I forgot some things during 
> the long pauses when implementing this, or perhaps I realized new ones.
> 
> > > - the WM receives the reply, and does what it would otherwise do right
> > > when getting the ButtonPress (unless there was another raising/activation
> > > meanwhile as a result of the mouse events)
> >
> > Either there is no reply to the WM, in which case it does nothing, or the
> > the WM receives the FocusIn event, in which case it raises/highlights the
> > window.
> >
> > >  Looks simple, and seems to be working.
> >
> > Is simple. Works. :-)
> 
>  Does it? I'll have to think this over again, but right now I wonder:
> 
> - 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})

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

I mention Windows because it's interesting to note that Windows isn't
dramatically different from X in this regard - mostly the programmer
expectations are different. Also, noting the similarities could make it
easier to win programmers. Both Qt and Gtk+ have Win32 backends - so 
there may be an opportunity to simply some toolkit code. Some code
in Mozilla's X11/Gtk+ backend seems to have been written expecting
more similarity to Windows - which I think explains some of their
focus bugs. Last I checked, they were failing to override recent changes
in Gtk+'s focus handling.

There are two fallback timestamps for the WM to focus the window. The
first is _NET_WM_USER_TIME which the app would set on the new window -
probably to the same time it would use if it called SetInputFocus itself.
The next fallback is one that you should always be able to get: the one
in the PropertyNotify generated by the WM changing WM_STATE.

Cheers,
Greg