Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] Adding a new menu in the MenuBar

From: Jeff Morriss <jeff.morriss.ws@xxxxxxxxx>
Date: Mon, 09 Jul 2012 16:46:37 -0400
Richard Sharpe wrote:
> On Mon, Jul 9, 2012 at 10:28 AM, Jeff Morriss <jeff.morriss.ws@xxxxxxxxx> wrote:
>> Richard Sharpe wrote:
>>> On Sun, Jul 8, 2012 at 10:15 PM, Tony Trinh <tony19@xxxxxxxxx> wrote:
>>>> On Mon, Jul 9, 2012 at 1:01 AM, Richard Sharpe <realrichardsharpe@xxxxxxxxx> wrote:
>>>>> Hi folks,
>>>>>
>>>>> I would like to add a new menu in the Menubar, like "Menubar/Blah" and
>>>>> place it before help, and after the tools menu (and probably before
>>>>> Internals).
>>>>>
>>>>> I would like to do it from Lua.
>>>>>
>>>>> I think I can see how to do this, but I wonder if anyone else has done
>>>>> that before?
>>>>>
>>>> WSLua does not support adding main menus. Currently, you can only add submenus to
>>>> existing menus.
>>> You are correct. The problem would seem to be twofold:
>>>
>>> 1. There is no function for doing that, and
>>>
>>> 2. In ui/gtk/funnel_stat.c, the stat_group_name function contains a
>>> static value_string of the relationships between values like
>>> REGISTER_STAT_GROUP_UNSORTED and the string to use for the menu item.
>>>
>>> Functions/methods would have to be added to allow new menu items to be
>>> added to allow the addition of whole new menus, but
>>> register_lua_menu_bar_menu_items and its subsidiary functions seem
>>> capable of this, as well as functions/methods to enter new values in
>>> VALS_GROUP_NAMES and to retrieve the index based on the string.
>> I had to make a bunch of changes to this code (in r41591) to get the Lua
>> menus working again.  And I wasn't terribly happy with the result; it
>> seems quite a bit of a mess to me.  But I didn't have a better idea at
>> the time...
> 
> Sure. I don't really have any criticism of your work. I would only
> suggest that VALS_GROUP_NAMES should be all lower case so that it does
> not look like a macro etc, unless, that is, there is a rule covering
> this case.
> 
> In addition, I think that what is there is fine for current needs.
> 
> I just have new needs, which I think others might have as well.

I just wanted to mention it in case you're going rework the code.

I renamed that value_string in r43627.