denemo-devel
[Top][All Lists]
Advanced

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

[Denemo-devel] Menu system and keyboard shortcuts


From: Richard Shann
Subject: [Denemo-devel] Menu system and keyboard shortcuts
Date: Mon, 15 Oct 2007 14:53:34 +0100

If denemo was more freindly to people who are just giving the program a
quick try, I think it might gain a sizeable user base and hence
developers.
In particular, I think that if the menu system allows newcomers to
access denemo without having to read and memorize/print out keybindings
from the outset then we will draw in users, and hopefully developers. It
could do this by 
        1) being logically arranged, e.g. all commands that insert something
under one menu, or all the commands affecting notes on one menu.
        2) having the keybinding visible on the menu element concerned.
        3) having an explanation of the menu elements available on the menu
element
        4) having the keybindings be editable on the menu element
        5) having all the commands available via the menu system.

Point 5 is there not with the idea that someone will want to operate the
program by selecting a menu item every time they want to, say, sharpen a
note, but with the idea that given a logical hierarchy of menus, someone
will be able to navigate their way to the sharpen-a-note menu item and
see what the keyboard shortcut for it is (and indeed re-define it if
they wish). In fact, someone might tear off the menu with the
sharpen-a-note menuitem on it and keep it on the screen, either for
clicking on, or to remind them of the keypress needed. (To this end I
have set all menus to have tear-offs).

For example, when you have navigated to, say, Insert->note->A you will
see the keyboard shortcuts a, b, c,... for the notes and know that you
can just press these keys in future to insert the notes.

Besides making denemo more approachable, going over to using menu
accelerators (as these keyboard shortcuts are called in gtk) will
simplify our codebase. The files keyboard.c, kbd-custom.c,
keyresponses.c, kbd-interface.c can all go, to be replaced by a modest
piece of code that attaches a callback that is invoked by right clicking
any menu item. The callback can both explain what the menu item is for
and offer to edit (& save) the keyboard shortcut. The code for
loading/saving accelerator keyboard shortcuts is built into gtk.
The files that will get bigger are denemoui.xml which will have menu
items for everything and more menu_entries in view.c.

Note that it seems you can only have one accelerator per menuitem, so if
there were a positive requirement to have more than one keypress to
activate one function we would need to generate additional menuitems
with the same callbacks. Alternatively, we could make an alias scheme
with the keypresses being intercepted and translated.

One of the nice things about the gtkaction stuff that denemo is using is
that it allows proxies for menuitems. This means that our modal program
can cope with keyboard accelerators meaning different things in
different modes rather elegantly. For example in Insert Mode the
callback that inserts/edits a notename can appear in an Insert menu,
while in Edit Mode it can appear in an Edit menu. This could be done by
inserting proxies for the action in the two places and hiding one or
other of them. As I say this is needed because we have a modal program,
so that the same keypress means different things in different modes. It
also means that those who dislike modal programs can choose separate
keybindings for edit notename and insert notename and make denemo
modeless. This will require a bit of unpacking of some functions -
mainly shiftcursor which at present does different things depending on
mode (or, even simpler, a bit of wrapping, as in surrounding shiftcursor
with switch to and from insert/edit mode as required).

Comments please.
Richard 







reply via email to

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