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 [EMAIL PROTECTED] _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel