[RFC] A differnt options system

[Derek Atkins]

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

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

Right.  The C api came second, and isn't complete because it hasn't
been necessary (until now).

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

Well, I like to think that people I work with are as smart as I ;)
I don't like to think that's over-estimating...

Also, your new code may do 100% what you want for your stuff but it
doesn't 100% replace the existing code, which means there's still work
to be done.

Also, you could ask for help.  If you needed a few more C apis into
the option db, ask.

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

Which APIs do you need?

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

Honestly, right now I don't care.. ;)
Besides, MOST of the hackers are _users_ of the optiondb API, not
those who need to create new option types.  The "hard" work is
creating new option types, but that's a relatively rare occurrance,
and a simple "hey, can you help with this" can sometimes go a long
way.  :)

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

In order to change a glade dialog I need to run the glade tool, change
the list of options, and then save it out.  How can I create "partial
options lists" and store them in separate places using glade, and then
pull them all together at one time into a single dialog?

With the current options I can define the optiondb specifications
piecemeal, but have it appear in a single dialog.  For example, the
reports all have some "default options" which are in all report,
defined centrally.  Then each report adds its own set of options.  If
I want to change the common options available I change the
configuration in one place, not in every report.

I just don't see how you get that flexibility in glade.

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

Hehe.  Well, you're here, and Neil Williams is here, and evanchsa is
here (sorry I don't recall your real name offhand).  I think we're
doing pretty well.

It's always easier for a new developer to say "I don't understand this
code; let me rewrite it so I can".  It's also human nature to do it
your own way.

*shrugs*

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

That's not quite what I meant by "different".  But you're right here
(and it doesn't disagree with what I said, either).  Perhaps, however,
I should have said "doing something differently is not necessarily
doing it better".

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