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 +0000, 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
