more generic preferences implementation

[mmann78 () netscape net]

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)

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe