jnmoyne@lbl.gov (Jean-Noel MOYNE) (06/13/91)
[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.
It wouldn't be impossible to let's say .... number these series of tags
(representing a serie of gadgets, or a window+gadgets, or a
screen+window+....), call them resources, put them in a different chunk,
and then slightly modify Intuition routines so they can accept 'resources'
numbers instead of a pointer to a suit of tags (just load the tags out of
the chunk in mem before you call the 'old' intuition routine).
Then, at this point, you could write an Amiga ResEdit to create/modify
windows/screens/menus ...
This would be quite a good improvement (IMHO). I've programmed quite a lot
on both systems (even if Amiga is by far the one I know and like the
most), the Mac is really a hard computer to program (in front of the
Amiga), but it has a lot of very good ideas, and ResEdit is one of these
(at least for window, gadget, menus). When I think about how much time we
(developpers) had to wait before a program like power windows appeared,
and then when you think how buggy and really hard to use (because of the
bugs) this program was (like the first version wouldn't allow you to
create a PAL sized window, like the one after would crash during the
generation of the code, so you had to sort-of cut your stuff in 2 parts,
and then jungle with the 2 resulting sources files that have the same
variable names ! )-:).
Mac programmers had ResEdit really long ago.... I can say I'm still
jealous ! Especially when you know the way you have to create gadgets on
the Mac. Intuition is so much more powerfull, that a (well done) ResEdit
on the Amiga would really be a kick, and a great improvement, would help a
lot the programmers, and would make the programs easier to use for the end
users (the first and quite only reason of the Mac's success).
Another thing, in it's documentation, Apple spends quite a few pages to
explain guidelines of user-interface creation. Most of the Mac programmers
follow these guidelines, and that's one of the reason Macs are so easy to
use. The main functions are the same from one program to the other, if
you're used to one program, you can use another one very easily, you won't
be lost by a completely different user interface.
Now that CBM has finished with 2.0, it's time to think about the next
version (2.1 ? 3.0 ?). It would really be a good idea to try to implement
what I've described here (ResEdit-like possibilities + a small booklet:
'guidelines to building an Amiga User Interface'). By posting here, I'm
doing like a pray to God (i.e.: anybody_important_or_smart@commodore.com
(-:). I'll go burn a candle just after ! (-:
And I don't think that having a ResEdit kinda information in a separate
file is a good idea, makes the file harder to just copy or move, it's too
easy to loose on the way and the program can't work without it. And it's
the same thing as the .info files, ends up creating a mess of small files
in the dir, redondancy when you use dir or list in the CLI... baaaad ! (-:
JNM (doing the easy part: asking! (-:)
---
#include <std/disclaimer.h>
JNM: jnmoyne@lbl.gov - The postmaster allways pings twice (soon
in your mailbox!)m0154@tnc.UUCP (GUY GARNETT) (06/14/91)
Perhaps I sould clarify my idea about resource files. What I intended was that the resources be in a separate file during program development (to make it easier to manipulate the resources separately from the program) and be accessed through a set of functions in a (possible language or compiler dependent) link library. When you are ready to release the program, link a different resource library (one that knows how to locate resources installed in the executable), and bind the resource file to the program executable. That way, the thing won't get lost, and it will be in a separate, independent hunk (or hunks) so that it will be relatively easy to modify in place. One additional benefit of a resource editor like this one is that appropriate structures can be placed in a hunk and marked for storage in CHIP RAM (even if the compiler in question does not provide a facility for it). This can happen "automatically" in the resource editor (with a way to over-ride the default behavior, of course). Wildstar "... I'll see you on the dark side of the Moon!" -- Pink Floyd
jnmoyne@lbl.gov (Jean-Noel MOYNE) (06/15/91)
In article <837@tnc.UUCP> m0154@tnc.UUCP (GUY GARNETT) writes: > Perhaps I sould clarify my idea about resource files. What I > intended was that the resources be in a separate file during program > development (to make it easier to manipulate the resources separately > from the program) and be accessed through a set of functions in a > (possible language or compiler dependent) link library. That is what I ment, and it is the way it is done on the Mac. I also know that it is really easy to use different chunks for the resources to be able to put the data directly in CHIP RAM. So bad, as somebody said in an other message, use of colors isn't really specifyed in structures, but more done by the program, this part could be improved too. You should be able to specify a 'picture' to put on the back of your window, instead of having to use a command to do that. JNM --- #include <std/disclaimer.h> JNM: jnmoyne@lbl.gov - The postmaster allways pings twice (soon in your mailbox!)
mykes@amiga0.SF-Bay.ORG (Mike Schwartz) (06/17/91)
In article <837@tnc.UUCP> m0154@tnc.UUCP (GUY GARNETT) writes: > >Perhaps I sould clarify my idea about resource files. What I >intended was that the resources be in a separate file during program >development (to make it easier to manipulate the resources separately >from the program) and be accessed through a set of functions in a >(possible language or compiler dependent) link library. When you are >ready to release the program, link a different resource library (one >that knows how to locate resources installed in the executable), and >bind the resource file to the program executable. That way, the thing >won't get lost, and it will be in a separate, independent hunk (or >hunks) so that it will be relatively easy to modify in place. > You and I are totally on the same wavelength here. I'd suggest that a loadable .library and a linkable .lib would be in order. The ResEdit program could be built on the .library, and the applications could either use the .library or the .lib. The advantage of a .lib is that the app wouldn't require a .library to be present on the user's libs:. >One additional benefit of a resource editor like this one is that >appropriate structures can be placed in a hunk and marked for storage >in CHIP RAM (even if the compiler in question does not provide a >facility for it). This can happen "automatically" in the resource >editor (with a way to over-ride the default behavior, of course). > Not only would you want to store data structures like a NewWindow, but you could also store IFF graphics, text, and code as well. Imagine, if you will, calling GetNewWindow(), which reads the NewWindow structure from the resource, and the code and iff and text, and it does a CreateTask() for you. The code loaded would control the window... >Wildstar >"... I'll see you on the dark side of the Moon!" -- Pink Floyd -- **************************************************** * I want games that look like Shadow of the Beast * * but play like Leisure Suit Larry. * ****************************************************
stephane@grasp1.univ-lyon1.fr (Stephane Guillard) (06/17/91)
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. > > [...] > JNM (doing the easy part: asking! (-:) > Something could be easier to do at the moment (I dont think C= will modify its OS the way you want before X.0, X >> 2) : why not build a library which would enable programmers to use for instance Power Windows editable resources files in their apps instead of the generated source code ? (read Power Windows or any other Resed like GadgetEd or the alikes). I think this would enable separating resources from code, and editing resources without modifying code, without modifying the OS. We've seen many libraries coming up during the few last months, and this one should not be an untakable effort. >--- >#include <std/disclaimer.h> > >JNM: jnmoyne@lbl.gov - The postmaster allways pings twice (soon >in your mailbox!) -- \\\ Only Amiga | Stephane GUILLARD - GRASP INSA Lyon FRANCE \\\ makes it | Tel: +33 72438383 poste 5546 \\\/// possible! | eMail at : stephane@grasp1.univ-lyon1.fr \XX/
dillon@overload.Berkeley.CA.US (Matthew Dillon) (06/19/91)
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: (1) embedded program resources are a great idea but not easily editable. Take, for example, an IntuiText structure. While you might declare such a structure: struct IntuiText RES_IText = { ..... &MyFont ..... }; The compiler & linker will not necessarily generate output that is referencable by a resource editor, even if symbols are left intact and a special naming convention is used for the variable. Example: SAS and DICE residentable code. The &MyFont is not known at link time, only at run time. To make such resources editable would require the programmer to not write residentable code! This is obviously not a desirable description (2) solution: Give the program special arguments to enter a 'resource editing' mode. Being run-time, all declared structures will be resolved to real pointers. The disadvantage is that now it us up to the program to edit the resources. (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 Since resources are edited run time, this array will have been resolved even if the program is residentable. In this manner, a single library call can be made to 'edit the resources'. A resource such as an IntuiText structure may contain a pointer to a TextAttr structure which itself may or may not be a resource, depending on whether it is in the Resource array or not. The library, given the above array, can determine exactly what resources are editable and what sub-resources (resources in resources) are editable. The final problem is that of modifying the executable itself after resource editing is complete. There are two possibilities related to this: (1) Do not modify the executable. Instead, the library writes out the resource structure(s) pointed to by ResAry[] to a separate file. The program when run normally must then call a library routine with ResAry as an argument to 'load' the resources. Since it is not necessary for the library to modify any pointers, the library need only load those portions of the 'resources' that are not pointers. For example, given an IntuiText resource the library does not bother to store the pointer to the TextFont in the file (or if it does, it ignores it on load) because while the TextFont itself might be modified, the structure remains at the same location run-time. (2) Modify the executable. Difficult at best, even with symbols, because the library would have to convert run-time pointers into hunk offsets etc etc etc... a mess. (4) program example: /* * defaults */ char TextBuf[128] = { "This is a test" }; char TxName[64] = { "topaz.font" }; struct TextAttr Ta = { TxName, 9, 0, 0 }; struct IntuiText MyText = { -1, -1, JAM2, 0, 0, &MyFont, TextBuf, NULL }; struct Resource ResAry[] = { "TextAttr", &Ta, sizeof(TextAttr), 0, "MyText", &MyText, sizeof(MyText), 0, "CStr", TextBuf, sizeof(TextBuf), 0, "CStr, TxName, sizeof(TxName), 0 NULL }; main(ac, av) short ac; char *av[]; { /* * note that the LoadResources() call never modifies any * *pointers*, only the non-pointer portion of a resource. * This means that LoadResources() needs no special knowledge * of the memory model. */ LoadResources(ResAry, "S:MyResFile"); if (ac == 1 && stricmp(av[1], "RESEDIT") == 0) { EditResources(ResAry, "S:MyResFile"); exit(0); } ... run program ... UnLoadResources(ResAry, "S:MyResFile"); } The *Resources() calls are library calls. This system is quite simple, but has extensibility in its capabilities. (1) Defaults are embedded in the executable. (2) The executable is never modified. (3) the resource editor call is smart enough to arrange editing in a hierarchal fashion, i.e. it knows that the TextBuf resource is a sub-resource of the MyText resource because it sees the pointers in the array entry and in the MyText structure are the same. (4) The program can have support for multiple users each with their own resource configuration, or one user with several configurations for different purposes. DEVELOPERS NEED TO Agree on the format of resource structures. For the most part they can actually follow standard amiga structures such as the NewWindow structure, and even include BitMap's and the like and even constructs that are determined run-time by the program since all resource editing is done run-time. Some things are obvious... CStr is a pointer to a standard string buffer whos maximum size is given in the resource structure. What is not so obvious is, say, how to represent an IFF file. static-sized IFF is easy, you simply have a resource type of "IFF" and a pointer to a large buffer. But this presents limits on the IFF file -- it cannot be larger than the buffer. I propose that we agree on extensibile typesi or flags, such as have a RESF_DYNAMIC flag which indicates to the resource library that the res_Ptr is actually a pointer to a pointer which the library should fill in with an AllocMem() enough to hold a dynamically sized resource. I also propose a RESF_FOFFSET flag which indicates to the resource that the res_Offset field be loaded with the offset of the resource in the resource file instead of actually loading the resource. Finally, I propose a RESF_ARRAY to go along with RESF_DYNAMIC which specifies that not only is the resource to be dynamically loaded, but also that the user be able to specify several of the same type that are loaded as an array of that type of resource. For example, for an editor the user could specify an array of NewWindow structures defining where additional editor windows are to be openned. In this case res_Ptr points to an array of NewWindow structures instead of just one, with the res_Size field reflecting the sizee of the array in bytes, i.e. sizeof(NewWindow) * NumberOfUserDefinedWindows Sorry for the long-winded message, but what do people think? -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA
jonesjg@polaris.rtp.dg.com (Greg Jones) (06/22/91)
In article <dillon.8733@overload.Berkeley.CA.US> 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
jonesjg@polaris.rtp.dg.com (Greg Jones) (06/22/91)
In article <dillon.8733@overload.Berkeley.CA.US> 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. >>>... > > (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 jonesjg@dg-rtp.dg.com or jonesjg%dg-rtp.dg.com@relay.cs.net ...!mcnc!rti!dg-rtp!jonesjg
jnmoyne@lbl.gov (Jean-Noel MOYNE) (06/26/91)
References:<14224@dog.ee.lbl.gov> <1991Jun17.083311.7113@grasp1.univ-lyon1.fr> <dillon.8733@overload.Berkeley.CA.US> First, sorry for the delay of my answer, unfortunately I don't have much time for the news... In article <dillon.8733@overload.Berkeley.CA.US> dillon@overload.Berkeley.CA.US (Matthew Dillon) writes: > 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: Agreed ! The first step should be to make the programmer's life easier. Having separate resource files for the developpement phase, that would be linked at the end is a very good idea. In fact, it is the way most (all?) of the Mac compilers work now. And this resource file produced by the ResEdit (or whatever you call it) should be directly linkable (no compilation phase involved). > (1) embedded program resources are a great idea but not easily editable. Also true, that's why they should be in a different hunk of the program file, and NOT in the middle of the data section. The ResEdit program can for example read the whole ressource hunck in memory, let the user do all the modifications he wants, and then link it back into the binary file. Of course, that means you'll have to modify the linkers. > (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 > > Since resources are edited run time, this array will have been > resolved even if the program is residentable. In this manner, > a single library call can be made to 'edit the resources'. > A resource such as an IntuiText structure may contain a pointer > to a TextAttr structure which itself may or may not be a resource, > depending on whether it is in the Resource array or not. And what about having a library call like 'LoadResources()' at the beginning of the program (startup code?) that would allocate the memory and read the hunk (containing an Array like the one you described), and return a pointer to the array (the file has only offsets, and the LoadResources() convert these in pointers (for example)). If you want to modify one element of the array, then modify it in memory and when you write it back, change the pointers to offsets. But the floor cleaning guy is here ! Damn ! I'm kicked out of my desk ! I can't continue my message. I recognise that I don't know exactly how the AmigaDOS loader works, and that what I say may be quite difficult to implement. But that's the way I see it. I also don't think that having a X-window kind of file allowing you to have different configurations is a great thing: too much files (confusing for normal user) and Amiga is multitask, NOT multi-user.... I really got to go now .. or he's gonna wax my power cord .. JNM (in a hurry!) --- #include <std/disclaimer.h> JNM: jnmoyne@lbl.gov - The postmaster always pings twice (soon in your mailbox!)