🚀 go-pugleaf

tytgat@esat.kuleuven.ac.be (John Tytgat) writes:

[icon grouping]
>As in Draw, group of icons can be nested.  However, there are certain
>consequences if we are using this approach : the icon numbering could be the
>order of apperance in the list of Icon object definitions.  And this puts a
>restriction on grouping/ungrouping because this action can change the order
>of the icon object definition block.

>This restriction does not apply for the programmer because (s)he only needs
>to remake the #define file but that's no solution for the user.

NO! You *must* use *tags* for icons! We use messagetrans tags for text, and
tags for window names, and we intend to have tags for menu entries, so why
leave this stupid icon-number thing in place?

Icons *should* be tagged so that they can be moved/grouped/edited wothout
changing the references inside the program: This is for 2 reasons:
  1) Users then wouldn't be able to freely edit templates
  2) It's a pain in the bum for the programmer, no matter how automated
     your system for spewing out header files is.

If you are really concerned about icon tags taking up a lot of sapce, then
I suggest that icon tags are either:
  * 8 bytes of text, or
  * 4 bytes of text/an integer.

It would be fine to use sequential numbers as tags, so long as once a number
is assigned to an icon, it is not renumbered by any change of position...

>Maybe we should give each icon its own explicit number ?

Yup... Note also, though, that using a 4-byte number, we can also use
numbers with weird 'values' such as:

  Wimp_GetIconInfo(mainwindow, 'ICok',...)

rather than just
  Wimp_GetIconInfo(mainwindow, 34, ...)

...which is more convenient ...


>Yes, it would.  What about defining the menu format in the Glass file ?

Already a proposition put forward. This would define menu entries and
build menus from them. Each menu entry is tagged and contains some msgtransed
text (e.g. the 'quit' item might contain the text 'Quit'). The support code
will support extra stuff like ESG groups for tickable items, and proper
handling of stuff like shading icons (shade an item with a submenu link
and the submenu will still appear, only shaded, as in Acorn's Style Guide)

This will also allow users to edit the menu layout completely, i.e. move
'quit' into a submenu so that it's actually main -> go away -> die -> quit
and the main program will still quite happily quit when 'quit' is selected.

A mechanism would also ve included for automatically handling hotkeys for
a menu item, so the user can change most of the key-bindings as well.

-- 
themasterofthearcanejwil1@cs.aukuni.ac.nzthismessagewassentonrecycledelectrons