Path: utzoo!yunexus!unicus!craig
From: craig@unicus.UUCP (Craig D. Hubley)
Newsgroups: comp.sys.amiga
Subject: Re: The Resource Problem
Message-ID: <2442@unicus.UUCP>
Date: 28 Mar 88 21:15:29 GMT
Article-I.D.: unicus.2442
Posted: Mon Mar 28 16:15:29 1988
References: <4595@garfield.UUCP>
Reply-To: craig@Unicus.COM (Craig D. Hubley)
Organization: Unicus Software Inc., Toronto, Ont.
Lines: 79

In article <4595@garfield.UUCP> john13@garfield.UUCP (John Russell) writes:
>The idea of adding resources to the graphical display is fairly simple, with
>several ways to do it. Anyone with a reasonable grasp of Intuition could
>construct the functions necessary to read definitions for menus, gadgets,
>etc from a file and use those to configure his display. Of course the format
>one person would use would be incompatible with that of everyone else...

Unless we standardize it.  Unlike IPCs, the things in menu and gadget
structures are well-defined.  A file format would be a joke to produce,
except perhaps for those things that must be pointers to other things.
They'd just have to be cross-labelled and an entire tree of references
read in when the highest-level was requested.  Or if you want to get smart,
read the whole mess in at load-time.  But that would stop you from doing
some really neat tricks...

>Nothing's stopping anybody from creating resource files that look like:
>
>[myprog.res]
>menu 1 is 5 items
>	item 1 is "Open" shortcut O
>	...
>	item 5 is "Quit" shortcut Q
>etc
>
>window background pen is 2
>window foreground pen is 3
>
>window startup is
>	position 100 50
>	size 200 by 100

Good starting point.  Even pretty readable.  The *real* problem here is to 
build a library of routines that make the reading of these files transparent
and quick.  Everything from a high-level `Display the thing with this name'
to the low-level `give me a handle (pointer) to the flame string', kind of
like the Mac's Get..Resource() calls, where the name is optional and you
can call them by number (for speed, I presume ?)

>And so on, with appropriate error messages from your program if bad values /
>wrong # of menu items or whatever or supplied. Why haven't I done so? Never
>written anything big enough to warrant it! But it can already be done by
>some applications (eg DME, via config file and command-line options) so why
>not by everyone?
>
>I don't think compatibility is a big concern, as long as no one creates some
>sort of cryptic, bug ridden type of resource facility for some major
>commercial program.

But a standardized format means a ResEdit-type thingy that can edit the 
menus and the like, and leave the results in a standard format file.
Power Windows produces C code, I think, why not produce a resource file ?

>Some of this can already done by patching Intuition structures once the
>program has started. I experimented with that a while back, and could
>certainly do it a lot 'cleaner' now by using things like message ports to
>track adjusted resources, eg menuitems with new text. Intuition is very
>robust about things like this, as evidenced by 'Setfont', 'Add', 'VScreen',
>etc.

Maybe everyone who's gotten bogged down by the idea of an IPC could work
on this.  After all, it's a much more well-defined problem.  Even if only
a few common types of resources could be dealt with, that would be useful
for things like supporting multiple languages.  This is important on the
Amiga since it's more popular in Europe than here, and the best piece of
software I've seen so far was French.  Remember, guys, this cuts two ways.
Anyone care to propose a complete format ?  

This would gain us the flexibility of resources without requiring us to 
use them, so that it would be possible to *port* things that didn't use it.
Also, if such a standard was published, it would probably encourage all 
the software houses that took a chance on the Mac to take a chance on the
Amiga, too, and thereby captrue a market.

>John

	Craig Hubley, Unicus Corporation, Toronto, Ont.
	craig@Unicus.COM				(Internet)
	{uunet!mnetor, utzoo!utcsri}!unicus!craig	(dumb uucp)
	mnetor!unicus!craig@uunet.uu.net		(dumb arpa)