[RFC] A differnt options system
warlord at MIT.EDU
Wed Feb 16 14:43:49 EST 2005
Chris Shoemaker <c.shoemaker at cox.net> writes:
> On Wed, Feb 16, 2005 at 01:05:31PM -0500, Derek Atkins wrote:
>> 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
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
>> 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.
> 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,
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".
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
More information about the gnucash-devel