[RFC] A differnt options system

[Chris Shoemaker]

On Wed, Feb 16, 2005 at 09:12:29PM -0500, Derek Atkins wrote:
> 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.

What's so special about an options dialog that diminishes the need for
logical presentation?

If you think that a one-column, uniformly-spaced stack of widgets will
always produce a reasonable gui layout for an options dialog, then we
have different concepts of the logical presentation of information.

<snip>
> 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 think this is the sort of thing that if it needs an explanation at
all, it probably needs a more thorough explanation than time allows.
But, just FTR, I'll summarize: On the sorting page, there's no visual
element to convey the parallel nature of the two sorts.  The big
separation between the primary key and the other primary sort fields
makes it look like the other primary sort fields go with the secondary
sort.  The very small space between the primary sort order and the
secondary key is especially misleading.

<snip>

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

Unfortunately not.  Is this just rhetoric or are we looking at
different versions of option-util.c and dialog-options.c?

> So take the file size with a pound of salt; you're not seeing the
> statistics that you think you are.

You make it sound like you think I haven't looked inside these
files. :)  I have.  In at least these two case, being two of the
largest C files in gnucash gives an accurate indication of their
complexity relative to all of gnucash.  

Your suggestion for me to simply special-case the behavior of
dialog-options.c ignores the circumstances that make that task much
more difficult than simply using my own GtkDialog.  Also, I find the
suggestion somewhat glib and disparaging, since it implies that I am
foolish for subclassing GtkDialog to get decent gui layout when I
could be doing the (allegedly) much more simple task of just fixing up
dialog-options.c

I may be foolish for other reasons, but I think the facts here suggest
that for my use, using dialog-options at all is overkill (even if I
didn't need to fix it!) and using my own GtkDialog to present "object
property"-type options is actually the wiser path.

<snip>

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

No, I'm not saying that it has to be only one way.  Let reports use
optionsdb, but things like gnc-plugin-page-account-tree's options
should be using something more similar to the api I proposed - a
derivative of GtkDialog that wraps a little libglade and
dirty-on-change functionality.

In my _opinion_, the fact that it even seems reasonable to you that
gnc-plugin-page-account-tree uses optionsdb for the options dialog
shows that everything's looking like a nail to the guy who has a 900
lbs.  hammer.

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

Essentially, the glade file contains a specially-named widget that
indirectly instructs the loader to load another glade file are
reparent it to that widget.

<snip>

Let me try to summarize, because this has been a long thread:

Sometimes, you just want to throw up a dialog to show some values.

Sometimes, you already know what you're going to do with those values
when the user has set them, and where you're going to store them
long-term, if at all. (e.g. in the object's structure, or in the books
kvp, or somewhere else.)  

Sometimes, you can think of a better presentation for your options
than a one-tab notebook with a one-column stack of uniformly spaced
widgets.

In those cases, using the options triad is almost certainly not the
right thing to do.

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.

-chris