From: shacha1@tau.ac.il (SHEMESH SHACHAR)
Subject: Re: People please infer! [ResEdit 21. for Amiga]
Organization: Tel-Aviv University Computation Center
X-Newsreader: TIN [version 1.1 PL8]
Date: Thu, 7 Jan 1993 12:12:02 GMT

Phil Dietz (pdietz@cse.unl.edu) wrote:

: True, Marc Barret gets on alot of peoples nerves, but don't flame him when
: he asks a question (even in it's want-to-be-flammed context).

: The Amiga has absolutley no type of ResEdit available.  If you want to move
: or edit a gadget...change a menu item...or add a font or what-have-you one
: has to recompile the whole darn thing.

: I must agree that their should be some sort of ResEdit for the Amiga.  It
: should allow people to include fonts, pictures, and sounds to be transfered
: inside of applications as well as the ability to edit strings, move gadgets,
: and all the other GUI stuff.

: -------------------------------------
: what a pseudo-resedit will accomplish
: -------------------------------------

: FORS:  a. allow easy transportation of data files for an application (ie
:           fonts, picts, etc.).
:        b. allow a programmer or user to easily change the position of
:           intuition objects (menus, gadgets, etc.)  that are normally
:           hard coded into a application and must be re-compiled.
:        c. ASSIGNs that are needed to point to an application data files
:           will no longer be needed since the files are in the APP. now.
:           (Thus making a clearer GUI to the super-novice)

: AGAINST: a. programs will slow down since they will have to fetch the
:             resources.
Not necessary - If we pick the solution that you though of in the end,
you can use the resources from where they are. They will behave
exactly like regular static global data.
:          b. a faulty tampering of the the resources could bring about bad
:             results...thus programs would need a large degree of error
:             checking code, etc.
No need - don't temper with the resources if you don't know what you
are doing. If you do - serves you right what you get.
:          c. the ability for resources is put on Commodore's back (since OS
:             stuff will need to be changed.)
It will need updates, surly. But so will any other program. So long as
Commodore keeps the OS backward compatible, there should be no
problem.
: ----------------
: Now how we do it
: ----------------
: There are many possible ways a resource type chunk could be made, however two
: stand out.

: 1) Keep the resources in the accompaning .info file.  All this programs
:    data (picts, fonts, snds, etc.) could easily be added to it's .info
:    file probably as an IFF extension as well.

: FOR: a. having to have hundreds of ASSIGNs for a program to be able to run will
:         go away since the .info file will store all the extra data.
:      b. Since all the data is in the info file, moving the application around
:         with Workbench will transparently move all the needed data files too.

: AGAINST: a. if someone trashes the icon then all the data is toast.  But then
:             again a person could due a 'format dh0:' by accident as well.
Not really. Many users don't keep the .info files at all, and use it
only from CLI. Also - CLI launched applications will not be able to
find the .info file easily.

: 2) Keep the resources in the so-called 'last un-used debug hunk' the executables
:    have.

: FORS: a. Data is kept in the Application so trashing .info's will not harm
:          the integrity of the application.
:       b. If we use this hunk as a data area, we might as well put the .info
:          icon in their as well to reduce the number of unnecessary files
:          presented to users.

: AGAINST: a. maybe some day we will need the extra hunk for something else.
There is an answer to that - It has to do with not putting it in a
Debug hunk at all, but in a Data hunk, however I cannot say more about
it since I want to begin development of such a system in the near
future (no promises though).

another against will be that many crunchers remove the debug hunks,
and also some linkers.

: ----------
: my opinion
: ----------

: I would shoot for the hunk storage area since theoretically one can store the
: .info in it as well.
That would, of course, demand Commodore to change the WB. It would
also mean that the workbench will have to look at two places for the
icons.
: Allowing a resource type chunk allows for customability.
:   - No need in copying an apps fonts to fonts: and all that jazz.
:   - No need in making 5 or 6 assigns.  Just click the icon like it should be.
:   - If a programmer needs to move his static intui-objects around he can do it
:     without hassles. Imagine a RES-Edit similar to GadToolsBox.
That is exactly what I had in mind to develop. It should be better for
the programer because he will not have to recompile after a change,
and also he will not have to bring foreign code into his own. Also it
should work with any language, any compiler.
:     If the programmer has some things he doesn't want customizable..he can
:     just hard-code them the old way.

: Commodore now allows the easy changing of internal strings (localization).
: They should take it another step and allow other data type to be changed.
They I though of implementing it, Commodore doesn't have to do a thing
(It would be nice if they did, of course, but it as we all know, the
likelyhood of that happening is low).
Also, it should work with all systems, right down to 1.3 and lower.
: I see only benefits from allowing the resource chunk.
The benefits are not only to the user, but also to the programer.  Not
only the mentioned above, but also he will not have to do anything
special to localise his programs. The resource support can even use
local.library if necessary to make the translations, so that the
program will still choose the best suited language automatically.

: --
:                                                               Phil Dietz
:      Why is Windows so popular?                       pdietz@cse.unl.edu
:         'PKzip for Windows' of course             University Of Nebraska
I don't want want anyone to get the idea that I have something of the
sort. This is just an idea that I want to begin working on. Any help
in the form of suggestions as for what should this system include will
be greatly appretiated, as well as knowledge of any such program
already available.

--
"Is it just me or has the world always been like that and I've been to
wraped up in myself to notice?" [Arthur Dent, THHGTTG]
Shachar Shemesh  (TheSun on IRC) shacha1@ccsg.tau.ac.il
My opinions are my own, not those of Commodore. In fact - I have
nothing to do with Commodore at all.