Re: [Denemo-devel] Custom menus

[Richard Shann]

Below is a design for how to incorporate custom lilypond-insert menus
into Denemo, based on Jean-Rene`s code managing the keybindings.
What is described is the basic building block, an on-line gallery of
useful thumbnailed LilyPond directives contributed by users would be a
final goal.
This is for 0.8.0 and I would like to start soon!

Design for including custom LilyPond insertion actions into Denemo.

The simple case of inserting a fixed LilyPond string is described here.
The basic idea is that we can include custom commands in the keymap
file, which define an action name, label, location in the menu system,
tooltip, keybinding,
and which when the keymap is loaded causes the menu item to be inserted
and the command to appear in the command store (keymap->commands).
Activation is a callback to the function that inserts the LilyPond
directive.
To achieve this I propose to expand the 
typedef enum
{
        KeymapEntry,
        KeymapToggleEntry,
        KeymapRadioEntry,
        KeymapLilyPondAction,
        KeymapModeAction
}KeymapCommandType;

to include LilyPond and Mode command types (the COL_ENTRY column for
KeymapLilyPondEntry will be a  GtkAction*
while for KeymapModeEntry they will be GtkRadioAction* rather than a
GtkActionEntry*
I'll omit further details on how the KeymapModeAction type will work for
now.

In save_keymap we save extra fields in each <row> which is found to have
the type KeymapLilyPondEntry
the fields saved in this case are <type>, <tooltip>, <label>,
<lilypond>, <location>

In load keymap at parseBinding (rename this to parseAction) we parse the
<type> and for
type KeymapLilyPondEntry instead of lookup_index_from_name we create the
GtkAction (which will shortly have tooltip, label and lilypond fields
attached) and register it - essentially this is the add_favorite
function I have already prototyped (in view.c). We also parse the
location and insert the menuitem in the menu system.
The tooltip etc which we attach to the action are now parsed as well,
and attached to the action.

Then the code continues as a present.
When looking up the type, we have extra cases, e.g. in kbd-custom.c as
well as

          case KeymapEntry:
              names[i] = ((GtkActionEntry *) entry)->name;
              break;
etc we have

          case KeymapLilyPondAction:
              names[i] = g_object_get_data(entry, "name");
//note: we could use
gtk_action_get_name(GTK_ACTION(entry)); but this would create a copy of
the name, whereas the others are just references
              break;

another example is
      case KeymapEntry:
          f = (((GtkActionEntry *) row.entry)->callback);
          if (!f) {
            res = FALSE;
          }
          break;
which has the extra case
      case KeymapLilyPondAction:
          f = myactivate;
          break;
where myactivate is the name of the function attached to the action in
the add_favorite routine (this name will need to be something sensible,
to do with the fact that it is a custom lilypond activation).

at the end of the load, if we have registered new commands we re-sort
the list using the end_register function.

That is all there is to it, I think.
comments please - particularly are there internationalization issues
which I don't understand?
Richard