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

nudone · « **Reply #25 on:** May 30, 2006, 09:20 AM »

oh, and thanks for the link, kimmchii.

i think 'gridmove' is the better program, though.

jgpaiva · « **Reply #26 on:** May 30, 2006, 09:30 AM »

the scenario is like this: you move the window within a trigger zone, then you decide to move it a little bit but 'gridmove' thinks you want to auto resize the window (again).
-nudone (May 30, 2006, 09:11 AM)

Did that happen to you? I tried doing it, but all i got was a bit of flicker, since it was moved to the place, and then moved back.
The thing is: Right now, i reduced the time between the drag and the click, to avoid such situations.
Making the trigger click be longer, is not a big deal, i just am not sure if it would compensate having the work of stoping the mouse, and clicking longer, to the other effect. Still, worth a try.

i've also noticed a side effect where the window can be dragged even when the cursor is not over the title bar - this has been done in other programs several times before but maybe it would be nice to incorporate it into gridmove - only if it's a simple thing to do and it didn't create further problems - maybe it could work if both mouse buttons were held down at the same time?
-nudone (May 30, 2006, 09:11 AM)

Sorry, I didn't understand. Did you get that effect, or would you like it to be implemented?

Having it in clicking with both buttons can be done, but will conflict with other apps (like opera), and might be buggy (i'm not sure, though).
Do you have a mouse with more than 2 buttons?

nudone · « **Reply #27 on:** May 30, 2006, 09:45 AM »

i probably just need to try using the current version for a bit longer - then it probably won't have the side effects i mention.

i can drag the window when it's not over the title bar if i let the window auto resize/move and i don't release the left mouse button - so, really, the window is jumping to fit the grid zone but my mouse cursor is remaining in the same place on screen - if i keep the left mouse button down it gives the appearance that i'm dragging the window without using the title bar. it's not a problem.

the two button thing isn't worth the hassle nor is the moving windows without clicking on the titlebar.

the auto size to zone is all i wanted to i'm happy with how things are - i just need to use it a while longer to see if any other problems pop up.

thanks for the work so far.

nudone · « **Reply #28 on:** May 30, 2006, 09:57 AM »

i'm still finding the large trigger zones a problem.

this becomes especially problematic when manually adjusting a window to reduce it's size after it has taken up one half of the screen (but will be a problem also when just manually changing a window).

because the large zones make in very difficult to be out of a trigger zone it's very easy to set the trigger off just be resizing and repositioning a window. i don't really want to have to become super careful when trying to manually resize a window as it will defeat the object of having a tool like 'gridmove' automate things for you.

maybe the delay trigger unless the mouse is held down on the title bar (whilst the mouse and titlebar remain stationary) for a couple of seconds will help???

jgpaiva · « **Reply #29 on:** May 30, 2006, 10:49 AM »

Ok... I've restricted the trigger.
Now, the trigger has to be a single click. If the person tries to drag the window after dragging it once, it will not snap the window, but move it. Let's see if this makes more sense.

I'm now working on the moving windows in places other than the title bar, as i also want it

(you didn't answer me: does your mouse have a mouse wheel button?)

[edit]forgot the link.. GridMove Alfa2[/edit]

nudone · « **Reply #30 on:** May 30, 2006, 11:18 AM »

sorry, my mouse has 8 buttons so the middle/third button would be available for use.

i shall now try the new gridmove...

nudone · « **Reply #31 on:** May 30, 2006, 11:23 AM »

WOW, the latest gridmove feels like a fully pollished util now.

if it's possible to include keyboard shortcuts and the drag window without using title bar then it's going to be one fine program.

nudone · « **Reply #32 on:** May 30, 2006, 11:28 AM »

time to throw a spanner in the works...

what happens if grid zones overlap?

i was thinking that it would be nice to have a 'central' grid zone in the center of the screen that would resize windows to a nice default type of size, say 1024 x768 (i'd probably use larger) but this would overlap other grid zones - especially the type of grid zones that occupy one half of the screen. i can see that if you were careful it wouldn't matter about the overlap and i'm assuming that as it's a script the first 'zone' that is defined would take precedence.

jgpaiva · « **Reply #33 on:** May 30, 2006, 11:30 AM »

Ok... I'm loving this!
I think it's almost ready to evolve to beta

You can now move a window with middle mouse button + right button.
But only the middle mouse button has to remain pressed. Which means you can do the following:
Press middle mouse button, press right button, release right button, drag window, release middle mouse button. (sorry for the lame description, i couldn't find a better one)

Another important issue is that when you move a window this way, after you release it, it gets snapped. I've been playing with it, and it looks soooo neat!

Let's see your opinion: GridMove Alfa2

jgpaiva · « **Reply #34 on:** May 30, 2006, 11:32 AM »

what happens if grid zones overlap?
-nudone (May 30, 2006, 11:28 AM)

Here's your answer:

i'm assuming that as it's a script the first 'zone' that is defined would take precedence.
-nudone (May 30, 2006, 11:28 AM)

Yes, that's exactly it. This script goes from the first area, to the last, in order, checking if the mouse is inside that area. If it it, it moves the window, and stops.
This means, that if you define the big area as the first one, it will be prioritary.

nudone · « **Reply #35 on:** May 30, 2006, 11:43 AM »

it's certainly i nice feature but can we have it so that the third mouse button drag feature can be toggled on whether it snaps to grid or not?

i'd probably just use the 3rd mouse way just to move windows around without them snapping to grid but i can see the appeal of it doing the snap to grid also.

this isn't quite the same and maybe it's just less intuitive but how about just using the 3rd mouse button (without a right mouse click) to drag window contents but only if the cursor is positioned over the edge of a window. it may sound kind of strange but this would behave in a manner that 'windowblinds' skins work when they have a thicker window border as part of the skin - it uses the left mouse click, though, as there is a definable border to click on.

this 3rd button click on edge to move window would also be like how many of us are used to moving skinned windows around in some programs where you don't have to click on the title bar.

i'm just suggesting this method as it's a bit fiddly for me to click the 3rd mouse button and then the right mouse button and drag the mouse at the same time...

(that's a good point about the most important window coming first in the script - looks like i can define what i was after.)

jgpaiva · « **Reply #36 on:** May 30, 2006, 12:06 PM »

Yes, it'll be possible to choose whether to snap or not to the grid. Possibly in the next version.
Making the window movable when pressing the middle mouse button, and close to the border is also easy.

As for moving the window like it's right now, it's similar to what you're referring. Notice this: you only have to press the middle mouse button, then click the right button, and drag the window. I find it very useful

Ok.. Now, i'll use it the rest of the day, see if there are any bugs, and if not, tomorrow i should have a more complete version (with settings storing, gui, and such

)

nudone · « **Reply #37 on:** May 30, 2006, 12:29 PM »

excellent. i look forward to the next version.

if it's not a problem to implement all the features, i.e. the 3rd mouse button + right click to drag from anywhere and the 3rd mouse button solo to drag from window edge then i can't really ask for more.

the keyboard shortcuts are going to be something that users will expect so it would be nice to allow that for specific grid zones.

it's a fantastic job so far.

jgpaiva · « **Reply #38 on:** May 30, 2006, 12:50 PM »

if it's not a problem to implement all the features, i.e. the 3rd mouse button + right click to drag from anywhere and the 3rd mouse button solo to drag from window edge then i can't really ask for more.
-nudone (May 30, 2006, 12:29 PM)

Nope, no problem at all, that's only 4 more 'if' instructions

the keyboard shortcuts are going to be something that users will expect so it would be nice to allow that for specific grid zones.
-nudone (May 30, 2006, 12:29 PM)

Good point, i had forgotten about that. But i also want them

Now.. Just to get your opinion, check this out: GridMove Alfa3
This one, works just like you asked in the first place! (at least, it should

)
It's faster, and easier, but i think it's more limited (this was the reason that made me not adopt this system), since it can't have any groups in the middle of the screen, and also a bit more anoying, since if you accidentally drag something out of the borders, you get some incorrect behaviour.

nudone · « **Reply #39 on:** May 30, 2006, 01:39 PM »

i like the alfa 3 version - for it to work properly it requires a timer feature so there is a delay between the drag and then the resize - this should avoid the accidental resizes i would hope, i.e. you have to hold the mouse down at the edge of the screen and on the title bar for a couple of seconds.

the second click feature that you've implemented so far does feel good, though, so i'm not too concerned about my 'screen edge' zones being discarded.

it was nice to see it working, so maybe if it was tweaked a bit further the 'screen edge' method could be a nice feature to enable or disable in 'gridmove'.

if you can provide the slight delay feature before the 'edge' triggers went to work then i'd have a better idea of whether the method was worthwhile. their would be a slight difference to how you've done things, though, as the 'screen edge trigger' wasn't really meant to be a part of the 'window resize zone'.

my idea was that there are two zones for each action. there is the 'trigger zone' this could be anywhere around the edge of the screen - and then there would be it's corresponding 'window resize zone' which could be anywhere on the screen.

so, as an example, i could drag and hold a window title bar over at the bottom right edge of the screen and after two seconds the trigger would be activated and the window i was holding would automatically jump to the center of the screen and resize to 1024 x 768 - there is no need for the trigger zone and the resize grid to be next to each other. i appreciate that wouldn't be very intuitive but my main aim was to just have something that 'flowed'.

i suppose it was really a bigger version of what you get when working with panels/panes inside macromedia software and acdsee - you just drag and release - no extra mouse clicks. i just extended it a bit further by not having the 'resize zone' as part of the trigger as i thought this would be more powerful.

jgpaiva · « **Reply #40 on:** May 30, 2006, 01:47 PM »

Hum.. I can see your idea. But i dislike the delay, as it takes some time. (Can, and i think will, be implemented, though)

Ok.. I have yet another version for you to test. In my opinion, this is the best one so far.

I've realized that when someone uses the midle mouse button, it's only for one click, not for click and drag. So, i made one version that on click with that button, sends a click, and on drag, moves the window.
This might have conflicts with other programs that need to have the dragging with that button, though, so, i can easily make it be configurable (like using mouse-button4 or 5 instead).

GridMove Alfa3 (it's similar to the other one, but has the feature on the mouse middle button)

nudone · « **Reply #41 on:** May 30, 2006, 02:15 PM »

i still like the 'click again' with left mouse button to resize window when it falls within a 'resize zone' - it just felt so precise they way it worked.

the 3rd mouse drag does indeed conflict with certain programs - i think maya and 3d max are two i know of - but as you say, if you allow it to be user definable then problem solved - i'd still like to see the 3rd mouse window edge drag thing working too.

if you can implement all the methods that have been described so far but allow them to be turned on and off by the user then everyone will be happy - it's going to be one hell of a super mouse app. i can see cody dancing up and down on that keyboard with glee already

(okay, so it's in my minds eye and not on the forum page.)

nudone · « **Reply #42 on:** May 31, 2006, 03:11 AM »

here's the little app i was trying to remember earlier on...

HandyThing: http://www.starfishb...dything/basics.shtml

it doesn't really compare with gridmove. i just thought i'd include it here as another example.

jgpaiva · « **Reply #43 on:** May 31, 2006, 01:47 PM »

Ok... I think i've got to a final conclusion about the right interface.
I fixed the drag+right click interface, and it looks like the best one so far (the drag,release,left-click is a bit uncertain, sometimes, it can not do anything).

I also added a gui, that appears 1second and a half (in the next versions, it'll be costumizable), and has information on where the groups are.

The middle-button drag + right-click interface is also enhanced, it looks really good now. (try it, i'm sure you'll love it

).

I also have been testing with overlapping groups, and it works great, and has a fantastic effect.

I've had another idea (which i think is similar to your original idea):
Instead of having only areas, we could make each of the areas have a specific "trigger area", which might (or might not, depending on how the user wants it) be different from the area itself. The big advantage of it would be that the program might actually work only by dragging, and if the mouse was in a trigger zone, the window would be resized to fit the corresponding area.

(now that i think about it... this was exactly your first idea wasn't it? i'm sorry, i think i only understood it now)

GridMove Beta1

nudone · « **Reply #44 on:** May 31, 2006, 02:46 PM »

I've had another idea (which i think is similar to your original idea):
Instead of having only areas, we could make each of the areas have a specific "trigger area", which might (or might not, depending on how the user wants it) be different from the area itself. The big advantage of it would be that the program might actually work only by dragging, and if the mouse was in a trigger zone, the window would be resized to fit the corresponding area.

(now that i think about it... this was exactly your first idea wasn't it? i'm sorry, i think i only understood it now)

GridMove Beta1
-jgpaiva (May 31, 2006, 01:47 PM)

er, yes, that was the original idea but i'm glad that you came around to it in the end

better late than never as they say (they do in the UK anyway).

i shall now download the new beta1 version and let you know what happens...

nudone · « **Reply #45 on:** May 31, 2006, 02:50 PM »

unfortunately, i can't use the new beta1 version at all - as soon as i click on a window title bar and drag it my mouse cursor become locked onto the title bar and won't release ????????????????

oh dear.

jgpaiva · « **Reply #46 on:** May 31, 2006, 03:20 PM »

WTF.... I can't reproduce that, in any of the computers i am trying. I'll look into it!

nudone · « **Reply #47 on:** May 31, 2006, 04:46 PM »

thought i better try it again but whatever i do as soon as i click a title bar it sticks to my cursor.

nudone · « **Reply #48 on:** May 31, 2006, 06:08 PM »

tried again...

the title bar always becomes stuck to the mouse cursor when i click on it...

but, i can release the title bar by left double clicking - the window doesn't resize or do anything after that.

the good news is that i've seen the 'grid overlay' mechanism - and i've realised how it works (on my machine, at least).

does this sound right:

3rd mouse button click and hold inside window then right mouse click to bring up the 'grid overlay' then move cursor and right click to select 'grid'.

i've also had the 'side triggers' working - in a similar way to the above but without the 3rd mouse button click.

i've also noticed that i can't minimise or restore windows when the new beta version is running.

i can see the potential of this mechanism - it appears that the only difference to what i originaly suggested is that the edges of the screen act as a single trigger and then you move the mouse cursor to select the grid you want to resize the window into.

this seems like a very nice way of working i wish i could test it more but it's not really practical to use at the moment on my system.

i hope trying to solve it isn't too much of a headache??????

jgpaiva · « **Reply #49 on:** June 01, 2006, 09:22 AM »

I've tried it already in 4 different computers, some even without ahk installed, and never could reproduce the problem you had.

Let's try a few stuff: please download the latest version of ahk, and test the script i've attached to this post. (just run it, and follow the message boxes). Then, post if it worked correctly.

BTW, which OS are you running?

The problem you mentioned is exactly what would happen if in the following lines:

[Select]

SnapWindow:
send, {LButton up}

was

[Select]

SnapWindow:
send, {LButton down}

instead.

I'm finding it a bit odd, but let's try to find out if that's it.