[RFC] A differnt options system

[Derek Atkins]

Hi,

Okay, after our conversation on IRC last night (thanks for coming in!)
and then sleeping on it....  Let's start from the beginning.

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?

now....  let me try to respond to some of the items in your mail....

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

>> Also, there are a TON TON TON of comments in that code.. There are
>> probably more comments than actual lines of C.
>
> Unfortunately not.  Is this just rhetoric or are we looking at
> different versions of option-util.c and dialog-options.c?

No, this is not rhettoric.  Here's an example from
src/app-utils/option-util.c, around line 2042 in the g2 branch:

/********************************************************************\
 * gnc_option_db_lookup_font_option                                 *
 *   looks up a font option. If present, returns its malloc'ed      *
 *   string value, otherwise returns the strdup'ed default, or NULL *
 *   if default was NULL.                                           *
 *                                                                  *
 * Args: odb     - option database to search in                     *
 *       section - section name of option                           *
 *       name    - name of option                                   *
 *       default - default value if not found                       *
 * Return: char * option value                                      *
\********************************************************************/
char *
gnc_option_db_lookup_font_option(GNCOptionDB *odb,
                                 const char *section,
                                 const char *name,
                                 const char *default_value)
{
  return gnc_option_db_lookup_string_option(odb, section, name, default_value);
}

.......

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

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

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