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. =============== 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"! |
On Fri, 30 Mar 2012, [hidden email] 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 - |
In reply to this post by Levente Uzonyi-2
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 <[hidden email]> wrote: > On Fri, 30 Mar 2012, [hidden email] 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 |
In reply to this post by Chris Muller-3
> 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 |
In reply to this post by Chris Muller-3
> 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 |
In reply to this post by Stéphane Rollandin
>> 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 |
In reply to this post by Stéphane Rollandin
> 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 |
In reply to this post by Stéphane Rollandin
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 <[hidden email]>: >> 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 Rollandin [hidden email]: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 |
In reply to this post by Chris Muller-4
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 |
In reply to this post by Bob Arning-2
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 <[hidden email]> 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 <[hidden email]>: > > 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 Arning [hidden email] 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 [hidden email]: 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 |
In reply to this post by David T. Lewis
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 <[hidden email]> 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 |
In reply to this post by Chris Muller-3
> 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 |
In reply to this post by Stéphane Rollandin
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 <[hidden email]>: > 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 > |
In reply to this post by Stéphane Rollandin
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 |
Free forum by Nabble | Edit this page |