(Feature Request) Arrow keys to move windows inside grid

[ppass]

I will summarize my request made in the Gridmove thread, just to make it easier for you to manage feature requests.

I would like to improve fast move by using arrow keys. If the current window is in zone2,then:

- Modifier + "->" key:           moves it to zone3
- Modifier + "<-" key:           moves it to zone 1
- Modifier + page-up key:      moves it to last zone
- Modifier + page-down key: moves it to zone1

Ideally, you could move the window around physically (eg if zone8 is above zone2, then Modifier + up key moves window from zone2 to zone8). But I understand that this is difficult and could be done in a 2nd step.


To achieve this, you will have to detect the position of the active window. To do that, may I suggest this simple algorithm:

• Get the size of the active window (Top, Right, Bottom, Left)
• Loop through all zones defined in the grid (start with zone1)
•    If (Top == GridTop) and (Right == GridRight) and (Bottom == GridBottom) and (Left == GridLeft) then ZONE_FOUND ! ! ! get out of the loop
•   else, go to next zone in the grid
• Return to  beginning of loop

If you have trouble with getting the size of the active window, you may try the Windows API GetWindowRect function.

[lanux128]

fantastic idea, ppass! did you had FreeSnap on your mind?

[ppass]

Thanks for the link, I did not know FreeSnap before making this suggestion. I recommend the author of GridMove to try FreeSnap, this gives the idea. Basically, it is all about pressing arrow keys and moving the active window around and resizing it.

However, I am asking something more than FreeSnap. Freesnap for one thing does not support multi monitor, and just resizes windows to the edged of the screen. Using zones like in GridMove is much more powerful and flexible. I hope that one day it will be possible to physically move windows inside GridMove (eg. "up" key moves to the zone just above the current one, etc.), then it will be very intuitive.

[lanux128]

yes, lack of multi-monitor support is a hindrance but i've contacted the author of FreeSnap and he replied that he is working on a new version that will include multi-monitor support. but i also believe that if GridMove incorporates this feature then all the better..

[jgpaiva]

The reason why i don't know how to add this to gridmove is because it's not easy to detect which grid element is on the right or left of the current one. When we have a 3-part grid, or a 4 part grid, it's easy, but when we have something like the edge grid or something, things become very confusing...

Maybe this could be added as a coding snack? I don't think it'd be that hard to reproduce freesnap with ahk...

[lanux128]

Maybe this could be added as a coding snack? I don't think it'd be that hard to reproduce freesnap with ahk...

no, it's not that hard replicate FreeSnap's functions with AHK but since FreeSnap is already available, why not use it as some sort of internal app? e.g. those with FreeSnap already installed will get the extra features. just my 2¢..

[jgpaiva]

What do you mean with "internal app", lanux?

I said that, because it was mentioned that it didn't have support for multi-monitor.

[ppass]

The reason why i don't know how to add this to gridmove is because it's not easy to detect which grid element is on the right or left of the current one. When we have a 3-part grid, or a 4 part grid, it's easy, but when we have something like the edge grid or something, things become very confusing...

Maybe this could be added as a coding snack? I don't think it'd be that hard to reproduce freesnap with ahk...

I dont know what a "coding snack" is, but defenitely Gridmove should include moving the current window with arrow keys. Please note as per my previous comment that the aim is not to reproduce FreeSnap, as Freesnap just resizes/moves windows to the edge of the screen. Here is my proposal for GridMove:

Step 1: forget about physical location of zones inside a grid. Implement a simple zone increment like this: Zone1 -> Zone2 -> Zone 3-> etc.

Step 2: include physical location.
I understand the problem that you cannot detect which zone is on the right of the current one, etc.
I suggest that you let the user parameter this for you, for each grid. Example for a 6 zone grid:

horizontal arrows (user defined per grid):  Zone1 -> Zone2 -> Zone4 -> Zone5 -> Zone6 -> Zone3
Example: if the current zone is Zone1 and you hit the left arrow, the window should be moved to Zone3 of the grid.

vertical arrows (user defined per grid): Zone1 -> Zone4 -> Zone6 -> Zone3 -> Zone2 -> Zone5
Example: if the current zone is Zone4 and you hit the up arrow, the window should be moved to Zone6 of the grid.


My understanding was that you are willing to implement step1 and are waiting to have some time available to code this. Could you confirm this?

Once step1 is coded, step2 with this proposal should be a small step further ahead.

[jgpaiva]

Ok,i added the "step 1" you mentioned (actually, it's pretty fun! Not sure if it's that useful, though).

To use it, download gridmove, run once, then edit the .ini file and replace the '0' on the SequentialMove key with a '1' and reload gridmove.
Then, to cycle grid elements, press win + right/left.

Regarding the step2, it'd have to be made in the following way: each grid element would say what was the grid on its right, the grid on its left and the grid on its top and bottom. I think it'd be quite a chore to implement and then to create grids with these features, though.

