DonationCoder.com Software > Post New Requests Here

IDEA: drag window to edge automatically resizes it

<< < (17/146) > >>

nudone:
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:
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:
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:
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:

--- ---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,

--- ---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:
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.  :Thmbsup:

Navigation

[0] Message Index

[#] Next page

[*] Previous page