[RFC] A differnt options system

[Chris Shoemaker]

On Wed, Feb 16, 2005 at 01:05:31PM -0500, Derek Atkins wrote:
> Hi,
> 
> It really is not bitrotting, why would you think it is?  There is a C
> api and a scheme api that are tied together.  Scheme is actually the
> primary API, so some of the C api is missing because nobody ever
> needed those particular functions.  In other words, the C api was
> never fully implemented because it seemed silly to implement functions
> nobody was using.

Well, to be fair, my evaluation is mostly based on the C api.  I
didn't see any fundamental problems with the scheme api.  But I want
to add functionality to gnucash using mostly C so I want to open
dialogs from C.

> If you need them, you can add them.  Adding them isn't very difficult.

Perhaps you're over-estimating my intellectual capacity, or you've
become de-sensitized to the complexity of the status quo because it's
familar to you, or both?  I actually had dialogs working 80% for me
using the existing options system.  After that investment, I estimated
getting an extra 10% was going to require becoming an expert in guile
and scheme (which I haven't substantially used since '98).  Now, after
a few evenings of coding, I have an options API that does 100% what I
want and seems to be flexible enough for me to use for any new
dialogs.

> 
> As for the complexity; the complexity is hidden in the fact that
> options are stored as guile thunks so you need to know a bit about the
> internal storage of the option in order to read it out on the C side.
> But that only has to happen once.  None of the users of the options
> API need to care about that.
> 
> > 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
> 
> And this isn't a good thing?  Actually, the current option system
> doesn't have many bugs at all; it's just missing some APIs on the C
> side.  Missing APIs does not a bad system make.

Ok, granted.  But if I can't easily complete the API, it does reduce
its usefulness.

> 
> > 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.
> 
> The cool thing about the options system is that it's completely dynamic.
> You don't need to change a significant amount of code to add new options.
> If you want to add a new option to a dialog you have to do two things:
> 
> 1) Add the option definition to the options-db specification
> 2) Add the code to use the option from the options-db.
> 
> All the HARD work is adding new types of options.  USING the options
> is pretty darn easy.

I agree, that _is_ cool.  I was impressed with how easy it was to get
80% of what I wanted.  (I didn't even mind the ugly layout. ;)

> Granted, it's MUCH easier to use them from scheme than it is to use
> them from C, but that's just due to the way it was designed.

Yes, you're exactly right.  But who do we want to attract to hack on
gnucash?  more scheme programmers or C programmers?  We should make it
easier for whoever we want to attract.

> 
> Creating an options dialog from scheme is extremely simple.  Creating
> it from C is slightly less so.  Take a look at the code for the File
> -> Properties menu option just to see how extensible the options code
> is!

Agreed.

> 
> No way could you have that flexibility using glade.

Now this, I'm not so sure I agree with.  Could you elaborate on why
you believe this?  IMO, glade gives you much more flexibility.  But
anyway, even if it were less flexible (which I don't think) glade has
IMO a huge bonus over options.scm: ** It's maintained out-of-tree. **
I'm willing to accept quite a bit of reduced flexibility when someone
else is doing all the work for me.  :)

> 
> >     they're not going to be real impressed with the Gnucash codebase.
> 
> That's true anyways.  Find 10 "new" developers and you'll probably get
> them pointing at 10 different ways the gnucash codeback sucks.

You're right, but I see two problems: 

First, for every ten "new" developers discovering that gncuash
codebase sucks, only one will sit down, figure out why it sucks and
try to improve it.  The other nine will say "gosh, this stuff blows my
mind; I'm gonna go work on something where I can make forward progress
without spending 3 months grokking this mess in the dark."  People
like seeing the fruit of their labor -- it's human nature.

Second, we don't have 10 new developers.

> 
> >>  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.
> 
> I'm not adverse to doing something differently; but I'd like to see a
> good reason to change the existing code.  I'd prefer not to have that
> reason be "these two apis don't exist".  I'd like to see real,
> tangible advantages to the new system that can't be fixed in the
> current code with a few pages of documentation (which the current code
> seriously needs).
> 
> I'll go re-read your proposal and look again for this tangible
> improvement.  But keep in mind that different is not necessarily
> better.  :)

Quite the contrary: When it comes to apis, "different" always has
inherent disadvantages, because it means "unfamiliar" and familarity
is what breeds programmer efficiency.  But, there are other factors,
too.

-chris