https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7402
Michael Mann <mmann78@xxxxxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #8902| |review_for_checkin?
Flags| |
--- Comment #15 from Michael Mann <mmann78@xxxxxxxxxxxx> 2012-08-03 18:31:46 PDT ---
Created attachment 8902
--> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=8902
Generic GUI preferences + backwards compatible preference support
Here is my first attempt at making all preferences use the "module preference"
API. I'm looking for review comments more than an actual checkin (if I receive
positive feedback, I'll just check it in myself).
The goal is to make all preferences use the (generic) "module preference" API
and minimize the "hardcoding" of reading/writing preferences (outside of the
backwards compatibility support). This could give more flexibility of breaking
up the prefs structure (or at least prevent it from growing too large). Don't
know if I'm trying to fit a round peg in a square hole, but it reduces a lot of
code and makes maintenance much easier.
Features of the patch:
1. Introduced the concept of allowing preferences to not be tied to a specific
GUI control/page. All of the "GUI preferences" can't really be setup with any
of the existing "preference types" (bool, int, enum, UAT, etc), so the API was
extended to all them to be "ignored" in the preference dialog.
2. "global" string preferences can't be NULL. This is why a handful of files
need a small modification to enforce this rule
3. PREF_COLOR created as an "internal" preference type to handle the many "GUI
preferences" that require color.
4. Bugfixed problems mentioned in
http://www.wireshark.org/lists/wireshark-dev/201208/msg00001.html
5. Removed a lot of "hardcoded" code.
Notes:
1. With the inconsistent naming convention of preferences, there are definitely
some hacks here, but hopefully moving forward it will be okay. The overall
order of the preferences in the preferences file is slightly off because I
didn't fit all preferences into their respective modules
2. Perhaps a PREF_CUSTOM type is needed to handle the remaining preferences.
It would involve lots of function handlers to create/destroy/read/write/copy a
preference, but would allow a more consistent ordering in the overall
preferences file.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.