Problems with a Morph that accepts File Dropping in Pharo 1.3+

Hi,
i still have problems with a Morph that should accept files from the OS dragged and dropped onto it.
I found out it works in Pharo 1.2 and in Squeak 4.3 but not in Pharo 1.3 and 1.4. Try this class:

Morph subclass: #DropZone
        instanceVariableNames: ''
        classVariableNames: ''
        poolDictionaries: ''
        category: 'DragAndDrop'!

!DropZone methodsFor: 'as yet unclassified' stamp: 'HeleneBilbo 9/21/2012 20:53'!
dropFiles: evt
        self color: Color blue.! !

!DropZone methodsFor: 'as yet unclassified' stamp: 'HeleneBilbo 9/21/2012 20:41'!
initialize
        super initialize.
        color := Color red.
        bounds := 0 @ 0 extent: 200 @ 200! !

!DropZone methodsFor: 'as yet unclassified' stamp: 'HeleneBilbo 9/21/2012 20:53'!
wantsDropFiles: anEvent
        ^ true! !

In Pharo 1.3 and 1.4 the DropZone Morph does only in some rare cases catch the dropped file, in most cases it's the PastUpMorph behind, that get's to handle the dropped file. In Pharo 1.2 and in Squeak (4.3) it works as it should, i.e. the DropZone always get's to handle the file dropped onto it.

Perhaps someone has an idea what changed between 1.2 and 1.3 that could cause this behavior?

Best regards, Helene.

helene can you send the cs file?

On Sep 21, 2012, at 10:26 PM, Helene Bilbo wrote:

Stéphane Ducasse wrote

helene can you send the cs file?

I send it as attachment.

Just open an instance of DropZone in the world and start dropping files onto it.

In 1.2 and in Squeak it works well, in 1.3 and 1.4 it sometimes works, when you make the morph really big, but it doesn't work or seldom works with smaller Morphs. I could not find where the problem lies.

helene.
DragAndDrop.st

which kind of files are you dropping because dropping a .st file does the same on 2.0 and 1.2

stef

On Sep 22, 2012, at 7:01 PM, Helene Bilbo wrote:

Stéphane Ducasse wrote

which kind of files are you dropping because dropping a .st file does the same on 2.0 and 1.2

Yes, that's the problem. It's PasteUpMorph that handles all the dropped files. I want to make a custom Morph, DropZone, that handles dropped files. Of course i could alter PasteUpMorph, but there is a functionality that worked in 1.2 and works in Squeak, that ceased to work in 1.3+, that allowed to make morphs that handle dropped files.

Background: I made an application for the psychology department of a university that parses Tobii eyetracker files (with PetitParser, which works AMAZINGLY WELL!) and does all sorts of calculations with them. I want to provide a nice interface, that allows users to drop the eyetracker files on a Pharo window to start the file processing.

> Stéphane Ducasse wrote
>> which kind of files are you dropping because dropping a .st file does the
>> same on 2.0 and 1.2
>
> Yes, that's the problem. It's PasteUpMorph that handles all the dropped
> files. I want to make a custom Morph, DropZone, that handles dropped files.
> Of course i could alter PasteUpMorph, but there is a functionality that
> worked in 1.2 and works in Squeak, that ceased to work in 1.3+, that allowed
> to make morphs that handle dropped files.

Do you have a scenario that works in 1.2 because I got exactly the same behavior
with 1.2 and 2.0?
When I drop a txt file I get a workspace in both version.
When do you get your halt open.


in 1.2 I put an halt into
Morph>>handleDropFiles: anEvent
        "Handle a drop from the OS."
        self halt.
        anEvent wasHandled ifTrue:[^self]. "not interested"
        (self wantsDropFiles: anEvent) ifFalse:[^self].
        anEvent wasHandled: true.
        self dropFiles: anEvent.

I tried the same on 2.0 and this is in both cases the PasteUpMorph that get it. So.



ok in 1.1-11411
I got your halt. :)

