[RFC] A differnt options system

[Josh Sled]

I'm jumping into this thread late, since I had RealJob to do this
afternoon.  My summarized take after catching up on it all:

1/ We're all in agreement that the current options stuff is
less-than-optimal, to various degrees.

2/ Your proposal doesn't have feature-parity with the existing system,
which is a problem.  I believe that when it does, it'll have similar
complexity to the existing options stuff.


Specifically, I think there are 3 distinct facets to the options stuff
in discussion:

1/ option-type declaration
   a/ Enumerated types
2/ option-editing dialog building and runtime
3/ option-value persistance

Your proposal relates to these in the following way:

1/ the mapping between types and widgets is in the code
   a/ <??nothing -- since it's in C, nothing needs to be done, which is 
         false.??>
2/ half-defer to glade/gtk; cut-and-paste
3/ <not handled>

As well, there's a partially-mentioned aspect that I personally have a
problem with, which is that the option "db" is generated scheme code
which is then eval'ed at startup, rather than simply being the raw
_data_ that it is.



I think the way to clean this stuff up is:

1/ flip the "authority" of the option-db implementation from scheme to 
   C. [It's probably best to do this after moving away from g-wrap, so 
   we don't need to change it again, but whatever...]

2/ clean up the API; phrasing, language, consistency, size and 
   documentation.

3/ clean up the option-value persistance and loading so it's less 
   weird, less dependent on scheme; use gconf and in-backend data where 
   appropriate [as opposed to book-parallel configuration storage].

4/ have better option layout support, via some declarative/gui-building 
   language.

5/ document how to do things like add a type, deal with sections, get 
   specific layouts, ...


I (and Derek) are totally sympathetic to the complexity.  But I don't
see how your proposal works within the existing code to make things
significantly better.



FTR, this is _always_ the rub with gnucash development, generally ...
there's a bunch of things exactly like this.  My mental cycle each time
is "fsck it!  nuke it and start over" ... "oh, wait ... there's years of
work that would need to be re-written, and can't really be salvaged".   

We need to /evolve/ our way out of this mess.  In some places that's
more true than others ... I think the register should simply be
re-written, for instance.  But the options stuff is a bit too core for
that treatment, and I don't think it's warranted.

...jsled

-- 
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`