Subject: FVWM: Two small questions

From: Stian Sletner <[email-masked]>
Date: Mon, 20 May 2002 13:53:53 +0200

Hello again.  Two small questions.

Firstly, I'm using this setup,

    mouse   1       w       m       function alt-move

    destroyfunc     alt-move
    addtofunc       alt-move
    +               m       move

which allows me to move a window by clicking and dragging from anywhere
within it, using alt.  However, it only works for focused windows (I'm
using clicktofocus, obviously).  Any way I can make it either focus the
window first, or make it work for non-focused ones?

Secondly, I tend to alt-tab alot, and sometimes I do so while moving the
mouse around.  This leads to disaster. :-)  I suppose there's no way
around this, but I thought I'd mention it...

-- 
Stian Sletner
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Marcus Lundblad <[email-masked]>
Date: Mon, 20 May 2002 14:14:54 +0200 (CEST)

> around this, but I thought I'd mention it...

I can confirm this.
I thought disaster was that fvwm crashed until I tried this myself (and I
use SloppyFocus). This crashes my machine...
I would think this is a serious bug.

//Marcus

---

From: Stian Sletner <[email-masked]>
Date: Mon, 20 May 2002 14:17:22 +0200

* At 2002-05-20T14:14+0200, Marcus Lundblad wrote:
: 
| I can confirm this.
| I thought disaster was that fvwm crashed until I tried this myself (and I
| use SloppyFocus). This crashes my machine...
| I would think this is a serious bug.

Wow.  I just meant that I don't get to the window I wanted. :-D

---

From: Mikhael Goikhman <[email-masked]>
Date: Mon, 20 May 2002 12:55:40 +0000

> > window first, or make it work for non-focused ones?

I can only suggest:

  Style * ClickToFocusPassesClickOff

This should solve your problem, but I am not sure this is what you want.
If a click on ClickToFocus window is passed to an application, unexpected
things may happen. Maybe Dominik may explain this better.

> > around this, but I thought I'd mention it...

Please always mention your version. And exact bindings if not default.

What is exactly the thing that there's no way around it?

> I would think this is a serious bug.

Yes. This problem was fixed a day or two after 2.5.1.
Use the stable version or the latest snapshot if you tend to move a
mouse a lot when using a keyboard, i.e. Alt-Tab. :)

Regards,
Mikhael.

---

From: Stian Sletner <[email-masked]>
Date: Mon, 20 May 2002 15:16:25 +0200

* At 2002-05-20T12:55+0000, Mikhael Goikhman wrote:
: 
| I can only suggest:
| 
|   Style * ClickToFocusPassesClickOff
| 
| This should solve your problem, but I am not sure this is what you want.
| If a click on ClickToFocus window is passed to an application, unexpected
| things may happen. Maybe Dominik may explain this better.

This does indeed solve it, but you're also right in that I don't want
it. :)  It seems sort of illogical to me that the w context does not
trigger on unfocused windows, but perhaps there should be a separate
context for it?

| Please always mention your version. And exact bindings if not default.
| 
| What is exactly the thing that there's no way around it?

Sorry, I didn't think it important.  What I meant was that alt-tab warps
the mouse pointer to the windowlist, and uses it in the selecting.  This
is what I assumed there is no way around.  Moving the mouse while doing
this causes it to skew off its course.  I'm running 2.4.6 with some
patches (currentatend, iconifiedatend).

    key     tab     a       m       windowlist root c c currentdesk, nogeometry, currentatend, iconifiedatend

---

From: Mikhael Goikhman <[email-masked]>
Date: Mon, 20 May 2002 18:57:41 +0000

> trigger on unfocused windows, but perhaps there should be a separate

I think it is a bug that with unfocussed ClickToFocus window a click is
passed to app and only then the "w" binding is checked, while with
focussed ClickToFocus window the "w" binding is checked before passing a
click (i.e. it is not passed).

So when a click is passed (window is not focussed) application eats this
click, FVWM only sees a mouse release.

For "m" in your function to work, FVWM should see a press, not a release.

But you may work around this bug, just change "m" to "i" in your function.

>     key     tab     a       m       windowlist root c c currentdesk, nogeometry, currentatend, iconifiedatend

Please define the behaviour you want to have.

If you don't want WindowList to warp the mouse pointer, remove "root"
option. If you don't want WindowList to be activated on Alt, add
"SelectOnRelease" option or press right-Alt-Tab.

Or maybe you need a new option "DontActivateWindowListWhenMouseIsMoved"?
Define what "MouseIsMoved" means. Moved by more than 5 pixels in 3 seconds
after Alt is pressed? :)

Regards,
Mikhael.

---

From: Stian Sletner <[email-masked]>
Date: Mon, 20 May 2002 21:13:53 +0200

* At 2002-05-20T18:57+0000, Mikhael Goikhman wrote:
: 
| > > >     mouse   1       w       m       function alt-move
| > > >  
| > > >     destroyfunc     alt-move
| > > >     addtofunc       alt-move
| > > >     +               m       move
: 
| I think it is a bug that with unfocussed ClickToFocus window a click is
| passed to app and only then the "w" binding is checked, while with
| focussed ClickToFocus window the "w" binding is checked before passing a
| click (i.e. it is not passed).
| 
| So when a click is passed (window is not focussed) application eats this
| click, FVWM only sees a mouse release.
| 
| For "m" in your function to work, FVWM should see a press, not a release.
| 
| But you may work around this bug, just change "m" to "i" in your function.

That is not at all the same...  I want to drag the window, not have it
attached until I click again.

| >     key     tab     a       m       windowlist root c c currentdesk, nogeometry, currentatend, iconifiedatend
| 
| Please define the behaviour you want to have.
| 
| If you don't want WindowList to warp the mouse pointer, remove "root"
| option. If you don't want WindowList to be activated on Alt, add
| "SelectOnRelease" option or press right-Alt-Tab.
| 
| Or maybe you need a new option "DontActivateWindowListWhenMouseIsMoved"?
| Define what "MouseIsMoved" means. Moved by more than 5 pixels in 3 seconds
| after Alt is pressed? :)

I see I've not made myself clear.  The point I'm trying to make is that
the alt-tab use of windowlist should be independent of the mouse
pointer, not warping the pointer to the windowlist, or necessarily
having the windowlist pop up under the pointer.  I do alt-tab quickly to
get from one window to the next, but if I'm moving the mouse while this
happens, the pointer ends up in the wrong place in the windowlist before
I release alt, bringing me to some other window than the one I was going
for.  I'm not sure I can explain this any better. :)  The option I would
want is something like DontUseTheMousePointerInWindowListAtAll. :)

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 21 May 2002 12:30:08 +0200

> window first, or make it work for non-focused ones?

Fixed in the next 2.4 and 2.5 versions.

Bye

Dominik ^_^  ^_^

-- 
Dominik Vogt, email: [email-masked]
LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen
fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].