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
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
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
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
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
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
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
excellent job so far anyway, jgpaiva.
-nudone
thanks!
Recent Posts
) in portuguese.
)
