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