MorphicEventDispatcher>>dispatchDefault: anEvent with: aMorph
        "Dispatch the given event. The event will be passed to the front-most visible submorph that contains the position wrt. to the event."
        | localEvt index child morphs inside |
        "See if we're fully outside aMorphs bounds"
        (aMorph fullBounds containsPoint: anEvent position) ifFalse:[^#rejected]. "outside"
        "Traverse children"
        index := 1.
        morphs := aMorph submorphs.
        inside := false.
        [index <= morphs size] whileTrue:[
                child := morphs at: index.
                localEvt := anEvent transformedBy: (child transformedFrom: aMorph).
                (child processEvent: localEvt using: self) == #rejected ifFalse:[
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


                        "Not rejected. The event was in some submorph of the receiver"
                        inside := true.
                        localEvt wasHandled ifTrue:[anEvent copyHandlerState: localEvt].
                        index := morphs size. "break"
                ].
                index := index + 1.
        ].

        "Check for being inside the receiver"
        inside ifFalse:[inside := aMorph containsPoint: anEvent position event: anEvent].
        inside ifTrue:[^aMorph handleEvent: anEvent].
        ^#rejected




> Background: I made an application for the psychology department of a
> university that parses Tobii eyetracker files (with PetitParser, which works
> AMAZINGLY WELL!) and does all sorts of calculations with them. I want to
> provide a nice interface, that allows users to drop the eyetracker files on
> a Pharo window to start the file processing.


>
>
>
> --
> View this message in context: http://forum.world.st/Problems-with-a-Morph-that-accepts-File-Dropping-in-Pharo-1-3-tp4648385p4648540.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>

Stéphane Ducasse wrote

I tried the same on 2.0 and this is in both cases the PasteUpMorph that get it. So.

ok in 1.1-11411
I got your halt. :)

So, you found my problem :)

Any idea, what i can do about it?

It is a pity (and a bug - as when you make the custom DropZone morph bigger, some parts of it handle the dropped file, while some other parts of it, pass it on to the PasteUpMorph) that it does no longer work this way, and i could not find any reason for it..

I will try to have a look.
Now putting a halt in such method can block everything :)

Stef

On Sep 23, 2012, at 4:35 PM, Helene Bilbo wrote:

On Sep 23, 2012, at 4:35 PM, Helene Bilbo wrote:

> Stéphane Ducasse wrote
>> I tried the same on 2.0 and this is in both cases the PasteUpMorph that
>> get it. So.
>>
>> ok in 1.1-11411
>> I got your halt. :)
>
> So, you found my problem :)

not really
so far the code is the same.
        dispatchDefault: anEvent with: aMorph


Now this method is used continuously. I put an halt inside to get a debugger when the drop event is managed

dispatchDefault: anEvent with: aMorph
        "Dispatch the given event. The event will be passed to the front-most visible submorph that contains the position wrt. to the event."
        | localEvt index child morphs inside |
       
       
        "See if we're fully outside aMorphs bounds"
        (aMorph fullBounds containsPoint: anEvent position) ifFalse:[^#rejected]. "outside"
        "Traverse children"
        index := 1.
        morphs := aMorph submorphs.
        inside := false.
        [index <= morphs size] whileTrue:[
                child := morphs at: index.
                localEvt := anEvent transformedBy: (child transformedFrom: aMorph).
                (child processEvent: localEvt using: self) == #rejected ifFalse:[
                        "Not rejected. The event was in some submorph of the receiver"
                        inside := true.
                        localEvt wasHandled ifTrue:[anEvent copyHandlerState: localEvt].
                        index := morphs size. "break"
                ].
                index := index + 1.
        ].

        "Check for being inside the receiver"
        anEvent class = DropFilesEvent ifTrue: [self halt.].
        inside ifFalse:[inside := aMorph containsPoint: anEvent position event: anEvent].
        inside ifTrue:[^aMorph handleEvent: anEvent].
        ^#rejected






Now in Pharo 2.0

