Re: raising windows on button release

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
 - wether a click on a focused window should raise it
 - wehter the same is done for clicks the decorations and/or the
 - 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.


Dominik ^_^  ^_^

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]