🚀 go-pugleaf

>How should the Glass format handle the fact that you use the text
>of an item leading to a submenu, as that's submenu title, which would
>be very convenient for menus you have multiple inside your menu tree,
>eg. colour selection menus. It's not neccesary to keep them multiple
>inside the glass file, as the only change would be the title name.

[aside:
  Well, for a start, throw away your colour selection menu. It was a silly
  idea in the first place, but now that Acorn draws a sprite for ticks
  in menus, the tick is all but guaranteed to be invisible on one colour...
  ;-(
  A colour menu should really be done as a dialogue window with 16 squares
  in it, as some programs are starting to use now... small, simple, and
  far more effective than a tacky stripey menu!
]

If you've read my template format document (posted recently), you may
have noticed that it doesn't handle this case: the reason is that I
personally want a UNIQUE identifier for each menu item in the tree.

If you rename just the menu title, then you lose the uniqueness of
identifiers, so you can't say 'colour0 was selected': you have to
refer to it as 'background.colour0', which limits the colour0 item to
lying within a submenu 'background', restricting the way you can redesign
your menu tree without recompiling the main application - this is something
I was hoping to avoid by having a flexible menu template format.

Thus, the suggestion was to copy a submenu altering the tags as you go,
to generate a new independent submenu. This means duplication in the menu
tree (but not necessarily in the menu template file), but who cares?
At least the thing can be edited properly.

There are also other problems: If GlassRM is going to support wonderful
stuff like tickable item ESG's and proper shading, as well as automatic
window popup, etc, it needs to have a separate copy of every submenu to
store the current state in (I kindof like the idea that you load a menu,
and then can ask about its state at any time, even when the menu is not
open, rather than having to store the state in variables yourself, and
re-write the state into the menu each time it is popped up...).
In this case, you have to have 2 copies of the menu, in order to store
all the state info correctly.

Apart from saving a teensy bit of memory (remember that the menu still has
to be duplicated n times in the WIMP menu definition in order to make it
work properly either way), I really can't see any good justification
for doing it your way... but I can see several very good reasons for
separate Glass-menu structures for every active/loaded submenu...
-- 
themasterofthearcanejwil1@cs.aukuni.ac.nzthismessagewassentonrecycledelectrons