[Armando]

Hummm... I just installed the new version, and Gridmove consumes a lot of CPU power for about 1.5 min, right after launching or reloading, and then it calms down. Anybody experiences such a thing ?

BTW, the cycling works well. 
Like you jpaiva, I'm not sure how useful that will be but it's another tool... Who knows...

Right now the hotkeys are :

CommandHotkey=#g
FastMoveModifiers=#

Could I change them to (because they conflict with FreeSnap's own hotkeys):

CommandHotkey=+^#g
FastMoveModifiers=+^#

I tried, but it didn,t seem to work...

And should that parameter have a value :

FastMoveMeta=

Thanks ! 

[jgpaiva]

Armando could you please send my your ini file?

Those 2 keys can be changed in the hotkeys -> command hotkey and hotkeys -> fast move modifiers.

The FastMoveMeta is supposed to be without value by default. It was added in this version. It allows you to move the windows to grids 11->20 in a similar way to pressing win+#. You press win+<fastmovemeta> and then press a # and the window it moved to grid 10 + #. (is that understandable? )

[Armando]

thanks jgpaiva.

i'll send you my ini file right away, before I make any changes to it.

[lanux128]

What do you mean with "internal app", lanux?

I said that, because it was mentioned that it didn't have support for multi-monitor.

my bad, i meant to quote ppass but then again, FreeSnap lacks multi-monitor support so it moot point..

[jgpaiva]

I just tested your ini file, and it's all right. Maybe we should deal with this in PM, to avoid spamming the forum, ok?

[ppass]

Ok,i added the "step 1" you mentioned (actually, it's pretty fun! Not sure if it's that useful, though).

Thank you so much for such a responsive attitude! It works exactly as expected. I find it pretty useful, especially since consecutive zone numbers match zones that are actually close one to the other in my grids.

Congratualtions on implementing detection of which grid element the active window is. This works perfectly!

Regarding the step2, it'd have to be made in the following way: each grid element would say what was the grid on its right, the grid on its left and the grid on its top and bottom. I think it'd be quite a chore to implement and then to create grids with these features, though.

That is pretty straight forward, the user just has to define 2 strings per grid as explained in my previous post:

horizontal arrows: (1,2,4,5,6,3)
This means that the user considers zone2 to have zone4 on its right and zone1 on its left

vertical arrows: (1,4,6,3,2,5)
This means that the user considers zone2 to have zone3 below and zone5 below

For example, for a 4 part grid, you'd have horizontal arrows = (1,2,3,4) and vertical arrows = (1,3,2,4). Believe me, defining this for the user is not a chore, it is just a small string.

On the program side, you just have to parse this simple string or dump it to an array, and assign the new zone to:

- the previous element of "horizontal arrows" in case the left  key was pressed
- the next      element of "horizontal arrows" in case the right key was pressed
- the first       element of "horizontal arrows" in case the "Home" key was pressed
- the last       element of "horizontal arrows" in case the "End"  key was pressed

- the previous element of "vertical arrows" in case the down  key was pressed
- the next      element of "vertical arrows" in case the up key was pressed
- the first       element of "vertical arrows" in case the "Page Down" key was pressed
- the last       element of "vertical arrows" in case the "Page Up"  key was pressed

At least for the simple grids, arrow navigation should feel pretty natural.

[ppass]

For step1, could you correct a couple of glitches:

- When a window is not recognised as inside a grid element, "No Match for Grid" pops up once if right key is pressed and once if left key is pressed. Could you make this only one popup?

- When one grid element is out of bounds of the visible screen, GridMove returns "No Match for Grid", although the window is inside a grid element. This may be because when you check the position of the current window, the value returned might not be the actual position, it could be cut to the limits of the visible screen?

Example: try this simple 2 zone-grid on a single monitor (I use this to cut/hide the top 10% of a window). When the active window is in zone2 with its top 10% hidden, GridMove fails to detect and returns "No Match for Grid"

[Groups]

NumberOfGroups = 2

[1]
  TriggerTop  = [Monitor1Top]
  TriggerLeft  = [Monitor1Left]
  TriggerBottom= [Monitor1Bottom]
  TriggerRight = [Monitor1Left] + [Monitor1Width] 
  GridTop  = [Monitor1Top]
  GridLeft  = [Monitor1Left]
  GridBottom= [Monitor1Bottom]
  GridRight = [Monitor1Left] + [Monitor1Width]
[2]
  TriggerTop  = [Monitor1Top] - 0.1 *([Monitor1Bottom]-[Monitor1Top])
  TriggerLeft  = [Monitor1Left]
  TriggerBottom= [Monitor1Bottom]
  TriggerRight = [Monitor1Left] + [Monitor1Width] 
  GridTop  = [Monitor1Top] - 0.1 *([Monitor1Bottom]-[Monitor1Top])
  GridLeft  = [Monitor1Left]
  GridBottom= [Monitor1Bottom]
  GridRight = [Monitor1Left] + [Monitor1Width]

[jgpaiva]

Ok, i fixed the issue you mentioned in this previous post and uploaded the new version. (notice that i didn't update the DCupdater file, so, to download it from dcupdater, press "install update from the web")

- When a window is not recognised as inside a grid element, "No Match for Grid" pops up once if right key is pressed and once if left key is pressed. Could you make this only one popup?

"no match for grid" pops up everytime the program tries to match that window agains the grid and can't find any match. I can't understand why you'd press right and then left, if it fails on right, it'll fail on left too as they both use the same mechanism..

Your idea on how to implement the horizontal/vertical cycle realy simplifies things, and maybe it really is the simplest way to implement it. I'll give it some thought.

[Armando]

no, it's not that hard replicate FreeSnap's functions with AHK but since FreeSnap is already available, why not use it as some sort of internal app? e.g. those with FreeSnap already installed will get the extra features. just my 2¢..

(This might be a bit off topic, but since the discussion started here... But I can move it if you want.)

Actually, I think that cloning freesnap with AHK would be a good idea : freesnap is pretty inflexible : can't really change the hotkeys, which is annoying since it monopolizes a bunch of keys, some I never use (Windows Key + I, Windows Key + K Windows Key + J, etc. because they’re not convenient for me)

So, inspired by your Winmanagement Script, jpaiva, I "cloned" freesnap  . There are  certain missing features : there is no undo (it would be complex for me to do that…  BUt if you can explain me how to do it, I’ll add it) , and no incremental window resizing... I could add that eventually (with the combination of Win  + or - keys). So I could post it here if you want.

Of course, shortcut keys can be changed to one's liking by modifying the script!

[painz]

Thanks, it's almost perfect now.
Although, is it possible to suppress 'no match for grid' message and just cycle grids from #1 instead? I dont use very large grid and its perfectly fine to browse possible locations.
Also is it possible to redefine WIN key or should I redefine hotkeys for winAmp instead? (my winamp uses win+arrows too)

[jgpaiva]

You're right, when it doesn't find a match, it should just move to the first grid instead.

As for redifining the hotkeys, i'll have it use the same modifier as fastmove.

Ok, new update to incorporate the above changes, and also corrected an error with the connection with DCUpdater.

Regarding step 2 of "cycle grid elements", i know exactly how to do it, but i'll have to wait for some time to implement it since it involves quite a few changes to the way gridmove works.

[Armando]

(my winamp uses win+arrows too)

I've remapped WinAmp hotkeys to ctrl+Alt+arrows. Fairly intuitive combination, I find.

[ppass]

"no match for grid" pops up everytime the program tries to match that window agains the grid and can't find any match. I can't understand why you'd press right and then left, if it fails on right, it'll fail on left too as they both use the same mechanism..

Now that you have suppressed the "No match for grid" popup, this discussion is of no avail any more.



I found one small bug with the latest version 1.19.49. I tried it with my simple 2 zone-grid presented above. Right arrow works, but the window remains stuck when the left arrow is pressed when the window has its top 10% hidden. Maybe a small bug in your code...

Regarding step 2 of "cycle grid elements", i know exactly how to do it, but i'll have to wait for some time to implement it since it involves quite a few changes to the way gridmove works.

I hope those are not too painful changes for you (anyway, you have made the hardest part already with step1). Looking forward to step2 !

[jgpaiva]

I found one small bug with the latest version 1.19.49. I tried it with my simple 2 zone-grid presented above. Right arrow works, but the window remains stuck when the left arrow is pressed when the window has its top 10% hidden. Maybe a small bug in your code...

Actually, the problem is a little different. Some windows don't resize to larger sizes than the screen. (windows explorer is a good example.) Thus, When you try to resize them using that second grid element, they don't get the correct size, and don't get identified as being in grid 2 when you press win+left. If you try that with a window that does resize to a size larger than the screen (which is very rare, from what i can see), you'll notice that it does work as expected.

[painz]

It's really good but question again - is it possible to somehow skip grids on win-arrrows? I use grid with WindowOnTop area and when window gots to it it just shrink uncontrollably. And #2 is it possible to inject additional pseudo-selector which will autosave and restore position/size we began with? And maybe actually remap win key? Thank you.

[jgpaiva]

It's really good but question again - is it possible to somehow skip grids on win-arrrows? I use grid with WindowOnTop area and when window gots to it it just shrink uncontrollably.

That wasn't supposed to happen, it should only cicle through grid elements that move the window, not special grid elements like "run", "alwaysontop" and such... Are you sure that's happening with the latest version? (V 1.19.50)

And #2 is it possible to inject additional pseudo-selector which will autosave and restore position/size we began with?

Sorry, i don't understand what you mean.

And maybe actually remap win key? Thank you.

That already can be done, just change the modifier of "fastmove", as it uses the same one.