preferences

[Derek Atkins]

Phil Longstaff <plongstaff at rogers.com> writes:

> On Tue, 2011-05-24 at 17:57 +0200, Maris wrote:
>> Hi Derek,
>> 
>> On Tue, 24 May 2011 16:32:10 +0200, Derek Atkins <warlord at mit.edu> wrote:
>> 
>> > Hi,
>> >
>> > Maris <maris.rob at vdi.de> writes:
>> >
>> >> I'm going to use gnucash as an effective means to do bookkeeping of my
>> >> hours spent to several customers and associated projects, using the
>> >> STD  currency as shortform for "Stunden" (hours) in german.
>> >>
>> >> At this time I encounter the need to select different preferences for
>> >> this application than for my financial bookkeeping. But the
>> >> preferences are  stored globally. Is there any means to have them
>> >> associated with the  gnucash file opened?
>> >
>> > At this time I'm afraid that no, the split of preferences is not
>> > amenable to this.  It's something that needs to be worked on.
>> >
>> > One thing that would be helpful would be a list of every preference and
>> > a way to categorize it as:
>> >
>> > - user pref      (per user for every data file)
>> > - data pref      (per data file for every user)
>> > - user/data      (per user, per data file)
>> >
>> > I believe there are lots of prefs in the first item that arguably should
>> > live in the second or third category.  Note that File -> Properties
>> > (instead of Edit -> Preferences) provides access to the second category.
>> 
>> As a probable route to implement this iteratively I'd propose to extend  
>> the .gnucash/xxx.gnucash.gcm file with a section where assignments can be  
>> specified that correspond to the Edit->Preferences entries (or a new file  
>> for this). Actually, this would represent the third category. This  
>> requires that this file be read after reading the "global" preferences, in  
>> the style of SciTE hierarchical preference file reads: global - user -  
>> local. For a while this would eliminate the pain of writing a GUI for  
>> copies of parameter sets on a more local level where it must be visible to  
>> the user whether a parameter equals the "parent" value or not (this saved  
>> the SciTE guys a lot of programming effort, but SciTE is a programmer's  
>> tool, and hence, it is reasonable).
>
> I'm currently modifying the preferences code to hide gconf to help make
> the user-pref/data-pref/userdata-pref split that Derek talks about
> easier.  I don't know SciTE hierarchical preferences files, but I can
> look at it.  Currently, there are some values which are stored in the
> book's kvp frames which could form the data preferences.  There could
> also be values under the books kvp under a specific path (e.g.
> "user/<username>").  

I guess it depends on the definition of "user".  I was imagining this
would be stored in the $HOME/.gnucash/books/ alongside the other data we
store there.

Moreover, I was not really considering a hierarchical preferences set.
I think each preference belongs in only one place.  I think it's
completely reasonable to categorize each pref into one of the three
categories, and *that is where it gets stored*.

Most preferences really don't need a way to override, and if you do have
an override mechanism I think it would just add too much complexity too
quickly.  One can certainly view prefs which don't make sense to be
overridable, or which you want users to have the same values, etc.

So basically I still think each pref should "live" in only one place; we
just need to properly categorize (and migrate) the existing prefs.

> 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