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 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
this is:

>  I changed a bit how it works, so now it is:
> - apps specifies that it supports the protocol

... by listing WM_TAKE_FOCUS in WM_PROTOCOLS and setting WM_HINTS.input_hint
to False.

> - user presses mouse button on the window (inside it)

Same.

> - instead of raising/activating/whatever the WM would normally do, it sends 
> the client a _NET_WM_TAKE_ACTIVITY [1] message

The window manager does nothing. It doesn't grab the button for globally
active windows, so the click goes on to the client.

> - the client saves the message and waits for next ButtonRelease

The client saves the timestamp from the ButtonPress.

> - if the mouse hasn't moved, the client sends the message back (the same way 
> _NET_WM_PING works), otherwise it was DND, moving a scrollbar, selecting text 
> etc.[2] so it doesn't do anything, and therefore there will be no 
> raising/activating

If the ButtonPress could not start a drag, or selection, or the like, the
client calls SetInputFocus with the timestamp from the ButtonPress event.

If the ButtonRelease occurs and no drag, selection, or the like has started,
the client calls SetInputFocus with the timestamp from the ButtonRelease
event.

If between the ButtonPress and ButtonRelease a drag, selection, or the like
has started, the client does nothing with regard to focus.

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

With WM_TAKE_FOCUS, a globally active window, and this scheme, the meaning
of the WM_TAKE_FOCUS message is, "the user has done something outside of
the client area which should cause the client window to be focused." That
user action could be a titlebar click, a proxy button (taskbar) click,
Alt+Tab or some other WM-grabbed key event, or a crossing event (for
sloppy/mouse focus).

The patch for Metacity is two lines (modulo tidyness) and already in
GNOME bugzilla. The patch for Gtk+ is more complicated because Gtk+
quite strictly uses the locally active input model (with one exception),
Owen wants an API simpler than handling ICCCM stuff, and there's also
the Win32 backend. A large portion of the patch is also filed.

I had demos for Gtk+ though they used a bad hack to get around Gtk+'s
abstraction. A recent change to Gtk+ has made a demonstration impossible.
Seth Nickell was one of the few people to see the demos work when they
did, so you can ask him for confirmation. The meta-bug for this is #133047.

  http://bugzilla.gnome.org/show_bug.cgi?id=133047

Cheers,
Greg