Author Topic: IDEA: drag window to edge automatically resizes it (Read 780036 times)

ajp · « **Reply #75 on:** June 16, 2006, 06:56 PM »

I'm sure I keep an interesting script for this (right now I just right-click maximize to get 100% tall by 80% width window aligned to the left of the screen), but not at this computer. I'll look for it at home and bring it.

jgpaiva · « **Reply #76 on:** July 01, 2006, 07:59 AM »

Ok... Here's gridmove beta4. This should be the last beta (i hope

).
I applied the method i mentioned before, now it works like this:

If you drag a window using it's part that is closer to the caption (definable in WindowPercentage, i set it to 20% of the caption), the window is always snapped. Also, now both methods use the second gui overlay, as like this it's possible to use it.
If you drag a window using the rest of the caption, the script does nothing.

Also fixed:
The screensize problem, now the gui shows for all the screen in every computer (notice that if you have a dual-screen layout, you need to change it in the options at the beggining of the script's source).
Added commands to the Win+G hotkey:

'r' restarts the script
'e' exits the script
'mbutton' disables /enables the mbutton interaction
'm' maximizes / restores the active window
any number of the grid moves the current window to that grid element.
any number out of the grid minimizes the window.

Fixed a small problem with the transparencies
Fixed the problem with the position of the triggers being a few pixels out.

This script still lacks lots of stuff (like decent options management), but at least now it's *almost* bug-free.

So... Tell me what you think about the new interaction.
.ahk Version
(it's now beta4, because beta3 was a test i made and didn't publish)

BTW... Anyone knows of a nice icon for this script?

jgpaiva · « **Reply #77 on:** July 01, 2006, 08:02 AM »

@nudone: About your idea of having the window resize, maintaining it's width or height, i think i might have a way to do this. And it'd make much sense in this script. I'll try to make it work.

@kproth: Sorry for that bug, i think it's now fixed. Don't forget to set the ScreenHeight and ScreenWidth parameters right. (if you have 2 screens with different resolutions, set the parameters to the biggest height and biggest width).

nudone · « **Reply #78 on:** July 01, 2006, 02:35 PM »

nice to see you coming back to the old gridmove, jgpaiva

i can see that the transparency is working better but i'll have to make a few changes to the script i think - my screen does't really suit the current grid layout.

i like the idea of dragging the titled part of the title bar to initiate gridmove - my final use will be very basic (i think) so i don't think i'd even need the grid popping up, so if you can allow that to be disabled i'd appreciate that.

keep up the great work...

jgpaiva · « **Reply #79 on:** July 01, 2006, 04:11 PM »

nice to see you coming back to the old gridmove, jgpaiva
-nudone (July 01, 2006, 02:35 PM)

Old? Nah! It's the best thing since sliced bread, i use it everyday, just haven't had much time to update it.

i can see that the transparency is working better but i'll have to make a few changes to the script i think - my screen does't really suit the current grid layout.
-nudone (July 01, 2006, 02:35 PM)

Notice that it might be a better idea to change the .ini file's grid, as you can use it throughout several versions, and you won't have to change the source everytime i update. (yes, i really should change the default grid, i also don't use it like that)

i like the idea of dragging the titled part of the title bar to initiate gridmove
-nudone (July 01, 2006, 02:35 PM)

Would you consider this the best way for the script to work?

my final use will be very basic (i think) so i don't think i'd even need the grid popping up, so if you can allow that to be disabled i'd appreciate that.
-nudone (July 01, 2006, 02:35 PM)

I hadn't thought of that, good point!

nudone · « **Reply #80 on:** July 02, 2006, 04:08 AM »

i can see that gridmove has progressed further than what i originally requested so i'm a little biased when i offer my thoughts on it now.

my own personal preference is still to use the edges of the screen to trigger the resize window function - i'm still hoping that you'll include that in the final version.

why do i stubbornly stick to this view? well, i'll only have a basic grid layout (i think) - perhaps it would be good to have a way of toggling between different grids - maybe a complex grid with a variety of window sizes/zones and then a basic alternative grid with just a few zones.

i'm straying from my answer to the question above... so, i'm only going to use gridmove to resize the occasional window. most likely using it so that only two program windows cover either side of my screen at a time - no doubt i'll probably use four programs and have each window take up a quarter of the screen on the rare occassion. the final use would be to have a window resize to fit with the central part of my screen so that there is a border around it that i can see my desktop.

this basic grid layout doesn't really need to be displayed to me - it will be very symmetrical - so all i need to remember is which part of the screen sides/edge will act as the trigger, i.e. left edge of screen will resize window to fill left half of screen - right edge of screen will resize window to fill right half of screen, etc. all very simple.

of course, this is just how i would use it, someone new to gridmove may well feel better if they could see the grid appear - or, at least, until they had remembered the grid layout.

i can see that the current 'titled area of title bar' to initiate gridmove is quicker than my 'screen edge acts as trigger' method - i've just not really made up my mind about which i prefer. the speedier method ought to appeal to me more but i'm still favouring my original drag to screen edge trigger way. might be irrational - can't really say at the moment.

here's yet another idea to add to the mix - what if different grids were invoked depending on what programs were running. this could perhaps lead back to the 'group' idea.

say you often have a web browser open and a couple of other programs that you always end up putting into a particular arrangement on screen - then you could have a 'grid 01' load in when the browser is running - other grids would load in when other programs where dominant - and there would be the 'general' grid when nothing in particular was running.

i guess, really, the above multi/group grid method would be better if a particular grid loaded in if two or more specific program windows were detected on screen at the same time - not just a single program window - otherwise i can see this would get confusing when the basic 'default' grid should be in use.

jgpaiva · « **Reply #81 on:** July 02, 2006, 06:17 AM »

I already thought of that, gridmove got way more complex than your original request. I'm sorry for that

(i just have this tendency to make stuff increasingly complex, to the point that nobody, including myself, can really understand what's happening there).

I have had another idea. The system you mentioned (drag window to the edge of the screen), can be done in a similar way. (actually, wasn't it implemented on Beta2, when you had a correct trigger layout?)
How about if i added yet another interaction method (notice that the 2 interaction methods available right now will have the possibility to be disabled, just as this third one will too), where the grid would come up when the mouse was on the edges of the screen for some time (with or without dragging a window), and then, you'd only have to move the mouse to the grid trigger and it'd snap the window to it?

I think i could have the option of forcing the mouse to be at the edge of the screen while dragging a window too.

I also think that having the option to disable the grid showing is important, i'll add an option for it too.

(ok, i think that it's getting time to have a graphical gui for the options, they are growing fast

)

nudone · « **Reply #82 on:** July 02, 2006, 06:40 AM »

the more options there are the better - everyone gets to use the final version of the program in the way that they feel most comfortable with - hopefully.

i will have to revisit version two for a bit i think...

jgpaiva · « **Reply #83 on:** July 02, 2006, 03:07 PM »

Ok... Here it is, GridMove Beta 4.5.
It has grown in features (and complexity), so, i'll just make a general comment:

At the beggining of the script, there's an options area.
The first 3 options enable / disable the interaction methods:

LButtonDrag is the drag window title method. If you drag a window by it's tile, the grid comes up, you choose which one to snap and drop the window.
MButtonDrag is the drag window with Middle Mouse Button method. You press and hold the Middle mouse button, the grid comes up, you let go and the window is adjusted to the highlighted area.
EdgeDrag is new in this version, it's the interaction method where when you drag a window (not necessarly by it's title) to the edge of the screen, the grid comes up, you select the one to highlight, drop the window and it's snapped to the highlighted area.

The next options are general options:

EdgeTime is the time that will take the groups to appear when you drag a window to the edge.
ShowGroups flag specifies if the program should or not show the groups (not yet working).
Caption size is the height of the title bars of your windows (gotta make it auto-detect).
WindowPercentage is the percentage of the title bar of the window that is detected as being the title of the window (for the first interaction method).
ScreenWidth and ScreenHeight are the dimentions of the screen. (unless you have a dual-screen layout, don't touch there).

Also new in this version is the keep dimentions feature.

If you specify a Group like this in the .ini file:

[Select]

1TriggerTop=0
1TriggerBottom=800
1TriggerLeft=0
1TriggerRight=3

1GridTop=WindowHeight
1GridBottom=WindowHeight
1GridLeft=0
1GridRight=1280

It'll create a group that is activated at part of the left of your screen, and when activated will make the window expand horizontally to have 1280 pixels wide and keep it's height (and vertical position). Thus, this can be used to create horizontal maximization, if you set 1GridRight to the width of your screen.

In a similar way,

[Select]

2TriggerTop=0
2TriggerBottom=10
2TriggerLeft=0
2TriggerRight=1280

2GridTop=0
2GridBottom=770
2GridLeft=WindowWidth
2GridRight=WindowWidth

Will create a group that is activated at part of the top of your screen, and when activated will make the window expand vertically to have 770 pixels of height and keep it's width (and horizontal position). Thus, this can be used to create vertical maximization, if you set 2GridBottom to the height of your screen.

I hope you like these new updates!

nudone · « **Reply #84 on:** July 02, 2006, 03:36 PM »

i certainly like where this is heading - i need to change the grid layout and give it a good run before saying anything further.

as always, keep it up. oh, and thanks for putting the screen edge trigger back in. pity about the grid not being hidden yet, though.

jgpaiva · « **Reply #85 on:** July 02, 2006, 03:52 PM »

i need to change the grid layout and give it a good run before saying anything further.
-nudone (July 02, 2006, 03:36 PM)

Notice that you don't have to copy it all, you can use the same grid you used on the other versions, you only have to change the name of the .ini file.

thanks for putting the screen edge trigger back in. pity about the grid not being hidden yet, though.
-nudone (July 02, 2006, 03:36 PM)

Actually, the screen edge trigger was such a big problem as i thought originally. The grid hiding isn't a big deal, as right now it can already be hidden, but is buggy, and for some reason it makes the snapping not work.
Anyways, i think i know what causes that, and it should be fixed in the next version.

nudone · « **Reply #86 on:** July 02, 2006, 05:15 PM »

it's beddybies time for me now but here's my edited script of version 4.5

i'd still make a few changes to the grid layout but it's pretty much what i was after... you may find the grid layout useful.

you'll see i've disabled the 'drag title bar method' and reduced the size of the trigger zones.

jgpaiva · « **Reply #87 on:** July 02, 2006, 07:13 PM »

Ok... Great to see it fits you.
This means that GridMove is mature (at laaast!!), and i can start working on a "final" (more like "stable") version. Finally i'll be able to get it in my CodingSnacks post!

And it's ready to become a "real" program

(I've just had a great idea! a grid creator. I hope i won't forget this one when i finish up the gui and other important details)

kproth · « **Reply #88 on:** July 03, 2006, 07:08 AM »

@jgpaiva: LOVE the Gui grid view! Testing on my multi-mon system and it's definitely much better behaved. I removed groups 5-10 that "shipped" with the script, keeping just groups 1-4 (all on my primary monitor), and then I added a single new group5 sized to show on my second monitor (Top@0, Bottom@700, Left@1281, Right@2304).

Group5 functioned just fine, but the number 5 wasn't visible anywhere (even though 1-4 were).

Also, will you handle odd-sized taskbars a little cleaner in the final product? Mine is two "rows" deep, so it's 50 pixels tall, at the bottom of screen 1. I added a variable called TaskbarSize and set it to equal 50, and then changed all the "30"s in your groups (e.g. GridBottom = A_WindowHeight - 30) to use it. Would it be possible to sniff out the actual position and size of the taskbar at runtime and automatically work around it?

jgpaiva · « **Reply #89 on:** July 03, 2006, 07:24 AM »

As for the fact that group5 doesn't appear, it might be because you didn't change the screenwidth to be equal to the sum of your both screens. (i need to fix that)
If you did, please post here the 5Trigger group. (also don't forget to change the Number of groups to 5).

As for the grids, it's not complete yet. I might be able to auto-detect the size (and position) of the taskbar in later versions, and i'm thinking of including a bunch of pre-defined grids instead of only one.

kproth · « **Reply #90 on:** July 03, 2006, 07:38 AM »

Thanks jgp. Yes, I had the ScreenWidth set wrong. I interpreted your comment earlier:

if you have 2 screens with different resolutions, set the parameters to the biggest height and biggest width

to mean I should set these to the largest height and width of any single screen. Changing so ScreenWidth & ScreenHeight points to the point at the bottom right of my overall screen area fixes that problem.

kproth · « **Reply #91 on:** July 03, 2006, 07:42 AM »

Oh, sorry, had one more thought. With LButtonDrag enabled, it's odd to see the grid overlay appear when I click (or double-click) on the upper-left corner of my windows to either drop-down the window menu, or close the window.

You could fix this by adding a brief delay - LButton has to be held down for 1 second before enabling the GridMove functions. Or, by making sure the X mouse position is also Greater Than the CaptionSize (in addition to checking if the Y mouse pos is > CaptionSize...)

jgpaiva · « **Reply #92 on:** July 03, 2006, 08:03 AM »

Oh, yeah, i didn't say that correctly, screenwidth should be the width of both screens summed.

Good point about forcing the click to be off the icon in the title bar. I'll add that!

jgpaiva · « **Reply #93 on:** July 04, 2006, 06:08 PM »

Ok... This is soo much more than an update.
GridMove is now V1.0!

This release's features:

No more editing of source code, all is done through .ini files.
Smart templates, included with the script, and detect position of taskbar.
Icon!!!
Tray menu.
Configurable grids, now with .grid files, which can be shared here. (aren't adaptable like the templates yet, though)
Bug fix, related to the horizontal maximizing.

Most probably, some bugs may come up, as it's quite late and i'm tired.

Here are the links:
.exe Version
.ahk Version
icon for the .ahk Version (place it under the same directory)

mouser · « **Reply #94 on:** July 04, 2006, 06:10 PM »

holy cow, this is worth a test.

nudone · « **Reply #95 on:** July 05, 2006, 12:56 AM »

holy cow, this is worth a test.
-mouser (July 04, 2006, 06:10 PM)

mouser finally sees the light.

it is truly a day of celebration here at nud towers with gridmove reaching v1.0

will download and put it through it's paces now, jgpavia. well done, as always.

nudone · « **Reply #96 on:** July 05, 2006, 01:14 AM »

gridmove v1.0 feels reeeaaaaaal good.

fantastic.

just a couple of things i've noticed bug wise:

with the 'edge' grid loaded in - the trigger bit on the left side of the title bar seems to have expanded (is this intentional?). it's covers about a third of the titlebar.

when using the non 'edge' grids there is a slight 'jerky' appearance to my windows when i drag them around. i think this has been part of gridmove for a while (not sure) and i guess it might be unavoidable as the script is having to work out the position of the window and mouse so often. the 'jerky' effect is only slight but it would be wonderful if not there at all - maybe it's only doing it on my screen???

going back to play with gridmove a bit more now...

mouser · « **Reply #97 on:** July 05, 2006, 01:21 AM »

i think this has huge potential to be a MUST HAVE util.
but its not quite right on multimon.
jgp says he will be working to get it perfect on multimon soon.

nudone · « **Reply #98 on:** July 05, 2006, 01:28 AM »

ha, ha, i've just noticed the full height or full width auto window sizer method - i love how you can drag it around

nudone · « **Reply #99 on:** July 05, 2006, 01:41 AM »

currently i have:

[Select]

[GridSettings]
GridName=edge
[InterfaceSettings]
LButtonDrag=1
MButtonDrag=0
EdgeDrag=1
[OtherSettings]
EdgeTime=1000
ShowGroupsFlag=0
WindowPercentage=25

this has the strange effect so that i'm unable to drag the window at all from the titled part of the title bar.