[RFC] A differnt options system

[Chris Shoemaker]

On Wed, Feb 16, 2005 at 11:31:01AM -0500, Derek Atkins wrote:
> Chris Shoemaker <c.shoemaker at cox.net> writes:
> 
> > Background: I'm mainly interested in getting budgeting to work, but
> > along the way I discovered that the options system in gnucash wasn't
> > exactly up to doing what I needed and, frankly, it looked like it was
> > going to be a major headache to make it work for me.
> 
> In what way does the existing options system not work for you?

Thanks for looking at this Derek.

Well, it started here:
https://lists.gnucash.org/pipermail/gnucash-devel/2005-January/012493.html
https://lists.gnucash.org/pipermail/gnucash-devel/2005-January/012496.html

Plus, I think the comments patch I submitted contained in option-util.c:

/* TODO: 

  - even though there is a make-text-option on the scheme side,
    gnc_option_db_lookup_string_option() doesn't seem to work for
    those, so I guess there's no way to use make-text-option
  - for make-date-option, there seems to be only support for getting,
    not for setting.
*/ 

I marked it TODO, but realistically, I suspect the options API is
bitrotting under their own complexity.  If I thought these were simple
bug-fixes, I would have attemted to fix them myself.  

Frankly, if I had done that, what would we have?  The same options
system, but with fewer bugs.  But, I'm not convinced that the
fundamental design of the options triad is maintainable.  At least to
someone coming from outside, like me, the options system is
practically an impenetrable mystery.  But, more people from outside
coming to hack gnucash is exactly what we need.  If they can't even
throw up an option dialog without either:
     1) groking the options triad or 
     2) using libglade; subclassing GtkDialog; rolling their own
change watcher; and remembering the API of every GtkCheckBox,
GtkSpinButton, and GtkEntry, etc, etc.

    they're not going to be real impressed with the Gnucash codebase.

>  I'd prefer it if we did not have multiple options systems in
> gnucash.  Doing it once and using it everywhere is usually the best
> way, IMHO.

I completely agree.  Somewhere along the line, however, the advantages
of doing something better have to outweigh the disadvantages of doing
something differently.  If I haven't missed some great hidden virtue
of the options triad or some horrible flaw of my proprosed approach,
(please tell me if I have) I think this might tip that balance.

> 
> Have you looked at the budget work in g2 that Darin Willits submitted?

Oh yes, quite extensively.  You reviewed the xml generated by the code
I wrote to (almost) make his budgets persistent, remember.  I hope to
discuss it more fully later, but in short, after a more thorough look
at the budgeting code, I concluded that persistence was not the only
area that could use some improvement.

-chris