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".
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 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)