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] more generic preferences implementation

From: Jeff Morriss <jeff.morriss.ws@xxxxxxxxx>
Date: Mon, 18 Jun 2012 11:53:25 -0400
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...