Sean 'Shaleh' Perry declaimed: > >> > >> interesting idea, does not seem to hard to implement. Although I tend to > >> believe that if the user is performing the action they should be able to see > >> the screen and react according ly. You should be able to implement this > >> algorithm with your advanced spatial recognition abilites bestowed by > >> nature. > >> Why add a less well designed engineering solution? > > > > Well, don't you sometimes think stuff like "Now snap to the da*n border > > you fu**ing piece of sh** window bas**rd!!"? > > > > Umm.. > > > > Okay, maybe I should just change my attitude or buy a better mouse. ;) > > > > no, I agree. "snap to window border" functionality assists the spatial recog > abilities as we tend to be bad at it around the 3 pixel range. Especially if > your background does not provide adequate contrast. It also makes the > operation faster. > I have edgeSnapThreshold set to 5, really like the feature. It seems to me that expanding the feature to include window edges would be good; people who like the snap-to-screen-edge effect shouldn't be put out by a little resistance when they cross a window boundary.
The idea of preventing the user from overlapping existing windows seems like overkill, snapping would do the job. IMHO: This should be a modification to the existing edgeSnapThreshold, I wouldn't want to add more properties to configure in the rc file. I envision it working like this: Whichever direction you're dragging, the leading edge of the window being moved snaps at every window boundary (left and right; top and bottom) it encounters, the sreen edge counts as a window boundary. My thinking is that this should be an easy extension of the current implementation, and would be feel intuitive to the user. PM -- Paul Mackinney [EMAIL PROTECTED]
