🚀 go-pugleaf

> By 'absence of action by Acorn', I mean that when I asked for a filetype
> to do this, no-one at Acorn said "Hang on, we're about to do something like
> that!", and, as I assume this is half the point of Acorn being the
> organisation that allocates filetypes, I guess nothing is happening soon.

I heard that Acorn are working on it, but it's probably going to be just the 
addition of icon names, and they're (sigh) added to the validation string.

> As mentioned, the file will be a chunk file as specified in the Acorn C
> manuals. [...] If anyone doesn't have access to it I'm sure myself or
> someone else could outline the format if necessary.

Yes, please.

[Long proposal for file format deleted; read the original posting]

* Estimating memory requirements
  With the current format definition, it's not easy to estimate the memory
  requirements for a set of templates. The problem is mainly with writable
  icons: in the file, there is only space for the actual contents of the
  icon; an empy string takes 1 byte; when you create the window, the user
  is able to edit the string, and fill it to the maximum length. Therefore,
  you have to allocate extra space up to the max length when loading the
  template; the required amount of memory is greater than the size of the
  window definition in the file. Besides, there may be "icons" that only
  have a meaning for the template editor (like icon groups), so that they
  need not be loaded.

* Number of icons in a window
  This is implicitly defined, being included in a window definition block
  (which is equal to a block passed to Wimp_CreateWindow). But the contents
  of this block may change in later versions of the Glass format. I think
  it's necessary to explicitly state where the number of icons can be found.
  (Either in the index or at a fixed position inside the window definition
  block.)

* Indirected data tables
  I have written code to generate template files, but I don't see how the
  extra level of indirection makes it easier. IMO it does have a clear
  disadvantage: when loading the template, the indirected data table causes
  non-contiguous reading of the file, slowing down file access (unless you
  use large buffers, of course.)

* Icon names
  I think this is too flexible, which makes the job of finding the icon
  handle that belongs to a name very complicated. That's probably OK if
  you only use the names to generate a C header file (leaving the work to
  the preprocessor), but for other languages(1) it's less handy. Why not
  restrict the choice for a naming scheme to
  <window name>+"_"+<icon name>? It's fine for SWIs.

  (1) Yes, Basic. It's quite handy for writing not-too-large applications.
      And cheap, too.

* Grouping icons
  A very useful feature to build into a template editor. Is the current
  format flexible enough to accomodate icon groups? It may be necessary to
  add a 1-word prefix to an icon definition block. A value of 1 would
  mean that an ordinary 32-byte icon block follows; a value of 2 indicates
  an icon group (list of icons), 3 for meta-icons etc.

* Quo vadis?
  Wouldn't it be nice if we could have an integrated programming environment,
  in which you can
    (1) design windows, icons and menus,
    (2) write routines that are linked to the icons and menus, and finally
    (3) let the environment build a wimp application from it
  The plans for Glazier are a nice step into the direction of (1); StrongEd
  supports the External Edit protocol so integrating (2) shouldn't be too
  hard (after we have agreement on the data format); for (3) you'd need a set 
  of make utilities, 1 for each programming language that is supported.

Dick Alstein