Smalltalk › Squeak › Squeak - Dev

The Inbox: Morphic-pre.1329.mcz

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

9 messages Options

commits-2

The Inbox: Morphic-pre.1329.mcz

A new version of Morphic was added to project The Inbox:
http://source.squeak.org/inbox/Morphic-pre.1329.mcz

==================== Summary ====================

Name: Morphic-pre.1329
Author: pre
Time: 15 March 2017, 4:16:07.772309 pm
UUID: bb5c49b1-402a-9443-b129-ae2e0f250f8f
Ancestors: Morphic-edc.1328

Changes the accept dropping behavior of the world to open the morph for a dropped object where it was dropped.

=============== Diff against Morphic-edc.1328 ===============

Item was changed:
----- Method: PasteUpMorph>>acceptDroppingMorph:event: (in category 'dropping/grabbing') -----
acceptDroppingMorph: dropped event: evt
"The supplied morph, known to be acceptable to the receiver, is now to be assimilated; the precipitating event is supplied"

| aMorph |
aMorph := self morphToDropFrom: dropped.
self isWorldMorph
ifTrue:["Add the given morph to this world and start stepping it if it wants to be."
+ aMorph position: evt position.
self addMorphFront: aMorph.
(aMorph fullBounds intersects: self viewBox) ifFalse:
[Beeper beep. aMorph position: self bounds center]]
ifFalse:[super acceptDroppingMorph: aMorph event: evt].

aMorph submorphsDo: [:m | (m isKindOf: HaloMorph) ifTrue: [m delete]].
aMorph allMorphsDo: "Establish any penDown morphs in new world"
[:m | | tfm mm |
m player ifNotNil:
[m player getPenDown ifTrue:
[((mm := m player costume) notNil and: [(tfm := mm owner transformFrom: self) notNil])
ifTrue: [self noteNewLocation: (tfm localPointToGlobal: mm referencePosition)
forPlayer: m player]]]].

self isPartsBin
ifTrue:
[aMorph isPartsDonor: true.
aMorph stopSteppingSelfAndSubmorphs.
aMorph suspendEventHandler]
ifFalse:
[self world startSteppingSubmorphsOf: aMorph].

