On Fri, 30 Mar 2012, commits@source.squeak.org wrote:
Chris Muller uploaded a new version of Morphic to project The Trunk: http://source.squeak.org/trunk/Morphic-cmm.606.mcz
==================== Summary ====================
Name: Morphic-cmm.606 Author: cmm Time: 5 January 2012, 10:12:46.114 pm UUID: b3bb5602-a323-4e67-a26d-236676c67c76 Ancestors: Morphic-laza.605
Pick up halo to behave the same as a red-button grab.
This change has an unwelcome side effect. When you pick up a morph with the halo, then it will move away, so that the center of the morph will be under your mouse pointer.
Levente
=============== Diff against Morphic-laza.605 ===============
Item was changed: ----- Method: HaloMorph>>doGrab:with: (in category 'private') ----- doGrab: evt with: grabHandle "Ask hand to grab my target."
self obtainHaloForEvent: evt andRemoveAllHandlesBut: grabHandle.
- evt hand attachMorph: target.
- evt hand grabMorph: target. self step. "update position if necessary" evt hand addMouseListener: self. "Listen for the drop"!
Name: Morphic-cmm.606 Author: cmm Time: 5 January 2012, 10:12:46.114 pm UUID: b3bb5602-a323-4e67-a26d-236676c67c76 Ancestors: Morphic-laza.605
Pick up halo to behave the same as a red-button grab.
This change has an unwelcome side effect. When you pick up a morph with the halo, then it will move away, so that the center of the morph will be under your mouse pointer.
Definitely not good !
Stef
On 30.03.2012, at 11:26, Stéphane Rollandin wrote:
Name: Morphic-cmm.606 Author: cmm Time: 5 January 2012, 10:12:46.114 pm UUID: b3bb5602-a323-4e67-a26d-236676c67c76 Ancestors: Morphic-laza.605
Pick up halo to behave the same as a red-button grab.
This change has an unwelcome side effect. When you pick up a morph with the halo, then it will move away, so that the center of the morph will be under your mouse pointer.
Definitely not good !
Stef
Yep. What was the problem, Chris?
- Bert -
Well, that was the primary _effect_ I want -- not a side-effect.
The problem with picking up by the black halo (top center) is comes when I want to drop it somewhere. I can't get the positioning I want, especially if its near the edge of the screen.
Allow me to turn the question back to you? Why do we have two types of grabs for Morphs depending on how we pick it up? One which attaches the Morph to the hand, another which attaches the halo to the hand and leaves the Morph following along well below the hand (and making it difficult to operate DnD interfaces)...
Thanks..
On Fri, Mar 30, 2012 at 4:23 AM, Levente Uzonyi leves@elte.hu wrote:
On Fri, 30 Mar 2012, commits@source.squeak.org wrote:
Chris Muller uploaded a new version of Morphic to project The Trunk: http://source.squeak.org/trunk/Morphic-cmm.606.mcz
==================== Summary ====================
Name: Morphic-cmm.606 Author: cmm Time: 5 January 2012, 10:12:46.114 pm UUID: b3bb5602-a323-4e67-a26d-236676c67c76 Ancestors: Morphic-laza.605
Pick up halo to behave the same as a red-button grab.
This change has an unwelcome side effect. When you pick up a morph with the halo, then it will move away, so that the center of the morph will be under your mouse pointer.
Levente
=============== Diff against Morphic-laza.605 ===============
Item was changed: ----- Method: HaloMorph>>doGrab:with: (in category 'private') ----- doGrab: evt with: grabHandle "Ask hand to grab my target."
self obtainHaloForEvent: evt andRemoveAllHandlesBut: grabHandle.
- evt hand attachMorph: target.
- evt hand grabMorph: target.
self step. "update position if necessary" evt hand addMouseListener: self. "Listen for the drop"!
Well, that was the primary _effect_ I want -- not a side-effect.
Sorry but that is not acceptable. For fine-tuning of the morph position, the halo must be stable: just grabing the handle should not move the morph.
Think of it this way: you grab the morph via the halo handle, then decide that eventually you do not want to move it: esay, you just release the handle and that'is it. But if the morph has been moved immediately, how do you get back to the initial position ?
Also, a morph may have a specific behavior depending on its precise position, and it is then crucial to be able to change the position continuously.
As far as I am concerned, this change would completely break my code. I am strongly opposed to it.
Best,
Stef
Sorry but that is not acceptable. For fine-tuning of the morph position, the halo must be stable: just grabing the handle should not move the morph.
You are talking about two different things: Moving the morph vs. picking up the morph. If you only want fine tuning of the morph position it is much better handled by one of:
1) using the brown handle 2) invoking the halos and then using the arrow keys to move it one-pixel at a time.
Think of it this way: you grab the morph via the halo handle, then decide that eventually you do not want to move it: esay, you just release the handle and that'is it. But if the morph has been moved immediately, how do you get back to the initial position ?
I would never use the black halo to only move a morph. I use it when I want to *pick it up*.
Also, a morph may have a specific behavior depending on its precise position, and it is then crucial to be able to change the position continuously.
As far as I am concerned, this change would completely break my code. I am strongly opposed to it.
Ok that's fine. The way it is now breaks my code, so perhaps a preference can resolve our differences.
- Chris
On Sat, Mar 31, 2012 at 11:16:18AM -0500, Chris Muller wrote:
As far as I am concerned, this change would completely break my code. I am strongly opposed to it.
Ok that's fine. The way it is now breaks my code, so perhaps a preference can resolve our differences.
Eeek! Please avoid adding another preference if at all possible. If different behavior is needed, surely there must be some way to achieve it without breaking backward compatibility. Preferences are great for tailoring look and feel and such, but not for specifying fundamental behavior that affects various subsystems in different ways.
question: "why is my foo window acting wierd?" answer: "it must by the freeble preference, try setting it the other way" question: "ok, foo is working now, but what's up this other window, it's acting wierd now" answer: "oh yes of course, you should set freeble back the other way if you want to do that" question: "huh?!?"
Dave
Dave, I appreciate your point about preferences. But where does this leave the discussion?
Stéphane at least engaged, even if I didn't understand the logic ("Fine-tuning of Morph position"). You don't like my solution, but offer no alternative nor even address the validity of my complaint.
Even if I don't gain this fix, I'd like to learn something from y'all. I'm evaluating other solutions like whatever happened to that preference which would put the halos *within* the morph's bounds rather than outside..? Oh, maybe it was #haloEnclosesFullBounds except that currently appears to do nothing. Could I fix that to toggle halos being inset rather than outset? At least then the morph would be under the hand for 'pick-up' and 'duplicate'..
On Sat, Mar 31, 2012 at 12:52 PM, David T. Lewis lewis@mail.msen.com wrote:
On Sat, Mar 31, 2012 at 11:16:18AM -0500, Chris Muller wrote:
As far as I am concerned, this change would completely break my code. I am strongly opposed to it.
Ok that's fine. The way it is now breaks my code, so perhaps a preference can resolve our differences.
Eeek! Please avoid adding another preference if at all possible. If different behavior is needed, surely there must be some way to achieve it without breaking backward compatibility. Preferences are great for tailoring look and feel and such, but not for specifying fundamental behavior that affects various subsystems in different ways.
question: "why is my foo window acting wierd?" answer: "it must by the freeble preference, try setting it the other way" question: "ok, foo is working now, but what's up this other window, it's acting wierd now" answer: "oh yes of course, you should set freeble back the other way if you want to do that" question: "huh?!?"
Dave
An idea: add a preference for a new handle in the halo. This handle would behave exactly like the black one, except that it would appear right under the hand, not in the halo rectangle.
This would allow you to grab the morph wherever it is, while keeping the morph unmoved upon grabbing; everybody is happy. Or is it ?
Stef
Yeah, that's even better than inset halos because then the morph could be grabbed whereever you wanted, which I think addresses the core of the issue I having with DnD.. But now I even want to see if there's even a way to fiddle my DnD code to see if I can get it to work with attached (vs. grabbed) morphs. I reverted the change.
2012/4/1 Stéphane Rollandin lecteur@zogotounga.net:
An idea: add a preference for a new handle in the halo. This handle would behave exactly like the black one, except that it would appear right under the hand, not in the halo rectangle.
This would allow you to grab the morph wherever it is, while keeping the morph unmoved upon grabbing; everybody is happy. Or is it ?
Stef
Stéphane at least engaged, even if I didn't understand the logic ("Fine-tuning of Morph position").
The logic is that, generally speaking, we do not know why a morph is where it is. A specialized morph may very well rely on its position to have a specific effect (think of a slider controlling sound volume, whatever is owner is; just a dumb example). So we do not want to have a default behavior for grabbing that does not ensure that the morph stays where it is upon grabbing. Else we would be mangling the action of "grabbing" with the action of "moving" (actually loosing the morph initial position, which is even worse).
I have actual instances of this pattern in muO, but it would be too much to describe them here. Play with muO and you'll see them :)
Stef
I see the black halo's purpose as for changing Morph ownership hierarchy, not moving or positioning. Brown halo is for moving.
2012/3/31 Stéphane Rollandin lecteur@zogotounga.net:
Well, that was the primary _effect_ I want -- not a side-effect.
Sorry but that is not acceptable. For fine-tuning of the morph position, the halo must be stable: just grabing the handle should not move the morph.
Think of it this way: you grab the morph via the halo handle, then decide that eventually you do not want to move it: esay, you just release the handle and that'is it. But if the morph has been moved immediately, how do you get back to the initial position ?
Also, a morph may have a specific behavior depending on its precise position, and it is then crucial to be able to change the position continuously.
As far as I am concerned, this change would completely break my code. I am strongly opposed to it.
Best,
Stef
The black halo does a bit more than change ownership hierarchy. It is also useful for bringing a morph to the front while leaving its ownership exactly the same.
Cheers, Bob
On 3/31/12 12:29 PM, Chris Muller wrote:
I see the black halo's purpose as for changing Morph ownership hierarchy, not moving or positioning. Brown halo is for moving.
2012/3/31 Stéphane Rollandinlecteur@zogotounga.net:
Well, that was the primary _effect_ I want -- not a side-effect.
Sorry but that is not acceptable. For fine-tuning of the morph position, the halo must be stable: just grabing the handle should not move the morph.
Think of it this way: you grab the morph via the halo handle, then decide that eventually you do not want to move it: esay, you just release the handle and that'is it. But if the morph has been moved immediately, how do you get back to the initial position ?
Also, a morph may have a specific behavior depending on its precise position, and it is then crucial to be able to change the position continuously.
As far as I am concerned, this change would completely break my code. I am strongly opposed to it.
Best,
Stef
I know of no way for the black halo to be used for that. When it is clicked, ownership is always changed, the morph becomes owned by the Hand..
What you describe is the "Bring to front" on the red-halo menu.
Am I missing a case that you're describing?
On Sat, Mar 31, 2012 at 11:54 AM, Bob Arning arning315@comcast.net wrote:
The black halo does a bit more than change ownership hierarchy. It is also useful for bringing a morph to the front while leaving its ownership exactly the same.
Cheers, Bob
On 3/31/12 12:29 PM, Chris Muller wrote:
I see the black halo's purpose as for changing Morph ownership hierarchy, not moving or positioning. Brown halo is for moving.
2012/3/31 Stéphane Rollandin lecteur@zogotounga.net:
Well, that was the primary _effect_ I want -- not a side-effect.
Sorry but that is not acceptable. For fine-tuning of the morph position, the halo must be stable: just grabing the handle should not move the morph.
Think of it this way: you grab the morph via the halo handle, then decide that eventually you do not want to move it: esay, you just release the handle and that'is it. But if the morph has been moved immediately, how do you get back to the initial position ?
Also, a morph may have a specific behavior depending on its precise position, and it is then crucial to be able to change the position continuously.
As far as I am concerned, this change would completely break my code. I am strongly opposed to it.
Best,
Stef
Ah, yes. I was thinking more of the whole process rather than individual phases. I often use the back handle to bring a morph to front, so that while it may be briefly owned by the hand, it returns to its original owner rather quickly. I had forgotten that there was the menu item you mentioned.
Cheers, Bob
On 4/1/12 11:55 AM, Chris Muller wrote:
I know of no way for the black halo to be used for that. When it is clicked, ownership is always changed, the morph becomes owned by the Hand..
What you describe is the "Bring to front" on the red-halo menu.
Am I missing a case that you're describing?
On Sat, Mar 31, 2012 at 11:54 AM, Bob Arningarning315@comcast.net wrote:
The black halo does a bit more than change ownership hierarchy. It is also useful for bringing a morph to the front while leaving its ownership exactly the same.
Cheers, Bob
On 3/31/12 12:29 PM, Chris Muller wrote:
I see the black halo's purpose as for changing Morph ownership hierarchy, not moving or positioning. Brown halo is for moving.
2012/3/31 Stéphane Rollandinlecteur@zogotounga.net:
Well, that was the primary _effect_ I want -- not a side-effect.
Sorry but that is not acceptable. For fine-tuning of the morph position, the halo must be stable: just grabing the handle should not move the morph.
Think of it this way: you grab the morph via the halo handle, then decide that eventually you do not want to move it: esay, you just release the handle and that'is it. But if the morph has been moved immediately, how do you get back to the initial position ?
Also, a morph may have a specific behavior depending on its precise position, and it is then crucial to be able to change the position continuously.
As far as I am concerned, this change would completely break my code. I am strongly opposed to it.
Best,
Stef
On Mar 31, 2012, at 4:58 AM, Stéphane Rollandin wrote:
Well, that was the primary _effect_ I want -- not a side-effect.
Sorry but that is not acceptable. For fine-tuning of the morph position, the halo must be stable: just grabing the handle should not move the morph.
It bears mentioning that cmd-drag is an exact equivalent to brown-handle-drag (i.e. as you drag, it repositions the object within its container,) but with the advantage that the point of contact for the drag is on the object, not on a halo handle outside the object's bounds.
This allows precise positioning (even at the top of the screen,) with none of the disadvantages that have been mentioned in this thread.
(By cmd-drag I mean use whatever mouse-button and perhaps modifier key gesture you normally use to bring up the halo on a morph, but instead of *cmd-clicking* on the morph, "cmd-drag" it by moving the mouse with that same mouse button down.)
-- Scott
Also, by holding Control key when doing this, performs a resize of the morph in place, including SystemWindows.
And once you get used to moving _everything_ this way, including SystemWindows, you'll never go back to using the title bar for moving windows.
Together, these gestures reduce time spent moving/resizing windows by a significant factor. I've gotten used to it, and it's really noticeable when I have to operate in a conventional windowing environment that doesn't support this because it's back to a fine-motor aim for every move and resize and it feels cumbersome..
On Tue, Apr 3, 2012 at 3:38 AM, Scott Wallace SqueakList@pacbell.net wrote:
On Mar 31, 2012, at 4:58 AM, Stéphane Rollandin wrote:
Well, that was the primary _effect_ I want -- not a side-effect.
Sorry but that is not acceptable. For fine-tuning of the morph position, the halo must be stable: just grabing the handle should not move the morph.
It bears mentioning that cmd-drag is an exact equivalent to brown-handle-drag (i.e. as you drag, it repositions the object within its container,) but with the advantage that the point of contact for the drag is on the object, not on a halo handle outside the object's bounds.
This allows precise positioning (even at the top of the screen,) with none of the disadvantages that have been mentioned in this thread.
(By cmd-drag I mean use whatever mouse-button and perhaps modifier key gesture you normally use to bring up the halo on a morph, but instead of *cmd-clicking* on the morph, "cmd-drag" it by moving the mouse with that same mouse button down.)
-- Scott
The problem with picking up by the black halo (top center) is comes when I want to drop it somewhere. I can't get the positioning I want, especially if its near the edge of the screen.
Well you can just put it close to the position you want, then use the brown handle to slide it where you want.
Now if that does not do what you want, I propose you add another handle to the halo with the behavior you like.
But please do not break the current behavior. You are not alone using morphs.
Stef
The problem with picking up by the black halo (top center) is comes when I want to drop it somewhere. I can't get the positioning I want, especially if its near the edge of the screen.
Well you can just put it close to the position you want, then use the brown handle to slide it where you want.
If the morph isn't using automatic layout, and it's near the edge, you won't be able to do that. Also, I guess my question remains: Other than legacy code, is this a good design? Two behaviors for picking something up?
Now if that does not do what you want, I propose you add another handle to the halo with the behavior you like.
That would be too ambiguous. I think a preference would be better.
But please do not break the current behavior. You are not alone using morphs.
Yeah, I know that Stéphane. Don't worry, I'm not going to leave your code broken.
- Chris
Allow me to turn the question back to you? Why do we have two types of grabs for Morphs depending on how we pick it up? One which attaches the Morph to the hand, another which attaches the halo to the hand and leaves the Morph following along well below the hand
Both types behave similarly: they do not move the morph upon grabbing it. You have to move the hand to move the morph, which makes sense to me.
Stef
squeak-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Bob Arning -
Chris Muller -
Chris Muller -
David T. Lewis -
Levente Uzonyi -
Scott Wallace -
Stéphane Rollandin