[RFC] A differnt options system

[Chris Shoemaker]

On Wed, Feb 16, 2005 at 06:36:48PM -0500, Derek Atkins wrote:
> Chris Shoemaker <c.shoemaker at cox.net> writes:
> 
> > Yes, it's AWFUL.  It means on page one of the dialog I have 20
> > checkboxes down only the left side of the page.  The dialog is as tall
> > as my screen so all the options fit.  Then on page two, I have two or
> > three wide options scrunched up at the top.  Both pages look awful.
> > It's an HMI disaster, and there's NO way to avoid it if you have
> > different shaped widgets.  The generated gui layout is only marginally
> > better than random widget placement!  How's a programmer to create a
> > friendly interface with that?
> 
> 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?

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

<snip bug report>

> Well, also keep in mind that there ARE a bunch of memory corruption
> bugs in Gnucash.  Also note that this is a bug in _C CODE_, so it
> could just as easily happen in your code as it does in the existing
> code.

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?

>  The devil you know vs. the devil you don't, I suppose.

Yes, but I've found a _littler_ devil.  :)

> 
> > I want to help fix bugs, really.  But if people who have been hacking
> > gnucash for years only understand the options system in part, what
> > chance do I have after only a few months?
> 
> I know you do..  But replacing working subsystems is not necessarily a
> good way to do that.  

If it were working, I would've finished in December. :(

<snip>
 
> >> That's not quite true.  Yes, you need to define the list in the option
> >> definition in scheme, but what those values mean is up to you later.
> >> You could define them in one place and export to the other, or you can
> >> define in two places and keep them in sync.  That's just a matter of
> >> programming.  
> >
> > Exactly, so if I want to display an option with a new enumeration, I
> > have to either duplicate the list or figure out how to "export" from
> > one language to the other.  I hope you can see how non-trivial that is
> > for people other than yourself.
> 
> Exporting from C to Scheme is absolutely trivial.
> See src/engine/gw-engine-spec.scm for tons of examples.  Also see
> guile-utils.c for C code to help you translate back and forth.
> 
> The code is there..  It's just not well documented.

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

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

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

> 
> > IMO, my proposal makes both adding new options and using existing
> > options easier.  As for using options, look at how
> > gnc-plugin-page-account-tree.c uses the options system.  Compare that
> > to the equivalent functionality with the proposed api.  Conceptually,
> > it's quite similar, especially w.r.t storage, but as for ease of use,
> > the proposed api is much simpler.
> 
> 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.

> 
> You've already shown how you can create the optiondb and setup the
> dialog in 6 lines of code.  If that's so much work, we can create a
> helper function.

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

> 
> >> Why would you NOT want to store your options?  What's the point of
> >> making options if you don't store them for later?
> >
> > Of course you store them.  You store them in C variables or structures
> > or whatever, and eventually they may be stored in some other form.
> > Maybe I wasn't clear on this point.  I'm basically referring to
> > overall program preferences here.  This is perhaps where gconf could
> > fit.
> 
> Except gconf doesn't seem to have a per-data-file (or even per-report)
> "save" mechanism...

I starting to regret having mentioned gconf.

> 
> Also, whether you store them in C variables/structures or Scheme
> variables/structures seems to be a no-op tradeoff, but not the issue
> I'm referring to.

I'm curious if others feel this way, too?

> 
> >> * shrugs * I don't really see this as a major issue, one way or the
> >> other.  Whether the options are defined in scheme or C seems to be a
> >> no-op tradeoff in my book.  So what if scheme is a full language and
> >> guile isn't?
> >
> > Did you mean glade?  I think this is an issue only insofar as using
> > scheme to do things that scheme is not well-suited for (like gui
> > specification) becomes a maintenance burden and prevents the creation
> > of a reasonable GUI.
> 
> Sorry, yes, I meant glade/XML.  As for "being suited", *shrugs* --
> it's not like it's unsuited.  The nice thing about scheme is that we
> CAN share configurations.  I see nothing inherently WRONG with using
> scheme for configuration.  In fact, it would (theoretically) allow a
> user to override the defaults by creating their own scheme runtime
> configuration..  Overriding XML is much more problematic.

You're not kidding are you?  If you seriously think that scheme is
well-suited to specify gui layout, then I want some of what you're
smokin' :)

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

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

> 
> >> I think this is a BAD THING.  What's the point of making options if
> >> you can't save them somewhere?
> >
> > Ok, I guess I wasn't clear about storage.  You store the option values
> > by getting them from the dialog, just like things currently work on
> > the C side with the existing options system.  You know,
> > option_db_lookup stuff...  
> 
> I think we're talking past one another. 

Maybe I should've included a longer write-up?  :)

> I honestly don't care where the information is stored in memory;
> it's all about how it gets saved and re-loaded.  Whether it's stored
> in a C structure or scheme structure is irrelevant.  Storing it in a
> dialog isn't reasonable, because you need to reference those options
> when the dialog isn't around (c.f. reports).  Again, I think this is
> a no-op tradeoff, you don't buy anything new by storing the options
> in C rather than Scheme.

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.

Anyway, then you can persist the value in what ever way appropriate.
E.g. In the entity structure, which then gets saved in the backend, or
possibly with gconf for overall program preferences, or in a book's
kvp for other options.

> 
> >> The triad has the gui and storage decoupled, too.  
> >
> > You mean I can use the scheme-generated gui and have values stored with gconf?
> 
> 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.

<snip>

> > Second, there's the case where the "option group" is just a loose list
> > of options, like in options-utilities.scm.  In scheme this is trivial
> > to specify and reuse.  WORST case with glade would be to make the
> > group once and then cut-n-paste it into multiple other glade files.
> > But I can think of several less-than-worst-case alternatives.  One
> > such alternative is to automatically replace specially-named
> > containers with other glade files, but there may be better ways.
> 
> Cut and paste == BAD BAD BAD..  If you need to make a change you now
> need to make it in N places rather than just one.

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.

>  See my report options example.
> 
> > While it doesn't do everything that the options triad does (by design)
> > it does do quite a bit that the option system can't do, like produce
> > nicely laid-out guis, and provide a simple C api.
> 
> The triad does have a relatively simple API.  There's also a more
> complicated API, too, but you can ignore that.

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

> 
> As for "nicely laid-out GUIs" I just don't think that's quite as
> important as you're making it out to be.  We're not trying to make a
> general dialog layout mechanism, here; we're making a bunch of
> options.

That doesn't mean they don't need visual display that reflects logical
organization.

> > But, it's important to highlight what it _doesn't_ do.  Please help me
> > complete this list:
> >

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?

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


Thanks for taking the time to discuss this.

-chris