[Geany-devel] Resetting menu accels - Re: Super modifier in keybindings - Re: Strange Geany behavior

Lex Trotman elextr at xxxxx
Fri Aug 14 01:59:27 UTC 2009


2009/8/14 Enrico Tröger <enrico.troeger at uvena.de>:
> On Thu, 13 Aug 2009 17:35:52 +0100, Nick wrote:
>
>>On Thu, 13 Aug 2009 08:32:48 +1000
>>Lex Trotman <elextr at gmail.com> wrote:
>>
>>> >> I hope that you havn't violated the "good GUI guidelines" by
>>> >> having functionality that is only available via keybindings and
>>> >> not by menu ;-)
>>> >
>>> > We have. Probably we could/should add some matching menu items,
>>> > and IIUC use the relevant widget for the focus commands. There are
>>> > some special cases though where some keybindings take precedence,
>>> > so I don't think we can simplify the code that much.
>>>
>>> Adding menu items is worth while from a user point of view even if it
>>> doesn't improve the code.
>>>
>>> I for one am unlikely to find functionality that is *only* available
>>> from keybindings since that would require reading and remembering the
>>> manual (unlikely ;-) or reading the keybindings (which is also
>>> unlikely).  Whereas searching the menus has a long and honourable?
>>> tradition.
>>
>>I agree.
>
> Not sure whether I do.
> In general, you are right. "Hiding" functionality only in keybindings
> is not the best way. But OTOH adding tons of new menu items just to
> have them is also not the smartest way, I think.
> IIRC one of the reasons not adding menu items for each single possible
> keybinding was to not clutter and bloat the menus too much, And IMO
> this is still true and still important.
>

Yes, its a personal judgement call and no two people will totally agree :-)
Having looked at the keybindings in detail I agree that some of them
don't make sense as menu items, particularly the following areas:
Snippets & completion
Scrolling
Focus
Notebook Tabs
Toggle fold

but I think the following should make it into a menu (actually a
submenu, since I don't think they are commonly used enough to go in a
top level menu) and I have suggested which new submenu to put them in.

Ctrl-K          delete current line       popup-edit
Ctrl-T          transpose current line    popup-edit
Ctrl-Shift-X    cut line                  popup-edit
Ctrl-Shift-C    copy line                 popup-edit
Alt-Shift-W     select word               edit-select and popup-select
Alt-Shift-P     select para               edit-select and popup-select
Alt-Shift-L     select line               edit-select and popup-select
               insert alt whitspace      popup-edit
               indent space              popup-indent
               undent space              popup-indent
               prev indent               popup-indent
Ctrl-B          matching brace            edit-goto  popup-goto
Ctrl-M          toggle marker             edit-goto  popup-goto
Ctrl-.          next marker                  "          "
Ctrl-,          prev marker                  "          "

Some of the less commonly used existing menu items could also move
into these submenus so actually reducing the size of the top level
menus.
We better be careful, this could spark another GUI discussion ;-)

On a related but different topic.

I have been toying with the idea of adding a simple action
recorder/replayer by recording key presses (in on_key_press_event
function) and capturing menu activations by a signal emission hook on
the activate signal.
 My question is, are there any actions that don't use one of these
paths, and are there any that use both, for example any key presses
that go to GTK and activate menus rather than call the callbacks
directly in on_key_press_event or any other actions that are invoked
directly without an activate signal?
This is something I'll look at in detail after the build-system is finished.

Cheers
Lex

>
>
> Regards,
> Enrico
>
> --
> Get my GPG key from http://www.uvena.de/pub.asc
>
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>
>



More information about the Devel mailing list