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 _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
