home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / amiga / programm / 18218 < prev    next >
Encoding:
Internet Message Format  |  1993-01-06  |  4.2 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!moe.ksu.ksu.edu!crcnis1.unl.edu!crcnis1.unl.edu!manager
  2. From: pdietz@cse.unl.edu (Phil Dietz)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: People please infer! [ResEdit 21. for Amiga]
  5. Date: 6 Jan 1993 17:13:47 GMT
  6. Organization: NCEMRSoft
  7. Lines: 88
  8. Distribution: world
  9. Message-ID: <1if40bINNhjc@crcnis1.unl.edu>
  10. NNTP-Posting-Host: cse.unl.edu
  11.  
  12.  
  13. True, Marc Barret gets on alot of peoples nerves, but don't flame him when
  14. he asks a question (even in it's want-to-be-flammed context).
  15.  
  16. The Amiga has absolutley no type of ResEdit available.  If you want to move
  17. or edit a gadget...change a menu item...or add a font or what-have-you one
  18. has to recompile the whole darn thing.
  19.  
  20. I must agree that their should be some sort of ResEdit for the Amiga.  It
  21. should allow people to include fonts, pictures, and sounds to be transfered
  22. inside of applications as well as the ability to edit strings, move gadgets,
  23. and all the other GUI stuff.
  24.  
  25. -------------------------------------
  26. what a pseudo-resedit will accomplish
  27. -------------------------------------
  28.  
  29. FORS:  a. allow easy transportation of data files for an application (ie
  30.           fonts, picts, etc.).
  31.        b. allow a programmer or user to easily change the position of 
  32.           intuition objects (menus, gadgets, etc.)  that are normally
  33.           hard coded into a application and must be re-compiled.
  34.        c. ASSIGNs that are needed to point to an application data files
  35.           will no longer be needed since the files are in the APP. now.
  36.           (Thus making a clearer GUI to the super-novice)
  37.  
  38. AGAINST: a. programs will slow down since they will have to fetch the 
  39.             resources.
  40.          b. a faulty tampering of the the resources could bring about bad
  41.             results...thus programs would need a large degree of error
  42.             checking code, etc.
  43.          c. the ability for resources is put on Commodore's back (since OS
  44.             stuff will need to be changed.)
  45.  
  46. ----------------
  47. Now how we do it
  48. ----------------
  49. There are many possible ways a resource type chunk could be made, however two 
  50. stand out.
  51.  
  52. 1) Keep the resources in the accompaning .info file.  All this programs
  53.    data (picts, fonts, snds, etc.) could easily be added to it's .info
  54.    file probably as an IFF extension as well.  
  55.  
  56. FOR: a. having to have hundreds of ASSIGNs for a program to be able to run will
  57.         go away since the .info file will store all the extra data.  
  58.      b. Since all the data is in the info file, moving the application around
  59.         with Workbench will transparently move all the needed data files too.
  60.  
  61. AGAINST: a. if someone trashes the icon then all the data is toast.  But then 
  62.             again a person could due a 'format dh0:' by accident as well.
  63.      
  64. 2) Keep the resources in the so-called 'last un-used debug hunk' the executables
  65.    have.
  66.  
  67. FORS: a. Data is kept in the Application so trashing .info's will not harm
  68.          the integrity of the application.
  69.       b. If we use this hunk as a data area, we might as well put the .info
  70.          icon in their as well to reduce the number of unnecessary files
  71.          presented to users.
  72.  
  73. AGAINST: a. maybe some day we will need the extra hunk for something else.
  74.  
  75. ----------
  76. my opinion
  77. ----------
  78.  
  79. I would shoot for the hunk storage area since theoretically one can store the
  80. .info in it as well.
  81.  
  82. Allowing a resource type chunk allows for customability.  
  83.   - No need in copying an apps fonts to fonts: and all that jazz.  
  84.   - No need in making 5 or 6 assigns.  Just click the icon like it should be.  
  85.   - If a programmer needs to move his static intui-objects around he can do it
  86.     without hassles. Imagine a RES-Edit similar to GadToolsBox.
  87.     If the programmer has some things he doesn't want customizable..he can 
  88.     just hard-code them the old way.
  89.  
  90. Commodore now allows the easy changing of internal strings (localization).
  91. They should take it another step and allow other data type to be changed.
  92.  
  93. I see only benefits from allowing the resource chunk. 
  94.  
  95.  
  96. --
  97.                                                               Phil Dietz
  98.      Why is Windows so popular?                       pdietz@cse.unl.edu
  99.         'PKzip for Windows' of course             University Of Nebraska
  100.