Re: Bugzilla default/QA assignees
+1 ;) On Mon, Feb 18, 2013 at 05:09:20PM -0800, John Ralls wrote: The default assignee field is mostly used to determine who gets bugmail for a particular component. Some of the assignments make sense, like having me be the default for Mac bugs, some not so much, like Chris Shoemaker for budget bugs: He hasn't been around for a long time. It also makes it hard for non-bugzilla-admins to set themselves up for bugmail on new bugs, because the mechanism for doing so is to watch another user. Watching a real user means that you get bug mail not only for the bugs that that user is the default assignee,QA contact, or added to the CC list, but also for every bug that user comments on. Not really useful unless you're a stalker. The mainstream Gnome approach is to have fake users for default assignees; for example, the Gtk Quartz backend has gtk-quartz-ma...@gnome.bugs, which I watch so that I get bug mail for any of those. I propose doing the same for our gnucash components, with a per-component address for default assignee and a gnucash-bugs address for QA assignee to make it easy to get all bugmail. I'll change the components, but I can't create the users because I don't have privs for doing that. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Git Migration: github with svn access
If GnuCash switches to git, can I request that the gnc_authors file be corrected with my name and email for username 'chris'? -chris On Sat, Aug 11, 2012 at 08:05:08AM -0400, Derek Atkins wrote: Could we rename this page Git Migration? Personally I never want github to be the canonical source. I think the canonical version should reside on code.GnuCash.org. We can still use github as backup and public dist, but iq think we should still maintain master. -derek Sent from my HTC smartphone - Reply message - From: Geert Janssens janssens-ge...@telenet.be To: Frank H. Ellenberger frank.h.ellenber...@gmail.com Cc: gnucash-devel@gnucash.org Subject: Git Migration: github with svn access Date: Sat, Aug 11, 2012 6:52 AM On 11-08-12 12:48, Frank H. Ellenberger wrote: Hoi, Am 11.08.2012 12:17, schrieb Geert Janssens: I have created a wiki page to track the progress of our git migration. It currently lists the things I know that still have to be done. Please add to it if you know more or have fixed some items: http://wiki.gnucash.org/wiki/Github_Migration Geert Linked by http://wiki.gnucash.org/wiki/Git. ;-) Frank Thanks :) Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Db structure
On Sun, Aug 09, 2009 at 03:46:46PM -0400, Phil Longstaff wrote: For the most part, I've tried to make the db schema match the XML schema, including warts. There are 2 places I'd like to change, and am looking for feedback: 2) Each budget stores all of the budget information in slots, with path names of guid/period (e.g. 294ddec82b0840980d98203/12). These should be moved to a new budget_values table with columns id (autoinc/primary key), account_guid, period_num, budget_value (numeric). This would allow better access to the budget info by external tools. That seems reasonable to me. The use of slots was originally just to avoid the proliferation of C structs. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Budget report
On Mon, Aug 03, 2009 at 11:43:32PM -0400, Forest Bond wrote: Hi Phil, On Mon, Aug 03, 2009 at 12:02:07PM -0400, Phil Longstaff wrote: The budget report is my current itch, so I've been upgrading it. ... I'd like to see the budget reporting improved as much as anyone else, and I'm glad that you are looking at it. However, the semantics of budget data have not been clearly established, as I highlighted in a comment on bug #570895: My current understanding of budget numbers is that if A and B are expense accounts and B is a child account of A and both A and B have numbers entered for a given period in the budget, the total expenses for that period is A[period] + B[period]. In other words, A[period] doesn't *override* B[period]. This is how things are handled in BIS, anyway. I don't think the correct behavior is documented anywhere. This may be part of a larger design discussion, so feel free to move it to the ML if you think it is appropriate. I'd really like to see some agreement on this before the budget reports get much further. Thoughts? What you describe is correct. It's important to remember that: a. A and B may use different currencies. b. Budget values for an account are always in the same currency as the account. c. There *may* be no reasonable way to convert from one currency to the other. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Budget report
On Tue, Aug 04, 2009 at 03:41:46PM +0100, Colin Law wrote: 2009/8/4 Chris Shoemaker c.shoema...@cox.net: On Mon, Aug 03, 2009 at 11:43:32PM -0400, Forest Bond wrote: Hi Phil, On Mon, Aug 03, 2009 at 12:02:07PM -0400, Phil Longstaff wrote: The budget report is my current itch, so I've been upgrading it. ... I'd like to see the budget reporting improved as much as anyone else, and I'm glad that you are looking at it. However, the semantics of budget data have not been clearly established, as I highlighted in a comment on bug #570895: My current understanding of budget numbers is that if A and B are expense accounts and B is a child account of A and both A and B have numbers entered for a given period in the budget, the total expenses for that period is A[period] + B[period]. In other words, A[period] doesn't *override* B[period]. This is how things are handled in BIS, anyway. I don't think the correct behavior is documented anywhere. This may be part of a larger design discussion, so feel free to move it to the ML if you think it is appropriate. I'd really like to see some agreement on this before the budget reports get much further. Thoughts? What you describe is correct. It's important to remember that: a. A and B may use different currencies. b. Budget values for an account are always in the same currency as the account. c. There *may* be no reasonable way to convert from one currency to the other. Where parent and children accounts are in the same currency a useful feature (for me at least) would be to show the budgeted, actual and diff values for the sum of parent + children as well as the individual parent and children account values. You're certainly not alone. Can someone propose a way to do that which neither breaks nor produces incorrect or misleading results in the case where A and B use different currencies with no conversion rate available? I think one solution would be to use a commodity collector which would show non-zero values for all currencies used by an account or any of its descendants. -chris Colin Law ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Register rewrite
On Sun, Mar 01, 2009 at 01:35:30PM -0800, Charles Day wrote: Could someone enlighten me as to the state of the register rewrite, or point me to some kind of readme about it? I would like to know what the approach was, where things left off, etc. I had a quick look at the register-rewrite branch. My first impression is that the original register code has not been changed at all and that some kind of new stuff based on GtkTreeView was being worked on. Is it the intention to abandon a GUI-independent register design for a Gtk+ dependent version? Yes, exactly. At the time, it was somewhat of a feasibility study, as GtkTreeViews were still a little new and there weren't too many examples of good implementations that used 1000s+ of entries. These days, it's not really a question of the quality of the gtk+ bits. I haven't had the time to work on it (or any other part of GnuCash) for quite a while now. IIRC, last time I worked on it, I got copy and pasting of transactions working, which was pretty low on my priority list, so I think it's probably usable, though not polished. -chris Cheers, Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Register code question
On Wed, Oct 15, 2008 at 08:41:58PM -0700, Charles Day wrote: I am debugging the register code and trying to figure out why bogus message boxes can appear, and also why crashes occur in certain cases. I believe that I've figured it out the sources of these problems, but I have a background question to ask before proceeding with a fix. These problems seem to stem from the way that the pending_trans_guid is used when entering a brand new transaction. Can anyone explain the intended use of pending_trans_guid where new transactions are concerned? I came across some comments in split-register-load.c which appear to shed some light. When the bottom line of the register is created (where the user would start entering a new transaction), a new transaction with a single blank split is tied to it but not marked pending: /* We don't want to commit this transaction yet, because the split doesn't even belong to an account yet. But, we don't want to set this transaction as the pending transaction either, because we want to pretend that it hasn't been changed. We depend on some other code (somewhere) to commit this transaction if we really edit it, even though it's not marked as the pending transaction. */ [disclaimer: This is totally from my poor memory. Your best bet for getting a deep understanding the register code is thoroughly studying the code and history, and single stepping in gdb.] pending_trans_guid is how the register keeps track of an open, edited transaction. From the user's perspective, navigating to the blank transaction is not an editing operation (especially since it happens automatically when the register opens) and should therefore not dirty the book. So it seems the intention is to never mark a brand-new transaction as the pending transaction. Not exactly, the intention is to not mark a brand-new transaction as pending until it is actually edited. Yet a few routines DO set the brand-new transaction as pending, such as the autocompletion routine gnc_split_register_auto_completion() in split-register-control.c, and a couple of other routines that perform split deletion. That seems correct. So does anyone know why some forms of editing (autocompletion, deleting a split) cause the brand-new transaction to be marked as pending, while all others, including the typical practice of simply typing a transaction in, do not? What is the correct practice? At a higher level, the ideal behaviors are: a) Opening and navigating in a register doesn't dirty the book. b) Editing a transaction doesn't dirty the book until it is committed. c) Closing a register while on an edited, uncommitted transaction will raise the modal commit/rollback dialog. d) Autocompletion counts as editing the transaction. Hope that helps, -chris p.s. Please be especially careful with register code. You probably know this, but over the years, that code has seen a pattern of subtle regressions that have taken months or years to fix (if ever?), and those bugs have caused data corruption. It is _extremely_ easy to break in subtle ways. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: AUDIT: r17421 - gnucash/trunk/lib/libqof/qof - Add a new function to the gnc_numeric library that converts denominators to exact powers of ten.
On Thu, Sep 18, 2008 at 06:12:19AM -0700, Charles Day wrote:
On Tue, Sep 16, 2008 at 2:40 PM, Charles Day [EMAIL PROTECTED] wrote:
On Tue, Sep 16, 2008 at 10:54 AM, Charles Day [EMAIL PROTECTED] wrote:
On Tue, Sep 16, 2008 at 9:38 AM, Andreas Köhler [EMAIL PROTECTED] wrote:
Hi,
On Mon, 2008-09-01 at 22:09 +0200, Andreas Köhler wrote:
Hi Charles,
On Sun, 2008-07-27 at 11:33 -0400, Charles Day wrote:
Trac: http://svn.gnucash.org/trac/changeset/17421
Log:
Add a new function to the gnc_numeric library that converts
denominators to exact powers of ten.
Modified: gnucash/trunk/lib/libqof/qof/gnc-numeric.c
===
--- gnucash/trunk/lib/libqof/qof/gnc-numeric.c 2008-07-27
15:11:19 UTC (rev 17420)
+++ gnucash/trunk/lib/libqof/qof/gnc-numeric.c 2008-07-27
15:33:23 UTC (rev 17421)
+ fraction = converted_val.denom;
+ if (fraction = 0)
+return FALSE;
out of curiosity, what is the reason for disallowing negative
denominators? I am not sure whether there is a gnc_numeric API
function
to switch signs of nom and denom safely, but I am sure that doing it is
possible :-) But maybe the current behavior is actually desired.
I just noticed that ignoring negative denominators means that 1/(-10) is
now printed as 1 * 10, where it was printed as 10.00 before. Is
that a regression we have to fix or not?
I can see how that would happen, because in previous versions, non-decimal
fractions were forced to print in decimal form in some places. So even
though the old routines considered 1/(-10) non-decimal, it would print it
as
decimal anyway. I think this takes us back to the original discussion.
Should go ahead and add support for negative denominators to
gnc_numeric_to_decimal()? I must only take less than 5 lines of code.
Here's the first attempt at that change. How are you testing these numbers?
I went ahead and committed this change in r17554. Calling
gnc_numeric_to_decimal on 4/-3 now gets you 12. However, there is an
overflow danger because gnc_numeric_convert() doesn't check for that
(apparently this has been a problem for some time). Someone else should
probably look at that, as I am no expert on 64-bit/128-bit math.
I haven't followed the thread at all, but just in case anyone's not
aware, I thought I should remind everybody about the reciprocal
denominator represention. IIRC, signs are always stored on the
numerator, and a negative denominator represents a reciprocal
denominator (essentially a multiplication). Last I knew, this
representation is used internally by some of the operations.
-chris
-Charles
$ svn diff
Index: gnc-numeric.c
===
--- gnc-numeric.c (revision 17505)
+++ gnc-numeric.c (working copy)
@@ -1043,7 +1043,14 @@
converted_val = *a;
if (converted_val.denom = 0)
-return FALSE;
+ {
+converted_val = gnc_numeric_convert(converted_val, 1,
GNC_DENOM_EXACT);
+if (gnc_numeric_check(converted_val) != GNC_ERROR_OK)
+ return FALSE;
+*a = converted_val;
+*max_decimal_places = decimal_places;
+return TRUE;
+ }
/* Zero is easily converted. */
if (converted_val.num == 0)
Ciao,
-- andi5
Cheers,
Charles
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Meaning of recurrence multiplier msgid?
On Mon, Mar 24, 2008 at 10:36:02PM +0100, Christian Stimming wrote: Hi all, the exact meaning of one translated string in Recurrence.c is unclear to me: #. translators: %u is the recurrence multipler. #. translators: %u is the recurrence multiplier #. translators: %u is the number of intervals #. translators: %u is the recurrence multiplier. #: ../src/engine/Recurrence.c:434 ../src/engine/Recurrence.c:508 #: ../src/engine/Recurrence.c:536 ../src/engine/Recurrence.c:549 #: ../src/engine/Recurrence.c:563 #, c-format msgid (x%u) This msgid is used to build words like Monthly (x5) or Daily (x2). Does that mean the sx in question is executed montly, five times in total, or rather every 5th month? The former is probably meant by the translator comment number of intervals and the latter by the comment recurrence multiplier, right? Also, only one translator comment talks about the number of intervals, namely the one in line 535 in PERIOD_DAY, Daily (x%u). However, from the code it seems the comment it wrong and this number has the same meaning as in all other intervals, right? In that case the comment needs to be fixed and all is fine. Otherwise we would be in trouble because an identical msgid is used for two contradictory meanings, which would have to be disambiguated. It means the latter, and the one comment is wrong. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: RFC: Server disk slowly failing, I plan to replace it using tip jar.
On Sat, Oct 06, 2007 at 09:52:15AM -0400, Derek Atkins wrote: Okay, sounds like rough consensus to me. I've got plenty of money in the tip jar but wanted to get feedback before I ordered anything. I'll order two drives and I'm thinking of adding another 500MB of memory (for an additional $60) to max out the memory of the server. Splurge and get the whole 512MB. :P -chris -derek ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: RFC: Server disk slowly failing, I plan to replace it using tip jar.
On Fri, Oct 05, 2007 at 10:29:55AM -0400, Derek Atkins wrote: Hi, snip So... Comments? Suggestions? Good idea. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Fwd: World friendlier printable invoices
On Tue, Oct 02, 2007 at 11:03:29AM -0400, Derek Atkins wrote: As I've said over and over, the REAL answer is to integrate e-guile and then invoices could be an HTML-template with embedded guile, instead of a scheme program that happens to generate HTML. I'm still waiting for someone to offer to implement that. :-D Just for the record, and because, as you point out, this has been repeated several times... I agree that the solution is an html templating system. However, there are many better examples than eguile, if one is willing to use a scripting language other than guile. I, for one, would not recommend anyone actually attempt to integrate e-guile, as that is essentially equivalent to writing and maintaining our own templating system. Also, I think it's very unlikely that anyone will ever get it to do anything impressive. Instead, if there is anyone interested, I would recommend that they adapt the swig .i files to the popular scripting language of their preference, and use the popular templating system of their choice. This is a far better engineering decision, IMO, and far easier to do, also. It's probably about 80 hours work to the initial working system for someone already familiar with the relevant tools. If I only had the time... -chris -derek Quoting Monte Jewell [EMAIL PROTECTED]: I'm a gnucash newbie but very experienced with proprietary billing systems for small law offices. I'm reading everything I can find on how to edit the gnucash templates, but my invoices still look like I'm selling automotive parts (not that there would be anything wrong with that if I wasn't actually drafting separation agreements . . . ) I want to help and to gnu use-share-study-improve the code, esp with nonprofit projects that I volunteer with who have no money to be spending on proprietary licenses but have to do it anyway. This invoice editing problem is kicking my butt so far. mj *** Monte Jewell PC Attorney at Law 500 N Higgins Ave Ste 107 Missoula MT 59802 www.montejewell.com -Original Message- From: Derek Atkins [EMAIL PROTECTED] Date: Tue, 02 Oct 2007 10:09:56 To:Bryan Cebuliak [EMAIL PROTECTED] Cc:gnucash-devel@gnucash.org Subject: Re: Fwd: World friendlier printable invoices Hi, Bryan Cebuliak [EMAIL PROTECTED] writes: Pardon me, I am really very new at this. Would you like me to do that now with the files or have you already done it? Will just a plain diff file.scm filenew.scm diffoutfile do the trick? Usually the way to do it would be: svn diff Attached please file the diff output files including the total ex tax localisation changes. Unfortunately you: a) ran diff manually b) didn't use '-u' to create a unified diff Also, do you have an idea why opening gnucash with a saved fancy-invoice report in the old format using the new fancy-invoice.scm etc crashes gnucash? The same may happen with the the other files. Not tested yet. This is avoided if the old report tab is closed prior to saving before upgrading the invoice files. This is a show stopper if it happened with a gnucash upgrade. Umm... Without really seeing your changes (while my brain can process a unified diff, I can't really process a non-context/non-unified diff) I can only guess. My first guess is that you changed the available options so that when gnucash reloads the options into the report it fails. But I don't know without seeing the code and seeing the crash backtrace. It would be allowed in a major release change, but certainly not within a stable release. E.g., this happened between 1.6 - 1.8 and again from 2.0 - 2.2. (It might have happened from 1.8 - 2.0 too, but I don't recall). -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 -- 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 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: RW access for german account charts
On Mon, Sep 03, 2007 at 04:03:13PM +0200, Rolf Leggewie wrote: Christian Stimming wrote: It would be fine to have more people with write access to gnucash/trunk/accounts/de_DE/ . OK, so what is the next step? In case you guys go with Chris' suggestion of a separate branch, I'd only ask you not to name it mob. As a contributor, I think I and anyone else deserves to be treated with respect and mob does not quite express that to me. I am sure it was not meant offensively, but the wording is not so super, I'd say. hehe. I can see your point. While the actual branch name is not important, the designation as a mob branch is actually a term of art. The term is a reference to an essay [1], and it's a term I've seen used by several different projects. Admittedly, it's probably not widely used outside of communities that use a distributed SCM, so I should have explained the term. Nevertheless, I don't think we have any say over the definition of that term. It's certainly not a derogatory term, so I expect it will eventually lose any intial negative connotations people have with it. As to the point at hand, it doesn't seem like anyone is too interested in figuring out how to implement this with svn, so it's probably easiest just to give you access to the directory. So, send Derek or Josh your public key, and see what happens. :) -chris [1] http://www.dreamsongs.com/MobSoftware.html ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: RW access for german account charts
On Fri, Aug 31, 2007 at 03:34:33PM +0200, Rolf Leggewie wrote: Hi, I am interested in maintaining German business related accounts (mainly SKR04 which is what I use). This is very uninteresting work that is of big concern to any German business user, but nobody else. Unfortuntately, that precludes all main devs. Thus, I was wondering if it was possible to seperate out RW privileges for files related to German accounts. If so, I would like to apply for them. And since this is probably more than a single person with a full-time job can achieve on his own, I would hope that Frank Ellenberger would apply as well. I hope it is clear what I am talking about, if not, ask. I originally raised this in http://bugzilla.gnome.org/show_bug.cgi?id=433428#c15 The reason that the normal way of send patches is not ideal is (quoting myself from IRC) (14:53:53) Rolf: Because there are lots of changes to be done right now (14:54:06) Rolf: Because this is shitty work noone wants to do (14:54:18) Rolf: Because you have half-assed implementations all over the place There are more reasons. It really boils down to make it easy for the one that is trying to fix this while encouraging others to chip in as well. If possible, there could be a small group of people with RW access for maintaining the German accounts only. This would not affect gnucash core. My recommendation would be to maintain a mob branch. This is a publicly-writable branch from which other devs can cherry-pick commits. This would come in handy for the occasional currency updates, too. And, sometimes, there are good patches that hang out in bugzilla for too long - just because they don't have much visibility. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Non compatibility of Gnucash 2.2 with report from Gnucash 2.0
On Wed, Aug 22, 2007 at 10:13:32PM +0200, Thierry Scalais wrote: Last year, I modified the advanced-portfolio report to add some useful functionality. I posted the report to this mailing list on September 2006. This reports worked fine with Gnucash 2.0. (https://lists.gnucash.org/pipermail/gnucash-devel/2006-September/018530.html) Unfortunately, Gnucash 2.2 is not compatible with this report. The main reason is that a series of function definitions disappear. Indeed, the current advanced-portfolio report was modified to take account of these changes. I found in the changelog, a list of equivalence between the old definitions and the new ones. But, some definitions used in my report are not listed. So my question is: Is there, any where, a file that I could include in my report to retrieve the old definitions and so avoid a rewrite of my report? No, there is not. We switched wrapper-generator tools from g-wrap to SWIG, so many identifiers changed. If your report used a method that no other report used, there's a chance it's not being exported to guile anymore, but it's more likely that the names just changed. Tell me what identifier you can't find anymore, and I'll see if I can help. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: The payment amount must be greater than zero
On Mon, Aug 20, 2007 at 05:13:13PM +0200, Graham Leggett wrote: On Mon, August 20, 2007 4:36 pm, Derek Atkins wrote: See, this is where you're not quite right. Gnucash really is a little schizophrenic here; it's not sure if it wants to be a Personal finance program or a Small Business finance program. It's really trying to be both. It's NOT trying to transition to being ONLY a business finance program. There is no reason why Gnucash cannot be both a personal finance program or a small business program at the same time, there is very little difference between the two. Having said that; the business features SHOULD be better; but I have no time to work on them and nobody else has really come forward to spend the many man-months of effort required to bring it up to snuff. But no, as a whole, I cannot say that gnucash is transitioning as you suggest it is. Sorry. My concern is that having spent the many man months of effort, will patches be considered? Gnucash is probably one of the best candidates out there to become a proper business accounting application with a few fixes here and there. What worries me is that when these issues are brought up, invariably someone infers the problem cannot be fixed or solved. These issues can be fixed. I think this impression comes from the fact that casual subscribers to this list tend to vastly under-estimate the effort involved in fixing them. If you enjoy a challenge, are extremely persistent, and somewhat talented, you can probably fix it. But, I'd expect it to take more than 9 months of spare-time hacking to do it well. Sometimes the patches accepted mantra comes across as hostile, but it's really not. It's just an acknowledgement of several implicit facts: 1) GnuCash has many areas that could be improved. 2) Nobody's working on improving that feature right now. 3) None of the current devs are likely to start working on that soon. 4) Hacking GnuCash is probably harder that you (the general you) think. 5) The current devs always welcome new devs, but the barrier imposed by GnuCash's overly-complex codebase is pretty high. 6) We'd love to proven wrong, but we're not holding our breath, and you probably shouldn't either. -chris p.s. Just to be clear, this is more general than just the business features - it applies to many areas of GnuCash. And, it's not specifically aimed at any one person - it's just a general response to the ever-present GnuCash should do X. comments. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
r16423 - gnucash/branches/register-rewrite - Merge in changes from [EMAIL PROTECTED]: 16422
r16423 - gnucash/branches/register-rewrite - Merge in changes from [EMAIL PROTECTED]:16422. Message body is too big: 31096607 bytes with a limit of 10240 KB 30MB is a bit excessive for a -commit email, but the register-rewrite branch is now rebased on [EMAIL PROTECTED] Details are available in trac or svn. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r16398 - gnucash/trunk/src/app-utils - In gncFindFile, use g_path_is_absolute instead of file[0]=='/'.
On Mon, Aug 06, 2007 at 08:56:40PM -0400, Andreas Köhler wrote: Author: andi5 Date: 2007-08-06 20:56:40 -0400 (Mon, 06 Aug 2007) New Revision: 16398 Trac: http://svn.gnucash.org/trac/changeset/16398 Modified: gnucash/trunk/src/app-utils/file-utils.c Log: In gncFindFile, use g_path_is_absolute instead of file[0]=='/'. Modified: gnucash/trunk/src/app-utils/file-utils.c === --- gnucash/trunk/src/app-utils/file-utils.c 2007-08-06 22:43:40 UTC (rev 16397) +++ gnucash/trunk/src/app-utils/file-utils.c 2007-08-07 00:56:40 UTC (rev 16398) @@ -86,7 +86,7 @@ if (!file || file[0] == '\0') return 0; /* take absolute paths without searching */ - if (file[0] != '/') + if (!g_path_is_absolute (file)) filename = gncFindFile (file); else filename = g_strdup (file); Andi, Do you happen to know if a non-absolute filename is even possible here? I looked into it a bit and couldn't see how it could occur. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r16102 - gnucash/trunk/src/gnome-utils - Unregister option dialogs from gui component list while destroying.
On Sat, May 19, 2007 at 07:19:47PM -0400, Andreas Köhler wrote:
Author: andi5
Date: 2007-05-19 19:19:44 -0400 (Sat, 19 May 2007)
New Revision: 16102
Trac: http://svn.gnucash.org/trac/changeset/16102
Modified:
gnucash/trunk/src/gnome-utils/dialog-options.c
Log:
Unregister option dialogs from gui component list while destroying.
FYI, this fixes a crasher introduced by r15976. r15976 was backported
to to the 2.0 branch, in case we were to ever release a 2.0.6.
However, this commit wasn't marked for backport. So, we should either
backport this, or just decide not to do anymore releases from the 2.0
branch.
-chris
Modified: gnucash/trunk/src/gnome-utils/dialog-options.c
===
--- gnucash/trunk/src/gnome-utils/dialog-options.c2007-05-19 23:19:39 UTC
(rev 16101)
+++ gnucash/trunk/src/gnome-utils/dialog-options.c2007-05-19 23:19:44 UTC
(rev 16102)
@@ -1485,6 +1485,8 @@
{
if (!win) return;
+ gnc_unregister_gui_component_by_data(DIALOG_OPTIONS_CM_CLASS, win);
+
gtk_widget_destroy(win-dialog);
if(win-tips) {
___
gnucash-changes mailing list
[EMAIL PROTECTED]
https://lists.gnucash.org/mailman/listinfo/gnucash-changes
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Register-rewrite update
On Wed, Jul 18, 2007 at 12:06:57AM -0500, Jeff Green wrote: I have been focusing on the crashes that were caused by adding autocompletion, since I realized that I couldn't adequately test any other functionality if I could only add one new transaction without crashing the program or closing and reopening the account. I spent some quality time with gdb and narrowed down the crashes to being caused by setting up the autocompletion using the real model associated with the transaction register treeview. So I tried making a copy of the data for the column that needs autocompletion (just the Description column for now) and using that for the autocompletion. This solved all the crashes. Unfortunately on the first implementation, autocompletion only worked for the first new transaction. This was an issue with TreeViewIters and creating a copy of the treeview model on each editing-started signal. So I made a new function to make a copy of the completion data when the cellrenderers are initialized (in cdf) and then use that copy for all completions. With this change autocompletion worked for all new transactions, the only problem being that the descriptions of the new transactions were not added to the copy of the completion data. This can be solved by adding the new text entered into the cell to the copy when the edited signal is received. This is where I'm at currently. Oh, what a pain! I was so pleased when I saw that the first autocomplete implementation re-used the transaction-model. That's just very simple, and automatically has many properties that are nice for autocompletion, like 1) it only uses the descriptions already in that register, and 2) it sees the newly added descriptions. It would be such a shame if we had to do something like copy model+insert new. But honestly, it would probably still be simpler than the old custom autocomplete code. If you try again with the single model, and get stumped, don't hesitate to send the backtrace here. -chris I also noticed when looking into creating a callback or using an existing one for the edited signal (the existing callback is gtvt_edited_cb) that I had unnecessarily created the editing_started_cb callback for the editing-started signal (get_editable_start_editing_cb was already being connected to that signal), so now I am working on integrating my code with the existing callbacks. Once the callbacks are integrated there should be no problems with autocompletion for the description field. It might also turn out that there is no need for the copy of the data from the treeview model, but that will have to wait until tomorrow. I'm running on very little sleep and I need to get to bed before my keyboard becomes my pillow. Jeff ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r16322 - gnucash/branches/register-rewrite/src/gnome-utils - Removed the editing_started_cb function (and related code) that set up the autocompletion and moved the code to
On Wed, Jul 18, 2007 at 03:40:25PM -0400, Jeff Green wrote: Author: jeff Date: 2007-07-18 15:40:23 -0400 (Wed, 18 Jul 2007) New Revision: 16322 Trac: http://svn.gnucash.org/trac/changeset/16322 Modified: gnucash/branches/register-rewrite/src/gnome-utils/gnc-tree-view-transaction.c Log: Removed the editing_started_cb function (and related code) that set up the autocompletion and moved the code to get_editable_start_editing_cb that was already present and set as the callback for the editing-started signal. Created the model_copy function to copy the data from the Description column of the treeview model into a liststore to use as the model for autocompletion (to solve the crashes caused by using the treeview model for autocompletion). Added code to gtvt_edited_cb to add the data from new transactions to the liststore used for autocompletion. If the solution with the ListStore turns out to be the long-term solution, we'll have to avoid leaking it, too. It would have to be owned by the transaction view, since the GtkCompletion is transient. IIRC, that means something like g_object_remove_ref() from the dispose method. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r16302 - gnucash/branches/register-rewrite/src/gnome-utils - Check if seconds returned by xaccTransGetDatePostedTS() are greater than zero in CellDataFunc (cdf) for COL_DATE. If
On Fri, Jul 13, 2007 at 01:22:06PM -0400, Derek Atkins wrote: Jeff, Jeff Green [EMAIL PROTECTED] writes: Check if seconds returned by xaccTransGetDatePostedTS() are greater than zero in CellDataFunc (cdf) for COL_DATE. If seconds are zero assume new transaction and set seconds to current time to display current date for new transactions. Actually, shouldn't a new transaction take the date of the previously entered transaction? The only time you should need to choose the start date is when the register first opens. Using the current date is better than using 1/1/1970. If people want to reuse the date from the previously entered transaction instead of the current date, that can be implemented later, after the more basic functionality. -chris p.s. Personally, I always found that behavior more annoying than helpful, so if _I_ implemented it, I'd probably make it optional. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Re (IRC): 2.2.0 and auto-save
On Thu, Jul 05, 2007 at 10:44:46AM +0200, Christian Stimming wrote: 14:40:57 warlord Hmm, are we going to have a 2.1.6? 16:21:25 andi5 warlord: wrt 2.1.6, if we plan not to revert the auto-save feature, we might want to have another test version iff christian wants to extend / improve it if we just change the default to disabled auto-save, then i am fine with no 2.1.6 as well... 16:21:52 warlord andi5: ok I don't want to extend/improve the auto-save feature before 2.2.0 (not enough time available). For that reason I don't think we need another 2.1.6 but should plan for 2.2.0 on the weekend July 15th, http://wiki.gnucash.org/wiki/Release_Schedule It seems to me the perfect solution would be to have a separate save-to-checkpoint function as opposed to the save-to-working-file, with extra auto-restore questions at startup, as outlined here by Eric Ladner http://lists.gnucash.org/pipermail/gnucash-user/2007-July/020890.html This would require major changes in our saving infrastructure, which I'm not going to do in the upcoming 1-3 months. As an aside, I'd like to point out that the current auto-save behaviour represents exactly how gnucash would behave with a database-backend currently, as explained here correctly http://lists.gnucash.org/logs/2007-07-04.html#T15:30:38 But for 2.2.0 we have the following choices: #1: Auto-save-datafile is enabled by default, just with a different default value (5 minutes? 10 Minutes?), and the explanation dialog box pops up upon the very first auto-save activation. Users would have to into the preferences to disable this feature. #2: Auto-save-datafile will be enabled once, then on the explanation dialog box the user is asked whether she/he wants to have this enabled: auto-save ... blabla ... Do you want to enable or disable this? [Enable] [Disable] #3: Auto-save is disabled by default and users have to find out the Option by themselves to enable it. No extra dialog explanation will be shown for this option, neither after startup nor at activation time or whatever. Using this feature is therefore restricted to those users who happen to stumble upon this during browsing through the preferences. The feedback from gnucash-user clearly points toward #3. However, my main intention was to implement a feature that helps the normal user to decrease the negative outcome of when an error occurs. This boils down to the question what behaviour the normal user actually expects from gnucash. As a programmer I know that my way of understanding gnucash is probably rather different from what the normal user does. However, I'm not so sure whether the gnucash-user feedback talks more about the normal user expectation than what I would think of, because those subscribers are power-users just as we are. (For example, my wife says the new auto-save behaviour is just fine and understandable, whereas the abovementioned restore-checkpoint-at-startup behaviour would be utterly confusing for her - she never really understands what she is supposed to answer when a program asks at startup about restoring whatever thingy is also there. I'm just saying we developers have to find a decision which doesn't necessarily conform with the majority of feedback on our mailing lists. Neither we ourselves nor even the users of our mailing lists might correspond the normal user in a representative way. Decisions, decisions... Following this way of thought I would decide for choice #1, leave as-is for 2.2.0. What do the other developers say? For better or for worse, we've conditioned users (me included) to expect that they can 1) open GnuCash, 2) make undesired changes for the purposes of exploration or experimentation, 3) close GnuCash w/o saving, and 4) re-open GnuCash with their data in exactly the state they last saved it. Purely as a matter of politeness, I think it would be rude to change this behavior without any user action. Given the current difficulty of implementing a autosave-to-alternate-file behavior, I'd suggest the following: #4) (a refinement of #2) Leave auto-save enabled by default, but change the behavior slightly: - When autosave triggers prompt the user with: Auto-save Do you want to auto-save your data file? [some explanation of the implications;] [explanation that this can be customized in Preferences] [Yes, just this once] [Yes, always] [No, not right now *] [No, never] === * default Until either (a) the user sets something in the preferences, or (b) they choose one of the always/never options, then this dialog should continue to appear _every_ time the auto-save triggers. This means: - The original behavior is one click away (No, never). - The fully automated auto-save behavior is one click away (Yes, always). - It leaves the user the option of full control. (with or
Re: register rewrite
[adding Jeff Green to cc] On Mon, May 21, 2007 at 11:48:06AM -0300, Peter Selinger wrote: Hi, I have tried the new register rewrite branch. It looks very nice; many thanks to Chris. Peter, Thanks for the review. I've unfortunately had very little time for the register rewrite recently. However, the good news is that Jeff Green has been accepted as a GSoC student specifically for this project. And that work should start up quite soon. I'll just make a few comments on the points below... I have a few minor comments and suggestions. * numbers in the register view should be right-aligned This should be quite easy. As a bit of an aside, does anyone know if this needs to be locale-dependent? * it would be nice if the transactions were sorted by date by default; the current default seems to be random order? Date certainly should be the default. IIRC, there was a slightly related bug in GtkTreeModelSort, where the order among transactions having equal values of the sort key would be determined by the order in which they had last emitted an event - and since cursor navigation triggers events, the most-recently navigated-to transactions bubbled to the top of the group of transactions with equal values of the sort key. It was (is?) quite annoying. If GtkTreeModelSort still exhibits this behavior, we'll have to work around it somehow. * a useful feature would be if double-clicking on the words -- Split Transaction -- split the transaction, and double-clicking on a transfer account opened that account. Also pretty easy to do. * in the debit and credit column in split transaction view, I would like to see that amount, and not the value, of each split. This is more transparent for multi-currency transactions. (I.e., it is more useful to know that you have exchanged CAD 40 for AUD 50, than that you have exchanged CAD 40 for CAD 40 in an AUD account). The value field is just there for debugging, and hiding it is easy. Notice that it is _not_ editable, in rather stark contrast to the current register. The ability to even see and edit the amount is, as you know, one of the reasons for the register rewrite in the first place. Jeff, I recommend that you review this thread: http://lists.gnucash.org/pipermail/gnucash-devel/2007-February/020008.html and the two documents that Peter links. Correct multi-currency support is one of the most important requirements for the register rewrite. However, there are still some issues to be addressed regarding smooth data-entry into the amount field. For example, is the currency symbol visible during entry? If you've entered something for an amount, and then you change the transfer account to an account in a different commodity, should the (probably invisible) value stay the same and the amount change automatically? or vice versa? (Aren't they both annoying in certain cases?) How can we optimize for the more common single-currency cases, while giving multi-currency users the power they need? * in the price column, the display of exchange rates as rational numbers (1 + 971 / 4118) is mathematically accurate, but not very user friendly. Since it's a derived quantity anyway (not stored separately by the engine), I am not sure why that extra accuracy is needed. Perhaps 4 decimal digits would suffice? That's very easy to fix, but did you notice that the price field is editable, even though it's a derived quantity? Its quantity is factored into the other fields. I think it'd be nice if multi-currency (or stock - exactly the same issues) users at least had the option of editing all the quantities directly in the register - without a dialog. * the old edit exchange rate button is still there, but does not seem to do anything. It would be nice if it still worked (so one does not have to display the Amt/Val/Price columns at all times. Yes, that'd be nice, too. Not too hard. BTW, I don't think cut-copy-paste work either. That's a little trickier, because it's probably a very bad idea to reuse the old register's implementation of cut-copy-paste. * keyboard entry in the account view leads to characters being typed into a little box at the bottom right of the corner. It looks like it's meant to be a search function, but it doesn't do anything except jumping to the first transaction. I don't remember seeing this, but I haven't tested with more recent gtk+. I didn't hook up the tree-view's native search functionality to the register, but that would be _really_ nifty. * it's now possible to split-view several transactions at the same time. Is there an easy way to unsplit them all? The old View - Journal Style etc. buttons seem to be gone. I call these three expansion policies and there are pretty easy to implement. I also kind of like the flexibility they give, for example, to have only the currently-edited paycheck transaction and the last paycheck transaction 10
Re: Some memory leaks as pointed out by Valgrind
On Sun, May 06, 2007 at 11:26:52PM +0200, Christian Stimming wrote: Here is some output of valgrind. This is with gnucash --nofile and directly terminating the program again. I'm trying to get some actual numbers for http://bugzilla.gnome.org/show_bug.cgi?id=431324 , but as one startup of gnucash with valgrind takes approx. 10 minutes :-) , I'm progressing quite slowly. But some issues are there already: ==5392== 44,394 bytes in 1,676 blocks are definitely lost in loss record 251 of 261 ==5392==at 0x4023515: malloc (vg_replace_malloc.c:149) ==5392==by 0x559B265: g_malloc (in /opt/gnome/lib/libglib-2.0.so.0.1200.4) ==5392==by 0x55AEA98: g_strdup (in /opt/gnome/lib/libglib-2.0.so.0.1200.4) ==5392==by 0x557D5E3: g_cache_insert (in /opt/gnome/lib/libglib-2.0.so.0.1200.4) ==5392==by 0x4055C20: qof_util_string_cache_insert (qofutil.c:296) ==5392==by 0x4048EBF: qof_collection_new (qofid.c:101) ==5392==by 0x404EDFB: qof_book_get_collection (qofbook.c:302) ==5392==by 0x404ACC7: qof_instance_init_data (qofinstance.c:287) ==5392==by 0x408EB74: book_sxes_setup (SX-book.c:251) ==5392==by 0x40514E0: qof_object_book_begin (qofobject.c:66) ==5392==by 0x404F3F6: qof_book_new (qofbook.c:88) ==5392==by 0x40588E6: qof_session_new (qofsession.c:197) Seems like the keys in the g_cache should be explicitly free'd after use, but currently they aren't. This leak is at least documented in book_sxes_setup(). ==5392== 3,428 bytes in 185 blocks are definitely lost in loss record 213 of 261 ==5392==at 0x4023515: malloc (vg_replace_malloc.c:149) ==5392==by 0x56B5ADF: strdup (in /lib/libc-2.5.so) ==5392==by 0x42E23C1: gnc_gettext_helper (gnc-gettext-util.c:35) ==5392==by 0x42DBB1D: _wrap_gnc_gettext_helper (swig-app-utils.c:1287) ==5392==by 0x5417D9E: (within /usr/lib/libguile.so.17.0.1) ==5392==by 0x5418F42: (within /usr/lib/libguile.so.17.0.1) ==5392==by 0x5418C64: (within /usr/lib/libguile.so.17.0.1) ==5392==by 0x5419E2F: (within /usr/lib/libguile.so.17.0.1) ==5392==by 0x5418CC0: (within /usr/lib/libguile.so.17.0.1) ==5392==by 0x541D789: scm_primitive_eval_x (in /usr/lib/libguile.so.17.0.1) ==5392==by 0x5472BB7: (within /usr/lib/libguile.so.17.0.1) ==5392==by 0x541F4CD: scm_c_with_fluid (in /usr/lib/libguile.so.17.0.1) Our gnc_gettext_helper returns a newly allocated string, but swig's generated _wrap_gnc_gettext_helper function doesn't free this string. Who has to fix this, we or swig? This is certainly our responsibility, and should be easy to fix. I'll see if I can look into this this evening. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r16017 - gnucash/trunk/src/scm - Drop process.scm and spawn perl to retrieve price quotes.
On Sat, Apr 28, 2007 at 03:13:51PM -0400, Andreas Köhler wrote: Author: andi5 Date: 2007-04-28 15:13:47 -0400 (Sat, 28 Apr 2007) New Revision: 16017 Trac: http://svn.gnucash.org/trac/changeset/16017 Removed: gnucash/trunk/src/scm/process.scm YEY! Way to go, Andi! @@ -519,13 +515,9 @@ (reverse result-list) (define (timestr-time-pair timestr time-zone) -(let ((broken-down (strptime %Y-%m-%d %H:%M:%S timestr))) - (if (not (= (string-length timestr) (cdr broken-down))) - #f - (cons (car (if time-zone - (mktime (car broken-down) time-zone) - (mktime (car broken-down -0 +;; time-zone is ignored currently +(cons (gnc-parse-time-to-timet timestr %Y-%m-%d %H:%M:%S) + 0)) (define (commodity-tz-quote-triple-price book c-tz-quote-triple) ;; return a string like NASDAQ:CSCO on error, or a price on This ignores time-zone now. Is that okay? -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r15939 - gnucash/tags - Tagging the 2.1.0 release of GnuCash
On Thu, Apr 19, 2007 at 08:58:51AM -0400, Chris Lyttle wrote: Author: wilddev Date: 2007-04-19 08:58:50 -0400 (Thu, 19 Apr 2007) New Revision: 15939 Trac: http://svn.gnucash.org/trac/changeset/15939 Added: gnucash/tags/2.1.0/ Log: Tagging the 2.1.0 release of GnuCash Copied: gnucash/tags/2.1.0 (from rev 15892, gnucash/trunk) ___ gnucash-changes mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-changes ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r15939 - gnucash/tags - Tagging the 2.1.0 release of GnuCash
[Sorry for the other empty response - accidentally sent. ] On Thu, Apr 19, 2007 at 08:58:51AM -0400, Chris Lyttle wrote: Author: wilddev Date: 2007-04-19 08:58:50 -0400 (Thu, 19 Apr 2007) New Revision: 15939 Trac: http://svn.gnucash.org/trac/changeset/15939 Added: gnucash/tags/2.1.0/ Log: Tagging the 2.1.0 release of GnuCash Copied: gnucash/tags/2.1.0 (from rev 15892, gnucash/trunk) Chris, Just FYI, I had already fixed up this tag exactly as you re-did. You can discover that from the messages sent to the gnucash-changes mailing list or by looking at http://svn.gnucash.org/trac/timeline or by subscribing to trac's RSS feed. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r15913 - gnucash/tags - Tagging the 2.1.0 release of GnuCash
On Thu, Apr 19, 2007 at 10:38:10AM -0400, Derek Atkins wrote: Chris Lyttle [EMAIL PROTECTED] writes: Actually that didnt work. The correct syntax was svn copy -r 15892 svn+ssh:// Are you sure? Chris.S had attempted to fix this once and the branch looked right in trac after he made the change.. I used svn copy -r 15892 svn+ssh://... -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r15913 - gnucash/tags - Tagging the 2.1.0 release of GnuCash
On Mon, Apr 16, 2007 at 10:43:48PM -0400, Chris Lyttle wrote: Author: wilddev Date: 2007-04-16 22:43:48 -0400 (Mon, 16 Apr 2007) New Revision: 15913 Trac: http://svn.gnucash.org/trac/changeset/15913 Added: gnucash/tags/2.1.0/ Log: Tagging the 2.1.0 release of GnuCash Copied: gnucash/tags/2.1.0 (from rev 15912, gnucash/trunk) Wouldn't it make more sense if we tagged the revision that was released? I'm not sure which revision that actually was, but it seems like it might have been close to 15894. -chris ___ gnucash-changes mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-changes ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: A crash in business functions
On Tue, Mar 27, 2007 at 03:44:02PM +0100, Nigel Titley wrote: Which confirms Andreas' assertion that gnc:id-book isn't in the sources anywhere. Yes, having looked at my email this morning, this was what I realised (it was pretty late when I emailed last night) So we are back to the original question. What caused the crash? What more information can I give you (and where did that * gnc:id-book come from?) Probably files left-over in your install directory, or picked up by the application during load. What did you use for a --prefix? and can you blow away the old install and redo the `make install`? -chris Nigel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Several basic(dumb?) questions on the Help Document
On Wed, Mar 21, 2007 at 08:16:37PM -0600, Dave Herman wrote: While reviewing the Help document I have several questions. I'm using primarily svn (trunk r15744). FC6 1) The register display for a expense type account displays two amount fields labeled Expense and Rebate. Is rebate the correct term? Seems resonable to me. 2) When verifying the section on Entering Multiple Split Transactions I noticed that the Split icon the Action Split Transaction are not active(highlighted) - How are these options activated? I can add splits without the use of these options by simply adding lines in the register. In fact on the transaction actions I've tried I have not been able to find the Split icon or the Action Split Transaction enabled. Can others see them enabled? They're only enabled in Basic Ledger view. 3) The Entering a Transactions via register section has the line Transactions with just one transfer account will show the name of that account in the Transfer field in completed transactions. Which is the transfer field? the field where the account names go Whoops - Issue #3 maybe that Transfer field is not labeled in the register display, with View Auto-Split Ledger enabled. Well, if the cursor is on a transaction line, that header is blank. If the cursor is on a split line, is says Account. In Basic Ledger view, it always says Transfer. Are these issues relevant in light of the register rewrite? I can't tell if you're suggesting that these issues are bugs to be fixed, but in any case, the current register remains relevant for as long as we're maintaining it. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GObject in GC implementation Plan
On Wed, Mar 21, 2007 at 10:48:12PM -0600, Daniel Espinosa wrote:
2007/3/21, Josh Sled [EMAIL PROTECTED]:
On Wed, 2007-03-21 at 00:42 -0600, Daniel Espinosa wrote:
Get GObject as the base of GC's objects. With the following advantages:
- Get ref counting
- Get signals events
Using GObject is a prerequisite of either of the separate ref counting
and signals projects, but aren't advantages that directly follow from
using GObject.
**OPTION 1: PORT QofEntity TO USE GObject AS BASE CLASS
***OPTION 2: PORT QofInstance TO USE GObject AS BASE CLASS
***OPTION 3: PORT GC's OBJECT TO USE GObject AS BASE CLASS
I read Option1-Step1 and Option2-Step2 as basically the same thing:
everything will just happen. They're not really steps; I don't take
away from them a clear plan of action.
Option 3 is broken out better, but it doesn't seem as suitable as Option
2. In particular, I don't see why one would change the type hierarchy
twice (in Steps 2 and 5). As well, it seems pretty agreeable all around
to merge QofInstance and QofEntity from the start. At least for the
purposes of discussion, let's call this merged type GncObject.
I'd agree with Chris; Option 2 is probably the better path. Or maybe a
modified version of Option 3, where:
- QofInstance and QofEntity are combined
- The GnuCash types then subclass GncObject.
- QofInstance fields are just inherited (not included by pointer)
- Minimal changes to use G[nc]Object. I'm thinking, here, for example:
// ..._get_type() { ...g_type_static_register()... }
// ...
Account*
xaccAccountMalloc()
{
Account *a = g_object_new(GNC_ACCOUNT_TYPE, NULL);
// ...existing Account setup...
return a;
}
...and, well, that's about all. No signal or property registration,
in particular.
Any GObject I'll setup will use properties or signal registration,
unless they *must* need it.
I assume you meant here that you will _not_ use ...
[from Option 3...]
Step 4:
Setup QofInstance to be a GObject and be sure to have a correct
construction/destruction process, this will ensure a correct
refcounting.
I'd suggest — in any plan — deferring handling correct
construction/destruction and ref counting to a later phase of work.
The realy point here is to ensure the construction/destruction of
QofInstance and its base class GObject, when
g_object_new/g_object_unref is called, I need to think how to call
g_object_new and ensure the GObject's mechanisms work fine for the
GC's and QOF construction/destruction process with out modify a lot of
code at the same time.
In particular, here's what I see happening. Once you start to modify
(say) xaccFreeTransaction() to be correct, it will want to look like:
xaccFreeTransaction(Transaction *t)
{
g_object_unref(t);
}
...then it only makes sense for its dispose handler to look like...
{
GList *splits = ...;
g_list_foreach(splits, g_object_unref, ...);
}
...which means you have to have correct both ref and unref behavior
for the Splits, which means, they need a correct dispose handler
like...
{
g_object_unref(split-account);
}
...which means ... for it to be correct, everything needs to happen
all at once. It quickly gets to a point where a bunch of changes need
to be made to every file at the same time, increasing the chance that
the whole set isn't clear or clearly acceptable.
I don't think that that necessarily needs to be the case. Better
construction/destruction and ref-counting can be phased in. In
particular, I think there are related groups of objects (Maybe {Account,
Split, Transaction}. {GncCommodity, GncPrice, GncNumeric} ... c.) that
could ref-count with each other, probably while intentionally ignoring
other groups of objects. Along the way it wouldn't be fully correct
nor complete, but it'd be much more tractable.
I realy want to make as less changes as possible, thats why I'm
sharing this plan.
The Option 3 is for get GObject in the early steps and when GncObject
was finished change (this process is realy easy to do) change the base
class to GncObject.
If we gain GC's objects to be GObject some other could use, for
example, a signal modified in a Transaction to create two
transactions to separate the sale and the tax of the transaction
when needed, a feature some one (including me) wants in GC; and get
advantages even if it doesn't use GncObject as its base class yet.
I'm not exactly sure what you're saying here, but remember that this
plan is about functional intermediate steps - but they're still
intermediate. We don't intend to _leave_ the conversion half-way
done, even though we do want it to be _working_ when only half-way
done.
Please reconsider again, and think about the
Re: GObject in GC implementation Plan
On Wed, Mar 21, 2007 at 12:42:32AM -0600, Daniel Espinosa wrote: GOBJECT IN GC IMPLEMENTATION PLAN: OBJECTIVE Get GObject as the base of GC's objects. With the following advantages: - Get ref counting - Get signals events STATE OF THE ART QOF is the object system used by the GC's objects, it has the following features: - Base class Object construction/destruction - Signal handling - Type system based on strings - Objects Properties like system called Parameters GC's objects depends directly from QofInstance, witch actually depends directly from QofEntity, both QofInstance and QofEntity, are virtual objects that means you can't create an instance of them; then the GC's objects when created need to init its base class QofInstance and this its own QofEntity. QofEntity holds the GUID, the unique id for the object, the type of the object as a string and a pointer to the QofCollection where this entity is stored. QofInstance holds pointer to the book it belongs to, and information that allows to know the state of the object related to commit to the backend. The string type system is hard to change for now, then this will need be modified in other work; for now is possible to leave it as is, because changing to GType means to alter the way of QofBook stores objects, QofParam identifies the parameters types, and QofQuery identifies the parameters. STEPS TO GET GOBJECT In order to get GObject as the base class for the GC's objects and get its functionalities, we can go though the following options: **OPTION 1: PORT QofEntity TO USE GObject AS BASE CLASS Step 1: Setup QofEntity, QofInstance and ALL GC's objects to be GObjects in order to have a correct construction/destruction process, this will ensure a correct refcounting. **ADVANTAGES Make all in one step and get GObject from the base QOF system. **DISADVANTAGES Too many changes to be mergable in Trunk. ***OPTION 2: PORT QofInstance TO USE GObject AS BASE CLASS Step 1: Merge QofInstance and QofEntity. This allow to get a single class used as the base for the GC's objects. Step 2: Setup QofInstance and ALL GC's objects to be GObjects and be sure to have a correct construction/destruction process, this will ensure a correct refcounting. **ADVANTAGES Make all in few steps and get GObject from the base QOF system. Simplify the object class hierarchy. **DISADVANTAGES Too many changes to be mergable in Trunk. ***OPTION 3: PORT GC's OBJECT TO USE GObject AS BASE CLASS Step 1: (this step can be done Object by Object, don't need to work in all objects at the same time) Make the QofInstance member as a Pointer, and allow to create a pointer to a QofInstance when the object is created using g_object_new. This means: - Add a new function in QofInstance to allow create an instance, setup it and return a pointer to a QofInstance - No modification in the current QofInstance implementation - Will need to change all references (JUST in the currently changing object) from 'object-inst.[someQofInstanceMember]' to 'object-inst-[someQofInstanceMember]' - Needs to change the definition of QOF_INSTANCE macro to call a functions witch returns the QofInstance pointer member of the GC's object Step 2: Setup the currently working object to be a GObject. This means: - The base class will be GObject not QofInstance - Other objects, not currently changing, will use the same QofInstance base class and its current construction/destruction process Step 3: Merge QofInstance and QofEntity. This allow to get a single base class. Step 4: Setup QofInstance to be a GObject and be sure to have a correct construction/destruction process, this will ensure a correct refcounting. Step 5: Now we can change the base class from GObject to QofInstance in all GC's objects. **ADVANTAGES Get GObject features directly in GC's objects quickly. Allows to delay the required modifications in QOF to later steps. Allows to modify QOF WITH OUT modify the GC's objects; even is possible to work on QOF with out modify the GC's objects, but this delay to get GObject in GC Once the process in QOF to GObject is finished we can change the base class in GC's objects again to QofInstance Simplify the object class hierarchy. **DISADVANTAGES Require to change the base class of the GC's objects from QofInstance to GObject. Needs to change the code from direct access to the members in QofInstance from '.' to '-'. Changing all the engine objects to include QofInstance by pointer is bad, so I think that Option 3 is out. Let's focus on Option 2. In particular, let's specify exactly what would and wouldn't have to be changed outside of qof, during this first round of changes. WOULD CHANGE * the internal implementation of allocation method, eg.
gobject-engine-dev branch progress
Daniel, First off, it's really good to see you committing. It's much easier to help you when everyone can see what you're doing. I think you're basically on the right track with the concept of your changes. But... now for the bad news :( Regarding the actual commits in this branch, it's really not going well. At all. There are really too many things wrong with your recent commits to go into, so I think it's better to look at the big picture. You should know that it's quite common for us to start one branch just to figure our how to do something right, and then redo the branch in order to actually do it right. If that's what you're doing, that's fine. However, you should know that the commits on the current branch will never be merge-able. In fact, the commits on the branch so far suggest that you might not realize what the standards are for a branch to be merge-able. It might be pretty disappointing for you to only figure that out later, and since they're not explicit in the docs, I want to try to be more clear about them. And now, since you've committed some code, we have some examples for reference. The _goal_ is to have a branch of small, logical, well-documented changes, such that each revision compiles, and works. (In exceptional cases, there might be minor, well-understood regressions.) Of course, when you start, you don't know what that set of changes will look like, but here's the strategy I recommend (and use) to figure it out: 1) Make a single logical change that's fundamental to your final goal. In this case, it might be making QofEntity a Gobject, or combining QofEntity into QofInstance, or, possibly, combining QofEntity into Qofinstance and making it a GObject. Although, that might be too big to qualify. 2) Identify the _minimum_ set of changes to make the first change compile and work. 3) Classify all the changes in 2) into two groups: A) those that don't depend on the change in 1); and B) those that do. An example in group A) would be changing a use of acc-inst.entity to QOF_ENTITY(acc). An example in group B) would be using some new GObject-provided feature of the class. Another example would be using qof_instance_get_kvp_data(acc) instead of acc-inst.kvp_data. 4) If all the changes in A) are small, preparatory changes, then prepare commits for them at the beginning of the sequence. If any of the changes in A) is itself a more fundamental change, possibly with its own prerequisites, then put everything on hold, and restart the process with that change as step 1). Often, group A can be broadly characterized as using existing abstractions that should've be used all along. 5) Now, look at group B. This group of changes is problematic, because their dependence on #1) implies that you can't make change #1) without making them, too. But, their absence from #1 implies that they are not logically fundamental to the change in #1. This group must be eliminated, by either 5.1) deciding that the change really is fundamental to #1, and so should be included in #1, or 5.2) realizing that the change doesn't really depend on #1, but instead is a desirable, but, strictly speaking, optional, consequence of #1, or, more usually, 5.3) changing #1 in some way to eliminate the need for the change. In the end, group B usually turns out to be broadly characterized as introducing new abstractions that decouple the code I want to change from the code that depends on the code I want to change. And, most importantly, it can now be ordered before or with #1. In this specific case, step 5) will probably involve introducing lots of ugly #defines and typedefs. For example, #define QOF_ENTITY QOF_INSTANCE. That's okay. Let me just throw out a wild, off-the-cuff estimate what your first merge-able branch should look like. 95% of the changes would be under libqof. It would introduce 100 new #defines. It would have 30-50 revisions, and half of them could theoretically be made in trunk with no breakage. It would result in the top-level objects being GObjects, but not the core engine objects yet, except insofar as the engine objects are struct-overlays of GObjects. It would work exactly as well as trunk. Perhaps you don't realize that that's all that would have to be accomplished before we'd want to merge it into trunk. We know you'd want to take it much further, but you can have as many branches as you want. The more, the better. You probably have plans enough to make 4-5 more branches just as substantial as the first. Also, let me say, yes, I know this is tedious, painful work, especially when you're confident that you can just make it work. But, it's the price we all pay in order to work together even though we don't share the same brain. And, it's important. I don't see how this line of development is going to help, even when trying to create mer-gable branch. The commits are just way too
Re: exp10() error on winXP svn 15713
On Tue, Mar 13, 2007 at 11:04:50PM -0400, Nathan Buchanan wrote:
Hello!
I ran into the following error when building svn 15713:
../../../repos/src/app-utils/gnc-ui-util.c: In function `integer_to_words':
../../../repos/src/app-utils/gnc-ui-util.c:1605: warning: implicit
declaration of function `exp10'
make[4]: *** [gnc-ui-util.lo] Error 1
make[4]: Leaving directory `/c/soft/gnucash/build/src/app-utils'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/c/soft/gnucash/build/src/app-utils'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/c/soft/gnucash/build/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/c/soft/gnucash/build'
make: *** [all] Error 2
it looks like exp10() is not defined - at least on my ststem. The call to
exp10() was added as part of r15677. Related lines:
while (val = 1000) {
log_val = log10(val) / 3 + FUDGE;
pow_val = exp10(log_val * 3) + FUDGE;
Does it work if you change this line to:
pow_val = exp(log_val * 3 * G_LN10) + FUDGE;
-chris
this_part = val / pow_val;
val -= this_part * pow_val;
tmp = integer_to_words(this_part);
g_string_append_printf(result, %s %s , tmp,
gettext(big_numbers[log_val]));
g_free(tmp);
}
Nathan
PS: this is with a fresh checkout and after I removed the build directory.
--
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
A conclusion is the place where you got tired of thinking.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: 80-column width [WAS: Re: indent]
On Fri, Mar 09, 2007 at 10:16:47AM -0500, Josh Sled wrote: On Thu, 2007-03-08 at 23:46 -0500, David Hampton wrote: -l80Line width of 80. This one I find problematic. I understand the arguments for it, and have made them myself. But identifiers and type names are just too long these days. An 80-char limit can cause frequent and unnatural line-breaking; I think 100-char limit is more realistic. I do think a 80-char limit is a good guideline ... but an unbroken (e.g.) 95-character line is better than an 80-character line followed by a 15-character line. See the attached example of over-zealous wrapping differences of gnc-plugin-page-register.c. If we persist, I think we should have a convention for where the '=' goes, and that is at the beginning of the next line (like other continuing operators). Let me speak up in favor of the 80-char limit. However, I'm okay with treating it as strongly encouraged rather than rigorously enforced. I'm sympathetic that, sometimes, overrunning the 80-char limit is less unreadable than some of the obvious line-wrapping alternatives. In order to make the overruns as rare as practical, I think we should: 1) encourage the use of the static functions prefixed with the acronym-ed name of their gtype receiver. e.g. gppr_close_helper() instead of gnc_plugin_page_register_close_helper(); and 2) encourage wrapping after the open parenthesis, e.g.: foo_is_a_short_name = but_these_names_are_rather_too_long( argument1, argument2, argument3, argument4); Do the ident settings permit 2)? -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: indent
On Thu, Mar 08, 2007 at 11:46:53PM -0500, David Hampton wrote:
There's been some discussion on IRC about using the indent program to
reformat the sources into something consistent from file to file. I'd
like to propose the following options as a starting point for
discussion. I think some of these options will be agreed upon by all,
and I'm sure others will be contentious. :-)
Indentation
-nut No tabs. Indentation is done with spaces.
-i4 Add four spaces for each indent level
-ci4 Continuation lines are indented by four spaces
-cli4 Case labels are indented by four spaces
-ppi4 Nested pre-processor defines are indented by four spaces
-nbc Do not force newlines after commas in declarations (default)
-nbfdaDon´t put each argument in a function declaration
on a separate line (default)
-lp Line up continued lines at parentheses (default)
-psl Put the type of a procedure on the line before its name.
-bbo Prefer to break long lines before boolean operators.
Blank Lines
-nsob Do not swallow optional blank lines (default)
-bad Force a blank line after a declaration.
-bbb Force a blank line before a block comment.
-bap Force blank lines after procedure bodies.
Comments
-fca Reformat all comments except those starting in column 1
-fc1 Reformat comments starting in column 1
-sc Continuation lines in a comments start with a '*'
Statements
-npcs Do not put space after the function in function calls.
-nprs Do not put a space after every ´(´ and before every ´)´.
-ncs Do not put a space after cast operators.
-saf Put a space after each for.
-sai Put a space after each if.
-saw Put a space after each while.
-brs Put braces on struct declaration line.
-br Put braces on line with if, etc.
-ce Cuddle else and preceeding `}´.
-cdw Cuddle while of do {} while; and preceeding `}´.
Other
-l80 Line width of 80.
Attached is a small source file formatted with the above options.
Let the discussion begin. :-)
Of the above list of options, the ones I feel strongly about are lining
up continued lines at parentheses (-lp), the space-after-keyword group
(saf, -sai, -saw), and the cuddling-of-braces group (-br, -ce, -cdw). I
feel most strongly about this last group. The parts of an if/then/else
statement are clearly delineated by the indentation of the keywords vs.
the indentation of the code blocks. I believe it a complete waste to
additionally add vertical separation my making the else take up three
lines. One for a closing parenthesis, one for the word else, and one
for an opening parenthesis. Maybe that's just me.
What do the rest of the developers think?
I like it. It's basically KR, but with -bad -psl and some
comment-formatting.
I would recommend adding -ss, and I would have defaulted to -cli0,
which is also KR, but I don't feel strongly about it.
-chris
David
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: tutorial on multi-currency accounting
On Tue, Mar 06, 2007 at 03:54:05PM -0500, Mike Alexander wrote: --On March 5, 2007 11:26:57 AM -0500 Chris Shoemaker [EMAIL PROTECTED] wrote: Mike, Peter, et al., I should have spoken up eariler, but have been pretty busy. I just now skimmed Peter's reports, and wanted to comment. First off, Peter's assessment of GnuCash's flaws are fundamentally correct. I went through a similar process of research and conclusion about a year ago, when I started the register-rewrite branch. It turned out to be a lot more work than I expected, because I hadn't yet realized _why_ multi-currency didn't work in the existing register. Relative to GnuCash, my conclusion was that the existing register design is fundamentally incapable of being used to do multi-currency correctly. This is the cause of many of the very long-standing open bugs regarding multi-currency support. So, when figuring out how to make it work correctly, I found that I had to not only re-implement, but also re-design the register and many of the functions that ensure balanced transaction entry. The good news is that I believe that GnuCash's foundational Transaction and Split data structures can accomodate the right way. Mathematically, the contraints and relationships in a multi-currency transaction are exactly the same as in a stock transaction, with capital gains/losses. Peter's recommendation that the register show the currency in each split is essential to any sort of reasonable interface to accurate transactions. While the use of full-blown trading accounts has some nice properties, there are also some smaller changes that would still be an improvement, even if it still meant calculating exchange gains/losses at report-time. Those changes would allow someone who wanted to use trading accounts manually to do so correctly. Fundamentally, I see this as a UI issue, and I believe that I've designed the new register in such a way as to support multi-currency transactions correctly, albeit still with report-time calculation of gains/losses. Mike, if you're up for it, I encourage you to take a look at the register-rewrite, and see if it supports multi-currency transactions correctly. Even if you're not, I'd be interested to hear more specifically which improvements you're working on. (BTW, I know you have outstanding patches filed in BZ that might relate to this functionality. I feel bad that they've been neglected, but the fact is, everybody's understandably shy to touch some of that messy code.) Just a status note about register-rewrite: It should be completely functional, just not very polished and not yet convenient to use. For evaluation, I like opening a new register and an old register side-by-side in adjacent tabs. (You can do this by double-clicking accounts in a budget, which still opens the old register.) I'm glad we all mostly agree about what needs to be changed. I agree that the current register code is a bit of a mess and doesn't support this sort of change well. I'll take a look at the register rewrite, but I think I've managed to make some changes that improve things with the current register code and which hopefully will port to the new register code without too much trouble. Here's a brief summary of what I've done so far (all of these changes are under control of a new preference and things work as before if it is off): - Changed xaccTransGetImbalance to return a list of all the imbalances in the transaction. The list will contain an entry for each commodity that is not balanced or for the transaction value if the new preference is off and it is unbalanced. This required adding a new data type (or at least I couldn't find an existing data type for it) similar to the commodity-collector used in Scheme code. The old version is now called xaccTransGetImbalanceValue and is still used in a few places. - xaccTransScrubImbalance now scrubs the transaction two ways. It makes sure the value is balanced, and it makes sure that the amounts balance separately for each commodity in the transaction. This makes capital gain splits as created by scrubbing lots unnecessary, although existing capital gains splits won't hurt anything. I assume this is done by auto-creating currency-accounts? - gnc_split_register_get_debcred_entry shows the split amount instead of the split value. It also shows the commodity symbol unless the commodity is the register's commodity or the split has the focus. I think it's likely that users will want to see both in some cases. This is one of the things that is much easier with the register rewrite. - The balance sheet report (as patched for bug 131623) is changed to not compute unrealized gains if the new preference is on since they will already be accounted for if all transactions are balanced. I don't know if this will work as a preference in the long-term. Being a preference
Re: tutorial on multi-currency accounting
On Sun, Mar 04, 2007 at 11:56:20PM -0500, Mike Alexander wrote: --On February 22, 2007 4:09:22 AM -0400 Peter Selinger [EMAIL PROTECTED] wrote: I have also written a fairly detailed critique of multi-currency accounting in GnuCash, with some suggestions for how it could be improved. Unlike the tutorial above, this second document is specific to GnuCash, but must be read after the tutorial: http://www.mathstat.dal.ca/~selinger/accounting/gnucash.html I thought I would let folks know that I've been working on some changes similar to the ones suggested on this page. As might be expected, it's not as simple as it seems and I don't know if the result will be useful or not, although it looks somewhat promising. I thought I'd mention it here in case anyone else is thinking about working on this. If so let me know so we can compare notes. I'm making all these changes under control of a new preference and if it is off GnuCash behaves as before. When I get something working I'll submit a patch in case anyone is interested in it. Mike, Peter, et al., I should have spoken up eariler, but have been pretty busy. I just now skimmed Peter's reports, and wanted to comment. First off, Peter's assessment of GnuCash's flaws are fundamentally correct. I went through a similar process of research and conclusion about a year ago, when I started the register-rewrite branch. It turned out to be a lot more work than I expected, because I hadn't yet realized _why_ multi-currency didn't work in the existing register. Relative to GnuCash, my conclusion was that the existing register design is fundamentally incapable of being used to do multi-currency correctly. This is the cause of many of the very long-standing open bugs regarding multi-currency support. So, when figuring out how to make it work correctly, I found that I had to not only re-implement, but also re-design the register and many of the functions that ensure balanced transaction entry. The good news is that I believe that GnuCash's foundational Transaction and Split data structures can accomodate the right way. Mathematically, the contraints and relationships in a multi-currency transaction are exactly the same as in a stock transaction, with capital gains/losses. Peter's recommendation that the register show the currency in each split is essential to any sort of reasonable interface to accurate transactions. While the use of full-blown trading accounts has some nice properties, there are also some smaller changes that would still be an improvement, even if it still meant calculating exchange gains/losses at report-time. Those changes would allow someone who wanted to use trading accounts manually to do so correctly. Fundamentally, I see this as a UI issue, and I believe that I've designed the new register in such a way as to support multi-currency transactions correctly, albeit still with report-time calculation of gains/losses. Mike, if you're up for it, I encourage you to take a look at the register-rewrite, and see if it supports multi-currency transactions correctly. Even if you're not, I'd be interested to hear more specifically which improvements you're working on. (BTW, I know you have outstanding patches filed in BZ that might relate to this functionality. I feel bad that they've been neglected, but the fact is, everybody's understandably shy to touch some of that messy code.) Just a status note about register-rewrite: It should be completely functional, just not very polished and not yet convenient to use. For evaluation, I like opening a new register and an old register side-by-side in adjacent tabs. (You can do this by double-clicking accounts in a budget, which still opens the old register.) -chris -- Mike Alexander [EMAIL PROTECTED] Ann Arbor, MIPGP key ID: BEA343A6 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Raise dependency versions of GLib, Pango and GTK+
On Wed, Jan 17, 2007 at 08:42:13PM -0500, Josh Sled wrote: On Tue, 2007-01-16 at 12:58 +0100, Andreas Köhler wrote: currently the code base depends on GLib = 2.4, Pango = 1.6 and GTK+ = 2.4. I would like to propose higher base versions, at least for GLib, better for all three of them. [deletia] There might be other reasons, like removing the burden to check whether a GLib/Gtk 2.6 feature is worth single-casing it. What do you think? Yeah, we should treat them as a triple... I updated README.dependencies with the status of a catch-all gtk+ verison number (from distrowatch) for the last two releases of the top 5 distros. Assuming we get 2.2 out the door in April, that means the 6 month dependency window is October 2006 ... which is about when Ubuntu, Mandriva and Fedora Core last released ... Suse was in December, and Debian just doesn't work that way. In any case, gtk 2.8 seems acceptable, and gtk+-2.10 is almost in there (except for Suse). So, should we go to 2.6, or 2.8? I say 2.8. RHEL4 users have gnucash-2.0.4 to get them by, and we're not really helping them by restricting ourselves to 2.6 if they're still on 2.4. I'd suggest bumping to 2.6 for now. If it turns out that we really start wishing we had 2.8 then we can reconsider at then. I didn't see any new-in-2.8 symbols that seemed that compelling, but time will tell. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Fwd: Bug#406378: gnucash bug #406378]
On Sun, Jan 14, 2007 at 12:52:34PM -0800, Thomas Bushnell BSG wrote: See the attached message. :) Please don't cast GType into guint; it breaks the API and fails on Alpha (at least). If you look at http://bugs.debian.org/406378, there is a patch at the end of the bug log which Steve Langasek says fixes the current problems. Can someone please check that into gnucash for the next release? I'll take care of it. And, please, don't cast GType into guint. Also, Steve is serious in asking where did they get the idea this was ok; apparently there are *lots* of gtk+ programs which are doing this, and so he really would like to find what documentation or whatever is confusing and leading people to make this mistake so often in so many different programs. It's historical. g_type_register_static() was advertized as a replacement for gtk_type_unique() which returned GtkType, which was a guint. See: http://developer.gnome.org/doc/API/gtk/gtk-types.html#GTKTYPE When we switched from GtkType to GType, we missed the fact that GType wasn't also a guint. -chris Thomas Content-Description: Forwarded message - Bug#406378: gnucash bug #406378 X-UIDL: 2fda1099cc5ea9cf109a2f05d45f8763.1168804738.81 Envelope-to: [EMAIL PROTECTED] Delivery-date: Sun, 14 Jan 2007 04:11:07 -0800 X-Loop: [EMAIL PROTECTED] Subject: Bug#406378: gnucash bug #406378 Reply-To: Steve Langasek [EMAIL PROTECTED], [EMAIL PROTECTED] Resent-From: Steve Langasek [EMAIL PROTECTED] Resent-To: debian-bugs-dist@lists.debian.org Resent-CC: [EMAIL PROTECTED] (Thomas Bushnell, BSG) Resent-Date: Sun, 14 Jan 2007 12:03:12 + Resent-Message-ID: [EMAIL PROTECTED] X-Debian-PR-Message: report 406378 X-Debian-PR-Package: gnucash X-Debian-PR-Keywords: unreproducible X-Debian-PR-Source: gnucash Date: Sun, 14 Jan 2007 03:55:45 -0800 From: Steve Langasek [EMAIL PROTECTED] To: Thomas Bushnell BSG [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Level: X-Spam-Status: No, hits=-0.3 required=4.0 tests=BAYES_00,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60-bugs.debian.org_2005_01_02 Resent-Sender: Debian BTS [EMAIL PROTECTED] Resent-Date: Sun, 14 Jan 2007 04:03:13 -0800 On Sat, Jan 13, 2007 at 09:26:13PM -0800, Thomas Bushnell BSG wrote: Hi Steve; you were very helpful with the last alpha bug reported by this submitter; I'm wondering if you can give it a little attention. I don't have easy access to an alpha to reproduce the problem. Please ask upstream where they got the idea that g_type_register_static() returned a guint, or that it was otherwise ok to cast its GType return type to a guint. Years of debugging crashing gtk+ programs on alpha, and it's always the same thing -- somehow, GTK programmers are consistently getting bad information about how to use gobject, and I want to know where it's coming from so I can lart the people responsible. Attached is a partial patch which fixes the bug responsible for the *current* crasher bug on alpha. Searching the code, there are several more instances of this type abuse that will also need to be cleaned up if we want things like searching to not crash. I'll follow up with a full patch soon. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: AUDIT: r15381 - gnucash/trunk/src - Fix cases where something that should be a GType isn't defined
On Sun, Jan 14, 2007 at 07:52:06PM -0500, David Hampton wrote: Author: hampton Date: 2007-01-14 19:52:04 -0500 (Sun, 14 Jan 2007) New Revision: 15381 Trac: http://svn.gnucash.org/trac/changeset/15381 Modified: gnucash/trunk/src/business/business-gnome/search-owner.c gnucash/trunk/src/business/business-gnome/search-owner.h gnucash/trunk/src/gnome-search/gnc-general-search.c gnucash/trunk/src/gnome-search/gnc-general-search.h gnucash/trunk/src/gnome-search/search-account.c gnucash/trunk/src/gnome-search/search-account.h gnucash/trunk/src/gnome-search/search-boolean.c gnucash/trunk/src/gnome-search/search-boolean.h gnucash/trunk/src/gnome-search/search-date.c gnucash/trunk/src/gnome-search/search-date.h gnucash/trunk/src/gnome-search/search-double.c gnucash/trunk/src/gnome-search/search-double.h gnucash/trunk/src/gnome-search/search-int64.c gnucash/trunk/src/gnome-search/search-int64.h gnucash/trunk/src/gnome-search/search-numeric.c gnucash/trunk/src/gnome-search/search-numeric.h gnucash/trunk/src/gnome-search/search-reconciled.c gnucash/trunk/src/gnome-search/search-reconciled.h gnucash/trunk/src/gnome-search/search-string.c gnucash/trunk/src/gnome-search/search-string.h gnucash/trunk/src/gnome-utils/gnc-query-list.c gnucash/trunk/src/gnome-utils/gnc-query-list.h gnucash/trunk/src/gnome/gnc-split-reg.c gnucash/trunk/src/gnome/gnc-split-reg.h gnucash/trunk/src/register/register-gnome/gnucash-date-picker.c gnucash/trunk/src/register/register-gnome/gnucash-date-picker.h Log: Fix cases where something that should be a GType isn't defined properly. Problem pointed out by Steve Langasek and is listed as Debian bug 406378. BP Good for backport. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r15383 - gnucash/trunk/src - Use GtkTreeModelFlags instead of guint.
On Sun, Jan 14, 2007 at 09:13:49PM -0500, David Hampton wrote: On Sun, 2007-01-14 at 20:08 -0500, Chris Shoemaker wrote: Author: chris Date: 2007-01-14 20:08:54 -0500 (Sun, 14 Jan 2007) New Revision: 15383 Trac: http://svn.gnucash.org/trac/changeset/15383 Modified: gnucash/trunk/src/gnome-utils/dialog-account.c gnucash/trunk/src/gnome-utils/gnc-tree-model-account.c gnucash/trunk/src/gnome-utils/gnc-tree-model-commodity.c gnucash/trunk/src/gnome-utils/gnc-tree-model-selection.c gnucash/trunk/src/gnome/dialog-sxsincelast.c Log: Use GtkTreeModelFlags instead of guint. Should this be back-ported to 2.0? No need, really. It's not a bugfix. Just protection against future gtk ABI changes. -chris David ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r15383 - gnucash/trunk/src - Use GtkTreeModelFlags instead of guint.
On Sun, Jan 14, 2007 at 09:23:32PM -0500, David Hampton wrote: On Sun, 2007-01-14 at 21:20 -0500, Chris Shoemaker wrote: On Sun, Jan 14, 2007 at 09:13:49PM -0500, David Hampton wrote: On Sun, 2007-01-14 at 20:08 -0500, Chris Shoemaker wrote: Author: chris Date: 2007-01-14 20:08:54 -0500 (Sun, 14 Jan 2007) New Revision: 15383 Trac: http://svn.gnucash.org/trac/changeset/15383 Modified: gnucash/trunk/src/gnome-utils/dialog-account.c gnucash/trunk/src/gnome-utils/gnc-tree-model-account.c gnucash/trunk/src/gnome-utils/gnc-tree-model-commodity.c gnucash/trunk/src/gnome-utils/gnc-tree-model-selection.c gnucash/trunk/src/gnome/dialog-sxsincelast.c Log: Use GtkTreeModelFlags instead of guint. Should this be back-ported to 2.0? No need, really. It's not a bugfix. Just protection against future gtk ABI changes. Well, are you sure that GtkTreeModelFlags is always a guint? Including on the Alpha? :-) Sure. I checked both of them. :-P -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: engine objects vs. SX or invoices (was: GDA: A few questions)
On Tue, Dec 12, 2006 at 09:47:10AM +0100, Christian Stimming wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Shoemaker schrieb: I'm just saying SXs could use the real engine objects, just like Invoices. The only difference is that the engine has to learn that real SX transactions aren't _that_ real. :) Except Invoices don't either, for the same reason that it's causing trouble that SXes do -- it complicates all the code when EVERYONE has to be aware that a foo-object is really part of a bar-object. Much easier to just have foo object and bar object and then use KVP GUIDs to link back and forth. I can see your point, but I just don't agree that the benefit of not requiring the engine to know how to provide a list of transactions that excludes SXs is greater than the benefit of reusing the data-structures and constraint code. There's an interesting additional twist here: We also have imported transactions, i.e. those that have been read by some import-export module and are being reviewed by the user in the generic transaction matcher. These took exactly the opposite approach than invoices or SX: They are being created as real transactions, except that all of them are not yet committed until the generic transaction matcher dialog is finished (at which point in time each imported transaction is either fully committed or deleted again). However, this leads to all sorts of problems with the registers of the accounts in question. See http://bugzilla.gnome.org/show_bug.cgi?id=150569 http://bugzilla.gnome.org/show_bug.cgi?id=341076 to name a few. The whole generic importer framework would rather need a data type of its own as well - OR the real objects might have another flag added that says I'm not a real object to the engine. Chris, would your understanding of a potential SX implementation lead to a solution like that? Yes, in my opinion, imported transactions and template transactions are both similar enough to real transactions to reuse the existing data structure and code. This obviously (almost) works for import. I would diagnose the problem with import being that it makes no attempt to distinguish transactions in the process of being imported from real posted transation. Import Transactions can be really created at the beginning of the import process. At the end they can be promoted into real transactions or deleted. All the while, we wouldn't be keeping transactions in an open state for long periods, and we wouldn't be affecting any other views that only care about real transaction. AFAICT, this is really quite a minor change for Import, but I think it would work. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: AUDIT: r15205 - gnucash/trunk - Load and store a commodity's KVP-frame (IFF it's non-empty).
On Mon, Dec 11, 2006 at 11:01:55PM -0500, Derek Atkins wrote:
I'll just point out a couple of things:
1) This patch doesn't actually change any data formats, because there's
no data in those fields. So without additional changes (which I agree
should not get backported), there's no chance of a data format change.
That requires us to be careful not to make any changes that use
commodity KVPs.
2) Your proposed change makes it WORSE, because it no longer preserves
data! It would happly read in the KVP data but then NOT SAVE IT BACK
OUT! I think that would be even worse than tossing chunks.
Keep in mind that just making the XML parser not blow chunks on
unrecognized tags isn't sufficient -- we also need to re-write out
those unrecognized tags or we destroy data. Reading and silently
discarding is worse than erroring out.
That's an ideal, but I'm pragmatic. Preserving unrecognized data is
best; Preventing me from opening the file at all is worst. Discarding
unrecognized data is somewhere inbetween. (And it doesn't have to be
silent.)
So, I argue that this change still is safe because it's effectively
unused code, but it would let us add additional information in a 2.2
release and not destroy that data in 2.0, which is why I think we should
backport this change.
Just to be clear, in my opinion, this feature (which we have yet to
actually see) does not by itself justify breaking backward
compatibility, even 2.0 - 2.2.
When we _do_ implement new features, I want to be intentional about
breaking compatibility, not just accept that, well if you're trying to
use your new file with 2.0.4 you're fine, but if you've got 2.0.3,
sorry you can't even open it. That's lousy.
-chris
-derek
Quoting Chris Shoemaker [EMAIL PROTECTED]:
I don't think this should be back-ported. At least not the whole
thing. I don't mind backporting the first and last hunks, but I'm
against breaking backward compatibility of the datafile within a
stable branch.
In fact, even between major releases I think these types of changes
should only be made if there's enough of them to warrant it.
Also, I'd prefer to see the proposed feature implemented _before_
breaking compatibilty, not the other way around.
Now, if someone wanted to make it so that our xml reader didn't croak
on unrecognized tags, that would make this kind of change easier.
So, can we please comment out hunks 2 and 3 with a comment about
re-enabling them when we're willing to break backward compatibility?
-chris
Property changes on: gnucash/trunk
___
Name: svk:merge
-
3889ce50-311e-0410-a464-f059747ec5d1:/local/gnucash/branches/swig-redo:802
3889ce50-311e-0410-a464-f059747ec5d1:/local/gnucash/trunk:943
d2ab10a8-8a95-4986-baff-8d511d9f15b2:/local/gnucash/trunk:13679
d2ab10a8-8a95-4986-baff-8d511d9f15b2:/local/gnucash/trunk2:13366
+
3889ce50-311e-0410-a464-f059747ec5d1:/local/gnucash/branches/swig-redo:802
3889ce50-311e-0410-a464-f059747ec5d1:/local/gnucash/trunk:943
d2ab10a8-8a95-4986-baff-8d511d9f15b2:/local/gnucash/trunk:13699
d2ab10a8-8a95-4986-baff-8d511d9f15b2:/local/gnucash/trunk2:13366
Modified: gnucash/trunk/src/backend/file/gnc-commodity-xml-v2.c
===
--- gnucash/trunk/src/backend/file/gnc-commodity-xml-v2.c 2006-12-11
22:28:36 UTC (rev 15204)
+++ gnucash/trunk/src/backend/file/gnc-commodity-xml-v2.c 2006-12-12
02:51:37 UTC (rev 15205)
@@ -58,6 +58,7 @@
#define cmdty_get_quotes cmdty:get_quotes
#define cmdty_quote_source cmdty:quote_source
#define cmdty_quote_tz cmdty:quote_tz
+#define cmdty_slots cmdty:slots
xmlNodePtr
gnc_commodity_dom_tree_create(const gnc_commodity *com)
@@ -66,8 +67,11 @@
const char *string;
xmlNodePtr ret;
gboolean currency = gnc_commodity_is_iso(com);
+xmlNodePtr kvpnode =
+ kvp_frame_to_dom_tree(cmdty_slots,
+ qof_instance_get_slots(QOF_INSTANCE(com)));
-if (currency !gnc_commodity_get_quote_flag(com))
+if (currency !gnc_commodity_get_quote_flag(com) !kvpnode)
return NULL;
ret = xmlNewNode(NULL, BAD_CAST gnc_commodity_string);
@@ -108,6 +112,10 @@
if (string)
xmlAddChild(ret, text_to_dom_tree(cmdty_quote_tz, string));
}
+
+if (kvpnode)
+ xmlAddChild(ret, kvpnode);
+
return ret;
}
@@ -159,6 +167,12 @@
gnc_commodity_set_quote_source(com, source);
xmlFree (string);
}
+else if(safe_strcmp((char*)node-name, cmdty_slots) == 0)
+{
+ /* We ignore the results here */
+ dom_tree_to_kvp_frame_given(node,
+ qof_instance_get_slots(QOF_INSTANCE(com)));
+}
else
{
struct com_char_handler *mark;
___
gnucash-changes mailing list
Re: engine objects vs. SX or invoices (was: GDA: A few questions)
On Tue, Dec 12, 2006 at 10:05:21AM -0500, Josh Sled wrote: On Mon, 2006-12-11 at 22:06 -0500, Chris Shoemaker wrote: Invoices basically reuse the engine objects. But SXs have: struct TTInfo_s [...] which look suspiciously like a Transaction, and struct TTSplitInfo_s [...] which looks suspiciously like a Split. And then the whole duplicated accounts setup. These structures aren't the actual storage, and are only barely used as runtime representations of Template [Splits and] Transactions. They were sourced from Robert Merkel's work on the SX-from-transaction dialog, and are used (by my hand) in the Mortgage/Loan Druid. In both cases, they're immediately passed to xaccSchedXactionSetTemplateTrans(...), which just converts these degenerate structures into the real template Transactions. Looking back on it, I'd just the calling code to write the template structures directly, though maybe with some convenience functions for readability. Ah, thanks for explaining that. That does make a lot more sense. The only structures relevant are the Accounts, Transactions and Splits rooted in the Template Account-Group. So, they already are real Transactions/Splits in an alternate Account hierarchy, where every account must refer to a real account, (named by its guid). So then, my recommendation is just to use real accounts and flag the transactions as templates. Although, this was originally brought up in the context of the register-rewrite, and using the alternate accounts is not a big deal in the register-rewrite. So, this has just been me harping on what I think is a good code improvement. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: A few questions
On Sat, Dec 09, 2006 at 12:53:35PM -0500, Josh Sled wrote: On Fri, 2006-12-08 at 17:34 -0500, Phil Longstaff wrote: I'm working on saving/restoring scheduled transactions, and have some questions: 1) Accounts - The only difference I can see between regular accounts and the accounts created for scheduled transactions is in the currency - the currency for scheduled transactions is in the template namespace. Anything else? Could we have a new account type called TEMPLATE so that I wouldn't need a really complex query to load just the regular accounts? Until this is fixed (*), I think it's safe to have a separate account-type, yes. As per the other thread, I agree: a bit isn't sufficient, a whole separate rooted tree is The Right Thing, and a bit will probably suffice for the moment. :) (*) This really should be fixed: the template-transaction accounts should probably be a more literal mirror of the real account tree, in terms of types and commodities. The whole point of using real Accounts and Transactions for the template transactions was to leverage the editor (register) and the implicit application constraints for the template transactions ... I didn't want to re-implment or re-specify a bunch of logic around template transactions seperate from real transactions, and especially not the register component. But for a few reasons, they did diverge. In any case, it'd be nice if they were closer together, but that's not a focus of the branches/sx-cleanup/, right now. I know I've mentioned this to jsled, but FTR, I would recommend taking this one step farther... by making SXs real transactions, using real accounts and real splits, but simply flagged at the transaction-level as SX. Then, we make the normal transaction queries exclude SX transactions. As far as register integration goes, then it's just a matter of adding a treeviewcolumn that knows how to display, edit and store (in KVP) the formula-amounts. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: #gnucash public logging?
On Mon, Dec 11, 2006 at 07:19:27PM -0500, Josh Sled wrote:
After our long-serving channel bot Scrambler had gone away for a period
of time, we setup a new channel bot (gncbot) for #gnucash, which is
hosted on {svn,lists,wiki}.gnucash.org.
Another IRC channel that I frequent has a persistant, public channel
logger: all channel activity is recorded, html-ized and published via
HTTP. It is then indexed (primarily by Google, of course, though we
have namazu as well) and searchable. I propose that we should institute
the same mechanism for #gnucash.
It turns out to be a convenient way to record both specific and general
project knowledge. As well, the logs can be useful to backfill
participants who are joining in the middle of a conversation, as well as
those (devs and interested parties) who haven't decided to inhabit the
channel persistently, but are curious about the goings on they might
miss. As well, a longer discussion which results in a decision no
longer needs to be copy-and-pasted to -devel, since the URL of the logs
can be posted.
On the down side, it does change the dynamic of the channel, both for
the transient participants as well as the devs. We have certainly used
the channel to discuss things that we would consider private.
However, the logger does support an [off]-log prefix, and in my
experience this actually works pretty well in allowing off-log
conversation; however, it only works if you know about it...
It's only courteous to inform random people who stop by the channel that
they're being recorded and published. While people do seem to err on
the side of caution when spilling personal financial details, that is
another wrinkle. The channel topic probably suffices, but some sort of
channel entry notice -- as supported by the channel service of most
other IRC networks -- would be better.
On the whole, I think publishing channel logs is a win, or I wouldn't be
suggesting it. :) But what do you think? I guess the options are:
- do it.
- do it for a month or two and re-evaluate.
- don't do it.
1) I'm for it.
2) I think a notice in the channel topic is sufficient.
3) I assume there would be some mechanism for an op to toggle logging off
for the whole channel.
-chris
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: A few questions
On Mon, Dec 11, 2006 at 09:22:15PM -0500, Derek Atkins wrote:
Chris Shoemaker [EMAIL PROTECTED] writes:
(*) This really should be fixed: the template-transaction accounts
should probably be a more literal mirror of the real account tree, in
terms of types and commodities. The whole point of using real Accounts
and Transactions for the template transactions was to leverage the
editor (register) and the implicit application constraints for the
template transactions ... I didn't want to re-implment or re-specify a
bunch of logic around template transactions seperate from real
transactions, and especially not the register component. But for a few
reasons, they did diverge. In any case, it'd be nice if they were
closer together, but that's not a focus of the branches/sx-cleanup/,
right now.
I know I've mentioned this to jsled, but FTR, I would recommend taking
this one step farther... by making SXs real transactions, using real
accounts and real splits, but simply flagged at the transaction-level
as SX. Then, we make the normal transaction queries exclude SX
transactions.
As far as register integration goes, then it's just a matter of adding
a treeviewcolumn that knows how to display, edit and store (in KVP)
the formula-amounts.
See, I think it should go the other way.. I think each object
should be unique and have its own tree-model. If the register
rewrite is general enough then that's all we should need, right?
We could do a test based on an Invoice register
I'm not disagreeing about Invoices. AFAICT, Invoices already have the
design feature that I think SXs should have - they use real accounts,
transactions, and splits, and just note in the transaction KVP that
this is an invoice transaction.
Invoices basically reuse the engine objects. But SXs have:
struct TTInfo_s
{
/* FIXME add notes field */
char *description; /* owned by us */
char *num; /* owned by us */
gnc_commodity *common_currency; /* not freed */
GList *splits; /* list of template splits, owned by us */
};
which look suspiciously like a Transaction, and
struct TTSplitInfo_s
{
char *action; /* owned by us */
/* FIXME: What about the split's KvpFrame */
char *memo; /* owned by us */
char *credit_formula, *debit_formula; /* owned by us */
Account *acc;
};
which looks suspiciously like a Split. And then the whole duplicated
accounts setup. I'm just saying SXs could use the real engine
objects, just like Invoices. The only difference is that the engine
has to learn that real SX transactions aren't _that_ real. :)
Just to clarify, as for the GUI, I'm not suggesting that the register
is a good place to edit or view the SX data structure - just the real
transactions it would link to.
-chris
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: AUDIT: r15205 - gnucash/trunk - Load and store a commodity's KVP-frame (IFF it's non-empty).
On Mon, Dec 11, 2006 at 09:51:37PM -0500, Derek Atkins wrote:
Author: warlord
Date: 2006-12-11 21:51:37 -0500 (Mon, 11 Dec 2006)
New Revision: 15205
Trac: http://svn.gnucash.org/trac/changeset/15205
Modified:
gnucash/trunk/
gnucash/trunk/src/backend/file/gnc-commodity-xml-v2.c
Log:
Load and store a commodity's KVP-frame (IFF it's non-empty).
This would let us store something like an Asset Class.
BP
I don't think this should be back-ported. At least not the whole
thing. I don't mind backporting the first and last hunks, but I'm
against breaking backward compatibility of the datafile within a
stable branch.
In fact, even between major releases I think these types of changes
should only be made if there's enough of them to warrant it.
Also, I'd prefer to see the proposed feature implemented _before_
breaking compatibilty, not the other way around.
Now, if someone wanted to make it so that our xml reader didn't croak
on unrecognized tags, that would make this kind of change easier.
So, can we please comment out hunks 2 and 3 with a comment about
re-enabling them when we're willing to break backward compatibility?
-chris
Property changes on: gnucash/trunk
___
Name: svk:merge
-
3889ce50-311e-0410-a464-f059747ec5d1:/local/gnucash/branches/swig-redo:802
3889ce50-311e-0410-a464-f059747ec5d1:/local/gnucash/trunk:943
d2ab10a8-8a95-4986-baff-8d511d9f15b2:/local/gnucash/trunk:13679
d2ab10a8-8a95-4986-baff-8d511d9f15b2:/local/gnucash/trunk2:13366
+
3889ce50-311e-0410-a464-f059747ec5d1:/local/gnucash/branches/swig-redo:802
3889ce50-311e-0410-a464-f059747ec5d1:/local/gnucash/trunk:943
d2ab10a8-8a95-4986-baff-8d511d9f15b2:/local/gnucash/trunk:13699
d2ab10a8-8a95-4986-baff-8d511d9f15b2:/local/gnucash/trunk2:13366
Modified: gnucash/trunk/src/backend/file/gnc-commodity-xml-v2.c
===
--- gnucash/trunk/src/backend/file/gnc-commodity-xml-v2.c 2006-12-11
22:28:36 UTC (rev 15204)
+++ gnucash/trunk/src/backend/file/gnc-commodity-xml-v2.c 2006-12-12
02:51:37 UTC (rev 15205)
@@ -58,6 +58,7 @@
#define cmdty_get_quotes cmdty:get_quotes
#define cmdty_quote_source cmdty:quote_source
#define cmdty_quote_tz cmdty:quote_tz
+#define cmdty_slots cmdty:slots
xmlNodePtr
gnc_commodity_dom_tree_create(const gnc_commodity *com)
@@ -66,8 +67,11 @@
const char *string;
xmlNodePtr ret;
gboolean currency = gnc_commodity_is_iso(com);
+xmlNodePtr kvpnode =
+ kvp_frame_to_dom_tree(cmdty_slots,
+ qof_instance_get_slots(QOF_INSTANCE(com)));
-if (currency !gnc_commodity_get_quote_flag(com))
+if (currency !gnc_commodity_get_quote_flag(com) !kvpnode)
return NULL;
ret = xmlNewNode(NULL, BAD_CAST gnc_commodity_string);
@@ -108,6 +112,10 @@
if (string)
xmlAddChild(ret, text_to_dom_tree(cmdty_quote_tz, string));
}
+
+if (kvpnode)
+ xmlAddChild(ret, kvpnode);
+
return ret;
}
@@ -159,6 +167,12 @@
gnc_commodity_set_quote_source(com, source);
xmlFree (string);
}
+else if(safe_strcmp((char*)node-name, cmdty_slots) == 0)
+{
+ /* We ignore the results here */
+ dom_tree_to_kvp_frame_given(node,
+ qof_instance_get_slots(QOF_INSTANCE(com)));
+}
else
{
struct com_char_handler *mark;
___
gnucash-changes mailing list
[EMAIL PROTECTED]
https://lists.gnucash.org/mailman/listinfo/gnucash-changes
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: A few questions
On Mon, Dec 11, 2006 at 10:21:36PM -0500, Derek Atkins wrote:
Quoting Chris Shoemaker [EMAIL PROTECTED]:
I'm not disagreeing about Invoices. AFAICT, Invoices already have the
design feature that I think SXs should have - they use real accounts,
transactions, and splits, and just note in the transaction KVP that
this is an invoice transaction.
Not at all. An unposted invoice has no Account, Transaction,
or Split objects.. It has references, but it uses a GncEntry
object as the line item entries.. A GncInvoice is like a Transaction,
and a GncEntry is like a Split, but no, it doesn't re-use the
core engine objects.
Ah, I see. I really don't know the business code well enough to
comment on Invoices then.
Invoices basically reuse the engine objects. But SXs have:
struct TTInfo_s
{
/* FIXME add notes field */
char *description; /* owned by us */
char *num; /* owned by us */
gnc_commodity *common_currency; /* not freed */
GList *splits; /* list of template splits, owned by us */
};
which look suspiciously like a Transaction, and
struct TTSplitInfo_s
{
char *action; /* owned by us */
/* FIXME: What about the split's KvpFrame */
char *memo; /* owned by us */
char *credit_formula, *debit_formula; /* owned by us */
Account *acc;
};
which looks suspiciously like a Split. And then the whole duplicated
accounts setup. I'm just saying SXs could use the real engine
objects, just like Invoices. The only difference is that the engine
has to learn that real SX transactions aren't _that_ real. :)
Except Invoices don't either, for the same reason that it's causing
trouble that SXes do -- it complicates all the code when EVERYONE has
to be aware that a foo-object is really part of a bar-object. Much
easier to just have foo object and bar object and then use KVP GUIDs
to link back and forth.
I can see your point, but I just don't agree that the benefit of not
requiring the engine to know how to provide a list of transactions
that excludes SXs is greater than the benefit of reusing the
data-structures and constraint code.
I'm not saying the same argument holds for invoices.
Just to clarify, as for the GUI, I'm not suggesting that the register
is a good place to edit or view the SX data structure - just the real
transactions it would link to.
Except an SX isn't a real transaction, it's a Template Transaction.
Well, I think of an SX as different from, and containing many,
template transactions, but I think your point is just that template
transactions aren't real. My point is just that the difference
between a template transaction and a real transaction is 95%
semantic and 5% syntactic, and that therefore, it's better to adjust
the syntax just a little to represent both concepts than to duplicate
95% of the syntax to represent the not real transaction.
-chris
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Win32 Port Efforts (eKA$H fork)
On Mon, Dec 11, 2006 at 06:54:55PM -0800, [EMAIL PROTECTED] wrote: Thanks. I think this will work for me. The only situation I can think of where it is not correct at the commodity level is defining asset classes that incorporate a tax hedge strategy (i.e. tax deferred Lg Cap vs. tax immediate Lg Cap). Tax policy balancing is rare but not unheard of in terms of a balanced portfolio. If I understand correctly, Account-level classification is the best thing for that situation, right? In fact, Account-level classification can represent _any_ type of asset balancing, can't it? I think the KVP at the commodity level is good enough. Our datafile _already_ stores/reads account-level KVPs, so using it wouldn't break backward compatibility. -chris As I mentioned earlier, I think I'll abandon my tree and try again from scratch with a recent SVN copy. -Jon. Derek Atkins [EMAIL PROTECTED] wrote: Derek Atkins [EMAIL PROTECTED] writes: Given that not many people are using it yet, I would like to work out a way to implement this functionality in the upstream if possible. It need not be compatible with what I have. Would it be a reasonable comprimise to add some kind of misc field(s) in the XML format for purposes similar to this? In that way, we could achieve compatibility and flexibility in one fell swoop. Well, I would store it in the KVP, sort of how transaction notes are stored in the KVP. But as I said earlier I think this particular data should live with the commodity, and unfortunately I dont think the current data file actually stores the Commodity KVP Frame, so it would be problematic to put it there right now without making changes to the XML code. For the record, I just committed code to Trunk that saves the commodity kvp-frame.. -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 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: current status
On Sat, Dec 09, 2006 at 11:53:52AM -0500, Phil Longstaff wrote: I've included a portion of the GDA_STATUS file which brings up some questions: - Recurrences are currently only used by budgets, and recurrence save/restore is included in the budget save/restore code. If recurrences will eventually be used elsewhere in GC, recurrence save/restore code may need to be split out on its own (separate recurrences table?) No, recurrences don't need a table. They are smaller than one GDate + one gint. You should view them as an immediate data value, like GDate. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: current status
On Sat, Dec 09, 2006 at 06:37:55PM -0500, Derek Atkins wrote:
Quoting Phil Longstaff [EMAIL PROTECTED]:
- Recurrences are currently only used by budgets, and recurrence
save/restore is included in the budget save/restore code. If
recurrences will eventually be used elsewhere in GC, recurrence
save/restore code may need to be split out on its own (separate
recurrences table?)
*GRR* I knew this was going to be a problem. I really should have
been more insistant that Chris fix this BEFORE 1.8. Recurrence and
Freqspec should merge into a single data object. We don't need both,
and having both just duplicates code and confuses the data model. They
perform essentially the same functions and even do it in fairly similar
ways.
It's unfortunate that they are still two separate objects.
For the DB backend I'd really like there to be only one (probably
Recurrence). And yes, it should be its own table.
I think Recurrence is a subset of FreqSpec i.e. FreqSpec can represent a
lot more than a Recurrence can. In any case, I will have 1 table and
the back end will convert to that 1 table. My choice (given my limited
knowledge) is to use FreqSpec because it is a more general mechanism.
If that generality is not desired, feel free to dictate otherwise.
Looks may be misleading. Just because Recurrence has 3 members
instead of FreqSpec's 17 doesn't mean FreqSpec can represent more. In
fact, Recurrence is more general, both in the types of repetition it
can specify, and in that it also represents the starting date.
I just saw Chris's response that Recurrences don't need their own table.
I'll let Derek and Chris hash out the larger architectural issues on
this one.
Recurrences don't have guids, and have no relation to QofInstance or
QofEntity. They are not engine objects. They are data.
Well, I think Freqspec is Recurrence + last-executed + number of
executions.
Actually, not at all. Things like last-executed, number-executed,
start and end dates, and several more are all part of SX, not
FreqSpec.
It would be more accurate to say, conceptually,
Recurrence = FreqSpec + starting date.
I dont really care how they get combined, but really there should be
only one.
Phil, if you want to adapt FreqSpec + starting date from SX into
Recurrences, you're more than welcome, but 1) it's really outside the
scope of gda-dev, so I'd recommend another branch, and 2) be warned
that doing it right is a lot of work, (or it would already have been
done).
The thing about FreqSpec is that they don't look like they need to be
evenly spaced. I don't know why you would not do that, but you might
want a FreqSpec to be last friday of every month or 15th and 30th of
every month which Recurrence wouldn't handle.
Sure it could. Recurrence has:
PERIOD_END_OF_MONTH, /* This is actually a period plus a phase. */
PERIOD_NTH_WEEKDAY, /* Also a phase, e.g. Second Tueday. */
PERIOD_LAST_WEEKDAY, /* Also a phase. */
I'm not exactly sure how you'd handle last friday, except perhaps by
nth weekday where n is -1 and the weekday of the first is friday.
Actually, it's much simpler than that. Last Friday of every month,
beginning yester day is represented as {12/8/2006,
PERIOD_LAST_WEEKDAY, 1} (mult=2 would mean last friday of every
_other_ month, etc.)
BTW, one difference between FreqSpec and Recurrence: FreqSpec can
actually represent an internally-linked tree-structure of nested
composite FreqSpecs. I have no idea why. It's a very inefficent
data structure, since only the leaves carry the data, and the
structure is meaningless. The Recurrence API handles this with a
GList of Recurrences. However, I believe it's an unused interface at
the moment.
-chris
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: current status
The thing about FreqSpec is that they don't look like they need to be
evenly spaced. I don't know why you would not do that, but you might
want a FreqSpec to be last friday of every month or 15th and 30th of
every month which Recurrence wouldn't handle.
Sure it could. Recurrence has:
PERIOD_END_OF_MONTH, /* This is actually a period plus a phase. */
PERIOD_NTH_WEEKDAY, /* Also a phase, e.g. Second Tueday. */
PERIOD_LAST_WEEKDAY, /* Also a phase. */
I'm not exactly sure how you'd handle last friday, except perhaps by
nth weekday where n is -1 and the weekday of the first is friday.
Actually, it's much simpler than that. Last Friday of every month,
beginning yester day is represented as {12/8/2006,
PERIOD_LAST_WEEKDAY, 1} (mult=2 would mean last friday of every
_other_ month, etc.)
For completeness, perhaps I should have also pointed out that it
doesn't matter that 12/8/2006 wasn't the last Friday of the month. By
specifying LAST_WEEKDAY, it will know you mean Friday, and the first
occurrence will be 12/29/2006. This is all documented in Recurrence.h
-chris
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Budget Question
On Sat, Dec 02, 2006 at 01:12:38PM -0500, Jason York wrote: I'm a new gnucash user and I've been playing around with the budget feature. Is there any way to copy values across columns? For example, I've set up a budget with a period of 1 month with 12 periods. I would like to be able to fill in all my budget values for the first month. Then have the option to copy them to the next month. Then I can just modify the few that change for that month. It seems quite tedious to manually re-enter those values for every month. Is there something I'm missing? I'm afraid not. One thing that would improve this situation would be if copy + keynav + paste was really fluid. This could probably be accomplished with some careful handing of focus and editmode. Another idea that's been kicking around is this: Say you start with a one year budget with one period, and fill in all the annual amounts. Then you change it to monthly budget of 12 months. Right now, it would simply leave the annual amounts as the amounts for the first month - not helpful. But wouldn't it be cool if it filled in each month's amount with 1/12 of the annual amount? Several months ago, I convinced myself that there was a well-defined, and often-useful mapping FROM: old_period_length, old_num_periods, (old_values for each old period), new_period_length, new_num_periods TO: new_values for each new period. If not, I would be willing to submit a patch if someone could at least point me in the right direction of what you think would need to be done to implement. I'm capable of coding it up, but I am not familiar with the gnucash source. There's no substitue for reading the source. Start with src/engine/budget.[ch]. -chris I've looked at the Estimate feature, and this is not particularly useful for me. Thanks, -- Jason ___ gnucash-user mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-user - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r15168 - gnucash/trunk - Fix bug #353450 - Crash on quit during save.
On Sat, Dec 02, 2006 at 05:13:14PM -0500, Chris Shoemaker wrote: Author: chris Date: 2006-12-02 17:13:13 -0500 (Sat, 02 Dec 2006) New Revision: 15168 Trac: http://svn.gnucash.org/trac/changeset/15168 Modified: gnucash/trunk/lib/libqof/qof/qofsession-p.h gnucash/trunk/lib/libqof/qof/qofsession.c gnucash/trunk/lib/libqof/qof/qofsession.h gnucash/trunk/src/gnome-utils/gnc-file.c Log: Fix bug #353450 - Crash on quit during save. Add a lock to the QofSession object, and use it in qof_session_save() to protect against re-entrance. The lock always starts at 1 and is 0 while inside qof_session_save(). If another call is made to qof_session_save() while one is in progress, the lock will momentarily drop below 0 before returning to zero. Note: The per-session nature of the lock would make it appear that we support concurrent saving of different sessions. In fact, we do not, because the file backend blocks the main process until the forked gzip process is finished, and it only knows how to keep track of one child pid at a time. I meant to request this for backport. However, because of the imminence of the 2.0.3 release, and because of the nature of the change, I'm requesting that this changeset not be backported until at least 2 devs approve it. Note that the solution I implemented is different from what I was describing in IRC at times. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Why I haven't released yet
On Tue, Nov 14, 2006 at 01:12:18PM -0500, Derek Atkins wrote: Quoting Ludovic Courtès [EMAIL PROTECTED]: Hi, Derek Atkins [EMAIL PROTECTED] writes: For what it's worth, GnuCash SVN/trunk doesn't use g-wrap anymore. We changed over to using SWIG. So once we release 2.2 g-wrap can just be left to die ;) Out of curiosity: could you summarize the reasons why you decided to switch? 1) g-wrap wasn't being maintained; there hasn't been a release for a long time, the release is broken (e.g. it doesn't find glib2 properly), and nobody was responding to any email about issues. 2) g-wrap is hard to build. It doesn't work on many platforms (e.g. I still can't get 1.9.6 to build, let alone work, on Solaris because of libffi). 3) g-wrap is guile-only; swig allows us to theoretically make bindings for many other languages, like perl or python. 4) g-wrap is extremely fragile, and lots of users have problems because e.g. g-wrap got split into too many packages and there's not a good way to make sure all the proper packages are installed 5) swig allows us to build the wrappers during 'make dist' so someone building the package from the tarball doesn't require any build-time (OR Runtime) libraries, so it reduces our dependencies on users. 6) swig is much better supported, has a larger user community, and is much more responsive to issues. 7) swig s used by MANY more applications 8) I'm sure I can come up with more, and I'm sure that Chris or others could add their $0.02 to the mix. 9) Documentation. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: AUDIT: r15088 - gnucash/trunk - Fix some scheme inexact errors. Fixes 347462.
On Sun, Nov 05, 2006 at 11:45:29PM -0500, David Hampton wrote:
Author: hampton
Date: 2006-11-05 23:45:27 -0500 (Sun, 05 Nov 2006)
New Revision: 15088
Trac: http://svn.gnucash.org/trac/changeset/15088
Modified:
gnucash/trunk/ChangeLog
gnucash/trunk/src/report/standard-reports/account-piecharts.scm
gnucash/trunk/src/report/standard-reports/category-barchart.scm
Log:
Fix some scheme inexact errors. Fixes 347462.
BP
Perhaps it's better to fix this inside options.scm,
in gnc:make-number-range-option.
-chris
Modified: gnucash/trunk/ChangeLog
===
--- gnucash/trunk/ChangeLog 2006-11-05 06:58:09 UTC (rev 15087)
+++ gnucash/trunk/ChangeLog 2006-11-06 04:45:27 UTC (rev 15088)
@@ -1,3 +1,9 @@
+2006-11-05 David Hampton [EMAIL PROTECTED]
+
+ * src/report/standard-reports/category-barchart.scm:
+ * src/report/standard-reports/account-piecharts.scm: Fix some
+ scheme inexact errors. Fixes 347462.
+
2006-10-09 Josh Sled [EMAIL PROTECTED]
* art/: Add, with 2.0 {banner,icon,logo,splash} art.
Modified: gnucash/trunk/src/report/standard-reports/account-piecharts.scm
===
--- gnucash/trunk/src/report/standard-reports/account-piecharts.scm
2006-11-05 06:58:09 UTC (rev 15087)
+++ gnucash/trunk/src/report/standard-reports/account-piecharts.scm
2006-11-06 04:45:27 UTC (rev 15088)
@@ -188,7 +188,8 @@
(show-fullname? (get-option gnc:pagename-display optname-fullname))
(show-total? (get-option gnc:pagename-display optname-show-total))
-(max-slices (get-option gnc:pagename-display optname-slices))
+(max-slices (inexact-exact
+ (get-option gnc:pagename-display optname-slices)))
(height (get-option gnc:pagename-display optname-plot-height))
(width (get-option gnc:pagename-display optname-plot-width))
(sort-method (get-option gnc:pagename-display optname-sort-method))
Modified: gnucash/trunk/src/report/standard-reports/category-barchart.scm
===
--- gnucash/trunk/src/report/standard-reports/category-barchart.scm
2006-11-05 06:58:09 UTC (rev 15087)
+++ gnucash/trunk/src/report/standard-reports/category-barchart.scm
2006-11-06 04:45:27 UTC (rev 15088)
@@ -200,7 +200,8 @@
(stacked? (get-option gnc:pagename-display optname-stacked))
(show-fullname? (get-option gnc:pagename-display optname-fullname))
-(max-slices (get-option gnc:pagename-display optname-slices))
+(max-slices (inexact-exact
+ (get-option gnc:pagename-display optname-slices)))
(height (get-option gnc:pagename-display optname-plot-height))
(width (get-option gnc:pagename-display optname-plot-width))
(sort-method (get-option gnc:pagename-display optname-sort-method))
___
gnucash-changes mailing list
[EMAIL PROTECTED]
https://lists.gnucash.org/mailman/listinfo/gnucash-changes
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GC, QOF and queries
On Fri, Nov 03, 2006 at 10:09:47AM -0500, Derek Atkins wrote: Phil Longstaff [EMAIL PROTECTED] writes: What version of LibGDA do you need to get GdaQuery? Is libgda-1.9.100 recent enough? Or do you need something more recent than that? (I ask because 1.9.100 is what FC5 has). I don't know. On the www.gnome-db.org web site, the 1.9.102.changes file is the first one I can see that mentions GdaQuery. That, of course, doesn't mean it doesn't exist earlier. Hmm.. I just pulled down libgda-devel and it indeed looks like there is no GdaQuery. I'm hesitant to request support from a GDA feature that's so new that even FC5 can't use it! I was willing to work with the upgraded SWIG dependency because it's only needed to build from SVN (not the tarball), but this would be a runtime requirement, which means we should be more conservative about it. Sorry, I think we should delay the use of GdaQuery... The fact that FC5-extras has 1.9.100 is irrelavant. That's an unstable release. It's not even forward API-compatible with newer unstable releases. It also has some pretty serious bugs. You have to target a stable api - either 1.2 (FC5 also has 1.2.3) or the still-in-beta 2.0. IMO, 1.2 is not even worth looking at. As far as depending on a library version that's newer than our target distros... my advice is choose the best tool for the job. We know how to deal with the release engineering issues. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Compiling GnuCash on Windows
On Thu, Nov 02, 2006 at 06:28:56PM +0100, Christian Stimming wrote: Also, in the command prompt window is the following: gnucash: [E] Failed to fork child process. This is probably because gnucash tries to save the file in compressed form, which requires a separate gzip process that won't work on windows. In short, in the preferences please uncheck the checkbox under General - File - Compress file. Does saving work, then? I wonder if we should just disable this feature on win32? The feature is already disabled on windows, see io-gncxml-v2.c:1243. I tried to find the place that's causing this failed to fork message, but apparently it doesn't come from within gnucash. At least we don't have that string anywhere, and the only fork() that gnucash uses is in io-gncxml-v2.c which is unused on windows. So I have no idea where this comes from, and I'd simply ignore it for now. That's process.scm which is run during price-quote retrieval. Perhaps guile's (primitive-fork) doesn't work on win32. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GC architecture for backends
On Thu, Nov 02, 2006 at 12:25:17PM -0500, Phil Longstaff wrote: On Thu, 2006-02-11 at 08:40 -0600, Daniel Espinosa wrote: 2006/11/1, Derek Atkins [EMAIL PROTECTED]: Quoting Daniel Espinosa [EMAIL PROTECTED]: Also, we'll need to make changes to handle the fact that file:// should get redirected to sqlite:// -- but the code will need to test the file first to see what kind of file it is, so that File - Open does the right thing. I.e., the fact that we're using SQLite should get hidden from the user when we migrate to it. I think the URI mus be gda:// or db://, think that gda is wrapper for many DB backends not just sqlite. At some level we need to be able to specify what kind of database is sitting behind there. At SOME point we need to know how to specify a filename for SQLite vs. a host/port/user/password for PG. So clearly there's some differentiation there. Isn't the case for GDA, when you create a DSN, you can use this name to connect: you just need to specify the DSN, user, password and some options (read only for example) see the libgda.h file where you'll find some convenient functions to easy use GDA and quick do some very common task. But this is irrelevant to what I meant. What the user types into the File-Open dialog does not need to be the string that gets passed the GDA. If you have an option to connect or open a DSN the URI could be: gda://gnucash:username:password With a gnomedb-login widget you can select a predefined DNS, get username and password, and thats all you can pass it to the QOF beggin session function to open the back end. I'm just pointing out that we need to intercept that input and handle it appropriately, which may mean adjusting the actual string and perhaps calling the XML or GDA-with-SQLite backends. In the event that GC will use just SQLite or other DB engines, you don't need a special intercept, I think the dialog *must* allways show a gnomedb-login widget to select the DSN, write a user and a password, and Go! I haven't thought through all of the issues around connections, but I don't think we want to use predefined DSNs. A user shouldn't have to set up the GC DSN with an external tool in order to use that DSN within gnucash. Phil At least for an initial implementation, I recommend letting the external tools handle DSN setup. The most general setups (i.e. anything other than sqllite) will probably require external configuration anyway. Once it's working, we can worry about streamlining setup for the simple cases. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GC, QOF and queries
On Thu, Nov 02, 2006 at 08:47:30AM -0500, Phil Longstaff wrote: I have started working on a gda backend and am starting with a QofQuery - SQL translator. Have you looked at just directly using the GdaQuery objects? You can constuct an abstract query out of GdaQueryFieldFields, GdaQueryFieldValues and such. Then, libgda will emit the provider-specific SQL for that query. To be frank, IMO, GdaQuery is a better data model for queries than QofQuery. By better, I mean more appropriate for GnuCash. I think it's very unfortunate that GnuCash uses its own home-grown object-agnostic query representation. Someone else will probably disagree. But, if you re-parented GnuCash's engine objects with a GnuCash-sepcific GncObject (even with GValue parameters, maybe), and implemented the QofQuery functionality by generating a GdaQuery, you would be my hero. But that's probably more work than you were hoping for. *sigh* Anyway, try to avoid writing the SQL emitter, if you can. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Another SCM bug in trunk
On Sat, Oct 28, 2006 at 12:14:57PM -0400, Derek Atkins wrote: Quoting Mike Alexander [EMAIL PROTECTED]: [snip] I think this is correct. There were similar problems in some of the reports and that's the explanation I got for the problem. See https://lists.gnucash.org/pipermail/gnucash-devel/2006-October/018834.html. I agree that finding and fixing all of these will be a pain. Yeah, Chris verified this is the problem and has a fix in place. I think we'll need someone to audit all the scheme code to look for any instance of (if ... and make sure it's still valid with the new '() as NULL-pointer construct.. Care to take a stab? I seem to be doing that at the moment. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
SX model changes [WAS: Updated DDL for SQL backend]
On Fri, Oct 27, 2006 at 12:31:40PM -0400, Josh Sled wrote:
On Fri, 2006-10-27 at 12:04 -0400, Derek Atkins wrote:
Josh Sled [EMAIL PROTECTED] writes:
There's a deeper modeling issue with SXes. We use a seperate, parallel
AccountGroup to store template transaction data, in which Accounts are
named as the string representation of the SXes GUID, and contain
Transactions with Splits which have their *real* Accounts, as well as
the credit and debit cell text formulae, in KVP frames.
I know David was working to re-model the AccountGroup...
True, though as I recall by giving Accounts self-hierarchy (rather than
with the current object + container system). So long as that's true,
then the book can contain a reference to the SX Account object graph
along side the normal Account object graph.
Either way, it becomes more of an issue in the DB, though, since it'll
be easier to write an incorrect query like {select * from accounts where
type = 'asset'} that would pick up SX accounts that aren't really part
of the normal hierarchy. As well, modifying the query to be correct
is actually a PITA, as you'd want to walk the tree to make how it's
rooted (either as the SX tree or the normal tree), and dbs generally
don't play nicely with hierarchical relationships. :/
I don't have a good solution, at present ... just bringing it up.
Probably the right thing is for SXes to just suck it up and model
template transactions seperately from the real
accounts/transactions/splits, though there's some serious downsides
there, too.
I'd actually recommend going the other direction.
1) eliminate all SX virtual accounts.
2) Introduce a flag to Transaction: is_template?
3) Make SX transactions out of real Transactions (with
is_template=true), with real zero-valued Splits, belonging to the real
accounts, with scheduled values as strings in the Split's KVP.
4) Change xaccQueryGetTransactions() and
xaccSplitListGetUniqueTransactions() to ignore template transactions.
What do you think?
-chris
I don't see a reason to model this differently in the DB than in the
object model. Though we might want to change the object model.
Also, in the DDL, SXes still have an sx_id, though as QOF entities they
are GUID-posessing objects, and thus should follow the pattern of those.
How closely should the DB Schema map to the QOF object model?
I think pretty closely ... if only to make the Object/Relational mapping
problem as simple as possible. I've worked in situations where the
models have a high impedence mismatch, and it's just not fun. :(
In particular, here: I don't see a reason to have a seperate sx_splits
table with string credit/debit values when the QOF model is real splits
with the credit/debit formulas in a kvp frame.
--
...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
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: DB abstraction layer: libdbi vs libgda
On Fri, Oct 27, 2006 at 11:31:37AM -0400, Phil Longstaff wrote: I'm starting to take a look at the data abstraction layer to be used. The two candidates are libdbi and libgda. Here's what I have found so far: SQLite: latest stable version is 3.3.8 (Oct 9/06) MySQL: latest stable version is 5.0.24a PostgreSQL: latest stable version is 8.1.5 DB abstraction layer maintained? libgda: latest stable release 1.2.3 (Oct 31/05). They are preparing a 2.0 release (1.99.0 on the ftp site is dated Oct 18/06, 1.99.1 AKA 2.0Beta3 is dated Oct 26/06). Note that libgda *is* included in suse 10.0. Hmmm, why is the version 1.3.91? libdbi: latest release 0.8.1 (Nov 21/05). Not much except spam on the libdbi-devel mailing list for 2006. Some bugs were reported in Oct 2006 and one of the people listed as an admin on the SourceForge project page added a comment to the bug in Oct 2006. Note that libdbi is *not* included in suse 10.0 i.e. the software management tool doesn't find it. Support for SQLite 3? libgda: YES libdbi: NO (2.8.x) Support for MySQL 5.0.x? libgda: YES libdbi: ? Support for PostgreSQL 8.x? libgda: YES libdbi: ? For MySQL and PostgreSQL, I couldn't see what versions were supported by libdbi. The libgda web site (http://www.gnome-db.org/) does have a page with version info. Based on the maintenance and availability status, I think libgda is the clear choice. Since they are at beta3 already, the unstable branch would be better. Phil, Here are some more reasons why I'd prefer libgda over libdbi: 1) libgda has better integration with glib. E.g. uses GValue. I would eventually like to see further use of GValue in GnuCash. 2) gnomedb has gtk+ widgets that are build on top of libgda. These may not be immediately useful for more than things like a connection manager or login dialog, but down-the-line I could see them being useful as presentation widgets. Note that gda also supports XML databases, so that for an interchange format, we *could* use it instead. AFAIK, this isn't true anymore. But, I believe it could be made true again if we really wanted it to. -chris As another make-work project, gda could be used as an interface around ofx (or other format) input/output to provide a standardized API for data access. Phil ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: SX model changes [WAS: Updated DDL for SQL backend]
On Fri, Oct 27, 2006 at 01:02:52PM -0400, Derek Atkins wrote: Quoting Chris Shoemaker [EMAIL PROTECTED]: I don't have a good solution, at present ... just bringing it up. Probably the right thing is for SXes to just suck it up and model template transactions seperately from the real accounts/transactions/splits, though there's some serious downsides there, too. I'd actually recommend going the other direction. 1) eliminate all SX virtual accounts. 2) Introduce a flag to Transaction: is_template? 3) Make SX transactions out of real Transactions (with is_template=true), with real zero-valued Splits, belonging to the real accounts, with scheduled values as strings in the Split's KVP. 4) Change xaccQueryGetTransactions() and xaccSplitListGetUniqueTransactions() to ignore template transactions. What do you think? I prefer separating them. There are too many places where you could build an incorrect query and get template txns where you really want real ones, or vice-versa. All queries would ignore template transactions, except those that explicitly looked for them - just like it is now. Also, the reason for the account is that an SX could need to create multiple transactions at once. I'm not sure how you would do this in your approach where you eliminate these virtual accounts. A single SX can keep a list of transactions that are all scheduled at once. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Another SCM bug in trunk
On Fri, Oct 27, 2006 at 09:32:42PM -0400, Derek Atkins wrote: Hey, I was just trying the business reports and found two bugs in trunk. Bug #1: [Menu] - Reports - Business - Printable Invoice It comes up without an invoice, but the report thinks it's trying to print invoice #0 instead of printing a message saying that you need to choose an invoice. Is this new or old? I see that same behavior in trunk at 14992. Bug #2: I clicked on Options, chose an invoice, clicked Apply, and then I got this scheme backtrace. It looks like gnc:entry-get-order wasn't converted to the wrapping in swig. snip backtrace Well, I'd done: s/gnc:entry-get-Order/gncEntryGetOrder/g so, no, it wasn't converted. Fixed in 15059. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Re: unable to run r15045
On Fri, Oct 20, 2006 at 11:31:08AM -0500, [EMAIL PROTECTED] wrote: From: Chris Shoemaker [EMAIL PROTECTED] On Fri, Oct 20, 2006 at 09:36:11AM -0500, [EMAIL PROTECTED] wrote: On Fri, Oct 20, 2006 at 06:19:15AM -0500, Michael D. Wise wrote: On tryin to run r15045 I get the following error. snip In core-utils.scm, can you try changing all the exports to re-export? Also, is this guile 1.8? Guile version is guile-1.8.0-8.20060831cvs. It runs when I changed the exports to re-export. Ok, fixed in 15054. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Has guile version check changed?
On Sat, Oct 21, 2006 at 06:29:53PM -0400, Derek Atkins wrote: Actually, 'env' does export to children. That's the whole point of 'env'. man env for more info. Doh. Of course it does. However... $ env FOO=bar echo $FOO will _not_ show the bar, but for a totally different reason. The variable substitution will occur _before_ env is executed, so: % guile16-build env PATH=/opt/bin:$PATH echo $PATH is just a really dumb test. Looks like David figured things out in spite of my help, though. :) -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: price quotes crash
On Sat, Oct 21, 2006 at 07:20:56PM -0400, David Reiser wrote: in svn 15054, after clicking the Get Quotes button in the Price Editor, gnucash crashes. Terminal window says: snip backtrace Thanks, fixed in r15057. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GnuCash trunk now uses SWIG
On Fri, Oct 20, 2006 at 12:40:52AM -0400, David Reiser wrote: On Oct 20, 2006, at 12:17 AM, Derek Atkins wrote: There is no compilation ... Just a path. I suppose we could add a --with-swig-path switch, but why not just set $PATH accordingly? Um. Because I wasn't paying close enough attention? While I'm displaying my ignorance, how is it I keep the $PATH modification local to the build? I keep my gnucash svn builds out of my normal path so I have fewer conflicts in my attempts at making fink versions work. I tend to lose track of environment changes that work in one instance but interfere in another. I did build swig 1.3.29 in /opt last weekend, but I haven't built anything with it. Fink's latest swig is 1.3.20. All the tool paths are set by ./configure. If you want to run with another tool version (e.g. swig or gcc), you can just tweak the PATH before running ./configure. For example, $ PATH=/opt/gcc-5/bin:/opt/swig-1.3.30/bin ./configure --prefix=/opt/gnucash After that, the path to the tool is used in all the Makefiles, without any environment changes. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: unable to run r15045
On Fri, Oct 20, 2006 at 06:19:15AM -0500, Michael D. Wise wrote: On tryin to run r15045 I get the following error. Backtrace: In current input: 1: 0* [gnc:main] In /home/michael.wise/usr/local/gnucash//share/gnucash/guile-modules/gnucash/main.scm: 227: 1* [gnc:debug starting up (1).] 182: 2 (if (gnc-is-debugging) (begin # # #)) 182: 3* (gnc-is-debugging) /home/michael.wise/usr/local/gnucash//share/gnucash/guile-modules/gnucash/main.scm:182:7: In expression (gnc-is-debugging): /home/michael.wise/usr/local/gnucash//share/gnucash/guile-modules/gnucash/main.scm:182:7: Unbound variable: gnc-is-debugging I have compiled it on Fedora Development updated on 19 Oct using gcc-4.1.1-30 and swig-1.3.29-1.fc6. Let me know if you need any more information. Hmm. Are you sure there wasn't some error during compile or install? Does this still happen if you blow away the install directory and reinstall? Were there any other errors before this one? In particular, earlier in that file (main.scm) is: (use-modules (gnucash core-utils)) which is supposed to load the wrappers that provide gnc-is-debugging. Can you tell if that has failed? -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Re: unable to run r15045
On Fri, Oct 20, 2006 at 09:36:11AM -0500, [EMAIL PROTECTED] wrote: On Fri, Oct 20, 2006 at 06:19:15AM -0500, Michael D. Wise wrote: On tryin to run r15045 I get the following error. Backtrace: In current input: 1: 0* [gnc:main] In /home/michael.wise/usr/local/gnucash//share/gnucash/guile-modules/gnucash/main.scm: 227: 1* [gnc:debug starting up (1).] 182: 2 (if (gnc-is-debugging) (begin # # #)) 182: 3* (gnc-is-debugging) /home/michael.wise/usr/local/gnucash//share/gnucash/guile-modules/gnucash/main.scm:182:7: In expression (gnc-is-debugging): /home/michael.wise/usr/local/gnucash//share/gnucash/guile-modules/gnucash/main.scm:182:7: Unbound variable: gnc-is-debugging I have compiled it on Fedora Development updated on 19 Oct using gcc-4.1.1-30 and swig-1.3.29-1.fc6. Let me know if you need any more information. Hmm. Are you sure there wasn't some error during compile or install? Does this still happen if you blow away the install directory and reinstall? I didn't have any errors in the compile or install. I removed the install directory and I'm still having the same error Were there any other errors before this one? In particular, earlier in that file (main.scm) is: (use-modules (gnucash core-utils)) which is supposed to load the wrappers that provide gnc-is-debugging. Can you tell if that has failed? This is the only error I get when I run it from the console. In core-utils.scm, can you try changing all the exports to re-export? Also, is this guile 1.8? -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Opening saved account reports
On Thu, Oct 19, 2006 at 03:42:42PM -0400, Mike Alexander wrote: I'm in the process of getting things to work again after updating to the swig version of gnucash. It mostly seems to work, but I've noticed a few things. For example, when I opened a file that had an Account Report (or Account Transaction Report) window open when it was saved in the g-wrap version of gnucash I got the error: register.scm:564:17: In procedure gnc_query_scm2compare in expression (gnc-scm2query query-scm): register.scm:564:17: Wrong type argument in position 1: query-compare-equal Just to clarify, you got this in the console, but gnucash didn't crash, right? You probably got a this report had errors page, right? The code in register.scm gets the query from a parameter passed in to it by the C code. In this case the query it gets is (query-v2 (terms book guid) #f guid query-compare-equal guid-match-any (6320ae727a3710d93d3ca7b097c43157)) ((account guid) #f guid query-compare-equal guid-match-any (ab40d43d2091ea21672ec1ba2113b630) (search-for Split) (primary-sort ((QofQueryDefaultSort) 0 #t)) (secondary-sort #f) (tertiary-sort #f) (max-results -1)) If I run the report again after opening the file it gets a different query: (query-v2 (terms book guid) #f guid 3 1 (6320ae727a3710d93d3ca7b097c43157)) ((guid) #f guid 3 1 (4055379c49a2142af5dc7ef59bd1ce49) (search-for Split) (primary-sort ((QofQueryDefaultSort) 0 #t)) (secondary-sort #f) (tertiary-sort #f) (max-results -1)) It looks like the symbols query-compare-equal and guid-match-any have been turned into numeric parameters in the new query. (The GUIDs changed since I probably selected a different account.) I don't know whether the bug is in the processing of the query or the generation of the query. Yeah, the swig wrappers wrap enums as numbers, while the g-wrap wrappers wrapped them as symbols. For that reason, and probably many more, in theory, saved reports from 2.0 (g-wrap) may be unreadable in 2.2. In practice, I think most reports will work fine, but saved queries won't. -chris This isn't a big deal since it only seem to affect documents with saved reports, but it might be a symptom of a wider problem (or it might be something I'm doing wrong). -- Mike Alexander [EMAIL PROTECTED] Ann Arbor, MIPGP key ID: BEA343A6 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
GnuCash trunk now uses SWIG
Hi, In case you missed recent list traffic, this is just to announce that, yes, GnuCash has switched from g-wrap to SWIG (http://swig.sf.net since http://www.swig.org is currently down.) SWIG is the program that generates wrappers for C functions that can be called from guile. The conversion was merged into trunk a few days ago, on the 15th. So, what does this mean for those of you following trunk? Well, for one, you should be on the look-out for bugs, as always. There have already been a couple wrapper-related bugs squashed. A typical wrapper-related bug would be an unbound-variable error while exercising some functionality that's implemented in guile. Chiefly, that's reports, and import-export, and import-export is especially under-tested. (But any bugs are possible.) If you're compiling trunk, you're going to need to install swig = 1.3.28. Makefile rules are enabled that will generate the needed wrappers from the .i interface files. However, they won't be removed by make clean. If you need to remove them for some reason, you'll need the more drastic make maintainer-clean. It's also possible that left-over g-wrap cruft in your working directory may interfere with the build process somehow. Anything g-wrap can safely be deleted. Also, you may get some errors when reloading reports that were saved with pre-swig versions. Reopening those reports should work. Early heads up: there are currently some bug fixes in swig's cvs for bugs that we're working around now. When those fixes appear in a released version, I hope to depend on them relatively quickly, (maybe 1 month after release?) Please speak up if this is problematic. BTW, swig is a _breeze_ to install from source, and there's no library to link to at all. (./configure make make install) Note to packagers: Don't worry, this is all good news for you. SWIG is only a build-time dependency for people building from trunk. There is no new runtime dependency and no new build-time dependency for building from tarball (whenever a 2.2 is eventually released.) And... all the g-wrap dependencies are gone. Note to (potential) developers: Hey, if somebody wants to push a little more reporting infrastructure (options, basically) from guile into C, we could conceivably write reports in some other scripting language. As a perk, you'd get to pick the language! :-) Have fun! -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Transaction and register reports don't work in swig version
On Thu, Oct 19, 2006 at 05:50:52PM -0400, Mike Alexander wrote: I found a couple more errors in the swig versions of the transaction and register reports. The patches below make them work better. I'm not suggesting that this is the correct fix, but rather I'm sending this to document the problems. Probably because of the order of the renames in the sed script (is that script available, by the way?) It's in the commit message for each commit in which it was applied. I figured it was worth recording but not worth committing. gnc:query-get-splits-unique-trans was renamed to qof-query-run-unique-trans and it seems to be called xaccQueryGetSplitsUniqueTrans now. Also gnc:split-corr-account-fullname was renamed to SPLIT-CORR-ACCT-FULLNAME and it looks like it should be SPLIT-CORR-ACCT-NAME. Yup and yup. These are both trivial, but a more interesting problem is that xaccTransGetSplit returns '() instead of #f when the index is greater than the number of splits in the transaction. This broke both transaction.scm and register.scm. I presume the better fix is to change xaccTransGetSplit to return #f in this case, but I'm not sure how to do that so I patched the caller to work with either. Any time a wrapped C function returns NULL, the guile value should now be checked with (null? ...). This also needed to be changed in engine/engine-interface.scm. Thanks, Mike, committed in 15046. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Opening saved account reports
On Thu, Oct 19, 2006 at 05:42:22PM -0400, Derek Atkins wrote: Quoting Chris Shoemaker [EMAIL PROTECTED]: It looks like the symbols query-compare-equal and guid-match-any have been turned into numeric parameters in the new query. (The GUIDs changed since I probably selected a different account.) I don't know whether the bug is in the processing of the query or the generation of the query. Yeah, the swig wrappers wrap enums as numbers, while the g-wrap wrappers wrapped them as symbols. For that reason, and probably many more, in theory, saved reports from 2.0 (g-wrap) may be unreadable in 2.2. In practice, I think most reports will work fine, but saved queries won't. This isn't a good idea.. It means that anytime you change the values in an enum ALL your saved state goes bad!! What's the point of using an enum if it's not stable? Is there any way we can fix this -- at least in certain places where we stringify the enums? There are two issues here: One is that pre-swig saved state is incompatible with new swig wrappers. E.g. the old file had query-compare-equal while the swig-wrapped constant is QOF-COMPARE-EQUAL. I don't think this is worth solving. The other issue is some saved state is now stringified with the numeric constant values instead of their names. IIRC, the way this worked before was that C code in engine-helpers.c would dynamically construct strings that would form the names of g-wrap generated mapping functions. Then, the string could be evaluated using scm_c_eval_string() and turned into a procedure which could then be called using libguile, passing the value of the constant. The g-wrap generated mapping function would return a symbol corresponding to the value of the constant. From there, I think the symbols were later automatically stringified by guile's (write ...) function. AFAIK, this technique was only used for query attributes, and only those that are enums, and not even all of _those_. Even with the old g-wrap code, we were saving numeric values for some query attribute enums like KvpValueType. (BTW, this code had been rotting since the linas days, c.f. gnc_scm2KvpValueTypeype (sic) which used to be called gnc_scm2kvp_value_type). I'm sure there's some smart, maintainable way to completely serialize the query while de-coupling it from the C enum definitions, but the old g-wrap solution was incomplete and a huge mess. Now it's simply gone. :) Maybe one solution is to change the guile representation of the query to just use symbols internally, and then provide our own mapping from enums to symbols, and vice versa. We already have 2k LOC (just in C) dedicated to serializing and unserializing the query. What's a few hundred more, right? :( -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Error in advanced portfolio report after swigification
On Wed, Oct 18, 2006 at 10:56:59PM +0200, Sigve Indregard wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 With the current HEAD I get the following error when trying to view the Advanced Portfolio. I got an error at compile-time related to xaccTransGetSplitsGL, but I fixed that through make uninstall before I make'd. I also struggled to install because the intl-scm/ Makefile tried to get all *.scm files, including those in g-wrapped/ directories. After deleting those directories, installation went smoothly. But the report does not work. I'm on Ubuntu Dapper Drake with swig 1.3.29 installed from source. snip backtrace Thanks for testing trunk, and thanks for reporting. Fixed in r15042. -chris - -- Sigve Indregard Student, Oslo ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Swig-user] enum constants vs. functions returning an enum value
On Sat, Aug 19, 2006 at 06:57:00PM -0500, John Lenz wrote: snip Ok, I just committed it to CVS. I added the feature as constasvar, and it works on all constants (including enums). You can apply it globally by adding %feature(constasvar, 1); or by using -features constasvar on the command line, or applying the feature to individual constants or enums (see the docs on how to do that... in CVS, I updated Guile.html with a paragraph about constasvar) snip So, it would be nice if you tested out the constasvar feature before we make a release. Hi John, I've tested this feature in the version from CVS. It works just as I expected. Thanks. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Patch to partially add recursion to budgets
On Tue, Oct 10, 2006 at 08:43:35AM -0500, Gregory Alexander wrote: Alright, I got the patch updated. I like the idea of using the unset value. I was just unfarmiliar with the value structure holding code. Ok, I've committed this to trunk as 15009, with some slight tweaks. I will note that there will be minor migration problems from old versions, since values that are currently 0 will display as 0, and values that are currently unset will display as blank. This shouldn't really break anyone, but it might be a little confusing. I don't think that's a huge deal. It's not incorrect behavior, just inconvenient. On 10/3/06, Chris Shoemaker [EMAIL PROTECTED] wrote: On Mon, Oct 02, 2006 at 08:26:07PM -0500, Gregory Alexander wrote: If the error value was the only way to convey unset I could see adding a code for it, but I'm thinking it's better to handle it at the budget-level. E.g. ... and then just unset the value if an error code is passed to gnc_budget_set_account_period_value(): Not that simple, because error values are not the same as blank values. I still handle errors as errors, but also will display unset as unset. I'm not sure the api should actually store gnc_numerics with errors, so I don't know if the difference is that important, but I basically left this as you had it. User interface changes: 1.) Budget values of 0/1 are now displayed when editing as $0.00 (as appropriate) instead of being left blank. okay, good. Now, zero is a legit budget value. 2.) If the user removes all text when editing a budget value entry, it will be initialized to GNC_ERROR_UNSET. With code above, any error code will do, and will actually _unset_ the value. Agreed. That code works better. 3.) GNC_ERROR_UNSET is displayed when editing as a blank budget value. ?? It should be just blank, right? Isn't that what I said? Sorry, I didn't parse it. 4.) cleanup/debug: Other errors display as error when editing. That's a good idea. I preserved this behavior, while implementing using a NULL budget value. 5.) In the existing budget report, entries with a value of GNC_ERROR_UNSET display as . instead of a currency value. Other errors continue to display as a single $ (as appropriate.) I'd prefer that the report display and editor display were more similar, like just and error, but I might change my mind if I actually saw it. The problem is that as the tables get larger, and larger portions are blank, it gets hard to track the columns, especially since we use boxless tables. Hmm, it looks ok, so I'll leave it as .. What I haven't been able to figure out is how to have new budget entries default to GNC_ERROR_UNSET instead of 0. I think changing the default to GNC_ERROR_UNSET would be the correct behavior, although again, this is open to discussion. Well, I think the default should be unset as per above, and I think it's just automatic. Nothing's there until it's set. Yup, works great. However, this is what introduces the weird upgrade behavior. Thanks for the patch! -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Budget report improvements
Hi Steven, Sorry for the late reply, I'm just getting back to stuff like this now. Thanks for the patch. That's pretty impressive for not having programmed in guil or lisp before - you must be a natural. I have some comments below. On Sat, Sep 09, 2006 at 11:51:58AM +0800, Steven Wilton wrote: I like the budget feature in gnucash 2.0, but there were a few features that I felt were missing in the report. Unfortunately I've not programmed in guile or lisp before, but I gave it a shot, and thought I'd send the work I'd done to this list in case anyone else thinks the features are useful. The patch does 3 things: 1 - It adds the sub-accounts in the budget columns to give a total. I did this because the actual columns already contained the total of all sub-accounts. I don't think that's generally correct behavior. What if not all sub-accounts are budgeted for? If a user wants to budget at the level of the parent account, they can enter a budget value for the parent account. This may or may not be the sum of budgeted children (if there even are any). 2 - It adds an option to make the budget and actual amounts cumulative. Interesting. I'm ambivalent about this behavior. On the one hand, I understand why it is useful to see this information. You're basically viewing actual and budgeted account _balances_. I'd like to see this information be easily available. On the other hand, this means reporting budget values that are _accumulation_ of the specified values, instead of identical to the specified values. Also, there are clearly uses when seeing the accumulated values is definitely not what you want. (But, yes, it's optional.) I'm going to think about this some more, but in any case, if we want this optional behavior, there are easier ways to get account balances - and it could probably use some assistance from the C-side of budgets. 3 - It allows the user to select a single budget period to show data for. That's clearly useful. Maybe a range of periods? 4 - It reduces the displayed accounts to income and expense only (not a core feature, but it was the only way I could see to easily remove all the asset and liability accounts from the report) You just changed the default. There's a full account selector in the options. But, I like that as default setting. 5 - It makes the default display depth 3, once again not a core feature. There are a few bugs that I'm aware of: 1 - For some reason the code that adds the sub-totals for the budget columns sometimes ends up with a blank entry. I have no idea why this is ocurring, as there is no pattern that I can see. 2 - The report takes a very long time to run. I've probably done something wrong int he code to make it run slowly. 3 - The number of periods that are displayed in the options menu is hard-coded to 12. This value should really be obtined from the number of periods in the budget. That's _really_ tricky to do right. It's the sort of thing I'd try to figure out how to avoid altogether. :) I hope the work I've done is useful. Thanks for sharing the patch. I'll see if I can commit some of these improvements some time in the future. -chris regards Steven ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: eek, disaster bug!
Thomas, et al., Thanks for the error reports. This bug has been #1 on my hit-list for a while, but I hadn't been able to reproduce it. It turns out that the unable to delete split behavior was a big clue, and something I could finally reproduce. I'm hoping that these bug(s) have been fixed by r15002 and r15004. -chris On Tue, Oct 10, 2006 at 10:20:35AM -0700, Andrew Sackville-West wrote: On Tue, Oct 10, 2006 at 04:35:27PM +0200, Herbert Thoma wrote: I can confirm this bug :-( And I got a crash when entering a new transaction, too. I did not get a blank split line at the end of the transaction in the auto-split mode. When I tried to enter the transaction by hitting return I got a crash and this error message in the shell: ** ERROR **: file split-register-load.c: line 248 (gnc_split_register_load): assertion failed: (pending_trans == NULL) aborting... same message as http://bugzilla.gnome.org/show_bug.cgi?id=348469 are they related? A ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
SWIGification status, Part 2
Devs and Testers, The swig-redo branch has a swigified GnuCash. I've smoke-tested it, but it needs some more exercise. Several steps in the process were pretty manual and error-prone. Fortunately, the type of bugs I'm most likely to have introduced are very easy to fix. The whole process went pretty smoothly except for one horrendous bug that killed many, many hours. (Giving guile a NULL when it expects an SCM_UNDEFINED will eventually bite you, perhaps sometime in the distant future and in the bowels of the garbage collector.) I'm even more impressed with SWIG's flexibility than I previously was, and I've continued to receive good support from swig-user. I expect there are some gwrap-specific tests that still have to be disabled, and probably some dist-check related errors, but otherwise, it's ready to be stress-tested. I hope it will get some review/comments in the swig-redo branch, but I hope it can be merged to trunk for wider testing soon. If you notice any regressions from trunk please send them here. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: repeated crashes in 2.0.1-3 deb unstable
On Tue, Oct 03, 2006 at 03:08:04PM -0700, Andrew Sackville-West wrote: I keep getting this: gnucash: [M] Found Finance::Quote version 1.11 ** ERROR **: file split-register-load.c: line 248 (gnc_split_register_load): assertion failed: (pending_trans == NULL) aborting... BTW, I think this is related to: http://bugzilla.gnome.org/show_bug.cgi?id=348469 Please include helpful info there. -chris in the terminal when doing entry in gnucash 2.0.1-3 debian unstable. this happens when I'm tabbing from one field to the next while entering transactions in the check register. The first time it happened when tabbing from the check number field to the description. This time it was from description to whatever comes up next. this is the latest gnucash in debian, r14585 according to the gnucash spash. A here is the backtrace: (gdb) bt #0 0xe410 in __kernel_vsyscall () #1 0xa6dcf713 in __waitpid_nocancel () from /lib/tls/i686/cmov/libpthread.so.0 #2 0xa7c4d655 in gnome_gtk_module_info_get () from /usr/lib/libgnomeui-2.so.0 #3 signal handler called #4 0xe410 in __kernel_vsyscall () #5 0xa6bb3821 in raise () from /lib/tls/i686/cmov/libc.so.6 #6 0xa6bb4fb9 in abort () from /lib/tls/i686/cmov/libc.so.6 #7 0xa6d29114 in g_logv () from /usr/lib/libglib-2.0.so.0 #8 0xa6d29149 in g_log () from /usr/lib/libglib-2.0.so.0 #9 0xa6d291c7 in g_assert_warning () from /usr/lib/libglib-2.0.so.0 #10 0xa7ea80b8 in gnc_split_register_load () from /usr/lib/gnucash/gnucash/libgncmod-ledger-core.so.0 #11 0xa7e9ce87 in gnc_ledger_display_find_by_query () from /usr/lib/gnucash/gnucash/libgncmod-ledger-core.so.0 #12 0xa7e9ced8 in gnc_ledger_display_refresh () from /usr/lib/gnucash/gnucash/libgncmod-ledger-core.so.0 #13 0xa7e9cf2d in gnc_ledger_display_refresh_by_split_register () from /usr/lib/gnucash/gnucash/libgncmod-ledger-core.so.0 #14 0xa7e9eca6 in gnc_split_register_redraw () from /usr/lib/gnucash/gnucash/libgncmod-ledger-core.so.0 #15 0xa7ea2a3d in gnc_split_register_set_read_only () from /usr/lib/gnucash/gnucash/libgncmod-ledger-core.so.0 #16 0xa7e67bec in gnc_table_set_virt_cell_cursor () ---Type return to continue, or q return to quit--- from /usr/lib/gnucash/gnucash/libgncmod-register-core.so.0 #17 0xa7e67fe4 in gnc_table_move_cursor_gui () from /usr/lib/gnucash/gnucash/libgncmod-register-core.so.0 #18 0xa7e68097 in gnc_table_verify_cursor_position () from /usr/lib/gnucash/gnucash/libgncmod-register-core.so.0 #19 0xa7e682b2 in gnc_table_wrap_verify_cursor_position () from /usr/lib/gnucash/gnucash/libgncmod-register-core.so.0 #20 0xa7e85092 in gnucash_sheet_cursor_set_from_table () from /usr/lib/gnucash/gnucash/libgncmod-register-gnome.so.0 #21 0xa7e89261 in gnucash_register_refresh_from_gconf () from /usr/lib/gnucash/gnucash/libgncmod-register-gnome.so.0 #22 0xa7351110 in _gtk_marshal_BOOLEAN__BOXED () from /usr/lib/libgtk-x11-2.0.so.0 #23 0xa6d91fe9 in g_value_set_boxed () from /usr/lib/libgobject-2.0.so.0 #24 0xa6d93b1c in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #25 0xa6da460f in g_signal_chain_from_overridden () from /usr/lib/libgobject-2.0.so.0 #26 0xa6da52a8 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #27 0xa6da5679 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #28 0xa743acc4 in gtk_widget_get_default_style () from /usr/lib/libgtk-x11-2.0.so.0 #29 0xa744a0c6 in gtk_window_propagate_key_event () from /usr/lib/libgtk-x11-2.0.so.0 ---Type return to continue, or q return to quit--- #30 0xa744cf1c in gtk_window_activate_key () from /usr/lib/libgtk-x11-2.0.so.0 #31 0xa7351110 in _gtk_marshal_BOOLEAN__BOXED () from /usr/lib/libgtk-x11-2.0.so.0 #32 0xa6d91fe9 in g_value_set_boxed () from /usr/lib/libgobject-2.0.so.0 #33 0xa6d93a2b in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #34 0xa6da460f in g_signal_chain_from_overridden () from /usr/lib/libgobject-2.0.so.0 #35 0xa6da52a8 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #36 0xa6da5679 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #37 0xa743acc4 in gtk_widget_get_default_style () from /usr/lib/libgtk-x11-2.0.so.0 #38 0xa734aaca in gtk_propagate_event () from /usr/lib/libgtk-x11-2.0.so.0 #39 0xa734bcc7 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0 #40 0xa71e4e3a in _gdk_events_init () from /usr/lib/libgdk-x11-2.0.so.0 #41 0xa6d207b1 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #42 0xa6d23826 in g_main_context_check () from /usr/lib/libglib-2.0.so.0 #43 0xa6d23be7 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #44 0xa734c141 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #45 0xa7dd873b in gnc_ui_start_event_loop () from /usr/lib/gnucash/gnucash/libgncmod-gnome-utils.so.0 #46 0x0804a505 in _start () (gdb) ___ gnucash-devel
Re: repeated crashes in 2.0.1-3 deb unstable
On Tue, Oct 03, 2006 at 03:08:04PM -0700, Andrew Sackville-West wrote: I keep getting this: gnucash: [M] Found Finance::Quote version 1.11 ** ERROR **: file split-register-load.c: line 248 (gnc_split_register_load): assertion failed: (pending_trans == NULL) aborting... in the terminal when doing entry in gnucash 2.0.1-3 debian unstable. this happens when I'm tabbing from one field to the next while entering transactions in the check register. The first time it happened when tabbing from the check number field to the description. This time it was from description to whatever comes up next. this is the latest gnucash in debian, r14585 according to the gnucash spash. *grrr* :( This bug is haunting me. I really have no idea how this can happen. As far as I remember, this code is only executed when opening the register or when navigating off of the blank transaction, when there is no blank split yet. The failed assertion means that there was already a transaction being edited when we go to add a blank split. I _think_ this implies there's a bug somewhere else. It would be very helpful if you can give detailed instructions for reproducing this. In any case, can you answer these questions: How many registers were open? What type of register was this? Regular? General Ledger? Which edit mode? Basic? Auto-Split? Journal? If in Basic mode, were the splits visible? What was the value of the enter moves to blank transaction preference? Was double-line mode in use? Had you used import functionality during the session that crashed? When tabbing from the description, was a memorized transaction being recalled? In general, did you do anything unusual with registers sometime before the crash? (not necessarily immediately) -chris A here is the backtrace: (gdb) bt #0 0xe410 in __kernel_vsyscall () #1 0xa6dcf713 in __waitpid_nocancel () from /lib/tls/i686/cmov/libpthread.so.0 #2 0xa7c4d655 in gnome_gtk_module_info_get () from /usr/lib/libgnomeui-2.so.0 #3 signal handler called #4 0xe410 in __kernel_vsyscall () #5 0xa6bb3821 in raise () from /lib/tls/i686/cmov/libc.so.6 #6 0xa6bb4fb9 in abort () from /lib/tls/i686/cmov/libc.so.6 #7 0xa6d29114 in g_logv () from /usr/lib/libglib-2.0.so.0 #8 0xa6d29149 in g_log () from /usr/lib/libglib-2.0.so.0 #9 0xa6d291c7 in g_assert_warning () from /usr/lib/libglib-2.0.so.0 #10 0xa7ea80b8 in gnc_split_register_load () from /usr/lib/gnucash/gnucash/libgncmod-ledger-core.so.0 #11 0xa7e9ce87 in gnc_ledger_display_find_by_query () from /usr/lib/gnucash/gnucash/libgncmod-ledger-core.so.0 #12 0xa7e9ced8 in gnc_ledger_display_refresh () from /usr/lib/gnucash/gnucash/libgncmod-ledger-core.so.0 #13 0xa7e9cf2d in gnc_ledger_display_refresh_by_split_register () from /usr/lib/gnucash/gnucash/libgncmod-ledger-core.so.0 #14 0xa7e9eca6 in gnc_split_register_redraw () from /usr/lib/gnucash/gnucash/libgncmod-ledger-core.so.0 #15 0xa7ea2a3d in gnc_split_register_set_read_only () from /usr/lib/gnucash/gnucash/libgncmod-ledger-core.so.0 #16 0xa7e67bec in gnc_table_set_virt_cell_cursor () ---Type return to continue, or q return to quit--- from /usr/lib/gnucash/gnucash/libgncmod-register-core.so.0 #17 0xa7e67fe4 in gnc_table_move_cursor_gui () from /usr/lib/gnucash/gnucash/libgncmod-register-core.so.0 #18 0xa7e68097 in gnc_table_verify_cursor_position () from /usr/lib/gnucash/gnucash/libgncmod-register-core.so.0 #19 0xa7e682b2 in gnc_table_wrap_verify_cursor_position () from /usr/lib/gnucash/gnucash/libgncmod-register-core.so.0 #20 0xa7e85092 in gnucash_sheet_cursor_set_from_table () from /usr/lib/gnucash/gnucash/libgncmod-register-gnome.so.0 #21 0xa7e89261 in gnucash_register_refresh_from_gconf () from /usr/lib/gnucash/gnucash/libgncmod-register-gnome.so.0 #22 0xa7351110 in _gtk_marshal_BOOLEAN__BOXED () from /usr/lib/libgtk-x11-2.0.so.0 #23 0xa6d91fe9 in g_value_set_boxed () from /usr/lib/libgobject-2.0.so.0 #24 0xa6d93b1c in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #25 0xa6da460f in g_signal_chain_from_overridden () from /usr/lib/libgobject-2.0.so.0 #26 0xa6da52a8 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #27 0xa6da5679 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #28 0xa743acc4 in gtk_widget_get_default_style () from /usr/lib/libgtk-x11-2.0.so.0 #29 0xa744a0c6 in gtk_window_propagate_key_event () from /usr/lib/libgtk-x11-2.0.so.0 ---Type return to continue, or q return to quit--- #30 0xa744cf1c in gtk_window_activate_key () from /usr/lib/libgtk-x11-2.0.so.0 #31 0xa7351110 in _gtk_marshal_BOOLEAN__BOXED () from /usr/lib/libgtk-x11-2.0.so.0 #32 0xa6d91fe9 in g_value_set_boxed () from /usr/lib/libgobject-2.0.so.0 #33 0xa6d93a2b in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #34 0xa6da460f in g_signal_chain_from_overridden () from /usr/lib/libgobject-2.0.so.0 #35
Re: r14927 - gnucash/trunk/src/gnome-utils/glade - Fix for bug #359471. Remove the glade hookup of gnc_xfer_dialog_close_cb() to
On Tue, Oct 03, 2006 at 10:30:33PM -0400, Chris Shoemaker wrote: Author: chris Date: 2006-10-03 22:30:32 -0400 (Tue, 03 Oct 2006) New Revision: 14927 Trac: http://svn.gnucash.org/trac/changeset/14927 Modified: gnucash/trunk/src/gnome-utils/glade/transfer.glade Log: Fix for bug #359471. Remove the glade hookup of gnc_xfer_dialog_close_cb() to the close signal. This callback doesn't handle aborting correctly when called directly, but it will behave correctly when called indirectly from close_handler(). The response callback will now be called for all actions that close the dialog. I forgot to mark that for backport (I'm out of practice!) but it's a good candidate. Please audit. -chris Modified: gnucash/trunk/src/gnome-utils/glade/transfer.glade === --- gnucash/trunk/src/gnome-utils/glade/transfer.glade2006-10-03 21:13:13 UTC (rev 14926) +++ gnucash/trunk/src/gnome-utils/glade/transfer.glade2006-10-04 02:30:32 UTC (rev 14927) @@ -19,7 +19,6 @@ property name=gravityGDK_GRAVITY_NORTH_WEST/property property name=has_separatorFalse/property signal name=response handler=gnc_xfer_dialog_response_cb last_modification_time=Sun, 27 Jul 2003 17:44:58 GMT/ - signal name=close handler=gnc_xfer_dialog_close_cb last_modification_time=Sun, 27 Jul 2003 17:45:10 GMT/ child internal-child=vbox widget class=GtkVBox id=vbox ___ gnucash-changes mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-changes ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Patch to partially add recursion to budgets
On Mon, Oct 02, 2006 at 08:26:07PM -0500, Gregory Alexander wrote:
Alright, I have a patch.
This may start a flame, but I added a new GNC_ERROR_UNSET error code.
I added this because none of the existing errors was really
appropriate for a value that simply wasn't set yet. I'm open to other
names like GNC_ERROR_UNINITIALIZED, and would reluctantly change it to
GNC_ERROR_ARG if there are strong objections to adding a new error
code. I already caught one place where the number of errors was
hard-coded, so I replaced that with a new GNC_ERROR_MIN value.
If the error value was the only way to convey unset I could see
adding a code for it, but I'm thinking it's better to handle it
at the budget-level. E.g.
gboolean
gnc_budget_is_account_period_value_set(GncBudget *budget, Account *account,
guint period_num)
{
const GUID *guid;
KvpFrame *frame;
gchar path[BUF_SIZE];
gchar *bufend;
frame = qof_instance_get_slots(QOF_INSTANCE(budget));
guid = xaccAccountGetGUID(account);
bufend = guid_to_string_buff(guid, path);
g_sprintf(bufend, /%d, period_num);
return (kvp_frame_get_value(frame, path) != NULL)
}
and then just unset the value if an error code is passed to
gnc_budget_set_account_period_value():
@@ -234,7 +251,10 @@
bufend = guid_to_string_buff(guid, path);
g_sprintf(bufend, /%d, period_num);
-kvp_frame_set_numeric(frame, path, val);
+if (gnc_numeric_check(val))
+kvp_frame_set_value(frame, path, NULL);
+else
+kvp_frame_set_numeric(frame, path, val);
qof_instance_set_dirty(budget-inst);
gnc_budget_commit_edit(budget);
In that case, adding an error code isn't really needed.
User interface changes:
1.) Budget values of 0/1 are now displayed when editing as $0.00 (as
appropriate) instead of being left blank.
okay, good. Now, zero is a legit budget value.
2.) If the user removes all text when editing a budget value entry, it
will be initialized to GNC_ERROR_UNSET.
With code above, any error code will do, and will actually _unset_ the value.
3.) GNC_ERROR_UNSET is displayed when editing as a blank budget value.
?? It should be just blank, right?
4.) cleanup/debug: Other errors display as error when editing.
That's a good idea.
5.) In the existing budget report, entries with a value of
GNC_ERROR_UNSET display as . instead of a currency value. Other
errors continue to display as a single $ (as appropriate.)
I'd prefer that the report display and editor display were more
similar, like just and error, but I might change my mind if I
actually saw it.
What I haven't been able to figure out is how to have new budget
entries default to GNC_ERROR_UNSET instead of 0. I think changing the
default to GNC_ERROR_UNSET would be the correct behavior, although
again, this is open to discussion.
Well, I think the default should be unset as per above, and I think
it's just automatic. Nothing's there until it's set.
Comments, concerns?
Thanks!
What do you think?
BTW, I'm also working on a fancier budget report, but it isn't
currently in a state appropriate for public consumption (read: I
naively reimplemented gnc:numeric-add, among other ugly things.) I'll
submit that in a separate patch once I get it cleaned up.
Looking forward to it.
Replies below here, but mostly just agreeing with what you said.
On 9/28/06, Chris Shoemaker [EMAIL PROTECTED] wrote:
On Thu, Sep 28, 2006 at 02:30:16AM -0500, Gregory Alexander wrote:
Now, let's assume the user doesn't actually care about the Non-Bills
category. It's just a placeholder (I can come up with some better
reasons
for this, but I want to keep using the same account structure.)
...
The user would probably prefer to have one of the following happen.
Option 1 (what I suggested earlier): fill in from the bottom-up. This
gives
I'm not so sure this is generally good behavior. Imagine that the
user only cares to budget for _some_ of the children accounts, and not
the parent. In that case, using the sum of the budgeted children as
the parent's budgeted value isn't correct.
I'm not convinced by your budget for _some_ argument, since they will
be counted in the actual total for that category. However, since the
overall budget for the parent may be different from the sum of the
children, I agree that automatically summing isn't a very good general
practice.
Yes, that's all I meant.
-chris
Since there isn't a clean or easy way to add this as an
option to the interface, I agree that the correct behavior is to not
implement summing.
Option 2: Mark entry as unbudgeted.
Hmm. I expected that the normal usage of the budget report would be
to only include the accounts that you budgeted for. But, I can
imagine some cases where it might be interesting to see the accounts
you budgeted for alongside the accounts you didn't, in the same
report
Re: Patch to partially add recursion to budgets
On Thu, Sep 28, 2006 at 02:30:16AM -0500, Gregory Alexander wrote: I apologize for the rich-text formatting, I needed it to get the mock-ups to look right. Hmmm, thanks for pointing me at that file. Now I understand the design philosophy behind what I thought was a functional bug. I think the reason I found it counter-intuitive is that this is different from how the rest of gnucash works, where account either stand on their own or are the sum of their sub-accounts. I think it will help to work backwards from the report I want to generate to determine what the correct behavior is. I want to generate a budget report that looks something like this: Budget entered by user: Expenses500 Bills 200 Non-Bills 300 Food100 Entertainment 50 Car 150 Misc. 0 Account:Budget: Actual: Remain: Percent remain: Expenses500 250 250 50% Bills 200 100 100 50% Non-Bills 300 150 150 50% Food100 50 50 50% Entertainment 50 60 (10) (20%) Car 150 0 150 0% Misc. 0 40 (40) * Right now, the user has to manually enter the budget values for each line, including the Non-Bills and Expenses parent categories. That's a lot of work for the user, but if they really want to track at all those granularity levels, it's probably worth it, espescially if they want a slush fund, or they've over child-budgeted at any parent level. Yes, the user must enter a budget value for each account they want to compare. Also keep in mind that there are cases where the user wants the budgeted value for the parent to be different than the sum of the budgeted values for children. Now, let's assume the user doesn't actually care about the Non-Bills category. It's just a placeholder (I can come up with some better reasons for this, but I want to keep using the same account structure.) Here's what happens if the user just doesn't fill in that category in the budget: Budget entered by user: Expenses500 Bills 200 Non-Bills 0 Food100 Entertainment 50 Car 150 Misc. 0 Account:Budget: Actual: Remain: Percent remain: Expenses500 250 250 50% Bills 200 100 100 50% Non-Bills 0 150 (150)* Food100 50 50 50% Entertainment 50 60 (10) (20%) Car 150 0 150 0% Misc. 0 40 (40) * Now the user has an ugly negative 150 in the remain column under non-bills. Just looking at the zero in Budget doesn't work, because there was a legitimate 0-budget column that had unexpected expenses. The user would probably prefer to have one of the following happen. Option 1 (what I suggested earlier): fill in from the bottom-up. This gives the user extra data for free, but clutters up the chart with data they don't care about. Budget entered by user: Expenses500 Bills 200 Non-Bills 0 (Sum children) Food100 Entertainment 50 Car 150 Misc. 0 Account:Budget: Actual: Remain: Percent remain: Expenses500 250 250 50% Bills 200 100 100 50% Non-Bills 300 150 150 50% Food100 50 50 50% Entertainment 50 60 (10) (20%) Car 150 0 150 0% Misc. 0 40 (40) * I'm not so sure this is generally good behavior. Imagine that the user only cares to budget for _some_ of the children accounts, and not the parent. In that case, using the sum of the budgeted children as the parent's budgeted value isn't correct. Option 2: Mark entry as unbudgeted. Budget entered by user: Expenses500 Bills 200 Non-Bills 0 (Unbudgeted) Food100 Entertainment 50 Car 150 Misc. 0 Account:Budget: Actual: Remain: Percent remain: Expenses500 250 250 50% Bills 200 100 100 50% Non-Bills . 150 .. Food100 50 50 50% Entertainment 50 60 (10) (20%) Car 150 0 150 0% Misc. 0 40 (40) * I think option 2 is actually a better option, though it is interesting that it's nowhere near where I expected to end up. Hmm. I expected that the normal usage of the budget report would be to only include the accounts that you budgeted for. But, I can imagine some
Re: Patch to partially add recursion to budgets
On Wed, Sep 27, 2006 at 12:59:34AM -0500, Gregory Alexander wrote: Budgets are almost what I need to get gnucash to do what I want. I'm having a problem in that budget behavior is inconsistently recursive over accounts. I have a bug open on that. Honestly, I read that bug once, and didn't immediately understand it, and figured I would just wait until I had more time to look more closely at it. However, in light of this patch, I'm thinking that what you describe is probably not so much a bug as a difference of expectations. See below... Attached is a patch that starts along the path of making recursion optional for budget calls, but stops short of propogating the change all the way up to the report interface. Would people please comment if I'm on the right track? I modeled the recursive behavior off Accounts.c Ok, this is certainly one direction to go. You might be able to gather from the design notes at the top of gnc-budget.h why I didn't go this way. Just to clarify the implications of this approach: At the end of the day, you need two sets of comparable numbers, actuals and budgeted. To be comparable, they need to be either both recursive or both not. Currently, GnuCash only supports both recursive. However, that _doesn't_ mean that budgeted values are summed from children accounts' budgeted values. (That would quickly become very complicated in multi-currency situations.) Instead, the user specifies the summary budgeted value, i.e. recursive. (To verify this, try out the bugdet estimator tool.) In this implementation you don't have the ability to budget for transactions that post to a parent account while excluding transactions that post to the account's children. I think this is an uncommon need. So, what would happen if GnuCash supported both not recursive? For one, you now have to specify budget values for the actual accounts that transactions are posted to. You lose the ability to choose a parent account, and to budget at a level of detail less than what you use for accounting. I think this is quite a common need. Side note: Can you specify budgets non-recursively, but then report recursively? Maybe, but then the reported budget value for a parent account with some non-recursive value is different than the specified budget value for that account. Isn't that pretty weird? Anyway, I concluded that being able to budget at different levels of detail was more important than being able to budget for accounts excluding their children. That said, if you really want to specify budgets non-recursively, then you're really changing the meaning of the stored values, so you should reflect that in the budget model, with an additional boolean structure member. That way, you can ensure that the reporting is consistent with the specification method. -chris Thanks! ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: (AUDIT?) Re: r14892 - gnucash/trunk - Add a new QOF_TYPE_NUMSTRING to add numeric sorts. (#150799).
On Tue, Sep 26, 2006 at 09:19:12AM -0400, Derek Atkins wrote: Quoting Chris Shoemaker [EMAIL PROTECTED]: What about...? 3) Leave sorting out of the type-system altogether and sort only in the view. Save the sort preference in GConf. (BTW, that's how it works in all the GtkTreeModel/View pairs, including on the register-rewrite branch.) That doesn't work with SQL backends when you want to return a subset of the responses. Playing the devil's advocate... A) We don't really have a working SQL backend. B) and no one is really working on one. But ignoring that for now... For example, if I wanted to do something like: select * from Split where ... order by ... limit 10; In this case, the order by clause is important in the underlying query.If you don't get the 'order by' correct then you'll get the wrong objects returned, which probably isn't what you want. Well, you get the right objects, just in the wrong order. If the user changes the sort from ascending to descending, do you want to requery the backend with different SQL? Of course not. You just reorder all the objects you already have. This is true for any sorting operation. Either that or you need to full working copy of all your data in core, which can get very expensive in large data sets. By core do you mean L1 data cache or just RAM? Either way, I'm _very_ skeptical of design decisions made with this motivation. Assuming you mean RAM, I would assert that the number of users who: a) would consider using GnuCash and b) have a financial dataset whose in memory (not on disk) representation is even 1/10 of the amount of RAM that came in the machine they want to use for GnuCash is actually zero. Yes, I understand that QOF was designed to handle NASA's multi petabyte image databases. I just think it's unnecessarily burdonsome to perpetuate that design requirement in GnuCash's QOF when it doesn't benefit any GnuCash users. I think it's _especially_ beneficial to drop the our database might be bigger than RAM ideas as we consider options for extending/rewriting QOF in the future. BTW, I don't object to this current changeset, or even backporting it. This is just the way QOF is today. I'm only concerned that we re-evaluate that design decision going forward. Just my $(small number)/$(xaccCommodityGetFraction(comm)) $(gnc_get_default_currency()). -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: (AUDIT?) Re: r14892 - gnucash/trunk - Add a new QOF_TYPE_NUMSTRING to add numeric sorts. (#150799).
On Tue, Sep 26, 2006 at 11:26:04AM -0400, Derek Atkins wrote: Quoting Chris Shoemaker [EMAIL PROTECTED]: That doesn't work with SQL backends when you want to return a subset of the responses. Playing the devil's advocate... A) We don't really have a working SQL backend. B) and no one is really working on one. But ignoring that for now... I concede A, but B is certainly in my mind.. If I can gain up the energy I certainly plan to work on it, but probably not in the timeframe for 2.2. For example, if I wanted to do something like: select * from Split where ... order by ... limit 10; In this case, the order by clause is important in the underlying query.If you don't get the 'order by' correct then you'll get the wrong objects returned, which probably isn't what you want. Well, you get the right objects, just in the wrong order. If the user changes the sort from ascending to descending, do you want to requery the backend with different SQL? Of course not. You just reorder all the objects you already have. This is true for any sorting operation. Not really. Assume you have 100 objects in the database, but you want to see the most recent 10 objects. If you only ask SQL for 10 objects, then the 10 objects it returns may not be the 10 objects you want to display unless the 'sort' matches. For example, if the sort is backwards, you might want to see objects 1-10 but it gives you 91-100. Or even worse, if you're sorting on the wrong thing it might give you some random set of the items between 1 and 100. Oh, I missed that limit 10 part. This is really conflating filtering with sorting. Does _GnuCash_ really have a use for filter N? _Even_ if we want to support remote datasets larger than RAM, you already have filtering by where. So, you're describing a case when you don't even want to return full query results! I just don't see this being even remotely possible for personal and small-business accounting software. Now, one approach to work around this is to assume you have regular checkpointing in the database (e.g. when you close the books) and then you always pull in all objects since the last checkpoint. Then you don't have to worry about it, except in the cases where you want to go back in time and see things that happened in the closed-out periods.. Then you just need to pull in periods atomically -- i.e. you always grab a full period of data from the database. Either that or you need to full working copy of all your data in core, which can get very expensive in large data sets. By core do you mean L1 data cache or just RAM? Either way, I'm _very_ skeptical of design decisions made with this motivation. Assuming you mean RAM, I would assert that the number of users who: I'm not thinking about it in terms of CPU cache usage. I'm thinking about it in terms of what's stored in QOF, and what QOF has to do in order to give you results. a) would consider using GnuCash and b) have a financial dataset whose in memory (not on disk) representation is even 1/10 of the amount of RAM that came in the machine they want to use for GnuCash is actually zero. I dunno. Go grab Don Paolo's data set.. 1000 accounts. 100,000 transaction. Well, I figure the on-disk representation is probably 2-4 times larger than the in memory size (totally a guess). So I wouldn't worry unless his datafiles are .5GB. Then tell me that it's okay to have it all in QOF's RAM cache.. I would say it's okay to have it all in RAM, and I don't think it needs any special cache at all. Now imagine going out to 20 years of data, hundreds of thousands of transactions... 10 years, 20 years, 100 years... Datasets grow linearly. RAM doesn't. To find the cross-over point when personal and small-business accounting data approached sizes larger than average RAM, I think we'd have to go back to the 1980s. Wouldn't you rather have a smaller working set? I know I would. From a user's POV, smaller memory requirements traded for increased latency isn't a clear win. From a developer's POV, having uniform access to the whole dataset is a clear benefit. Yes, I understand that QOF was designed to handle NASA's multi petabyte image databases. I just think it's unnecessarily burdonsome to perpetuate that design requirement in GnuCash's QOF when it doesn't benefit any GnuCash users. I wasn't really thinking in those terms... But I do think that requiring QOF to operate on 20 years of data for every operation is sub-optimal. I don't really think of it as QOF operating. I think of it as GnuCash operating. And I think GnuCash should have immediate access to all of the data in a book, even if that's 20 years. Now, book closing is a nice feature, too I think it's _especially_ beneficial to drop the our database might be bigger than RAM ideas as we consider options for extending/rewriting QOF in the future. I disagree... but perhaps
Re: Alternate patch to handle the Number Column sort
On Tue, Sep 26, 2006 at 07:20:11PM -0400, Derek Atkins wrote: Here's an attempt to implement choice #2. As you can see from this patch, it's much simpler. With approval I can back out r14892 and apply this patch instead. I've tested that this patch works, and it does (successfully). It turns out that I do NOT need to edit every QofParam to get it to work right! :) Let me know what you think. Do you prefer this patch or the one I committed earlier? I think this one is much better. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GnuCash on windows - Instructions for giving it a try
I have to say: Way to go, guys! A big Thanks! to Christian, and Andreas, and Derek for whacking at the win32 build. I look forward to seeing even more reports of success. -chris On Thu, Sep 21, 2006 at 04:03:05PM +0200, Christian Stimming wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear all, several of us have now compiled and run GnuCash on MS Windows by the mingw32/gcc compiler environment. This is how everyone else can give it a try as well. We would be happy to hear any further feedback about problems or (hopefully) success in this matter. We've created a shell script that will download, compile, and install all requirements of GnuCash on Windows and eventually GnuCash itself. It will even make sure to retrieve the most up-to-date gnucash source code directly from SVN. Running this script will probably download ~200MB of data (but all downloaded data will be cached) and will take anything between 0.5 through 5 hours of time. That shell script is located in packaging/win32/install.sh of the gnucash SVN sources. For your convenience I've attached the content of that directory to this email. Before you can execute this shell script (which will do everything else automatically), you have to complete these steps manually: * Get the content of the packaging/win32 directory of gnucash SVN, either from SVN or from the attached archive, and unpack it somewhere on your Windows machine. * Adapt the directory name variables in the custom.sh file according to your preferences; the defaults would install everything in subdirectories below c:\soft. (Note that due to shell syntax, every windows-style backslash has to be specified as two backslashes.) * Download the MSYS package from http://www.mingw.org/download.shtml - - Section Current - Subsection MSYS - MSYS-1.0.10.exe http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download * Execute this downloaded package to install it into the chosen directory, say, C:\soft\msys (which is the $MSYS_DIR variable in custom.sh) * Download the wget package from http://www.mingw.org/download.shtml - - Current - mingwPORT - wget-1.9.1-mingwPORT.tar.bz2 http://prdownloads.sf.net/mingw/wget-1.9.1-mingwPORT.tar.bz2?download and place the downloaded file in the $DOWNLOAD_DIR you have set in custom.sh * Start the MSYS commandline shell by double-clicking the MSYS icon on the desktop which should have been created when you installed the MSYS package. * Let the automated build begin by typing: cd $INSTALLER_DIR (the directory where install.sh is located) ./install.sh * If there haven't been any errors, you should be able (after several hours of compiling and installing) to start gnucash from the MSYS command line by typing c:/soft/gnucash/bin/gnucash or even without MSYS directly by Start- Run- c:\soft\gnucash\bin\gnucash.bat Please spread the word and report back any problems you encounter. It is probably not too difficult anymore to create a full self-contained package of GnuCash on Windows as well! Some more information is also collected on http://wiki.gnucash.org/wiki/Windows, but the information there might already be out of date as well. Good luck everyone with this! Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRRKbmWXAi+BfhivFAQIGQAP5AUX6Ml+B/RbQPRHrhbw1bDDHrsOWRN3Q 42GXZcwG3qx/mY7RJE8sonCljmpTR1ZskIFAFcAHbfqmg6xf3CET+cKItIEg+Cmq 4uKUlXQwH+d77Mtu0YMdMPiz10dsdyngpQiPeanrjPkdZEmufmoC4jvEVg8Pea7v IVPmVTBcv3M= =mJyh -END PGP SIGNATURE- ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: AUDIT: r14865 - gnucash/trunk - Do not complain about non-existent files if we save to a new file. In
On Mon, Sep 18, 2006 at 08:52:55PM -0400, Andreas Köhler wrote: Author: andi5 Date: 2006-09-18 20:52:54 -0400 (Mon, 18 Sep 2006) New Revision: 14865 Trac: http://svn.gnucash.org/trac/changeset/14865 Modified: gnucash/trunk/ChangeLog gnucash/trunk/src/backend/file/gnc-backend-file.c gnucash/trunk/src/gnome-utils/gnc-file.c Log: Do not complain about non-existent files if we save to a new file. In pass one we ignore the error returned by stat and call qof_session_begin with create_if_nonexistent=TRUE for a second run. BP ACK. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r14758 - gnucash/branches/2.0 - Add missing call to xaccAccountBeginEdit.
On Mon, Aug 28, 2006 at 11:27:43PM -0400, Derek Atkins wrote: Author: warlord Date: 2006-08-28 23:27:42 -0400 (Mon, 28 Aug 2006) New Revision: 14758 Trac: http://svn.gnucash.org/trac/changeset/14758 Modified: gnucash/branches/2.0/ gnucash/branches/2.0/ChangeLog Log: Add missing call to xaccAccountBeginEdit. Merge from r14694. Um.. but where's the real change? -chris Property changes on: gnucash/branches/2.0 ___ Name: svk:merge - d2ab10a8-8a95-4986-baff-8d511d9f15b2:/local/gnucash/branches/2.0:13185 + d2ab10a8-8a95-4986-baff-8d511d9f15b2:/local/gnucash/branches/2.0:13186 Modified: gnucash/branches/2.0/ChangeLog === --- gnucash/branches/2.0/ChangeLog2006-08-29 03:27:31 UTC (rev 14757) +++ gnucash/branches/2.0/ChangeLog2006-08-29 03:27:42 UTC (rev 14758) @@ -1,5 +1,9 @@ 2006-08-19 David Hampton [EMAIL PROTECTED] + * src/engine/Account.c: Add missing call to xaccAccountBeginEdit. + +2006-08-18 David Hampton [EMAIL PROTECTED] + * src/gnome/gnucash-desktop*: Update so that bug-buddy 2.16 will still allow you to file bugs against gnucash. ___ gnucash-changes mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-changes ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r14759 - gnucash/branches/2.0 - Update so that bug-buddy 2.16 will still allow you to file bugs
On Mon, Aug 28, 2006 at 11:27:54PM -0400, Derek Atkins wrote: Author: warlord Date: 2006-08-28 23:27:53 -0400 (Mon, 28 Aug 2006) New Revision: 14759 Trac: http://svn.gnucash.org/trac/changeset/14759 Modified: gnucash/branches/2.0/ gnucash/branches/2.0/ChangeLog Log: Update so that bug-buddy 2.16 will still allow you to file bugs against gnucash. Hmm, I see a pattern. -chris Merge from r14695. Property changes on: gnucash/branches/2.0 ___ Name: svk:merge - d2ab10a8-8a95-4986-baff-8d511d9f15b2:/local/gnucash/branches/2.0:13186 + d2ab10a8-8a95-4986-baff-8d511d9f15b2:/local/gnucash/branches/2.0:13187 Modified: gnucash/branches/2.0/ChangeLog === --- gnucash/branches/2.0/ChangeLog2006-08-29 03:27:42 UTC (rev 14758) +++ gnucash/branches/2.0/ChangeLog2006-08-29 03:27:53 UTC (rev 14759) @@ -1,5 +1,8 @@ 2006-08-19 David Hampton [EMAIL PROTECTED] + * src/gnome/gnucash-desktop*: Update so that bug-buddy 2.16 will + still allow you to file bugs against gnucash. + * src/engine/Account.c: Add missing call to xaccAccountBeginEdit. 2006-08-18 David Hampton [EMAIL PROTECTED] ___ gnucash-changes mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-changes ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r14760 - gnucash/branches/2.0 - Maintain the account hierarchy when reparenting the descendants of a
On Mon, Aug 28, 2006 at 11:28:05PM -0400, Derek Atkins wrote: Author: warlord Date: 2006-08-28 23:28:04 -0400 (Mon, 28 Aug 2006) New Revision: 14760 Trac: http://svn.gnucash.org/trac/changeset/14760 Modified: gnucash/branches/2.0/ gnucash/branches/2.0/ChangeLog gnucash/branches/2.0/src/gnome/gnc-plugin-page-account-tree.c Log: Maintain the account hierarchy when reparenting the descendants of a deleted account. Merge from r14700. Property changes on: gnucash/branches/2.0 ___ Name: svk:merge - d2ab10a8-8a95-4986-baff-8d511d9f15b2:/local/gnucash/branches/2.0:13187 + d2ab10a8-8a95-4986-baff-8d511d9f15b2:/local/gnucash/branches/2.0:13188 Modified: gnucash/branches/2.0/ChangeLog === --- gnucash/branches/2.0/ChangeLog2006-08-29 03:27:53 UTC (rev 14759) +++ gnucash/branches/2.0/ChangeLog2006-08-29 03:28:04 UTC (rev 14760) @@ -1,10 +1,8 @@ -2006-08-19 David Hampton [EMAIL PROTECTED] +2006-08-20 David Hampton [EMAIL PROTECTED] - * src/gnome/gnucash-desktop*: Update so that bug-buddy 2.16 will - still allow you to file bugs against gnucash. + * src/gnome/gnc-plugin-page-account-tree.c: Maintain the account + hierarchy when reparenting the descendants of a deleted account. - * src/engine/Account.c: Add missing call to xaccAccountBeginEdit. - 2006-08-18 David Hampton [EMAIL PROTECTED] * src/gnome/gnucash-desktop*: Update so that bug-buddy 2.16 will Gah! ChangeLog-mangling-alert! WOONKA! WOOKNA! -chris Modified: gnucash/branches/2.0/src/gnome/gnc-plugin-page-account-tree.c === --- gnucash/branches/2.0/src/gnome/gnc-plugin-page-account-tree.c 2006-08-29 03:27:53 UTC (rev 14759) +++ gnucash/branches/2.0/src/gnome/gnc-plugin-page-account-tree.c 2006-08-29 03:28:04 UTC (rev 14760) @@ -1095,7 +1095,7 @@ GList *acct_list, *ptr; xaccAccountBeginEdit (daa); - acct_list = xaccGroupGetSubAccounts(children); + acct_list = g_list_copy(xaccGroupGetAccountList(children)); for (ptr = acct_list; ptr; ptr = g_list_next(ptr)) xaccAccountInsertSubAccount (daa, ptr-data); g_list_free(acct_list); ___ gnucash-changes mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-changes ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
