Re: a request for the next 1.8.* version
I committed patch2. -derek Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > Derek Atkins <[EMAIL PROTECTED]> writes: > >> Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: >> >> > I can provide the details upon request. >> >> Can you send a patch? I know we've applied aclocal.m4 changes for, >> e.g., OSX. > > Here are two options. The first is preferred; the second is slightly > more conservative. > > Now autogen.sh seems to run aclocal, which will clobber changes to > aclocal.m4. I don't know what needs to be done to prevent that, or if > it is not a real worry. The gnucash build system baffles me. :) -- 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 [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [RFC] A differnt options system
Chris Shoemaker <[EMAIL PROTECTED]> writes: > On Wed, Feb 16, 2005 at 09:16:22PM -0500, Derek Atkins wrote: >> > No, I really mean account properties, like account name and account type. >> > I know that the tree-view options are reachable from the tree-view-page. >> >> Okay, then what do you mean by "account page"? If you mean the >> account tree, you should be able to select an account and then click >> "Edit" and it will pop up the account dialog. > > Ok this is OT, but when you "open" an account, you get a page with the > account register. But then you can't actually edit that account's > properties with out going back to the treeview. That's all. Sure you can. Edit -> Edit Account > -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 [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [RFC] A differnt options system
On Wed, Feb 16, 2005 at 09:16:22PM -0500, Derek Atkins wrote: > > No, I really mean account properties, like account name and account type. > > I know that the tree-view options are reachable from the tree-view-page. > > Okay, then what do you mean by "account page"? If you mean the > account tree, you should be able to select an account and then click > "Edit" and it will pop up the account dialog. Ok this is OT, but when you "open" an account, you get a page with the account register. But then you can't actually edit that account's properties with out going back to the treeview. That's all. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [RFC] A differnt options system
Chris Shoemaker <[EMAIL PROTECTED]> writes: >> Yes and no. I think there are a bunch of helper functions that exist >> which that code doesn't use. > > I didn't mean, "is it complete?" I think its too complicated for what > it's doing. I don't.. Once you separate the option memory-cache from option display from option long-term storage you've effectively recreated the same amount of complexity in the current code. The only real immediately obvious improvement is using g-wrap for the C<->guile conversion instead of doing it in the option-utils code. >> > Yes, I think I would call those "book properties." Edit->Preferences >> > is what I'm calling overall program preferences. What you see when >> > you click "Edit" in the account-tree-view-page is what I would call >> > "account properties". BTW, why can't I edit account properties from >> > the account page?!? Am I missing something? >> >> The "account properties" are really properties of the account tree, >> not any particular single "account". That's why you edit them from >> where you do. > > No, I really mean account properties, like account name and account type. > I know that the tree-view options are reachable from the tree-view-page. Okay, then what do you mean by "account page"? If you mean the account tree, you should be able to select an account and then click "Edit" and it will pop up the account dialog. > -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 [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [RFC] A differnt options system
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. >> > By pure chance, I had to take a break from coding an hour ago to do >> > finances. For my real books, I still use 1.8.9. I was in a P&L >> > report, and checking the boxes for subtotaling (which by the way are >> > laid out *worse* than random, because they are misleading about which >> > field go with with key) when I saw: >> >> I think that's a labeling issue; you'd have the same issue with any >> other method... > > No. It's NOT a labeling issue. It's a widget spacing issue. Can't > we agree that there's a good reason for visual grouping and space > between widges? 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'm getting the impression that you think I'm saying C code is better > than scheme code. I'm not. I'm saying that simple is better than > complex. Of course any code can have bugs, but not all C code is > equally complex. Anyway, how do you _know_ that the bug is in the C > code? Couldn't it be some C/guile/scheme interaction? That's really > the point. Maybe _you_ know, and maybe you're right. But how would > _I_ know where to start looking for a bug in code so complex? "Simple" is mostly a matter of "understanding". Is algebra simple? I think that will depend on whether you ask a 10 year old or a 15 year old. As for how I know the problem is in the C code, it's because of the particular check. Because I understand how C and Scheme interact, you're not going to get a gtk warning from anything "wrong" in the scheme side. Or if you do, it's going to be that it gives you the wrong value. That warning message says that a C struct member is NULL when it shouldnm't be. As for where you should start looking for this bug, start at the error message and then work backwards, the same way you'd work on any other bug. > Wow. Is it necessary to wrap all symbols like that? If not all, > which ones are required? It depends. "find | xargs grep" is useful to figure out which ones are used. But exporting the symbols is what gives us the nice scheme bindings. >> > What if I don't want a notebook with a single tab? >> >> Then fix dialog-accounts.c to hide the notebook when there's a single >> tab. > > 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. So take the file size with a pound of salt; you're not seeing the statistics that you think you are. >> I don't see how the new api is any simpler for a user. Seriously, I don't. >> What's so hard about using the various existing APIs: >> >> gnc_option_db_lookup__option() and >> gnc_option_db_set__option() > > Don't forget gnc_option_db_commit, and all the gnc_option_dialog_* > functions. Most of those functions aren't necessary by the average user. Sure, you need the "create" and callbacks, but that's about it, really. Certainly it's no more complicated than your API. > That was just an outline. I left out the details. I think I wrote > that. It was a fairly complete outline. So we add a few helpers to reduce the "normal" complexity. Go take a look at the File Properties code. It's not a lot of code to create and instantiate that dialog. Granted, much of it is done in Scheme, but still. > I recognize that scheme IS well-suited for configuration > specification, but it's being used for much else right now in gnucash. True... > I don
Re: a request for the next 1.8.* version
On Wednesday 16 February 2005 20:05, Derek Atkins wrote: > Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > > The problem on mips is a trivial one: gnucash works on mips, it's a > > minor build system problem that prevents it. > > If it's truly a minor build system problem then a "minor" patch to > correct it might be reasonable. Although I really hope we don't have > another 1.8 release... We may not have much of a choice, the OFX import is pretty much broken for checks. -- Benoit Grégoire, http://benoitg.coeus.ca/ pgpzqsC33bljd.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [RFC] A differnt options system
On Wed, Feb 16, 2005 at 07:49:17PM -0500, Derek Atkins wrote: > Chris Shoemaker <[EMAIL PROTECTED]> writes: > > Would you consider gnc-plugin-page-account-tree.c a normal user of the > > optionDB? If so, I really don't think it's a documentation problem. > > But, I'm sure documentation would help a lot. > > Yes and no. I think there are a bunch of helper functions that exist > which that code doesn't use. I didn't mean, "is it complete?" I think its too complicated for what it's doing. > > >> Define "object properties"? Do you mean something like how the File > >> -> Properties dialog or the [ Options ] toolbar button work? Or do > >> you mean something else? > > > > Yes, I think I would call those "book properties." Edit->Preferences > > is what I'm calling overall program preferences. What you see when > > you click "Edit" in the account-tree-view-page is what I would call > > "account properties". BTW, why can't I edit account properties from > > the account page?!? Am I missing something? > > The "account properties" are really properties of the account tree, > not any particular single "account". That's why you edit them from > where you do. No, I really mean account properties, like account name and account type. I know that the tree-view options are reachable from the tree-view-page. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [RFC] A differnt options system
On Wed, Feb 16, 2005 at 08:09:25PM -0500, Stephen Evanchik wrote: > I don't know much about the options code, but I do know that some of > your ideas may be important and quite relevant to making gnucash better. > Is it possible to incorporate them in to the existing code base even if > it takes longer and may be more difficult? I'm sorry, I don't understand the question. Could you elaborate? -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [RFC] A differnt options system
On Wed, 2005-02-16 at 20:24, Derek Atkins wrote: > scheme sort of has this dichotomy that merges the concept of code and > data. It's sorta the nature of the beast. *shrugs* Yah yah, I'm well aware of that... the problem, though, is that that flexibility comes with a price. Since the configuration is _anything_ you can never make simplifying assumptions about it. E.g., setting a boolean configuration option could end up doing a distributed transaction across a set of resources spread across the wider internet... or maybe it'll just invoke `(lambda () (quit))`. Which makes no sense. Or not. It's only the nature of the beast because our option-data-format is eval'ed lambdas instead of simply data. In code, it's useful to have code be data. In data, it's useful to have data _not_ be code. ...jsled -- http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [RFC] A differnt options system
On Wed, Feb 16, 2005 at 06:36:48PM -0500, Derek Atkins wrote: > Chris Shoemaker <[EMAIL PROTECTED]> writes: > > > Yes, it's AWFUL. It means on page one of the dialog I have 20 > > checkboxes down only the left side of the page. The dialog is as tall > > as my screen so all the options fit. Then on page two, I have two or > > three wide options scrunched up at the top. Both pages look awful. > > It's an HMI disaster, and there's NO way to avoid it if you have > > different shaped widgets. The generated gui layout is only marginally > > better than random widget placement! How's a programmer to create a > > friendly interface with that? > > 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? > > > By pure chance, I had to take a break from coding an hour ago to do > > finances. For my real books, I still use 1.8.9. I was in a P&L > > report, and checking the boxes for subtotaling (which by the way are > > laid out *worse* than random, because they are misleading about which > > field go with with key) when I saw: > > I think that's a labeling issue; you'd have the same issue with any > other method... No. It's NOT a labeling issue. It's a widget spacing issue. Can't we agree that there's a good reason for visual grouping and space between widges? > Well, also keep in mind that there ARE a bunch of memory corruption > bugs in Gnucash. Also note that this is a bug in _C CODE_, so it > could just as easily happen in your code as it does in the existing > code. I'm getting the impression that you think I'm saying C code is better than scheme code. I'm not. I'm saying that simple is better than complex. Of course any code can have bugs, but not all C code is equally complex. Anyway, how do you _know_ that the bug is in the C code? Couldn't it be some C/guile/scheme interaction? That's really the point. Maybe _you_ know, and maybe you're right. But how would _I_ know where to start looking for a bug in code so complex? > The devil you know vs. the devil you don't, I suppose. Yes, but I've found a _littler_ devil. :) > > > I want to help fix bugs, really. But if people who have been hacking > > gnucash for years only understand the options system in part, what > > chance do I have after only a few months? > > I know you do.. But replacing working subsystems is not necessarily a > good way to do that. If it were working, I would've finished in December. :( > >> That's not quite true. Yes, you need to define the list in the option > >> definition in scheme, but what those values mean is up to you later. > >> You could define them in one place and export to the other, or you can > >> define in two places and keep them in sync. That's just a matter of > >> programming. > > > > Exactly, so if I want to display an option with a new enumeration, I > > have to either duplicate the list or figure out how to "export" from > > one language to the other. I hope you can see how non-trivial that is > > for people other than yourself. > > Exporting from C to Scheme is absolutely trivial. > See src/engine/gw-engine-spec.scm for tons of examples. Also see > guile-utils.c for C code to help you translate back and forth. > > The code is there.. It's just not well documented. Wow. Is it necessary to wrap all symbols like that? If not all, which ones are required? > > What if I don't want a notebook with a single tab? > > Then fix dialog-accounts.c to hide the notebook when there's a single > tab. I assume you mean dialog-options.c. I'm sure what you describe is possible, but I want to point something out: [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? > > > IMO, my proposal makes both adding new options and using existing > > options easier. As for using options, look at how > > gnc-plugin-page-account-tree.c uses the options system. Compare that > > to the equivalent functionality with the proposed api. Conceptually, > > it's quite similar, especially w.r.t storage, but as for ease of use, > > the proposed api is much simpler. > > I don't see how the new api is an
Re: a request for the next 1.8.* version
Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > Here are two options. The first is preferred; the second is slightly > more conservative. > > Now autogen.sh seems to run aclocal, which will clobber changes to > aclocal.m4. I don't know what needs to be done to prevent that, or if > it is not a real worry. The gnucash build system baffles me. :) The key is to change acinclude.m4, actually ;) Then it'll get into aclocal.m4 when autogen runs aclocal. I'll take a look at these patches in a bit. Thanks. > Thomas -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 [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: a request for the next 1.8.* version
Derek Atkins <[EMAIL PROTECTED]> writes: > Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > > > I can provide the details upon request. > > Can you send a patch? I know we've applied aclocal.m4 changes for, > e.g., OSX. Here are two options. The first is preferred; the second is slightly more conservative. Now autogen.sh seems to run aclocal, which will clobber changes to aclocal.m4. I don't know what needs to be done to prevent that, or if it is not a real worry. The gnucash build system baffles me. :) patch-1 Description: Binary data patch-2 Description: Binary data Thomas ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [RFC] A differnt options system
On Wed, 2005-02-16 at 13:55 -0500, Chris Shoemaker wrote: > > Granted, it's MUCH easier to use them from scheme than it is to use > > them from C, but that's just due to the way it was designed. > > Yes, you're exactly right. But who do we want to attract to hack on > gnucash? more scheme programmers or C programmers? We should make it > easier for whoever we want to attract. Well, I know C and Scheme and at the risk of being a bit of an elitist: a competent programmer should be able to pick up a language over the course of a week. It's not reasonable to expect them to be a master at the end of the week, but they should be able to stumble around and use pre-existing code. An iterative process is key. "You" in the following context is really any developer reading this: If you are having trouble using the APIs you should confirm whether you are understanding them fully. I doubt that the designers of the API intended it to be difficult to accomplish routine tasks. Ask questions and seek guidance before expending a tremendous amount of work on something that will be shot down because it is too narrow an implementation or solves the wrong problem entirely. > > > > > they're not going to be real impressed with the Gnucash codebase. > > > > That's true anyways. Find 10 "new" developers and you'll probably get > > them pointing at 10 different ways the gnucash codeback sucks. > > You're right, but I see two problems: > > First, for every ten "new" developers discovering that gncuash > codebase sucks, only one will sit down, figure out why it sucks and > try to improve it. The other nine will say "gosh, this stuff blows my > mind; I'm gonna go work on something where I can make forward progress > without spending 3 months grokking this mess in the dark." People > like seeing the fruit of their labor -- it's human nature. Well, at this point it is probably better for us not to have 9 people asking questions and bombarding the list with patches that aren't acceptable. Changes should be interative in 95-plus-percent of development cases. Especially in the case of working with something that is functional albeit flawed. > > Second, we don't have 10 new developers. I'm one. I don't know much about the options code, but I do know that some of your ideas may be important and quite relevant to making gnucash better. Is it possible to incorporate them in to the existing code base even if it takes longer and may be more difficult? Stephen ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [RFC] A differnt options system
Josh Sled <[EMAIL PROTECTED]> writes: > As well, there's a partially-mentioned aspect that I personally have a > problem with, which is that the option "db" is generated scheme code > which is then eval'ed at startup, rather than simply being the raw > _data_ that it is. scheme sort of has this dichotomy that merges the concept of code and data. It's sorta the nature of the beast. *shrugs* > I (and Derek) are totally sympathetic to the complexity. But I don't > see how your proposal works within the existing code to make things > significantly better. Reducing complexity is always a good thing, provided you don't lose (real, usable) functionality in the process. > FTR, this is _always_ the rub with gnucash development, generally ... > there's a bunch of things exactly like this. My mental cycle each time > is "fsck it! nuke it and start over" ... "oh, wait ... there's years of > work that would need to be re-written, and can't really be salvaged". I feel the same way about QOF and the hole query/save object system. I feel the same way about all the gpointers we have everywhere. I'd much rather use a type-safe object system But you know what? That's a LOT of work. So I need to either ignore it, or make small adjustments here and there. > We need to /evolve/ our way out of this mess. In some places that's > more true than others ... I think the register should simply be > re-written, for instance. But the options stuff is a bit too core for > that treatment, and I don't think it's warranted. Agreed, it needs to be an evolution. Small steps. Let's get the API better documented. Let's add the helper functions we need to make it easier to use. Let's flush out the API that you need to get the functionality you need. > ...jsled -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 [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: a request for the next 1.8.* version
Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > I can provide the details upon request. Can you send a patch? I know we've applied aclocal.m4 changes for, e.g., OSX. > Thomas -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 [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [RFC] A differnt options system
I'm jumping into this thread late, since I had RealJob to do this afternoon. My summarized take after catching up on it all: 1/ We're all in agreement that the current options stuff is less-than-optimal, to various degrees. 2/ Your proposal doesn't have feature-parity with the existing system, which is a problem. I believe that when it does, it'll have similar complexity to the existing options stuff. Specifically, I think there are 3 distinct facets to the options stuff in discussion: 1/ option-type declaration a/ Enumerated types 2/ option-editing dialog building and runtime 3/ option-value persistance Your proposal relates to these in the following way: 1/ the mapping between types and widgets is in the code a/ 2/ half-defer to glade/gtk; cut-and-paste 3/ As well, there's a partially-mentioned aspect that I personally have a problem with, which is that the option "db" is generated scheme code which is then eval'ed at startup, rather than simply being the raw _data_ that it is. I think the way to clean this stuff up is: 1/ flip the "authority" of the option-db implementation from scheme to C. [It's probably best to do this after moving away from g-wrap, so we don't need to change it again, but whatever...] 2/ clean up the API; phrasing, language, consistency, size and documentation. 3/ clean up the option-value persistance and loading so it's less weird, less dependent on scheme; use gconf and in-backend data where appropriate [as opposed to book-parallel configuration storage]. 4/ have better option layout support, via some declarative/gui-building language. 5/ document how to do things like add a type, deal with sections, get specific layouts, ... I (and Derek) are totally sympathetic to the complexity. But I don't see how your proposal works within the existing code to make things significantly better. FTR, this is _always_ the rub with gnucash development, generally ... there's a bunch of things exactly like this. My mental cycle each time is "fsck it! nuke it and start over" ... "oh, wait ... there's years of work that would need to be re-written, and can't really be salvaged". We need to /evolve/ our way out of this mess. In some places that's more true than others ... I think the register should simply be re-written, for instance. But the options stuff is a bit too core for that treatment, and I don't think it's warranted. ...jsled -- http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: a request for the next 1.8.* version
Derek Atkins <[EMAIL PROTECTED]> writes: > Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > > > The problem on mips is a trivial one: gnucash works on mips, it's a > > minor build system problem that prevents it. > > If it's truly a minor build system problem then a "minor" patch to > correct it might be reasonable. Although I really hope we don't have > another 1.8 release... Well, the minor patch--if you don't upgrade any build tools--would require a tweak inside aclocal.m4 for the libtool macro included there. Basically, you need to tell the libtool macro to stop using the output of "file" to recognize ELF shared libraries on a linux-gnu system, and instead assume that every library is always ELF. It already makes that assumption for certain arch's. Since the arch's not in its list are now only supported by Debian, and Debian is ELF-only, there is nothing really destabilizing there. I can provide the details upon request. Thomas ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: a request for the next 1.8.* version
Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > The problem on mips is a trivial one: gnucash works on mips, it's a > minor build system problem that prevents it. If it's truly a minor build system problem then a "minor" patch to correct it might be reasonable. Although I really hope we don't have another 1.8 release... -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 [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: a request for the next 1.8.* version
Derek Atkins <[EMAIL PROTECTED]> writes: > > We just had two releases of 1.8 in a row to fix bugs; gnucash *cannot* > > build on mips due purely to the way-way-way out-of-date build tools, > > and using even newer versions of the old versions of the build tools > > invariably breaks the build system and causes pain. > > It doesn't build on 6502, either. Your point? I'm sure there are > lots of platforms gnucash doesn't work on. gnucash 1.8 is old code. > We're still maintaining it some, but that's not the focus of > development. The problem on mips is a trivial one: gnucash works on mips, it's a minor build system problem that prevents it. > 1.8? Unlikely. As you said, using newer versions of the build tools > invariably breaks the build system and causes pain. 1.8 is supposed > to be _STABLE_ -- breaking the build is inherently unstable. We had a > pair of releases in a row because we had a real data corruption > problem. Data corruption != build problem on some random > way-out-there platforms. Ok, I understand. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: a request for the next 1.8.* version
Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > What kind of time frame are you actually talking about? Later this year, we hope. We're really really trying to complete the g2 port. Some of the devs have become more active, and we have a few new people who have started helping. > This link is not comforting, for it reports that the gnome2 port is > "nowhere near being usable accounting software". This is what I > already report to Debian users who ask about it too. I say that > upstream is working on the gnome2 version, which is unfortunately > nowhere near ready. That is certainly true today. Ask again April 1 and we'll see. > We just had two releases of 1.8 in a row to fix bugs; gnucash *cannot* > build on mips due purely to the way-way-way out-of-date build tools, > and using even newer versions of the old versions of the build tools > invariably breaks the build system and causes pain. It doesn't build on 6502, either. Your point? I'm sure there are lots of platforms gnucash doesn't work on. gnucash 1.8 is old code. We're still maintaining it some, but that's not the focus of development. > Someone has to do the work; does the gnome-2 branch use new auto* > tools? That is, *not* autoconf-1.4? and *not* libtool-1.4? Yes, it uses new autotools. It has not (yet) been upgraded to a newer libtool, but we plan to do that. > If a Debian developer were to revamp the build system for 1.8 so that > it works on modern systems, would there be any chance of having it > folded into a release of the 1.8 branch? 1.8? Unlikely. As you said, using newer versions of the build tools invariably breaks the build system and causes pain. 1.8 is supposed to be _STABLE_ -- breaking the build is inherently unstable. We had a pair of releases in a row because we had a real data corruption problem. Data corruption != build problem on some random way-out-there platforms. If you have Debian Developers who want to help complete the g2 port, we'll gladly fold patches into the g2 tree. > Thomas -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 [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [RFC] A differnt options system
Chris Shoemaker <[EMAIL PROTECTED]> writes: > On Wed, Feb 16, 2005 at 02:52:25PM -0500, Derek Atkins wrote: >> >> That was David saying that, but I' understand it about 75%. And yes, >> I _COULD_ flush out the C api -- tell me which APIs you need (which is >> where you should have started in this whole thing, and was exactly why >> I asked at the beginning "what's wrong with it?" :) > > In my defense, I really did bring this up on Jan 4th. I hope that > post plus some of the ones in this thread have covered some of the C > API problems. In my defense, I was still on holiday on Jan 4th and was coping with parents, sick mothers-in-law, and sister with baby (my first nephew).. So I was somewhat distracted at that point in time, too. > Would you consider gnc-plugin-page-account-tree.c a normal user of the > optionDB? If so, I really don't think it's a documentation problem. > But, I'm sure documentation would help a lot. Yes and no. I think there are a bunch of helper functions that exist which that code doesn't use. >> Define "object properties"? Do you mean something like how the File >> -> Properties dialog or the [ Options ] toolbar button work? Or do >> you mean something else? > > Yes, I think I would call those "book properties." Edit->Preferences > is what I'm calling overall program preferences. What you see when > you click "Edit" in the account-tree-view-page is what I would call > "account properties". BTW, why can't I edit account properties from > the account page?!? Am I missing something? The "account properties" are really properties of the account tree, not any particular single "account". That's why you edit them from where you do. >> Are you trying to improve the maintainability of something like the >> customer, vendor, etc. dialogs which are really just a bunch of >> getter/setters with very little logic? > > I hadn't considered those, but I guess, yes, I am, at least some of > them. BTW, when I looked at one of those I got: > (gnucash:16049): Gtk-WARNING **: gtksettings.c:739: an rc-data property > "gtk-toolbar-style" already exists > (gnucash:16049): Gtk-WARNING **: gtksettings.c:739: an rc-data property > "gtk-toolbar-icon-size" already exists > > and gnucash segfaulted, but I think I saw enough to know what you're asking. In the g2 branch, I'm not surprised. Unfortunate.. Then again I have no idea where these errors are coming from. -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 [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: a request for the next 1.8.* version
Neil Williams <[EMAIL PROTECTED]> writes: > On Wednesday 16 February 2005 8:43 pm, Thomas Bushnell BSG wrote: > > There are a number of build problems, particulary on mips, but some > > other archs too, which are the end result of gnucash using quite > > outdated auto* tools. > > > > Would it be possible for the next 1.8.* release . . . > > There might not be another release from the 1.8 tree - it's hoped that the > long awaited Gnome2 port will be the next release and this will remove the > dependencies on Gnome1.4 tools. It's not about "gnome1.4 tools". It's about old *build* tools, that is, autoconf, libtool, and automake. > http://gnomesupport.org/wiki/index.php/GnuCashPortingStatus What kind of time frame are you actually talking about? This link is not comforting, for it reports that the gnome2 port is "nowhere near being usable accounting software". This is what I already report to Debian users who ask about it too. I say that upstream is working on the gnome2 version, which is unfortunately nowhere near ready. We just had two releases of 1.8 in a row to fix bugs; gnucash *cannot* build on mips due purely to the way-way-way out-of-date build tools, and using even newer versions of the old versions of the build tools invariably breaks the build system and causes pain. Someone has to do the work; does the gnome-2 branch use new auto* tools? That is, *not* autoconf-1.4? and *not* libtool-1.4? If a Debian developer were to revamp the build system for 1.8 so that it works on modern systems, would there be any chance of having it folded into a release of the 1.8 branch? Thomas ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: access_method and new, empty, sessions.
Neil Williams <[EMAIL PROTECTED]> writes:
> On Wednesday 16 February 2005 9:30 pm, Derek Atkins wrote:
>> > I'm now trying to see how it can work when qof_session_new() and
>> > qof_session_begin() are called where no content exists, i.e. new, empty,
>> > sessions.
>>
>> You mean what to do when we use File -> Save As?
>
> Yes, as well as Report->Export data, or any other situation where certain
> entities from an existing book are to be saved / exported.
Uh, Report->Export exports the HTML results of the report... I don't think
QSF applies in that case.
> It's tied in with those qof_entity_copy routines - a regular GnuCash book
> can't save a QofBook that doesn't follow the AccountGroup hierarchy, so if
> this isn't a complete file, just a selection of entities, the user should
> expect that a suitable format is used.
Agreed.
> I'd rather that each of the qof_entity_copy functions (and anything else)
> that
> create partial books are not forever tied to a specific backend.
Agreed. They shouldn't need to be tied to a specific backend.
> I'd prefer a general usage function in qof_session.c that allows a different
> way of selecting amongst the existing file:/ backends - bearing in mind the
> two systems too, gnc_mod and load_library.
Yea.. Not sure the best way to handle that.
>> Where are the cases when
>> this is an issue? AFAICT it's only an "issue" during File -> New File
>> or when you run (effectively) gnucash --nofile. At that point the
>> user clicking on "save" is effectively calling Save As.
>
> At present, qof_session_save doesn't do that, it simply calls whatever
> backend
> was selected by qof_session_begin which in turn relies on the access_method.
Oh? So File -> New File does... what? There's no backend associated
with it. Simiarly File -> Save As, what does that do?
> How would qof_session_save determine the nature of the contents of the
> QofBook? (without converting the entire book to each format in turn so that
> the existing file_type routines could be used!)
>
> What about if the qof_entity_copy routines put a flag in qof_book_set_data()
> that can also be set by any other routines that will result in partial books?
That's probably a good idea, so you keep track of full books
v. partial books. We know that the gnucash file backends (xmlv1,
xmlv2, and sqlite) will all be full books, but qsf is not guaranteed
to be a full book. So you should treat them as such. Partial books
cannot be "loaded", only "merged".
"Save" isn't as much of an issue -- you can "save" only into the
gnucash formats, and only from full books. You can "export" partial
data, and only into qsf. The only exception to this would be the
(eventual) export gnc-xml, but I suppose that could just be a Save As
option.
> save could then use that to destroy the old backend, create a new one and
> execute the save?
Hmm.. Maybe..
> If the flag had different values for QSF and SQLite, qof_session_save could
> know how to find the _new() routines for the required backend.
>
> Maybe an enum?
No, enums are bad.. Not pluggable. Use a glist or hash table.
> qof_book_set_data(book, "partial_status", partial_book);
maybe.
> Maybe the results of partial_book in a switch could call a specific backend
> using prov->description?
> switch (partial_book) {
> case QSF :
> if(0 == safe_strcmp("QSF Backend Version 0.1", prov->description)) {
> if (NULL == prov->backend_new) continue;
> }
> break;
>
> (the default would be gnc-backend-v2)
Well, until the default is sqlite ;)
> Only if changing the backend would cause problems for a live book - after
> data
> had been added or modified.
>
> Can you see any problems with changing the backend of a book in use?
"Save As" does it..
> OK, that'll be file:// too, so that would use the same system - if we choose
> to use a flag in the book data that is set by any routines that require a
> certain file backend?
>
> Make it part of the API - if you create a QofBook that cannot or should not
> be
> saved by the default GnuCash-xml-v2 file backend, specify the type of backend
> in the book data . . .
Could be... We definitely need to keep track of whether a book is a
Full Book or a Partial Book and act accordingly.
-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
[EMAIL PROTECTED]PGP key available
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [RFC] A differnt options system
On Wed, Feb 16, 2005 at 02:52:25PM -0500, Derek Atkins wrote: > > That was David saying that, but I' understand it about 75%. And yes, > I _COULD_ flush out the C api -- tell me which APIs you need (which is > where you should have started in this whole thing, and was exactly why > I asked at the beginning "what's wrong with it?" :) In my defense, I really did bring this up on Jan 4th. I hope that post plus some of the ones in this thread have covered some of the C API problems. > > >> Isn't this something that a bunch of documentation would fix? We've > >> certainly had a dearth of developer docs in the code. We've > >> definitely been working on fixing that. > > > > Unfortunately, I don't think this is a documentation problem. Look at > > the number of functions in option-util.h. And look at how many public > > functions use the SCM type. Even if they were all documented, this is > > a complex API, that uses some unusual programming idioms. (However, > > several portions of this api appear not be used much if at all.) And > > this is only part of the options triad. > > IMHO it really is a documentation issue. Many of those option-util > functions that take a SCM thunk are just meant to be used from the > dialog-options code, not from option-user code. The documentation > part that I see there is clearing up what's meant to be the API > between the options-db and the options-dialog, and what's the API for > normal users of the option DB. Would you consider gnc-plugin-page-account-tree.c a normal user of the optionDB? If so, I really don't think it's a documentation problem. But, I'm sure documentation would help a lot. > >> I'm not trying to defend the existing options code. It took me a long > >> time to grok it, and frankly I'd certainly rather see code written in > >> C with scheme wrappers than the current code-in-scheme with C > >> pull-outs. Well, if we add scheme wrappers, isn't that what we're looking at now? > >> But gconf doesn't fit as a drop-in replacement. Again, I really don't know much about gconf, but maybe it's well-suited for saving overall program preferences. > > > > I completely agree. gconf may only solve one particular piece of the > > problem, (just as libglade may only solve one piece.) Incidentally, > > I'm more concerned about the "object properties" type of option > > dialog, because it's a more common task than the overall program > > preferences dialog. > > Define "object properties"? Do you mean something like how the File > -> Properties dialog or the [ Options ] toolbar button work? Or do > you mean something else? Yes, I think I would call those "book properties." Edit->Preferences is what I'm calling overall program preferences. What you see when you click "Edit" in the account-tree-view-page is what I would call "account properties". BTW, why can't I edit account properties from the account page?!? Am I missing something? > >> It IS kind of nice to have a single API that we can use for global > >> options, book options, report options, etc. I wouldn't want to lose > >> that. > > > > I agree that that's ideal. But note that we don't really meet that > > ideal now. For example, just look at the glade files that contain > > "option dialog"-type widgets. These users aren't using the > > GNCOptionDB API, but they're doing essentially similar things. I kind > > of think of my options proposal as a regularization of that paradigm > > that's already in use. > > Are you trying to improve the maintainability of something like the > customer, vendor, etc. dialogs which are really just a bunch of > getter/setters with very little logic? I hadn't considered those, but I guess, yes, I am, at least some of them. BTW, when I looked at one of those I got: (gnucash:16049): Gtk-WARNING **: gtksettings.c:739: an rc-data property "gtk-toolbar-style" already exists (gnucash:16049): Gtk-WARNING **: gtksettings.c:739: an rc-data property "gtk-toolbar-icon-size" already exists and gnucash segfaulted, but I think I saw enough to know what you're asking. It left this is the trace file, but I don't know if it's related: could not find signal handler 'gnc_main_window_exit_cb'. could not find signal handler 'gnc_main_window_file_save_cb'. could not find signal handler 'gnc_main_window_prices_cb'. could not find signal handler 'gnc_main_window_file_save_as_cb'. could not find signal handler 'gnc_main_window_totd_cb'. could not find signal handler 'gnc_main_window_fincalc_cb'. could not find signal handler 'gnc_main_window_gl_cb'. could not find signal handler 'gnc_main_window_about_cb'. could not find signal handler 'gnc_main_window_help_cb'. could not find signal handler 'gnc_main_window_commodities_cb'. > > It sounds like you want dwi (dwi.sf.net). I don't think we're there, > yet. Perhaps eventually, maybe. Interesting. > > >> > believe that switching to a shared options system like gconf is the way > >>
Re: [RFC] A differnt options system
Chris Shoemaker <[EMAIL PROTECTED]> writes:
> Yes, it's AWFUL. It means on page one of the dialog I have 20
> checkboxes down only the left side of the page. The dialog is as tall
> as my screen so all the options fit. Then on page two, I have two or
> three wide options scrunched up at the top. Both pages look awful.
> It's an HMI disaster, and there's NO way to avoid it if you have
> different shaped widgets. The generated gui layout is only marginally
> better than random widget placement! How's a programmer to create a
> friendly interface with that?
The same way a programmer would have to do it with glade or any other
layout mechanism -- split the options onto separate pages..
> By pure chance, I had to take a break from coding an hour ago to do
> finances. For my real books, I still use 1.8.9. I was in a P&L
> report, and checking the boxes for subtotaling (which by the way are
> laid out *worse* than random, because they are misleading about which
> field go with with key) when I saw:
I think that's a labeling issue; you'd have the same issue with any
other method...
> ** CRITICAL **: file option-util.c: line 173
> (gnc_option_set_selectable): assertion `option->odb->set_selectable !=
> NULL' failed.
Hmm, okay.. This is certainly the first I've heard of this. And it
makes little sense to me. The code in question is:
void
gnc_option_set_selectable (GNCOption *option, gboolean selectable)
{
g_return_if_fail (option != NULL);
g_return_if_fail (option->odb != NULL);
g_return_if_fail (option->odb->set_selectable != NULL); <--- error here
option->odb->set_selectable (option, selectable);
}
> and the report behaved as if the box was checked when it wasn't. For
> me to see strange behavior like this is not uncommon -- I do what I
> always do. Close the options and reopen. You'd think this would be
> an easy bug to fix. Maybe it is, but knowing what I know, I'd guess
> it's probably not. :(
Well, also keep in mind that there ARE a bunch of memory corruption
bugs in Gnucash. Also note that this is a bug in _C CODE_, so it
could just as easily happen in your code as it does in the existing
code. The devil you know vs. the devil you don't, I suppose.
> I want to help fix bugs, really. But if people who have been hacking
> gnucash for years only understand the options system in part, what
> chance do I have after only a few months?
I know you do.. But replacing working subsystems is not necessarily a
good way to do that. You fix bugs by fixing bugs. Have you ever
looked at the Mozilla code base? How do you think they would feel if
you said you wanted to wholesale replace their
code?
I dont know. I rarely need to touch the code, so my knowledge of it
bitrots over time. It's been stable; the only major issue we've had
with the code was the guile-1.6 int vs. double issue. Between that
and adding the business options, and adding the code to save the
optiondb into the book kvp, I've not had to touch the code much at
all. That's why I don't understand it 100% -- I haven't had to LOOK
at it in a very long time.
>> That's not quite true. Yes, you need to define the list in the option
>> definition in scheme, but what those values mean is up to you later.
>> You could define them in one place and export to the other, or you can
>> define in two places and keep them in sync. That's just a matter of
>> programming.
>
> Exactly, so if I want to display an option with a new enumeration, I
> have to either duplicate the list or figure out how to "export" from
> one language to the other. I hope you can see how non-trivial that is
> for people other than yourself.
Exporting from C to Scheme is absolutely trivial.
See src/engine/gw-engine-spec.scm for tons of examples. Also see
guile-utils.c for C code to help you translate back and forth.
The code is there.. It's just not well documented.
> Well, the file you reference above contains:
> (define (gnc:account-get-type-string-plural type)
> (assoc-ref
>(list
> (cons 'bank (_ "Bank"))
> (cons 'cash (_ "Cash"))
[snip]
> I suppose that's not exactly independent of xaccAccount* and
> account_type_name[] in Account.c
It mostly is, actually. There's no order binding between them.
OTOH I'll note that even in the C code there are multiple places
where the list of accounts are enumerated in multiple forms and
need to be kept in sync, so..
> What if I don't want a notebook with a single tab?
Then fix dialog-accounts.c to hide the notebook when there's a single
tab.
> IMO, my proposal makes both adding new options and using existing
> options easier. As for using options, look at how
> gnc-plugin-page-account-tree.c uses the options system. Compare that
> to the equivalent functionality with the proposed api. Conceptually,
> it's quite similar, especially w.r.t storage, but as for ease of use,
> the proposed api is much simpler.
I don't see how the new api is any simpler for a user. Seriously, I don't.
Wh
Re: access_method and new, empty, sessions.
On Wednesday 16 February 2005 9:30 pm, Derek Atkins wrote:
> > I'm now trying to see how it can work when qof_session_new() and
> > qof_session_begin() are called where no content exists, i.e. new, empty,
> > sessions.
>
> You mean what to do when we use File -> Save As?
Yes, as well as Report->Export data, or any other situation where certain
entities from an existing book are to be saved / exported.
If, e.g. the user runs a report, that in turn may run certain queries and
other rules to select the entities to build into the report data. Using the
copy routines, all the entities behind the report could be put into a second
session and saved to QSF as an "export the report data" command. More than
just saving the presentation of the report, this would export the data set
behind the report - allowing data mining and customised report layouts using
external tools.
e.g. it should be possible to build a simple parser for QSF XML (in Perl, PHP,
whatever) that could reformat the data into bespoke invoices and other
customised layouts that are just too individual to warrant a report of their
own.
> I think in general
> from the user standpoint it's fairly "obvious" what they want. The
> user is never going to "File -> Save As" QSF, it's always going to
> save as the "primary" file:// method.
It's tied in with those qof_entity_copy routines - a regular GnuCash book
can't save a QofBook that doesn't follow the AccountGroup hierarchy, so if
this isn't a complete file, just a selection of entities, the user should
expect that a suitable format is used.
> > Is the access_method more of an identifier than a reflection of a
> > protocol?
>
> If I'm understanding what you're asking, yes. We're not using IANA
> protocol definitions in the discriminator. The "protocol" field is
> just a tool to allow the user to differentiate between different
> access methods. Generally they have two choices now, file:// or
> postgres://
OK.
> > How should I proceed to discriminate two backends that use the same
> > access_method when no content exists yet?
>
> Do you necessarily need to choose up front?
Come to think of it, probably not. After all, until the data needs to be
saved, it's just another QofBook.
When we need to save and decide which backend to use, we still need a way to
load a specific backend from amongst the file:// access_methods.
I can use qof_session_destroy_backend(session), then initialise a known
backend directly using qof_book_set_backend() - it's about how to pick one
from many file:/ backends.
I'd rather that each of the qof_entity_copy functions (and anything else) that
create partial books are not forever tied to a specific backend.
I'd prefer a general usage function in qof_session.c that allows a different
way of selecting amongst the existing file:/ backends - bearing in mind the
two systems too, gnc_mod and load_library.
> Where are the cases when
> this is an issue? AFAICT it's only an "issue" during File -> New File
> or when you run (effectively) gnucash --nofile. At that point the
> user clicking on "save" is effectively calling Save As.
At present, qof_session_save doesn't do that, it simply calls whatever backend
was selected by qof_session_begin which in turn relies on the access_method.
How would qof_session_save determine the nature of the contents of the
QofBook? (without converting the entire book to each format in turn so that
the existing file_type routines could be used!)
What about if the qof_entity_copy routines put a flag in qof_book_set_data()
that can also be set by any other routines that will result in partial books?
save could then use that to destroy the old backend, create a new one and
execute the save?
If the flag had different values for QSF and SQLite, qof_session_save could
know how to find the _new() routines for the required backend.
Maybe an enum?
typedef enum partial_book {
GnuCash = 0,
QSF,
SQLite
};
?
qof_book_set_data(book, "partial_status", partial_book);
?
Maybe the results of partial_book in a switch could call a specific backend
using prov->description?
switch (partial_book) {
case QSF :
if(0 == safe_strcmp("QSF Backend Version 0.1", prov->description)) {
if (NULL == prov->backend_new) continue;
}
break;
(the default would be gnc-backend-v2)
> > Should I use and support:
> > session = qof_session_new();
> > qof_session_begin(session, "qsf:/somefile.xml", TRUE, FALSE);
> >
> > using an arbitrary qsf:/ access_method?
>
> If you want. Do you need to do so?
Only if changing the backend would cause problems for a live book - after data
had been added or modified.
Can you see any problems with changing the backend of a book in use?
> > (Loading an existing file that contains QSF data using file:// will still
> > load it as a QSF file.)
> >
> > Is there an alternative method?
>
> I don't know, I haven't looked at that code extensively. But keep in
> mind that it's going to get much more complex o
Re: [RFC] A differnt options system
On Wed, Feb 16, 2005 at 02:30:27PM -0500, Derek Atkins wrote: > > > * But... there are cases where everything doesn't work perfectly, and > > * there are cases where things work, but painfully: > > * > > * 1) GncOptionWin's option layout is quite flat. Linear layout order > > * can be specified in the scheme option definition, but that's it. > > Well, not quite. You supply a page and a layout order on the page. > True, you can't put options next to each other, but is that > necessarily a bad thing? Agreed, the options system is not meant to > be a generic dialog builder. Is that really a problem? Yes, it's AWFUL. It means on page one of the dialog I have 20 checkboxes down only the left side of the page. The dialog is as tall as my screen so all the options fit. Then on page two, I have two or three wide options scrunched up at the top. Both pages look awful. It's an HMI disaster, and there's NO way to avoid it if you have different shaped widgets. The generated gui layout is only marginally better than random widget placement! How's a programmer to create a friendly interface with that? > > > * 2) Some option types are buggy. > > Oh? Which ones? If there are buggy option types that should > definitely be fixed! This is the first I've heard of buggy options. By pure chance, I had to take a break from coding an hour ago to do finances. For my real books, I still use 1.8.9. I was in a P&L report, and checking the boxes for subtotaling (which by the way are laid out *worse* than random, because they are misleading about which field go with with key) when I saw: ** CRITICAL **: file option-util.c: line 173 (gnc_option_set_selectable): assertion `option->odb->set_selectable != NULL' failed. and the report behaved as if the box was checked when it wasn't. For me to see strange behavior like this is not uncommon -- I do what I always do. Close the options and reopen. You'd think this would be an easy bug to fix. Maybe it is, but knowing what I know, I'd guess it's probably not. :( I want to help fix bugs, really. But if people who have been hacking gnucash for years only understand the options system in part, what chance do I have after only a few months? > > * 4) Reusing groups of options isn't easy. There's probably some way > > * to define the option list as a concatenation of smaller option > > * lists, but I don't think there are any examples of this. > > It's very easy, and there are examples. See > gnc:options-add-account-selection! > in src/reports/report-system/options-utilities.scm for one example. > Basically you write a scheme procedure that defines the block of > options you want to create. Thanks for pointing that out. I knew it should be possible. > > > * 5) If you're storing option values in C as enumerated types > > * (multi-choice option type), you'll need to specify the enumeration > > * in C and in Scheme, and keep them in sync. > > That's not quite true. Yes, you need to define the list in the option > definition in scheme, but what those values mean is up to you later. > You could define them in one place and export to the other, or you can > define in two places and keep them in sync. That's just a matter of > programming. Exactly, so if I want to display an option with a new enumeration, I have to either duplicate the list or figure out how to "export" from one language to the other. I hope you can see how non-trivial that is for people other than yourself. > Can you show me an example where there's a list that needs to be > kept in sync between scheme and C? Well, the file you reference above contains: (define (gnc:account-get-type-string-plural type) (assoc-ref (list (cons 'bank (_ "Bank")) (cons 'cash (_ "Cash")) (cons 'credit (_ "Credits")) (cons 'asset (_ "Assets")) (cons 'liability (_ "Liabilities")) (cons 'stock (_ "Stocks")) (cons 'mutual-fund (_ "Mutual Funds")) (cons 'currency (_ "Currencies")) (cons 'income (_ "Income")) (cons 'expense (_ "Expenses")) (cons 'equity (_ "Equities")) (cons 'checking (_ "Checking")) (cons 'savings (_ "Savings")) (cons 'money-market (_ "Money Market")) (cons 'receivable (_ "Accounts Receivable")) (cons 'payable (_ "Accounts Payable")) (cons 'credit-line (_ "Credit Lines"))) type)) I suppose that's not exactly independent of xaccAccount* and account_type_name[] in Account.c > > > * 6) Your options are displayed in a GtkNotebook page. I hope that's > > * what you want, because that's the way it is. > > And why is this a problem? It's just a bunch of options. If you have > multiple pages how ELSE would display them other than a GtkNotebook? > What other multi-page dialog method would you use? A Druid? What if I don't want a notebook with a single tab? > > > *Of course these problems are probably solvable by improving > > * GNCOptionWin and GncOptionDB and the Scheme options system. But, > > * t
Re: access_method and new, empty, sessions.
Neil Williams <[EMAIL PROTECTED]> writes: > In the g2 branch, I adapted qofsession.c to handle QSF using the QOF > load_backend_library routine in qof_session_load_backend(). > > Loading an existing file is handled fine, because the routines inspect the > file contents and report back on what kind of content is found. QSF needs a > few more tweaks to load files properly but g2 always tells the difference > between gnucash-xml-v2, v1 or binary vs QSF. That's good - the access_method > is not a problem here. > :-) > > (The tweaked code will be in CVS - g2 - soon, it's working locally). Excellent. > I'm now trying to see how it can work when qof_session_new() and > qof_session_begin() are called where no content exists, i.e. new, empty, > sessions. You mean what to do when we use File -> Save As? I think in general from the user standpoint it's fairly "obvious" what they want. The user is never going to "File -> Save As" QSF, it's always going to save as the "primary" file:// method. > Is the access_method more of an identifier than a reflection of a protocol? If I'm understanding what you're asking, yes. We're not using IANA protocol definitions in the discriminator. The "protocol" field is just a tool to allow the user to differentiate between different access methods. Generally they have two choices now, file:// or postgres:// > Can we invent new access_method strings that have no basis in real protocols? Yes. We had rpc:// which isn't a "real" protocol (at least as far as IANA is concerned). > (Dialogs and other code can determine which is to be used, there's no reason > for users to worry or know about the access_method - is there?) In general this is true. I suspect there will be multiple dialogs (or perhaps a "file format" option in a combined dialog) to let the user choose what format they want to use when saving/exporting data. > How should I proceed to discriminate two backends that use the same > access_method when no content exists yet? Do you necessarily need to choose up front? Where are the cases when this is an issue? AFAICT it's only an "issue" during File -> New File or when you run (effectively) gnucash --nofile. At that point the user clicking on "save" is effectively calling Save As. > Should I use and support: > session = qof_session_new(); > qof_session_begin(session, "qsf:/somefile.xml", TRUE, FALSE); > > using an arbitrary qsf:/ access_method? If you want. Do you need to do so? > (Loading an existing file that contains QSF data using file:// will still > load > it as a QSF file.) > > Is there an alternative method? I don't know, I haven't looked at that code extensively. But keep in mind that it's going to get much more complex once we add SQLite to the mix. -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 [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: a request for the next 1.8.* version
On Wednesday 16 February 2005 8:43 pm, Thomas Bushnell BSG wrote: > There are a number of build problems, particulary on mips, but some > other archs too, which are the end result of gnucash using quite > outdated auto* tools. > > Would it be possible for the next 1.8.* release . . . There might not be another release from the 1.8 tree - it's hoped that the long awaited Gnome2 port will be the next release and this will remove the dependencies on Gnome1.4 tools. http://gnomesupport.org/wiki/index.php/GnuCashPortingStatus -- Neil Williams = http://www.dcglug.org.uk/ http://www.nosoftwarepatents.com/ http://sourceforge.net/projects/isbnsearch/ http://www.neil.williamsleesmill.me.uk/ http://www.biglumber.com/x/web?qs=0x8801094A28BCB3E3 pgpenRlkUlup5.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
access_method and new, empty, sessions.
In the g2 branch, I adapted qofsession.c to handle QSF using the QOF load_backend_library routine in qof_session_load_backend(). Loading an existing file is handled fine, because the routines inspect the file contents and report back on what kind of content is found. QSF needs a few more tweaks to load files properly but g2 always tells the difference between gnucash-xml-v2, v1 or binary vs QSF. That's good - the access_method is not a problem here. :-) (The tweaked code will be in CVS - g2 - soon, it's working locally). I'm now trying to see how it can work when qof_session_new() and qof_session_begin() are called where no content exists, i.e. new, empty, sessions. Is the access_method more of an identifier than a reflection of a protocol? Can we invent new access_method strings that have no basis in real protocols? (Dialogs and other code can determine which is to be used, there's no reason for users to worry or know about the access_method - is there?) How should I proceed to discriminate two backends that use the same access_method when no content exists yet? Should I use and support: session = qof_session_new(); qof_session_begin(session, "qsf:/somefile.xml", TRUE, FALSE); using an arbitrary qsf:/ access_method? (Loading an existing file that contains QSF data using file:// will still load it as a QSF file.) Is there an alternative method? -- Neil Williams = http://www.dcglug.org.uk/ http://www.nosoftwarepatents.com/ http://sourceforge.net/projects/isbnsearch/ http://www.neil.williamsleesmill.me.uk/ http://www.biglumber.com/x/web?qs=0x8801094A28BCB3E3 pgpZIoTdjrRou.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
a request for the next 1.8.* version
There are a number of build problems, particulary on mips, but some other archs too, which are the end result of gnucash using quite outdated auto* tools. Would it be possible for the next 1.8.* release to use libtool 1.5* and autoconf 1.50*? This requires some working getting things "up to speed" because some stuff has changed, but the files currently in place for gnucash are deprecated and really shouldn't be in production software anymore. Thomas ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [RFC] A differnt options system
Chris Shoemaker <[EMAIL PROTECTED]> writes: >> Because there isn't an alternative out there that has the same set of >> features that gnucash uses? > > The exact set? No, but there are alternatives that provide subsets of > those features, and usually they do a better job. Of course. I don't want yet another options API in gnucash. If we're going to replace the triad then the replacement had better have equivalent functionality. Otherwise you have to keep and maintain the triad and now maintain yet another optiondb API. That seems suboptimal. Granted, a theoretical replacement doesn't have to be API compatible with the existing triad, but it had better be feature compatible. >> >I had >> > a hard time understanding the options code myself when I first started, >> > and i wouldn't say that I understand more than 50% of it today. > > 50%! You're an expert! :) Maybe _you_ could flush out the C API? That was David saying that, but I' understand it about 75%. And yes, I _COULD_ flush out the C api -- tell me which APIs you need (which is where you should have started in this whole thing, and was exactly why I asked at the beginning "what's wrong with it?" :) >> Isn't this something that a bunch of documentation would fix? We've >> certainly had a dearth of developer docs in the code. We've >> definitely been working on fixing that. > > Unfortunately, I don't think this is a documentation problem. Look at > the number of functions in option-util.h. And look at how many public > functions use the SCM type. Even if they were all documented, this is > a complex API, that uses some unusual programming idioms. (However, > several portions of this api appear not be used much if at all.) And > this is only part of the options triad. IMHO it really is a documentation issue. Many of those option-util functions that take a SCM thunk are just meant to be used from the dialog-options code, not from option-user code. The documentation part that I see there is clearing up what's meant to be the API between the options-db and the options-dialog, and what's the API for normal users of the option DB. >> I'm not trying to defend the existing options code. It took me a long >> time to grok it, and frankly I'd certainly rather see code written in >> C with scheme wrappers than the current code-in-scheme with C >> pull-outs. But gconf doesn't fit as a drop-in replacement. > > I completely agree. gconf may only solve one particular piece of the > problem, (just as libglade may only solve one piece.) Incidentally, > I'm more concerned about the "object properties" type of option > dialog, because it's a more common task than the overall program > preferences dialog. Define "object properties"? Do you mean something like how the File -> Properties dialog or the [ Options ] toolbar button work? Or do you mean something else? >> It IS kind of nice to have a single API that we can use for global >> options, book options, report options, etc. I wouldn't want to lose >> that. > > I agree that that's ideal. But note that we don't really meet that > ideal now. For example, just look at the glade files that contain > "option dialog"-type widgets. These users aren't using the > GNCOptionDB API, but they're doing essentially similar things. I kind > of think of my options proposal as a regularization of that paradigm > that's already in use. Are you trying to improve the maintainability of something like the customer, vendor, etc. dialogs which are really just a bunch of getter/setters with very little logic? It sounds like you want dwi (dwi.sf.net). I don't think we're there, yet. Perhaps eventually, maybe. >> > believe that switching to a shared options system like gconf is the way >> > to go. That code is used by multiple applications (17 that I use on an >> > occasional or more frequent basis), is maintained by others, and is >> > already a dependency of gnucash. The only downside I see is the current >> > lack of per data file options. >> >> That's a serious downside, and one that gnucash uses everywhere. > > Obviously, gconf doesn't address that problem. Right, which is part of my complaint of proposing gconf. > -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 [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [RFC] A differnt options system
Chris Shoemaker <[EMAIL PROTECTED]> writes: > On Wed, Feb 16, 2005 at 01:05:31PM -0500, Derek Atkins wrote: >> Hi, >> >> It really is not bitrotting, why would you think it is? There is a C >> api and a scheme api that are tied together. Scheme is actually the >> primary API, so some of the C api is missing because nobody ever >> needed those particular functions. In other words, the C api was >> never fully implemented because it seemed silly to implement functions >> nobody was using. > > Well, to be fair, my evaluation is mostly based on the C api. I > didn't see any fundamental problems with the scheme api. But I want > to add functionality to gnucash using mostly C so I want to open > dialogs from C. Right. The C api came second, and isn't complete because it hasn't been necessary (until now). >> If you need them, you can add them. Adding them isn't very difficult. > > Perhaps you're over-estimating my intellectual capacity, or you've > become de-sensitized to the complexity of the status quo because it's > familar to you, or both? I actually had dialogs working 80% for me > using the existing options system. After that investment, I estimated > getting an extra 10% was going to require becoming an expert in guile > and scheme (which I haven't substantially used since '98). Now, after > a few evenings of coding, I have an options API that does 100% what I > want and seems to be flexible enough for me to use for any new > dialogs. Well, I like to think that people I work with are as smart as I ;) I don't like to think that's over-estimating... Also, your new code may do 100% what you want for your stuff but it doesn't 100% replace the existing code, which means there's still work to be done. Also, you could ask for help. If you needed a few more C apis into the option db, ask. > Ok, granted. But if I can't easily complete the API, it does reduce > its usefulness. Which APIs do you need? >> Granted, it's MUCH easier to use them from scheme than it is to use >> them from C, but that's just due to the way it was designed. > > Yes, you're exactly right. But who do we want to attract to hack on > gnucash? more scheme programmers or C programmers? We should make it > easier for whoever we want to attract. Honestly, right now I don't care.. ;) Besides, MOST of the hackers are _users_ of the optiondb API, not those who need to create new option types. The "hard" work is creating new option types, but that's a relatively rare occurrance, and a simple "hey, can you help with this" can sometimes go a long way. :) >> No way could you have that flexibility using glade. > > Now this, I'm not so sure I agree with. Could you elaborate on why > you believe this? IMO, glade gives you much more flexibility. But > anyway, even if it were less flexible (which I don't think) glade has > IMO a huge bonus over options.scm: ** It's maintained out-of-tree. ** > I'm willing to accept quite a bit of reduced flexibility when someone > else is doing all the work for me. :) In order to change a glade dialog I need to run the glade tool, change the list of options, and then save it out. How can I create "partial options lists" and store them in separate places using glade, and then pull them all together at one time into a single dialog? With the current options I can define the optiondb specifications piecemeal, but have it appear in a single dialog. For example, the reports all have some "default options" which are in all report, defined centrally. Then each report adds its own set of options. If I want to change the common options available I change the configuration in one place, not in every report. I just don't see how you get that flexibility in glade. >> > they're not going to be real impressed with the Gnucash codebase. >> >> That's true anyways. Find 10 "new" developers and you'll probably get >> them pointing at 10 different ways the gnucash codeback sucks. > > You're right, but I see two problems: > > First, for every ten "new" developers discovering that gncuash > codebase sucks, only one will sit down, figure out why it sucks and > try to improve it. The other nine will say "gosh, this stuff blows my > mind; I'm gonna go work on something where I can make forward progress > without spending 3 months grokking this mess in the dark." People > like seeing the fruit of their labor -- it's human nature. > > Second, we don't have 10 new developers. Hehe. Well, you're here, and Neil Williams is here, and evanchsa is here (sorry I don't recall your real name offhand). I think we're doing pretty well. It's always easier for a new developer to say "I don't understand this code; let me rewrite it so I can". It's also human nature to do it your own way. *shrugs* > Quite the contrary: When it comes to apis, "different" always has > inherent disadvantages, because it means "unfamiliar" and familarity > is what breeds programmer efficiency. But, there are other factors, > too.
Re: [RFC] A differnt options system
Chris, Let me try to provide feedback based on your actual code comments in the header. I didn't look at the actual implementation because, frankly, how you implement it is much less important that how it is used.. At least at this stage of the game. There'll be lots of snipping of your header; I don't plan to mark all of those snips. Chris Shoemaker <[EMAIL PROTECTED]> writes: > * The "Options Triad": > * > *I call GNCOptionWin, GncOptionDB, and options.scm the "options > * triad." GNCOptionWin is a dialog wrapper for GncOptionDB, which is > * the C interface to an options system that is written in Scheme (see > * src/app-utils/options.scm). Unfortunately, there is very little > * documentation for GNCOptionWin and GncOptionDB. (Actually, there's > * just a few comments in the code. Maybe some of the comments here > * will grow into some documentation that can then be moved to > * GNCOptionWin.) The underlying options system is well-documented in > * gnucash-design.info. More documentation is always a good thing. > *The options triad can be a bit confusing, but a few tips can > * ease the understanding. The options system is actually much more > * than just a way to display and modify option values. It is also > * intended to be the primary storage container for those option > * values. That means that the option values "live" somewhere in the > * Scheme interpreter. On the C side of things, GnuCash has access > * (getting and setting) to the option values though guile bindings. > * As a consequence, using the options system for new options > * (I'm not talking about new option types.) requires at > * least a bit of scheme coding. "a bit of scheme coding" isn't being quite accurate. It's a miniscule amount of scheme coding, and it's coding that is well documented (by your own admission). So, reading between the lines it doesn't sound like this is a complaint... Except for the fact that it's scheme instead of some other "language" to define the set of options. > *A typical scenario might roughly go like this: (Lots of details > * are left out here - this is only intended as a conceptual outline.) This is a great example (that I removed here). This description would be great for the docs. It truly shows how easy it is to use the triad. > * But... there are cases where everything doesn't work perfectly, and > * there are cases where things work, but painfully: > * > * 1) GncOptionWin's option layout is quite flat. Linear layout order > * can be specified in the scheme option definition, but that's it. Well, not quite. You supply a page and a layout order on the page. True, you can't put options next to each other, but is that necessarily a bad thing? Agreed, the options system is not meant to be a generic dialog builder. Is that really a problem? > * 2) Some option types are buggy. Oh? Which ones? If there are buggy option types that should definitely be fixed! This is the first I've heard of buggy options. > * 3) Not all GnuCash values have option types, and new GnuCash values > * that you invent for sure won't, (unless you make them). The > * options triad supports a fairly complete set of simple option > * types. This is good because extending the underlying options > * system to support new option types requires a _deep_ understanding > * of Scheme, Guile, Gtk+/Gnome, and existing GnuCash users (Here and > * henceforth, by "user" I usually mean code that uses some API.) of > * the option system (currently, Reports options, business options and > * top-level GnuCash preferences). What do you mean by "gnucash values"? Do you mean "data type with a corresponding option type"? As I said in a previous email, the system is designed in an extensive manner; Option types have only been added as necessary. For example, see the business-options code for an example of how I added options for various business objects. Historically we haven't had a need for options of every gnucash data type, so yes, we need to add more if you need more. That's not necessarily a reason to scrap the existing infrastructure. > * 4) Reusing groups of options isn't easy. There's probably some way > * to define the option list as a concatenation of smaller option > * lists, but I don't think there are any examples of this. It's very easy, and there are examples. See gnc:options-add-account-selection! in src/reports/report-system/options-utilities.scm for one example. Basically you write a scheme procedure that defines the block of options you want to create. > * 5) If you're storing option values in C as enumerated types > * (multi-choice option type), you'll need to specify the enumeration > * in C and in Scheme, and keep them in sync. That's not quite true. Yes, you need to define the list in the option definition in scheme, but what those values mean is up to you later. You could define them in one place and export to the other, o
Re: [RFC] A differnt options system
On Wed, Feb 16, 2005 at 01:14:32PM -0500, Derek Atkins wrote: > David Hampton <[EMAIL PROTECTED]> writes: > > > On Wed, 2005-02-16 at 12:13 -0500, Derek Atkins wrote: > > > >> The existing gnc option code has a method to save options into the > >> Book. See the File -> Properties menu option. > > > > I know. > > > > My question is why are we maintaining and even extending a private > > options storage system that is totally orthogonal to the purpose of > > managing finances. I think its a waste of time an resources, and Chris > > it right, it makes it harder for new developers to join gnucash. > > Because there isn't an alternative out there that has the same set of > features that gnucash uses? The exact set? No, but there are alternatives that provide subsets of those features, and usually they do a better job. > > >I had > > a hard time understanding the options code myself when I first started, > > and i wouldn't say that I understand more than 50% of it today. 50%! You're an expert! :) Maybe _you_ could flush out the C API? > > Isn't this something that a bunch of documentation would fix? We've > certainly had a dearth of developer docs in the code. We've > definitely been working on fixing that. Unfortunately, I don't think this is a documentation problem. Look at the number of functions in option-util.h. And look at how many public functions use the SCM type. Even if they were all documented, this is a complex API, that uses some unusual programming idioms. (However, several portions of this api appear not be used much if at all.) And this is only part of the options triad. > > I'm not trying to defend the existing options code. It took me a long > time to grok it, and frankly I'd certainly rather see code written in > C with scheme wrappers than the current code-in-scheme with C > pull-outs. But gconf doesn't fit as a drop-in replacement. I completely agree. gconf may only solve one particular piece of the problem, (just as libglade may only solve one piece.) Incidentally, I'm more concerned about the "object properties" type of option dialog, because it's a more common task than the overall program preferences dialog. > > It IS kind of nice to have a single API that we can use for global > options, book options, report options, etc. I wouldn't want to lose > that. I agree that that's ideal. But note that we don't really meet that ideal now. For example, just look at the glade files that contain "option dialog"-type widgets. These users aren't using the GNCOptionDB API, but they're doing essentially similar things. I kind of think of my options proposal as a regularization of that paradigm that's already in use. > > > believe that switching to a shared options system like gconf is the way > > to go. That code is used by multiple applications (17 that I use on an > > occasional or more frequent basis), is maintained by others, and is > > already a dependency of gnucash. The only downside I see is the current > > lack of per data file options. > > That's a serious downside, and one that gnucash uses everywhere. Obviously, gconf doesn't address that problem. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [RFC] A differnt options system
On Wed, Feb 16, 2005 at 01:05:31PM -0500, Derek Atkins wrote: > Hi, > > It really is not bitrotting, why would you think it is? There is a C > api and a scheme api that are tied together. Scheme is actually the > primary API, so some of the C api is missing because nobody ever > needed those particular functions. In other words, the C api was > never fully implemented because it seemed silly to implement functions > nobody was using. Well, to be fair, my evaluation is mostly based on the C api. I didn't see any fundamental problems with the scheme api. But I want to add functionality to gnucash using mostly C so I want to open dialogs from C. > If you need them, you can add them. Adding them isn't very difficult. Perhaps you're over-estimating my intellectual capacity, or you've become de-sensitized to the complexity of the status quo because it's familar to you, or both? I actually had dialogs working 80% for me using the existing options system. After that investment, I estimated getting an extra 10% was going to require becoming an expert in guile and scheme (which I haven't substantially used since '98). Now, after a few evenings of coding, I have an options API that does 100% what I want and seems to be flexible enough for me to use for any new dialogs. > > As for the complexity; the complexity is hidden in the fact that > options are stored as guile thunks so you need to know a bit about the > internal storage of the option in order to read it out on the C side. > But that only has to happen once. None of the users of the options > API need to care about that. > > > Frankly, if I had done that, what would we have? The same options > > system, but with fewer bugs. But, I'm not convinced that the > > And this isn't a good thing? Actually, the current option system > doesn't have many bugs at all; it's just missing some APIs on the C > side. Missing APIs does not a bad system make. Ok, granted. But if I can't easily complete the API, it does reduce its usefulness. > > > fundamental design of the options triad is maintainable. At least to > > someone coming from outside, like me, the options system is > > practically an impenetrable mystery. But, more people from outside > > coming to hack gnucash is exactly what we need. If they can't even > > throw up an option dialog without either: > > 1) groking the options triad or > > 2) using libglade; subclassing GtkDialog; rolling their own > > change watcher; and remembering the API of every GtkCheckBox, > > GtkSpinButton, and GtkEntry, etc, etc. > > The cool thing about the options system is that it's completely dynamic. > You don't need to change a significant amount of code to add new options. > If you want to add a new option to a dialog you have to do two things: > > 1) Add the option definition to the options-db specification > 2) Add the code to use the option from the options-db. > > All the HARD work is adding new types of options. USING the options > is pretty darn easy. I agree, that _is_ cool. I was impressed with how easy it was to get 80% of what I wanted. (I didn't even mind the ugly layout. ;) > Granted, it's MUCH easier to use them from scheme than it is to use > them from C, but that's just due to the way it was designed. Yes, you're exactly right. But who do we want to attract to hack on gnucash? more scheme programmers or C programmers? We should make it easier for whoever we want to attract. > > Creating an options dialog from scheme is extremely simple. Creating > it from C is slightly less so. Take a look at the code for the File > -> Properties menu option just to see how extensible the options code > is! Agreed. > > No way could you have that flexibility using glade. Now this, I'm not so sure I agree with. Could you elaborate on why you believe this? IMO, glade gives you much more flexibility. But anyway, even if it were less flexible (which I don't think) glade has IMO a huge bonus over options.scm: ** It's maintained out-of-tree. ** I'm willing to accept quite a bit of reduced flexibility when someone else is doing all the work for me. :) > > > they're not going to be real impressed with the Gnucash codebase. > > That's true anyways. Find 10 "new" developers and you'll probably get > them pointing at 10 different ways the gnucash codeback sucks. You're right, but I see two problems: First, for every ten "new" developers discovering that gncuash codebase sucks, only one will sit down, figure out why it sucks and try to improve it. The other nine will say "gosh, this stuff blows my mind; I'm gonna go work on something where I can make forward progress without spending 3 months grokking this mess in the dark." People like seeing the fruit of their labor -- it's human nature. Second, we don't have 10 new developers. > > >> I'd prefer it if we did not have multiple options systems in > >> gnucash. Doing it once and using it everywhere is usually the best > >
Re: [RFC] A differnt options system
David Hampton <[EMAIL PROTECTED]> writes: > On Wed, 2005-02-16 at 12:13 -0500, Derek Atkins wrote: > >> The existing gnc option code has a method to save options into the >> Book. See the File -> Properties menu option. > > I know. > > My question is why are we maintaining and even extending a private > options storage system that is totally orthogonal to the purpose of > managing finances. I think its a waste of time an resources, and Chris > it right, it makes it harder for new developers to join gnucash. Because there isn't an alternative out there that has the same set of features that gnucash uses? >I had > a hard time understanding the options code myself when I first started, > and i wouldn't say that I understand more than 50% of it today. Isn't this something that a bunch of documentation would fix? We've certainly had a dearth of developer docs in the code. We've definitely been working on fixing that. I'm not trying to defend the existing options code. It took me a long time to grok it, and frankly I'd certainly rather see code written in C with scheme wrappers than the current code-in-scheme with C pull-outs. But gconf doesn't fit as a drop-in replacement. It IS kind of nice to have a single API that we can use for global options, book options, report options, etc. I wouldn't want to lose that. > believe that switching to a shared options system like gconf is the way > to go. That code is used by multiple applications (17 that I use on an > occasional or more frequent basis), is maintained by others, and is > already a dependency of gnucash. The only downside I see is the current > lack of per data file options. That's a serious downside, and one that gnucash uses everywhere. > David -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 [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [RFC] A differnt options system
Hi, Chris Shoemaker <[EMAIL PROTECTED]> writes: > Well, it started here: > https://lists.gnucash.org/pipermail/gnucash-devel/2005-January/012493.html > https://lists.gnucash.org/pipermail/gnucash-devel/2005-January/012496.html > > Plus, I think the comments patch I submitted contained in option-util.c: > > /* TODO: > > - even though there is a make-text-option on the scheme side, > gnc_option_db_lookup_string_option() doesn't seem to work for > those, so I guess there's no way to use make-text-option I think there may be a difference between "string option" and "text option". I need to take a look. > - for make-date-option, there seems to be only support for getting, > not for setting. > */ > > I marked it TODO, but realistically, I suspect the options API is > bitrotting under their own complexity. If I thought these were simple > bug-fixes, I would have attemted to fix them myself. It really is not bitrotting, why would you think it is? There is a C api and a scheme api that are tied together. Scheme is actually the primary API, so some of the C api is missing because nobody ever needed those particular functions. In other words, the C api was never fully implemented because it seemed silly to implement functions nobody was using. If you need them, you can add them. Adding them isn't very difficult. As for the complexity; the complexity is hidden in the fact that options are stored as guile thunks so you need to know a bit about the internal storage of the option in order to read it out on the C side. But that only has to happen once. None of the users of the options API need to care about that. > Frankly, if I had done that, what would we have? The same options > system, but with fewer bugs. But, I'm not convinced that the And this isn't a good thing? Actually, the current option system doesn't have many bugs at all; it's just missing some APIs on the C side. Missing APIs does not a bad system make. > fundamental design of the options triad is maintainable. At least to > someone coming from outside, like me, the options system is > practically an impenetrable mystery. But, more people from outside > coming to hack gnucash is exactly what we need. If they can't even > throw up an option dialog without either: > 1) groking the options triad or > 2) using libglade; subclassing GtkDialog; rolling their own > change watcher; and remembering the API of every GtkCheckBox, > GtkSpinButton, and GtkEntry, etc, etc. The cool thing about the options system is that it's completely dynamic. You don't need to change a significant amount of code to add new options. If you want to add a new option to a dialog you have to do two things: 1) Add the option definition to the options-db specification 2) Add the code to use the option from the options-db. All the HARD work is adding new types of options. USING the options is pretty darn easy. Granted, it's MUCH easier to use them from scheme than it is to use them from C, but that's just due to the way it was designed. Creating an options dialog from scheme is extremely simple. Creating it from C is slightly less so. Take a look at the code for the File -> Properties menu option just to see how extensible the options code is! No way could you have that flexibility using glade. > they're not going to be real impressed with the Gnucash codebase. That's true anyways. Find 10 "new" developers and you'll probably get them pointing at 10 different ways the gnucash codeback sucks. >> I'd prefer it if we did not have multiple options systems in >> gnucash. Doing it once and using it everywhere is usually the best >> way, IMHO. > > I completely agree. Somewhere along the line, however, the advantages > of doing something better have to outweigh the disadvantages of doing > something differently. If I haven't missed some great hidden virtue > of the options triad or some horrible flaw of my proprosed approach, > (please tell me if I have) I think this might tip that balance. I'm not adverse to doing something differently; but I'd like to see a good reason to change the existing code. I'd prefer not to have that reason be "these two apis don't exist". I'd like to see real, tangible advantages to the new system that can't be fixed in the current code with a few pages of documentation (which the current code seriously needs). I'll go re-read your proposal and look again for this tangible improvement. But keep in mind that different is not necessarily better. :) -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 [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [RFC] A differnt options system
On Wed, 2005-02-16 at 12:13 -0500, Derek Atkins wrote: > The existing gnc option code has a method to save options into the > Book. See the File -> Properties menu option. I know. My question is why are we maintaining and even extending a private options storage system that is totally orthogonal to the purpose of managing finances. I think its a waste of time an resources, and Chris it right, it makes it harder for new developers to join gnucash. I had a hard time understanding the options code myself when I first started, and i wouldn't say that I understand more than 50% of it today. I believe that switching to a shared options system like gconf is the way to go. That code is used by multiple applications (17 that I use on an occasional or more frequent basis), is maintained by others, and is already a dependency of gnucash. The only downside I see is the current lack of per data file options. David signature.asc Description: This is a digitally signed message part ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [RFC] A differnt options system
On Wed, Feb 16, 2005 at 11:31:01AM -0500, Derek Atkins wrote: > Chris Shoemaker <[EMAIL PROTECTED]> writes: > > > Background: I'm mainly interested in getting budgeting to work, but > > along the way I discovered that the options system in gnucash wasn't > > exactly up to doing what I needed and, frankly, it looked like it was > > going to be a major headache to make it work for me. > > In what way does the existing options system not work for you? Thanks for looking at this Derek. Well, it started here: https://lists.gnucash.org/pipermail/gnucash-devel/2005-January/012493.html https://lists.gnucash.org/pipermail/gnucash-devel/2005-January/012496.html Plus, I think the comments patch I submitted contained in option-util.c: /* TODO: - even though there is a make-text-option on the scheme side, gnc_option_db_lookup_string_option() doesn't seem to work for those, so I guess there's no way to use make-text-option - for make-date-option, there seems to be only support for getting, not for setting. */ I marked it TODO, but realistically, I suspect the options API is bitrotting under their own complexity. If I thought these were simple bug-fixes, I would have attemted to fix them myself. Frankly, if I had done that, what would we have? The same options system, but with fewer bugs. But, I'm not convinced that the fundamental design of the options triad is maintainable. At least to someone coming from outside, like me, the options system is practically an impenetrable mystery. But, more people from outside coming to hack gnucash is exactly what we need. If they can't even throw up an option dialog without either: 1) groking the options triad or 2) using libglade; subclassing GtkDialog; rolling their own change watcher; and remembering the API of every GtkCheckBox, GtkSpinButton, and GtkEntry, etc, etc. they're not going to be real impressed with the Gnucash codebase. > I'd prefer it if we did not have multiple options systems in > gnucash. Doing it once and using it everywhere is usually the best > way, IMHO. I completely agree. Somewhere along the line, however, the advantages of doing something better have to outweigh the disadvantages of doing something differently. If I haven't missed some great hidden virtue of the options triad or some horrible flaw of my proprosed approach, (please tell me if I have) I think this might tip that balance. > > Have you looked at the budget work in g2 that Darin Willits submitted? Oh yes, quite extensively. You reviewed the xml generated by the code I wrote to (almost) make his budgets persistent, remember. I hope to discuss it more fully later, but in short, after a more thorough look at the budgeting code, I concluded that persistence was not the only area that could use some improvement. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [RFC] A differnt options system
David Hampton <[EMAIL PROTECTED]> writes: > On Wed, 2005-02-16 at 11:31 -0500, Derek Atkins wrote: > >> In what way does the existing options system not work for you? I'd >> prefer it if we did not have multiple options systems in gnucash. >> Doing it once and using it everywhere is usually the best way, IMHO. > > I put some options into gconf in some of my earlier work on gnucash2, > based on the same report Chris mentioned: That gnome is moving towards > gconf as a container for preferences. My problem was that while this > works well for global (i.e. across data file) preferences, it doesn't > work for preferences that are specific to a given data file. For > example, a preference to remember which accounts in the main window are > open and which are closed would need to be a data file specific > preference. The existing gnc option code has a method to save options into the Book. See the File -> Properties menu option. > David -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 [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [RFC] A differnt options system
On Wed, 2005-02-16 at 11:31 -0500, Derek Atkins wrote: > In what way does the existing options system not work for you? I'd > prefer it if we did not have multiple options systems in gnucash. > Doing it once and using it everywhere is usually the best way, IMHO. I put some options into gconf in some of my earlier work on gnucash2, based on the same report Chris mentioned: That gnome is moving towards gconf as a container for preferences. My problem was that while this works well for global (i.e. across data file) preferences, it doesn't work for preferences that are specific to a given data file. For example, a preference to remember which accounts in the main window are open and which are closed would need to be a data file specific preference. David signature.asc Description: This is a digitally signed message part ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [RFC] A differnt options system
Chris Shoemaker <[EMAIL PROTECTED]> writes: > Background: I'm mainly interested in getting budgeting to work, but > along the way I discovered that the options system in gnucash wasn't > exactly up to doing what I needed and, frankly, it looked like it was > going to be a major headache to make it work for me. In what way does the existing options system not work for you? I'd prefer it if we did not have multiple options systems in gnucash. Doing it once and using it everywhere is usually the best way, IMHO. Have you looked at the budget work in g2 that Darin Willits submitted? -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 [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [RFC] A differnt options system
On Tue, Feb 15, 2005 at 11:38:50PM -0800, Chris Lyttle wrote: > On Wed, 2005-02-16 at 01:16 -0500, Chris Shoemaker wrote: > > Background: I'm mainly interested in getting budgeting to work, but > > along the way I discovered that the options system in gnucash wasn't > > exactly up to doing what I needed and, frankly, it looked like it was > > going to be a major headache to make it work for me. > > > > So, on the side, I'm trying to come up with an options system that > > does what I want, and maybe can be generally useful, too. Consider > > the attached a rough-draft. All the usually first-draft caveats > > apply. It's probably buggy, etc. (Although it passes enough unit > > tests to suggest that at least the idea isn't fundamentally flawed.) > > Chris, > > I saw a mention towards the end of the header of gconf, and I remember > reading some time back about how gnome in general was moving towards > using gconf as a container for prefs, is that what you're trying to > achieve here for gnucash? Well, I know very little about gconf, so I may be wrong, but I think of it a global _storage_ container for program preferences with persistence across program executions and potentially sharing between programs. My code doesn't provide any storage for option values. And the potential uses for this code that I'm considering most closely are the type that set option values that are local to a particular object, not overall program preferences. But I know that overall program preferences currently use the scheme options system, so I was trying to suggest a potential storage method for that type of option that could be used my options code. Actually, I don't even know how overall program preferences are stored by gnucash now. [Following a hunch, I look in ~/.gnucash] Oh, ok. I have a vague idea how they're stored. ;) That wouldn't work with my options system, because it doesn't generate scheme code. So yeah, the mention of gconf was off-the-cuff. The important point is that my code doesn't provide gconf-like functionality, which the existing options system does. For global program preferences, using gconf with my options system may provide functionality similar to the existing options system. [Note: I think that my approach has some merit even if only used for the "object properties" case and not the "program preferences" case.] -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [RFC] A differnt options system
On Wed, 2005-02-16 at 01:16 -0500, Chris Shoemaker wrote: > Background: I'm mainly interested in getting budgeting to work, but > along the way I discovered that the options system in gnucash wasn't > exactly up to doing what I needed and, frankly, it looked like it was > going to be a major headache to make it work for me. > > So, on the side, I'm trying to come up with an options system that > does what I want, and maybe can be generally useful, too. Consider > the attached a rough-draft. All the usually first-draft caveats > apply. It's probably buggy, etc. (Although it passes enough unit > tests to suggest that at least the idea isn't fundamentally flawed.) Chris, I saw a mention towards the end of the header of gconf, and I remember reading some time back about how gnome in general was moving towards using gconf as a container for prefs, is that what you're trying to achieve here for gnucash? Chris -- RedHat Certified Engineer #807302549405490. Checkpoint Certified Security Expert 2000 & NG |^| | | |^| | |^| | | Life out here is raw | | |^| | But we will never stop | |_|_| | We will never quit | / __> | cause we are Metallica |/ /| \ / | | ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
