The more I think about the more I think you are right..... Who said we are not learning every day.

I will try to find some times to fix that but I cannot get my hand on a recent updates image (connection too slow here). So if you or somebody else wants to fix that I will review it.

Stef On Monday, July 7, 2003, at 11:15 AM, Ingo Hohmann wrote:

Hi Stephane,

creating 'throw away' objects seems very strange to me.

I guess what _I_ would like most from a usage point of view would be to have class side methods, so that it wouldn't look so much different from the usage of the Smalltalk variable ... (of course that's just me newbie ;-)

But having SystemNavigation default, and it being documented, would work, for me, too.

Stephane Ducasse wrote:

...

Hi ingo for now SystemNavigation new works.

That's what I did, but with the feeling "Oh well, it works, I will find out how to do it right later"

...

To check why browse the class SystemNavigation, clcik on the class button and look on the instance creation protocol.

Now a deeper answer, this is true that I'm not really satisfied to have to create an instance all the time, so I do not know what the other think but turning SystemNavigation into a singleton for now could be good. SystemNavigation default could work well

Ingo

On Wednesday 16 July 2003 02:46 pm, Yoshiki.Ohshima@acm.org wrote:

Hello,

I'm playing around 3.6b-5331 (updated from 3.6a-5325). The first thing I noticed is there are quite a few unimplemented messages. If you call 'Smalltalk browseAllUnimplementedCalls', there are 161 unimplemented calls. It looks like most of them have explaination: some are primitives, which is ok, but some are in removed packages, which isn't great. But isn't it be nice if there are a lot of few such methods.

That should be

SystemNavigation new browseAllUnimplementedCalls

(see below)

There are a few more unimplemented call cases that can't be check with the unimplemented check mechanism. FileList>>openMorphFromFile should is 'called' from FileList>>fullFileListMenu:shifted: but is not there anymore. What happened to #openMorphFromFile? (I admit that I don't follow all of the email traffic...)

It seems to have gone away.

Actually, the only callers of it should have been replaced when the registering file list was done. Unfortunately, you still see those entries in some cases.

We still can do this, it's just that those hard-coded lists need to go away.

The convention was supposed to be that the classes that registered file list services should see a suffix of '*' as a flag to add all of their services that might be appropriate in the "all services" list. I notice that not all of them do that; I'll fix this.

FileList itemsForFile: 'fred.morph' => an OrderedCollection( Service: (ProjectViewMorph --- openFromDirectoryAndFileName: Service: (Morph --- fromFileName: Service: (ArchiveViewer --- addFileToNewZip: Service: (GZipWriteStream --- compressFile:)

So Morph>>fromFileName: is called ordinarily from the file list.

Once the corrections are made to the various methods, you get the equivalent of the following (31 items) for

FileList itemsForFile: 'a.*'

'open in midi player' ScorePlayerMorph #playMidiFile: 'load as project' ProjectViewMorph #openFromDirectoryAndFileName: 'open as movie' MoviePlayerMorph #openAsMovie: 'open for playback' EventRecorderMorph #openTapeFromFile: 'load as book' BookMorph #openFromFile: 'load as morph' Morph #fromFileName: 'read graphic into ImageImports' Form #importImage: 'open graphic in a window' Form #openImageInWindow: 'use graphic as background' Form #openAsBackground: 'open as Flash' FlashMorphReader #openAsFlash: 'remove line feeds' FileStream #removeLineFeeds: 'fileIn entire file' FileStream #fileIn: 'code-file browser' FileContentsBrowser #browseFile: 'changelist browser' ChangeList #browseChangesFile: 'recent changes in file' ChangeList #browseRecentLogOnPath: 'changelist browser' ChangeList #browseCompressedChangesFile: 'install into new change set' ChangeSorter #fileIntoNewChangeSet: 'fileIn entire file' GZipReadStream #fileIn: 'install into new change set' GZipReadStream #fileIntoNewChangeSet: 'view decompressed' GZipReadStream #viewContents: 'decompress to file' GZipReadStream #saveContents: 'load Genie Gesture Dictionary' CRRecognizer #loadCRDictionary: 'load Genie Display Properties' CRRecognizer #loadCRDisplayProperties: 'add file to new zip' ArchiveViewer #addFileToNewZip: 'open in zip viewer' ArchiveViewer #openOn: 'extract all to...' ArchiveViewer #extractAllFrom: 'open true type font' TTFontReader #openTTFFile: 'play in MPEG player' MPEGMoviePlayerMorph #playFile: 'compress file' GZipWriteStream #compressFile: 'install SAR' SARInstaller #installSAR: 'install ttf style' TTCFont #newTextStyleFromTTFile:

Which should replace the hard-coded list in #fullFileListMenu:shifted:.

Similar logic can be used to get rid of the other hard-coded lists.

And, The deprecated method notice says 'Use SystemNavigation>>browseUnimplementedCalls'. However, how can I use this exactly? This is an instance method of SystemNavigation, and I saw some discussion about adding #default instance creation method to the class side, but there is no such method.

And since #systemNavigation is not implemented in SystemNavigation itself,

SystemNavigation new browseUnimplementedCalls

or such fails. Probably, we should implement #systemNavigation in SystemNavigation?

Fixed in 5338. The latest is 5352.

You can do:

Smalltalk systemNavigation ...

or

Utilities systemNavigation ...

On Wednesday 16 July 2003 05:52 pm, Yoshiki.Ohshima@acm.org wrote:

Thank you, Ned,

I updated up to 5352 and,

...

That should be

SystemNavigation new browseAllUnimplementedCalls

Ok, now it works.

...

Actually, the only callers of it should have been replaced when the registering file list was done. Unfortunately, you still see those entries in some cases.

Are we getting it back?

I don't know. Do we need it?

...

So Morph>>fromFileName: is called ordinarily from the file list.

Ok. This is the method I need to update m17n work, then^^;

By the way, now there is a class called Imports and Imports>>images returns an Array. However, SystemDictionary>>imageImports used to return a Dictionary. In the other words, the interface is not compatible. Is this... Intentional? (Well, I guess)

No,

Imports default imports

should be that same dictionary.

This restores access to the imports dictionary, needed by at least one package.

< I'm a bug-fixing machine! >

This post brought to you by the BugFixArchiveViewer, a handy tool that makes it easy to comment on proposed fixes and enhancements for Squeak. For more information, check out the Web page for the BugFixArchiveViewer project: http://minnow.cc.gatech.edu/squeak/3214

< I'm a bug-fixing machine! >

Hi

By the way, now there is a class called Imports and Imports>>images returns an Array. However, SystemDictionary>>imageImports used to return a Dictionary. In the other words, the interface is not compatible. Is this... Intentional? (Well, I guess) Anyway, m17n thing trys to pickup a image based on the key of the imports dictionary, so it would be nice if we have a way to do so other than #namesAndImagesDo:

Please changes what you need in Imports. As I did not have any client at that time I thought to let it simple and wait until clients showed up. So fix, adapt to what you need and I will review it and push so that your changes goes into the image to populate Imports.

Stef