Focus snapshot [Re: FVWM: disallowing the transfer of focus while a key is pressed]
f...@stefan-klinger.de wrote: On Sat, Dec 31, 2011 at 01:32:05AM +, Thomas Adam wrote: On Sat, Dec 31, 2011 at 02:27:25PM +1300, f...@stefan-klinger.de wrote: On Sat, Dec 31, 2011 at 01:14:38AM +, Thomas Adam wrote: So set a reasonable delay for you binding: 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
Re: FVWM: disallowing the transfer of focus while a key is pressed
On Sat, Dec 31, 2011 at 02:03:25PM +1300, f...@stefan-klinger.de wrote: On Fri, Dec 30, 2011 at 09:48:02AM +, Thomas Adam wrote: On 29 December 2011 23:02, f...@stefan-klinger.de wrote: 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 -- Deep in my heart I wish I was wrong. But deep in my heart I know I am not. -- Morrissey (Girl Least Likely To -- off of Viva Hate.)
fragile approaches [Re: FVWM: disallowing the transfer of focus while a key is pressed]
Thomas Adam wrote: On Sat, Dec 31, 2011 at 02:03:25PM +1300, f...@stefan-klinger.de wrote: On Fri, Dec 30, 2011 at 09:48:02AM +, Thomas Adam wrote: On 29 December 2011 23:02, f...@stefan-klinger.de wrote: 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 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
