Re: Proposal for a smarter behavior for raising windows on mouse click (#2)
- From: Gregory Merchan <merchan phys lsu edu>
- To: Lubos Lunak <l lunak suse cz>
- Cc: wm-spec-list gnome org
- Subject: Re: Proposal for a smarter behavior for raising windows on mouse click (#2)
- Date: Thu, 22 Apr 2004 09:36:17 -0500
On Thu, Apr 22, 2004 at 02:41:44PM +0200, Lubos Lunak wrote:
> 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
> 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
> - user presses mouse button on the window (inside it)
> - instead of raising/activating/whatever the WM would normally do, it sends
> the client a _NET_WM_TAKE_ACTIVITY  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. so it doesn't do anything, and therefore there will be no
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
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
> 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
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.
] [Thread Prev