Re: [Denemo-devel] Custom menus

[Richard Shann]

On Thu, 2008-07-03 at 19:54 +0200, Jean-René Reinhard wrote: 
> 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
> ...
> > 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. 
Until now this was true, but the custom command does not have an
ActionEntry, because GtkActionEntries are just a convenience structure
used by the source code to create GtkActions, they do not take any part
in the actual execution of the program once the GtkActions have been
created.

> 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.
To avoid having these different types we should change the current code
to use the GtkActions directly rather than the GtkActionEntries used to
create them. 
> 
> > 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.
This was my first thought - I thought it is ugly to shoehorn other
information into the keymap file. 
> 
> I'd prefer if the keymap could remain just what it is, ie the keymap. It 
> should
> not handle ui stuff.
As you had the same idea, I gave it some more thought:
As I remarked in an earlier mail we have three places in the code where
the action names are mentioned, denemoui.xml, view.c and Default.keymap.
The first of these can mention the same action many times, specifying
which places in the menu system a widget proxying the action should
appear. The second contains the arrays of menu_entries that are used to
construct the actions. The default keymap contains keybindings which the
user wishes to trigger the action.
With the introduction of extra actions post-compile time which are to
persist between evocations of Denemo we need to a store for actions in a
file. The fields in ths file would need to define the action (LilyPond
text, tooltip ...). Then we need the user's keybinding for these actions
to persist, and we could use the current .keymap file for that. In
addition we need the location of the proxies for the action to persist,
so we need to store this on disk. I think it would be difficult to
re-write a local version denemoui.xml to contain this, especially in the
face of updates to the program, and in any case, the gtk ui manager is
strong on handling the merge of ui files, so the solution would be to
write a gtk ui file for additional actions created or downloaded by the
user. This would unfortunately mean that a new action would occupy three
files in a gallery of such items (which could of course be tarred
together). And at the loading stage we would need to separately open and
load keybindings, ui and custom command definitions.
At this point I thought I would go back to the start. The keymap file
can be thought of as storing the user's preferences for actions. At
present, the only preference the user can express is what keybindings he
wants to invoke the action. But in principle he could wish to do other
things
        1) He could add a modifier to an action (such as move to the next
object after executing this command).
        2) He could re-write the tooltip to remind himself of something it took
him a while to figure out. (Using gimp, for example, I have often wished
I could write myself a note about how to use one of the tools when I
have got it figured out.)
        3) He could move the menuitem in the menu system - for example moving
something from the Other category to the toolbar.
        4) He could delete it, (for example to avoid having a longer than
needed menulist).

I know these things are useful, because I have hard-wired all of them in
the code from time to time. (For example, when entering a figured bass I
have arranged that after entering a figure the cursor moves on to the
next note/rest. But no-one has written in the same thing for Lyrics, and
some people might want it when editing notes in Edit mode).

So if we invent a new sort of file, a .action file, say, which can be
used for all this then we achieve a good simplification of the code.
Some actions just refer to a built-in name, and express no preferences,
others can have a keybinding, others a tooltip, still others contain a
definition and a ui.

What I find interesting about this (apart from the fact that I think it
will be very practical) is that it seems to me to be introducing
something new to the way programs are normally designed. I don't have a
name for it.

Richard