Wireshark-bugs: [Wireshark-bugs] [Bug 7402] New: generic preferences implementation
Date: Mon, 25 Jun 2012 13:16:03 -0700 (PDT)

           Summary: generic preferences implementation
           Product: Wireshark
           Version: SVN
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Enhancement
          Priority: Low
         Component: Wireshark
        AssignedTo: [email protected]
        ReportedBy: [email protected]

Michael Mann <[email protected]> changed:

           What    |Removed                     |Added
   Attachment #8680|                            |review_for_checkin?
              Flags|                            |

Created attachment 8680
  --> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=8680
Generic preferences implementation - Protocol and Statistics

Build Information:
Version 1.9.0 (SVN Rev 43477 from /trunk)

Copyright 1998-2012 Gerald Combs <[email protected]> and contributors.
This is free software; see the source for copying conditions. There is NO

Compiled (32-bit) with GTK+ 2.24.10, with Cairo 1.10.2, with Pango 1.30.0, with
GLib 2.32.2, with WinPcap (4_1_2), with libz 1.2.5, without POSIX capabilities,
with SMI 0.4.8, with c-ares 1.7.1, with Lua 5.1, without Python, with GnuTLS
2.12.18, with Gcrypt 1.4.6, with MIT Kerberos, with GeoIP, with PortAudio
V19-devel (built Jun 25 2012), with AirPcap.

Running on Windows XP Service Pack 3, build 2600, with WinPcap version 4.1.2
(packet.dll version, based on libpcap version 1.0 branch 1_0_rel0b
(20091008), GnuTLS 2.12.18, Gcrypt 1.4.6, without AirPcap.

Built using Microsoft Visual C++ 9.0 build 30729
While looking into possible fixes for bug 3239, I discovered that the
preference API (and the GUI screens that can be created from it) is written
fairly generically, but that only the "protocols" can take advantage of it.

This first patch allows the Statistics and "Protocol" (parent) screens to be
populated through the generic preferences API that already exists.  The current
filter field names were more specific than the categories provided through the
GUI, so I'm not sure how backwards the solution is.  Not sure how big an issue
that is.

I kept the preferences structure (e_pref) together for "backwards code
compatibility" and to minimize the number of global variables needed for
preferences, although the hope was that some members could be moved out to be
self-contained within an individual source module. 

If this design is acceptable, I will continue and provide more patches of the
other GUI preferences screens.  I may not be able to include the User Interface
and its sub screens, but everything else appears that it will fit in with the
"preferences API". 

In addition to the patch, the following files can be removed as they are no
longer needed (because they can be "generated" with the generic preferences

Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.