home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / acorn / tech / 1157 < prev    next >
Encoding:
Internet Message Format  |  1993-01-05  |  4.0 KB
  1. Path: sparky!uunet!pipex!bnr.co.uk!uknet!mcsun!sun4nl!tuegate.tue.nl!svin09!wsintt05!wsinda
  2. From: wsinda@wsintt05.info.win.tue.nl (Dick Alstein)
  3. Newsgroups: comp.sys.acorn.tech
  4. Subject: Re: New Template format discussion document
  5. Message-ID: <4897@svin09.info.win.tue.nl>
  6. Date: 5 Jan 93 10:58:10 GMT
  7. References: <930101200448@kernow.demon.co.uk>
  8. Sender: news@svin09.info.win.tue.nl
  9. Reply-To: wsinda@info.win.tue.nl
  10. Lines: 74
  11.  
  12.  
  13. > By 'absence of action by Acorn', I mean that when I asked for a filetype
  14. > to do this, no-one at Acorn said "Hang on, we're about to do something like
  15. > that!", and, as I assume this is half the point of Acorn being the
  16. > organisation that allocates filetypes, I guess nothing is happening soon.
  17.  
  18. I heard that Acorn are working on it, but it's probably going to be just the 
  19. addition of icon names, and they're (sigh) added to the validation string.
  20.  
  21. > As mentioned, the file will be a chunk file as specified in the Acorn C
  22. > manuals. [...] If anyone doesn't have access to it I'm sure myself or
  23. > someone else could outline the format if necessary.
  24.  
  25. Yes, please.
  26.  
  27. [Long proposal for file format deleted; read the original posting]
  28.  
  29. * Estimating memory requirements
  30.   With the current format definition, it's not easy to estimate the memory
  31.   requirements for a set of templates. The problem is mainly with writable
  32.   icons: in the file, there is only space for the actual contents of the
  33.   icon; an empy string takes 1 byte; when you create the window, the user
  34.   is able to edit the string, and fill it to the maximum length. Therefore,
  35.   you have to allocate extra space up to the max length when loading the
  36.   template; the required amount of memory is greater than the size of the
  37.   window definition in the file. Besides, there may be "icons" that only
  38.   have a meaning for the template editor (like icon groups), so that they
  39.   need not be loaded.
  40.  
  41. * Number of icons in a window
  42.   This is implicitly defined, being included in a window definition block
  43.   (which is equal to a block passed to Wimp_CreateWindow). But the contents
  44.   of this block may change in later versions of the Glass format. I think
  45.   it's necessary to explicitly state where the number of icons can be found.
  46.   (Either in the index or at a fixed position inside the window definition
  47.   block.)
  48.  
  49. * Indirected data tables
  50.   I have written code to generate template files, but I don't see how the
  51.   extra level of indirection makes it easier. IMO it does have a clear
  52.   disadvantage: when loading the template, the indirected data table causes
  53.   non-contiguous reading of the file, slowing down file access (unless you
  54.   use large buffers, of course.)
  55.  
  56. * Icon names
  57.   I think this is too flexible, which makes the job of finding the icon
  58.   handle that belongs to a name very complicated. That's probably OK if
  59.   you only use the names to generate a C header file (leaving the work to
  60.   the preprocessor), but for other languages(1) it's less handy. Why not
  61.   restrict the choice for a naming scheme to
  62.   <window name>+"_"+<icon name>? It's fine for SWIs.
  63.  
  64.   (1) Yes, Basic. It's quite handy for writing not-too-large applications.
  65.       And cheap, too.
  66.  
  67. * Grouping icons
  68.   A very useful feature to build into a template editor. Is the current
  69.   format flexible enough to accomodate icon groups? It may be necessary to
  70.   add a 1-word prefix to an icon definition block. A value of 1 would
  71.   mean that an ordinary 32-byte icon block follows; a value of 2 indicates
  72.   an icon group (list of icons), 3 for meta-icons etc.
  73.  
  74. * Quo vadis?
  75.   Wouldn't it be nice if we could have an integrated programming environment,
  76.   in which you can
  77.     (1) design windows, icons and menus,
  78.     (2) write routines that are linked to the icons and menus, and finally
  79.     (3) let the environment build a wimp application from it
  80.   The plans for Glazier are a nice step into the direction of (1); StrongEd
  81.   supports the External Edit protocol so integrating (2) shouldn't be too
  82.   hard (after we have agreement on the data format); for (3) you'd need a set 
  83.   of make utilities, 1 for each programming language that is supported.
  84.  
  85. Dick Alstein
  86.