john13@garfield.UUCP (John Russell) (03/19/88)
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... 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 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. 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. John PS To Davide Cervone, I've been unable to reach you by mail; could I get sources + binaries to VScreen by mail? Your letter reached me fine.
lawley@munnari.oz (Michael J. Lawley) (03/22/88)
in article <4595@garfield.UUCP>, john13@garfield.UUCP (John Russell) says: > > 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... > > 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 > ^^^ Personally, I think this sort of format is a bit verbose and cumbersome however, with my nifty new product (see below) you could write a simple program to convert this sort of format to the format I use. [ stuff deleted ] > John Actually, I've already written all the routines for just such a system. All I have to do is work out how to convert them into a shared library (like intuition.library etc) and write a converter that takes standard C structure initialisers and converts them to the resource file format and I will release it. It is in fact more sophisticated than what you describe as it keeps track of everything you have opened (windows, screens, menus etc) and closes them, deallocates the memory used for temp storage etc when the program exits. It is based on the Mac way of doing things (since I wrote an application using them on the Mac and found it great for simple but sophisticated looking interfaces), so you can define a window with an ID of, say, 1 then open window 1 as many times as you like, it will open a new window each time on the specified screen, open it if necessary, attatching any gadgets, menus etc. Eventually, I hope to get an editor written along the lines of PowerWindows or ResEdit (for the Mac), but until then the converter will have to do. (Maybe someone else would like to write the editor) Mike.
craig@unicus.UUCP (Craig D. Hubley) (03/29/88)
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)
kim@amdahl.uts.amdahl.com (Kim DeVaughn) (03/31/88)
In article <2442@unicus.UUCP>, craig@unicus.UUCP (Craig D. Hubley) writes: > In article <4595@garfield.UUCP> john13@garfield.UUCP (John Russell) writes: > > >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. While some standards/guidelines would be nice, they aren't an absolute necessity. The vt100 terminal emulation and comm program has always allowed window colors, type, etc. to be specified. Tony added the ability to define one's one "shortcut key" bindings in v2.7. All you have to do is read in a config/init file, and set things to what the *user* wants. Perhaps not as "elegant" as a resource "hunk", but it *works*. Now. Today. Only point I'm trying to make, is that if you wait for standards, etc. to come out, you will (likely) be waiting a *long* time. Ever notice that most standards, etc. seldom spring full blown on a waiting audience, but tend to evolve from "current practices", instead? /kim -- UUCP: kim@amdahl.amdahl.com or: {sun,decwrl,hplabs,pyramid,ihnp4,uunet,oliveb,cbosgd,ames}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 CIS: 76535,25
cmcmanis%pepper@Sun.COM (Chuck McManis) (03/31/88)
Another part of the 'resource' problem isn't a problem at all. And that's the
pointers that are imbedded into the code. Because when the *user* edits the
'resource' file (I like to call them tool files) they are only interested in
changing things like the fonts, text, borders, and menu shortcuts. The other
stuff is fixed by the application at compile time. Take my ezmenus package
for instance, it uses a link list of structures to build up a menu list.
The structure can be reordered at will in the code and the menu will change
appropriately. It is a very simple modification to have the runtime code
read these structures from a file. Things like the 'routine to execute'
when a menu is selected appear in the file as 32 bit hex constants but
the user doesn't care because those fields are 'unmodifiable'.
--Chuck
--Chuck McManis
uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.mp1u+@andrew.cmu.edu (Michael Portuesi) (04/03/88)
Excerpts from: 22-Mar-88 Re: The Resource Problem Michael J. Lawley@munnar (2135) > Actually, I've already written all the routines for just such a system. [...] > It is in fact more sophisticated than what you describe as it keeps track of > everything you have opened (windows, screens, menus etc) and closes them, > deallocates the memory used for temp storage etc when the program exits. [...] > Eventually, I hope to get an editor written along the lines of PowerWindows > or ResEdit (for the Mac), but until then the converter will have to do. > (Maybe someone else would like to write the editor) Not to belittle anyone's efforts, but I think resources are yet one more area where developers are going to have to establish a standard (along with window iconification and IPC) before everyone produces "their way of doing it" and leaves application development in utter chaos from the result. --M Michael Portuesi / Carnegie Mellon University ARPA/UUCP: mp1u+@andrew.cmu.edu BITNET: rainwalker@drycas "Memories are uncertain friends, when recalled by messages" -- OMD, "Messages"
doug@eris (Doug Merritt) (04/04/88)
In article <QWJQary00Xo4M4eEV1@andrew.cmu.edu> mp1u+@andrew.cmu.edu (Michael Portuesi) writes: >Excerpts from: 22-Mar-88 Re: The Resource Problem Michael J. Lawley@munnar >> Eventually, I hope to get an editor written along the lines of PowerWindows > >Not to belittle anyone's efforts, but I think resources are yet one more area >where developers are going to have to establish a standard (along with window >iconification and IPC) before everyone produces "their way of doing it" and >leaves application development in utter chaos from the result. Nice idea. However, please note that the discussion of TCP, no matter how hot it seems recently, has in fact been going on for over a year, with no final standard established yet. This is typical of standards efforts. I encourage anyone and everyone to go ahead and do their own thing rather than waiting forever. Some discussion first is a good idea, of course, but don't let it slow you down. Doug Merritt doug@eris.berkeley.edu (ucbvax!eris!doug) or ucbvax!unisoft!certes!doug