Re: fragile approaches [Re: FVWM: disallowing the transfer of focus while a key is pressed]
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 -- Stefan Klinger o/klettern /\/ bis zum send plaintext only - max size 32kB - no spam \ Abfallen http://stefan-klinger.de
Re: fragile approaches [Re: FVWM: disallowing the transfer of focus while a key is pressed]
On Sat, Jan 07, 2012 at 03:29:32PM +1300, Stefan Klinger wrote: 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. 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 -- 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
