ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-dev: Re: [Wireshark-dev] Infrastructure for plugins (including Lua-based ones) to add

From: Anders Broman <anders.broman@xxxxxxxxxxxx>
Date: Thu, 12 Jul 2012 15:40:47 +0200
 

-----Original Message-----
From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Richard Sharpe
Sent: den 12 juli 2012 15:37
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Infrastructure for plugins (including Lua-based ones) to add their own menus

On Thu, Jul 12, 2012 at 12:30 AM, Tony Trinh <tony19@xxxxxxxxx> wrote:
> On Tue, Jul 10, 2012 at 10:06 AM, Richard Sharpe 
> <realrichardsharpe@xxxxxxxxx> 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 :-)

That should be possible by defining a plugin menu place holder.

> 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@xxxxxxxxxxxxx>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>              
> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe



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