denemo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Denemo-devel] Re: Denemo-devel: Key bindings


From: Richard Shann
Subject: [Denemo-devel] Re: Denemo-devel: Key bindings
Date: Sat, 10 May 2008 20:57:08 +0100

On Sat, 2008-05-10 at 18:30 +0200, Jean-René Reinhard wrote:
> On Sat, May 10, 2008 at 04:04:28PM +0100, Richard Shann wrote:
> > key_diff.txt patch:
> > 
> > I didn't manage to get it to patch automatically, but have it working -
> > thanks. There is another place where keypresses are being examined (in
> > the LilyPond editor stuff in exportlilypond.c) where something similar
> > will probably be needed.
> > I used the patched program to fix the accel Shift++ in standard.accels
> > and have checked the files in to CVS.
> 
> Yes, and I think there is another place in the keybinding editor too...
> 
> > All this talk of keybindings reminds me that there is (or was?) a
> > mechanism for switching keybindings when doing pitch recognition. This
> > will be obsolete, since we have gone over to accelerators since then.
> > 
> > Also, the menued and unmenued commands became obsolete when I put *all*
> > actions into the menu system as an effort to make things simpler and
> > provide a simple method of defining shortcuts. I had thought that
> > perhaps no-one would want aliases, and we could simply drop all the old
> > code, but as not all keypresses can be accelerators, this will not be
> > possible. Nevertheless, I still hoped that all that stuff where the
> > menu_actions structure is shared between view.c and kbd-custom.c etc
> > could go if we just set up an alias scheme where aliases are paired with
> > accelerators. So all you would need to store is pairs of keypresses. Are
> > you seeing a need for more than this (e.g. for detecting already
> > assigned keypresses?).
> > 
> 
> Well, it's just cleaner, isn't it? 

That for me is the crucial question. If we end up with three files in
which actions are named (denemoui.xml, standard.accels, denemo.keymaprc)
this doesn't seem attractive.

> The other problem remaining is that the
> parser of keymaprc relies on the label of actions to determine actions instead
> of actions name. I don't think it is necessary to internationalize this file,
> since it makes packaging a more difficult task. Since there are some issues
> left, I thought it was fun to rewrite it.
> 
> I've gone through the code, and found that the interface to the keymap can
> almost be left as it is. 
??? by interface to the keymap you surely do not mean the one found
under Edit->Keyboard Setup->Extra Keybindings
where you trawl down a seemingly endless list of functions looking for
what you want.
??? you must be referring to something else... reading below, I think
you must mean the way the keybindings are stored and retrieved?

> Some improvements possible :
> - move the denemo_command into the key map. No need to keep this global
>   variable, when all the info could be stored in the keymap
> - store the GtkActionEntry into the keymap.
> - add some accessors, like lookup_keybinding_by_command, return the list of
>   keybinding for a specific command.
> 
> The major improvement I'd like to achieve is to have an unified keymaprc 
> dealing
> with all keybindings.
Would you set the accelerators by parsing that keymap and calling
gtk_accel_map_change_entry()? (It would be nice to keep the left cursor
move showing the "Left" as accelerator on the menu item, even though it
will have to be an alias, since people will look up the menu Cursor to
find it).

On a related topic, I wonder if you could enlighten me on something that
I haven't understood? Why do the accelerators work on the "main" denemo
window, but do not apply to other windows that Denemo opens: what
singles out the "main" window? If I wanted to create accelerators in the
LilyPond text window where would they go? (It may be something to do
with this that caused me to create two hierarchies of menus in
denemoui.xml, the second for the LilyPond text window).
Cheers,
Richard









reply via email to

[Prev in Thread] Current Thread [Next in Thread]