Hi all,
I've checked in version 45 of LookEnhancements. In this release window borders have been put on a diet shedding 1/3 of their width. I thought about making it a preference, but I kind of like the thinner borders the more I look at them. If there is anyone that really wants thicker borders (we are talking 4 pixels vs. the former 6 pixels) then let me know. It would be real easy to make a preference, but I kind of don't like lots of preferences if no one particularly cares.
Anyways, enjoy.
John
Thank you, love the new thinner look, feels much nicer. As far as the docking window idea goes, I don't know how to do it, else I would submit a change set. I came to squeak for Seaside, morphic has not been on my list of things to learn, and I only get to play in squeak in my free time, which is limited.
You asked, "So the question in mind is "is it natural for windows to know about other windows as if you are laying out tiles on the screen?" or would this feature frustrate users when they are trying to overlap windows slightly?"
I'd say, does anyone "ever" want to overlap a window by 2px? I'd say not really, if they are getting the borders that close together, odds are they're trying to tile them to work with multiple windows. I played with Linux a bit recently and KDE had this as an option, when the window borders got close enough they'd just snap together, but only within a certain range, couple of pixels, or when they got close enough to the edge of the screen, they'd snap to it. I loved it, you'd only notice it when you were trying to tile, and it helped tremendously, I thought it was one the of coolest little features I'd seen and wish Windows did that, wish Squeak did that, be nice to see an autoDockWindows preference.
Hi Ramon,
On 8/8/05, Ramon Leon rleon@insario.com wrote:
Thank you, love the new thinner look, feels much nicer. As far as the docking window idea goes, I don't know how to do it, else I would submit a change set. I came to squeak for Seaside, morphic has not been on my list of things to learn, and I only get to play in squeak in my free time, which is limited.
I am interested in the docking windows idea, but I am plumb out of ideas on how to implement right now.
I played with Linux a bit recently and KDE had this as an option, when the window borders got close enough they'd just snap together, but only within a certain range, couple of pixels, or when they got close enough to the edge of the screen, they'd snap to it. I loved it, you'd only notice it when you were trying to tile, and it helped tremendously, I thought it was one the of coolest little features I'd seen and wish Windows did that, wish Squeak did that, be nice to see an autoDockWindows preference.
Sounds nice and seems like something that should be easy to implement, but the more I think about it I think it is non-trivial (unless I am thinking about it the wrong way). You'd have to know direction the user is moving the window and snap to windows in that general direction once you got near them (say 10 - 20 pixels). Then you'd have to let the user pass over that window if they wanted to keep trucking by. Also, the user should be able to unstick the window with ease and go in the opposite direction.
So the pseudo-code elludes me right now on how to do this, but I think you'd have to model direction of movement and do some edge analysis with each movement.
John
On Wed, Aug 10, 2005 at 05:30:08PM -0400, John Pierce wrote:
Sounds nice and seems like something that should be easy to implement, but the more I think about it I think it is non-trivial (unless I am thinking about it the wrong way). You'd have to know direction the user is moving the window and snap to windows in that general direction once you got near them (say 10 - 20 pixels). Then you'd have to let the user pass over that window if they wanted to keep trucking by. Also, the user should be able to unstick the window with ease and go in the opposite direction.
It does seem like it could be tricky to do live snapping in a smooth way. In particular, without fastDragWindowsForMorphic, the window picked up by the hand becomes a submorph of the hand; you might therefore have to override some very basic morph movement methods. (Or maybe not. I don't know.) However, it would not be difficult at all to simply snap the window into place at the end of the drag, which should provide a usable approximation of the same behavior. Only use would tell.
If you want to try live snapping, you basically have to track two positions for the window: its normal drag position, where it would be now in an unsnapped drag, and its actual current snapped position. On each mouseMove, you check to see if the normal drag position is within N pixels of a snap point. (Actually, this can be a snap line; the check is made for x and y coordinates almost independently.) If so, set its current position to the snap point. If not, set it to the drag point. Thus, unsticking the window is as simple as continuing to drag it in the direction you want it to move. N should not be as large as 10 to 20 pixels, though. 5 would be ample.
-Jesse
squeak-dev@lists.squeakfoundation.org