home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / acorn / tech / 1175 < prev    next >
Encoding:
Internet Message Format  |  1993-01-07  |  2.5 KB
  1. Path: sparky!uunet!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: <4926@svin09.info.win.tue.nl>
  6. Date: 7 Jan 93 14:22:48 GMT
  7. References: <930101200448@kernow.demon.co.uk> <4897@svin09.info.win.tue.nl> <1993Jan6.113946.4153@gate.esat.kuleuven.ac.be>
  8. Sender: news@svin09.info.win.tue.nl
  9. Reply-To: wsinda@info.win.tue.nl
  10. Lines: 39
  11.  
  12. tytgat@esat.kuleuven.ac.be (John Tytgat) writes:
  13.  
  14. >In article <4897@svin09.info.win.tue.nl> wsinda@info.win.tue.nl writes:
  15. >>* Grouping icons
  16. >Very good idea.  But maybe we can have a look at the way Draw stores grouped
  17. >objects.  I think we can adopt the same way, something like : [...]
  18. >
  19. >As in Draw, group of icons can be nested.  However, there are certain
  20. >consequences if we are using this approach : the icon numbering could be the
  21. >order of apperance in the list of Icon object definitions.  And this puts a
  22. >restriction on grouping/ungrouping because this action can change the order
  23. >of the icon object definition block.
  24. >This restriction does not apply for the programmer because (s)he only needs
  25. >to remake the #define file but that's no solution for the user.
  26.  
  27. Doing icon grouping as in !Draw has the advantage that it enforces a proper
  28. nesting (if two groups have objects in common, then one group must be a part of 
  29. the other). However, in Draw files, objects are self-contained (except for
  30. font handles, I think); all data needed to render an object can be found inside 
  31. the definition block. IMO, it would be best to split the Indirected Data tables
  32. and attach the data for each icon to the icon definition block. 
  33.  
  34. A consequence is that you are limited in how icons overlap: if icon A overlaps 
  35. icon B, then all icons in the same group as A overlap B. But I think that's not 
  36. a big restriction.
  37.  
  38. Another (logical) consequence is that you have to hide the icon numbers from
  39. the programmer; if the grouping changes, then the order of the icon definitions 
  40. in the file may change completely; hence icon numbers are very "unstable", and 
  41. the programmer should only refer to icons by their names.
  42.  
  43. >What about defining the menu format in the Glass file ?
  44.  
  45. Looking at Olaf Krumnow's proposal, it wouldn't be much of a problem to define 
  46. it. But, as Tim Browse wrote in his original posting, it's best to start with
  47. a minimal definition, and extend the format when someone is seriously thinking
  48. of writing a program (i.e. a Glass editor) that actually uses the extension.
  49.  
  50. Dick
  51.