Re: raising windows on button release

[Dominik Vogt <dominik vogt gmx de>]

On Sat, Aug 10, 2002 at 11:22:44PM +0200, Dominik Vogt wrote:
> On Sat, Aug 10, 2002 at 02:37:20PM -0400, Havoc Pennington wrote:
> > 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?

I forgot to list what options we have in fvwm, the user can chose


 - the button(s)+modifiers to raise/focus a window on click
 - wether a click on an unfocused window should raise and/or focus
   it
 - wether a click on a focused window should raise it
 - wehter the same is done for clicks the decorations and/or the
   icon
 - to pass the click that focused the window to the application
 - to pass the click that raised the window to the application
 - to recycle these clicks for other bindings (resizing)
 - if windows without the input_hint set should still receive the
   focus normally
 - if click-dragging should be ignored in terms of
   raising/focusing or not

The click-drag part should be good enough.  I can't think of an
application that needs to handle click-drag itself at some places
and relies on the WM to raise it when that happens at other
places.  Two realistic (?) use cases come to my mind:

 * The user always stops the pointer before clicking in a window.
   (S)he won't have any problem with the ...IgnoreMothing thing.
 * The user moves the pointer at full speed when clicking in
   windows to raise/focus them.  This user could configure the
   applications where (s)he needs click-drag like the other user
   and configure the other windows to not pass the mouse motion
   to the window.  Not perfect, but should work resonalby well for
   most users.

Bye

Dominik ^_^  ^_^

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