I think that for people new to the system an Import class would be
easier than the existing system. I remember spending WAY too much time
trying to track down where the images lived.
I, personally, would rather have a single class "Imports" which is a
dictionary of dictionaries. So I can say:

image := ( Imports bundle: 'RussellsImports' ) at: 'MyImage'.
movie := ( Imports bundle: 'RussellsImports' ) at: 'MyMovie'.
font := ( Imports bundle: 'RussellsImports' ) at: 'MyFont' ifAbsent: [ (
Imports bundle: 'SystemDefaults' ) at: 'DefaultFont' ].

Where my particular bundle (or package or whatever it gets called) is
loaded by:

Imports loadBundle: 'RussellsImports' from: 'c:\russells_media\*.*'

The file names without extensions become the keys to my dictionary and
each recognised filetype gets instanced as the appropriate class.

The main thing is that Imports not be limited to images but to all media
types including Mpeg, MP3, wav, images, fonts, etc.

There would be system objects loaded in the base image and modules can
load their own bundle so they are not/less dependent on the minimal
image.

And for something like a headless system, just empty (most of) it to
save space!

Russell
-----Original Message-----
From: squeak-dev-bounces at lists.squeakfoundation.org
[mailto:squeak-dev-bounces at lists.squeakfoundation.org] On Behalf Of
Martin Wirblat
Sent: Wednesday, 14 May 2003 3:11 AM
To: Squeak
Subject: Re: SystemDictionary>>imageImports -> XXX>>imageImports

Hi Julian,
the specific method I had in mind is #imageImports. It is a method, 
but it is about data, it looks up images. I can't think of the 
existence of this method, without first thinking about this data. 

Classes and methods are nicely i.e. hierarchial ordered in Squeak. But 
if I want to see e.g. what icons are available, or what urls or texts 
the system knows, what pictures and sound it has, it turns out, that 
these non-code-objects are somewhat scattered around the system. They 
may be hardcoded as literals, they may be accessible via Smalltalk the 
SysDic. If there are now new classes introduced to take away this data 
from Smalltalk ( as I understand Stephane ) I fear the access to these 
objects gets even more dissipated. 

But I think you are right regarding that if one has this in mind, it 
should be possible to even structure these non-code-objects better 
than they are today. If this is done with more than one new class, 
these classes should belong together in some way, so that they make 
something whole. 

Regards, Martin

Julian Fitzell <julian at beta4.com> wrote on 13.05.2003 16:44:50:
>
>Martin Wirblat wrote:
>> Hi Stephane,
>> 
>> thank you for replying to me. I think I should have left out the 
>> middle part of my post regarding references to Smalltalk, I just 
>> thought that there has to be access to it, maybe it would be better 
>> to replace all hardwired refs to it with something like 'Smalltalk 
>> default' in order to prepare Squeak for multiple environments, 
>> maybe something else, I don't know. 
>> 
>> However, you don't convince me really on finding things in 
>> additional classes. 
>> 
>> 
>>>In Imports I have a better chance to find stuff related to imported 
>>>objects
>>>than to namespace whose the only responsibility should be dealing 
>>>with class names.
>> 
>> 
>> At first you have to find Imports. Probably you need some more 
>> dictionaries holding data, if you don't want to have this data in 
>> Smalltalk. Isn't this more complicated than to have one single 
>> place where to look for this? Wasn't Smalltalk meant to be the 
>> single place for this? 
>
>Hrm... well... I mean by that logic, by extension, why have classes 
>at all?  If we just put all the methods in one place then we'd know 
>where to find them all.  But it isn't very logically divided.  This 
>seems like unclean design, not to mention causing problems for 
>eSqueak, etc. 
> I don't think that what we have now is exactly the same problem, 
> just to a 
>lesser degree.
>
>I'd actually argue it makes it harder to find stuff because while you 
>know where to look it would take you hours to look through all the 
>methods.  And if you're working with a certain set of functionality 
>(ie a bunch of clases in the system) then presumably you will look 
>for any methods having to do with that functionality there.
>
>You don't mention specific methods and I assume that there is a small 
>subset of methods that should be on SystemDictionary.  But most of 
>the methods there, imo, belong on more appropriate classes.
>
>Julian