home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / sys / acorn / tech / 1427 < prev    next >
Encoding:
Internet Message Format  |  1993-01-27  |  3.8 KB
  1. Path: sparky!uunet!comp.vuw.ac.nz!newshost.wcc.govt.nz!sideways!bridge!julian
  2. From: julian@bridge.welly.gen.nz (Julian Wright)
  3. Newsgroups: comp.sys.acorn.tech
  4. Subject: Glass format: Do we really need it?
  5. Message-ID: <3kl5BVj027n@bridge.welly.gen.nz>
  6. Date: Mon, 25 Jan 1993 22:41:47 +1300
  7. References: <MNEWS.727635326.17168@demon.co.uk>
  8. Reply-To: wright_j@kosmos.wcc.govt.nz
  9. Organization: USS Enterprise, NCC 1701a
  10. Lines: 84
  11.  
  12. tb@liszt.thorn-emi-crl.co.uk (Tim Browse) writes:
  13.  
  14. > One thing that had occured to me was that it would be nice to 
  15. > have two GLS_WIND type chunks - one for System font templates, 
  16. > and one for Anti-aliased fonts...perhaps a GLS_WINF for the fancy 
  17. > font chunk? Obviously you'd tell the module which one to load 
  18. > when you do a Glass_Load or whatever so they're not soaking up 
  19. > memory if not used...
  20.  
  21. I don't think there is a need for this. You can get this effect
  22. by putting a standard prefix/suffix onto the identifier of
  23. each window defined in the file, so that, for example, you could
  24. have the windows "saveas" and "saveas_f" both defined, the latter
  25. using fonts... you could extend this and have "saveas_3" and
  26. "saveas_3f" as well, for 3d varients, if you like...
  27.  
  28. Actually, I'd like to play Devil's Advocate here, and ask why do
  29. we need a new template file format? Let me go through the reasons
  30. that I have seen posted so far...
  31.  
  32.   "It would allow the centralising of resources"
  33.  
  34.   I hope you don't mean putting lots of different data files into
  35.   one chunk file. This would be, IMHO, much more difficult to
  36.   maintain during developement, as the output of the individual
  37.   editors/utilities used to create those data files would then
  38.   need to be merged into the GLASS file before they could be used.
  39.   To me this smells like a Macintosh's forks. I think using
  40.   separate files inside an Application directory is a far
  41.   superior method of resource management.
  42.  
  43.   "You could include menu definitions in it"
  44.  
  45.   You can do the same with the current template file format if you
  46.   want to. Just include data with a new chunk type, for example
  47.   type &554E454D springs to mind (I doubt Acorn will use this
  48.   type for quite a while...).
  49.  
  50.   "You could have named icons"
  51.  
  52.   There are several ways of doing this in the current template file
  53.   format. For example you could insert a list of tags (names) after
  54.   each window+icons definition and before the indirected data for
  55.   that definition. Or you could define a TAGS (&53474154) chunk
  56.   that has the list of names in it (null name for anonymous icon).
  57.   There could be one of these chunks after each window (type 1)
  58.   chunk...
  59.  
  60.   (I would suggest that library code used for loading the template
  61.   would be passed a list of tags and a buffer to fill with a list
  62.   of corresponding integer icon numbers, BTW)
  63.  
  64.   "You could have meta-icons"
  65.  
  66.   Include a flags word after each tag in the list of tags in the
  67.   TAGS chunk. Or the flags word could contain the group number
  68.   that this icon belongs to, as well as the function of the group
  69.   as a whole. Or you could use ESG numbers to group icons together.
  70.  
  71.   "It could be an extensible tagged file format"
  72.  
  73.   Beautifying the format for the sake of it. The current template
  74.   file format *is* extensible, and I see no reason to re-invent
  75.   the wheel.
  76.  
  77.   "Chunks of the file could be timestamped"
  78.  
  79.   How about the template editor simply *preserving the date stamp*
  80.   when it detects that the only thing that has changed is the
  81.   positioning of a window or icon...?
  82.  
  83.   "We won't have to guess the memory requirements"
  84.  
  85.   You don't with the current template file format, and RISC OS 3.10.
  86.   You can call Wimp_LoadTemplate without a buffer pointer and it
  87.   will return the size of the required buffer(s).
  88.  
  89. In summary, I have not yet seen a reason why a new template file
  90. format is needed at this stage. Have I missed something?
  91.  
  92.     Cheers, Julian
  93.  
  94. --
  95. Question Authority!   WHY?
  96.