[RFC] A differnt options system

[Derek Atkins]

Hi,

Chris Shoemaker <c.shoemaker at cox.net> 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
       warlord at MIT.EDU                        PGP key available