Blog post on https://folivora.ai from Sat, 16 Jan 2010 12:09:50 +0000
This is a companion discussion topic for the original entry at https://folivora.ai/blog/post/1378
You're talking about removing the seeking for the title bar cognitive lag involved in positioning windows, right? This is fantastic. I would definitely use this feature, all the time.
Coming from Windows, I wrote an Autohotkey script to allow me to move windows by holding down a button on my mouse (the G9 button on a Logitech G700s). It improved my productivity ridiculously, and I had other options by using my mouse's "back" and "forward" buttons as shifting keys for the other buttons, giving me access to close, maximize, minimize, send to back, and snap to left/right of window and cycle through multiple monitors. I noticed that in BetterTouchTool I'm limited to using a modifier key on the keyboard itself, and I have no way of mapping this kind of window movement to the mouse, and I have no options for using mouse keys as shifted for access to overloaded options that I can tell.
Although I'm currently mapping my Fn key to window movement, I find it about as inconvenient to use as seeking the title bar, so I'm definitely hoping for more options.
I suggest allowing triggers to operate across the current boundaries in the app (for example, using a mouse button or trackpad positional multitouch as a "state" and allowing combinations of such states to directly be mapped to actions, that way you could define for yourself which zones or combinations of mouse and keyboard buttons activate these states, and you can choose whether they are active while being held down or switch it on or off or toggle. In many ways it would be similar to what you currently have when defining application groups, just applied to triggers.