Hi, Chris Shoemaker <[EMAIL PROTECTED]> writes:
> Well, it started here: > https://lists.gnucash.org/pipermail/gnucash-devel/2005-January/012493.html > https://lists.gnucash.org/pipermail/gnucash-devel/2005-January/012496.html > > Plus, I think the comments patch I submitted contained in option-util.c: > > /* TODO: > > - even though there is a make-text-option on the scheme side, > gnc_option_db_lookup_string_option() doesn't seem to work for > those, so I guess there's no way to use make-text-option I think there may be a difference between "string option" and "text option". I need to take a look. > - for make-date-option, there seems to be only support for getting, > not for setting. > */ > > I marked it TODO, but realistically, I suspect the options API is > bitrotting under their own complexity. If I thought these were simple > bug-fixes, I would have attemted to fix them myself. 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. If you need them, you can add them. Adding them isn't very difficult. 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. > 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. 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. 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! No way could you have that flexibility using 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. >> 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. :) -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 [EMAIL PROTECTED] PGP key available _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
