Smalltalk › Squeak › Squeak - Dev

The Trunk: Morphic-cmm.606.mcz

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

22 messages Options

commits-2

The Trunk: Morphic-cmm.606.mcz

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"!

Levente Uzonyi-2

Re: The Trunk: Morphic-cmm.606.mcz

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"!
>
>
>

Stéphane Rollandin

Re: The Trunk: Morphic-cmm.606.mcz

>> 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

Bert Freudenberg

Re: The Trunk: Morphic-cmm.606.mcz

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 -

Chris Muller-3

Re: The Trunk: Morphic-cmm.606.mcz

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"!
>>
>>
>>
>

Stéphane Rollandin

Re: The Trunk: Morphic-cmm.606.mcz

> 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

Stéphane Rollandin

Re: The Trunk: Morphic-cmm.606.mcz

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

Stéphane Rollandin

Re: The Trunk: Morphic-cmm.606.mcz

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

Chris Muller-4

Re: The Trunk: Morphic-cmm.606.mcz

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

dnd.png (31K) Download Attachment

Chris Muller-4

Re: The Trunk: Morphic-cmm.606.mcz

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

Chris Muller-3

Re: The Trunk: Morphic-cmm.606.mcz

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
>
>
>

Bob Arning-2

Re: The Trunk: Morphic-cmm.606.mcz

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

David T. Lewis

Re: The Trunk: Morphic-cmm.606.mcz

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

Chris Muller-3

Re: The Trunk: Morphic-cmm.606.mcz

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
>
>
>
>
>
>
>

Bob Arning-2

Re: The Trunk: Morphic-cmm.606.mcz

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

Chris Muller-3

Re: The Trunk: Morphic-cmm.606.mcz

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
>
>

Stéphane Rollandin

Re: The Trunk: Morphic-cmm.606.mcz

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 Rollandin

Re: The Trunk: Morphic-cmm.606.mcz

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

Chris Muller-3

Re: The Trunk: Morphic-cmm.606.mcz

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
>

Scott Wallace-3

Re: The Trunk: Morphic-cmm.606.mcz

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