🚀 go-pugleaf

tb@liszt.thorn-emi-crl.co.uk (Tim Browse) writes:

> One thing that had occured to me was that it would be nice to 
> have two GLS_WIND type chunks - one for System font templates, 
> and one for Anti-aliased fonts...perhaps a GLS_WINF for the fancy 
> font chunk? Obviously you'd tell the module which one to load 
> when you do a Glass_Load or whatever so they're not soaking up 
> memory if not used...

I don't think there is a need for this. You can get this effect
by putting a standard prefix/suffix onto the identifier of
each window defined in the file, so that, for example, you could
have the windows "saveas" and "saveas_f" both defined, the latter
using fonts... you could extend this and have "saveas_3" and
"saveas_3f" as well, for 3d varients, if you like...

Actually, I'd like to play Devil's Advocate here, and ask why do
we need a new template file format? Let me go through the reasons
that I have seen posted so far...

  "It would allow the centralising of resources"

  I hope you don't mean putting lots of different data files into
  one chunk file. This would be, IMHO, much more difficult to
  maintain during developement, as the output of the individual
  editors/utilities used to create those data files would then
  need to be merged into the GLASS file before they could be used.
  To me this smells like a Macintosh's forks. I think using
  separate files inside an Application directory is a far
  superior method of resource management.

  "You could include menu definitions in it"

  You can do the same with the current template file format if you
  want to. Just include data with a new chunk type, for example
  type &554E454D springs to mind (I doubt Acorn will use this
  type for quite a while...).

  "You could have named icons"

  There are several ways of doing this in the current template file
  format. For example you could insert a list of tags (names) after
  each window+icons definition and before the indirected data for
  that definition. Or you could define a TAGS (&53474154) chunk
  that has the list of names in it (null name for anonymous icon).
  There could be one of these chunks after each window (type 1)
  chunk...

  (I would suggest that library code used for loading the template
  would be passed a list of tags and a buffer to fill with a list
  of corresponding integer icon numbers, BTW)

  "You could have meta-icons"

  Include a flags word after each tag in the list of tags in the
  TAGS chunk. Or the flags word could contain the group number
  that this icon belongs to, as well as the function of the group
  as a whole. Or you could use ESG numbers to group icons together.

  "It could be an extensible tagged file format"

  Beautifying the format for the sake of it. The current template
  file format *is* extensible, and I see no reason to re-invent
  the wheel.

  "Chunks of the file could be timestamped"

  How about the template editor simply *preserving the date stamp*
  when it detects that the only thing that has changed is the
  positioning of a window or icon...?

  "We won't have to guess the memory requirements"

  You don't with the current template file format, and RISC OS 3.10.
  You can call Wimp_LoadTemplate without a buffer pointer and it
  will return the size of the required buffer(s).

In summary, I have not yet seen a reason why a new template file
format is needed at this stage. Have I missed something?

    Cheers, Julian

--
Question Authority!   WHY?