dispatchEvent: anEvent with: aMorph
        "Dispatch the given event for a morph that has chosen the receiver to dispatch its events. The method implements a shortcut for repeated dispatches of events using the same dispatcher."
        anEvent type == lastType ifTrue:[^self perform: lastDispatch with: anEvent with: aMorph].
        "Otherwise classify"
        lastType := anEvent type.
        anEvent isMouse ifTrue:[
                anEvent isMouseDown ifTrue:[
                        lastDispatch := #dispatchMouseDown:with:.
                        ^self dispatchMouseDown: anEvent with: aMorph]].
        anEvent type == #dropEvent ifTrue:[
                lastDispatch := #dispatchDropEvent:with:.
                ^self dispatchDropEvent: anEvent with: aMorph].
        anEvent isWindowEvent ifTrue:[
                lastDispatch := #dispatchWindowEvent:with:.
                ^self dispatchWindowEvent: anEvent with: aMorph].
        lastDispatch := #dispatchDefault:with:.
        ^self dispatchDefault: anEvent with: aMorph

the last line is executed
while in 1.1

dispatchEvent: anEvent with: aMorph
        "Dispatch the given event for a morph that has chosen the receiver to dispatch its events. The method implements a shortcut for repeated dispatches of events using the same dispatcher."
        anEvent type == lastType ifTrue:[^self perform: lastDispatch with: anEvent with: aMorph].
                                                                it stopped in this branch.
        "Otherwise classify"
        lastType := anEvent type.
        anEvent isMouse ifTrue:[
                anEvent isMouseDown ifTrue:[
                        lastDispatch := #dispatchMouseDown:with:.
                        ^self dispatchMouseDown: anEvent with: aMorph]].
        anEvent type == #dropEvent ifTrue:[
                lastDispatch := #dispatchDropEvent:with:.
                ^self dispatchDropEvent: anEvent with: aMorph].
        anEvent isWindowEvent ifTrue:[
                lastDispatch := #dispatchWindowEvent:with:.
                ^self dispatchWindowEvent: anEvent with: aMorph].
        lastDispatch := #dispatchDefault:with:.
        ^self dispatchDefault: anEvent with: aMorph

but this is the same :)

Slowly debugging step by step the process it seems that the

        (aMorph fullBounds containsPoint: anEvent position) ifFalse:[^#rejected]. "outside"

pass in the false path in 20 and true path in 1.1


May be
        localEvt := anEvent transformedBy: (child transformedFrom: aMorph).

the transformation changed the position.

Stef

What is really strange is that the event location is always too large.
I put the dropZone on 0@0 - 200@200 and I drop a file on it and the event location is 15@800….
I traced that up to HandMorph…processEvents
and this is event in the evtBuf of the vm.

Stef


dispatchDefault: anEvent with: aMorph
        "Dispatch the given event. The event will be passed to the front-most visible submorph that contains the position wrt. to the event."
        | localEvt index child morphs inside |
        "See if we're fully outside aMorphs bounds"
        (anEvent class = DropFilesEvent ) and: [(aMorph class = DropZone) ifTrue: [self halt]].
        (aMorph fullBounds containsPoint: anEvent position) ifFalse:[^#rejected]. "outside"
        "Traverse children"
        index := 1.
        morphs := aMorph submorphs.
        inside := false.
        [index <= morphs size] whileTrue:[
                child := morphs at: index.
                localEvt := anEvent transformedBy: (child transformedFrom: aMorph).
                (child processEvent: localEvt using: self) == #rejected ifFalse:[
                        "Not rejected. The event was in some submorph of the receiver"
                        inside := true.
                        localEvt wasHandled ifTrue:[anEvent copyHandlerState: localEvt].
                        index := morphs size. "break"
                ].
                index := index + 1.
        ].

        "Check for being inside the receiver"
        inside ifFalse:[inside := aMorph containsPoint: anEvent position event: anEvent].
        inside ifTrue:[^aMorph handleEvent: anEvent].
        ^#rejected

Thanks for investigating my issue - and for documenting how you did so! That's interesting to read. I would not have found the right way to modify and halt the dispatchDefault: anEvent with: aMorph method myself..
Something like this would be a nice screencast for beginners on PharoCasts.
helene.

Stéphane Ducasse wrote

What is really strange is that the event location is always too large.
I put the dropZone on 0@0 - 200@200 and I drop a file on it and the event location is 15@800….
I traced that up to HandMorph…processEvents
and this is event in the evtBuf of the vm.

Stef


dispatchDefault: anEvent with: aMorph
        "Dispatch the given event. The event will be passed to the front-most visible submorph that contains the position wrt. to the event."
        | localEvt index child morphs inside |
        "See if we're fully outside aMorphs bounds"
        (anEvent class = DropFilesEvent ) and: [(aMorph class = DropZone) ifTrue: [self halt]].
        (aMorph fullBounds containsPoint: anEvent position) ifFalse:[^#rejected]. "outside"
        "Traverse children"
        index := 1.
        morphs := aMorph submorphs.
        inside := false.
        [index <= morphs size] whileTrue:[
                child := morphs at: index.
                localEvt := anEvent transformedBy: (child transformedFrom: aMorph).
                (child processEvent: localEvt using: self) == #rejected ifFalse:[
                        "Not rejected. The event was in some submorph of the receiver"
                        inside := true.
                        localEvt wasHandled ifTrue:[anEvent copyHandlerState: localEvt].
                        index := morphs size. "break"
                ].
                index := index + 1.
        ].

        "Check for being inside the receiver"
        inside ifFalse:[inside := aMorph containsPoint: anEvent position event: anEvent].
        inside ifTrue:[^aMorph handleEvent: anEvent].
        ^#rejected

Helene

two key things:
        - look for senders
        - put a halt there and check
        at worse you crash the system :)

