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

jgpaiva · « **Reply #125 on:** July 12, 2006, 05:13 AM »

@Mouser: Working on it

I also am for the titlebar and mbutton method, those are more practical. (i also use a lot the command-line).
Oh, that remembers me, i should be releasing a new version soon. I hope it'll be still today.

mouser · « **Reply #126 on:** July 12, 2006, 06:30 AM »

are you asking for suggestions for a new name or is GridMove the final name?
I was thinking: ScreenZones or ZoneDropper

jgpaiva · « **Reply #127 on:** July 12, 2006, 07:51 AM »

GridMove is a pretty bad name (doesn't make much sense, does it?). I'm with you, the final version should have a decent name, related to what the program actually does. Which means i'm open to suggestions

nudone · « **Reply #128 on:** July 12, 2006, 02:17 PM »

my apologies, jgpaiva.

it appears the problem i described about the taskbar not working how it normally can was due to the fact i was using on older version of gridmove. i've since tried it with the latest version and things do appear to work just as they should

i was just using an older version as it just seemed a bit simpler for me to change a few things but i think i've now realised what i needed to do with the latest version to get the same result - i just have to keep deleting the .ini file when i make the changes.

as for the keyboard shortcuts being the quickest way of using gridmove - depends on what you are doing, mouser.

this has been discussed before and it's one of those no real right or wrong answers.

if you are sat there happily working away with your hand(s) at the keyboard then using a key shortcut is going to be quicker than the mouse.

if you are sat at the computer, mouse in one hand, head propped up by your other arm - then having to break away from that position to find the keyboard isn't as fast as just dragging with the mouse. maybe i'm in a minority but i often forget that i have a left hand whilst using the computer - having to press 'alt' or 'ctrl' sometimes just winds me up - other times i have to use both hands (forget about typing), using adobe products would be very tiresome without one hand on the keyboard and the other on the mouse.

it's just whatever feels natural to do at the time - keyboard shortcuts in gridmove would be great and i'm sure i'd use them - sometimes.

my suggested way of using the screen edges as triggers has to be the slowest way of using gridmove - but speed isn't everything - i'd say whatever feels comfortable and intuitive is the more important requirement - heck, sometimes just what looks nice can overrule everything else.

mouser · « **Reply #129 on:** July 12, 2006, 02:23 PM »

i actually agree - im not one for hotkeys most of the time i prefer dragging and dropping. i just never have good luck with the edge docking effects with my multimonitor setups. i actually like the titlebar thing.

jgpaiava has got multimon support in the last gridmove really working well - very impressive work.

nudone · « **Reply #130 on:** July 12, 2006, 04:19 PM »

will there be a different way of creating grids - the current way is doing my head in. i shall persevere...

jgpaiva · « **Reply #131 on:** July 12, 2006, 06:18 PM »

Ok, glad to know it's working. The .ini file is a damn awful method of interaction with the script. The latest version doesn't have any .ini file editing (it's still not released, though).

heck, sometimes just what looks nice can overrule everything else.
-nudone (July 12, 2006, 02:17 PM)

Absolutelly true. You know what? a few days ago i decided i didn't like the way the grid is created right now. So, i created a new grid. Curious about the end result? Check the .zip attached to this post.
As you will noticed, it has absolutelly no practical use, but it's much more fun and better looking

The hotkeys are still under development but it's looking quite good!

As for improving the way the grids are created... Yes, i know that should be done, as it's quite a hard method right now, but i'll eventually make a tool to create grids, and hopefully, the next version featuring the grid changing should make a good compensation for not being able to create new ones.

[edit] forgot the .zip...

[/edit]

mouser · « **Reply #132 on:** July 13, 2006, 12:34 AM »

tool for creating grids

if you include a bunch of grids then 99.9% of users will never need to make their own, and writing a tool to help the .01% of pro users seems a waste of time. just my humble opinion. in other words, let nudone suffer

nudone · « **Reply #133 on:** July 13, 2006, 12:40 AM »

i've made 'my' grid so i'm happy now. including several grids probably does negate the need of a grid editor - providing there is always a way of manually creating a grid inside the script for those picky people like myself.

jgpaiva · « **Reply #134 on:** July 21, 2006, 07:20 PM »

At last!!
I present GridMove v1.13

New features:

Next grid / grid list. When the on drop zone mode, right click and the grid will change to the next one on the list. this list can be costumized in the options.
Options Menu. No more .ini file editing, all is done through the tray menu now.
New command mode. Pressing win+g will bring the new command window up. No more selecting number and pressing enter. Now, you only press the number of the window and it'll be moved there. If the grid has more than 9 elements, it'll wait for the next digit, but if you just give it one and wait a bit, the window will be moved. Also, by pressing 'n' you get the next grid, pressing 'r' reloads the script and pressing 'm' maximizes the window.
Dynamic Grids. Now, the custom grids can featura variables line [Monitor1Width] or [Monitor1Left], and can be expressions. This means you can create your own and share it!
MultiMonitor support. The default grids will now work on multimonitor configurations, displaying the same grid on every monitor. It's also possible to create custom grids with variables like [Monitor2Width] or [Monitor3Top].
New about box.

The dynamic grids can be created line the earlier ones, on one .grid file.

Click here for more on how to make custom grids

Variables must be enclosed in rectangular brackets.
Parentesis cam be used.
Monitor1Top represents the top of the work area of the first monitor.
MonitorReal1Top represents the top of the first monitor.
Notice that if, for example, the monitor is at the top of the screen, Monitor1Top will be 30, while MonitorReal1Top will be 0.
The variables available are top,left,right,bottom,width and height, for all screens from one to three.

The following will create a trigger that goes from the left of the work area to 1/3rd of the work area, which will make the window take the whole work area when activated.

[Select]

1TriggerTop =[Monitor1Top]
1TriggerBottom=[Monitor1Bottom]
1TriggerLeft =[Monitor1Left]
1TriggerRight =[Monitor1Left] + ([Monitor1Width] / 3)

1GridTop=[Monitor1Top]
1GridBottom=[Monitor1Bottom]
1GridLeft=[Monitor1Left]
1GridRight=[Monitor1Right]

The following code will create a trigger that goes from the half of the second monitor to it's right, and that when activated will expand the window so that it takes the whole screen. (even if there is a taskbar there).

[Select]

1TriggerTop =[Monitor2Top]
1TriggerBottom=[Monitor2Bottom]
1TriggerLeft =[Monitor2Left] + ([Monitor2Width] /2]
1TriggerRight =[Monitor2Right]

1GridTop=[MonitorReal2Top]
1GridBottom=[MonitorReal2Bottom]
1GridLeft=[MonitorReal2Left]
1GridRight=[MonitorReal2Right]

To test any of those, just copy the code, open notepad, write

[Select]

[Groups]
NumberOfGroups = 1

paste the code you'd like to try, save it as test.grid, run GridMove and go to the templates menu, select "browse" and open the file you created.

There's no problem in using a grid that was configured to work on several screens in one only screen, as the non-existent elements will be ignored.

I hope you like this new version, here's the links:
.exe version
.zip version (the .ahk version is now a .zip version as it includes several .ahk files and image files, all included in the .exe version)

mouser · « **Reply #135 on:** July 21, 2006, 07:27 PM »

i have to say a huge congratulations is due to jgpaiva for the amazing work he did getting multimonitor stuff to work.
its absolutely flawless on my multimonitor system.

it takes a tiny bit of time to get used to where you have to click near the top left titlebar area of a window, but after you get the feel for it, it comes without thinking.

really great work.

Carol Haynes · « **Reply #136 on:** July 21, 2006, 07:35 PM »

Really brilliant - this project has come such a long way since I last downloaded a copy and had a play. Congratulations on an excellent job.

nudone · « **Reply #137 on:** July 22, 2006, 02:51 AM »

fantastic work there, jgpaiva.

nice features added - i was about to say perfect but i've noticed a bug(?).

when i have left mouse button drag disabled i can't use the edge trigger method either - nothing happens at all. i've tried closing gridmove and reloading and also tried deleting the .ini file but it doesn't appear to make much difference.

i'm thinking that it's time for me to get used to the titlebar drag methods - one thing that might be nice to add to this is with the left button drag, how about having a small area in the right hand side of the title bar that serves the same purpose as the left 'selection' area - just something close to the left of the minimise button. i just feel it would be nicer if this could be done for when you are dragging windows to the right of the screen.

this is a cosmetic suggestion so may be considered of little importance - for the left mbutton drag method - how about having a visual cue for when the mouse cursor is in the 'hot' part of the title bar - just something obvious but small - a red dot next to the cursor or the actual area in the title bar that is 'hot' is overlayed with a coloured rectangle - this would also help in identifying the right hand side selection area in the titlebar that i suggested above.

i've also thought of another idea, and maybe this is going too far again - how about when using the titlebar drag methods, instead of having to drag to a position on your screen, a 'mini' grid appears under the mouse cursor that represents the screen with the gridzones marked on it - then you merely drag over a very short distance (a hundred or so pixels or less) and then release. this idea strikes me as the next logical step for gridmove - dare i say it, but perhaps it should have been how things were done from the start.

i'll shut up before i get carried away.

you can certainly be proud of gridmove - i hate to imagine how much work has gone into it. it certainly has become a util any windows user can take advantage of - that's a great achievement all in itself.

nudone · « **Reply #138 on:** July 22, 2006, 04:21 AM »

i like the win+G method too - just right for the keyboard shortcuts. excellent.

just wondering if it would be possible to use the mouse scroll wheel to select other grid layouts instead of using right mouse click (i think mouser suggested the mouse wheel) - would be kind of nice to be able to scroll up through the list as well as down through the list.

jgpaiva · « **Reply #139 on:** July 22, 2006, 04:58 AM »

Thanks nudone, there really was a bug there. Disabling the lbutton method was disabling the edge drag method.
It's now fixed.

I forgot to mention earlier, now there's also the on top grid element, which makes the windows that are dragged into it be on top, the maximize grid element, which makes the windows dragged into it be maximized, and the restore grid element that restores the window to it's last position and size, before it was snapped. (for those times when you inadvertedly resize a window and then can't get it back to the old size)

The mouse wheel method makes much sense to me, i had already thought about it. The only problem i find is that it can't be used with the mbutton drag method, as the button is pressed. I'll have to think it over.

As for being able to activate the drop zone by dragging in a place close to the right of the title bar, i'll see if that's possible without having it not allowing you from clicking the minimize/maximize/close buttons.

Now, the best part.
I can see what you mean about having the grid close to the mouse pointer, it'd make the program be way faster. And the best part is that i think this can be done. A few days ago, i tried something similar, which had great effects but it also broke half of the code. I'll look into it, and see what i can do.

As for the red dot next to the pointer when the mouse is on the titlebar, i think that's very important, specially for new users, and i'll install that asap.

Thanks!

mouser · « **Reply #140 on:** July 22, 2006, 05:02 AM »

nudone's suggestions are interesting but, speaking from personal experience, i might advise taking some time to let them sink in before embarking on implementing them.. they sound like they might involve some real work and im not sure about their long term use.

for example:
wheel select of grids - i may have suggested it but i realize now its not ergonomically fun to use wheel while left mouse is down and right clicking through grids feels perfect to me. also - i dont think very many people are going to be adjusting grids on the fly very often. i suspect we will each have our favorite and rarely change it.
grid pop up over cursor - this is a fun idea BUT it sounds like a lot of work.
red dot - this is something that seems like after you got used to the program you wouldnt need or want, but could be difficult to do without causing some side effects (occassional dots left on screen, cpu performance hit).

my #1 request in terms of efficiency would be let the digit key work after you activate grid mode even through mouse, just as they work when you hit win+g.

nudone · « **Reply #141 on:** July 22, 2006, 05:49 AM »

well, again, anything i suggest - i'd only want to see it done if it was an 'option' and not something forced on the user.

the 'mini' grid idea, well, the way it would speed things up would be good but i also realise that as you are probably going to move your cursor down to the location the window has 'zoned' to, then you probably aren't being that more efficient. the only time it would make a difference is when you were moving windows out of the way and not necessarily working with them immediately after the move.

something has just occurred to me - and maybe this is how the 'mini' grid has already been interpreted(?) - what if the 'mini' grid didn't move windows to different locations on the screen but instead only resized them...

or, again, there was the option of it doing just a resize and/or a move.

it would be nice (and look good) if as you move the cursor around the mini grid a transparent template of the new size for the window appeared and updated on-the-fly so you could see what size the window would change to when you release the mouse button.

all very complicated to implement i'm sure - it's just a thought, maybe something for gridmove version 5.

ithink the 'mini' grid idea would lend itself better to the 'ontop', 'restore' functions also.

jgpaiva · « **Reply #142 on:** July 22, 2006, 06:16 AM »

@nudone:
You actually gessed what i mentioned i had tried.
I've been thinking, and the grid on the mouse needs to have a complete rewrite of the whole code. I misunderstood what you mentioned. But i have already tested this latest options you mentioned:
If the grid was dynamic, it could use variables like mouse position and resize the window based on that information (like the maximize vertically / horizontally works now).
But this is limited, the grid's trigger has to be fixed because the gui is generated at the beggining, generating it each time the grid comes up would take too much time.
But using this grid, we could have some really cool grids.

Anyways, for now i'll focus on making the command work on drop zone mode and on the red dot helper.
Next i'll also make a "help mode", which will display some tooltips when gridmove is running, so that new users can get aquainted faster with the program

I now expect everyone's beta testing, to find bugs, and improve this program, so that it can have it's own page and go out in the public during the next week.

Also, please try to mention a better suiting name, so that i can open a poll to find the best name for it.

nudone · « **Reply #143 on:** July 22, 2006, 06:19 AM »

'gridmove' sounds kinda snappy to me.

mouser · « **Reply #144 on:** July 22, 2006, 06:58 AM »

ScreenZones?
DesktopZones?

Josh · « **Reply #145 on:** July 22, 2006, 06:11 PM »

WinSizer!

kimmchii · « **Reply #146 on:** July 22, 2006, 06:31 PM »

ScreenZones?
-mouser (July 22, 2006, 06:58 AM)

Josh · « **Reply #147 on:** July 22, 2006, 08:16 PM »

Both mouser and I thought this would be helpful to explain to users what exactly gridmove does. So here you go, your very own screencast.

The dual label bug is present in this cast. A replacement cast will be done once this bug is fixed. So please ignore it

http://josh.dcmember...sts/GM/GridMove.html

Enjoy

And again jgp, great job!

nudone · « **Reply #148 on:** July 23, 2006, 04:06 AM »

good job on the screencast, Josh, but when you do the next one can you demonstrate the way gridmove resizes the windows - this is one of its crucial features. just moving windows about isn't enough to demonstrate what 'gridmove' is really for - 'gridmove' moves and resizes and arranges windows thereby cutting down the steps it would normally take for the user to achieve the same result.

i look forward to seeing the next screencast.

jgpaiva · « **Reply #149 on:** July 23, 2006, 02:38 PM »

Hi there!
I'm glad that you are suggesting new names for the program

Josh: thanks for the screencast!
I noticed it's quie weird, though. This means i need your full specs, to try to trace the bug. Tell me, normally the command is on the right of your screen or did it happen only on the screencast? (did you change your resolution or are you using some function of the screencast program?)
I also noticed the grid is all messed up :S

I'm currently not at home, which means i'll be posting less. Nevertheless, i'm updating more. I've already made the feature mouser asked, made some more templates (included in the for of .grid files so that you can learn how to make custom grids).
Also, I've changed the .grid files syntax, so that you can create a grid only by copy-pasting stuff from other grids. Please don't create your own grids right now, as it'll not work on the next version.
I hope i'll upload the new version as soon as possible (which should be in about 24hours from today.

Nudone: I know you made your own grid. I'm sorry for this, but it won't take you much time to convert it to the new format.