Re: raising windows on button release

[Dominik Vogt <dominik vogt gmx de>]

On Sat, Aug 10, 2002 at 02:37:20PM -0400, Havoc Pennington wrote:
> There are some cases where you do not want to raise (or focus) a
> window on click, even though you normally do. For example a click that
> begins a drag-and-drop operation, or a click that selects (or perhaps
> middle-click-pastes) some text should not activate the window.

This is clearly a user preference, not an application preference.
Some users and it this way and some the other way, and probably
different for different applications.  It should thus be
configurable in the window manager.

> In Windows XP you can see this behavior for example, if you start
> dragging an icon in the file manager. I think Mac has the same.
> 
> Nautilus used to have a hack using a Sawfish-specific feature; IIRC
> the hack went like this:
>  - a window could have a special WM_PROTOCOL indicating it 
>    would self-raise on click
>  - Sawfish wouldn't ever activate the window in that case
>  - the window would activate itself if it decided the click 
>    wasn't on an icon being dragged

Oh no, not *another* protocol for focus handling.  It's difficult
enough already.  Eh, wait a minute ... you've reinvented the
WM_TAKES_FOCUS protocol :-)

> I've considered solving this by just moving the activate from button
> press to button release in the window manager, and not activating if
> the release is outside the window (i.e. if the release drops a drag
> elsewhere).
>
> I'm not sure if this will break stuff though. It's also
> not quite optimal behavior, as one would like to activate on click
> immediately, if appropriate.

To see the difference yourself, download the latest fvwm sources
from CVS with 

  $ cvs -d :pserver:anonymous cvs fvwm org:/home/cvs/fvwm login
  (password: guest)
  $ cvs -d :pserver:anonymous cvs fvwm org:/home/cvs/fvwm checkout fvwm

(you really need the latest sources, no guarantees otherwise).
Start it with "fvwm -f /dev/null" then open a couple of xterms
from the root menu and an FvwmConsole via the "Issue fvwm
commands" menu item.  On the console window, type

  Style * SloppyFocus
  Style * mousefocusclickignoremotion
  Style * MouseFocusClickRaises

Then try clicking in windows to raise them or click/drag to make a
selection.  It's a bit irritating if you're used to raising
windows immediately, but since you can't do much else with a
button pressed I guess you can get used to it.  To turn that
option off, issue

  Style * mousefocusclickignoremotionoff

The code works like this:

 * Let's assume the ...ignoremotion style is active.
 * When a button is pressed, fvwm gets an automatic grab of the
   pointer on the parent of the client window.  No further mouse
   events are reported to fvwm or the app.
 * The pointer is released and the click and motion events are
   reported to both, the application and fvwm.  Of course this can
   be hazardous, but I can't think of another way.
 * The pointer position is queried in a loop.  The loop exits when
   one of three conditions is met:
    - the pointer moves to a different screen
    - the pointer moves by more than a few pixels (configurable)
    - all buttons are released
   You can't simply read events from the input queue because they
   might be needed later and can not be properly put back to the
   correct place in the queue.

Unfortunately that enforces that the raise click is passed to the
application before it's clear wether the app should get it or not.
  
> You also have the problem that if a window has the "self-activating"
> WM_PROTOCOL set and the WM doesn't have activate-on-click enabled,
> things are sort of broken.
>
> Has anyone else thought about this issue?


Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, dominik vogt gmx de
Reply-To: dominik vogt gmx de