Implement "move-or-raise" action
RamonUnch opened this issue · 16 comments
Hi Ramon, do you think you could also implement "move-or-raise" (see original post), where raise means to foreground the window (not sure what that is called in windows parlance).
If not clear why this is useful: I can raise a window simply by clicking the mouse1 button (LMB?), but the problem is that it is completely ingrained in me to press the Alt key when I use X11 (or AltSnap), and in that case there is no programming of AltSnap that will raise the window (move-or-raise is the desired functionality).
Originally posted by @reikred in #110 (comment)
If I understand correctly you would like the window to raise when you Alt+Click on it, but still not to raise when you alt+click+drag it, is that right?
Because otherwise you already have the Focus Windows when draging option
I just would have to implement a Set foreground mouse action that you would set as a drag-free move action.
As I understand it, he wants that the hotkey alone (Ctrl/Win/Alt) is able to focus the window.
Or he simply doesn't know about Focus Windows when dragging.
The discussion comes from the non-drag actions That is why I understood that.
Anyway it seems a good idea to gave the Focus window action, it takes barely takes extra code and could also be used as a While moving action or something.
If I understand correctly you would like the window to raise when you Alt+Click on it, but still not to raise when you alt+click+drag it, is that right?
Actually, in both cases raise the window, whether or not it is moved. Maybe that is how you already implemented it?
Sorry I was 8 hours late to respond, I'm apparently in a different time zone or went to sleep too early ;-).
Then, just Check the Focus Windows while dragging option in the general tab of the config file, (first option).
Sorry I was 8 hours late to respond, I'm apparently in a different time zone or went to sleep too early ;-).
It is fine, there is no hurry, I am aware that people from the whole globe are commenting here So I understand there can be easily more than a day for a full answer response loop.
Then, just Check the Focus Windows while dragging option in the general tab of the config file, (first option).
I have now tried config.general.focus-windows-when-dragging, but "Move" ends up iconizing/minimizing the window rather than raising it when NOT dragging. The reason is I'm using move as the base operation for both mouse1 and mouse2, and move has already been programmed to the "move-or-iconify", so the iconify/minimize takes precedence (I guess) over "move"+config.general.focus-windows-when-dragging setting when I am NOT dragging.
Said another way: Need to get focus when NOT dragging. Am I making sense? I hope I am. Apoligies for rambling a bit, maybe I'm just trying to convince myself I am understanding correctly how things currently work. I'm still learning.
Upshot: It looks to me like a programmable "raise"/Focus action pulldown menu functionality/entry would be needed, with the optional "move-if-dragged" also in effect.
Just for easy reference, my original X11 + twm/vtwm/fvwm style formulation from #110
Button1 = m : window|title|icon : f.function "move-or-iconify"
Button2 = m : window|title|icon : f.function "move-or-raise"
Button3 = m : window|title|icon : f.function "resize-or-circledown" (I'm NOT asking you for circle down, though, not so essential :-))
I do not see how I could implement what you are asking.
When you Alt+Click without a drag AltSnap cannot know if you want to rigger the drag-free action (minimize in your case) or if you want to focus the window. You are asking for two different actions for the same input.
Is it the same input? I'm describing the action of a different mouse button, mouse2 not mouse1. Does AltSnap not take into account which mouse button was pressed when deciding what do to? Granted, both mouse1 and mouse2 in some sense invoke "move" (if dragged), but does AltSnap then not distinguish between the choice of minimize/iconify and focus/raise if there was no dragging?
Ok, I get it, it is indeed not supported by AltSnap indeed.
The Move Up action is for move action and does not depend on the mouse button.
There is no solution to your problem for now.
If however you only use the Move action you can setup you Resize action as Right click and then setup the resize action to basically behave like the Move action by setting the center resize mode to Move and by setting the Center fraction to 100%, Then use different actions on MoveUp and ResizeUp, (Just use None for ResizeUp).
I'm trying your suggested "resize" trick, specifically I set
config.mouse.mouse2.action=resize (not move)
config.mouse.mouse3.action=resize (I already had this setting)
config.mouse.long-drag-free-resize=NOTHING (not resize) (NOTHING will in practice FOCUS/raise the window)
config.advanced.center-side-fraction=255/255 (was 24/255).
That worked for me!! Don't really understand how it works, but great, I can now mouse2.press-drag for resize, and mouse3.click for raise/focus.
One more general comment that may be relevant or provide an idea:
I noticed that the mouse action menu has multiple "modes" such as 1. primary with "submodes" A. while moving B. while resizing.
Seems to me that if there existed submodes called C. press-release and D. press-drag-release then that would be a way of specifying independently for each mouse button what function/operation to do when drag/nodrag. Just some food for thought, maybe it is a viable idea? The limitation of the long-drag-free-move/resize "special two hacks" is that they apply only to either move or resize operations, but as we know, also that it cannot distinguish between multiple mouse buttons set to move as for selection of the non-drag operation to choose. A more general scheme like aforementioned (C,D) might have some advantages and be more flexible and extensible?
At some point I may generalize the UpClick actions so that you can configure any action on the upclick, but for now it is not the case because the upclick only makes sense for the move and resize actions.
I see what you mean, although the action of the upclick is in some sense dependent on whether there was a drag right before it :). One might need a configuration distinction between nodrag-upclick and drag-upclick actions.
Note to self: downclick-drag-upclick as terminology, versus what I have been calling it: press-drag-release