[MacPerl] droplets

[Bart Lateur <color@pophost.eunet.be>]

In the last two months, there have been (at least) two posts of people
having trouble with files that used to be droplets, but have been edited and
saved as text since then.

All this has to do with the fact that droplets store their script in a
resource, type "TEXT", ID 128 (or so), and name "!". These resources are not
destroyed when save a script as text on top of what used to be a droplet. So
the old "TEXT" resource is retained. What's worse: MacPerl seems to have a
preference to use this "TEXT" resource, over the text in the "normal" data fork.


I've experimented a little with droplets. I found out that with droplets,
the data fork is *empty*. This is where text files keep their text. So I can
see no good reason why this use of a "TEXT" resource. Just think along with me:

1) If droplets were to store their script in the data fork, the bugs like
the one this post started with, would simply vanish forever.

2) MacPerl's task would be a *little* simpler. MacPerl needn't check the
existence of a "TEXT" resource, before looking at the data fork.

3) You could edit droplets using BBedit.

4) I have noticed that if you have a little trouble with your files (a
little damage), the resource fork is easily damaged beyond repair. So now I
keep a backup copy of my droplets as a text file. If a few bytes are damaged
there, you'll still have a mostly readable file. So no need to keep
duplicates in two different formats any more.

5) Plain simpler to understand.


There are only futile arguments against this:

1) Maybe it's a little easier for an applet to ask the OS where it's
resources are, than to open it's own data fork (that is, in plain talk,
opening a file). But I seriously doubt it.

2) preventing casual users to open your script. But most editors will not
allow you to open a application file, either from a file dialog or by
dropping the file onto your editor icon. Even in BBedit, you have to check
"show all types" first. And ssecond, no casual user in his right mind would
even think about opening a file in an editor. Too afraid to damage anything,
rendering the application useless.

3) Privacy, hiding your details. But your script
  a) can be opened from within MacPerl
  b) the TEXT resource can be accessed with ResEdit. It is not scrambled.


On top of it all, I've tried something really daring. I have duplicated and
existing droplet, deleted it's TEXT resource with ResEdit, and opened it
with the BBedit text editor. I've typed in:

        print "Hello, world!";

and saved it.

Next, I started it up. Guess what happened? MacPerl opened a window, with a
nice little message for the entire world. Yes, it works!


So I would suggest to Matthias to change this "save as" thing in MacPerl, so
that it's script is saved in the data fork from now on.


>>>>>

Ok, that's the bulk of my post. Now as an aside, about this
&MacPerl::Quit(level) thing. In summary, you have the following possibilities:

 &MacPerl::Quit(LEVEL)
   If LEVEL is 0, don't quit after ending the script.
   If 1, quit if running under a runtime version, 
   if 2, always quit. 
   If LEVEL is 3, quit if this was the first script to be run since
starting MacPerl.

None of them gives the desired result if run from a droplet. My intuition
says: "quit if MacPerl was started up by this droplet". That is not
possible. LEVEL=3 comes closest, but if you open MacPerl, open a script in a
window without running it, and then start up a droplet containing this
"&MacPerl::Quit(3);" line, MacPerl will be terminated if it is executed.

What I guess that would be needed for a patch, is an internal flag that is
set if MacPerl is opened in a normal way. Maybe only if a code window is
opened. This should stop terminating MacPerl by a droplet this way. Of
course, if a droplet opens up MacPerl, this flag would *not* get set...


By for now,
Bart Lateur,
Gent (Belgium)

--- Embracing the KIS principle: Keep It Simple