[RFC] A differnt options system

[Derek Atkins]

Chris Shoemaker <c.shoemaker at cox.net> writes:

>> 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.

Of course.  I don't want yet another options API in gnucash.
If we're going to replace the triad then the replacement had
better have equivalent functionality.  Otherwise you have to
keep and maintain the triad and now maintain yet another
optiondb API.  That seems suboptimal.

Granted, a theoretical replacement doesn't have to be API compatible
with the existing triad, but it had better be feature compatible.

>> >    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?

That was David saying that, but I' understand it about 75%.  And yes,
I _COULD_ flush out the C api -- tell me which APIs you need (which is
where you should have started in this whole thing, and was exactly why
I asked at the beginning "what's wrong with it?"  :)

>> 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.

IMHO it really is a documentation issue.  Many of those option-util
functions that take a SCM thunk are just meant to be used from the
dialog-options code, not from option-user code.  The documentation
part that I see there is clearing up what's meant to be the API
between the options-db and the options-dialog, and what's the API for
normal users of the option DB.

>> 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
> preferences dialog.

Define "object properties"?  Do you mean something like how the File
-> Properties dialog or the [ Options ] toolbar button work?  Or do
you mean something else?

>> 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
>> that.
>
> 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.

Are you trying to improve the maintainability of something like the
customer, vendor, etc. dialogs which are really just a bunch of
getter/setters with very little logic? 

It sounds like you want dwi (dwi.sf.net).  I don't think we're there,
yet.  Perhaps eventually, maybe.

>> > 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.

Right, which is part of my complaint of proposing gconf.

> -chris

-derek

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