DonationCoder.com Software > Post New Requests Here
IDEA: drag window to edge automatically resizes it
jgpaiva:
:D
Thank you DrIce!
Its this kind of messages that really motivate the work we all do for the community!
Good luck for your job search ;)
jgpaiva:
GridMove was updated just now ;)
- Tried to fix this
- Removed the duplicate grids from the templates menu
- Now doesn't interfeer with Office2007 (or any other "strange" window).
- "undo" button (formerly known as "restore") is now in the 2-part and 3-part grid also.
- A few code updates
There may be some problems with stuff from previous versions still in the config options. If you get any problem, try moving GridMove.ini to another folder and start GridMove again to see if problems still are there.
Let's hear your opinions ;)
tmuka:
Just noticed my gridmove was a few versions old. I am really happy after the update Gridmove plays well with Adobe CS4 suite that uses Adobe Air! Thanks for the great work!!!
major_lag:
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 (December 12, 2007, 05:15 AM)
--- End quote ---
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!
ebennetthill:
I'm having two problems with 1.19.57.
One, I did have to do the trick of turning off "advanced text services for this program" just to get it to work. I didn't have that problem with 1.19.53. I was a little panicky for a while. But the grids did work after I found that trick on the forums.
The other problem has to do with "TitleSize" and "TitleLeft". I had TitleLeft set at 150 and TitleSize set at 355 which gave me a comfortable range to grab the title bar. With 1.19.57 I'm not sure what was going on, but it shrank the left mouse grab area to just a few pixels. It seemed to be okay with the default settings, but as I increased the TitleSize, things started acting weird.
But I fixed it while messing around with the AHK version. I changed the line "if(WinWidth > 3 * TitleSize)" to "if(WinWidth > 2 * TitleSize)" and things work as they used to for me. I don't understand it. It was a fortunate guess for me.
I like the outlined trigger areas. That visualization is helpful.
Thanks,
Ben
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version