Hey ppass.
About the suggestions regarding fastmove:
Currently, none of those are possible, simply because gridmove isn't aware of where the window is. I mean, it only moves the window to a grid, and doesn't keep track of which windows are in which grids. It's not impossible to implement your suggestions, only something i can't do right now.
About having the windows move to the other screen... You can make your own gird, which could have for example in monitor 1, an element that would move the window to monitor 2, and in mornitor 2 would have an element that would move to monitor 1.
ps: I have attached to this post, another version of axcrusik's grid, which allows you to, in conjuntion with being able to move windows with the numpad, move them in a way that makes more sense.
To install it, just add it to the "grids" folder of gridmove, and replace the earlier version.
Another interesting feature is that now you can add a modifier to reach for numbers higher than 10 faster. Check on the ini file, and set the key FastMoveMeta like this:
FastMoveMeta=\
That will allow you to move a window to area 11 by pressing win+\ followed by 1 (instead of 11 like when you press win+g).
-jgpaiva
I would like to throw my vote in with ppass; I would appreciate a mechanism to migrate a window from one grid space to an adjacent one using a single key combination, and the ability to repeat that same motion to achieve a desired location further along. Identifying the grid space currently occupied by a window I don't think is too rigorous a task. I'll man up and throw down some pseudocode:
; given W as window, D as direction pushed (1-8)
nearestDistance := MAX_INT ; or some arbitrary large number
nearestGroup := 0
maximumDistance := 50 ; this would be set through the UI
minimumDistance := 4 ; for rounding errors, perhaps?
for each G in Groups
distance := abs(G.left - W.left) + abs(G.right - W.right) + abs(G.top - W.top) + abs(G.bottom - W.bottom)
if distance < nearestDistance
nearestDistance := distance
nearestGroup := G
if nearestDistance < minimumDistance
; this is most likely it; quit looking.
break
end if
end if
end for
if nearestDistance < maximumDistance
; this window is 'close enough' to nearestGrid; move from there
Move(W, NextGrid(nearestGrid, D))
else
; this window is too far from nearestGrid; move to there
Move(W, nearestGrid)
end if
The minimum distance keeps it from searching if we've found the right window (or the window which invariably will be the one selected). The maximum distance allows for windows which don't resize well (like cmd.exe) to still be considered 'in' a grid area.
you could add a single element (GridNext) to the grid file relating directions moved to grid segments, like so:
[1]
TriggerTop = [Monitor1Top] + [Monitor1Height] /3 *2
TriggerRight = [Monitor1Left] + [Monitor1Width] /3
TriggerBottom = [Monitor1Bottom]
TriggerLeft = [Monitor1Left]
GridTop = [Monitor1Top] + [Monitor1Height] /3 *2
GridRight = [Monitor1Left] + [Monitor1Width] /3
GridBottom = [Monitor1Bottom]
GridLeft = [Monitor1Left]
GridNext = 2,5,4,1,1,1,1,1
Which would represent the next grid segment in a cardinal direction (numbered from right, incrementing as we move counter-clockwise) so if the grid network were arranged as a number pad this would be a suitable entry for the '1' key region, moving to 2 on a right direction, 5 on up-right, and 4 on up.
Anyway, I realize that we are all busy. No rush or anything, but I'd be extra-ordinarily grateful for this addition.
Thanks!