" self presenter morph: aMorph droppedIntoPasteUpMorph: self."
self griddingOn ifTrue: [aMorph position: (self gridPoint: aMorph position)].
self showingListView ifTrue:
[self sortSubmorphsBy: (self valueOfProperty: #sortOrder).
self currentWorld abandonAllHalos].

self bringTopmostsToFront.
!

Hannes Hirzel

Re: The Inbox: Morphic-pre.1329.mcz

Could you please give more details and a use case? (screen shot)

--Hannes

On Wed, 15 Mar 2017 15:16:31 0000, [hidden email]
<[hidden email]> wrote:

> A new version of Morphic was added to project The Inbox:
> http://source.squeak.org/inbox/Morphic-pre.1329.mcz
>
> ==================== Summary ====================
>
> Name: Morphic-pre.1329
> Author: pre
> Time: 15 March 2017, 4:16:07.772309 pm
> UUID: bb5c49b1-402a-9443-b129-ae2e0f250f8f
> Ancestors: Morphic-edc.1328
>
> Changes the accept dropping behavior of the world to open the morph for a
> dropped object where it was dropped.
>
> =============== Diff against Morphic-edc.1328 ===============
>
> Item was changed:
> ----- Method: PasteUpMorph>>acceptDroppingMorph:event: (in category
> 'dropping/grabbing') -----
> acceptDroppingMorph: dropped event: evt
> "The supplied morph, known to be acceptable to the receiver, is now to be
> assimilated; the precipitating event is supplied"
>
> | aMorph |
> aMorph := self morphToDropFrom: dropped.
> self isWorldMorph
> ifTrue:["Add the given morph to this world and start stepping it if it
> wants to be."
> + aMorph position: evt position.
> self addMorphFront: aMorph.
> (aMorph fullBounds intersects: self viewBox) ifFalse:
> [Beeper beep. aMorph position: self bounds center]]
> ifFalse:[super acceptDroppingMorph: aMorph event: evt].
>
> aMorph submorphsDo: [:m | (m isKindOf: HaloMorph) ifTrue: [m delete]].
> aMorph allMorphsDo: "Establish any penDown morphs in new world"
> [:m | | tfm mm |
> m player ifNotNil:
> [m player getPenDown ifTrue:
> [((mm := m player costume) notNil and: [(tfm := mm owner
> transformFrom: self) notNil])
> ifTrue: [self noteNewLocation: (tfm localPointToGlobal: mm
> referencePosition)
> forPlayer: m player]]]].
>
> self isPartsBin
> ifTrue:
> [aMorph isPartsDonor: true.
> aMorph stopSteppingSelfAndSubmorphs.
> aMorph suspendEventHandler]
> ifFalse:
> [self world startSteppingSubmorphsOf: aMorph].
>
> " self presenter morph: aMorph droppedIntoPasteUpMorph: self."
> self griddingOn ifTrue: [aMorph position: (self gridPoint: aMorph
> position)].
> self showingListView ifTrue:
> [self sortSubmorphsBy: (self valueOfProperty: #sortOrder).
> self currentWorld abandonAllHalos].
>
> self bringTopmostsToFront.
> !
>
>
>

Patrick R.

Re: The Inbox: Morphic-pre.1329.mcz

This allows for more "intuitive" drag and drop behavior. When I drop something into the world and a morph is opened for it than the morph is displayed at the position where the element was dropped. For a simple example so the gif attached.

To avoid confusions: I have already moved the change into trunk. However, I am thankful for you bringing this up as I am not sure about all implications yet.
________________________________________
From: Squeak-dev <[hidden email]> on behalf of H. Hirzel <[hidden email]>
Sent: Wednesday, March 22, 2017 10:02
To: [hidden email]
Subject: Re: [squeak-dev] The Inbox: Morphic-pre.1329.mcz

Could you please give more details and a use case? (screen shot)

--Hannes

On Wed, 15 Mar 2017 15:16:31 0000, [hidden email]
<[hidden email]> wrote:

dndrop.gif (266K) Download Attachment

Bob Arning-2

Re: The Inbox: Morphic-pre.1329.mcz

I guess one question is why the bowl was attached to the hand at the lower left corner of the bowl rather than the upper left. If it had been attached at the upper left, then it probably would have dropped right where expected.

On 3/23/17 11:13 AM, Rein, Patrick wrote:

This allows for more "intuitive" drag and drop behavior. When I drop something into the world and a morph is opened for it than the morph is displayed at the position where the element was dropped. For a simple example so the gif attached.

Patrick R.

Re: The Inbox: Morphic-pre.1329.mcz

Well before the change, the morph would have opened anywhere in the world. Most of the time that was not close to the hand.

You are right though, that the new behavior look weird too... Maybe this is because it looks good for dragging menu items?

From: Squeak-dev <[hidden email]> on behalf of Bob Arning <[hidden email]>
Sent: Thursday, March 23, 2017 16:36
To: [hidden email]
Subject: Re: [squeak-dev] The Inbox: Morphic-pre.1329.mcz

On 3/23/17 11:13 AM, Rein, Patrick wrote:

This allows for more "intuitive" drag and drop behavior. When I drop something into the world and a morph is opened for it than the morph is displayed at the position where the element was dropped. For a simple example so the gif attached.

Bob Arning-2

Re: The Inbox: Morphic-pre.1329.mcz

The real question is how the morph got attached to the hand in the first place. People have been picking morphs up and dropping them for decades, so there is something new here. Do you have the code that put the bowl into the hand?

On 3/23/17 11:43 AM, Rein, Patrick wrote:

Well before the change, the morph would have opened anywhere in the world. Most of the time that was not close to the hand.

You are right though, that the new behavior look weird too... Maybe this is because it looks good for dragging menu items?
From: Squeak-dev [hidden email] on behalf of Bob Arning [hidden email]
Sent: Thursday, March 23, 2017 16:36
To: [hidden email]
Subject: Re: [squeak-dev] The Inbox: Morphic-pre.1329.mcz
I guess one question is why the bowl was attached to the hand at the lower left corner of the bowl rather than the upper left. If it had been attached at the upper left, then it probably would have dropped right where expected.

On 3/23/17 11:13 AM, Rein, Patrick wrote:
This allows for more "intuitive" drag and drop behavior. When I drop something into the world and a morph is opened for it than the morph is displayed at the position where the element was dropped. For a simple example so the gif attached.

Patrick R.

Re: The Inbox: Morphic-pre.1329.mcz

Hi Bob,

I think I see now what I missed out in my explanation. Ordinary morph drag and drop should not be affected by my change at all.

Actually you can still drag and drop morphs like before (even openInHand and dropping it afterwards).

What I intented to change was the drop behavior for the mechanism for opening a morph for an object dropped in the world (basically PasteUpMorph>>transferMorphConverter:).

For example, my method checks whether the dropped object is a Model and if so tries to open it with ToolBuilder.

The drag starts in PluggableTreeMorph>>#startDrag: to answer your initial question.

Bests

Patrick

From: Squeak-dev <[hidden email]> on behalf of Bob Arning <[hidden email]>
Sent: Thursday, March 23, 2017 18:15
To: [hidden email]
Subject: Re: [squeak-dev] The Inbox: Morphic-pre.1329.mcz

On 3/23/17 11:43 AM, Rein, Patrick wrote:

Well before the change, the morph would have opened anywhere in the world. Most of the time that was not close to the hand.

You are right though, that the new behavior look weird too... Maybe this is because it looks good for dragging menu items?
From: Squeak-dev [hidden email] on behalf of Bob Arning [hidden email]
Sent: Thursday, March 23, 2017 16:36
To: [hidden email]
Subject: Re: [squeak-dev] The Inbox: Morphic-pre.1329.mcz
I guess one question is why the bowl was attached to the hand at the lower left corner of the bowl rather than the upper left. If it had been attached at the upper left, then it probably would have dropped right where expected.

On 3/23/17 11:13 AM, Rein, Patrick wrote:
This allows for more "intuitive" drag and drop behavior. When I drop something into the world and a morph is opened for it than the morph is displayed at the position where the element was dropped. For a simple example so the gif attached.

Patrick R.

Re: The Inbox: Morphic-pre.1329.mcz

I just also made a small gif to show the usual use case of dropping an object in the world which is not a morph yet.

From: Squeak-dev <[hidden email]> on behalf of Rein, Patrick
Sent: Friday, March 24, 2017 09:39
To: The general-purpose Squeak developers list
Subject: Re: [squeak-dev] The Inbox: Morphic-pre.1329.mcz

Hi Bob,

I think I see now what I missed out in my explanation. Ordinary morph drag and drop should not be affected by my change at all.

Actually you can still drag and drop morphs like before (even openInHand and dropping it afterwards).

What I intented to change was the drop behavior for the mechanism for opening a morph for an object dropped in the world (basically PasteUpMorph>>transferMorphConverter:).

For example, my method checks whether the dropped object is a Model and if so tries to open it with ToolBuilder.

The drag starts in PluggableTreeMorph>>#startDrag: to answer your initial question.

Bests

Patrick

On 3/23/17 11:43 AM, Rein, Patrick wrote:

Well before the change, the morph would have opened anywhere in the world. Most of the time that was not close to the hand.

You are right though, that the new behavior look weird too... Maybe this is because it looks good for dragging menu items?
From: Squeak-dev [hidden email] on behalf of Bob Arning [hidden email]
Sent: Thursday, March 23, 2017 16:36
To: [hidden email]
Subject: Re: [squeak-dev] The Inbox: Morphic-pre.1329.mcz
I guess one question is why the bowl was attached to the hand at the lower left corner of the bowl rather than the upper left. If it had been attached at the upper left, then it probably would have dropped right where expected.

On 3/23/17 11:13 AM, Rein, Patrick wrote:
This allows for more "intuitive" drag and drop behavior. When I drop something into the world and a morph is opened for it than the morph is displayed at the position where the element was dropped. For a simple example so the gif attached.

dropModel.gif (206K) Download Attachment

Bob Arning-2

Re: The Inbox: Morphic-pre.1329.mcz

You are right about it looking good for menu items. TransferMorph specifically aligns its bottomLeft with the hand, thus keeping the text fully readable.

aboutToBeGrabbedBy: aHand
    "The receiver is being grabbed by a hand.
    Perform necessary adjustments (if any) and return the actual morph
         that should be added to the hand."
    "Since this morph has been initialized automatically with bounds origin
         0@0, we have to move it to aHand position."
    super aboutToBeGrabbedBy: aHand.

    self align: self fullBounds bottomLeft with: aHand position.
    aHand newKeyboardFocus: self.

The above could be changed to #topLeft and perhaps achieve the effect you wanted, although maybe less nicely for menu/list items. I was thinking that since TransferMorph was making things a bit difficult, maybe TransferMorph could clean things up. Have you installed a transferMorphConverter in the World? What does it do? Maybe that's the place to handle the offset.

morphToDropForTransferMorph: aTransferMorph
    "aTransferMorph has been dragged directly onto the desktop. TransferMorphs, by nature, are about transferring a 'logical object' from another source. Answer the Morph that should actually be dropped on to the desktop."
    ^ self
        perform: self transferMorphConverter
        with: aTransferMorph

On 3/24/17 4:51 AM, Rein, Patrick wrote:

I just also made a small gif to show the usual use case of dropping an object in the world which is not a morph yet.
From: Squeak-dev [hidden email] on behalf of Rein, Patrick
Sent: Friday, March 24, 2017 09:39
To: The general-purpose Squeak developers list
Subject: Re: [squeak-dev] The Inbox: Morphic-pre.1329.mcz
Hi Bob,

I think I see now what I missed out in my explanation. Ordinary morph drag and drop should not be affected by my change at all.

Actually you can still drag and drop morphs like before (even openInHand and dropping it afterwards).

What I intented to change was the drop behavior for the mechanism for opening a morph for an object dropped in the world (basically PasteUpMorph>>transferMorphConverter:).

For example, my method checks whether the dropped object is a Model and if so tries to open it with ToolBuilder.

The drag starts in PluggableTreeMorph>>#startDrag: to answer your initial question.

Bests

Patrick
From: Squeak-dev [hidden email] on behalf of Bob Arning [hidden email]
Sent: Thursday, March 23, 2017 18:15
To: [hidden email]
Subject: Re: [squeak-dev] The Inbox: Morphic-pre.1329.mcz
The real question is how the morph got attached to the hand in the first place. People have been picking morphs up and dropping them for decades, so there is something new here. Do you have the code that put the bowl into the hand?

On 3/23/17 11:43 AM, Rein, Patrick wrote:
Well before the change, the morph would have opened anywhere in the world. Most of the time that was not close to the hand.

You are right though, that the new behavior look weird too... Maybe this is because it looks good for dragging menu items?
From: Squeak-dev [hidden email] on behalf of Bob Arning [hidden email]
Sent: Thursday, March 23, 2017 16:36
To: [hidden email]
Subject: Re: [squeak-dev] The Inbox: Morphic-pre.1329.mcz
I guess one question is why the bowl was attached to the hand at the lower left corner of the bowl rather than the upper left. If it had been attached at the upper left, then it probably would have dropped right where expected.

On 3/23/17 11:13 AM, Rein, Patrick wrote:
This allows for more "intuitive" drag and drop behavior. When I drop something into the world and a morph is opened for it than the morph is displayed at the position where the element was dropped. For a simple example so the gif attached.