home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / acorn / tech / 1225 < prev    next >
Encoding:
Internet Message Format  |  1993-01-11  |  3.0 KB
  1. Path: sparky!uunet!cs.utexas.edu!wupost!waikato.ac.nz!aukuni.ac.nz!cs18.cs.aukuni.ac.nz!jwil1
  2. Newsgroups: comp.sys.acorn.tech
  3. Subject: Re: New template format
  4. Message-ID: <1993Jan11.013519.13951@cs.aukuni.ac.nz>
  5. From: jwil1@cs.aukuni.ac.nz (TMOTA)
  6. Date: Mon, 11 Jan 1993 01:35:19 GMT
  7. Sender: jwil1@cs.aukuni.ac.nz (TMOTA)
  8. Organization: Computer Science Dept. University of Auckland
  9. Lines: 49
  10.  
  11. >How should the Glass format handle the fact that you use the text
  12. >of an item leading to a submenu, as that's submenu title, which would
  13. >be very convenient for menus you have multiple inside your menu tree,
  14. >eg. colour selection menus. It's not neccesary to keep them multiple
  15. >inside the glass file, as the only change would be the title name.
  16.  
  17. [aside:
  18.   Well, for a start, throw away your colour selection menu. It was a silly
  19.   idea in the first place, but now that Acorn draws a sprite for ticks
  20.   in menus, the tick is all but guaranteed to be invisible on one colour...
  21.   ;-(
  22.   A colour menu should really be done as a dialogue window with 16 squares
  23.   in it, as some programs are starting to use now... small, simple, and
  24.   far more effective than a tacky stripey menu!
  25. ]
  26.  
  27. If you've read my template format document (posted recently), you may
  28. have noticed that it doesn't handle this case: the reason is that I
  29. personally want a UNIQUE identifier for each menu item in the tree.
  30.  
  31. If you rename just the menu title, then you lose the uniqueness of
  32. identifiers, so you can't say 'colour0 was selected': you have to
  33. refer to it as 'background.colour0', which limits the colour0 item to
  34. lying within a submenu 'background', restricting the way you can redesign
  35. your menu tree without recompiling the main application - this is something
  36. I was hoping to avoid by having a flexible menu template format.
  37.  
  38. Thus, the suggestion was to copy a submenu altering the tags as you go,
  39. to generate a new independent submenu. This means duplication in the menu
  40. tree (but not necessarily in the menu template file), but who cares?
  41. At least the thing can be edited properly.
  42.  
  43. There are also other problems: If GlassRM is going to support wonderful
  44. stuff like tickable item ESG's and proper shading, as well as automatic
  45. window popup, etc, it needs to have a separate copy of every submenu to
  46. store the current state in (I kindof like the idea that you load a menu,
  47. and then can ask about its state at any time, even when the menu is not
  48. open, rather than having to store the state in variables yourself, and
  49. re-write the state into the menu each time it is popped up...).
  50. In this case, you have to have 2 copies of the menu, in order to store
  51. all the state info correctly.
  52.  
  53. Apart from saving a teensy bit of memory (remember that the menu still has
  54. to be duplicated n times in the WIMP menu definition in order to make it
  55. work properly either way), I really can't see any good justification
  56. for doing it your way... but I can see several very good reasons for
  57. separate Glass-menu structures for every active/loaded submenu...
  58. -- 
  59. themasterofthearcanejwil1@cs.aukuni.ac.nzthismessagewassentonrecycledelectrons
  60.