home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / amiga / programm / 18271 < prev    next >
Encoding:
Text File  |  1993-01-07  |  6.9 KB  |  145 lines
  1. Newsgroups: comp.sys.amiga.programmer
  2. Path: sparky!uunet!news.univie.ac.at!blekul11!frmop11!barilvm!aristo.tau.ac.il!shacha1
  3. From: shacha1@tau.ac.il (SHEMESH SHACHAR)
  4. Subject: Re: People please infer! [ResEdit 21. for Amiga]
  5. Message-ID: <1993Jan7.121202.9554@aristo.tau.ac.il>
  6. Sender: usenet@aristo.tau.ac.il (USENET)
  7. Nntp-Posting-Host: ccsg.tau.ac.il
  8. Organization: Tel-Aviv University Computation Center
  9. X-Newsreader: TIN [version 1.1 PL8]
  10. References: <1if40bINNhjc@crcnis1.unl.edu>
  11. Date: Thu, 7 Jan 1993 12:12:02 GMT
  12. Lines: 131
  13.  
  14. Phil Dietz (pdietz@cse.unl.edu) wrote:
  15.  
  16. : True, Marc Barret gets on alot of peoples nerves, but don't flame him when
  17. : he asks a question (even in it's want-to-be-flammed context).
  18.  
  19. : The Amiga has absolutley no type of ResEdit available.  If you want to move
  20. : or edit a gadget...change a menu item...or add a font or what-have-you one
  21. : has to recompile the whole darn thing.
  22.  
  23. : I must agree that their should be some sort of ResEdit for the Amiga.  It
  24. : should allow people to include fonts, pictures, and sounds to be transfered
  25. : inside of applications as well as the ability to edit strings, move gadgets,
  26. : and all the other GUI stuff.
  27.  
  28. : -------------------------------------
  29. : what a pseudo-resedit will accomplish
  30. : -------------------------------------
  31.  
  32. : FORS:  a. allow easy transportation of data files for an application (ie
  33. :           fonts, picts, etc.).
  34. :        b. allow a programmer or user to easily change the position of
  35. :           intuition objects (menus, gadgets, etc.)  that are normally
  36. :           hard coded into a application and must be re-compiled.
  37. :        c. ASSIGNs that are needed to point to an application data files
  38. :           will no longer be needed since the files are in the APP. now.
  39. :           (Thus making a clearer GUI to the super-novice)
  40.  
  41. : AGAINST: a. programs will slow down since they will have to fetch the
  42. :             resources.
  43. Not necessary - If we pick the solution that you though of in the end,
  44. you can use the resources from where they are. They will behave
  45. exactly like regular static global data.
  46. :          b. a faulty tampering of the the resources could bring about bad
  47. :             results...thus programs would need a large degree of error
  48. :             checking code, etc.
  49. No need - don't temper with the resources if you don't know what you
  50. are doing. If you do - serves you right what you get.
  51. :          c. the ability for resources is put on Commodore's back (since OS
  52. :             stuff will need to be changed.)
  53. It will need updates, surly. But so will any other program. So long as
  54. Commodore keeps the OS backward compatible, there should be no
  55. problem.
  56. : ----------------
  57. : Now how we do it
  58. : ----------------
  59. : There are many possible ways a resource type chunk could be made, however two
  60. : stand out.
  61.  
  62. : 1) Keep the resources in the accompaning .info file.  All this programs
  63. :    data (picts, fonts, snds, etc.) could easily be added to it's .info
  64. :    file probably as an IFF extension as well.
  65.  
  66. : FOR: a. having to have hundreds of ASSIGNs for a program to be able to run will
  67. :         go away since the .info file will store all the extra data.
  68. :      b. Since all the data is in the info file, moving the application around
  69. :         with Workbench will transparently move all the needed data files too.
  70.  
  71. : AGAINST: a. if someone trashes the icon then all the data is toast.  But then
  72. :             again a person could due a 'format dh0:' by accident as well.
  73. Not really. Many users don't keep the .info files at all, and use it
  74. only from CLI. Also - CLI launched applications will not be able to
  75. find the .info file easily.
  76.  
  77. : 2) Keep the resources in the so-called 'last un-used debug hunk' the executables
  78. :    have.
  79.  
  80. : FORS: a. Data is kept in the Application so trashing .info's will not harm
  81. :          the integrity of the application.
  82. :       b. If we use this hunk as a data area, we might as well put the .info
  83. :          icon in their as well to reduce the number of unnecessary files
  84. :          presented to users.
  85.  
  86. : AGAINST: a. maybe some day we will need the extra hunk for something else.
  87. There is an answer to that - It has to do with not putting it in a
  88. Debug hunk at all, but in a Data hunk, however I cannot say more about
  89. it since I want to begin development of such a system in the near
  90. future (no promises though).
  91.  
  92. another against will be that many crunchers remove the debug hunks,
  93. and also some linkers.
  94.  
  95. : ----------
  96. : my opinion
  97. : ----------
  98.  
  99. : I would shoot for the hunk storage area since theoretically one can store the
  100. : .info in it as well.
  101. That would, of course, demand Commodore to change the WB. It would
  102. also mean that the workbench will have to look at two places for the
  103. icons.
  104. : Allowing a resource type chunk allows for customability.
  105. :   - No need in copying an apps fonts to fonts: and all that jazz.
  106. :   - No need in making 5 or 6 assigns.  Just click the icon like it should be.
  107. :   - If a programmer needs to move his static intui-objects around he can do it
  108. :     without hassles. Imagine a RES-Edit similar to GadToolsBox.
  109. That is exactly what I had in mind to develop. It should be better for
  110. the programer because he will not have to recompile after a change,
  111. and also he will not have to bring foreign code into his own. Also it
  112. should work with any language, any compiler.
  113. :     If the programmer has some things he doesn't want customizable..he can
  114. :     just hard-code them the old way.
  115.  
  116. : Commodore now allows the easy changing of internal strings (localization).
  117. : They should take it another step and allow other data type to be changed.
  118. They I though of implementing it, Commodore doesn't have to do a thing
  119. (It would be nice if they did, of course, but it as we all know, the
  120. likelyhood of that happening is low).
  121. Also, it should work with all systems, right down to 1.3 and lower.
  122. : I see only benefits from allowing the resource chunk.
  123. The benefits are not only to the user, but also to the programer.  Not
  124. only the mentioned above, but also he will not have to do anything
  125. special to localise his programs. The resource support can even use
  126. local.library if necessary to make the translations, so that the
  127. program will still choose the best suited language automatically.
  128.  
  129. : --
  130. :                                                               Phil Dietz
  131. :      Why is Windows so popular?                       pdietz@cse.unl.edu
  132. :         'PKzip for Windows' of course             University Of Nebraska
  133. I don't want want anyone to get the idea that I have something of the
  134. sort. This is just an idea that I want to begin working on. Any help
  135. in the form of suggestions as for what should this system include will
  136. be greatly appretiated, as well as knowledge of any such program
  137. already available.
  138.  
  139. --
  140. "Is it just me or has the world always been like that and I've been to
  141. wraped up in myself to notice?" [Arthur Dent, THHGTTG]
  142. Shachar Shemesh  (TheSun on IRC) shacha1@ccsg.tau.ac.il
  143. My opinions are my own, not those of Commodore. In fact - I have
  144. nothing to do with Commodore at all.
  145.