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.
