[RFC] A differnt options system
c.shoemaker at cox.net
Wed Feb 16 14:25:22 EST 2005
On Wed, Feb 16, 2005 at 01:14:32PM -0500, Derek Atkins wrote:
> David Hampton <hampton at employees.org> writes:
> > On Wed, 2005-02-16 at 12:13 -0500, Derek Atkins wrote:
> >> The existing gnc option code has a method to save options into the
> >> Book. See the File -> Properties menu option.
> > I know.
> > My question is why are we maintaining and even extending a private
> > options storage system that is totally orthogonal to the purpose of
> > managing finances. I think its a waste of time an resources, and Chris
> > it right, it makes it harder for new developers to join gnucash.
> Because there isn't an alternative out there that has the same set of
> features that gnucash uses?
The exact set? No, but there are alternatives that provide subsets of
those features, and usually they do a better job.
> > I had
> > a hard time understanding the options code myself when I first started,
> > and i wouldn't say that I understand more than 50% of it today.
50%! You're an expert! :) Maybe _you_ could flush out the C API?
> Isn't this something that a bunch of documentation would fix? We've
> certainly had a dearth of developer docs in the code. We've
> definitely been working on fixing that.
Unfortunately, I don't think this is a documentation problem. Look at
the number of functions in option-util.h. And look at how many public
functions use the SCM type. Even if they were all documented, this is
a complex API, that uses some unusual programming idioms. (However,
several portions of this api appear not be used much if at all.) And
this is only part of the options triad.
> I'm not trying to defend the existing options code. It took me a long
> time to grok it, and frankly I'd certainly rather see code written in
> C with scheme wrappers than the current code-in-scheme with C
> pull-outs. But gconf doesn't fit as a drop-in replacement.
I completely agree. gconf may only solve one particular piece of the
problem, (just as libglade may only solve one piece.) Incidentally,
I'm more concerned about the "object properties" type of option
dialog, because it's a more common task than the overall program
> It IS kind of nice to have a single API that we can use for global
> options, book options, report options, etc. I wouldn't want to lose
I agree that that's ideal. But note that we don't really meet that
ideal now. For example, just look at the glade files that contain
"option dialog"-type widgets. These users aren't using the
GNCOptionDB API, but they're doing essentially similar things. I kind
of think of my options proposal as a regularization of that paradigm
that's already in use.
> > believe that switching to a shared options system like gconf is the way
> > to go. That code is used by multiple applications (17 that I use on an
> > occasional or more frequent basis), is maintained by others, and is
> > already a dependency of gnucash. The only downside I see is the current
> > lack of per data file options.
> That's a serious downside, and one that gnucash uses everywhere.
Obviously, gconf doesn't address that problem.
More information about the gnucash-devel