Stef



On Sep 24, 2012, at 9:28 AM, Helene Bilbo wrote:

Hi helene

As I was thinking after investigating the problems, there was a bug in the VM. Esteban fixed it.
The point is that the mac event location was not converted to the right coordinate system.
Now this is fixed. Grab the most recent VM from the jenkins server and let us know.
Thanks for spotting the bug.

Stef

On 24 Sep 2012, at 19:55, Stéphane Ducasse <[hidden email]> wrote:

> Thanks for spotting the bug.

Yes indeed: people reporting bugs like that (with code, being knowledgeable and persistent) are really very helpful.

Thanks.


--
Sven Van Caekenberghe
http://stfx.eu
Smalltalk is the Red Pill

Stéphane Ducasse wrote

As I was thinking after investigating the problems, there was a bug in the VM. Esteban fixed it.
The point is that the mac event location was not converted to the right coordinate system.
Now this is fixed. Grab the most recent VM from the jenkins server and let us know.
Thanks for spotting the bug.

Thank you. I am waiting for the VM, at the moment there seems to be a new problem as the build failed: https://ci.lille.inria.fr/pharo/view/Cog/job/Cog-VM/
or i am just too impatient..

looks like Esteban's latest commit reverted some stuff. or else i dont
know what happens

On 24 September 2012 21:07, Helene Bilbo
<[hidden email]> wrote:


--
Best regards,
Igor Stasenko.

I souldn't... I merge blessed and mine, I think I didn't stepped on anything

On Sep 24, 2012, at 9:36 PM, Igor Stasenko <[hidden email]> wrote:

On 24 September 2012 22:03, Esteban Lorenzano <[hidden email]> wrote:
> I souldn't... I merge blessed and mine, I think I didn't stepped on anything
>
but current builds failed because of some out-of-sync in file plugin (again)..
it may be you using wrong VMMaker sources then.



--
Best regards,
Igor Stasenko.

Helene - and my thanks to you for your polite persistence - thanks as
a Pharo user devoting his time to issues on another dev platform - and
me, not by nature diplomatic ;-)

In only a few weeks I may be so grateful that file drops work in 1.4+
or a 2.0+ !!

Robert,
Atlantic Canada