Preferences

[Derek Atkins]

I can't imagine any preference that we would want to define in multiple
places.  For example, I cannot imagine any situation where we would want
to set a date/time/number format in a data file (except, perhaps, in
the specific case of an SX formula number-format preference).  But I
think that's a different preference, not the same preference.

-derek

"Andy Den Tandt" <adtlist_qsd at adtsoft.eu> writes:

> My feeling is that there will also be cases where preferences are defined
> two/three places. E.g. a global user preference could be overruled in a
> specific book. Eg. A user can have his date/time/number preferences and have
> one book that requires a different convention.
>
> Phil, you've been through Bugzilla, so I leave it up to your judgment
> whether this is a common case that we should think about in advance, or
> whether it's more exceptional and thus better handled in an ad-hoc manner. 
>
> Andy
>
> -----Oorspronkelijk bericht-----
> Van: gnucash-devel-bounces at gnucash.org
> [mailto:gnucash-devel-bounces at gnucash.org] Namens Derek Atkins
> Verzonden: woensdag 29 april 2009 22:22
> Aan: Phil Longstaff
> CC: GnuCash development list
> Onderwerp: Re: Preferences
>
> Phil,
>
> Quoting Phil Longstaff <plongstaff at rogers.com>:
>
>> A number of bugs in bugzilla reference the idea of splitting global 
>> preferences from per-file preferences, so I thought I would take a 
>> stab at this.  Here's my design idea, and I'm looking for any 
>> response/feedback:
>>
>> 1) Preferences are currently stored in gconf.  Global preferences 
>> will continue to be stored there, but local preferences will be 
>> stored as kvp entries of the QofBook.  This is per-file, uses 
>> existing mechanisms (I'll need to check that the xml/dbi backends 
>> load/save book kvp entries) and fits with the gconf/preferences 
>> hierarchical nature.
>
> Note that there are really three categories for preferences/properties:
>
> 1) Global for a user (Applies for a specific user to all data files)
> 2) Specific to a data file (Applies to a specific data file for all users)
> 3) Per-user, Per-Datafile (Applies to a specific user using a specific
>    data file).
>
> Your proposal only touches #1 and #2, but I do think we need to handle
> #3 as well.  For example, "current open reports" probably belongs in
> this category, and I'm sure we can come up with more values that
> belong here instead of #1 or #2.
>
> Also note that we do have the File -> Properties which are like preferences
> and stored in the Book KVP.
>
>> 2) Over the past few years, I've grown to really like the interface 
>> idea when two pieces of code need to interact.  It allows one module 
>> to use another module's services while only having a dependence on 
>> the interface, not the implementation behind it.  Therefore, I'll 
>> create a GncPrefs GObject-based interface (GInterface - is that the 
>> right term?) with get_string/boolean/double/int and 
>> set_string/boolean/double/int methods.
>
> Sounds like a good approach to me.
>
>> 3) A GncPrefsFromGconf GObject will be created and will implement 
>> GncPrefs.  This object will interact with gconf (will replace the 
>> gnc_gconf_xxx() functions).
>>
>> 4) A GncPrefsFromQofBook GObject will be created and will implement 
>> GncPrefs.  For a set operation, this will store the value into the 
>> QofBook kvp frames.  For a get operation, this will look for the 
>> value in the QofBook kvp frames.  If found, it will be returned.  If 
>> not found, it will relay the request to the global prefs to get the 
>> value from gconf and then will set the value in the QofBook kvp 
>> frames.  This will handle transfering values which are currently 
>> global and make them local.  If the key is not found globally, a 
>> default value will be returned.
>
> I'm wondering if it would be better to do the migration only once,
> like when the data file is loaded.  If the Book Prefs KVP doesn't exist
> prompt the user to upgrade and if so do the migration (or perhaps
> do the migration anyways and just inform the user you've done it).
>
>> 5) New routines GncPrefs* qof_session_get_local_prefs() and GncPrefs* 
>> qof_session_get_global_prefs() will return the local and global 
>> prefs, respectively.
>
> See above about prefs object #3.
>
>> 6) I don't think anything needs to be done for a newly created book.  
>> For current installations, #4 will copy global values from gconf to 
>> the book and then they will be used from the book from that time 
>> forward.  For new installations with no current gconf values, the 
>> defaults will be used until they are changed.
>>
>> Of course, then there is the decision about which current prefs stay 
>> global and which become local.  I haven't looked into that yet, but 
>> when I do, I'll make a proposal.
>
> There's also the question of how you define the prefs..  And how you know
> where something is supposed to live.  Right now the user of the pref
> needs to know where it lives so you would need to do something like:
>
>   GncPref* gnc_get_global_pref(const char *prefpage, const char *prefname);
>   GncPref* gnc_get_book_pref(QofBook*, const char*, const char *);
>   GncPref* gnc_get_user_book_pref(QofBook*, const char*, const char*);
>
> Then of course we would need to define the set of prefs in each
> PrefsSet, so there's the Global prefs set, Book PrefsSet, and the
> User/Book PrefsSet.  So we would need a registration procedure so
> that GnuCash can register preferences settings in each section.
>
> That preference definition could contain the page, name, tooltip,
> default value, etc for each preference.
>
> If we want to abstract out the pref location (Global, Book, or UserBook)
>>From the caller/user of the pref then we need to assure that a pref
> isn't duplicated anywhere and DEFINITELY need a "global" registry.
>
>> Phil
>
> -derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available