[Geany-devel] editor context menu - Re: Search submenu for editor popup menu

[Jiří Techet]

On Thu, Sep 16, 2010 at 13:57, Nick Treleaven
<nick.treleaven at btinternet.com> wrote:
> On Thu, 16 Sep 2010 09:54:09 +1000
> Lex Trotman <elextr at gmail.com> wrote:
>
>> >> 2. let the user pick say four most used top level commands since we
>> >> are *never* going to agree on them.  Use a simplified version of the
>> >> customise toolbar dialog.
>> >
>> > Personally I don't think it's worth doing this. Put the most useful
>> > things at toplevel, everything else in submenus.
>>
>> Ah but whats the most useful?
>
> Things which are useful for the largest number of users. There is also
> an issue of letting new users discover some useful things easily that
> they might not know Geany does.
>
>>  I *never* use insert comments from the popup and rarely from the menu
>> (changelog mostly) so for me having any insert comments in the popup
>> is a waste of space.
>
> Which is why a single Insert submenu would be better.
>
>> I'm not suggesting its required, but if someone out there has the time
>> to implement it this would remove all the disagreements :-)
>
> Is it so bad to solve the disagreements using submenus?
>
> This avoids maintenance and code complexity of popup configurability,
> which I predict isn't going to be pretty. C is not a good GUI language.
>

Where I really see an advantage of having the context menu
customisable are plugin actions. With my gproject plugin and my
not-publicly-released ctags plugin I also added several items at the
top of the context menu (plus separators). I can imagine that if
several plugins do a similar thing, the context menu gets pretty messy
(someone will put the new items to the top, someone to the bottom,
someone will use separators, someone not, ...) Also the menu starts
growing even if the user doesn't really use the context menu item of
the given plugin.

This is why I really like the Lex's idea of having a fixed set of
items in the menu that are always present (possibly containing
submenus) and a variable set of configurable items. If the
configurable items can be arbitrary items from the keybindings list,
the plugins won't have to add their own items into the context menu
and the user can only pick those he wishes to be present. It's not
necessary to have submenus in the customisable part of the menu - a
plain list of items would be fine. By default the variable list could
also contain the "questionable" entries that someone wishes to be
present in the menu and someone not. Those who don't want to have them
can just remove them if they wish.

Of course this would require some work...

Jiri