Re: [Denemo-devel] Custom menus

[Jean-René Reinhard]

Le Mon, Jun 30, 2008 at 06:13:59PM +0100, Richard Shann écrivait:
> 
> 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.
> 

The different command type have been introduced to handle different
GtkActionEntries type. The semantics of the commands are not involved. If there
had been a single ActionEntry type, this would not have been needed. If you
intend to use ActionEntry or RadioActionEntry, then you don't have to add
KeymapLilyPondAction or KeymapModeAction. KeymapEntry and KeymapRadioEntry are
sufficient.

> 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>

I'm not sure the keymap to be the right place for this information. A
curstom-menu file would be cleaner.

I'd prefer if the keymap could remain just what it is, ie the keymap. It should
not handle ui stuff.

> 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
> 
> 
> 
> _______________________________________________
> Denemo-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/denemo-devel

Jean-René