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

[Olivier Chapuis <olivier chapuis free fr>]

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.
> 
>  I changed a bit how it works, so now it is:
> - apps specifies that it supports the protocol
> - 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 [1] message
> - the client saves the message and waits for next ButtonRelease
> - 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
> - 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)
> 
>  Looks simple, and seems to be working.
>

This seems reasonable for me, we have a style in FVWM which do
something similar without application collaboration (if a mouse motion
is detected in addition of a possible raise click, the application is
not raised).  Application collaboration is surely better (e.g., the
application should be raised when you start to draw in gimp).

>  Any comments, flames, questions, is anybody going to try to implement it as 
> well (the Qt patch may help you, it's for Qt-3.3.x)?
> 

On this subject I've investigated a more complex interaction. Click
Raising work like this on my machine (thanks to some not really
regular hack):

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

- The wm detect if the user start a Xdnd drag and drop operation, if
  yes the window is not raised and not focused; the click raise
  interaction is finished.

- So now we know that we are not doing a dnd and the window *is*
  raised but not focused if you are ClickToFocus (I am SloopyFocus).

- At ButtonRelease the wm check if a motion has been performed, if no
  the click raise interaction is finished (and the window is
  focused).

- The wm detects if the motion was a "text" selection, if yes the
  window is put back at its original position in the stacking order
  and you can copy into the raised (focused) window (this is really
  the **good** point, when you start to use this you cannot go
  backward IMHO). If not (e.g., the motion was for scrolling, drawing
  or whatever) the window is put back at its original position in the
  stacking order only when you leave the window; a kind of weak/tmp
  raising (do not know exactly what to do with the focus for
  ClickToFocus users).

I do not claim that this should be the way a wm should handle
clickraising, but it will be good that the protocol allows
such interactions.
 
So, I suggest to add a msg from the Client to the window manager
in your protocol:

- apps specifies that it supports the protocol
- 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 [1] message

- the client saves the message and If the user start a "mouse motion
  operation" the client sends the msg back and indicate in one of the
  data field the type of the operation: 
_NET_WM_MOUSEMOTION_DND
_NET_WM_MOUSEMOTION_TEXTSELECTION
_NET_WM_MOUSEMOTION_SCROLLING
_NET_WM_MOUSEMOTION_DRAWING
_NET_WM_MOUSEMOTION_DUMMY  (not usefull motion)
...?...
_NET_WM_MOUSEMOTION_RAISE (not in the list and the application think
that the application should be raised)
_NET_WM_MOUSEMOTION_NORAISE (not in the list and the application think
that the application should not be raised)

- At ButtonRelease (and whatever happen) the client sends the message
back with _NET_WM_MOUSEMOTION_END in the mouse motion operation type
data field.


This include your protocol but also allows a more fine "click raise"
handling.

Regards, Olivier