[RFC] A differnt options system

[Chris Shoemaker]

On Thu, Feb 17, 2005 at 07:08:40PM -0500, Derek Atkins wrote:
> Hi,
> 
> Okay, after our conversation on IRC last night (thanks for coming in!)
> and then sleeping on it....  Let's start from the beginning.

Thanks, I appreciate it.

> 
> First, as you suggested, let's ignore the existing OptionsDB,
> dialog-options, and options-util.  Your code doesn't try to solve the
> problem(s) that the existing options code does; so let's not conflate
> the issues.
> 
> Second, let's look at what your code DOES do, and how it can be used
> going forward...  It sounds like what you're trying to is simplify the
> bunch of dialog-FOO sources by abstracting out the glade and gtk
> widget code for the majority of fields which are purely get/set.
> 
> How am I doing so far?

I think you got it.  :)

<snip>
 
> > Currently in gnucash, when those cases have arisen (so far, more than
> > 40 occasions) the solution used was to use glade and GtkDialog to
> > present and retrieve those options.  That's a very reasonable
> > approach, and one that I want to use also.
> >
> > I could just cut-n-paste from one of the many other examples of this
> > method and go from there, as has obviously been done many times
> > already.  However, there's a good chance I'm going to need more than
> > just one of these dialogs.  I'd like to do the common stuff once and
> > reuse it instead of replicating dialog-foo.c each time.  The "common
> > stuff" includes:
> >
> >   . load the gui using libglade
> >   . dirty-on-change behavior for the apply
> >   . connecting to the dialog response signals
> >   . accessing named fields without necessarily remembering what type
> > of GtkWidget I used in the glade file and what the api is for that
> > particular widget (to get/set the value)
> >   . [occasionally] including some glade guis from other glade files
> > into my main dialog
> >   
> > It turns out that when I derive GtkDialog to provide this abstraction,
> > throwing a dialog up becomes much easier.  All that's left to do is
> > each time is:
> >
> >    . make the glade file
> >    . instantiate my dialog, passing it the glade filename
> >    . call the set_<type>() function for each value to push the values
> > to the dialog
> >    . call the get_<type>() function for each value to fetch the values
> >>From the dialog, in the apply callback
> >    . validate the values
> >
> > It's not that hard, and it it's a lot easier than implementing
> > everything over again each time.  I don't need to make any libglade
> > calls; if I use the type_specific gettter/setters, I don't even need
> > to use the gtk+ api at all.
> >
> > Finally, I think that the advantages of using an abstraction like this
> > are made most evident when one looks at all the other implementations
> > of this paradigm in gnucash.  Some of them are pretty inelegant, using
> > lots more code than needed to implement this functionality.  That's to
> > be expected when you have 40+ implementations.  
> >
> > I think there was some initial misunderstanding about the
> > functionality that my proposed api was attempting to provide.  That
> > was probably my fault because I was using the term "options" in a way
> > that's not what gnucash developers are used to.  Perhaps a better name
> > for the proposed API is GncDialog?  It's a derivative of GtkDialog
> > that can be treated like GtkDialog but offers gnucash-specific
> > convenience functions.
> >
> > Let's at least provide an alternative.  At least critique my proposal
> > in the light in which it was intended.
> 
> Unfortunately I was really tired last night and had to leave before we
> could finish our conversation.  I think that as a way to abstract
> dialog creation (note that I didn't say "options" ;) this might be an
> interesting approach.  I'd like to see this approach validated -- does
> it really reduce code size and code complexity, or does it just
> tradeoff one set of APIs for another set of APIs?

Well, of course it trades one api for another api (or set thereof).
But it replaces less abstract apis with a more abstract one.

> 
> As a validation of this approach I'd definitely like to see how this
> could, for example, reduce the code footprint of existing dialogs.
> For example, could you re-implement dialog-customer (just to take a
> relatively simple dialog) using your API?  How much would it reduce
> the code and/or complexity of dialog-customer?  (note, feel free to
> use dialog-vendor or dialog-employee instead as a test-case).  Does
> this reduce the code size by 5%?  10%?  50%?

Well, a particularly favorable example would probably be
gnc-plugin-page-account-tree, since it currently uses optionsDb.  But
I'll look at some dialog-foo and try to answer the question you asked.

-chris