Re: [Denemo-devel] Custom menus

[Richard Shann]

On Fri, 2008-07-04 at 18:29 +0100, Richard Shann wrote:
> 
> 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).
This could be a useful place to discuss macros. If we allowed users to
define one keypress as a sequence of others then a lot of possibilities
become available. (The one mentioned above, namely "move to the next
note or rest" does not, as it happens, have an action defined for it as
yet, there is just "cursor right", which moves to the next object: this
should prove a spur to providing a good set of basic actions).
As before we would want to store these which could be done as (for
example)
<row>
        <macro>KP_0<\macro>
        <action>InsertLyric<\action>
        <action>CursorRight<\action>
<\row>

That is, the keypress would be associated with a sequence of actions,
rather than with the keypresses of those actions (so that changing a
keybinding of an action that is one step in a macro would not change the
semantics of the macro).
In the Manage Keybindings Dialog we would be able to set up the macros
which could appear as commands in the first column with names, say

Macro KP_O

etc and would display the sequence of actions in the second column.
This would be a fair bit of work, though quite straightforward to do.

The implementation could perhaps usefully avoid running the
displayhelper() routine until the macro finishes (it is normally added
to the callback of each function - it updates the display). We would
probably need a classification scheme for actions (there is a field in
the original structure, now in generate_source.c for classifying
actions) to know which actions modify the display, change the file etc.
This would be needed to know whether to run displayhelper(), etc.

Richard