Dropping a morph gives me a funny menu

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
cbc
Reply | Threaded
Open this post in threaded view
|

Dropping a morph gives me a funny menu

cbc
In a fully up to date trunk image (windows/64bit, but I don't think that matters), if I drop a *.morph on the desktop, i get this funny dialog:
Inline image 1

The funny part is that it has 2 options for "load as morph".  One should be sufficient.

-cbc


Reply | Threaded
Open this post in threaded view
|

Re: Dropping a morph gives me a funny menu

Hannes Hirzel
Confirmed.

PasteUpMorph selectors select: [ :s | s asString includesSubstring: 'drop']

gives

     #(#dropFiles: #dropEnabled)


So a place to start to find out what happens is

PasteUpMorph>>
dropFiles: anEvent
        "Handle a number of dropped files from the OS.
        TODO:
                - use a more general mechanism for figuring out what to do with the
file (perhaps even offering a choice from a menu)
                - remember the resource location or (when in browser) even the
actual file handle
        "
        | numFiles |
        numFiles := anEvent contents.
        1 to: numFiles do: [ :i |
                (FileDirectory requestDropDirectory: i)
                        ifNotNil: [:directory | self handleDroppedItem: directory event: anEvent]
                        ifNil: [(FileStream requestDropStream: i) ifNotNil: [:stream |
                                [self handleDroppedItem: stream event: anEvent] ensure: [stream close]]]].
                               


--Hannes

On 3/24/17, Chris Cunningham <[hidden email]> wrote:
> In a fully up to date trunk image (windows/64bit, but I don't think that
> matters), if I drop a *.morph on the desktop, i get this funny dialog:
> [image: Inline image 1]
>
> The funny part is that it has 2 options for "load as morph".  One should be
> sufficient.
>
> -cbc
>

Reply | Threaded
Open this post in threaded view
|

Re: Dropping a morph gives me a funny menu

Hannes Hirzel
BTW with the same effort the 'save morph to file' menu entry could be
moved from the 'debug' menu to the 'export' menu.

That's a more natural place .....

--Hannes

On 3/24/17, H. Hirzel <[hidden email]> wrote:

> Confirmed.
>
> PasteUpMorph selectors select: [ :s | s asString includesSubstring: 'drop']
>
> gives
>
>      #(#dropFiles: #dropEnabled)
>
>
> So a place to start to find out what happens is
>
> PasteUpMorph>>
> dropFiles: anEvent
> "Handle a number of dropped files from the OS.
> TODO:
> - use a more general mechanism for figuring out what to do with the
> file (perhaps even offering a choice from a menu)
> - remember the resource location or (when in browser) even the
> actual file handle
> "
> | numFiles |
> numFiles := anEvent contents.
> 1 to: numFiles do: [ :i |
> (FileDirectory requestDropDirectory: i)
> ifNotNil: [:directory | self handleDroppedItem: directory event:
> anEvent]
> ifNil: [(FileStream requestDropStream: i) ifNotNil: [:stream |
> [self handleDroppedItem: stream event: anEvent] ensure: [stream
> close]]]].
>
>
>
> --Hannes
>
> On 3/24/17, Chris Cunningham <[hidden email]> wrote:
>> In a fully up to date trunk image (windows/64bit, but I don't think that
>> matters), if I drop a *.morph on the desktop, i get this funny dialog:
>> [image: Inline image 1]
>>
>> The funny part is that it has 2 options for "load as morph".  One should
>> be
>> sufficient.
>>
>> -cbc
>>
>



save_morph_to_file_2017-03-24.png (205K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Dropping a morph gives me a funny menu

Edgar J. De Cleene-3
In reply to this post by cbc
Is a very old, maybe from 4.1 and still in the .image.
The first time I see this also ask, maybe looking in the archives some response could help.

> On Mar 23, 2017, at 21:26, Chris Cunningham <[hidden email]> wrote:
>
> In a fully up to date trunk image (windows/64bit, but I don't think that matters), if I drop a *.morph on the desktop, i get this funny dialog:
> <image.png>
>
> The funny part is that it has 2 options for "load as morph".  One should be sufficient.
>
> -cbc
>


Reply | Threaded
Open this post in threaded view
|

Re: Dropping a morph gives me a funny menu

Hannes Hirzel
On 3/24/17, Edgar De Cleene <[hidden email]> wrote:
> Is a very old, maybe from 4.1 and still in the .image.
> The first time I see this also ask, maybe looking in the archives some
> response could help.

Let Smalltalk tell you what the problem is :-)

    ExternalDropHandler lookupExternalDropHandler: anItem

brings up the 'Choose' dialog box Chris posted ....




>> On Mar 23, 2017, at 21:26, Chris Cunningham <[hidden email]>
>> wrote:
>>
>> In a fully up to date trunk image (windows/64bit, but I don't think that
>> matters), if I drop a *.morph on the desktop, i get this funny dialog:
>> <image.png>
>>
>> The funny part is that it has 2 options for "load as morph".  One should
>> be sufficient.
>>
>> -cbc
>>
>
>
>



ExternalDropHandler_lookup.png (65K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Dropping a morph gives me a funny menu

Hannes Hirzel
On 3/24/17, H. Hirzel <[hidden email]> wrote:

> On 3/24/17, Edgar De Cleene <[hidden email]> wrote:
>> Is a very old, maybe from 4.1 and still in the .image.
>> The first time I see this also ask, maybe looking in the archives some
>> response could help.
>
> Let Smalltalk tell you what the problem is :-)
>
>     ExternalDropHandler lookupExternalDropHandler: anItem
>
> brings up the 'Choose' dialog box Chris posted ....
>
     #lookupExternalDropHandler:

calls

     #lookupServiceBasedHandler:


which calls

     #itemsForFile:


which answers a list of services.

     services explore

is attached.


--HH

>
>
>>> On Mar 23, 2017, at 21:26, Chris Cunningham <[hidden email]>
>>> wrote:
>>>
>>> In a fully up to date trunk image (windows/64bit, but I don't think that
>>> matters), if I drop a *.morph on the desktop, i get this funny dialog:
>>> <image.png>
>>>
>>> The funny part is that it has 2 options for "load as morph".  One should
>>> be sufficient.
>>>
>>> -cbc
>>>
>>
>>
>>
>



registeredFileReaderClasses_Screenshot_2017-03-25.png (243K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Dropping a morph gives me a funny menu

Edgar J. De Cleene-3
Following lead of Hannes, we found

an OrderedCollection(SimpleServiceEntry: (FileStream --- edit:) SimpleServiceEntry: (Morph --- fromFileName:) SimpleServiceEntry: (ProjectViewMorph --- openFromDirectoryAndFileName:) SimpleServiceEntry: (CornerGripMorph --- fromFileName:))

When ExternalDropHandler reduce the list of possible services.
I propose unregister Morph as provider and let ProjectViewMorph be the only class dealing with dropping Morphs in the World.


On Mar 25, 2017, at 04:44, H. Hirzel <[hidden email]> wrote:

#itemsForFile:



Reply | Threaded
Open this post in threaded view
|

Re: Dropping a morph gives me a funny menu

Tobias Pape

> On 25.03.2017, at 12:26, Edgar De Cleene <[hidden email]> wrote:
>
> Following lead of Hannes, we found
>
> an OrderedCollection(SimpleServiceEntry: (FileStream --- edit:) SimpleServiceEntry: (Morph --- fromFileName:) SimpleServiceEntry: (ProjectViewMorph --- openFromDirectoryAndFileName:) SimpleServiceEntry: (CornerGripMorph --- fromFileName:))
>
> When ExternalDropHandler reduce the list of possible services.
> I propose unregister Morph as provider and let ProjectViewMorph be the only class dealing with dropping Morphs in the World.
>
>

I think CornerGripMorph  is the one that should not do fromFileName:


>> On Mar 25, 2017, at 04:44, H. Hirzel <[hidden email]> wrote:
>>
>> #itemsForFile:
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Dropping a morph gives me a funny menu

Edgar J. De Cleene-3
You are right.
FileServices   unregisterFileReader: CornerGripMorph solves the issue and can’t see any use of having a CornerGripMorph outside of the .image

On Mar 25, 2017, at 08:31, Tobias Pape <[hidden email]> wrote:

CornerGripMorph



Reply | Threaded
Open this post in threaded view
|

Re: Dropping a morph gives me a funny menu

Hannes Hirzel
    FileServices allInstances size

gives

    0

only class methods.

There is

     FileServices initialize.

The #initialize method looks for classes which implement
#fileReaderServicesForFile:suffix: and asks them to register.


The list of classes which implement #fileReaderServicesForFile:suffix:
is given by


    (Smalltalk allClasses select: [:aClass|
                (aClass class includesSelector: #fileReaderServicesForFile:suffix:)])
         sorted: [:a :b | a name < b name]


It is

{AnimatedImageMorph . ArchiveViewer . BookMorph . ChangeList .
ChangeSet . DummyToolWorkingWithFileList . EventRecorderMorph .
FileContentsBrowser . FileDirectory . FilePackage . FileStream . Form
. GZipReadStream . GZipWriteStream . InternalTranslator .
MCVersionReader . MczInstaller . Morph . NaturalLanguageTranslator .
Object . Preferences . ProjectViewMorph . SARInstaller . ScorePlayer .
ScorePlayerMorph . TTCFont . TTFontReader}

in Squeak 5.1.
The CornerGripMorph is _not_ in this list.


So

    FileService initialize


should do the job.

It has as code

initialize
        "FileServices initialize"
       
        Smalltalk allClassesDo:[:aClass|
                (aClass class includesSelector: #fileReaderServicesForFile:suffix:)
                        ifTrue:[self registerFileReader: aClass]].


It does not do it. The double entry of 'Load as morph' still appears.

What #initialize needs to do it to reset the FileReaderRegistry class variable

        FileReaderRegistry := nil.


So the updated #initialize method should look like


initialize
        "FileServices initialize"
       
        FileReaderRegistry := nil.

        Smalltalk allClassesDo:[:aClass|
                (aClass class includesSelector: #fileReaderServicesForFile:suffix:)
                        ifTrue:[self registerFileReader: aClass]].


Then after

      FileServices initialize

the CornerGripMorph is no longer included.


Note: In  spite of this generic direct initialisation mechanism 10
#initialize methods on the class side directly reference FileServices.
And MczInstaller has #registerForFileList which references
FileServices.

So we would need to check if with this change

    FileReaderRegistry := nil.


we still get enough registrations. That is to check each class which
references FileServices.

On 3/25/17, Edgar De Cleene <[hidden email]> wrote:
> You are right.
> FileServices   unregisterFileReader: CornerGripMorph solves the issue and
> can’t see any use of having a CornerGripMorph outside of the .image
>
>> On Mar 25, 2017, at 08:31, Tobias Pape <[hidden email]> wrote:
>>
>> CornerGripMorph
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Dropping a morph gives me a funny menu

Hannes Hirzel
To summarize:

    FileServices   unregisterFileReader: CornerGripMorph

solves the issue.

The use case in detail

ExternalDropHandler>>handleDroppedItem:event:
http://wiki.squeak.org/squeak/4283

See also thread
'ExternalDropHandler chooseServiceFrom:'

--Hannes

On 3/25/17, H. Hirzel <[hidden email]> wrote:

>     FileServices allInstances size
>
> gives
>
>     0
>
> only class methods.
>
> There is
>
>      FileServices initialize.
>
> The #initialize method looks for classes which implement
> #fileReaderServicesForFile:suffix: and asks them to register.
>
>
> The list of classes which implement #fileReaderServicesForFile:suffix:
> is given by
>
>
>     (Smalltalk allClasses select: [:aClass|
> (aClass class includesSelector: #fileReaderServicesForFile:suffix:)])
>          sorted: [:a :b | a name < b name]
>
>
> It is
>
> {AnimatedImageMorph . ArchiveViewer . BookMorph . ChangeList .
> ChangeSet . DummyToolWorkingWithFileList . EventRecorderMorph .
> FileContentsBrowser . FileDirectory . FilePackage . FileStream . Form
> . GZipReadStream . GZipWriteStream . InternalTranslator .
> MCVersionReader . MczInstaller . Morph . NaturalLanguageTranslator .
> Object . Preferences . ProjectViewMorph . SARInstaller . ScorePlayer .
> ScorePlayerMorph . TTCFont . TTFontReader}
>
> in Squeak 5.1.
> The CornerGripMorph is _not_ in this list.
>
>
> So
>
>     FileService initialize
>
>
> should do the job.
>
> It has as code
>
> initialize
> "FileServices initialize"
>
> Smalltalk allClassesDo:[:aClass|
> (aClass class includesSelector: #fileReaderServicesForFile:suffix:)
> ifTrue:[self registerFileReader: aClass]].
>
>
> It does not do it. The double entry of 'Load as morph' still appears.
>
> What #initialize needs to do it to reset the FileReaderRegistry class
> variable
>
> FileReaderRegistry := nil.
>
>
> So the updated #initialize method should look like
>
>
> initialize
> "FileServices initialize"
>
> FileReaderRegistry := nil.
>
> Smalltalk allClassesDo:[:aClass|
> (aClass class includesSelector: #fileReaderServicesForFile:suffix:)
> ifTrue:[self registerFileReader: aClass]].
>
>
> Then after
>
>       FileServices initialize
>
> the CornerGripMorph is no longer included.
>
>
> Note: In  spite of this generic direct initialisation mechanism 10
> #initialize methods on the class side directly reference FileServices.
> And MczInstaller has #registerForFileList which references
> FileServices.
>
> So we would need to check if with this change
>
>     FileReaderRegistry := nil.
>
>
> we still get enough registrations. That is to check each class which
> references FileServices.
>
> On 3/25/17, Edgar De Cleene <[hidden email]> wrote:
>> You are right.
>> FileServices   unregisterFileReader: CornerGripMorph solves the issue and
>> can’t see any use of having a CornerGripMorph outside of the .image
>>
>>> On Mar 25, 2017, at 08:31, Tobias Pape <[hidden email]> wrote:
>>>
>>> CornerGripMorph
>>
>>
>