On Friday, June 29, 2001, at 11:16 AM, Marcel Weiher wrote:

> On Thursday, June 28, 2001, at 07:24  Uhr, Doug Way wrote:
>
>> So, to get the VM I downloaded and untarred Squeak3.0.1-MacOSX-
>> VM.tar.gz, and it contained all the sources, but I just wanted the 
>> compiled VM so I then untarred the Frameworks subpackage as per the 
>> Readme instructions.
>
> Is it a problem that it includes source?

Not really.  I assume at some point we'd want to package a non-sources 
version (like the pre-built VM-only packages for other platforms), but 
maybe it's a bit early for that.

>> I then realized I probably needed to move the Squeak.framework file 
>> into the framework search path, which the Readme mentions.
>
> Both Squeak.framework and SqueakAppKit.framework.

Sorry, this was my problem... not sure how I missed this.  Once I moved 
SqueakAppKit.framework over, double-clicking the VM worked, and I could 
open the .image file from within CocoaSqueak.

The feel of CocoaSqueak is slower than running Squeak in the classic 
environment, but the benchmarks are about the same between the two, so I 
guess the display updating or events must be a bit slower at this 
point?  Otherwise, it seemed to work pretty well... I didn't run into 
any crashes (except for the known quit-from-world-menu problem).

Thanks for the detailed explanation on Cocoa frameworks.  Probably at 
some point it'd be good to have a combined/binary-only distribution, but 
it's obviously good to have the framework-based distribution as well.

- Doug Way
   dway at riskmetrics.com


>
>>  I tried moving it to the suggested directories (I had to create them 
>> both),
>
> Yes, sadly, the default OS-X install doesn't create those.
>
>>  but I'm not sure if they were actually in my framework search path.
>
> Either
>
> /Library/Frameworks/Squeak.framework
> /Library/Frameworks/SqueakAppKit.framework
>
> or
>
> ~/Library/Frameworks/Squeak.framework
> ~/Library/Frameworks/SqueakAppKit.framework
>
> should work.
>
>
>>   (I checked my environment variables but didn't see one which looked 
>> like the right one.  Yes, I am a Cocoa newbie, but I'm familiar with 
>> Unix.)
>
> The framework search path is not encoded in environment variables.
>
>>  Double-clicking the VM still didn't work.
>
> That should have done the trick.
>
>> Anyway, do all Cocoa apps need a separate .framework file?
>
> Yes and no.
>
> Frameworks are the 'default' method for bundling functionality (code / 
> shared libraries) in MacOS-X.  Look at /System/Library/Frameworks and 
> /System/Library/PrivateFrameworks/, almost all the higher level 
> functionality in MacOS-X is there.   They differ from shared libraries 
> in that they can contain both code and non-code resources, including 
> documentation, headers, data-files, user-interface elements, squeak 
> images/projects, whatever and also have a versioning mechanism so 
> multiple version of frameworks can exist at the same time and be used 
> by different applications.
>
> Since just about all applications on MacOS-X require at least some of 
> these frameworks, and Cocoa itself comes as (several) frameworks all 
> Cocoa applications do, in fact, 'require' separate framework 'files', 
> just like programs on other platforms usually require (system) shared 
> libraries.
>
> Not all Cocoa programs bring their own framework files, however.  Some 
> programs simply aren't themselves modular, all the relevant code is 
> heaped into one single executable (apart from references to system 
> libraries).  However larger pieces of software tend to also have code 
> that is split into individual frameworks (shared libraries), just like 
> the system code.  I consider this (i.e. system-supported modularity) a 
> Good Thing.  As a matter of fact, absence of this or a comparable 
> mechanism is one of the biggest problems I have with Squeak at this 
> time.  It's a bit like dynamic messaging:  difficult to do without once 
> you've become used to it.
>
> When functionality is packaged as frameworks it ceases to be private to 
> your particular application but instead becomes available for others as 
> well.  For example, OmniWeb makes virtually all of the functionality of 
> a web-browser available as separate frameworks.  Mail.app references a 
> Message.framework for mail-delivery that is also available to other 
> applications, ScreenSaver functionality is available as a framework, 
> etc.
>
> Apart from the utilitarian effect, this sort of packaging also has a 
> positive (and difficult to describe) effect on the code you write, 
> well, at least on the code I write.  Together with Objective-C 
> categories (which allow you to add methods to pre-existing classes), 
> you can really split your code into small, self contained units that do 
> one thing, and only one thing, well.  Applications then usually become 
> a matter of a little glue to tie several frameworks together, possiby 
> with some UI, but maybe also without.  That is why CocoaSqueak.app is 
> only 60K, it really just ties together Squeak.framework (base 
> interpreter and faceless I/O),  SqueakAppKit.framework  (GUI, 
> interaction, media) and Cocoa's application-support.
>
> This opens up a whole range of possibilities.  For example, you can 
> very easily build your own Squeak-based Cocoa-applications, using a 
> custom icon, custom code etc. but sharing all the common Squeak VM 
> stuff via the framework.  The framework could also be a centralized 
> repository for other shared Squeak resources, such as the sources file 
> or even one or several 'standard' image files.  Squeak-Cocoa apps could 
> then consist of the small binary (as you noted about 60K), some custom 
> native classes or plugins and maybe a project file.
>
> A Squeak Shell  ( sqsh? ) could benefit from the same mechanism, with a 
> small executable linking in the framework and thus being able to 
> execute with a standard image.  Of course, the usability of this 
> depends on being able to load the 'standard' image file quickly.  
> CocoaSqueak already maps the image-file into memory, so once its there 
> loading time is negligible with Mach's very lazy virtual memory 
> subsystem, and Andreas hinted that we might soon be able to do without 
> going through the image each time on load if we manage to get the same 
> VM address.
>
> However, as you note, the problem with this approach is that it makes 
> installation more difficult, requiring detailed instructions or an 
> installer program.  (I figured that the average Squeak user at this 
> point is savvy enough to deal with it...).  Anyway, MacOS-X also 
> provides a mechanism for placing an application's frameworks inside the 
> application wrapper (applications and frameworks are both kinds of 
> 'Bundles', a specific directory structure for packing executable code 
> and resources).   Of course, this hides the frameworks again, making 
> them, once again, unavailable for others.   Also, this packaging method 
> requires some voodoo that isn't entirely well supported by Apple's 
> development tools at this point, which is why I haven't gotten around 
> to it yet.
>
> However, creating a combined (and possibly binary-only) CocoaSqueak 
> package is something that is on the list of things to do, but hasn't 
> gotten done (along with lots of other things) because I've had a few 
> other things on the table recently.  What would then be great is a 
> mechanism for making those frameworks sharable as well.
>
> I hope this answers you question.
>
> Marcel
>