AWCTTYPA@UIAMVS.BITNET ("David A. Lyons") (02/04/89)
>Date: Wed, 1 Feb 89 22:50:26 GMT >From: Doug Gwyn <haven!adm!smoke!gwyn@AMES.ARC.NASA.GOV> > >In article <25074@apple.Apple.COM> keith@Apple.COM (Keith Rollin) writes: >[examples of using "resource forks"] > >But all those could just as easily have been achieved by using >ordinary data files. Why is a "split personality" file particularly >useful? Sure, everything you can do with resources could be achieved some other way, but it would _not_ be as easy. Advantages include: (1) the resource fork is _part of_ the file, meaning you don't have to remember to copy any data files along with your program & worry about keeping them in the same directory as the program. (2) the format of the resouce fork is not only standard, but it is managed completely by the resource manager so your program doesn't have to deal with it--it just asks for the resources that it wants when it wants them. (3) the formats of many specific types of resources are standard, meaning that you can use widely-available programs to edit your own program's standard resources _as well as_ other programs' standard resouces. (If you have a Mac and ResEdit, browse through the System file's resources and the Finder's resources sometime. Find a magazine article or something that tells you about "LAYO" resources you can customize in the Finder.) While programmers _could_ certainly provide users with the same level of customizability that resrouces provide, I assert that they usually don't. And without a _standard_ way of storing stuff like window/ menu/dialog/alert templates, the benefits of interactive interface-designing are mostly lost. If you have to write your _own_ interface editor, you might as well just hard-code all the rectangle coordinates into your program (writing the interface editor would take far too long unless you knew you would write a _lot_ of programs you could use it with). Anybody want to tell me how the NeXT's "interface builder" relates to resources? I don't know much about it. Does it spit out source code that you can include in your program? --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
AWCTTYPA@UIAMVS.BITNET ("David A. Lyons") (02/07/89)
>Date: Sun, 5 Feb 89 06:32:10 GMT >From: Christopher Hassell <tramp!hassell@BOULDER.COLORADO.EDU> >Subject: Re: Why resources on the GS will be _great_ >I'm for actually putting ALL of the true user-interface >object-templates up for grabs in it. How about having ALL objects >definable there, with defaults if not mentioned? Anything can be put in a resource. If the system doesn't support it directly, the application can still invent its own type of resource, but of course things are nicest when there's a system-defined standard for a particular kind of object. I don't know whether defaults are typically stored in the resources on the Mac or not, but it would certainly be a Good Thing. If it's not supported automatically in general, applications can still do a little work and keep defaults in separate resources. >NOW my main concern is this... Is it SMALLER? The calls and their >setting up and their actual code are rather tedious but IS IT BETTER? >If it is, as it certainly could be, compressed and optimized as a >list of object-creations w/little proc-codes or something then I'd >certainly vote for that! Many resources are just templates to be loaded into memory; these take the same space that the same templates would take if they were hard-coded into the program in the first place. But most Pascals don't provide a way to hard-code data structures, so more code is needed--resources will eliminate the need for setting up data structures that are set up clumsily in some high-level languages. It will make things smaller in some cases because the resources can be loaded from disk automatically when needed rather than loaded as part of the program. (But applications can load the resources all at the beginning to avoid causing extra disk swaps.) >That is certainly a hot option! Making code modular in its CODE >form, no less. Companies could come along and simply give you little >patchers to upgrade to the just-released-wild-new-machine-x for their >entire line. That kind of "carrying-ROM-with-you" may be a bit large >on the size side. Ideally (and in most cases) applications are compatible with future machines just by following the rules. There are certainly plenty of interesting ways to use code in resources, though. I suppose it remains to be seen whether people will organize their applications well enough that they can change big things about their programs by adding or replacing code segments. More typically they will probably be used where the modularity is already built into the application/etc somehow. >My other question is whether or not this would tax the already-loaded >processor speed and, not to mention, memory images. Adaptible code >that can be "inserted" once for machine-configuration would become >more common, BUT do all of these things need 1200K more in the >operating system? I don't know how much RAM the Resource Manager will take...we'll see. Overall I expect RAM requirements will go _down_ at the expense of doing more disk access during an application. I hope either the system or applications will provide the option of automatically loading all the resources (or all the _appropriate_ resources) into RAM when the application starts up, marking them "purgable" in memory so that no extra disk access is needed mid-application unless you're actually running out of RAM. >### C>H> ### --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