[Guy Harris <guy@xxxxxxxxxxxx>]

On Oct 22, 2003, at 11:59 AM, Guy Harris wrote:

> I'm not sure what it should be, either - but if taps go under more 
> than one top-level menu, we'd have to change the API, even if the only 
> change is to have the menu path supplied when registering the tap be a 
> path rooted at the menu bar (e.g., register as "Statistics/XYZP" for a 
> tap that gives statistics for the XYZ protocol or "Analyse/TCP Stream" 
> for a tapified version of "TCP Stream Analysis").

Well, I have a change that assumes that the menu path for a tap is 
rooted at the menu bar, and it seems to work - it creates top-level 
menu items as needed.

However, they get created in the order in which taps register, meaning 
that "Analyse" and "Statistics" and... would appear in an order that 
might not be the desired order.

The thing to bear in mind about menus and submenus containing only 
entries registered by taps is *"menu.c" currently has no control 
whatsoever about the order in which they appear!*  If you don't like 
the order, currently, the only way to change it is to change the order 
in which taps are registered.

The order in which tap source files are processed is the order in which 
they appear in the ETHEREAL_TAP_SRC macro in Makefile.am and 
Makefile.nmake.  If a tap source file has more than one tap, the order 
in which they're processed is basically sequential order of the 
registration calls within the source file.

So that does let you control the order to some degree, although all 
menu items registered by a given tap source file in a given menu or 
submenu are consecutive - that cannot be changed.  However, when the 
next tap is added, it'll be added wherever the people who write the tap 
source file, and the people who change Makefile.am and Makefile.nmake, 
put them.

I.e., if you want to change the order of tap items, that's a harder 
problem than changing the order of other items, and becomes even harder 
as more taps are added.  If we ever support taps as plugins, it becomes 
even *harder*, as the order would depend on the order in which builtin 
and plugin taps were registered, and on the order in which plugin files 
are loaded, which depends on the order in which, on the particular type 
of file system containing the taps, file names are returned by the 
"scan the directory" mechanism in the OS, unless you pick a fixed 
order, e.g. alphabetical order, or unless you have a file containing a 
list of taps to load (which means that you have to update that file 
when a new tap is added!) with the load order being the order in the 
list.

And it's currently *impossible* to perfectly control the order if you 
want

	tap from source file X
	tap from source file Y
	tap from source file X

To fix *that*, you'd have to split source file X and register two taps, 
and make sure that the register routines are called in the right order.

And don't forget that a user can also have a *personal* plugin 
directory; plugins in that directory are loaded after plugins in the 
system plugin directory.

This suggests that trying to control the order, within a menu, of 
tap-registered menu items is probably going to be futile.

You could have a fixed set of top-level menu items to contain taps 
(e.g., "Analyse" and "Statistics"), and have the tap registration API 
specify which top-level menu item the tap should go under and *NOT* 
create a new top-level menu item if a non-existent top-level menu item 
is specified; that'd at least let you control the order in which 
top-level menu items are created, although the order of tap menu items 
*under* those menu items is out of your control.