[RFC] A differnt options system

[Chris Shoemaker]

On Wed, Feb 16, 2005 at 02:52:25PM -0500, Derek Atkins wrote:
>
> That was David saying that, but I' understand it about 75%.  And yes,
> I _COULD_ flush out the C api -- tell me which APIs you need (which is
> where you should have started in this whole thing, and was exactly why
> I asked at the beginning "what's wrong with it?"  :)

In my defense, I really did bring this up on Jan 4th.  I hope that
post plus some of the ones in this thread have covered some of the C
API problems.

> 
> >> Isn't this something that a bunch of documentation would fix?  We've
> >> certainly had a dearth of developer docs in the code.  We've
> >> definitely been working on fixing that.
> >
> > Unfortunately, I don't think this is a documentation problem.  Look at
> > the number of functions in option-util.h.  And look at how many public
> > functions use the SCM type.  Even if they were all documented, this is
> > a complex API, that uses some unusual programming idioms.  (However,
> > several portions of this api appear not be used much if at all.)  And
> > this is only part of the options triad.
> 
> IMHO it really is a documentation issue.  Many of those option-util
> functions that take a SCM thunk are just meant to be used from the
> dialog-options code, not from option-user code.  The documentation
> part that I see there is clearing up what's meant to be the API
> between the options-db and the options-dialog, and what's the API for
> normal users of the option DB.

Would you consider gnc-plugin-page-account-tree.c a normal user of the
optionDB?  If so, I really don't think it's a documentation problem.
But, I'm sure documentation would help a lot.

> >> I'm not trying to defend the existing options code.  It took me a long
> >> time to grok it, and frankly I'd certainly rather see code written in
> >> C with scheme wrappers than the current code-in-scheme with C
> >> pull-outs.

Well, if we add scheme wrappers, isn't that what we're looking at now?

> >> But gconf doesn't fit as a drop-in replacement.

Again, I really don't know much about gconf, but maybe it's
well-suited for saving overall program preferences.

> >
> > I completely agree.  gconf may only solve one particular piece of the
> > problem, (just as libglade may only solve one piece.)  Incidentally,
> > I'm more concerned about the "object properties" type of option
> > dialog, because it's a more common task than the overall program
> > preferences dialog.
> 
> Define "object properties"?  Do you mean something like how the File
> -> Properties dialog or the [ Options ] toolbar button work?  Or do
> you mean something else?

Yes, I think I would call those "book properties."  Edit->Preferences
is what I'm calling overall program preferences.  What you see when
you click "Edit" in the account-tree-view-page is what I would call
"account properties".  BTW, why can't I edit account properties from
the account page?!?  Am I missing something?

> >> It IS kind of nice to have a single API that we can use for global
> >> options, book options, report options, etc.  I wouldn't want to lose
> >> that.
> >
> > I agree that that's ideal.  But note that we don't really meet that
> > ideal now.  For example, just look at the glade files that contain
> > "option dialog"-type widgets.  These users aren't using the
> > GNCOptionDB API, but they're doing essentially similar things.  I kind
> > of think of my options proposal as a regularization of that paradigm
> > that's already in use.
> 
> Are you trying to improve the maintainability of something like the
> customer, vendor, etc. dialogs which are really just a bunch of
> getter/setters with very little logic? 

I hadn't considered those, but I guess, yes, I am, at least some of
them.  BTW, when I looked at one of those I got:
(gnucash:16049): Gtk-WARNING **: gtksettings.c:739: an rc-data property "gtk-toolbar-style" already exists
(gnucash:16049): Gtk-WARNING **: gtksettings.c:739: an rc-data property "gtk-toolbar-icon-size" already exists

and gnucash segfaulted, but I think I saw enough to know what you're asking.

It left this is the trace file, but I don't know if it's related:
    could not find signal handler 'gnc_main_window_exit_cb'.
    could not find signal handler 'gnc_main_window_file_save_cb'.
    could not find signal handler 'gnc_main_window_prices_cb'.
    could not find signal handler 'gnc_main_window_file_save_as_cb'.
    could not find signal handler 'gnc_main_window_totd_cb'.
    could not find signal handler 'gnc_main_window_fincalc_cb'.
    could not find signal handler 'gnc_main_window_gl_cb'.
    could not find signal handler 'gnc_main_window_about_cb'.
    could not find signal handler 'gnc_main_window_help_cb'.
    could not find signal handler 'gnc_main_window_commodities_cb'.

> 
> It sounds like you want dwi (dwi.sf.net).  I don't think we're there,
> yet.  Perhaps eventually, maybe.

Interesting.

> 
> >> > believe that switching to a shared options system like gconf is the way
> >> > to go.  That code is used by multiple applications (17 that I use on an
> >> > occasional or more frequent basis), is maintained by others, and is
> >> > already a dependency of gnucash.  The only downside I see is the current
> >> > lack of per data file options.
> >> 
> >> That's a serious downside, and one that gnucash uses everywhere.
> >
> > Obviously, gconf doesn't address that problem.
> 
> Right, which is part of my complaint of proposing gconf.

Did you mean _my_ proposing gconf?  I just threw in a reference to
gconf as a potential storage solution for a certain type of program
preference.

-chris