mmann78@xxxxxxxxxxxx wrote:
I was looking at the possibility of implementing an API for "statistics
preferences" (for say, stats_tree plugin). The preference module
(prefs.[ch]) seems to be written generically enough to support such a
concept, however I'm having a little trouble with the implementation.
I'd like to create a "module" at the same (tree) level as "Printing" and
"Name Resolution". I called prefs_register_module() from
prefs_register_modules(), expecting a "subtree" at the "top level"
within the Preferences dialog. No such luck. I called
prefs_register_subtree(), followed by prefs_register_module() in
prefs_register_modules(), and I got a "subtree" at the "top level" (with
the "subtree" name), with my "module" as a subtree off of that. Not
exactly what I was looking for. Can someone offer any advice? I got
lost trying to debug through the prefs_modules_foreach_submodules()
function trying to figure out why my module wasn't populating at the
"top level".
I think that all of that preferences code is only for dissectors (stuff
under the Protocols tree). The subtrees stuff is/was really intended
for subtrees under Protocols. So, since you're doing something new,
you'll probably need new functions to do it.
Also taking this generic implementation farther, it appears that most of
the non-dissector preferences could be replaced with the existing
preferences API (and implemented within prefs_register_modules()). This
would certainly reduce the amount of "GUI code" (for each dialog
specific to "Statistics", "Name Resolution", "Printing", etc) and make
the gtk->qt transition easier. Is this something worth pursuing? My
I'd think so; the current non-dissector preferences stuff is a mess and
a pain to maintain. I noticed that again recently:
http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=42648
biggest concern (besides my current implementation troubles) would be
possible backwards compatibility issues when switching to "individual
variables" from the current "global preferences structure" (e_prefs)
Well, the 1.8 branch has been cut so we've got a year to sort those out...
