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

Cheers,
Jean-René Reinhard




reply via email to

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