Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!crdgw1!uunet!dg-rtp!polaris!jonesjg From: jonesjg@polaris.rtp.dg.com (Greg Jones) Newsgroups: comp.sys.amiga.programmer Subject: Re: ResEdit for the Amiga? It's not impossible... and it's desirable Message-ID: <1991Jun22.070156.10006@dg-rtp.dg.com> Date: 22 Jun 91 07:01:56 GMT References: <14224@dog.ee.lbl.gov> <1991Jun17.083311.7113@grasp1.univ-lyon1.fr> Sender: usenet@dg-rtp.dg.com (Usenet Administration) Distribution: comp.sys.amiga.programmer Organization: Data General Corporation, RTP, NC. Lines: 59 In article dillon@overload.Berkeley.CA.US (Matthew Dillon) writes: >In article <1991Jun17.083311.7113@grasp1.univ-lyon1.fr> stephane@grasp1.univ-lyon1.fr (Stephane Guillard) writes: >>In article <14224@dog.ee.lbl.gov> jnmoyne@lbl.gov (Jean-Noel MOYNE) writes: >>>[about a ResEdit for the Amiga] >>> >>>Well, creating such a thing for the Amiga doesn't look as impossible as >>>that. Think about the WB 2.0, and the way it handles windows, screens and >>>gadgets: tags. >>>... > > The whole problem is that of convenience and extensibility. Unless the > system can be made convenient to the programmer and also be extensible > and easily modifiable, nobody will use it. I've had my go at > resources, both attempts didn't work too well, but here's a new idea: > (3) solution: Here is where a library comes in. In the program declare > a structural array of editable resources, like this: > > struct Resource { > char *res_Type; /* type of resource (name) */ > union { > void *Ptr; /* pointer to resource */ > long Offset; > } u; > long res_Size; /* size of res. in bytes */ > long res_Flags; /* user, system, whatever */ > } ResAry[] = { > > #define res_Ptr u.Ptr > #define res_Offset u.Offset > > Sorry for the long-winded message, but what do people think? > > -Matt > >-- > > Matthew Dillon dillon@Overload.Berkeley.CA.US I think the idea of a standard set of library routines for resources makes a lot of sense. It reminds me a little of the X window mechanism for user preferences, which has proven to be very flexible. Users of motif can use a resource file to specify, the size, color, text, font, and many other attributes of the toolkit supplied widgets. Using an heirarchal namespace for resource names along with wildcards allows the user to over the applications at any level. For example, you could use *.font in the database to specify the default font for every application, while myterm.font would only be used for the application myterm. I like it .... Greg Jones J. Greg Jones Data General Corp - RTP, NC