Re: Infrastructure for plugins (including Lua-based ones) to add their own menus

[Richard Sharpe <realrichardsharpe () gmail com>]

On Thu, Jul 12, 2012 at 12:30 AM, Tony Trinh <tony19 () gmail com> wrote:
> On Tue, Jul 10, 2012 at 10:06 AM, Richard Sharpe
> <realrichardsharpe () gmail com> wrote:
> > Hi folks,
> >
> > In a previous email I raised the issue of givin Lua plugins the
> > ability to declare their own menus, not just menu items on existing
> > menus. Indeed, I would like to go further and to expose facilities for
> > plugins to add items to other places, like the Filter bar and the
> > popup menus.
> >
> >
> > However, one additional discussion that I think it is important to
> > have has occurred to me.
> >
> > It seems to me that there are two approaches that can be taken with
> > respect to allowing plugins to add menus:
> >
> > 1. A free-for-all, where each plugin can establish its own menu. This
> > keeps each plugin separate, but could get a bit ugly.
>
> It would be simple to modify the current code to allow Lua to insert
> anywhere in the menu bar, but I agree that one of the reasons this
> restriction is in place is likely to prevent menu madness (the "ugliness"
> you mention) and possible user confusion. Imagine 20 Lua plugins that
> created their own top-level menus.
>
> > 2. A single menu for plugins, with each plugin getting its own section.
>
> Hmm. I don't understand the advantage of this approach over the current
> solution. Can you clarify with an example?

My thought here is that after you have installed a few plugins, you
will have to hunt around for which menu they have installed themselves
in.

If there was a separate plugins menu, it would be obvious :-)

> The common goal for these approaches seem to be the separation of each
> plugin's menus. Menu grouping is already possible with the current release
> of Wireshark, as shown below.
>
> Lua:
>     register_menu('PluginA/foo1', foo1_action, MENU_TOOLS_UNSORTED)
>     register_menu('PluginA/bar1', bar1_action, MENU_TOOLS_UNSORTED)
>
>     -- note the dash is used for menu separator
>     register_menu('-/PluginB/foo2', foo2_action, MENU_TOOLS_UNSORTED)
>     register_menu('PluginB/bar2', bar2_action, MENU_TOOLS_UNSORTED)
>
> Menu result:
> Tools
> |-- PluginA
>   |-- foo1
>   \-- bar1
>         ------------------------ (menu separator)
> |-- PluginB
> \-- foo2
> \-- bar2
>
> Another undocumented feature (as of 1.7.0) is keyboard shortcuts (e.g.,
> shortcut on "f" with "PluginA/_foo").
>
> I think it would be nice to add more control over menu items, including the
> following
>
> edit menu text/icon
> create toggle menu
> disable menu
> hide/remove menu
> add menu after init (it's currently prevented, and IMO, there's no reason to
> do so)
>
> These additions might call for a new "Menu" [meta]class.
>
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>              mailto:wireshark-dev-request () wireshark org?subject=unsubscribe



-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe