[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Mother ship App. A recent comment about distributing FASL files got me thinking.



> X400-Received: by /PRMD=inria/ADMD=atlas/C=FR/;
>         Relayed; 14 Jan 93 08:08:50+0100
> X400-Received: by /PRMD=CNET/ADMD=ATLAS/C=FR/;
>         Relayed; 14 Jan 93 08:05:00 GMT
> Date: 14 Jan 93 08:05:00 GMT
> From: Ranson <ranson@LANNION.cnet.fr>
> To: bhyde@gensym.com, info-mcl@cambridge.apple.com
> Subject: Re:  Mother ship App.  A recent comment about distributing FASL files got me thinking.
> 
> You can already do that. Making a single .fasl out of a MCL application is
> just a matter of using the fasl-concatenate function that is in a file some-
> where on the MCL CD. If you want to load a single appl, name the file init.fasl.
> If you want to be able to load several, it is easy to use init.fasl to load
> the files in a Inits folder. My init file does that, and I think it is on the
> CD.
> 
> There is another solution we could borrow from Frontier: applets. An applet
> would be a small application, with a .fasl file in its data fork. The appli-
> cation code itself has to be written in C or Pascal or whatever, but it needs
> to be written once, and then copied with ResEdit to all applets. All this
> mini-application does is launch MCL if necessary, and then ask it with an 
> AppleEvent to load the .fasl that is in its data fork. This way, MCL itself is
> a shared library. Though if you want to be able to run several applets, some
> protocol for sharing MCL resources and cleaning when done will be needed.

Sounds good. Making these Applets needs some documentation explaining
the  fasl-concatenate, how to add the applet resource [described above]
to a fasl file, and how to save the old menu bar and install a new one,
then reinstall the old one when you Quit the "applet". [I know this is
elsewhere in the documentation but its god to pull all this together.

It would also be nice to have some support for a user switching between 
applets while in one. This should be adding the applet to the
right hand menu bar menu of apps. Selecting it would switch to the
new menu bar [if any] and run some arbitrary user-defined fn
that 
1 puts the previous app to sleep and 
2 wakes up the new app. Some applets may have zero code in these fns, others
a lot.   To make this easy, the system might support tagging
each window with its owner applet. Then provide fns
hide-all-shown-windows-of-applet and 
show-all-shown-windows-of-applet.
I suppose a window could belong to > 1 applet as well as
"all-applets".

The documentation should have warnings and guidelines of how to make
applets that don't step on each other but its ok not to have more support
than that.