[RFC] A differnt options system

[Derek Atkins]

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

>> The same way a programmer would have to do it with glade or any other
>> layout mechanism -- split the options onto separate pages..
>
> No.  It doesn't work.  No amount of spliting options onto separate
> pages produces reasonable layout.  What do you think the dozen-plus
> gtk layout containers are for?

I think our definitions of "reasonable" is very different for an
options dialog.

>> > By pure chance, I had to take a break from coding an hour ago to do
>> > finances.  For my real books, I still use 1.8.9.  I was in a P&L
>> > report, and checking the boxes for subtotaling (which by the way are
>> > laid out *worse* than random, because they are misleading about which
>> > field go with with key) when I saw:
>> 
>> I think that's a labeling issue; you'd have the same issue with any
>> other method...
>
> No.  It's NOT a labeling issue.  It's a widget spacing issue.  Can't
> we agree that there's a good reason for visual grouping and space
> between widges?

I'm looking at the dialogs for the P&L options right this minute and I
can't see where there's anything confusing about it.

> I'm getting the impression that you think I'm saying C code is better
> than scheme code.  I'm not.  I'm saying that simple is better than
> complex.  Of course any code can have bugs, but not all C code is
> equally complex.  Anyway, how do you _know_ that the bug is in the C
> code?  Couldn't it be some C/guile/scheme interaction?  That's really
> the point.  Maybe _you_ know, and maybe you're right.  But how would
> _I_ know where to start looking for a bug in code so complex?

"Simple" is mostly a matter of "understanding".  Is algebra simple?  I
think that will depend on whether you ask a 10 year old or a 15 year
old.

As for how I know the problem is in the C code, it's because of the
particular check.  Because I understand how C and Scheme interact,
you're not going to get a gtk warning from anything "wrong" in the
scheme side.  Or if you do, it's going to be that it gives you the
wrong value.  That warning message says that a C struct member is NULL
when it shouldnm't be.

As for where you should start looking for this bug, start at the error
message and then work backwards, the same way you'd work on any other
bug.

> Wow.  Is it necessary to wrap all symbols like that?  If not all,
> which ones are required?

It depends.  "find | xargs grep" is useful to figure out which ones
are used.  But exporting the symbols is what gives us the nice scheme
bindings.

>> > What if I don't want a notebook with a single tab?
>> 
>> Then fix dialog-accounts.c to hide the notebook when there's a single
>> tab.
>
> I assume you mean dialog-options.c.  I'm sure what you describe is
> possible, but I want to point something out:

Sorry, yes, I mean dialog-options.  It's been a long day.

> [chris at pe gnucash]$ find . -name "*.c" -a ! -name "gw-*.c" -printf '%k %p\n' |sort -nr |head
> 184 ./intl-scm/guile-strings.c
> 152 ./src/gnome/dialog-sxsincelast.c
> 124 ./src/gnome/druid-loan.c
> 116 ./src/backend/file/io-gncxml-v1.c
> 108 ./src/engine/iso-4217-currencies.c
> 100 ./src/gnome/dialog-scheduledxaction.c
> 100 ./src/engine/Transaction.c
> 100 ./src/app-utils/option-util.c
> 88 ./src/register/register-gnome/gnucash-sheet.c
> 88 ./src/gnome-utils/dialog-options.c
>
> 88K! and good ol' option-utils.c weighs in at 100K!  These are the
> largest c files in gnucash.  Can you excuse me for being a bit wary of
> hacking into them to try to remove the tab when I get much more from
> an implementation less that 1/4 the size?

option-util is large because it handles all the mapping between C and
Scheme and also handles the storage and loading of optiondbs.  In
other words, it's about three modules combined into on source file.

Also, there are a TON TON TON of comments in that code.. There are
probably more comments than actual lines of C.  So take the file size
with a pound of salt; you're not seeing the statistics that you think
you are.

>> I don't see how the new api is any simpler for a user.  Seriously, I don't.
>> What's so hard about using the various existing APIs:
>> 
>>   gnc_option_db_lookup_<foo>_option() and
>>   gnc_option_db_set_<foo>_option()
>
> Don't forget gnc_option_db_commit, and all the gnc_option_dialog_*
> functions.

Most of those functions aren't necessary by the average user.  Sure,
you need the "create" and callbacks, but that's about it, really.
Certainly it's no more complicated than your API.

> That was just an outline.  I left out the details.  I think I wrote
> that.

It was a fairly complete outline.  So we add a few helpers to reduce
the "normal" complexity.  Go take a look at the File Properties code.
It's not a lot of code to create and instantiate that dialog.
Granted, much of it is done in Scheme, but still.

> I recognize that scheme IS well-suited for configuration
> specification, but it's being used for much else right now in gnucash.

True...

> I don't know much about the history of gnucash development, so I'm
> probably stepping on some toes, but from where I stand it looks like
> someone's infatuation with scheme got the better of gnucash.  I'm
> sympathetic.  I've heard the scheme siren's call before.  ;) I
> implemented a really crappy window manager in scheme when I was in
> school.  It worked.  Kind of.  (Actually, it was a disaster.)  I'm not
> down on scheme; I just know it's not good for _everything_.

Agreed on all counts.  There WERE a lot of schemers who decided it was
the best thing since sliced bread.  Unfortunately they've long since
left, and we're stuck with their remnants.  That doesn't mean that all
usage of scheme is bad....

> Again, I'm curious if others agree.  IMO, if you only need the value
> in C then it's better to store the value in C.  That's not a no-op.

Except the VAST majority of users of the optiondb are all in scheme..
The reports.  So by your analysis we should optimize for scheme
access, which is what they've done.

>> Sure, just like you can use the scheme-generated gui and have the
>> values stored in a KVP_frame in the QofBook or in a scheme file.
>
> You mean by accessing the optionsDB with gnc_options_db_lookup_*,
> right?  If that were the standard way of storing option values, then
> the C api would probably be more complete.

No.  That's not how the kvp access works.  The options actually load
from and store to the kvp frame natively.  Take a look at the xxx->kvp
methods in options.scm.

> Yes, that's why I said WORST case.  What do you think about
> heirarchically loading glade files?  I had a fully recursive
> implemetation of that idea, but it seemed kind of like overdesign.

Uh, what does "hierarchically loading glade files" mean?

> I guess that's where the documentation saying which is which would help.

100% Agreed.

> Ok let me remake the list, and add some comments:
>
> 1) Provide scheme-side option value access 
>
> Would scheme wrappers for the proposed C api meet this need?

Scheme wrappers around _some_ C api would probably work.  Whether your
API is sufficient, I dont know.  I would definitely like to see a
clear separation between the "options db" and "gtk".  Having it return
the GtkWidget is IMHO a Bad API model.

> 2) Provide persistence for program preference option values across
> program executions
>
> I think this is gconfs domain.
>
> 3) Report option persistence
>
> Could these be saved in the book's kvp which then gets sent to the
> backend?
>
> 4) File Properties persistence
>
> These are "book properties", right?  They can be saved with the book
> in the backend, right?

Sure.

> 5) Provide for the composition of loosely-grouped option values in a
>  way that is as simple as in scheme
>
> What do you think about the heirarchical glade-file idea?

I dont know what it means or how it works, so I don't have an answer.

> Thanks for taking the time to discuss this.

you're welcome.

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