home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / acorn / tech / 1191 < prev    next >
Encoding:
Text File  |  1993-01-08  |  4.7 KB  |  107 lines
  1. Newsgroups: comp.sys.acorn.tech
  2. Path: sparky!uunet!mcsun!ub4b!news.cs.kuleuven.ac.be!gate!lorca!tytgat
  3. From: tytgat@esat.kuleuven.ac.be (John Tytgat)
  4. Subject: Re: New Template format discussion document
  5. Message-ID: <1993Jan8.113649.10579@gate.esat.kuleuven.ac.be>
  6. Originator: tytgat@lorca
  7. Sender: tytgat@esat.kuleuven.ac.be (John Tytgat)
  8. Reply-To: tytgat@esat.kuleuven.ac.be (John Tytgat)
  9. Organization: K.U.Leuven, Belgium
  10. References: <4897@svin09.info.win.tue.nl> <1993Jan6.113946.4153@gate.esat.kuleuven.ac.be> <1993Jan7.203406.16154@cs.aukuni.ac.nz>
  11. Date: Fri, 8 Jan 1993 11:36:49 GMT
  12. Lines: 93
  13.  
  14. jwil1@cs.aukuni.ac.nz (TMOTA) writes:
  15.  
  16. > NO! You *must* use *tags* for icons! We use messagetrans tags for text, and
  17. > tags for window names, and we intend to have tags for menu entries, so why
  18. > leave this stupid icon-number thing in place?
  19.  
  20. I agree that using tags for icons is a good idea.  But if you are only using
  21. tags for referring icons you lose information about the icon overlap (Dick
  22. Alstein also noticed this).  This is eg. very important when you are using
  23. certain 3D icons.
  24.  
  25. Therefore I suggested to include also an icon-number together with each
  26. icon definition.  This icon-number is in fact totally invisible for the
  27. Glass editor user and will define the icon order in the window definition.
  28.  
  29. If the user wants to move an icon to the front/back, he can simply choose
  30. '<' or '>' icons (like in ArtWorks) and internally this results in an
  31. icon-number renumbering.  Note that this icon-number is *not* being used in
  32. the program to determine a certain icon (we use iconnames for this), but only
  33. when building up the window definition for Wimp_CreateWindow.
  34.  
  35. This system allows the user to move the icons.  However, when we want to
  36. allow user to create new icons or to delete icons (do we want that ?), an
  37. icon renumbering has to happen, so we're back to point zero.
  38.  
  39. Maybe a better way could be : if there is an icon which has to be absolute in
  40. front of certain other icons, it can have a list of their icon names somewhere
  41. in this icon definition.
  42.  
  43. I think the latter is the most flexible one, but maybe not simpliest to deal
  44. with.  Opinions, please.
  45.  
  46. > If you are really concerned about icon tags taking up a lot of sapce, then
  47. > I suggest that icon tags are either:
  48. >   * 8 bytes of text, or
  49. >   * 4 bytes of text/an integer.
  50.  
  51. I never said I was concerned about space (although not in this discussion ;-)).
  52.  
  53. wsinda@wsintt05.info.win.tue.nl (Dick Alstein) wrote:
  54.  
  55. > Doing icon grouping as in !Draw has the advantage that it enforces a proper
  56. > nesting (if two groups have objects in common, then one group must be a part
  57. > of the other). However, in Draw files, objects are self-contained (except for
  58. > font handles, I think); all data needed to render an object can be found
  59. > inside the definition block. IMO, it would be best to split the Indirected
  60. > Data tables and attach the data for each icon to the icon definition block. 
  61.  
  62. Why is it so important to make self-contained icon objects ? Would the split
  63. of the Indirected Data tables make reading/writing Glass files not more
  64. difficult ?
  65.  
  66. > A consequence is that you are limited in how icons overlap: if icon A
  67. > overlaps icon B, then all icons in the same group as A overlap B. But I
  68. > think that's not a big restriction.
  69.  
  70. On the contrary, I think it *is* a big restriction (see above).
  71.  
  72. > Another (logical) consequence is that you have to hide the icon numbers from
  73. > the programmer; if the grouping changes, then the order of the icon
  74. > definitions in the file may change completely; hence icon numbers are very
  75. > "unstable", and the programmer should only refer to icons by their names.
  76.  
  77. Agreed.
  78.  
  79. jwil1@cs.aukuni.ac.nz (TMOTA) writes:
  80.  
  81. > In DSEdit, I have no default text in my application. This is simply because
  82. > the messages file is so absolutely mindbogglingly important that there is
  83. > no point in even trying to run without it... As the text for all interactions
  84. > and the menus are messagetransed, I can't really see any point in defaults
  85. > most of the time...
  86.  
  87. Neither can I.
  88.  
  89. > I would say the easiest way is to specify a bit which indicates that the
  90. > text is actually a tag, and then in the application-side support code that
  91. > is supplied with the template editor, put in a method by which these
  92. > text items can be 'expanded'. Off the top of my head, I'd say a nice way to
  93. > approach this might be to register a messagetrans decoding function with
  94. > the support code, so it calls some user-defined function, passing in the
  95. > tag, and gets back a pointer to the actual string...
  96.  
  97. Not such a bad idea.
  98.  
  99. Another point I would like to raise is : are we going to support Acorn's
  100. Help application by defining a help string in each window/icon and menu entry
  101. (it should also be language independant) ?
  102.  
  103. John
  104. tytgat@esat.kuleuven.ac.be
  105. BASS
  106.  
  107.