Smalltalk › Squeak › Squeak - Dev

Dropping a morph gives me a funny menu

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

11 messages Options

cbc

Dropping a morph gives me a funny menu

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:

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

-cbc

Hannes Hirzel

Re: Dropping a morph gives me a funny menu

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
>

Hannes Hirzel

Re: Dropping a morph gives me a funny menu

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

Edgar De Cleene

Re: Dropping a morph gives me a funny menu

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
>

Hannes Hirzel

Re: Dropping a morph gives me a funny menu

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

Hannes Hirzel

Re: Dropping a morph gives me a funny menu

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

Edgar De Cleene

Re: Dropping a morph gives me a funny menu

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:

Tobias Pape

Re: Dropping a morph gives me a funny menu

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

Edgar De Cleene

Re: Dropping a morph gives me a funny menu

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

Hannes Hirzel

Re: Dropping a morph gives me a funny menu

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

Hannes Hirzel

Re: Dropping a morph gives me a funny menu

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