On Wed, Feb 16, 2005 at 09:12:29PM -0500, Derek Atkins wrote: > Chris Shoemaker <[EMAIL PROTECTED]> 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. > > > [EMAIL PROTECTED] 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 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel