FVWM: disallowing the transfer of focus while a key is pressed

[f***@stefan-klinger.de]

Hello,

I've been using FVWM for several years now, and I'm quite happy about
it. There's one focus-related thing however, I coud not manage to
figure out, even though there are a lot of focus-policy settings
around:


=== Problem

I'm looking for a way to prevent focus to shift from one window to
another, as long as a key is held down.


=== Reason

I'm using a focus-follows-mouse policy and I frequently use keys to
move windows around. While doing so, sometimes (often) a second
window gets between the mouse cursor, and the window I want to move.
Instantly focus jumps to the second window, which is then moved
instead of the one I wanted to.


=== Try this yourself

Excerpt from my .fvwm/config, which allows me to move a window to one
of the 9 positions with a single keystroke.

Style * FPEnterToFocus, FPLeaveToUnfocus

key 1 a 4 animatedmove 0 0 warp
key 2 a 4 animatedmove 50-50w 0 warp
key 3 a 4 animatedmove -0 0 warp
# ... and so on, think of a keypad, 1=top-left, 5=center, 9=bottom-right

Now open two terminals, put the upper one in the top-left corner, the
lower one somewhere else. Move mouse to lower terminal, which gets
the focus. Hold down mod4 and press 1, then 3, then release mod4. The
lower window moves to the top left, where it instantly looses its
focus to the upper window, which then moves to the top-right.


Another example is the following setup, which allows me to jump to
another page on the desktop, and take the current window with me:

destroyfunc gotomovetopage
addtofunc gotomovetopage
+ I movetopage $0 $1
+ I gotopage $0 $1

key right A C4 gotomovetopage 1p 0p
key left A C4 gotomovetopage -1p 0p
key up A C4 gotomovetopage 0p -1p
key down A C4 gotomovetopage 0p 1p

When jumping over multiple pages, I loose the window on the first
occasion where the mouse pointer accidentally catches another window.


=== Proposed Solution

IMHO, disallowing the transfer of focus while a key is pressed, would
remedy the situation.

Is this doable with current FVWM configuration options?


=== Version

***@verne:~> fvwm --version
fvwm 2.5.30 compiled on Oct 16 2010 at 07:00:26
with support for: ReadLine, RPlay, Stroke, XPM, PNG, SVG, Shape, XShm,
SM, Bidi text, Xinerama, XRender, XCursor, XFT, NLS



Thank you!
Stefan

[Michael Großer]

I have no concrete idea that you could directly transform
into source code, but, perhaps my question and a general
idea could help to find a direction.

Question:
What do you mean with "while a key is pressed"?
Only the mod4 (Win) key? And perhaps a Control key?

When I see your lines of code, I think it should be enough
when the mod4 (Win) key is kept down?

Idea:
If so: Is it possible to recognize a currently pressed
mod4 key, and set another focus policy until the key is up again?

Michael

Post by f***@stefan-klinger.de
Hello,
I've been using FVWM for several years now, and I'm quite happy about
it. There's one focus-related thing however, I coud not manage to
figure out, even though there are a lot of focus-policy settings
=== Problem
I'm looking for a way to prevent focus to shift from one window to
another, as long as a key is held down.
=== Reason
I'm using a focus-follows-mouse policy and I frequently use keys to
move windows around. While doing so, sometimes (often) a second
window gets between the mouse cursor, and the window I want to move.
Instantly focus jumps to the second window, which is then moved
instead of the one I wanted to.
=== Try this yourself
Excerpt from my .fvwm/config, which allows me to move a window to one
of the 9 positions with a single keystroke.
Style * FPEnterToFocus, FPLeaveToUnfocus
key 1 a 4 animatedmove 0 0 warp
key 2 a 4 animatedmove 50-50w 0 warp
key 3 a 4 animatedmove -0 0 warp
# ... and so on, think of a keypad, 1=top-left, 5=center,
9=bottom-right
Now open two terminals, put the upper one in the top-left corner, the
lower one somewhere else. Move mouse to lower terminal, which gets
the focus. Hold down mod4 and press 1, then 3, then release mod4. The
lower window moves to the top left, where it instantly looses its
focus to the upper window, which then moves to the top-right.
Another example is the following setup, which allows me to jump to
destroyfunc gotomovetopage
addtofunc gotomovetopage
+ I movetopage $0 $1
+ I gotopage $0 $1
key right A C4 gotomovetopage 1p 0p
key left A C4 gotomovetopage -1p 0p
key up A C4 gotomovetopage 0p -1p
key down A C4 gotomovetopage 0p 1p
When jumping over multiple pages, I loose the window on the first
occasion where the mouse pointer accidentally catches another window.
=== Proposed Solution
IMHO, disallowing the transfer of focus while a key is pressed, would
remedy the situation.
Is this doable with current FVWM configuration options?
=== Version
fvwm 2.5.30 compiled on Oct 16 2010 at 07:00:26
with support for: ReadLine, RPlay, Stroke, XPM, PNG, SVG, Shape, XShm,
SM, Bidi text, Xinerama, XRender, XCursor, XFT, NLS
Thank you!
Stefan

[Stefan Klinger]

Hi, thanks for the feedback.

Post by Michael Großer
What do you mean with "while a key is pressed"?
Only the mod4 (Win) key? And perhaps a Control key?

For me it would clearly be sufficient to name only one key (Win) or
even just a modifier bit (mod4). But sometimes I additionally use
Control, or Shift. So a modifier bitmask (with or-semantics?) could
be useful for other people. Maybe the approach about "while any
modifier being held down" is simpler.

Post by Michael Großer
If so: Is it possible to recognize a currently pressed
mod4 key, and set another focus policy until the key is up again?

That should do the job, but I would not know how to do this in FVWMs
config file.

Basically I see two options now:
1. Change focus policy on key press/release (as you suggested), or
2. Introduce another focus policy that keeps the focus to a window,
while any, or a certain, key or modifier is pressed.

No insult intended, but the latter one occurs more natural to me =)
Of course I'd be happy with any solution!

Any ideas?

Kind regards,
Stefan

Post by Michael Großer

Post by f***@stefan-klinger.de
I'm looking for a way to prevent focus to shift from one window to
another, as long as a key is held down.
=== Reason
I'm using a focus-follows-mouse policy and I frequently use keys to
move windows around. While doing so, sometimes (often) a second
window gets between the mouse cursor, and the window I want to move.
Instantly focus jumps to the second window, which is then moved
instead of the one I wanted to.

[Thomas Adam]

Post by f***@stefan-klinger.de
I'm looking for a way to prevent focus to shift from one window to
another, as long as a key is held down.

It's possible, but impractical. Why are you thinking you need this?

-- Thomas Adam

[f***@stefan-klinger.de]

Post by Thomas Adam

Post by f***@stefan-klinger.de
I'm looking for a way to prevent focus to shift from one window to
another, as long as a key is held down.

It's possible, but impractical. Why are you thinking you need this?

Another example: I use the key combination mod4-d to delete a window,
where mod4 is produced by the window key. Imagine focus is in an xterm
I want to get rid of, so I hold down the window key, and hit
D. Unfortunately, just a fraction of a second before I pressed D, the
application that took ages to start mapped its first window right
beneath the mouse pointer, gets the focus (which follows the mouse),
and is therefore deleted.

What do you mean wich impractical?

Regards,
Stefan

[Thomas Adam]

Post by f***@stefan-klinger.de

Post by Thomas Adam

Post by f***@stefan-klinger.de
I'm looking for a way to prevent focus to shift from one window to
another, as long as a key is held down.

It's possible, but impractical. Why are you thinking you need this?

Another example: I use the key combination mod4-d to delete a window,
where mod4 is produced by the window key. Imagine focus is in an xterm
I want to get rid of, so I hold down the window key, and hit
D. Unfortunately, just a fraction of a second before I pressed D, the
application that took ages to start mapped its first window right
beneath the mouse pointer, gets the focus (which follows the mouse),
and is therefore deleted.

So set a reasonable delay for you binding:

Schedule 700 Close

-- Thomas Adam

[f***@stefan-klinger.de]

Post by Thomas Adam
Schedule 700 Close

Sorry, that won't help in general. Maybe you want to read my initial mail?

[Thomas Adam]

Post by f***@stefan-klinger.de

Post by Thomas Adam
Schedule 700 Close

Sorry, that won't help in general. Maybe you want to read my initial mail?

It will if you use a function. I did read your initial email and you did
not give me any reason for me to help you. Your question is asking for a
solution to a problem you've not yet stated; confer an XY problem.

-- Thomas Adam

[f***@stefan-klinger.de]

Post by Thomas Adam

Post by f***@stefan-klinger.de

Post by Thomas Adam
Schedule 700 Close

Sorry, that won't help in general. Maybe you want to read my initial mail?

It will if you use a function.

How exactly? Just

key d A 4 Schedule 1000 Close

won't help, since, according to the FVWM doc: "The command is executed
in the same context window as the Schedule command". It simply means
that the wrong window is killed later. I've tried this.

Post by Thomas Adam
I did read your initial email and you did not give me any reason for
me to help you. Your question is asking for a solution to a problem
you've not yet stated; confer an XY problem.

Problem: I want to configure FVWM to not take away the focus from a
window, while I hold down any modifier key. No reason why, I just
want to.

I wonder whether I have said anything worng, or unfriendly, or whether
I have a reason not to like your attitude. Maybe one of the fellow
readers would be so kind as to set me straight.

Thanks,
Stefan

[Michael Großer]

Post by f***@stefan-klinger.de

Post by Thomas Adam

Post by f***@stefan-klinger.de

Post by Thomas Adam
Schedule 700 Close

Sorry, that won't help in general. Maybe you want to read my initial mail?

It will if you use a function.

How exactly? Just
key d A 4 Schedule 1000 Close
won't help, since, according to the FVWM doc: "The command is executed
in the same context window as the Schedule command". It simply means
that the wrong window is killed later. I've tried this.

Try to define a function. Then let your key binding call this function.
Let the function change the focus and then let it fire the close command.
Please report the result after you coded and tested this.

Post by f***@stefan-klinger.de

Post by Thomas Adam
I did read your initial email and you did not give me any reason for
me to help you. Your question is asking for a solution to a problem
you've not yet stated; confer an XY problem.

Problem: I want to configure FVWM to not take away the focus from a
window, while I hold down any modifier key. No reason why, I just
want to.
I wonder whether I have said anything worng, or unfriendly, or whether
I have a reason not to like your attitude.

@Stefan:
Be patient. Some people are just uncompromisingly straight and their
boundary related to social skills is shifted slightly away from kindness,
slightly in the direction of precision. As long as these people do not
pass over that boundary in a really unacceptable way, it could be smarter
to play along that game and to learn how to deal with this kind of people.
The world is full of them. If you are a person with a high level of
standards according to the ability to solve sophisticated, challenging
problems, then your chances to reach your ambitious goals increase with
your ability to deal with difficult people, because these people may be
the persons who may give you the deciding ideas that people who are nicer
than precise wouldn't be able to give you. When YOU increase your level
of social skills significantly, then you can become one of the few people
who are equipped with the interface to be able to involve these difficult
people into your goals. A lot of people do not have such kind of interface,
they run away, they look for less sophisticated, less challenging problems
to solve, and will become losers for the rest of their lowbrow lives.

http://catb.org/~esr/faqs/smart-questions.html
http://www.tty1.net/smart-questions_de.html

Post by f***@stefan-klinger.de
Maybe one of the fellow
readers would be so kind as to set me straight.

As I can realize, you unmistakably made clear what you really
want: A generic approach. I even helped you making that clear.
It seems that this generic approach is not that easy to reach.
When this happens, Thomas usually tries to find out your concrete
reasons that led you to want your rather generic approach. This
means: When generic approaches are not possible, then individual
approaches for each concrete reason would be better than nothing.
This is one of the implicit rules that people with a high level
of social skills should know (or learn (by making mistakes (people
who do not make mistakes do not work at all))).

:-)
Michael

[Michael Großer]

Post by f***@stefan-klinger.de

Post by Thomas Adam

Post by f***@stefan-klinger.de

Post by Thomas Adam
Schedule 700 Close

Sorry, that won't help in general. Maybe you want to read my initial mail?

It will if you use a function.

How exactly? Just
key d A 4 Schedule 1000 Close
won't help, since, according to the FVWM doc: "The command is executed
in the same context window as the Schedule command". It simply means
that the wrong window is killed later. I've tried this.

What do you think of my invention of a focus snapshot?
I invented it 15 minutes ago after I come out of the bathtube :-)

Define a key binding <Win> + <Space>, which makes a mental
snapshot of the window that currently has the focus.

When you press <Win> + <Space>, and something unforeseen happens,
then just go back to the original window and press <Win> + <Space>
again.

After pressing <Win> + <Space>, you could perform any action
you want and bind it the mental focus snapshot. This is not
exactly the workflow you want, but it is a possible workflow,
a tradeoff. And I'm rather sure that I were able to code this.

Do you understand my approach?

Michael

[Dan Espen]

Post by f***@stefan-klinger.de

Post by Thomas Adam
Schedule 700 Close

Sorry, that won't help in general. Maybe you want to read my initial mail?

Does this work the way you want:

Key F7 A M Move

But this doesn't:

Key F7 A M Move 10p 10p

[f***@stefan-klinger.de]

Hi Dan,

thank's for the suggestions, but unfortunately they both don't do what

Post by Dan Espen
Key F7 A M Move

This basically starts moving the window with the mouse, which is what
I want to avoid in this situation.

Post by Dan Espen
Key F7 A M Move 10p 10p

This leaves the mouse cursor where it is, which means that the window
to be moved looses the focus as soon as it is not under the cursor any
more (focus follows mouse, not sloppy). Even with sloppy focus, a
lower non-root window under the mouse cursor gets the focus. In fact,
to disable switchingg focus while a modifier is held down would allow
me to use SloppyFocus instead.

Kind regards,
Stefan

[Dan Espen]

Post by f***@stefan-klinger.de
Hi Dan,
thank's for the suggestions, but unfortunately they both don't do what

Post by Dan Espen
Key F7 A M Move

This basically starts moving the window with the mouse, which is what
I want to avoid in this situation.

Post by Dan Espen
Key F7 A M Move 10p 10p

This leaves the mouse cursor where it is, which means that the window
to be moved looses the focus as soon as it is not under the cursor any
more (focus follows mouse, not sloppy). Even with sloppy focus, a
lower non-root window under the mouse cursor gets the focus. In fact,
to disable switchingg focus while a modifier is held down would allow
me to use SloppyFocus instead.

Okay still trying to understand all the issues.

This isn't animated move but I think it will work with animated
move too:

DestroyFunc My_AM
AddToFunc My_AM
+ I Pick SetEnv B $[w.id]
+ I WindowId $[B] move $* Warp
+ I WindowId $[B] Raise

key 1 a C My_AM 0 0 warp
key 2 a C My_AM 50-50w 0 warp
key 3 a C My_AM -0 0 warp

Worked for the cases I tried.
I also tried it with layer changing my that didn't seem
to help.

[Thomas Adam]

Post by f***@stefan-klinger.de

Post by Thomas Adam

Post by f***@stefan-klinger.de
I'm looking for a way to prevent focus to shift from one window to
another, as long as a key is held down.

It's possible, but impractical. Why are you thinking you need this?

Another example: I use the key combination mod4-d to delete a window,
where mod4 is produced by the window key. Imagine focus is in an xterm
I want to get rid of, so I hold down the window key, and hit
D. Unfortunately, just a fraction of a second before I pressed D, the
application that took ages to start mapped its first window right
beneath the mouse pointer, gets the focus (which follows the mouse),
and is therefore deleted.
What do you mean wich impractical?

I'm reading this thread in bewilderment.

Your entire problem is centered around windows receiving focus which you
think shouldn't, and then deciding that how you want to fix it involves a
key which, when pressed, disallows focus?

Sorry -- but that's never going to work with applications.

All these fanciful ideas using WarpToWindow inside functions is just as
fragile as your original idea, Stefan, of a key press.

FVWM is doing the right thing with respect to your problem of "windows
getting in the way", and I do sympathise only slightly about that
potentially being annoying when deleting windows.

If you _really_ think you need this still use:

NoWindow Pick SomeFunctionNameOrCommandOfYourChoice

Bind the above to a key/mouse binding however you like -- the whole point of
this is to always make FVWM force the user to choose which window to run the
corresponding binding's action.

The above might not be so useful for moving windows around interactively,
but it will help with your other problems.

-- Thomas Adam

[Michael Großer]

Post by Thomas Adam

Post by f***@stefan-klinger.de

Post by Thomas Adam

Post by f***@stefan-klinger.de
I'm looking for a way to prevent focus to shift from one window to
another, as long as a key is held down.

It's possible, but impractical. Why are you thinking you need this?

Another example: I use the key combination mod4-d to delete a window,
where mod4 is produced by the window key. Imagine focus is in an xterm
I want to get rid of, so I hold down the window key, and hit
D. Unfortunately, just a fraction of a second before I pressed D, the
application that took ages to start mapped its first window right
beneath the mouse pointer, gets the focus (which follows the mouse),
and is therefore deleted.
What do you mean wich impractical?

I'm reading this thread in bewilderment.
Your entire problem is centered around windows receiving focus which you
think shouldn't, and then deciding that how you want to fix it involves a
key which, when pressed, disallows focus?
Sorry -- but that's never going to work with applications.
All these fanciful ideas using WarpToWindow inside functions is just as
fragile as your original idea, Stefan, of a key press.
FVWM is doing the right thing with respect to your problem of "windows
getting in the way", and I do sympathise only slightly about that
potentially being annoying when deleting windows.
NoWindow Pick SomeFunctionNameOrCommandOfYourChoice
Bind the above to a key/mouse binding however you like -- the whole point of
this is to always make FVWM force the user to choose which window to run the
corresponding binding's action.
The above might not be so useful for moving windows around interactively,
but it will help with your other problems.
-- Thomas Adam

I too use fragile approaches to enforce a certain focus behaviour to my computer.
Yes, it is fragile sometimes, but for me this construction brings the most
possible benefit to me. I do not like it when the computer interactively
asks me to choose a window. This too often unnecessarily forces me to grab
the mouse, to shove it around and to press mouse buttons (when I have both
hands on the keyboard). It's a matter of taste. Fragile approaches always
implicate the risk of misconduct, which a user may purposely accept when
his workflow as a whole goes ahead much faster than with an ultra stable
but inconvenient system behaviour. And the effects of focus related
misconducts are negligible in contrast to the benefits.

Well: Stefan has the option to choose. Thomas gives very stable ideas.
My ideas may solve Stefan's problems more unconventional and MIGHT bear
the risk of fragility. If someone always knows what he does, fragility
in the grade I described above shouldn't be that bad. Or is it?

Michael

[Stefan Klinger]

Hello,

please excuse my late reply, these days I'm offline most of the time.

Thank you very much for the solutions you have suggested, but
unfortunately they are not what I was looking for.

I was trying to get something similar to the SelectOnRelease
MenuStyle, which seems to be used frequently to allow Alt-Tab style
focus shifting. From the user's perspective, pressing down Tab while
the modifier held down marks the start of the selection process, while
releasing the modifier marks the end of it, actually making the
selection. It is interesting to see that windows that want to be
mapped while a menu is open, wre postponed until the user is done with
the menu (although this does not apply to torn off menues). I assume
this is partly due to the difficulty of updating a menu while it's
being displayed, and also because it would be mean on the user to
change a menu while he's trying to make a selection.

Anyways, following this line of thought, I wanted to achieve something
similar (and, yes, general) which allows the WM to guess more
precisely the granularity of my actions, i.e., the intended scope of a
focus over time.

It was then that I realised an important difference between the
Alt-Tab style and what I wanted: With the former, pressing down Tab,
marks the beginning of an interaction, while in my situation holding
down the modifier alone should already ask the WM to stop changing the
focus.

I've been living with that situation for years now. It was only when
I discovered that accidentally deleting a window (which has just been
mapped between pressing the modifier and D) could be prevented using
the same technique, that I decided to re-read the documentation, and
then ask you for a general solution.

Now since that's not possible, I guess I can live on with the
situation as it is. I certainly do appreciate your suggestions,
however, I assume the focus-snapshot and the explicit picking for each
interaction more clumsy than my current setup.

Thank you very much!
Stefan

[Thomas Adam]

Post by Stefan Klinger
I was trying to get something similar to the SelectOnRelease
MenuStyle, which seems to be used frequently to allow Alt-Tab style
focus shifting. From the user's perspective, pressing down Tab while
the modifier held down marks the start of the selection process, while
releasing the modifier marks the end of it, actually making the
selection. It is interesting to see that windows that want to be
mapped while a menu is open, wre postponed until the user is done with
the menu (although this does not apply to torn off menues). I assume
this is partly due to the difficulty of updating a menu while it's
being displayed, and also because it would be mean on the user to
change a menu while he's trying to make a selection.

Correct -- we're grabbing the XServer at this point which is why when you're
dealing with the menu, that's the only thing you're allowed to happen.
XEvents queue up in the background and FVWM will the process them when the
WindowList has been dealt with.

Note that torn-off menus are not menus in the traditional FVWM sense;
they're just another window created with XCreateWindow() and hence do not
grab the XServer when they're mapped; they behave like ordinary windows,
which is why you're unable to use Alt-tab on them.

Post by Stefan Klinger
Anyways, following this line of thought, I wanted to achieve something
similar (and, yes, general) which allows the WM to guess more
precisely the granularity of my actions, i.e., the intended scope of a
focus over time.

You'll need to explain what this means.

-- Thomas Adam

[Michael Großer]

[We have some kind of split brain problem. You will
see some days later why.]

Apart from my generic "<Win> + <Alt>" approach from yesterday,
here is yet another idea, which has very high chances of solving
SOME of your specific wishes without compromise. (Focus related
logics are a topic I'm interested in a lot.)

Post by f***@stefan-klinger.de
Another example is the following setup, which allows me to jump to
destroyfunc gotomovetopage
addtofunc gotomovetopage
+ I movetopage $0 $1
+ I gotopage $0 $1
key right A C4 gotomovetopage 1p 0p
key left A C4 gotomovetopage -1p 0p
key up A C4 gotomovetopage 0p -1p
key down A C4 gotomovetopage 0p 1p
When jumping over multiple pages, I loose the window on the first
occasion where the mouse pointer accidentally catches another window.

This code fragment below will work, especially when you DO NOT use the
FPLeaveToUnfocus policy, where such kind of approach would make more sense
than with:

destroyfunc gotomovetopage
addtofunc gotomovetopage
+ I SetEnv BOOKMARKED_WINDOW $[w.id]
+ I movetopage $0 $1
+ I gotopage $0 $1
+ I WindowId $[BOOKMARKED_WINDOW] WarpToWindow 50 50

WarpToWindow moves the mouse pointer, wich prevents that the
wrong window gets the focus.

My own config also uses such kind of "bookmark" and WarpToWindow
approach (in similar contextes).

Post by f***@stefan-klinger.de
Excerpt from my .fvwm/config, which allows me to move a window to one
of the 9 positions with a single keystroke.
Style * FPEnterToFocus, FPLeaveToUnfocus
key 1 a 4 animatedmove 0 0 warp
key 2 a 4 animatedmove 50-50w 0 warp
key 3 a 4 animatedmove -0 0 warp
# ... and so on, think of a keypad, 1=top-left, 5=center,
9=bottom-right

Similar here: Build a function, "bookmark" the window ID, use "WarpToWindow",
use "Raise", and your window should keep the focus (not tested, but it should
work).

Now, choose between this and the generic "<Win> + <Alt>" approach from
yesterday :-)

Michael





Have to withdraw now for a while. It was great, but holidays are over :-(

[Michael Großer]

Post by Michael Großer
Apart from my generic "<Win> + <Alt>" approach from yesterday,

should read "<Win> + <Space>"...