is it possible to save a list of lists in the option db?

Derek Atkins warlord@MIT.EDU
30 Jul 2002 10:41:31 -0400


There is no way to store lists of strings in the option-db.  You would
have to create a new option type to do so.

Look at src/app-utils/options.scm for the definitions of most of the
other options.  Also note that if you want to provide a user-interface
to your new type of option (i.e. if you expect uses to manipulate the
options directly) then you probably need to modify
src/gnome-utils/dialog-options.c and plug in the three functions for
your new option.

Another thing to note: if you store these lists in the global options,
and if the user ever hits the "reset defaults" button, you will _LOSE_
this information.  The "reset defaults" button will reset everything
in the option database (not just on that particular page).  This may
be considered a bug in the current option ui.

You really should think about what you need to store, where, and why.

In particular, I'm not at all convinced that banks will assign
multiple userids to access the same bank account, nor am I at all
convinced that there will be this level of multiple access.  In
particular if there is a direct binding of "Gnucash Account" <-> "HCBI
Bank + Account", I'm not convinced you need to keep much more
information than a binding between "HCBI Bank" and "Username/Password".

Note, however, that the option-db, as currently defined, wont even let
you do this.  You'll definitely have to build a new option structure
to hold this information.

-derek

Christian Stimming <stimming@tuhh.de> writes:

> In HBCI, each human user can be a customer of various banks, and for each bank 
> he might have been assigned various user-ids. I would like to store this 
> "list of banks containing lists of user-ids" on a per-end-user basis. This 
> doesn't quite allow me to save it in a kvp_frame of each book, since a) one 
> book might be used by different end-users, and b) the same end-user will want 
> to access different books and still have the same functionality available.
> 
> Therefore I thought the most appropriate place would be to store that "list of 
> banks containing lists of user-ids" in the options file of the end user, 
> probably as an internal option. How hard is it to store a list of lists 
> there? These lists will not be very big, but still an average user might have 
> 3 banks with 2 user-ids each, so I have to stick to the list structure. The 
> user-ids have a fairly limited character set, so I could probably add control 
> characters to do some parsing on my own.
> 
> Christian
> 
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel@lists.gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

-- 
       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@MIT.EDU                        PGP key available