home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / acorn / tech / 1198 < prev    next >
Encoding:
Internet Message Format  |  1993-01-08  |  4.0 KB

  1. Path: sparky!uunet!pipex!demon!kernow.demon.co.uk!vulch
  2. Newsgroups: comp.sys.acorn.tech
  3. From: vulch@kernow.demon.co.uk (Anthony Frost)
  4. Reply-To: vulch@kernow.demon.co.uk
  5. Subject: New Template file format RFC
  6. Organization: VCS Kernow
  7. X-Mailer: ReaderS for the Acorn Archimedes
  8. Date: Fri, 8 Jan 1993 20:42:06 +0000
  9. Message-ID: <930108204206@kernow.demon.co.uk>
  10. Sender: usenet@demon.co.uk
  11. Lines: 73
  12.  
  13. I've been passing all contributions to the template file format discussion
  14. to Tim, he has asked me to post the following...
  15.  
  16.  
  17. ----------------------------cut--here-------------------------------------
  18.  
  19. Re:Glass files - a short addendum...
  20.  
  21. A few people have commented on the naming of icons and asked how the lookup
  22. of icon names would work - a library? a relocatable module?
  23.  
  24. Now then, here I must confess to being a bit of a heretic - I'd always
  25. thought that a constant header file would be generated and would be used
  26. with the source (whether for C, ARM, BASIC, Pascal etc).  ie the
  27. compiler/assembler would actually use the icon number directly (via a
  28. #define) or in the case of BASIC, the interpreter would use the variable
  29. contents to get the number.  There may be problems in getting this to work
  30. with BASIC (I looked at using LIBRARY to do this - I think it's a
  31. non-starter as it won't share variables) but there must be *some* way to do
  32. it reasonably elegantly, and, as Dick Alstein pointed out, BASIC is handy
  33. for small apps, and it's dead cheap (=free); I consider ensuring that the
  34. format is usable by BASIC important.
  35.  
  36. There are two reasons why I don't think icon names should be used at run
  37. time:
  38.  
  39. (1) It's inefficient. Just think about it - *every* time you change an
  40. icon's contents, set its flags, read its selection state, decode a mouse
  41. click - you go through a string look up table routine.  This may be
  42. acceptable to some people, but not to me, because, well...see (2).
  43.  
  44. (2) What's the point?  Heretical, I know, but what do you actually gain by
  45. being able to decode icon names at run time? If you change a name, the
  46. source has to change too - so recompilation is necessary. If you change icon
  47. names around, the program no longer works properly - so why do you need it?
  48. Why not just leave it to the compiler/interpreter?  There's only one
  49. instance I can think of that that might warrant it:
  50.  
  51.  You want to change the icon ordering - without string lookup this
  52.  will require re-compilation.
  53.  
  54. But why would the *end-user* want to do this?  It would be a *very* minor
  55. advantage for the programmer to be able to do this without re-compiling.
  56.  
  57. In summary, I don't consider the overhead (having to keep icon names in
  58. memory, having to scan them for every icon access) to justify the additional
  59. functionality (which I perceive to be zero). I am open to suggestion - if
  60. anyone can think of any reason why run-time look up would be desirable, post
  61. to this group - giving a convincing example! I am, as you may have divined,
  62. somewhat sceptical, but I don't mind being proved wrong. Also, failing a
  63. suitable alternative solution for BASIC, we might as well do it...
  64.  
  65. As to the suggestion of a module to support loading etc of Glass files -
  66. this seems a good idea as it negates the need for specific prog.lang.
  67. libraries, and avoids duplication of effort by co-resident applications.
  68. Comments? Anyone against this?
  69.  
  70. Finally, thanks for the general tone of the comments on the format so far -
  71. helpful, constructive and technically sound.  Keep it up :-)
  72.  
  73. Tim Browse.
  74.  
  75. PS. I know BASIC does a string lookup to access variables anyway, but
  76. that's a side issue. I don't see that it warrants run-time look-up.
  77. Unless you know better?
  78. PPS.Stop press - I've just thought of a reason which may justify decoding
  79. icons at run-time, but I want to see if anyone else thinks of it :-)
  80. If you want a hint, have a look at Glazier's template file(s).
  81.                                                            |
  82.                                   this is a clue ! --------+
  83.  
  84. ---------------------------cut--here---------------------------------------
  85.  
  86.