[Top][All Lists]

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

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

From: Jean-René Reinhard
Subject: [Denemo-devel] Re: Denemo-devel: Key bindings
Date: Sat, 10 May 2008 18:30:15 +0200
User-agent: Mutt/1.5.11+cvs20060126

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

> Another topic:
> For those who want a non-modal program we do not provide a set of
> keybindings at present - that would be a sensible point to switch sets
> of accelerators (ie if someone has a preference->non-modal set then the
> mode switches are not shown and another set of keybindings are active).

This could be done by loading an alternative keymap file, probably...

> Thanks again for your most useful patch,
> Richard

Jean-René Reinhard

reply via email to

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