🚀 go-pugleaf

okrumnow@mcshh.Hanse.DE (Olaf Krumnow) writes:

>I've been thinking about named menu items quite a while since it is easier to
>write programs reacting to a menu selection "QUIT" instead of "item no. 3".
>This is especially true when you insert a new menu item ... renumber!
>The SWI Wimp_DecodeMenu is not worth alot if you want to write applications
>using the MessageTrans module for internationalisation.

...not to mention that DecodeMenu never seems to work properly with
indirected menu items (fixed in RO3.10?)

>In my solution I decided that each menu item has a tag which
>- is the tag for the MessageTrans module, i.e. the text displayed is
>  read from the message file.
>- gives the item a name you can use in the program.

Well, the idea with Glazier is to suply an editor, a file format, and also
som code libraries to support the new formats. Thus, we can get *right*
away from standard menu definitions for the file format, and supply code
to handle menu-template loading for you.

Things that the menu template system should provide:
 * Tagged menu items so that menu action is unrelated to the text displayed
   in an item, and also to the position of the item in the menu tree.
   (i.e. the user can move 'quit' from the main menu onto another menu
    so that it is now 4 submenus deep, and it should still work)
 * Automaytic handling by the support code of creating menus when required.
   By mixing and matching tagged menu items, you can build different menus
   from pre-defined items (so you can add/delete items as necessary)
 * Automatic creation/addition of submenus/ssubwindows
 * support for creation of menus such as are made on the fly (e.g. font list)
 * support for 'tickable' menu items, with ESG groups.
 * support for proper shading of items and submenus
   (i.e. if an item with a submenu off it is shaded, the submenu should
   still pop up, only be totally shaded, as in Acorn Style Guide)
 * support for a keypress handler that will act as if a menu selection jhas
   been made for certain keypresses: These key bindings are user-editable.
 * While we're at it, a proper key-binding scjheme, so ALL key bindings
   for the entire application can be edited.

This will differ significantly from Wimp menu structures on disc, but can
be quite efficiently stored and converted into menu structures on the fly.
(I've already done it, and it works)

This allows total control of the menu interface from !Glazier.

The easiest way I can see to handle menu decoding is that in your event handler
you place calls to predefined functions whenever you get a menu hit or
keypress event you can't handle:

  menutag = DecodeMenu(event_block);
  if (menutag != NULL)
    ActionAMenuChoice(menutag);

...so the DecodeMenu function will decode what the click meant, and pass
back a tag 'quit' 'info' etc. to indicate which item was selected. (It can
of course, weed out clicks on pseudo-shaded items and tickable items
if you don't want ot know about them).

For keypresses, the same thing:

  menutag = DecodeKeyPress(event_block);
  if (menutag != NULL)
    ActionAMenuItem(menutag);

...the function ActionAMenuItem() is a user function with a switch statement
in it which decodes the tag and takes appropriate action.

NOTE that I'm only using 1 tag here, because unless every menu item has a
unique tag, you lose position independance: You shouldn't specify a
tag as menu.submenu.item unless you really have to, or it locks the user
into having to leave that item in that submenu...

>- The level where the selection occured.
>- A pointer to the item in the menu structure (e.g. for setting the tag).
>Menu items without tags are given numeric names 0000, 0001, ....

Nope... just provide calls to alter the state of the current menu.

>The path is not stored as a long string but as an array of item names. Nor-

Nope. As I mentioned above, a path is a bad thing. It should be available,
but where possible, you should only use a unique item identifier for the
final selected menu item, so as to make the menu as editable as possible.

>I didn't give the menu itself a name. Basically since there is only one active
>at one time anyhow; so what for? On the other hand each sub menu is a menu
>as well leading to the question: 'shall sub menus have names'. If this is

Yes. Every menu has a tag. Every item has a tag. A menu consists of a list
of items. Items can contain references to window tags and menu tags. for
submenus...

>I'm neither into using the RiscOsLib nor the DeskLib - I stick to the GagLib
>(the C library being written by Olaf Krumnow and me, GAG being the abbrevia-
>tion of German Archimedes Group). Therefore it would be nice to be able to
>implement Glazier-Templates in our libray as well. Perhaps you or someone
>else could write a module to offer Gazier_Template-SWIs as replacement of
>the Wimp_Template-SWIs which load them in memory in a decent way, i.e. so
>that the program can start using them right away and not as e.h. with normal
>templates has to get storage for the indirected buffers ...

Well, the way I planned to implement my menu code before !Glazier came into
the scene, is totally unreliant on any library structure, so can be easily
added on top of the library. But abyway, it shouldn't take much work
on your part to include our source code into your own library...
-- 
themasterofthearcanejwil1@cs.aukuni.ac.nzthismessagewassentonrecycledelectrons