home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / acorn / tech / 1179 < prev    next >
Encoding:
Internet Message Format  |  1993-01-07  |  3.1 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.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 discussion document
  4. Message-ID: <1993Jan7.203406.16154@cs.aukuni.ac.nz>
  5. From: jwil1@cs.aukuni.ac.nz (TMOTA)
  6. Date: Thu, 7 Jan 1993 20:34:06 GMT
  7. Sender: jwil1@cs.aukuni.ac.nz (TMOTA)
  8. References: <930101200448@kernow.demon.co.uk> <4897@svin09.info.win.tue.nl> <1993Jan6.113946.4153@gate.esat.kuleuven.ac.be>
  9. Organization: Computer Science Dept. University of Auckland
  10. Lines: 61
  11.  
  12. tytgat@esat.kuleuven.ac.be (John Tytgat) writes:
  13.  
  14. [icon grouping]
  15. >As in Draw, group of icons can be nested.  However, there are certain
  16. >consequences if we are using this approach : the icon numbering could be the
  17. >order of apperance in the list of Icon object definitions.  And this puts a
  18. >restriction on grouping/ungrouping because this action can change the order
  19. >of the icon object definition block.
  20.  
  21. >This restriction does not apply for the programmer because (s)he only needs
  22. >to remake the #define file but that's no solution for the user.
  23.  
  24. NO! You *must* use *tags* for icons! We use messagetrans tags for text, and
  25. tags for window names, and we intend to have tags for menu entries, so why
  26. leave this stupid icon-number thing in place?
  27.  
  28. Icons *should* be tagged so that they can be moved/grouped/edited wothout
  29. changing the references inside the program: This is for 2 reasons:
  30.   1) Users then wouldn't be able to freely edit templates
  31.   2) It's a pain in the bum for the programmer, no matter how automated
  32.      your system for spewing out header files is.
  33.  
  34. If you are really concerned about icon tags taking up a lot of sapce, then
  35. I suggest that icon tags are either:
  36.   * 8 bytes of text, or
  37.   * 4 bytes of text/an integer.
  38.  
  39. It would be fine to use sequential numbers as tags, so long as once a number
  40. is assigned to an icon, it is not renumbered by any change of position...
  41.  
  42. >Maybe we should give each icon its own explicit number ?
  43.  
  44. Yup... Note also, though, that using a 4-byte number, we can also use
  45. numbers with weird 'values' such as:
  46.  
  47.   Wimp_GetIconInfo(mainwindow, 'ICok',...)
  48.  
  49. rather than just
  50.   Wimp_GetIconInfo(mainwindow, 34, ...)
  51.  
  52. ...which is more convenient ...
  53.  
  54.  
  55. >Yes, it would.  What about defining the menu format in the Glass file ?
  56.  
  57. Already a proposition put forward. This would define menu entries and
  58. build menus from them. Each menu entry is tagged and contains some msgtransed
  59. text (e.g. the 'quit' item might contain the text 'Quit'). The support code
  60. will support extra stuff like ESG groups for tickable items, and proper
  61. handling of stuff like shading icons (shade an item with a submenu link
  62. and the submenu will still appear, only shaded, as in Acorn's Style Guide)
  63.  
  64. This will also allow users to edit the menu layout completely, i.e. move
  65. 'quit' into a submenu so that it's actually main -> go away -> die -> quit
  66. and the main program will still quite happily quit when 'quit' is selected.
  67.  
  68. A mechanism would also ve included for automatically handling hotkeys for
  69. a menu item, so the user can change most of the key-bindings as well.
  70.  
  71. -- 
  72. themasterofthearcanejwil1@cs.aukuni.ac.nzthismessagewassentonrecycledelectrons
  73.