ATTENTION: You are viewing a page formatted for mobile devices; to view the full web page, click HERE.

DonationCoder.com Software > Post New Requests Here

IDEA: drag window to edge automatically resizes it

<< < (12/146) > >>

jgpaiva:
After playing with it a while, i noticed there was a small bug, that it didn't recognise the correct window, if you moved the mouse too fast.
It's fixed now, so please redownload:
GridMove Beta2.21

nudone:
not tried the .21 version yet so here are my comments for the previous.

first impressions are that this is one of the greatest improvements on the windows gui i've seen. even if it's not finished yet the potential is clear to see.

as you mentioned before - you can define a grid that would create a sort of working space in which you can quickly move windows around - like minimising and maximising but with more potential.

i've seen this tried before (even by microsoft) and the results were no were near as good as what 'gridmove' is currently providing.

i see that with the right layout you could have windows 'shrink' to the side and their content remain visible and then quickly bring them back into focus and 'grow' back to fit inside a larger grid space. this has great potential - it could easily replace the windows taskbar as it is easier to identify a 'small' window that is in view at all times rather than a narrow panel button that rests in the taskbar. it's not quite 'perfect' yet but already is starting to resemble the types of gui that you see in 'high tech' movies when they are trying to show some flashy computer interfaces on screen.

if may be a better description to say that out of a single monitor screen you can create a layout that resembles several monitors side by side. all the 'shrunken' windows can be made to display enough content to make them quickly recognisable and then a larger 'center grid' acts as the main focus center monitor.

currently i couldn't work out if the 'screen edge triggers' are implemented - i don't see any need for them with how things are working at the moment. i've had to increase the 'trigger' time slighly as the grid was appearing a bit too soon. no problem.

in the left mouse drage and pause method - it would be nice to have the same 'grey panel' area appear that represents the selected grid zone as when using the 3rd mouse button.

this isn't going to be a problem if you can provide a 'click to toggle' mechanism but in maya and 3d max the 3rd button is used to drag things around on screen so it would conflict with how 'gridmove' currently works.

otherwise the 3rd mouse drag method works really well - it would certainly be good to keep that how it is - make it bring the grid up instantly when a 3rd button drag is detected - and maybe, just have the left mouse drag and pause method work so there is a pause before the grid appears.

my original description of having zones at the edge of the screen has certainly been made unnecessary with how things are currently working.

all i can suggest for future versions is maybe extending the 'high tech gui' feel of things - perhaps allow 'window groups' to be assigned that know how to move around the screen...

or, if this is possible (i imagine it will be) that 'gridmove' can be made to work a little like the windows taskbar. description follows:

if you drag and release a window onto a grid already occupied by a window - gridmove will automatically swap the windows around

so, if you have a grid in the center of the screen that is quite large (this is your working area) and smaller grid zones down the sides of the screen - you can drag from the larger center zone to the smaller side zones and the windows from the two zones will exchange places. similar to what you have happen when you alt+tab but this is done visually and by dragging windows around rather than using the keyboard.

excellent job so far anyway, jgpaiva.

jgpaiva:
currently i couldn't work out if the 'screen edge triggers' are implemented - i don't see any need for them with how things are working at the moment. -nudone (June 02, 2006, 08:07 AM)
--- End quote ---
The "screen edge triggers" would be a trigger that would be active when the mouse was over it, without dragging a window, wasn't it? I believe that would work, but pose a few small problems: the detection of the active window might be incorrect, you would have to select the window before snaping it to the grid (notice that with the 3rd button method, you can drag any window, all it needs is to be beneath the mouse), accidental appearences of the grid would be more constant (and would stop the current work, as the grid selection would take the full screen), and, if not, the grid would have to take too much time to come up, i think.

in the left mouse drage and pause method - it would be nice to have the same 'grey panel' area-nudone (June 02, 2006, 08:07 AM)
--- End quote ---
Right, i also thought of that, but i thought that having 2 things moving (the window itself and the grey panel might be confusing, that's why i didn't include it. But i am thinking of an alternative. Possibly making the window itself simulate the snapping, instead of having the grey panel doing it. I'm not quite sure what's the best solution, though.

this isn't going to be a problem if you can provide a 'click to toggle' mechanism but in maya and 3d max the 3rd button is used to drag things around on screen so it would conflict with how 'gridmove' currently works.-nudone (June 02, 2006, 08:07 AM)
--- End quote ---
Yep, i'm aware of that problem, and it possibly will arrise in more applications. I think the best solution would be to have the "drag in window edge" system you mentioned, possibly associated with exceptions, i. e., for the general windows, it'd work just as it works now, and for assigned windows, it'd need to be dragged in the edge. (Since i already have most of the code in DialogMove, this shouldn't be too hard to create)

and maybe, just have the left mouse drag and pause method work so there is a pause before the grid appears.-nudone (June 02, 2006, 08:07 AM)
--- End quote ---
I don't think i understand what you mean, i know you noticed the time before the grid was too little, is that what you're referring to?
(the time was too short because that's my personal configuration, i don't like to drag windows around, i prefer to snap everything)

all i can suggest for future versions is maybe extending the 'high tech gui' feel of things - perhaps allow 'window groups' to be assigned that know how to move around the screen...-nudone (June 02, 2006, 08:07 AM)
--- End quote ---
Hum... I think i need you to explain me a bit more about that idea, i don't quite understand what you mean...

if you drag and release a window onto a grid already occupied by a window - gridmove will automatically swap the windows around-nudone (June 02, 2006, 08:07 AM)
--- End quote ---
Yes, we are in the same page here, when you first mentioned your idea, i immideatelly thought of the exact thing you mentioned, having this work in a similar way to a taskbar. I've seen the atempts microsoft did at this, and i thought it looked pretty good, but my screen was too small.
I think this will be the most interesting feature of the program, but it'll still take some time. (as i still have to make a decent gui, a .ini file for configuration storage, and a few default "templates" as, for what i've been through, configuring a grid layout is a bit of a "pain in the a**"). Still, i'm also very interested in seeing this too :D

excellent job so far anyway, jgpaiva.
-nudone (June 02, 2006, 08:07 AM)
--- End quote ---
:D thanks!  :Thmbsup:

jgpaiva:
Oh.. And i almost forgot.. I need to do those keyboard shortcuts ASAP..
Good thing i'm almost in vacations! :D

jgpaiva:
This is the great thing about being able to build stuff. When you need something, you can just build it.
I was needing the keyboard shortcuts, so, i made an update to gridmove.
Now, by pressing win+g, you get a dialog, where you can input a number, which can correspond to one of the grids in the layout. if it does, the active window will be moved there. If not, the active window will be minimized.

I also fixed the minimize /maximize /restore bug. The script was trying to move the window, while windows was trying to minimize /maximize /restore it, which lead to some erratic behaviour. But it's fixed now ;)

GridMove Beta 2.3

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version