Re: fr.po for 1.6.1 : won't be finished
On Fri, 06 Jul 2001 18:09:09 [EMAIL PROTECTED] wrote: At 21:52 05/07/01 -0500, you wrote: Preferez-vous le finir? To non-french speaking-people : the question was : do you prefer to finish it ? Sorry if I came across a bit snappy, but it's just that if I can't read a conversation on a list I might miss something that I can contribute useful information to . . . My answer is yes. I will finish it in a few days. I send a new version to dave last night. Translations are missing at the end of the file, but i will end them till end of july (before holidays in august). If you want to help on translations, you can : 1- get the gnc-glossary.txt from CVS (which I translated to) 2- Say here how you would translate COMMODITY (even non-french speaking people can explain here the meaning of the word) I've a lot of 3- begin translating the user manual. It's a HUGE work. So you can begin where you want, and we could divide the job between the volunteers. WRT translating the user manual, it's not only huge, it's somewhat of a moving target at the moment. If you see a part of the manual that contains a FIXME or a comment along the lines of this section is not fully documented yet, just put in a placeholder for that section, or, if you feel really inspired, write documentation in English for that section :) Thanks to all our translators. -- Robert Merkel [EMAIL PROTECTED] Go You Big Red Fire Engine -- Unknown Audience Member at Adam Hills standup gig ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: fr.po for 1.6.1 : won't be finished
On Fri, 06 Jul 2001 12:52:13 Jean-Claude Magras wrote: Preferez-vous le finir? Sincerely Jean-Claude Magras Could you please use English on this list? Only a minority of people here speak any French. -- Robert Merkel [EMAIL PROTECTED] Go You Big Red Fire Engine -- Unknown Audience Member at Adam Hills standup gig ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Proposal
On Mon, 02 Jul 2001 12:55:43 Chris Lyttle wrote: Hi I've been following the GnuCash-devel mailing list for some time now and now that we have 1.6.0 out the door I was wondering what the feeling would be for an occasional News email sent out to the various Linux News sites to keep people up with the directions GnuCash is heading. I would be willing to put this together from mailing list posts if no one objects. A couple of people (including me) have proposed doing this a couple of times, but nobody's actually been prepared to put in the time to do it. I think this would be really great. I would suggest a bi-weekly or monthly schedule, if you want to make it a regular thing. I'd be prepared to help out if you were unable to do a particular issue. One home might be as a Kernel Cousin (http://kt.zork.net), but it could also be posted on the gnucash web pages - opinions, anyone? BTW, since a fair bit of important stuff gets discussed on the IRC channel, you might wish to include it. Considerable discretion if of course called for if you want to do that (in fact, it'd probably be best if you always asked for permission before doing so IMHO). Anyway, this would be a really great contribution to the project if you can stick with it. -- Robert Merkel [EMAIL PROTECTED] Go You Big Red Fire Engine -- Unknown Audience Member at Adam Hills standup gig ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Pie chart reports
On Thu, Jun 21, 2001 at 08:36:22AM -0500, Greg Hewgill wrote: I've just started using gnucash 1.6 (migration from Money 95). I've been running the reports and have found some odd discrepancies. In particular, in the expenses piechart (account-piecharts.scm), even expense accounts that have a negative balance over the requested time interval show up as pie slices. That's just not right. :) In particular, I have an expense account where I entered some money that I loaned to a friend a while ago. As he repaid me over time, I have entered offsetting transactions so once he's done, the account balance will be zero. However, if I run a report for just the last couple of months (so my initial payment to him is not included), I get his repayments to me showing up as expenses in the pie chart. I don't suppose you've tried simply deselecting that particular account in the report options? ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Huh? Starting out with gnucash (new accounts, etc)
On Tue, 19 Jun 2001 09:22:43 Robin Coon wrote: Eric Schwartz wrote: The current thing that is blocking me is setting up a brokerage account. Create all the relevant commodities first (check) Create accounts for each commodity in the brokerage account (check) Create an account for cash on hand in the brokerage account (check) but how to I assign the initial values? I have 60 shares of this stock, and 32 of that one, and I can't figure out how to put this information all in. I thought about putting buy transactions in place for each stock, using the correct date (that would be most useful anyway), but the money has to come from somewhere... THis is getting really confusing. I assume you bought these before the period you started tracking from? In that case, I'm in the same situation. What I did was to enter buy transactions at the relevant dates and prices, and transferred the money from the Equity:Opening Balances account. Since I wasn't using gnucash back when I bought most of the stock, I figure that's more or less what it's for. Mind you, I know jack about accounting, and even less about gnucash, so I welcome rebuttal from someone who actually knows what they're talking about. -=Eric Please forgive me if I sound clueless about GNUCash, I am very new to it and just started subscribing to the mail list. I do hope that with my accounting background (dangerously close to completing licensing for my CPA designation and I work at a large accounting firm) I can make some contribution. From an accounting perspective, the transactions that are most relevant at this time are those that occur during the current tax year (Jan 1, 2001 - Dec 31, 2001). When you initially set up your brokerage accounts, the offset to the account should be Equity: Opening Balance. So your cash for those initial buy transactions to get your securities into GNUCash would be Equity. That sounds pretty correct to me. -- Robert Merkel [EMAIL PROTECTED] Go You Big Red Fire Engine -- Unknown Audience Member at Adam Hills standup gig ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Transaction report bug might be fixed now
WRT to account display bug in transaction report, I've checked in a fix to CVS HEAD. Would it be possible for you to check it works before I merge the fix into the 1.6 tree? 1 down (I think), several to go :) -- Robert Merkel [EMAIL PROTECTED] Go You Big Red Fire Engine -- Unknown Audience Member at Adam Hills standup gig ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: compiling 1.6.0 on Mandrake 8.0
On Thu, 14 Jun 2001 19:52:08 Arnaud Calvo wrote: Well, I have understood your last message : install name-devel.rpm when you have name.rpm ! So when I encountered other pb, I installed : db1-devel-1.85-4mdk.i586.rpm libgal4-devel-0.5-2mdk.i586.rpm ... but it would have been too easy : checking for main in -lgal... no configure: error: gal library not found. See the README for more info. ALTHOUGH I have libgal4-0.5-2mdk and libgal4-devel-0.5-2mdk installed :-((( Am I so stupid ??? No, you are certainly not stupid. Compiling GnuCash from source can be challenging, particularly as the distributions do not contain the necessary prerequisites yet. For instance, have a look at http://lwn.net this week. The head writer there can't get it to work, and he's been writing about Linux for years. As to your specific difficulty, I'm not absolutely sure here, but I think that your problem is that the version of gal you have is probably too old, you need a newer one. -- Robert Merkel [EMAIL PROTECTED] Go You Big Red Fire Engine -- Unknown Audience Member at Adam Hills standup gig ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Balance sheet report for a sub-group of accounts
On Wed, 13 Jun 2001 19:15:46 Christian Stimming wrote: -BEGIN PGP SIGNED MESSAGE- Oops, that bug goes on me. The problem is that I didn't manage to get the sub-balance calculation and the account showing/not-showing to follow the same rules on which accounts to include and which not. The problem lies in html-utilities.scm at e.g. line 511, where the function for subbalance calculation simpy ignores any of the account selection options. At this point we would need to introduce a new function that does the subbalance calculation with regards to the account selection options. Note, however, that the semantics of the account selection in the balance sheet and those in the profit and loss report are slightly different. (That's what you get if two different developers write different reports...) The semantics for the latter are explained in html-utilities.scm:309. If somebody fixes the subbalance bug, he might want to unify those two semantics in a consistent behaviour as well. Yes, I suppose we should fix it. I can do that, but I'm busy this week, i.e. I can work on that after June 18th. If somebody else wants to go ahead before that date, please do it. Christian There is another issue to do with this code, that I noticed WRT the balance sheet but also appears in the average-balance report. What should we do if somebody has an asset parent account with, say, a credit card subaccount? At the moment, the credit card account will be displayed as an asset . . . -- Robert Merkel [EMAIL PROTECTED] Go You Big Red Fire Engine -- Unknown Audience Member at Adam Hills standup gig ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: integration with paytrust.com
On Tue, 12 Jun 2001 06:27:58 Austad, Jay wrote: Has anyone here used Paytrust.com? How hard would it be to set up Gnucash to pull down bill information and handle transactions with paytrust? (Paytrust receives your bills for you, scans them in, and sends you an email when a bill comes in. You just go to their site to view the jpg of the bill, click to pay it, or you can set up automatic payments that require no interaction at all. Probably the most convenient thing I've ever used.) At the moment, GnuCash doesn't directly support doing transactions online, but there is interest from several people in supporting various online transaction systems (for instance, there are a couple of Germans who wish to support their local online banking standard). There is probably some amount of infrastructure work that needs to be (and will be) done before support for this kind of system is feasible. Of course, having input early is more likely to lead to infrastructure that meets the specific needs of your system :) Support for a specific tool like this depends on whether the provider already has a publically-documented interface for interacting with the system, or is prepared to provide one. Screenscraping websites subject to formatting changes is difficult enough just reading stock prices (which we handle through an externally maintained perl module), but actually performing transactions in this manner is extremely risky IMHO. If you're at all interested in working on this, we'd be equally keen to help you. We always need more people to work on new features. -- Robert Merkel [EMAIL PROTECTED] Go You Big Red Fire Engine -- Unknown Audience Member at Adam Hills standup gig ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Modularization
I have read Bill's suggestions, and I thoroughly support the concept of increasing modularity. There are, however, a couple of related issues I'd like to raise . . . 1) Are there self-contained parts of gnucash that we could turn in to libraries, enabling their easy use in projects that don't contain any other parts of the GnuCash codebase? One possible example is the gnc_numeric code - relatively self-contained IIRC, and it might be useful for external projects. Similarly, the HTML-generation scheme code may well be useful for projects that have nothing to do with gnucash (though it's perhaps a little less self-contained). 2) One of the difficulties of using guile as an extension language for GnuCash is that the GUI is implemented in C. So, if you want to get information from the user for your funky scheme script, you have to code up some C and g-wrap it. Is this always going to be the case? -- Robert Merkel [EMAIL PROTECTED] Go You Big Red Fire Engine -- Unknown Audience Member at Adam Hills standup gig ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
User documentation for the Postgres backend
Linas, I'm currently going through the user docs, and I notice that we don't have the postgres backend documented in the online help. Is it OK to transplant your stuff from src/engine/sql/README into a help file? Is that document currently up-to-date? -- Robert Merkel [EMAIL PROTECTED] Go You Big Red Fire Engine -- Unknown Audience Member at Adam Hills standup gig ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
RE: GLib RFC: Improve checking provided with --enable-mem-check
On Wed, 06 Jun 2001 16:45:08 Phillip Shelton wrote: I am lost. How does glib compare with glibc? glib and glibc are two seperate libraries. Glib was originally written as part of the gtk+ toolkit, and provides a whole collection of useful routines, such as basic data structures like lists, trees, and hash tables, and some of which provide similar functionality to the C library (but with a much nicer API), such as gmalloc. GnuCash, like most gnome applications, uses glib wherever possible, as it is a well-designed library that saves a heck of a lot of time testing and debugging. Amongst glib's tricks is a mode where it helps to detect common memory allocation errors (when those memory allocation errors are made using glib's memory allocation functions such as gmalloc). However, this functionality is not as complete as it could be, and Ben is proposing an enhancement to it which would allow more errors to be detected (and thus fixed faster :-) ) This is really not an issue that directly affects gnucash, Ben just raised it here because the spur for his proposal came out of debugging gnucash, I guess. -- Robert Merkel [EMAIL PROTECTED] Go You Big Red Fire Engine -- Unknown Audience Member at Adam Hills standup gig ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: 1.5.97 first impression
On Mon, 04 Jun 2001 15:41:37 Jeffrey W. Baker wrote: Hi, I've been trying to install GnuCash off and on for at least two years. 1.5.97 is the first version that I have successfully installed. Congratulations are in order, I think. Here is a rundown of my impressions: Installation is much more of a pain in the ass than any other program I have ever installed. SLIB is definitely the weak link: installing it from source is a completely undocumented headache. Anyway I finally got it installed when I found mention of GUILE_LOAD_PATH on some mailing list somewhere. GnuCash also has more obscure dependencies than any other application on my system. Installing all of them is a chore, even for a user who has been developing software on Unix for decades. That said, I'm sure most people install GnuCash from packages. It's the package maintainers that we'll have to put on the suicide watch. I agree that there are a lot of dependancies. However, if the distributors do their jobs right, once the new GnuCash becomes part of the distros the problem largely goes away. I also expect that Ximian will add it to their GNOME distribution once the release is stable and they get around to it, making the installation trivial. WRT to the specific issue with slib, there are moves, I believe to get it into the main guile distribution, so one dependancy will go away :) Anyway, Once the beast is up and running it works acceptably. I did notice that the initial new file wizard doesn't display any account types in its list, so I couldn't use it jumpstart my accounts tree. Is it supposed to work in this verion? Could you please explain in more detail what you mean? It works for us here. Another major flaw was that I carefully configured my expenses pie chart, but after I closed its notebook tab, all my settings went away. I chose Reports-Income Expense-Expense Pie Chart, and it had the default settings again. How do I save my custom reports? (Also it looks like you have to be a Ph.D CompSci to create new reports. Some people can make macros with *Basic but try teaching my wife about functional programming!) You can just leave them open and keep the tabs there - they are persistent across sessions. We should, however, be able to save named reports explicitly, and GnuCash doesn't do that yet. With respect to the perceived difficulty of writing custom reports, well, all I can say is that I, and my fellow developere, like working with scheme, and intend to keep doing so. That said, if somebody were to contribute and maintain another language binding, that would be all well and good, but I personally don't feel any need at this point. The help browser left navigation doesn't stay in sync with the display on the right. Also selecting something on the left navigates to something else entirely on the right. Yes, the help-topics stuff is slightly broken at the moment, I believe. If GConf is unavailable (because oafd has gone out to pasture), GnuCash will crash when trying to create reports. This sounds like a bug in gtkhtml, which is used to display reports. I'll take a look. Speaking of reports, generating even the simplest reports takes forever. On my 1.2 GHz Athlon with 512M of memory, generating the pie chart of exactly one expense takes over 30 seconds. Is there some way I can fix that? Reports can be slow, but aren't usually *that* slow. What version of guile are you using? Memory usage is completely out of proportion. With a few ledger entries and one report, the RSS is 21M, almost as much as Mozilla. Restarting doesn't help. I can't really comment here because I don't know enough about the issues, but fair amounts of that are probably various bitmaps , guile stack (which can be reduced if it turns out to be a problem), and about 10 megabytes of shared libraries (of which only one copy gets loaded for all the processes, I think). Starting GnuCash also takes forever. I noticed with strace that a whole lot of Scheme hoo-haw happens at startup time, then the display blocks for 30 seconds generating my report. Like I said, it can be slow, but not that slow. I have a P3-733 and my startup is much, much faster than that. I should also add that several of the GnuCash developers are working on speedups and performance analysis tools for guile. The splash screen is usually obscured at startup by the main window, and it also has a frame which usually splash screens do not. This is partly a window manager issue. I know that at some stages the splash screen was frameless, but Dave Peticolas (the lead programmer) changed it back because, I believe, it worked better with some window managers that way. Perhaps he will comment further . . . I noticed that the account tree is collapsed when I restart. I would rather save the previous expanded/collapsed state. Is there a preference? Those are the only issues I noticed so far.
Average Balance report borken WRT stocks/mutual funds
It appears that the average-balance report is fundamentally wrong-headed about balance displays for stock and mutual fund accounts. Basically, when the average-balance report converts to the report currency, a fixed price is calculated which is used for all intervals in the report. This is OK for a foreign currency, but for shares is almost certainly not what you want - you want to look up new prices each time you deal with a new transaction to show how the total value of your stock changes over time. We can probably get this fixed in time for the scheduled release of 1.6, but we won't have time to test it much. However, if the problems with gtkhtml and guppi printing don't get sorted out perhaps holding off is going to be desirable after all. -- Robert Merkel [EMAIL PROTECTED] Go You Big Red Fire Engine -- Unknown Audience Member at Adam Hills standup gig ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Problem with multi-line style transaction report
On Sat, 02 Jun 2001 11:59:33 Damian Ivereigh wrote: OK I have fixed it. I needed to actually *save* the file before running the reports. I hope that doesn't mean we have to do that generally. Damian Sorry I didn't reply to your earlier email. This sounds like it's a bug. We have had others report some problems with multi-line style on the transaction report, but we haven't been able to confirm it. If you can recreate the conditions that caused the crash and send me the data it'd aid the debugging process a lot. My gnupg key is attached if you want to keep the message private. -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.0.1 (GNU/Linux) Comment: For info see http://www.gnupg.org mQGiBDjSqOQRBADb0yED8Odqthzb64MjXptIAMWT+ak0X6KsAdpTwxObwZStxfQY 5khvLtG1oe3gnfMPCBqQOGWuvR+cKHlO7ajmWoBHnzm09rrM5GpST6xgcmwUW/3j 2scc33DN4Yj9w2XOI9cIR6LpRHACyVkpc4rxkQWLldg+LYJaNmME+EvX9wCgoXgP rza3SjeuwjqD21xkbmK3YUUD/3pZWC3T2V5TNy/geuQvZ019+msMsdqmBM55cZEh Vb7ZOJbBo9BChz0W5C2ULGtu3jocBkgg8mCtqUtNmQBkAEwd1NUdZRFFoiZ5ORov R4a9jxbeMoHzZ1lWz/XERFkKd+tHqOg/W8458vIJG8Wv2IgIhbHJiYcNj/dGiUSv P+YEA/9Siy0oyigxW8itdEWaYuBaIa8VzP1JEuLSS62i7jW+e5OW3thlpZcvypol obiRLmGbCWHlt2ZO+ok4XAeG/wPCtJRFrBmh5vaZInf8WoJxH/GhliDDetylX4pB 0aA/zlLFEThEutgLhaI0yeRa/ODrKT/tOlLJBBFpMk+DrjOrTbQmUm9iZXJ0IEdy YWhhbSBNZXJrZWwgPHJnbWVya0BtaXJhLm5ldD6IVgQTEQIAFgUCONKo5AQLCgQD AxUDAgMWAgECF4AACgkQjqyS+ax0mNH56gCeKnNtA/MZZmkF/PpjsoMhToVNWj4A n1B9jmttkoeXOsFDaXESF8wb/liXuQENBDjSqO0QBACrQqqeY6dLLMW7QYMmDsVM Sqdm5GOxclxsa3Mtr0BkLlJA2XWDVXF36aa92+p1Ldh3i8076nzqJXuvGxpiMyzz C97LdYkUaGFgC2XxAzk+PmWoHzzbb/bcSS9sGRjHY5NQ/b2t4+R9/yVVawqy+8xc WFn/VYTBOHAx4iFsgtSwIwADBQQAnEbnAWT/akV3o0gSkzYQ+JqoR+oP7QQPZsKf AGmgezPZpNTWbPUP1heop1spbmuOg8UynaPcljFuIgEYGBYp8LK5+6+tkPQE6iJu fAUWwP8gtzwiFG71QUHOpM9lFyNZE5w5gKEBAMI0OaHnHDvZmlLsRewhlEFo6Sds HxSbBd+IRgQYEQIABgUCONKo7QAKCRCOrJL5rHSY0dXZAJ9RWGQmTr92nsJwKTcK BeTMSDNBNgCfc81vut0DhMqg1gBSal1279LXCw4= =gq7B -END PGP PUBLIC KEY BLOCK- On 01 Jun 2001 23:16:33 +1000, Damian Ivereigh wrote: -- Robert Merkel [EMAIL PROTECTED] Go You Big Red Fire Engine -- Unknown Audience Member at Adam Hills standup gig ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Check printing and localisation (DE)
On Thu, 31 May 2001 19:30:13 Herbert Thoma wrote: Klaus Ridder wrote: I totally agree: checkes are nearly not used here, focus on online banking would be much more important. I agree, too. A few points: 1) fixing check printing is a considerably smaller job than online banking. 2) Business people like to print checks, at least in Australia and the US. 3) most of the functionality is already present, all we need is to add some infrastructure for picking the right check-printing method and write the amount-word conversion functions for the areas where there is sufficient demand to warrant putting the effort in. 4) We can do both things at the same time. For me personally, work on online banking is going to be difficult because AFAICT Australian banks online efforts are exclusively web-based (using either Javascript, Java clients, or proprietary clients speaking protocols unknown) at this stage. However, as spelled numbers in Germany are quite a mess, as far as I know the following method is also accepted in germany ( I have seen this a couple of times): 234 DM and 56 Pfennig as Zwei-drei-vier DM (just the numbers two-three-four). Yes, this method is valid for a german check (at least the checks I did this way were accepted, but they were not many). Probably implementing that would not be too difficult. for the english developers: Missed the zero: 0 = null 1 = eins 2 = zwei 3 = drei 4 = vier 5 = fuenf 6 = sechs 7 = sieben 8 = acht 9 = neun 10 = zehn Regards, Klaus Thanks for your help. Anybody else add any more? I've spoken to some UK residents, and the rules are similar to Australia. Anybody else? I'd be particularly interested in the situation with more than one official language - for instance, what's the deal in Canada? I presume cheques written in both French and English are in use there? -- Robert Merkel [EMAIL PROTECTED] Go You Big Red Fire Engine -- Unknown Audience Member at Adam Hills standup gig ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: doc problems
On Fri, 01 Jun 2001 03:47:50 James LewisMoss wrote: I didn't want to go messing with this stuff not knowing how things were setup and planned, but here's the issues I see with the docs (I'm willing to fix these issues I just wanted to make sure I'm not messing with things that are meant to be a certain way): 1) There are nested Getting Started sections in xacc-quickstart.sgml. Maybe the sect1 Getting Started should be removed and all the sect2's should be promoted to sect1's. Yep. That makes sense. Shall fix. 2) Getting Started section should be at the top. Not halfway down the page. Yep. 3) A tip mentions looking at a What Changed section, but a quick scan didn't find it (it may be there). If it exists it should be prominent (subsection of the first section on the page) or it should be created if it doesn't exist. It's there - I think I called it What's new in GnuCash 1.5 . . . Will fix the tip. 4) Like 1 above, nested Finding transactions with \Find Transactions\ dialog Ok. Shall fix. 5) If an article doesn't have any sections it gets no space between it's title and the next article's title making it seem as if it's one long (and ofter confusing) article name. Adding a sect1title/title.../sect1 around all the content in the file gives it a nice space from the rest. This problem exists for Preferences, Balance Tracking Report, Creating a \commodity\, Account Window, Profit and Loss Statement, Printing, Tax Report / TXF Export, Transaction Report, Detailed TXF Category Descriptions, TXF Export - Known Anomalies and Limitations, TXF Export of tax data, and GnuCash Y2K Readiness. Agreed. Will fix. BTW, dres, did you ask Mr. Haggerty to try a 1.5.x version and see if the problem still exists? -- Robert Merkel [EMAIL PROTECTED] Go You Big Red Fire Engine -- Unknown Audience Member at Adam Hills standup gig ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
GnuCash locking up your window manager
A little while ago you reported having some problems with GnuCash locking up Enlightenment when opening a new register window. I don't know whether you received a reply (if not, sorry about that), but your problem was added to our bug tracker (http://www.gnumatic.com/bugs) by one of the developers. As far as I know, none of the main developers has been able to confirm or reproduce your problem - I think most of them use either sawfish or the KDE WM, and no such symptoms have been reported under either of those. In any case, the 1.5 series has now entered beta and is soon to become a new 1.6 stable version. This is almost a complete rewrite. If you have the time and are interested, it would be very useful if you were able to try the beta and see if the problem still exists. -- Robert Merkel [EMAIL PROTECTED] Go You Big Red Fire Engine -- Unknown Audience Member at Adam Hills standup gig ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Transaction report crash?
You reported a report with style: multi-line in the transaction report a little while ago. Nobody has been able to duplicate the crash, and there wasn't much to go on in the bug report. Is this crash still happening? Does GnuCash hang totally? Is there a scheme backtrace? I'd really like to get some resolution to this issue as the release date approaches. -- Robert Merkel [EMAIL PROTECTED] Go You Big Red Fire Engine -- Unknown Audience Member at Adam Hills standup gig ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Currency printing not really fixable for 1.6
Ben, You're right - fixing the currency printing for cheques, for full generality, is going to be a major PITA, and there's no way we can get it into 1.6. However, for a quick hack to make things work just for AU users, you can just modify the function number-to-words in number-to-words.scm. -- Robert Merkel [EMAIL PROTECTED] Go You Big Red Fire Engine -- Unknown Audience Member at Adam Hills standup gig ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Check printing and localisation
GnuCash 1.5.x has the ability to print checks. Unfortunately, it writes out the amounts in words in a US-specific way - for examples, $234.56 is written out as Two hundred and thirty-four Dollars 56/100 and $234 is written as Two hundred and thirty-four Dollars 0/100 on Australian cheques, the equivalent amount would be written as: Two hundred and thirty-four dollars and fifty-six cents and $234 would be written Two hundred and thirty-four dollars only However, a sample of two isn't great for developing a general solution for the many countries with GnuCash users (or potential GnuCash users) who might conceivably want to print checks from their PC's. So what I'm really asking international users to do is describe how this is done in your home country, so that we can come up with a more general solution for translating numerical quantities to words in a localised way for next time round. If you want GnuCash to fully support localised check printing for your country in the future, have your say now! -- Robert Merkel [EMAIL PROTECTED] Go You Big Red Fire Engine -- Unknown Audience Member at Adam Hills standup gig ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Check printing and localisation
On Wed, 30 May 2001 23:06:31 Duarte Loreto wrote: Hope this helps someone. I can look at the scheme file and see how it could work in portuguese, although I promisse nothing as I never coded in scheme nor C. Do you know perl? Python? Basic? Pseudocode? If you can code a little demonstration program in one of these languages (or any other language you do know) to explain how to convert a numeric amount into text like you'd write on a check, that would be extremely helpful. If that's too complicated, could you explain the grammar rules for constructing such a string? Thanks for your input. -- Robert Merkel [EMAIL PROTECTED] Go You Big Red Fire Engine -- Unknown Audience Member at Adam Hills standup gig ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: check locales (was something that I deleted and can't remmember)
On Thu, 31 May 2001 10:03:29 Duarte Loreto wrote: I think it woul be easier to do the code than explain the grammar... ;) OK. By weekend, I can send you a Java class that gets a number and returns the string. The languages I'm better at (or least worse) are Java and VB. My current project at work is in VB so I prefer to do it in Java. Well... I would always prefer to do it in Java :) Sorry for not doing it until weekend, but I've been working 12+ hours per day... Cannot get home and code... Have fun! (I'll have more fun when you get my class :) There is no hurry at all - this is a post-1.6 issue. Whenever you have time will be fine. -- Robert Merkel [EMAIL PROTECTED] Go You Big Red Fire Engine -- Unknown Audience Member at Adam Hills standup gig ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Compiling 1.5.97 for FreeBSD
On Tue, 29 May 2001 22:57:41 Matthew Condell wrote: Hi, I've just started trying to get 1.5.97 compiled on FreeBSD 4.3. Haven't had a chance to try out earlier releases in the 1.5.x series. I've had a couple of hangups so far: Fixes (or at least workarounds) for the problems you have described have been added to latest CVS. Could you you possibly check to see whether it now compiles for you? -- Robert Merkel [EMAIL PROTECTED] Go You Big Red Fire Engine -- Unknown Audience Member at Adam Hills standup gig ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
test
Please ignore. -- Robert Merkel [EMAIL PROTECTED] Go You Big Red Fire Engine -- Unknown Audience Member at Adam Hills standup gig ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
printing bugs, at least one of which is guppi's
(sorry for the crossposting, but probably appropriate in this case). I've been investigating bugs with gnucash's printing of guppi graphs. One seems to be a straightforward guppi bug, the other is somewhere in the interaction of guppi, gnucash, gtkhtml and possibly gnome-print :( Firstly, a relatively simple one. When printing a bar chart, guppi chops the bottom half of the zero y-axis scale marking. It appears that the bounding box that guppi clips to around this extends exactly to the zero point on this axis, cropping the bottom half of this marking. This one is present in the guppi barchart demo, and should hopefully be reasonably easy to fix. The second one is a bit of a brain-strainer. While displaying fine as an embedded widget as part of a gnucash report displayed by gtkhtml, when printed, guppi graphs are seriously misaligned - titles and even the top of the graphs themselves is disappearing off the top of the page. If I manually insert a few line breaks into the report to move it down, the entire graph will be rendered, indicating that either (a) somehow, the top margin is being ignored, or (b) the size of the printed guppi chart is being miscalculated. I have tried tracing what's going on in this code, but there's too many interactions going on and I'm stumped. Anybody suggest where I should start looking for this bug? Robert Merkel[EMAIL PROTECTED] Go You Big Red Fire Engine -- Unknown Audience Member at Adam Hills standup gig ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Assignigng VAT values to accounts
On Sun, 27 May 2001 02:07:12 Klaus Ridder wrote:
Talking about GnuCash for business:
It is already possible to set accounts to tax-related, which is quite
useful.
{tax} is inserted in the notes-field, as I can see.
I _am_ using gnucash for business, and one of the functions I'm really
missing the most is the possibility to assign a VAT value to every
account.
This feature would make Gnucash really usable for business.
I see that Gnucash for business is quite a road ahead, but I think the
following feature probably wouldn't be _too_ difficult to implement and
would REALLY help a LOT:
I imagine the feature as follows:
Every account has a flag, called VAT. This now can be set to any
percentage (0% - 100% and to UNSET, which is the default for all
accounts).
Now you can create a VAT TAX REPORT that makes a listing of all
accounts
tagged in the tax report, and shows:
Account NameTaxAmount
+Business 16% 160$
|--+PCs - 160$
| |--without tax0% 0$
The account Business is tagged with 16%, #
the account PCs is not tagged at all,
The account without tax is tagged with 0%.
The account PCs, which is not tagged, takes it VAT value from its
fahter
account for this report.
Currently, I am handling it the following way:
Business expenses 16%
|--- PCs
Business expenses 0%
|--- PCs
For the VAT report, I print the Business expenses 16% account, take my
calculator and calculate the VAT total.
It is just bad that I have to maintain 2 equal account structures for 16%
and 0%. Whith the new feature, I just had to make a sub-account if I had
transactions with different VAT values.
I would love to program this by myself, but I'm sorry I can't, so it
would
be great if someone could implement that feature. It would really help me
a
lot!
(Some of you might say now: Oh, this would be better the following
way...:
Yes, of course, this is not THE way for business-gnucash. But it helps
around until that is finished.)
While this might work, in Australia you *must* explicitly record the
GST/VAT
amount for each transaction, as reported on the receipt. Presenting tax
statements calculated by the methods you describe is *illegal*, if Ben
Stanley
and I have interpreted the Guidlines provided by the Australian Tax Office
correctly. This of course, may not be the case in your jurisdiction.
However, for doing GST calculations for goods/services you sell, the system
you
describe would be very handy for doing the calculations (and hopefully
printing
a Tax Invoice or whatever the equivalent is in your jurisdiction).
However,
for actually recording the transaction, you still have to store the GST
value
explicitly - just recording the rate won't do.
I do want to have GST/VAT support as soon as possible in the next
development
cycle, but we have to do it right, or people won't be able to use it.
By the way, when we have GST/VAT recording/reporting implemented, we'll
need
testers from as many jurisdictions as possible. I'm confident we can find
some Australians, but your help as a tester from a different jurisdiction
would
be most appreciated. That goes for anybody from any other countries with
this
type of tax.
--
Robert Merkel [EMAIL PROTECTED]
Go You Big Red Fire Engine
-- Unknown Audience Member at Adam Hills standup gig
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
1.{56} dependancy list
OK, below is a list of all the requirements I can *currently* think of for
building
and running gnucash 1.5.x, soon to be gnucash 1.6. Feel free to flame for
errors
and omissions :)
Once we've corrected the errors we'll put this up
on gnucash.org.
Software requirements for GnuCash 1.{5,6}:
Gnome 1.4: Debian woody and sid already include GNOME 1.4, and other
distributions
may already do so. If not, try Ximian Gnome (http://www.ximian.com) - they
put
all the Gnome 1.4 packages together conveniently for easy download.
You need pretty much the full set of gnome libraries, including gtkhtml,
bonobo, and
gal. NOTE: while you need to install the gnome libraries, you don't need
to install
the whole desktop if you don't want it. GnuCash will run quite happily
under any
window manager/desktop environment, including KDE.
GUPPI: any recent version will work, but 0.35.5 or later is required for
full
functionality. Debian unstable should have it, or you can download
packages from
ftp://ftp.gnucash.org/pub/guppi. The guppi homepage is at
http://www.gnome.org/guppi
g-wrap: you need a 1.1 version The older 0.9 series, required for gnucash
1.4, is
not sufficient. Note that g-wrap 1.1 is not backwards compatible with
gnucash
1.4 either. Get it from ftp://ftp.gnucash.org/pub/g-wrap
guile: you need at least version 1.3, but more recent versions are
considerably
faster. Guile can be obtained from the homepage at
http://www.gnu.org/software/guile/guile.html
and packages are included with all Linux distributions.
Python: some guppi binary packages are built with python support, so if you
use one with
this support you will also need python. GnuCash does not make use of this,
so if you are building your own version of guppi just for GnuCash you can
safely
disable python support. Python is included with all distributions.
Python's
homepage is at http://www.python.org
Additional requirements for online quotes:
Perl: you need some kind of Perl installation. Virtually all systems have
Perl
installed, and every general purpose Linux distribution includes it on
their
CD's. In the unlikely event you can't find a package for your system,
try the Perl homepage at http://www.perl.com.
Finance::Quote : a special Perl module for downloading finance quotes.
Might
be included with your distribution, otherwise most easily obtained using
CPAN
(http://www.cpan.org). Getting the most recent version is a very good idea
-
this program interprets web pages that change in format from time to time,
at which point the program may stop working properly.
Additional requirements for building gnucash yourself:
* You need the development files for all the libraries you installed. If
you
install a library package foo, you will need foo-dev or foo-devel, and get
it
from the same source you got the original package from and make sure it's
the
same version!
* gcc, make: the versions that come with your distribution should be fine.
GnuCash *may* work with non-GNU C compilers and make versions, but we
haven't
tried.
Additional requirements for building from CVS:
autoconf, automake, libtool: standard tools for building GNU programs. The
versions with your distribution will be fine. If you can't find them for
your
system, try http://www.gnu.org/software/software.html
jade, cygnus-stylesheets: The GnuCash documentation is authored in DocBook,
and then converted to HTML during the build process. We do this in case we
ever decide to turn the documentation into printed form. These packages
are available with most distributions. Jade's homepage is at
http://www.jclark.com/jade/. The cygnus stylesheets can be downloaded from
ftp://sourceware.cygnus.com/pub/docbook-tools/docware.
--
Robert Merkel [EMAIL PROTECTED]
Go You Big Red Fire Engine
-- Unknown Audience Member at Adam Hills standup gig
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: margins for printing gtkhtml?
O This is weird, as gtkhtml uses A4 size. I am not sure what is the standard way of printing settings like paper size, resolution, ... Lauris? I did notice this. I think the margins are probably fine for general text, for for tables, you want the option to use as much as the page as possible. So could you please check, that wide tables aren't some other issue? GtkHTML printing code is in htmlengine-print.c, where we use GnomePaper object. users. As gnucash tends to use tables that can get rather wide, this is rather restrictive. Is there an existing interface/API that can be used to configure the margins (and papersize, for this matter)? If not, how difficult would that be to add? I think it's not very usefull when each library will have its own way of setting these standard parameter, again Lauris could you please comment on this? On the other hand, I am thinking about some more general interface, when calling application (like GnuCash) gives to GtkHTML GnomePrintContext and printing area (like x_offset, y_offset, width, height) and then will call for each page print. So the interface could look like this: void gtk_html_print_begin (GnomePrintContext *pc, gdouble x_off, gdouble y_offset, gdouble width, gdouble height); /* return value: FALSE - nothing printed, we are on the end of print, TRUE otherwise */ gboolean gtk_html_print_page (); void gtk_html_print_end (); OK, so what do you think? Personally I always think in terms of margins rather than printable width and height, so I'd prefer and interface that takes left, right, top, and bottom margins, and figures out the width based on the paper size (which might also be passed in as a parameter). Bill Gribble, do you have a comment on any of this? Anyway, thanks for your input. -- Robert Merkel [EMAIL PROTECTED] Go You Big Red Fire Engine -- Unknown Audience Member at Adam Hills standup gig ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Australian BAS with GNUCash
On Thu, 10 May 2001 17:50:56 Klaus Ridder wrote: 29/4/2001 Woolworths 50.25 Assets:GST Credits 2.64 Expenses:Foodstuffs 47.61 Cash 50.25 When you implement VAT / BAS in GnuCash, please don't do it the terrible way Quicken 2000 does it by making split-transactions, as showed here. This makes everything very complex nad difficult to handle. Especially ifyou have transactions or an whole account that _may_ be accepted by the tax office, but you're not sure of it. I prefer the folliging way: Date Item PriceTaxKey 12.04.2001Copy-Pater 500 sheets $5.0016% 12.04.2001Snacks$100.0 - 12.04.2001Newspaper $2.0 7% 12.04.2001MobilePhone $300.0 Default Every Account now has a DEFAULT Percentace, that you can access by Default. This is default for every transaction. However, you are able to change the tax Key for every transaction. If you now see: The financial office will not accept my computer newspapers, simply change the default value of that account. The most important thing is, that you don't make split transactions, but just add a tax key to every transaction, that can easily be changed. The method you describe may be more convenient, but it doesn't meet the Australian government requirements for GST record keeping, for one thing. You can automate the process of recording GST/VAT to remove some of the overhead of doing split transactions (for instance, attaching a tax key to an account, which indicates that transactions to that account should have a GST component, and calculates the numbers for the split transaction), but split transactions *are* the correct way of handling things. Anything else is a hack. -- Robert Merkel [EMAIL PROTECTED] Go You Big Red Fire Engine -- Unknown Audience Member at Adam Hills standup gig ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Balance Sheet report
On Thu, 10 May 2001 14:55:07 Linas Vepstas wrote: Found a bug in balance sheet report, Christian, is this yours? When I back-date a report, and select 'nearest price', it doesn't seem to actually use the nearest price. It seems to always use the latest price ... Maybe this is a price-db query bug?? The balance sheet code was mine (with lots of stuff based on Christian's work) and the pricedb stuff was rlb's, IIRC. I'll try and figure out what's going on. . . -- Robert Merkel [EMAIL PROTECTED] Go You Big Red Fire Engine -- Unknown Audience Member at Adam Hills standup gig ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: further plans with guppi, bonobo?
On Sun, 06 May 2001 18:00:33 Dave Peticolas wrote: Christian Stimming writes: Bill Gribble will know more, but as I recall the libguppitank interface was already in existance when we decided to use guppi. I don't think it was created just for gnucash, but I'm not sure if any other apps use it. Basically, I think we chose it because it was really simple to use, there really wasn't a lot of discussion. If using the main interface would give us enough good features then I don't see why we couldn't do that in the next development cycle. I think this is definitely worth examining. Guppitank *is* simple, but is rather constricting. -- Robert Merkel [EMAIL PROTECTED] Go You Big Red Fire Engine -- Unknown Audience Member at Adam Hills standup gig ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Gnucash 1.5.6 Python
On Sat, 28 Apr 2001 13:13:22 Nathan A. Smith wrote: Hi, I have been trying to run the latest gnucash, but when I do I get the following errors: Could not find platform independent libraries prefix Consider setting $PYTHONHOME to prefix[:exec_prefix] 'import site' failed; use -v for traceback Fatal Python error: couldn't import os Aborted (core dumped) What does this mean? And how do I fix it? I could assign PYTHONHOME to /usr/lib/python2.1/ and that gets rid of the first 2 lines. But what does the rest mean? Thanks This appears to be a problem with your guppi installation - no other part of GnuCash uses python (and GnuCash doesn't use guppi's python interface anyway). If you built guppi yourself, and only use it for gnucash, you could try building guppi without python support (use the --disable-python configuration option). By the way, that has to be the coolest login I've seen :-) -- Robert Merkel [EMAIL PROTECTED] Go You Big Red Fire Engine -- Unknown Audience Member at Adam Hills standup gig ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
we forgot something
Christian Stimming writes: -BEGIN PGP SIGNED MESSAGE- Hi goonie, we forgot another case. If the user chooses a small display-depth so that children accounts are not shown, then what balance should the parent-account show? Ok, given accounts Rob's Liabilities $500 Credit Card $10 Card1$60 Card2$30 total liabilities are $600. Say display-depth==2. With the proposed new options we would have e.g. report1 Rob's Liabilities Credit Card $100 Total Rob's Liabilities $600 /report1 or report2 Rob's Liabilities $500 Credit Card $100 Total Rob's Liabilities $600 /report2 with show-parent-balances?==#f for report1 and ==#t for report2, and without the Total line if show-parent-totals?==#t. Currently we also have the do-subtot? option (which I never really understood, just carried over as a legacy from the balance-and-pnl.scm), which, if #f, would swith the balance for "Credit Card" from $100 to $10. Do we want that at all? Perhaps there might be cases when that's useful. Anyway I can't think of any and I would rather propose the throw out the current do-subtot? completely. If, in the example, the user wants to see the "Credit Card $10", she would have to increase the display-depth and set show-parent-totals?==#t. What do you think? I think you're quite right. Robert Merkel [EMAIL PROTECTED] telsa I left my client on #gtk+ overnight and there was nothing in scrollback at all except quit/rejoins. bighead telsa: well its been that for, I think 3 days now (ever since started coming back on IRC) telsa Clearly they are busy implementing telepathy, and dog-fooding it. :) ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
borked gnc_numeric_mul
There's something screwy happening in in gnc:numeric-mul. Here's a snippet of code, and the results out of the gnc-warn . . . (let . . . ;;; stuff . . . ;;; (price (gnc:price-get-value (gnc:pricedb-lookup-nearest-in-time pricedb commodity currency to-date))) (value-num (gnc:numeric-mul units price GNC-DENOM-AUTO GNC-RND-ROUND)) (dummy (begin (gnc:warn "price " price) (gnc:warn "units " units) (gnc:warn "value-num" value-num))) --- gnucash: [W] "price "#gnc-numeric num: 0 denom: 1 gnucash: [W] "units "#gnc-numeric num: 100 denom: 1 gnucash: [W] "value-num"#gnc-numeric num: 0 denom: 0 What's going on? Am I misusing gnc:numeric-mul, or is there a bug? Robert Merkel [EMAIL PROTECTED] telsa I left my client on #gtk+ overnight and there was nothing in scrollback at all except quit/rejoins. bighead telsa: well its been that for, I think 3 days now (ever since started coming back on IRC) telsa Clearly they are busy implementing telepathy, and dog-fooding it. :) ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: reports
[EMAIL PROTECTED] writes: I'd like to see 'invoice' added as a report type. The way I envision it, its almost identical to 'transaction report', except that the visual layout resembles an invoice. The adressee would either be typed in by hand, or maybe pulled out of the account notes field. I know that this is very far from 'perfect', but it serves two purposes: 1) it whets the apetite and interest for more/better; and we need something that will stir the interest of the masses. 2) its is usable for small jobs, e.g. a non-for-profit that prints one invoice a week. Hmm. Let me think about that one. - what's the difference between 'register report' and 'transaction report', and the 'accounts-payable' report? These seem to be the same thing to me ... ??? The concept behind a 'register report' is that you can click a button on a register and a report containing those transactions will be displayed. It is closely related to the transaction report, but some of the subtotalling/categorization that the transaction report can do are not possible there. Accounts payable, I suppose, is a transaction report of a certain set of liability trnasactions. what's the difference between 'account summary', 'balance sheet', 'net worth', and 'portfolio'? These sound like they're all the same report to me ... "Account summary" is a list of the values in all accounts. As I understood things, "net worth" and "balance sheet" are different names for the same thing. Dave, if you could comment that would be good. Portfolio is a list of your stocks, mutual funds, etc, but including ROI calculations, I think. --- instead of 'investment income', we should proabably do something that shows unrealized gains as well: I want to see the changes in price of my stock, not just the total dividends paid out. (maybe that's the 'portfolio' report?) Agreed. Robert Merkel [EMAIL PROTECTED] telsa I left my client on #gtk+ overnight and there was nothing in scrollback at all except quit/rejoins. bighead telsa: well its been that for, I think 3 days now (ever since started coming back on IRC) telsa Clearly they are busy implementing telepathy, and dog-fooding it. :) ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Stacked barcharts?
Guppi supports them (though I'm not sure whether guppitank does), but it doesn't seem like we do. I was thinking that they'd be a kind of useful way to present income/expense data (ie each slice of the bar representing a different expense account). What do you think? Robert Merkel [EMAIL PROTECTED] telsa I left my client on #gtk+ overnight and there was nothing in scrollback at all except quit/rejoins. bighead telsa: well its been that for, I think 3 days now (ever since started coming back on IRC) telsa Clearly they are busy implementing telepathy, and dog-fooding it. :) ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Problem after installation
[EMAIL PROTECTED] writes: I am facing a similar situation as Markus. I was using version 1.4.3 while Suse 7.0 was installed. Recently I upgraded to Suse 7.1, gnucash 1.4.3 still worked fine. Problems started when I discovered that later versions of gnucash were available. In the beginning I was not aware that one was already on the Suse CDs. I have to confess that I can no longer keep track of the the things I tried - several RPMs, different versions of gwrap and guile, I even tried to compile stuff. I currently again see 'undefined symbol: qt_error' from libguile. However I can see that libqthreads exists on my system. A version of guile 1.4 I could not find for Suse 7.1, so I downloaded the source, but am not able to run make without errors. One problem you may have is that g-wrap must be compiled against the *same* version of guile as gnucash. If possible, try and get your guile and g-wrap from the same source. If SuSE includes a version of g-wrap, guile and gnucash on your CD, stick with that. Can I put out another request to our user community to build a set of SuSE 7.x RPM's of gnucash and g-wrap, and possibly even send them to Dave for inclusion on the FTP site? Robert Merkel [EMAIL PROTECTED] telsa I left my client on #gtk+ overnight and there was nothing in scrollback at all except quit/rejoins. bighead telsa: well its been that for, I think 3 days now (ever since started coming back on IRC) telsa Clearly they are busy implementing telepathy, and dog-fooding it. :) ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Detecting shared library problems
Ben Stanley writes: The bane of a GNUCash user's life seems to be getting all the shared libraries installed - and learning what a shared library is etc. One would hope that rpm and other packaging systems would look after this for us, but a recent posting to the gnucash-users list would seem to indicate that this is a continuing problem. You might notice that we never hear of problems from Debian users trying to install the Debian packages. That's because Debian *does* have this problem solved. Debian dependancies are package rather than file-based, and the Debian package management front-ends automatically pull in required packages. However, seeing the world isn't going to stop using RPM-based systems with inadequate package management tools overnight, anything to reduce the hassles they face and we regularly deal with would be good. I have a suggestion to remedy this problem. The error must be able to be trapped somehow. When the error occurs, if we could print out a message pointing to a local file and perhaps a URL (with identical contents) which explains the problem and what to do about it, and has links to pages with explanations particular to each OS / packaging system. Perhaps these explanations already exist in the form of a HOWTO somewhere? Or perhaps Robert Merkel's recent post "Problem after installation" could be used as a starting point. Why not simply modify the dynamic linker to print more helpful error messages? That would be relatively simple and would be a substantial improvement. Each distribution could have their own error message. I have recently found that I am able to type a library file name into http://www.rpmfind.net, and it will give me a list of packages which provide it. I just have to find the one for my OS, and hope that it's on my CDs so I don't have to download it :-). Unfortunately it doesn't solve the problem of long dependency chains, but I have been able to find out that library X is supplied by package Y without having to have magical knowledge... I'm not trying to start a distro flamewar (all of the disributions have their good points), but you might want to have a look at Debian. You'll never have to worry about a dependancy chain again :) Robert Merkel [EMAIL PROTECTED] telsa I left my client on #gtk+ overnight and there was nothing in scrollback at all except quit/rejoins. bighead telsa: well its been that for, I think 3 days now (ever since started coming back on IRC) telsa Clearly they are busy implementing telepathy, and dog-fooding it. :) ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Detecting shared library problems
Derek Atkins writes: Robert Graham Merkel [EMAIL PROTECTED] writes: You might notice that we never hear of problems from Debian users trying to install the Debian packages. That's because Debian *does* have this problem solved. Debian dependancies are package rather than file-based, and the Debian package management front-ends automatically pull in required packages. Huh? RedHat package dependencies are both package and file based dependencies. Only the automatic dependencies are file-based. The packager, however, can supply a dependency on a particular package version. The only time this is really necessary is when you have shared libraries that have the same SO-number but are incomptabile. Thanks for the correction. Debian can do package-based library dependancies automatically, meaning there's never any problem figuring out which package you need to install a library, and allowing Debian's package front ends to go and easily grab all the dependancies required to install a package. Robert Merkel [EMAIL PROTECTED] telsa I left my client on #gtk+ overnight and there was nothing in scrollback at all except quit/rejoins. bighead telsa: well its been that for, I think 3 days now (ever since started coming back on IRC) telsa Clearly they are busy implementing telepathy, and dog-fooding it. :) ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
table row styles
Bill, I'm just trying to get my head around the table style code, and I'm not sure how the API appears to work matches up with what I want to do. As you anticipated a while ago, I want set different rows different colours (heading rows different to subheading rows, alternating colors for each split etc. Now, to do this, I have to set add an attribute bgcolour=#f0, for example to a particular row's style. However, it appears that to set a style for a particular row, you have to know exactly what row number you're presently at. There isn't a "set the last row you added's style" or something similar, is there? Robert Merkel [EMAIL PROTECTED] telsa I left my client on #gtk+ overnight and there was nothing in scrollback at all except quit/rejoins. bighead telsa: well its been that for, I think 3 days now (ever since started coming back on IRC) telsa Clearly they are busy implementing telepathy, and dog-fooding it. :) ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
proposed imaging arch
Bakki Kudva writes: Just a quick note to put down my recent thoughts on image enabling gnucash. I made a diagram with Gnu Dia and have attached it. Still at a high leve conceptual stage. My thoughts are to keep mods to the gnc tree to an absolute minimum (so I don't have to dig too deep in gnc :) and write a quick and dirty back end and a Gui front end which can talk to gnc via named pipes. The idea here is that the doc-organizer services to any app who needs it (may be mp3 or jpeg album). I thought a name for this might be "gnu electronic organizer" (GEORGe). May even have its own cvs? Before just using named pipes as your IPC solution, you might want to do some digging through the gnucash mail archives. We have had substantial amounts of debate on the issue . . . Robert Merkel [EMAIL PROTECTED] telsa I left my client on #gtk+ overnight and there was nothing in scrollback at all except quit/rejoins. bighead telsa: well its been that for, I think 3 days now (ever since started coming back on IRC) telsa Clearly they are busy implementing telepathy, and dog-fooding it. :) ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Gnucash password protection and encryption
[EMAIL PROTECTED] writes: Hi, Sounds like not a bad idea, you should pursue this on the [EMAIL PROTECTED] mailing list. --linas It's been rumoured that Booster said: Hello, I am using Gnucash regularly, its really great. But I have one problem, security. Could you please add an option to protect the saved files with a password, or better, call gnupg to encrypt the files when saving them ? And then extract them when loading ? What do you thing of that ? Thanks very much for your great work. CU Booster While this might sound like a good idea, it has some problems which make the improved security somewhat illusory. The following thread in the mail archives provides a good argument for *not* providing such a facility from within gnucash: http://www.gnumatic.com/pipermail/gnucash-devel/2000-September/000765.html Note in particular the suggestion to use an encrypted filesystem like CFS instead. Robert Merkel [EMAIL PROTECTED] telsa I left my client on #gtk+ overnight and there was nothing in scrollback at all except quit/rejoins. bighead telsa: well its been that for, I think 3 days now (ever since started coming back on IRC) telsa Clearly they are busy implementing telepathy, and dog-fooding it. :) ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: etags crashes, ctags not
Darryl Okahata writes: Christian Stimming [EMAIL PROTECTED] wrote: On Tuesday 27 February 2001 10:59, James LewisMoss wrote: etags != ctags ctags produces a vi tags file. etags produces an emacs tags file. I don't agree. For that matter, why is gnucash even trying to use either? Some people don't have ctags or etags, and, has been pointed out, may have buggy implementations. If some programmer wants to use ctags or etags, they can manually use them. It's not difficult, and running ctags/etags just unnecessarily slows down the build process. I can't speak for anyone else, but I think having a tags file is very useful, and IIRC it's a very small part of the time required to do the build. By the way, what's better about cscope? Robert Merkel [EMAIL PROTECTED] telsa I left my client on #gtk+ overnight and there was nothing in scrollback at all except quit/rejoins. bighead telsa: well its been that for, I think 3 days now (ever since started coming back on IRC) telsa Clearly they are busy implementing telepathy, and dog-fooding it. :) ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Gnucash from CVS goes into infinite loop
Derek Atkins writes: I was trying to create a new account for some stock. When I tried to add the new stock, I decided to ask for "help", and this is when Gnucash went into an error loop. I did the following: o Right-click in the main window o Select "New Account" o Select account-type "stock" o click on the "Select" button on the 'Security:' line o click "New..." o click "? Help" Gnucash will spew the following errors ad nauseum. I can't reproduce this one, but it looks like it's a gtkhtml problem. Have you updated your gtkhtml installation, or any of the libraries it depends on, recently? Robert Merkel [EMAIL PROTECTED] telsa I left my client on #gtk+ overnight and there was nothing in scrollback at all except quit/rejoins. bighead telsa: well its been that for, I think 3 days now (ever since started coming back on IRC) telsa Clearly they are busy implementing telepathy, and dog-fooding it. :) ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Improving report performance
Bill, It appears that the new report-generation code appends new html elements to the end of scheme lists. This is fine for short reports, but it's obviously O(n^2) and thus it seems like it's a real performance bottleneck for the transaction report, which can generate very large html tables. There are several ways we could get around this I can forsee: replace the lists with a vector structure and use the "if it gets full, double the size" trick, keep a reference to the end of the list around and update that destructively, or even just store things in reverse order and reverse things in the list before rendering the particular element. What do you think? Robert Merkel [EMAIL PROTECTED] telsa I left my client on #gtk+ overnight and there was nothing in scrollback at all except quit/rejoins. bighead telsa: well its been that for, I think 3 days now (ever since started coming back on IRC) telsa Clearly they are busy implementing telepathy, and dog-fooding it. :) ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
libguile.so.9 trouble
Olaf Marc Zanger writes: hi there, on my suse 7.0 system with suse-gnucash 1.4.9 with the rpmfind guile-1.3-7.i386.rpm installed i get the following error message maxwest@sino:~ : error in loading shared libraries: libguile.so.9: cannot open shared object file: No such file or directory with the suseRPM guile-1.3.4-133.i386.rpm installed i get the following error message - maxwest@sino:~ gnucash: error in loading shared libraries: /usr/lib/libguile.so.9: undefined symbol: qt_error a locate libguile.so --- maxwest@sino:~ locate libguile.so /usr/i486-linux-libc5/lib/libguile.so /usr/i486-linux-libc5/lib/libguile.so.2 /usr/i486-linux-libc5/lib/libguile.so.2.0.0 /usr/lib/libguile.so /usr/lib/libguile.so.6 /usr/lib/libguile.so.6.0.0 Neither guile 1.3 nor 1.3.4 provides libguile6. Guile 1.4 does. For some reason, it appears that whomever built the SuSE rpm built against guile 1.4 (and libguile.so.9), but many SuSE users have an earlier version. If you can find a working guile 1.4 RPM for SuSE, install that and your problems should go away. Otherwise, the person who built the SuSE package really should rebuild for guile 1.3.4. Could whomever that is please comment? i found all other stuff that should be installed with other locate's if i want to install gnucash 1.5.3 on the suse under yast it says --- can't get PREIN for gnucash-1.5.3.rpm Unsure (I'm not an expert on RPM) but itappears that the 1.5.3 RPM is either corrupted (which you can check by downloading it again), or is built using a more recent RPM. 1.5.3 is a *development* version, BTW. Robert Merkel [EMAIL PROTECTED] telsa I left my client on #gtk+ overnight and there was nothing in scrollback at all except quit/rejoins. bighead telsa: well its been that for, I think 3 days now (ever since started coming back on IRC) telsa Clearly they are busy implementing telepathy, and dog-fooding it. :) ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Image enabling gnucash?
Bakki Kudva writes: teri wrote: In its current state OCR seems to work only in very controlled situations. eg. a warranty return card which you have control over and you force the user to write into boxes, or neatly typed paper documents which law firms use to do full text OCR and indexing etc. However free form OCR from various qualities of underlying images is error prone and the fix non-trivial. Even in production environments OCR finds use only in some apps. I am afraid that the average home user has such a wide variety of receipts and paperwork that you'd have to manually check OCR results anyhow. You wouldn't want $80.00 entered as $8000 from a poor original. Also some times the receipts don't have ALL the information. You'd have to deduce where you bought something based on your own memory since the cash register receipt may not have a merchant name or anything on it. Also, there isn't any open-source OCR software available AFAIK, and it would be most preferable (both for technical and philosophical reasons) to base this system completely around open source, rather than have a key component proprietary. If you *are* looking for a challenging project to make your name, open-source OCR is probably a good one :) Robert Merkel [EMAIL PROTECTED] "We can build a better product than Linux" - Jim Allchin, chief Windows Technologist, Microsoft Corporation. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: profit/loss with mutual funds
[EMAIL PROTECTED] writes: It's been rumoured that Jason Rennie said: [EMAIL PROTECTED] said: What way is a profit or loss calculated; should be (total_amount * current_price) - sum_t(value(t)), that is (current value of account - money spent to buy the current amount). And since this contains re-investments the total profit/loss is wrong. Ah, yes. The current version of GNUCash doesn't seem to have any way to calculate profit correctly. The engine has C code for a 'fifo' that would handle this correctly, However, none of the reports currently use this, and I'm not sure what that would take. (old gnucash-1.2 used to do this, but it fell into disrepair). The fifo does the right thing for reinvestments etc, adding subtracting the purchase prices and quantities when they were made, and correctly tracking the remainder. I'm not sure, there may be a plan to re-implement the fifo in scheme. There is a plan to reimplement this. Robert Merkel [EMAIL PROTECTED] "We can build a better product than Linux" - Jim Allchin, chief Windows Technologist, Microsoft Corporation. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
KDE personal finance app soon to be previewed
Looks interesting, but strictly personal finance, and closed source. http://www.thekompany.com/products/kapital/ Robert Merkel [EMAIL PROTECTED] "We can build a better product than Linux" - Jim Allchin, chief Windows Technologist, Microsoft Corporation. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
apt-get wants to remove gnucash!?
Jonathan David Wheelhouse writes: Hi Already sent this to debian-user but didn't get any really helpful responses. Needless to say I _don't_ want gnucash removed but the following seems to be a mistake in dependencies. I've cut other bits out that seem to be irrelevant. apt-get dist-upgrade says The following packages will be REMOVED: gnucash guile1.3 libguile6 libguile6-slib libguile9-dev libguppi-dev dselect reveals gnucash depends on guile1.3 ... gnucash depends on libguile9 (= 1.4-6) guile1.3 depends on libguile6 libguile9 conflicts with libguile6 Does anyone have any ideas? We were just discussing this in the IRC channel. Rob Browning (rlb) is the guile maintainer, and for various good reasons he has removed libguile6 from the distribution, to be replaced with libguile9. gnucash, and any other packages depending on libguile6, need to be recompiled against libguile9. I have cc'd this to the gnucash debian maintainer to inform him of the problem, I can also file a bug or do an NMU (non-maintainer upload of a recompiled version) if he wishes. Robert Merkel [EMAIL PROTECTED] "We are excited and optimistic about its usage going forward and, yes, we can teach penguins the military close-order drill", Mark Norton, US Department of Defense. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
apt-get wants to remove gnucash!?
Robert Graham Merkel writes: Jonathan David Wheelhouse writes: Hi Already sent this to debian-user but didn't get any really helpful responses. Needless to say I _don't_ want gnucash removed but the following seems to be a mistake in dependencies. I've cut other bits out that seem to be irrelevant. apt-get dist-upgrade says The following packages will be REMOVED: gnucash guile1.3 libguile6 libguile6-slib libguile9-dev libguppi-dev dselect reveals gnucash depends on guile1.3 ... gnucash depends on libguile9 (= 1.4-6) guile1.3 depends on libguile6 libguile9 conflicts with libguile6 Does anyone have any ideas? Hang on, my brain is rotting here. The guile1.3 dependancy is wrong - it should be guile1.4, or better still taken out entirely (guile is needed for the build process, but only libguile9 is needed to *run* gnucash). Robert Merkel [EMAIL PROTECTED] "We are excited and optimistic about its usage going forward and, yes, we can teach penguins the military close-order drill", Mark Norton, US Department of Defense. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: simplifying memory management in panes
Bill Gribble writes: On Fri, Feb 02, 2001 at 02:38:17PM +1100, Robert Graham Merkel wrote: However, if we are to have some reasonable hope of saving/restoring state (not to mention the popup menu issues) we can't just have arbitrary GtkWidgets put in panes, and at the moment gnc_report_windows allow us to do just about everything we want in a pane. The save/restore problem is a real one. While I think your solution may be fine, keep in mind that the save/restore problem doesn't require anything more than special treatment for report-windows at save/restore time, i.e. it says nothing about the general relationship between panes and report windows. The popup menu issues I think can be managed at content-selection time (i.e. report window creation time) in the same way they are now... you pass in some more args to the report window. One of my main motivations here is that there's a real problem (IMO) with the embedded mainwindow -- my problem, not yours. I don't know how to make gtkhtml behave WRT resizes, and to me that's a showstopper. That might change, but it's a good enough reason for me to say we should have first-class support for mainwindows in panes from the start, just in case. OK, I'll buy that. How much flexibility do you want? Can I restrict myself to just gtkhtml and mainwindows, or do you want to keep on going more general again? If we're going to do that, what we might need to do is create a new class of GtkWidget with some special operations we can do, like "here's a popup menu, attach this to yourself in some intelligent way". Is this what you'd like to do? Robert Merkel [EMAIL PROTECTED] "We are excited and optimistic about its usage going forward and, yes, we can teach penguins the military close-order drill", Mark Norton, US Department of Defense. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
simplifying memory management in panes
WRT our discussions on simplifying panes by replacing the gnc_report_window * member of the gnc_pane structure with a GtkWidget *, I agree that this would be a win. However, if we are to have some reasonable hope of saving/restoring state (not to mention the popup menu issues) we can't just have arbitrary GtkWidgets put in panes, and at the moment gnc_report_windows allow us to do just about everything we want in a pane. Therefore, what I propose to do is make relatively small modifications to what I have now, replacing the gnc_report_window pointer with a gtkwidget * pointer, and letting the gtkwidget memory management do its thing. Instead of jumping through hoops to get at the gtkwidget from the gnc_report_window (as is currently the case), we'll jump through (considerably smaller) hoops to get the gnc_report_window from the widget. Finally, if we decide that we really do want to put arbitrary (or at least a broader range of) widgets into gnc_panes, making the transition will be easier. Does the above clear? Does it make sense? Robert Merkel [EMAIL PROTECTED] "We are excited and optimistic about its usage going forward and, yes, we can teach penguins the military close-order drill", Mark Norton, US Department of Defense. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Regression tests?
Dan Kegel writes: Could something similar be done for gnucash? Would it help make crash bugs less likely? One of the problems with that is that the majority of crashes seem to come from GUI code. Writing test scripts for a GUI is rather more difficult than writing them for server code. It's probably something that gnome is going to have to look at, though - a testing framework to allow scripts to operate GUI's would not be a bad thing. Robert Merkel [EMAIL PROTECTED] "We are excited and optimistic about its usage going forward and, yes, we can teach penguins the military close-order drill", Mark Norton, US Department of Defense. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Regression tests?
Dan Kegel writes: That's interesting. So the crashes are usually in the C that handles the GUI, not in the C that handles the database or any of the Scheme? We get the occasional crash from all three, but the engine stuff is probably the most reliable, and also easiest to debug if it does crash. Reasons for this include: a) It's exclusively C, and doesn't use external libraries as much as the GUI stuff (it uses a bit of glib and the fileio uses libxml, but that's about it). b) The flow of control is much easier to follow in the engine than in the GUI code, which has callbacks flying all over the place. c) It's not filled with opaque GTK/GNOME types (opacity is great for *design*, but for *debugging* you really need to be able to figure out what's going on from the bottom up sometimes). d) Its interfaces are more precisely specified than anything else. Of course, my viewpoint is somewhat biased because I spend most of my time on GUI stuff rather than engine stuff. And is hand-coded C GUI code less safe than, say, stuff driven by a file output by libglade? Yes and no. Yes, glade code is probably safer than hand-coded stuff. However, glade only does part of the job for you, and in my experience so far, the bits that glade does for you tend to be the relatively easy bits anyway. It's where you've got widgets behaving dynamically where the fun begins, and in my limited experience glade is of very limited help in those situations. Robert Merkel [EMAIL PROTECTED] "We are excited and optimistic about its usage going forward and, yes, we can teach penguins the military close-order drill", Mark Norton, US Department of Defense. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
transaction-report.scm
Birger Retterstl Olaisen writes: I've made some modifications to the file share/gnucash/scm/report/transaction-report.scm to add the posibility to sort by account number. These modifications may perhaps not be well coded (it's my first attempt to code in sceme, so I don't know the style) but they work. The transaction report is just about to be pulled apart and rewritten in any case, so unfortunately your patch can't go in to the development version. However, we might be able to look at adding your code to the next 1.4.x release, if we make another one (1.4.x is getting to the "ancient" stage, and we are heading towards a 1.5.x code freeze in preparation for a 2.0 stable release in a couple months time hopefully). Thanks for your efforts though! We do appreciate it, but it does pay to check the development version to see whether your feature has already been added, or the underlying way of doing things has changed. Robert Merkel [EMAIL PROTECTED] "We are excited and optimistic about its usage going forward and, yes, we can teach penguins the military close-order drill", Mark Norton, US Department of Defense. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Looks Good
Alex J.P. writes: Hi All, Finally got the unstable version to compile and run. The initial look at the new register windows and the help system in one short word is WOW!!. It looks really good. (A few more WOWs like this and we are going to make a lot more waves than we are making now) It's long promised and considerably overdue, but I'm well on the way to a new visual "Wow!" factor. The main window is going to allow you to display multiple, resizable, reports for all your financial info, in multiple, savable configurations . . . :) For the benefit of the rest of the list, splits are now working beautifully, now all I have to do is squash the bugs on "nuke" :) Additionally, the ability to totally customize the layout apparently puts us one up on Quicken, who restrict you to a set of fixed layouts. Chalk one up to the good guys :) -- Robert Merkel [EMAIL PROTECTED] "We are excited and optimistic about its usage going forward and, yes, we can teach penguins the military close-order drill", Mark Norton, US Department of Defense. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: how to create nice HTML tables in reports?
Clark Jones writes: Christian Stimming wrote: [...] trtd colspan=2Assets/td.../tr trtd/tdtdCash/td.../tr trtd/tdtdChecking/td.../tr I think this solution looks a bit more sound than the rather ad-hoc Have a look at the development version, There's a bunch of table generation code in it that ALL reports are going to get converted to using. Robert Merkel [EMAIL PROTECTED] "We are excited and optimistic about its usage going forward and, yes, we can teach penguins the military close-order drill", Mark Norton, US Department of Defense. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: how to create nice HTML tables in reports?
Christian Stimming writes: -BEGIN PGP SIGNED MESSAGE- On Sunday 21 January 2001 13:09, Robert Graham Merkel wrote: Have a look at the development version, There's a bunch of table generation code in it that ALL reports are going to get converted to using. I did have a look at the development version. The existence of table generation code is good, but it doesn't answer any of my questions. The point is, that as a report writer, you don't worry about the details of how the table gets rendered. Just use the table generation functions. If it turns out that these aren't flexible enough to give you layout that you need, then we have two discussions to have: a) What facilities does gtkhtml offer to display these reports appropriately? b) How should we make those facilities available through the table-generation code? Robert Merkel [EMAIL PROTECTED] "We are excited and optimistic about its usage going forward and, yes, we can teach penguins the military close-order drill", Mark Norton, US Department of Defense. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
gnome-print
Jonathan David Wheelhouse writes: Hi First, thanks for a great app; I use it daily (and drive my wife nuts asking for receipts after she's done the shopping). I'm glad you like it! I'm a programmer and am interested in hacking on gnucash (although I have a mainframe background (Cobol, JCL, database stuff) so C, automake, make, autoconf, etc confuse me but I'm trying). Don't worry, automake etc confuse a lot of people (macro languages are a pain), but for somebody who copes with JCL they should be masterable :) If you check the list archives, you'll see that there's been a fair bit of stuff about database backends recently, so your experience would probably be quite valuable. Anyhow, I recently checked out the development source from CVS and attempted to do a autogen.sh. After fixing up missing libraries (I run Debian unstable) I got the following error: checking for GNOME-PRINT - version = 0.1.0... no *** Could not run GNOME-PRINT test program, checking why... *** The test program failed to compile or link. See the file config.log for the *** exact error that occured. This usually means GNOME-PRINT was incorrectly installed *** or that you have moved GNOME-PRINT since it was installed. In the latter case, you *** may want to edit the gnome-config script: /usr/bin/gnome-config configure: error: GNOME-PRINT not found A quick search on the Debian site reveals that gnome-print is there as part of the stable distribution. However, I run pure Debian unstable (ie. no Helix gnome etc.) and the closest thing it's got is libgnomeprint-dev. In Debian (and most Linux distributions), the files necessary to *run* a program compiled against a shared library are stored in a libfoo package, and the header files and so on are in a libfoo-dev package. However, Linux supports you simultaneously installing different versions of shared libraries - for example trell /lib :ls -l libc.so* lrwxrwxrwx1 root root 14 Jul 14 2000 libc.so.5 - libc.so.5.4.46 -rw-r--r--1 root root 586720 Feb 9 1999 libc.so.5.4.46 lrwxrwxrwx1 root root 11 Jan 9 17:58 libc.so.6 - libc-2.2.so trell /lib : Here, libc.so.5 and libc.so.6 happily coexist (no DLL hell for Linux :). However, for *compiling* programs, it's a different story. You (almost always) can have one version of the "development files" (header files etc.) for a library for a particular machine (anything I compile on my machine, for instance, is compiled and libc.so.6). Anyway, the upshot of all this is that Debian libraries are often packaged in to several packages as follows: libfoomajor-version libfoo-dev so as to allow the continued installation of older versions of libfoo for running older programs. The specific packages you need for debian are libgnomeprint11 (containing the latest libraries) libgnomeprint-dev (containing the latest headers). note that if you install libgnomeprint-dev with dselect or apt-get, the debian package tools will automatically fetch and install the appropriate libgnomeprintmajor-version package for you. Anyway, after all that, I think that should help you compile the latest development version of gnucash. Make sure you have the very latest g-wrap, as g-wrap and gnucash development are very closely interwoven. Good luck! Robert Merkel [EMAIL PROTECTED] "We are excited and optimistic about its usage going forward and, yes, we can teach penguins the military close-order drill", Mark Norton, US Department of Defense. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
embedded gnc_report_windows and panes
I should have realised this earlier, but your report window code shoves the options dialog in a gtk_paned container even when the report is itself embedded in another container (in the case of panes, in another gtk_paned). Do you think it might be better to have a seperate options dialog for this case? Can I go ahead and make the changes necessary without interfering with plans for the report window to be used elsewhere? Robert Merkel [EMAIL PROTECTED] "We are excited and optimistic about its usage going forward and, yes, we can teach penguins the military close-order drill", Mark Norton, US Department of Defense. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
attaching callbacks (was Re: arguments to -render . . .)
Bill Gribble writes: On Tue, Jan 16, 2001 at 03:53:49PM +1100, Robert Graham Merkel wrote: Hey grib, I'm almost to the point of doing useful things with panes (finally). One of the final things that needs to be in place is a renderer along the lines of the gnc:html-*foo*-render that are required to display guppi charts in reports. I'm skeptical that this is what you need. The html-*-render functions are strictly for block-level structural elements of HTML, and I don't think you are defining any new kinds of block level HTML elements, are you? Tell me more about what you are doing. Oh, wait.. are you talking about a renderer for the mainwindow account tree? That makes sense. Correct. Sorry I wasn't more explicit. To answer your question, the arguments to the html-foo-render functions are (1) the object to render and (2) the HTML document to render into. You need to have the document in order to get inherited style infomation. ATM, the Guppi objects all ignore the style information since they are sort of a special case of HTML rendering, but in the future they might respect 'data style' (for example how many decimal digits to display in legends) or default colors or somesuch. yep, makes sense. I get suspicious in guile when I see functions with fewer or more arguments than they use - it tends to suggest there's something going on I don't understand :-) To add a new type of html object, you need to do two things: basically cut-n-paste html-piechart.scm with appropriate changes for the new object type, then patch the 'cond' statement at html-document.scm:341 to add the new class. This is a bassackwards attempt to get some sort of genericity... with a real object system there would be an inheritance relationship between html-object and the various html-foo classes. Yep. Maybe in the future GOOPS will be the go for this sort of thing. Hope this is clear. Let me know if it ain't. Yep. The only thing I need to figure out is "callbacks". Your example account-tree report doesn't mention them. I'm about to dig through the code to see if I can figure it out. Thanks for your help. Robert Merkel [EMAIL PROTECTED] "We are excited and optimistic about its usage going forward and, yes, we can teach penguins the military close-order drill", Mark Norton, US Department of Defense. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Bug Report - Saving Empty File Causes Crash
Christopher Browne writes: This is with a CVS checkout from last night of the latest and greatest. This is admittedly one of those pathological cases where the "dumb user" has _nothing to save_, so that trying to save the DB is a mite silly. Crashing is nonetheless an irritating result. Any crash is a serious bug. Somebody (RMS?) said something along the lines of "properly written software should never crash". While the development series isn't to that stage yet, we'd certainly like it to to be as uncrashable as possible before release. For one thing, instead of sending one email to the -devel list, it'll require 27 to people who don't bother to check ML archives or even buglists ;-) Anyway, I can confirm the crash. I'll have a quick look, as it's an opportunity to get familiar with the File IO code which I'm going to have to modify in a little while anyway. Robert Merkel [EMAIL PROTECTED] "We are excited and optimistic about its usage going forward and, yes, we can teach penguins the military close-order drill", Mark Norton, US Department of Defense. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
arguments to -render in HTML generator code
Hey grib, I'm almost to the point of doing useful things with panes (finally). One of the final things that needs to be in place is a renderer along the lines of the gnc:html-*foo*-render that are required to display guppi charts in reports. However, I'm not exactly clear on how these are supposed to work. For instance, what's the second argument "doc" to these render functions? Any help would be much appreciated. Robert Merkel [EMAIL PROTECTED] "We are excited and optimistic about its usage going forward and, yes, we can teach penguins the military close-order drill", Mark Norton, US Department of Defense. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: scripting language vs. developer community size
Ariel Rios writes: On Sun, 14 Jan 2001, Dan Kegel wrote: I'm sure this has been discussed a zillion times but I'd like to bring it up again: Requiring that all high-level Gnucash code be in Scheme might be restricting the number of developers able to contribute to it. Why? Here's a few quotes from the web in support of that theory (found by searching for "scheme learning curve"): I don't see why quoting some web posts can be a good reason. OK, here's the canonical reply to "why do we use scheme". The "core" developers (dave_p, rlb, grib etc.) all either love, or are at least comfortable with scheme. It works very nicely for our purposes. We've written a whole lot of code in it, and it's not going to go away. I personally dislike Perl, and while I'm not the arbiter of such things, I would be extremely wary of any new Perl code going into the main gnucash tree. In fact, it's pretty unlikely that code in languages other than C and Scheme will be added to the main tree in the forseeable future. As far as providing a perl interface for user scripts, maintaining one scripting language binding is hard enough. Maintaining a bunch of them is too difficult (and if anyone mentions SWIG's guile support we'll scream) and we have other priorities. There are two main alternatives, I suppose, if you want perl support. One is to work on getting/keeping the SWIG perl bindings up to date - there have been others who have shown interest in doing so, a quick check of the archives should reveal their email address. The second is to get g-wrap to support perl. Of course, g-wrap is written in scheme, and people who know scheme aren't really all that fussed about writing their scripts in scheme :-) Look, we realize that a lot of people are put off by scheme, but it really is a nice language once you get over the parentheses hurdle (and a good editor works wonders for that). Robert Merkel [EMAIL PROTECTED] "We are excited and optimistic about its usage going forward and, yes, we can teach penguins the military close-order drill", Mark Norton, US Department of Defense. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: microsoft gnucash
Linas Vepstas writes: FYI, just for grins, I had occasion to look over the web server logs recently, and couldn't not notice that folks at Microsoft like to look at our screenshots every now and then. Also, curiously, they seem very interested in our documentation for the QIF file format. Maybe they don't have any? Hmm. Maybe we should put up some more current ones. Then again, maybe we should keep them in suspense . . . As for QIF, the only time I'd *really* start to be concerned is if Intuit is looking at our QIF documentation. Then again, I'm not sure if the Intuit people ever documented it either ;-) Robert Merkel [EMAIL PROTECTED] "We are excited and optimistic about its usage going forward and, yes, we can teach penguins the military close-order drill", Mark Norton, US Department of Defense. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Mind if I modify report.scm to provide a different constructor?
To support saving reports (required for panes, amongst others) we really need to create report instances with options already specified, and thus a constructor that takes report options as an argument. Any problem with this? Robert Merkel [EMAIL PROTECTED] "We are excited and optimistic about its usage going forward and, yes, we can teach penguins the military close-order drill", Mark Norton, US Department of Defense. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
multiple report window bug
WRT the bug discussed on IRC where multiple report windows caused a crash in Redhat (with guile 1.3.4), I can confirm the bug is repeatable on Debian potato (also with guile 1.3.4). Fun fun fun for everyone to debug :/ Robert Merkel [EMAIL PROTECTED] "We are excited and optimistic about its usage going forward and, yes, we can teach penguins the military close-order drill", Mark Norton, US Department of Defense. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Saving pane layouts in .xac file
Rob, I'd like so save the pane layout as part of the .xac file, rather than have it as a seperate file or as a part of the .gnucash-auto file. As it's file metadata, rather than something that fits with a specific account, transaction, or split, it's not really suitable for putting in the existing kvp_frame system, AFAICT. How should I go about this? Robert Merkel [EMAIL PROTECTED] "We are excited and optimistic about its usage going forward and, yes, we can teach penguins the military close-order drill", Mark Norton, US Department of Defense. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: How do I get the top-level HTML widget from a gnc_report_window?
Bill Gribble writes: On Fri, Dec 29, 2000 at 01:56:45PM +1100, Robert Graham Merkel wrote: Bill, I'm busily working on the pane code, and I need to get the actual widget from a gnc_report_window and shove it in a container. How do I do so? You do it the other way 'round: pass it the container (must be a GtkContainer) as the argument to the gnc_report_window constructor. If you really need to do it the other way I can add the infrastructure, but ATM when you create the report window it gets realized and shown so it need to know where it's going in advance. Bill, if I split a pane, obviously I can either destroy the original gnc_report_window and create two new ones, or I can reparent one and create one new one. If possible, I'd prefer the latter option. I'm blocked on this, so I'll have a look at the code and see if I can add the infrastructure myself. Robert Merkel [EMAIL PROTECTED] "We are excited and optimistic about its usage going forward and, yes, we can teach penguins the military close-order drill", Mark Norton, US Department of Defense. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Interface to pass a popup menu to a gnc_report_window
Bill, I think we discussed before how I'd like to be able to pass a popup menu to a report_window. How difficult would this be to arrange? Robert Merkel [EMAIL PROTECTED] "We are excited and optimistic about its usage going forward and, yes, we can teach penguins the military close-order drill", Mark Norton, US Department of Defense. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
How do I get the top-level HTML widget from a gnc_report_window?
Bill, I'm busily working on the pane code, and I need to get the actual widget from a gnc_report_window and shove it in a container. How do I do so? Robert Merkel [EMAIL PROTECTED] "We are excited and optimistic about its usage going forward and, yes, we can teach penguins the military close-order drill", Mark Norton, US Department of Defense. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Support for casual users (was: Re: client-server)
Eugene Tyurin writes: snip Is this really something a casual user who wants to balance his checkbook and know how much he spends on beer can bear? Unless it's totally transparent to them, no. Basically, it may be that GnuCash, in the long term, has to split into two seperate products (still sharing large amounts of code and developers), one aimed at business users and supporting database backends and such complexities, and one aimed at home users and not involving them. Rest assured none of us wants to disenfranchise the single home user. Robert Merkel [EMAIL PROTECTED] "We are excited and optimistic about its usage going forward and, yes, we can teach penguins the military close-order drill", Mark Norton, US Department of Defense. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
test 2
-- rijweoprjwoiejrpoiwej Robert Merkel [EMAIL PROTECTED] "We are excited and optimistic about its usage going forward and, yes, we can teach penguins the military close-order drill", Mark Norton, US Department of Defense. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Hardwired path in src/guile/Makefile.am
The following code in latest CVS src/guile/Makefile.am is kinda machine-specific . . . FLAVOR=gnome guile -c \ '(set! %load-path (cons "/usr/local/opt/g-wrap/share/guile" %load-path)) \ (primitive-load "./gnc.gwp") \ (gw:generate-module "gnc")' CLEANFILES += gnc.h gnc.c gnc.html gnc-autogen.h How do you want to fix it?? Robert Merkel [EMAIL PROTECTED] "We are excited and optimistic about its usage going forward and, yes, we can teach penguins the military close-order drill", Mark Norton, US Department of Defense. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Financial library
Phillip J Shelton writes: Woud also having the date functions in this library be a good thing? On the face of it, that's not a bad idea. However, the gnumeric people to some extent have already had their date representation and functions decided for them (by the desire for Excel combatability), whereas we are free to do whatever we want in regards to representation, and we have some rather complex goals which will probably *require* a more complex representation. In summary, I'm certainly not opposed, but I don't know whether it's we have a natural match of requirements like we do for financial functions. Robert Merkel [EMAIL PROTECTED] "We are excited and optimistic about its usage going forward and, yes, we can teach penguins the military close-order drill", Mark Norton, US Department of Defense. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
RE: Financial library
Phillip Shelton writes: As gnucash is in C, should we look at seeing if it is ok to rewrite in C or just run with the gnumeric date functions? Or add another dependency? :-\ Um, I can't speak definitively but I think we'd all be extremely wary of adding dependancies to C++ libraries, or new perl ones for that matter. Robert Merkel [EMAIL PROTECTED] "We are excited and optimistic about its usage going forward and, yes, we can teach penguins the military close-order drill", Mark Norton, US Department of Defense. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: ROI discussion
Rob Browning writes: [EMAIL PROTECTED] (Bill Gribble) writes: jody suggested that the gnumeric folks might be receptive to an app-neutral refactoring of the financial stuff in gnumeric. If we can make a freestanding library from their code, we can share it with them and hopefully get some synergy out of it. PLUS I won't have to try to dust off all my pitiful math skills. [...] rgmerk and others, what think ye? Sounds like an excellent idea to me. I'm very much in favour. Robert Merkel [EMAIL PROTECTED] "We are excited and optimistic about its usage going forward and, yes, we can teach penguins the military close-order drill", Mark Norton, US Department of Defense. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: ROI discussion
Bill Gribble writes: On Fri, Dec 08, 2000 at 12:04:59PM +1100, Robert Graham Merkel wrote: Bill, you wanted some information about ROI calculation. All this stuff is all archived in the ML - read the thread starting at this URL: http://gnucash.org/gnucash-devel/June-2000/msg00409.php3 This calculations are slightly nontrivial, so sharing them with gnumeric if possible may not be a bad idea. Robert - we had talked about using the ROI report as a 'test case' for the complexity needed in the new report system. However, aside from a complicated number-crunch, there's really nothing interesting about the structure of the ROI report. I totally agree. The complex bit of this report is the number crunch. However, I think you might be underestimating the complexity of other reports which aren't as mathematically complex but the kinds of flexibility you require makes them more progammatically complex. It's the simplest possible case of a Query (to select the splits involved in the relevant cash flow), plus an algorithm (which crunches the splits into an ROI value) and a simple report that amounts to about a couple of sentences of text and maybe a table to show the splits in the cash flow. Well, depending on whether you want to do just one stock or summarise all stocks (you might want a table that does a calculation for each stock, then displays an overall result). So I'll say I'm encouraged about the possibility of an reporting-analysis library of moderate complexity :) I agree that getting the code for the actual IRR computation is a little bit tricky, though I'm pretty sure I have coded up a reasonable and simple library for representing and solving these kinds of equations ... I think it's in c++ though :( In any case, I'll see if I can find an implemented version to use. As numerical analysis problems go, it's not particularly tough, and of course it depends on how clever an equation solver (don't call it a root finder in discussions with an Australian, by the way) you want to implement. This kind of thing is probably even easier to play with in scheme than C, but I gather we'd prefer C at this point. Is this your view? Robert Merkel [EMAIL PROTECTED] "We are excited and optimistic about its usage going forward and, yes, we can teach penguins the military close-order drill", Mark Norton, US Department of Defense. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Financial library
I also agree that a shared financial library would be an excellent idea. Is there any other project that might get on board, or should we just get going and if we start producing something good other people can get involved as they see fit? Robert Merkel [EMAIL PROTECTED] "We are excited and optimistic about its usage going forward and, yes, we can teach penguins the military close-order drill", Mark Norton, US Department of Defense. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
ROI discussion
Bill, you wanted some information about ROI calculation. All this stuff is all archived in the ML - read the thread starting at this URL: http://gnucash.org/gnucash-devel/June-2000/msg00409.php3 This calculations are slightly nontrivial, so sharing them with gnumeric if possible may not be a bad idea. Robert Merkel [EMAIL PROTECTED] "We are excited and optimistic about its usage going forward and, yes, we can teach penguins the military close-order drill", Mark Norton, US Department of Defense. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Open project - data file obfuscator
Mike Sabin writes: I fall into the category of "wanting-to-help-but-lousy-at-C-and-scheme". Your idea is a good one. Python is about the only language i'm worth anything in. I will consider it for a few weeks. December is looking pretty hopeless, workload-wise. If you get a chance to work on it, that would be great. We'll see if anyone else is interested, and if so how to coordinate. As far as Python goes, I'm language-agnostic for this, but I think it's clear that a scripting language is the way to go. If you wrote it in scheme, you could use the g-wrap hooks to do the work of parsing and outputting for you. If you do it in another language, there's extra work, but we get an entirely independent implementation that can parse/export gnucash data files. Either way, it's a win. Just a general point which is really addressed to the lurkers in general, don't be afraid to give scheme a go. It's a little odd to those that have only programmed in conventional imperative languages, but once you get your head around it it's got some really nifty features (including being perhaps the most extensible and flexible language I have ever used). Robert Merkel [EMAIL PROTECTED] "We are excited and optimistic about its usage going forward and, yes, we can teach penguins the military close-order drill", Mark Norton, US Department of Defense. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Open project - data file obfuscator
Looking for a way to help gnucash, but your scheme and C is a little rusty? Want to learn some xml? Want to help speed up development? Want to build a tool that could be the building block for a bunch of other very nifty things? Well, have I got a project for YOU! Generally, one of the first steps to fixing a bug is being able to reliably reproduce it. Consequently, bug reports are often accompanied with a data file which can be used to reproduce the bug. However, gnucash users are understandably reluctant to provide this information to developers. I don't like divulging my financial records either. One approach to avoid this is something analagous to the C code "obfuscators" like opqcp and the like. The idea is simple - replace names of accounts, payees, and the like with meaningless text. However, it gets a little bit more complex than that. You don't want to simply replace each field text randomly. You'd want to replace each text in a consistent way - for instance, each instance of "Bloggs Inc." should be replaced with "Payee 01" or something similar. Similarly, sometimes amounts are important to demonstrate the bug, sometimes they aren't, so you'd probably want to think about providing the option to randomize amounts. Now, this program doesn't have to be part of gnucash - it can be (and probably) should be stand-alone, and doesn't have to be written in scheme. In fact, you might consider some of the xml parsing and generation tools available for Perl. If you get this working, you'll not only provide a useful tool in its own right, you'll have a working environment for people to write code to parse and output valid gnucash data files in Perl - a capability that will be *extremely* useful. So, all those lurkers out there - is there anybody that finds a project like this interesting?? Robert Merkel [EMAIL PROTECTED] "We are excited and optimistic about its usage going forward and, yes, we can teach penguins the military close-order drill", Mark Norton, US Department of Defense. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Performance improvement for xml loads (+comments)
Derek Atkins writes: That's still not a fair comparrison. I can go compress the old binary format, too. Let's compare apples to apples here and leave file compression out of it. You certainly can go and compress the old binary format, and it shrinks a file down to about 1/3rd the size of what a compressed new file looks like. However, the point remains that the released version isn't going to cause gnucash data files to explode in size - in fact for Joe User, the size of their data files is going to go down. Finally, I'd just like to make the point that while the XML format currently has some performance problems, it's here, and it largely works, it has features simply not possible to support with the old binary format, and will continue to play an important role as an import/export format when we start to use a database for the backend - unlike any new binary format which will be essentially a dead end. We can't go back to the old format, and I can't see how ripping out the work we've done and starting from scratch is an appropriate use of time. Robert Merkel [EMAIL PROTECTED] "We are excited and optimistic about its usage going forward and, yes, we can teach penguins the military close-order drill", Mark Norton, US Department of Defense. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Associating expense/income accounts with stocks continued
OK, we've continued discussing this on IRC, and it turns out that like
many things in life it's more complex than I first envisiaged.
Not only do we need to record which accounts contain transactions
related to a stock, for later tax reporting purposes we need to
differentiate between interest, dividends, short and long term
capital gains, and "other" on the income side, and commission and
"other" on the expense side.
Secondly, while a druid will probably be the way to go for account
entry, we'll still need a paned conventional dialog for account
editing.
Therefore, we need to build an interface that lets the user specify a
number of accounts, as well as specify the category of income
(expense) for each account selected.
The idea would probably be to have a conventional account tree on the
left, with a button with a right arrow and saying "add", which adds
the selected account to the left button. Next would be a two-column
alphabetically-ordered list display (we'll call this the "related"
list) of the accounts that have been
added to the "related" group. The second column lists which category
(interest, CG, dividend) the account is going to be placed under.
To the right of the related list is a clist which allows the user to
choose the category for the account selected in the "related" list.
I was initally proposing that the dialog should insist that at least
one expense and income account be specified, but I'm no longer
convinced that it is necessary. If people don't want to record income
and expenses for stocks, we don't need to insist.
As far as the back end is concerned, The API for storing/accessing this
information would be as follows:
/*
* account_list is a list of account *'s, all of which much be expense
* accounts
*/
typedef enum {GNC_TR_INC_MISC,
GNC_TR_INC_INTEREST,
GNC_TR_INC__DIVIDEND,
GNC_TR_INC_LT_CG,
GNC_TR_INC_ST_CG} GNCTrackingIncomeCategory;
typedef enum {GNC_TR_EXP_MISC,
GNC_TR_EXP_COMMISSION} GNCTrackingExpenseCategory;
/*
* account_list is a list of account *'s, all of which much be expense
* accounts. You can clear associations by setting account_list to NULL
*/
void gnc_tracking_associate_income_accounts(Account *stock_account,
GNCTrackingIncomeCategory category,
GList *account_list);
void gnc_tracking_asssociate_expense_account(Account *stock_account,
GNCTrackingExpenseCategory category,
GList *account_list);
/*
* returns a list of account *'s,
* returns null if no association specified
*/
GList *gnc_tracking_find_expense_accounts(Account *stock_account,
GNCTrackingExpenseCategory
category);
GList *gnc_tracking_find_income_accounts(Account *stock_account,
GNCTrackingIncomeCategory
category);
/* for ROI purposes we don't care about categories, these are "grab
all" for that purpose */
GList *gnc_tracking_find_all_expense_accounts(Account *stock_account);
GList *gnc_tracking_find_all_income_accounts(Account *stock_account);
/*
* reverse lookup - obviously returns a stock account (or NULL if none
* associated), and argument must be an income or expense account
*
Account *gnc_tracking_find_stock_account(Account *inc_or_expense_acc);
Note that this interface will need to be g-wrapped (with the new
g-wrap this shouldn't present a problem).
Implementation of backend: a frame with key "expense accounts"
would be created in each stock account, as would a frame "income
accounts". The value of these frame would
itself be another frame, containing keys for each category and each
value being a list of account GUIDs.
Income and expense accounts associated with a stock account would
would have a kvp associating "stock account" with the account GUID
for the stock account.
Comments invited.
Robert Merkel [EMAIL PROTECTED]
"We are excited and optimistic about its usage going
forward and, yes, we can teach penguins the military
close-order drill", Mark Norton, US Department of Defense.
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
tracking investment-related transactions
OK, one thing that we need to do for stock reporting is associate stock accounts with income and expense accounts containing (surprise surprise) income and expenses related to that stock. I propose to add turn the "account add/edit dialog" into a tabbed dialog. The first page would stay pretty much as is, with the removal of the "security" and "source for price quotes field. The next tab, entitled "investment settings" (or something more appropriate if anyone can think of something better), would have the "security" and "price quotes" field, as well as a new account-tree field "related accounts" where you would specify which account(s) are to be used to record expenses and incomes for that stock/mutual fund account. If, after the "OK" button is clicked, there is not at least one expense and one income account selected, the user will be asked whether they wish to create them. Account creation dialog(s) for the missing accounts, set to create either expense or income accounts, will be displayed. I thought about using druids for this, but there doesn't seem to need to be a fixed sequence. Thoughts? Robert Merkel [EMAIL PROTECTED] "We are excited and optimistic about its usage going forward and, yes, we can teach penguins the military close-order drill", Mark Norton, US Department of Defense. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Away Friday
I'm intending to be away Friday 1st through the morning of Sunday 3rd December. -- Robert Merkel [EMAIL PROTECTED] "We are excited and optimistic about its usage going forward and, yes, we can teach penguins the military close-order drill", Mark Norton, US Department of Defense. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Callback cleverness in window-main.c or just old cruft?
Is there something incredibly clever going on here that I'm not
understanding, or is this code just crufty:
src/gnome/window-main.c:
static void
gnc_account_cb(GNCMainWinAccountList *tree, Account *account, gpointer
data)
/* why the extra argument */
{
gboolean sensitive;
account = gnc_mainwin_account_list_get_current_account(tree);
sensitive = account != NULL;
gnc_account_set_sensititives(gnc_get_main_info(), sensitive);
}
void
mainWindow()
{
. . .
gtk_signal_connect(GTK_OBJECT(main_info-account_tree), "unselect_account",
GTK_SIGNAL_FUNC(gnc_account_cb), NULL);
/* cast required here because of it */
. . .
}
src/gnome/account-tree.c (gnc_account_tree_init):
account_tree_signals[ACTIVATE_ACCOUNT] =
gtk_signal_new("activate_account",
GTK_RUN_FIRST,
object_class-type,
GTK_SIGNAL_OFFSET(GNCAccountTreeClass,
activate_account),
gtk_marshal_NONE__POINTER,
GTK_TYPE_NONE, 1,
GTK_TYPE_POINTER);
Robert Merkel [EMAIL PROTECTED]
"We are excited and optimistic about its usage going
forward and, yes, we can teach penguins the military
close-order drill", Mark Norton, US Department of Defense.
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Tax report bug
I was kind of afraid something like this might happen!nbsp; If every time where a null string used to be returned, we now get a #f, this could cause a lot of bugs in numerous places. It would be better to fix the source of the problem, rather than the downstream problems it causes. Richard, I've been working with Rob Browning on g-wrap quite a lot lately, and perhaps I should explain the situation. G-wrap is still a program in flux, as indicated by its 1.0 version number. At the moment gnucash is the only widely-used program using g-wrap, but we hope that that will change once we get past 1.0. Once that point is reached the API will have to be largely set in stone, so any misfeatures will have to be faithfully retained. On this point, Rob is working hard to fix the API *now* rather than later, and the change to the string behaviour is an example of this. Therefore, it's not a "problem" in the sense that the change was unintended. It's a "problem" in the sense that the change breaks code dependent on the old behaviour, requiring somebody to fix it. I don't mind helping with that if you want. g-wrap will continue to change substantially for the next little while, before stabilising (I expect, but of course Rob B makes these decisions) for a 1.0 release in the next few months. I'm sorry that it had to be you that got caught by this, but, typically, we'd have to make twenty fixes to every one you'd have to make :-/ If you think this particular API change, or the way we are managing them, is inappropriate please feel free to discuss it with Rob B and I. Robert Merkel [EMAIL PROTECTED] "We are excited and optimistic about its usage going forward and, yes, we can teach penguins the military close-order drill", Mark Norton, US Department of Defense. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Tax report bug
Richard -Gilligan- Uschold writes: gnucash: latest CVS guile: 1.3.4 g-wrap: 0.9.12 Herbert. -- Herbert Thoma FhG-IIS A, Studio Department Am Weichselgarten3, 91058 Erlangen, Germany Phone: +49-9131-776-323 Fax: +49-9131-776-399 email: [EMAIL PROTECTED] www: http://www.iis.fhg.de/ ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel I see a possible problem, but, as I don't yet have the latest compiled, (missing dependencies) I can't check it out. The problem does not seem to exist on 1.5.2 or earlier 1.4.x versions. Could you add the line below marked with the "+" between existing lines 233 and 234, in file /usr/share/gnucash/scm/report/tax.scm, and let me know if it fixes the problem? (don't put in the "+"!) (let* ((notes (gnc:account-get-notes a)) + (notes (if notes notes "")) (key-start (string-search notes key 0)) Richard, I haven't confirmed it, but I think the problem is that the handling of null const-strings has changed in the latest g-wrap. I think a NULL const string on the C side is converted to scheme #f. Robert Merkel [EMAIL PROTECTED] "We are excited and optimistic about its usage going forward and, yes, we can teach penguins the military close-order drill", Mark Norton, US Department of Defense. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
#gnucash on irc.gnome.org
Linas, would you like to put something on the webpage about the #gnucash channel on irc.gnome.org? We've been using it quite a bit the past week or two, and I think it's working quite well. Robert Merkel [EMAIL PROTECTED] "We are excited and optimistic about its usage going forward and, yes, we can teach penguins the military close-order drill", Mark Norton, US Department of Defense. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
gnc-scheme URLs (was: printing problems)
Glen Ditchfield writes: On November 18, 2000 12:13 am, Robert Graham Merkel wrote: Bill Gribble writes: ... which makes the HTML look sort of like what Linas was hoping it would: iframe src="gnc-scheme:(scheme-func-to-spew-html)" Then maybe somebody could implement a kio_gnc_scheme I/O handler, and then konqueror and the rest of the KDE 2 tools could display could display this stuff too. That would be fine *except* that, if you saw the earlier part of Bill's email, you'll know that we probably intend to use gtkhtml's facilities to embed gtk objects within a web page. Konqueror is unlikely to support this ability - Qt objects maybe, gtk not likely :) Additionally, unless you were porting gnucash to Qt, why would you *want* to do this? This is an honest question, BTW, not a flame. On November 18, 2000 12:13 am, Robert Graham Merkel wrote: ... I think panes will be better. It's easier to provide a UI for configurability and we can probably lay things out a little more precisely. If anybody wants to disagree, however, feel free, and feel free *right now* before I do any more implementation :) HTML and CSS provide good enough layout for me. Yes, but you can't dynamically create new panes, merge them back together, and such with straight HTML. Robert Merkel [EMAIL PROTECTED] "We are excited and optimistic about its usage going forward and, yes, we can teach penguins the military close-order drill", Mark Norton, US Department of Defense. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: printing problems
Bill Gribble writes:
On Fri, Nov 17, 2000 at 10:25:46AM +1100, Robert Graham Merkel wrote:
snip
With suitable conventions for encoding the object's parameters (they
get passed in via a GHashTable) we can use this as a handy way of
embedding a LIVE guppi plot in the HTML widget. I have *no* idea how
this interacts with printing. We can also embed any kind of GTK
controls we find useful, live registers, or any other manner of
craziness that we want to implement an appropriate "classid" handler
for in the gnc-html object handler.
OK, very nifty, this would almost certainly be the way to go for
embedding guppi into gtkhtml stuff.
The iframe tag ("inline" frame) may easily allow us to embed
sub-reports and/or scheme code output directly into a "template" HTML
file, which makes the HTML look sort of like what Linas was hoping it
would:
iframe src="gnc-scheme:(scheme-func-to-spew-html)"
Since we handle the parsing of URLs in gtkhtml, it's easy to add a way
of interpreting the "gnc-scheme:" protocol string and evaluating the
rest of the URL appropriately. It may be better to use the object
tag for that too, but I'm not exactly sure if it will DTRT:
object classid="gnc-inline-scm"
param name="form" value="(scheme-func-to-spew-html)"
/object
Cool. We probably *could* use that kind of thing to implement similar
functionality to what I'm busy doing with gtkpanes, but after thinking
about it I think panes will be better. It's easier to provide a UI
for configurability and we can probably lay things out a little more
precisely.
If anybody wants to disagree, however, feel free, and feel free *right
now* before I do any more implementation :)
It's just that we're still having problems with table splitting,
despite the latest CVS gtkhtml supposedly fixing this. Is it
somehow possible that the interface has changed in some obscure
fashion causing the page splitting to break?
I have no idea. There's really no "interface" to the gnome-print
functionality, just gtk_html_print(GtkHTML *, GnomePrintContext *);
I'll have a look when this new HTML code gets more on its feet
(hopefully today).
OK, the page splitting is working with the tarball the Helixcode guys
sent me (which may or may not be on anoncvs.gnome.org yet), but the
print preview seems to be borken (only one page is displayed with no
ability to switch between pages). Can anyone else confirm this for
me?
Robert Merkel [EMAIL PROTECTED]
"We are excited and optimistic about its usage going
forward and, yes, we can teach penguins the military
close-order drill", Mark Norton, US Department of Defense.
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
printing problems
You mentioned briefly on IRC that you were doing something with printing. Was that gtkhtml printing, or just checks? It's just that we're still having problems with table splitting, despite the latest CVS gtkhtml supposedly fixing this. Is it somehow possible that the interface has changed in some obscure fashion causing the page splitting to break? Robert Merkel [EMAIL PROTECTED] "We are excited and optimistic about its usage going forward and, yes, we can teach penguins the military close-order drill", Mark Norton, US Department of Defense. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Could somebody try CVS gnucash with cvs gtkhtml?
According to the gtkhtml people, they have now implemented table splitting in CVS gtkhtml. However, when I try it, the tables are still split in the middle of lines. Could somebody else try printing (to a file is easiest) a multi-page transaction report with CVS gnucash and gtkhtml, just as a sanity check? Robert Merkel [EMAIL PROTECTED] ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
gtkhtml strangeness continues
Guys, I've just tried the new gtkhtml which was supposed to fix the page splitting with tables, but doesn't. Is it possible that we're doing something wrong with our use of gtkhtml to cause this to occur? Robert Merkel [EMAIL PROTECTED] ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Making a fancy main window like our competitor :)
Matthew Vanecek writes: Robert Graham Merkel wrote: A couple of questions that must be answered about something like that. Do you want it simply because Quicken has it, or because it looks cool? Those in charge would really have to look very hard at whether such a feature truly enhances productivity. Personally, I don't mind copying the concept of something else, with my own twists added. It does, however, need to make sense, both from a complexity standpoint, and from a useability standpoint. IOW, don't copy simply because the 'competitor' has it; rather, glean good ideas from what's available, and come up with new innovative ideas. I think the GNUCash team is doing a good job at that. I haven't seen it myself - Bill, Rob B, and Linas have, and they think it's a good idea, and the idea of letting the user set up what financial information they'd like to see by default when they start up GnuCash seems like a good idea. If they want just what they have now, they can. If they want a plethora of fancy graphs and reports, they can have that too. I've prototyped the idea, and I think it can be done with a relatively small amount of code. As for usability, I think I can make it fairly easy to customize both with code and with the GUI. You're absolutely right, though - you don't just blindly copy the features of your competitor's product. That's what got us commercial bloatware in the first place. Robert Merkel [EMAIL PROTECTED] ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Making a fancy main window like our competitor :)
For those of you who haven't used Quicken lately, apparently it now has a main window that displays a configurable set of reports, graphs and other financial information (including downloaded stock quotes). It's a very nice feature and probably worth trying to do something similar. The question is: how? I've had a look at GnomeDock, and to me it seems it's really designed for toolbars and menus rather than resizable display widgets. The best way of going about it I can come up with so far is to use a descending sequence of GTKHPaned and GtkVapaned widgets to divide the main window up. To configure what appears in each subwindow, there is a small toolbar at the top with a list of things to display (ie "financial summary" or "net worth graph" and the like) and a configure button that when selected gives the appropriate options for that display. To give you an idea what I mean, imagine the paned widget in the current gnome file manager applied recursively to an area, or kind of like a framed web page. Finally, to allow the layout itself to be customized, each toolbar also contains the options "split horizontally", "split vertically", and "join". Obviously, you'd want to provide a selection of default layouts, and let the user save their customized layout. What do you all think? Is this an abuse of Gtk*Paned? Will it look like a dog's breakfast? Is it going to be too hard to configure? Is there a better solution already out there? Robert Merkel [EMAIL PROTECTED] ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Transaction report crashes
Hans-Juergen Hay writes: Robert Graham Merkel wrote: I can't duplicate your crash. Is there any other distinguishing features you can identify when the crash occurs. No, I try to buid it with debugging info so that I can look at the core file. I get back to you when I can say more. BTW: trying to build cvs, g-wrap complains about unrecognised type long-long and that type is not documented in the g-wrap info files, at least not in mine, only unsigned-long-long is documented. Do I need a newer version of g-wrap than the one required by the README file (0.9.5)? I have 0.9.6. Yep, CVS requires g-wrap 0.9.11. Sorry for not updating the README, but the README will often not keep up with the bleeding edge. CVS is likely to require new versions of g-wrap as they are released - new features are being added to g-wrap to allow the wrapping of the entire gnucash internal API. Robert Merkel [EMAIL PROTECTED] ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
