Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cwjcc!tut.cis.ohio-state.edu!ucbvax!UIAMVS.BITNET!AWCTTYPA
From: AWCTTYPA@UIAMVS.BITNET ("David A. Lyons")
Newsgroups: comp.sys.apple
Subject: resources, etc. (GS)
Message-ID: <8902091735.aa03814@SMOKE.BRL.MIL>
Date: 9 Feb 89 23:02:31 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 74
X-Unparsable-Date: Thursday 09 Feb 89 3:54 PM CT

>Date:         Wed, 8 Feb 89 02:27:49 GMT
>From:         Sean Kamath

>Interresting, David.  Yes, the resource fork was designed for the Desktop
>interface, simply because of the immense complexity of it.  Without a
>resource fork, making menus, dialog boxes, etc., is a complete pain in the
>butt.

I dunno about a _complete_ pain in the butt; anybody who has written
a GS desktop-based application has done it.  I'm definitely looking
forward to being able to design them interactively and visually.

Dave:
>>Many kinds of resources can be edited interactively in an
>>application
Sean:
>all of which can lead to frighteningly strange desktops, where the whole
>idea of the "common" interface is chucked out the window. . .

Or it can lead to not-strange desktops:  so what?  A resource editor
doesn't have a concept of "strangeness"--it's just a tool you can
use however you want.  (Geez, you can take a magic marker and edit
your walls with it interactively, and you can come up with
frightenly strange walls if you want. :-)

>Keep in mind that you have to hard code resource numbers into the
>program.

Not necessarily:  you can hard-code resource _names_ into the program
if you prefer.  (I'm talking about actual string names, not just
CONSTs that stand for numbers or something.)

>Granted, a lot of the problem is with ResEdit, but sometimes it just
>the whole concept.  If I'm building an application with menu's, and I
>decide to add a menu item, say, to the beginning of a menu, then all
>the one's "down" it change their number, and I have to recompile
>after finding all occurences of the id number. [...]

Not on the GS:  menu items have their own ID numbers, so they don't
change when you rearrange your menus.

>>Since it's possible (on the Mac anyway) to have executable code in
>>resources, there are some really keen things you can do:  You can
>>let the user customize your program by adding code to it!
>
>I.e. add the virus *very* easy . . . :-(

That's true, unfortunately.  There are utilities for the Mac that
will warn you whenever a program attempts to modify certain kinds of
resources that most legitimate programs have no business fiddling
with.

>Let's not forget that the rest of the world doesn't have resources,
>and that such things as "mactar" only back up the data fork [...]

Sounds like a good reason not to use "mactar".

>[...] Ever read inside mac?  init that before you init this, but only
>after initing this, which will then allow that to . . ."  Yuk.

Yup, reads lots of that, & also lots of GS manuals that are similar.
GS tool startup order is dealt with pretty well in a Tech Note (which
is modified whenever releases more toolsets).

>Sean
>UUCP:  {decvax allegra ucbcad ucbvax hplabs}!tektronix!reed!kamath
>CSNET: reed!kamath@Tektronix.CSNET  ||  BITNET: kamath@reed.BITNET
>ARPA: kamath%reed.bitnet@cunyvm.cuny.edu
>US Snail: 3934 SE Boise, Portland, OR  97202-3126 (I hate 4 line .sigs!)

--David A. Lyons              bitnet: awcttypa@uiamvs
  DAL Systems                 CompuServe:  72177,3233
  P.O. Box 287                GEnie mail:    D.LYONS2
  North Liberty, IA 52317     AppleLinkPE: Dave Lyons