Re: [GNC-dev] UK VAT and "Making Tax Difficult"
On Sun, 8 Jan 2023 00:41:42 +0200 Graham Leggett via gnucash-devel wrote: > Hi all, > > In the archives there have been discussions over coming up with a way to do > the UK’s MTD (making tax digital). > > The key missing bit is the bridge part - the piece that logs into HMRC and > passes the JSON message. Does an open source bridge exist? > > If an open source bridge does not exist I am going to write one, but if I > didn’t have to that would be great. > > Regards, > Graham > — > A bug was submitted some time ago. I have just updated it a little. https://bugs.gnucash.org/show_bug.cgi?id=798263 > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel -- GPG Key ID: DB8F7CF1C67BBC0F Keyserver: https://keys.openpgp.org ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] UK VAT and "Making Tax Difficult"
On Sun, 8 Jan 2023 00:41:42 +0200 Graham Leggett via gnucash-devel wrote: > Hi all, > > In the archives there have been discussions over coming up with a way to do > the UK’s MTD (making tax digital). > > The key missing bit is the bridge part - the piece that logs into HMRC and > passes the JSON message. Does an open source bridge exist? > > If an open source bridge does not exist I am going to write one, but if I > didn’t have to that would be great. > > Regards, > Graham > — > Hi Graham. There's some code I wrote at https://gitlab.com/saxicola/hmrc_self_submit it may be useful as a starter hint. The cpp stuff never got very far but the python test code to submit earnings worked with their sandbox. I never got into the VAT part. And I've done nothing since the last commit. Their API has changed a little since I last tested it. Register as a developer https://developer.service.hmrc.gov.uk/api-documentation Regards Mike Evans > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel -- GPG Key ID: DB8F7CF1C67BBC0F Keyserver: https://keys.openpgp.org ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] [GNC] UK specific: MTD - Making Tax Digital
> > > Hi, > > > > Is anyone interest in having a MTD bridge for GnuCash for VAT submissions? > > I > > have developed a bridge and would be happy to integrate it with GnuCash if > > there is still any interest. > > > > Kind regards, > > Chris > > Please do. I made a start on a bridge for submitting self employed income, then got distracted. Mike -- PGP Key fingerprint = DA68 9657 0FF3 EFCB 58BD 3349 982E 6790 44C1 29D0 Use saxic...@protonmail.com for end to end encrypted communication. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Deprecation of XML file
> The *main* benefit of SQL storage is that you get immediate saves. I.e., > when you commit a transaction, it gets saved to storage immediately. So > -- no lost work. This is exactly why I *don't* use a database for storage. I often screw up entering data. I don't save until I'm happy I've done it right. With XML I can just reload the file and try again. With a database I'd have to restore the last backup, probably yesterday's, then restart GnuCash and try again losing *everything* I did today. (Yes I could manually do a backup of the sqlite file after each transaction but...). With XML I can enter a transaction, check that I've not screwed up, save the file, then move on to the next transaction, check it and save. This way If I screw up I can simply reload the XML from however many minutes ago I last saved and continue. The no-lost-work maybe fine for some|many but not for me. The only immediate advantage of a DB backend is (as far as I can see) is concurrent user access, which GnuCash doesn't do, yet, so until then I will be using the XML file storage. Yes, extracting data with other external programs is easier with SQL and If I want to do that I can. I've never had the need to do so though as the reporting features of GnuCash gives me all the data I need. -- PGP Key fingerprint = DA68 9657 0FF3 EFCB 58BD 3349 982E 6790 44C1 29D0 Use saxic...@protonmail.com for end to end encrypted communication. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] RE Bug 797085
On Mon, 29 Jul 2019 19:13:27 -0700 John Ralls wrote: > > On Jul 29, 2019, at 2:12 AM, Mike Evans wrote: > > > > https://bugs.gnucash.org/show_bug.cgi?id=797085 > > > > I've made the strings translatable. Should I do two commits; one for > > updates to the strings in dialog-bi-import.c and another for updating all > > the .po files? The po files update changes a lot of stuff not related to > > the new strings. > > If you made a new gnucash.pot and merged it into the po files, discard those > changes, we leave that task to translators. The only time we change po files > is when we change an already-translated string and want to continue using the > existing translations; as a general rule the change needs to be a minor one > like fixing a typo. Your commit adds a bunch of new strings so it doesn't > qualify. > > Regards, > John Ralls > Thanks John. After some more thought that's what I decided to do. Regards Mike E -- PGP Key fingerprint = DA68 9657 0FF3 EFCB 58BD 3349 982E 6790 44C1 29D0 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[GNC-dev] RE Bug 797085
https://bugs.gnucash.org/show_bug.cgi?id=797085 I've made the strings translatable. Should I do two commits; one for updates to the strings in dialog-bi-import.c and another for updating all the .po files? The po files update changes a lot of stuff not related to the new strings. Mike E -- PGP Key fingerprint = DA68 9657 0FF3 EFCB 58BD 3349 982E 6790 44C1 29D0 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Bug 787018
On Sat, 4 May 2019 18:14:48 +0100 Mike Evans wrote: > Hi all > > In regard to saving the last dir that a PDF was printed to I assume I can use > gtk_print_settings_to_key_file (print_settings, SOME_KEY_FILE, NULL) ? What > is the SOME_KEY_FILE that I need and how do access it from > gnc-html-webkit2.c. This ultimately writes to the "physical" > BOOKNAME.gnucash.gcm file in the GnuCash settings directory on close ? > > Regards Mike E > As is always the case, I appear to have now figured this out. :) -- GPG Key fingerprint = 0D8A 33A8 F7F8 733C 7519 2A56 DB8F 7CF1 C67B BC0F ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Bug 787018
Hi all In regard to saving the last dir that a PDF was printed to I assume I can use gtk_print_settings_to_key_file (print_settings, SOME_KEY_FILE, NULL) ? What is the SOME_KEY_FILE that I need and how do access it from gnc-html-webkit2.c. This ultimately writes to the "physical" BOOKNAME.gnucash.gcm file in the GnuCash settings directory on close ? Regards Mike E -- GPG Key fingerprint = 0D8A 33A8 F7F8 733C 7519 2A56 DB8F 7CF1 C67B BC0F ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] gnucash: New branch 'Bug-797168'
Oops didn't mean to make a new branch. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Gnucash and the UK's "Making Tax Digital" initiative
On Sat, 6 Apr 2019 18:36:41 +0100 Alain D D Williams wrote: > On Sat, Apr 06, 2019 at 11:29:30PM +0800, Christopher Lam wrote: > > > All these are "bridging software" problems. > > I would feel happier working on a free standing bridging s/ware than digging > inside Gnu cash. It doesn't sound as if it is very hard, although I have not > done played with Oauth before. I assume that it is send one file to HMRC, get > one file by way of reply - do you know if it is more complicated than that ? > Working python examples at https://github.com/EvansMike/hmrc_self_submit convert them into your favourite language. It's example code code using the sandbox-test API. Mike E -- GPG Key fingerprint = 0D8A 33A8 F7F8 733C 7519 2A56 DB8F 7CF1 C67B BC0F ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Gnucash and the UK's "Making Tax Digital" initiative
On Fri, 5 Apr 2019 12:52:05 +0100 Alain D D Williams wrote: > On Thu, Apr 04, 2019 at 09:31:22PM +0100, Mike Evans wrote: > > > After a hiatus I have successfully interacted with the HMRC API for a test > > account to post earning & expenses using python. > > Brilliant ... something that I got part way through but never completed. > > This is something that I need to do for my, one man band, business. So I will > volunteer to help in some way. > > > I've not looked at the VAT part, because I'm not VAT registered, so... > > I am VAT registered, so I have motivation to do something. > > > A minimal json data set for a self-employed quarterly submission looks > > like: > > So your script reads & sends JSON to HMRC and, presumably generates a JSON > file > with the HMRC reply. This is good and I can see it being useful to many others > who need to talk to HMRC - eg organisations that have written their own > accounts > programs. > Well at the moment it's just a collection of test cases so files aren't generated just data printed to the screen at present. These are just the building blocks at the moment. > > > I'm still thinking how to keep the secret, even though HMRC have apparently > > relaxed that requirement. Ideas welcome on that, maybe a json request from > > gnucash.org, I know the request code will still be public however, that's > > the > > part that needs more_thought_input. > > With Open Source software it is hard to have a secret. Ideas: > > * Everyone who uses it gets a secret from HMRC. Possible, but a nasty way of > doing it. The key is application specific and is obtained when registering the application. > Thinking about it: how does closed source keep a secret ? The only way is to > use > compiled code and embed the secret in there, possibly obscuring it in some > way. > But something embedded can be obtained by running the code under a suitable > debugger - an expending some effort. > Just run strings on any compiled code. If you know the key format then use a regex to find candidate keys from the output. Mike E -- GPG Key fingerprint = 0D8A 33A8 F7F8 733C 7519 2A56 DB8F 7CF1 C67B BC0F ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Gnucash and the UK's "Making Tax Digital" initiative
Hello all. After a hiatus I have successfully interacted with the HMRC API for a test account to post earning & expenses using python. None of it is joined up yet to: create|query a business, post and query data about that business but my "tests" appear to work as individual pieces. I haven't yet queried GnuCash for the data either but I can confirm that the HMRC API works for submitting self employed account data. I've not looked at the VAT part, because I'm not VAT registered, so... A minimal json data set for a self-employed quarterly submission looks like: json_data = { "from": "2017-04-06", "to": "2017-07-04", "incomes": { "turnover": { "amount": 100.25 }, "other": { "amount": 100.25 } }, "consolidatedExpenses": 100.25 } and that's it. That's the example data from: https://developer.service.hmrc.gov.uk/api-documentation/docs/api/service/self-assessment-api/2.0#selfemployment-business_create-a-selfemployment-periodic-update_post_accordion Doing a query on the same period returns: {u'to': u'2017-07-04', u'consolidatedExpenses': 100.25, u'from': u'2017-04-06', u'incomes': {u'other': {u'amount': 100.25}, u'turnover': {u'amount': 100.25}}} You can of course provide detailed account data but I never have in past submissions. These data should be easy to pull out of GnuCash with the (probably augmented) Python bindings to satisfy HMRC each quarter. I guess this could be incorporated into GnuCash as a C++ module at some point but I'll leave that that others more committed. Lest I be committed. I'll stick the code on GitHub in a while. It's very much just code to test the connection with a some test POSTs and GETs. I have lots of cleaning up and comments to add before it's publicly viewable. Tomorrow maybe. I'm still thinking how to keep the secret, even though HMRC have apparently relaxed that requirement. Ideas welcome on that, maybe a json request from gnucash.org, I know the request code will still be public however, that's the part that needs more_thought_input. Python because it's easy to do quick tests, Sorry Derek. :) Mike E -- GPG Key fingerprint = 0D8A 33A8 F7F8 733C 7519 2A56 DB8F 7CF1 C67B BC0F ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Register Documentation Improvements (was Re: [GNC] Column widths again)
On Mon, 27 Aug 2018 11:14:28 -0500 Rob Gowin wrote: > On Mon, Aug 27, 2018 at 7:50 AM, Mike Evans wrote: > > > > Hi Rob > > > > Referring to your mail of 2015-09-01 you "put the XSL file and a python > > script to run the conversion process in a repository at > > https://github.com/codesmythe/asciidoc-conversion.; > > > > This no longer exists, can you make it available again? Unless you'd > > rather not of course. > > > > Mike Evans > > > > And by not-so-popular demand, that repository is back. :-) > > I haven't touched that code since the 2015 discussion, but hopefully you > can some use out of it. > > Regards, > > Rob Forked. So now there are two. Mike E ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Register Documentation Improvements (was Re: [GNC] Column widths again)
On Thu, 23 Aug 2018 12:25:51 -0500 Rob Gowin wrote: > On Thu, Aug 23, 2018 at 11:40 AM, John Ralls wrote: > > > > > > > So a new thought: One of the core devs use pandoc to convert the DocBook > > source to one of the markup/markdown variants, do the necessary manual > > fixups and commit the result. If we want DocBook for some reason the build > > process would use pandoc to generate it. > > > > If we had GitHub-flavored markdown sources then > > https://github.com/gnucash/gnucash-docs would show rendered documentation > > and one could use the "preview" button to check basic layout; it would > > appear pretty similar to how the document would look in a PDF or eBook > > rendering. > > > > > Hmmm. Old thought. :-) I did all of this in the 2015 thread that Geert > referenced. (Except I did not use pandoc, and used Asciidoc has my markup > variant of choice.) A rendered version of the Tutorial and Concept Guide > can be found here: https://github.com/codesmythe/gnucash-guide-asciidoc. > For example, click on 'en' then on ch_cbook.adoc to see a rendered version. > Then on that page click on the 'Raw' to see the Asciidoc source. I'd also > worked out the flow changes to generate PDF, eBook, etc from the Asciidoc > sources. > > In > https://lists.gnucash.org/pipermail/gnucash-devel/2015-September/038997.html, > you asked for buy-in from the non-tech doc writers, and unfortunately, none > was found. :-( > > One thing that has changed in the interim is the availability of decent > editors that have a live-preview mode that will show the raw Asciidoc on > the left and the live-rendered result on the right. For example, Visual > Studio Code (available for Mac, Linux, Windows) has an extension for this: > https://marketplace.visualstudio.com/items?itemName=joaompinto.asciidoctor-vscode > (see the demo gif), and VS Code supports Git out of the box. > > Rob > ___ Hi Rob Referring to your mail of 2015-09-01 you "put the XSL file and a python script to run the conversion process in a repository at https://github.com/codesmythe/asciidoc-conversion.; This no longer exists, can you make it available again? Unless you'd rather not of course. Mike Evans -- GPG Key fingerprint = 0D8A 33A8 F7F8 733C 7519 2A56 DB8F 7CF1 C67B BC0F ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash Bugzilla URLs -- /bugzilla or not?
On Thu, 10 May 2018 05:37:31 -0400 "Derek Atkins"wrote: > Hi, > > As you are aware, we are looking at migrating from gnome bugzilla to our > own instance because gnome is shutting their BZ off. I've been working on > migrating the data, and have what I think is a good migration process in > place. We are at the early stages of testing the migration, but I wanted > to open up some high-level questions to everyone. > > My first question to you all: The BZ URL. > > The current URLs at gnome are bugzilla.gnome.org/show_bug.cgi > > Currently, the URLs for us are bugzilla.gnucash.org/bugzilla/show_bug.cgi > > Do people care? Do you want me to look at removing that /bugzilla in there? > > Let me know your thoughts. I'll post more questions later. > > Thanks! > > -derek > The extra /bugzilla does seem superfluous to me. Mike E ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Font colours in 2.8
Thanks again Bob. Is that documented anywhere? I sure I'm not the only one who hates grey text. Mike E On Sat, 14 Oct 2017 10:30:06 +0100 Robert Fewell <14ubo...@gmail.com> wrote: > Mike, > You will have to create it in your home directory, just a text file but > make sure it has a leading dot. > > Bob > > On 14 October 2017 at 09:49, Mike Evans <mi...@saxicola.co.uk> wrote: > > > On Fri, 13 Oct 2017 16:13:54 +0100 > > Robert Fewell <14ubo...@gmail.com> wrote: > > > > > Mike, > > > > > > Try this in your .gtk-3.0-gnucash.css file > > > > > > notebook tab label { > > > color: black; > > > } > > > > > > Regards, > > > Bob > > > > Hi Bob. > > > > I can't find any such file. Fedora26. > > > > Cheers. > > Mike E > > ___ > > gnucash-devel mailing list > > gnucash-devel@gnucash.org > > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Font colours in 2.8
On Sat, 14 Oct 2017 09:49:19 +0100 Mike Evans <mi...@saxicola.co.uk> wrote: > On Fri, 13 Oct 2017 16:13:54 +0100 > Robert Fewell <14ubo...@gmail.com> wrote: > > > Mike, > > > > Try this in your .gtk-3.0-gnucash.css file > > > > notebook tab label { > > color: black; > > } > > > > Regards, > > Bob > > Hi Bob. > > I can't find any such file. Fedora26. > > Update: Adding that in gnucash/gnome-utils/ui/gnucash.css works for me. Thanks Bob ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Font colours in 2.8
On Fri, 13 Oct 2017 16:13:54 +0100 Robert Fewell <14ubo...@gmail.com> wrote: > Mike, > > Try this in your .gtk-3.0-gnucash.css file > > notebook tab label { > color: black; > } > > Regards, > Bob Hi Bob. I can't find any such file. Fedora26. Cheers. Mike E ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Font colours in 2.8
I've ranted elsewhere about the "fashion" of grey text on grey background elsewhere on the web but I never expected it to appear in GnuCash. I know it's trendy an' all but as an "older" (also grumpy) user I find it hard to read grey on grey. In order to use the latest version I need to change the font colour to black. It seems to be only the tabs are affected. I've tried the various settings in Fedora to change the colours to no avail, is this hard coded somewhere? Mike E ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: dialog-invoice
On Sat, 2 Sep 2017 13:42:56 +0100 Robert Fewell <14ubo...@gmail.com> wrote: > I have noticed some invalid casts which trace back to dialog-invoice but > not sure what has changed, so here is what I have found... > > Looking at a local pre gtk3/master dialog-invoice.glade, you have > page_terms_menu being a GtkEntry and dialog_terms_menu being a GtkComboBox > with no Entry. > > Looking at master now dialog-invoice.glade, you have page_terms_menu being > a GtkComboBox with no Entry and dialog_terms_menu being a GtkComboBox with > no Entry. > > What I do not know is did I make a mistake in the conversion, seems strange > I would of changed widgets or was there a change made that was not correct ? > > Tried looking at the history of dialog-invoice.glade on GitHub but that has > no history before the directory changes, any other way to find out > what/when changed ? > > Bob > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel git log --follow will get previous you history Mike E ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Master: Printing of PDF Reports
On Wed, 30 Aug 2017 06:35:30 -0700 John Ralls <jra...@ceridwen.us> wrote: > > On Aug 30, 2017, at 3:37 AM, Mike Evans <mi...@saxicola.co.uk> wrote: > > > > Hi all. Good job on all the hard work you guys are doing to produce 2.8. > > > > I finally got round to compiling master and noticed a possible behaviour > > regression when printing/exporting reports as PDFs. On maint selecting > > "export to PDF" provides the user dialog with a pre-populated filename to > > export to consisting of the report name and the current date. On master the > > same action takes me to the standard print menu where I select from printer > > or pdf and have to fill in the filename manually. > > > > I've not looked into the "why" of this as yet. Want to confirm this first > > just in case it's settings related somewhere I've missed/forgotten. > > Mike, > > It’s because WebKit2 doesn’t expose the necessary API to do it separately. > They expose the functionality from the print dialog instead. We need to > remove the export to PDF actions and document that users should use “print” > instead. > > Regards, > John Ralls > John That's a shame as I use that a lot for invoicing. Is there any mechanism to pass through a filename to the print dialog? I'll open a bug then so this isn't forgotten and mark that as blocking Geerts tracker bug 778981. Regards Mike E ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Master: Printing of PDF Reports
Hi all. Good job on all the hard work you guys are doing to produce 2.8. I finally got round to compiling master and noticed a possible behaviour regression when printing/exporting reports as PDFs. On maint selecting "export to PDF" provides the user dialog with a pre-populated filename to export to consisting of the report name and the current date. On master the same action takes me to the standard print menu where I select from printer or pdf and have to fill in the filename manually. I've not looked into the "why" of this as yet. Want to confirm this first just in case it's settings related somewhere I've missed/forgotten. Mike E ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: For UK users: Will gnucash get ready for Making Tax, Digital ?
A little more reading. https://www.cchdaily.co.uk/lords-probe-software-companies-lack-readiness-making-tax-digital and https://github.com/hmrc ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: VAT Call for Software developers
On Thu, 17 Aug 2017 17:04:52 +0200 John Ralls <jra...@ceridwen.fremont.ca.us> wrote: > > On Aug 17, 2017, at 2:47 PM, Mike Evans <mi...@saxicola.co.uk> wrote: > > > > I just received this from HMRC. > > > > Begin forwarded message: > > > > Date: Thu, 17 Aug 2017 10:46:57 + > > From: <sdst...@hmrc.gsi.gov.uk> > > To: <sdst...@hmrc.gsi.gov.uk> > > Subject: VAT Call for Software developers > > > > > > Dear All, > > > > I writing to tell you about a conference call that has been arranged for > > 11:00am on 05 September 2017. > > > > You may be aware that the Government has proposed that businesses with a > > turnover above the VAT threshold (currently £85,000) will be mandated to > > keep digital records and submit data to HMRC through its secure API > > platform service. The changes will take place from April 2019 for VAT. > > > > Current plans are to make the APIs available for private beta test in > > October 2017 and we want to advise interested software vendors about our > > thinking as well as provide them with an early opportunity to raise any > > issues or questions. It will of course also help us identify if your > > company is considering developing or enhancing a VAT product to support the > > proposals. > > We can then arrange to work with you going forward, providing the usual > > technical assistance and other support needed to prepare for the pilot, > > from April 18 and in readiness for the changes being mandated from April > > 2019. > > > > * Only businesses with a turnover above the VAT threshold will have to > > keep digital records and only for VAT purposes. They will only need to do > > so from 2019. > > * Other businesses will be able to file digitally on a voluntary basis > > for both VAT and Income Tax and NICs > > > > Our current development schedule is as follows > > > > 1. October 2017 - private beta (API testing) with interested software > > vendors > > 2. April 2018 - public beta (pilot) data submission for VAT purposes (MVP > > to include unincorporated businesses); we will be inviting business > > volunteers throughout the year, anticipating that early adopters will > > already be using software and therefore likely to already be your > > customers. These will include both Tax Agents, their clients as well as > > unrepresented VAT businesses. > > 3. From April 2019 - data submission for VAT purposes (that is all > > VAT-registered businesses whether the business is unincorporated or not); > > Mandated for VAT registered businesses with a turnover above the VAT > > threshold, but all VAT registered businesses can use the service. > > > > Please let me know if you intend to join the call so I can make the > > necessary arrangements. Please send your reply to this email no later than > > 17:00 on 24th August 2017. > > > > > > Kind Regards > > > > Dennis Dawkins |Senior Delivery Operations Lead| HMRC CDIO Digital - > > Software Developers Collaboration - Software Developers Support Team > > (SDST) | 2nd Floor, Accounts Office Shipley, Victoria Street, Shipley BD98 > > 8AA > > > > The information in this e-mail and any attachments is confidential and may > > be subject to legal professional privilege. Unless you are the intended > > recipient or his/her representative you are not authorised to, and must > > not, read, copy, distribute, use or retain this message or any part of it. > > If you are not the intended recipient, please notify the sender immediately. > > > > HM Revenue & Customs computer systems will be monitored and communications > > carried on them recorded, to secure the effective operation of the system > > and for lawful purposes. > > > > The Commissioners for HM Revenue and Customs are not liable for any > > personal views of the sender. > > Mike, > > Can you attend the conference call and raise the issue about per-application > secret keys that we've discussed here? I'd do it but I'll be back in > California by then and I'm seldom compos mentis at 3AM. > > Regards, > John Ralls > I don't think I'm best (or at all) qualified for this. I know almost nothing about UK tax, other than having to file my returns each year. Maybe someone better qualified would like to volunteer. Mike Evans ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Fw: VAT Call for Software developers
I just received this from HMRC. Begin forwarded message: Date: Thu, 17 Aug 2017 10:46:57 + From:To: Subject: VAT Call for Software developers Dear All, I writing to tell you about a conference call that has been arranged for 11:00am on 05 September 2017. You may be aware that the Government has proposed that businesses with a turnover above the VAT threshold (currently £85,000) will be mandated to keep digital records and submit data to HMRC through its secure API platform service. The changes will take place from April 2019 for VAT. Current plans are to make the APIs available for private beta test in October 2017 and we want to advise interested software vendors about our thinking as well as provide them with an early opportunity to raise any issues or questions. It will of course also help us identify if your company is considering developing or enhancing a VAT product to support the proposals. We can then arrange to work with you going forward, providing the usual technical assistance and other support needed to prepare for the pilot, from April 18 and in readiness for the changes being mandated from April 2019. * Only businesses with a turnover above the VAT threshold will have to keep digital records and only for VAT purposes. They will only need to do so from 2019. * Other businesses will be able to file digitally on a voluntary basis for both VAT and Income Tax and NICs Our current development schedule is as follows 1. October 2017 - private beta (API testing) with interested software vendors 2. April 2018 - public beta (pilot) data submission for VAT purposes (MVP to include unincorporated businesses); we will be inviting business volunteers throughout the year, anticipating that early adopters will already be using software and therefore likely to already be your customers. These will include both Tax Agents, their clients as well as unrepresented VAT businesses. 3. From April 2019 - data submission for VAT purposes (that is all VAT-registered businesses whether the business is unincorporated or not); Mandated for VAT registered businesses with a turnover above the VAT threshold, but all VAT registered businesses can use the service. Please let me know if you intend to join the call so I can make the necessary arrangements. Please send your reply to this email no later than 17:00 on 24th August 2017. Kind Regards Dennis Dawkins |Senior Delivery Operations Lead| HMRC CDIO Digital - Software Developers Collaboration - Software Developers Support Team (SDST) | 2nd Floor, Accounts Office Shipley, Victoria Street, Shipley BD98 8AA The information in this e-mail and any attachments is confidential and may be subject to legal professional privilege. Unless you are the intended recipient or his/her representative you are not authorised to, and must not, read, copy, distribute, use or retain this message or any part of it. If you are not the intended recipient, please notify the sender immediately. HM Revenue & Customs computer systems will be monitored and communications carried on them recorded, to secure the effective operation of the system and for lawful purposes. The Commissioners for HM Revenue and Customs are not liable for any personal views of the sender. This e-mail may have been intercepted and its information altered. Dear All, I writing to tell you about a conference call that has been arranged for 11:00am on 05 September 2017. You may be aware that the Government has proposed that businesses with a turnover above the VAT threshold (currently £85,000) will be mandated to keep digital records and submit data to HMRC through its secure API platform service. The changes will take place from April 2019 for VAT. Current plans are to make the APIs available for private beta test in October 2017 and we want to advise interested software vendors about our thinking as well as provide them with an early opportunity to raise any issues or questions. It will of course also help us identify if your company is considering developing or enhancing a VAT product to support the proposals. We can then arrange to work with you going forward, providing the usual technical assistance and other support needed to prepare for the pilot, from April 18 and in readiness for the changes being mandated from April 2019. * Only businesses with a turnover above the VAT threshold will have to keep digital records and only for VAT purposes. They will only need to do so from 2019. * Other businesses will be able to file digitally on a voluntary basis for both VAT and Income Tax and NICs Our current development schedule is as follows 1. October 2017 â private beta (API testing) with interested software vendors 2. April 2018 â public beta (pilot) data submission for VAT purposes (MVP
Re: UK specific: MTD - Making Tax Digital
On Mon, 17 Apr 2017 20:06:15 +0100 Mike Evans <mi...@saxicola.co.uk> wrote: > On Mon, 17 Apr 2017 19:34:36 +0100 > "Maf. King" <m...@chilwell.net> wrote: > > > On Monday, 17 April 2017 16:39:02 BST Alain Williams wrote: > > > On Mon, Apr 17, 2017 at 04:00:20PM +0100, David Goodenough wrote: > > > > Apparently they have effectively locked out open source software as > > > > there > > > > is a per application (i.e. there would be one just for GnuCash) "secret" > > > > that is used during the OAuth2 login. Keeping that value secret is not > > > > possible in open source (closed source just hard code it into their > > > > code) > > > > so effectively open source can not be used. The authorisation process is described at: https://developer.service.hmrc.gov.uk/api-documentation/docs/authorisation I've CC'd this to the devel list. Mike E ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Compiling on Fedora25
On Sat, 15 Apr 2017 08:32:29 -0500 Rob Gowin <r...@gowin.net> wrote: > On Sat, Apr 15, 2017 at 3:24 AM, Mike Evans <mi...@saxicola.co.uk> wrote: > > > > > Compiling using cmake I get a different error messages: > > > > In file included from /usr/include/sys/types.h:25:0, > > from /home/mikee/Projects/gnucash/ > > src/libqof/qof/md5.c:27: > > /usr/include/features.h:331:4: error: #warning _FORTIFY_SOURCE requires > > compiling with optimization (-O) [-Werror=cpp] > > # warning _FORTIFY_SOURCE requires compiling with optimization (-O) > > ^~~ > > > > Any thoughts? > > > > Regards Mike E > > > > Hi Mike, > > Looks like I need to backport this commit on master to maint: > https://github.com/Gnucash/gnucash/commit/992f3232ee90cfcf6484a0fdb4cf506168676a40 > > In the meantime as a workaround, on line 419 of the top level > CMakeLists.txt file, you can change -D_FORTIFY_SOURCE=2 to > -U_FORTIFY_SOURCE.to continue. > > Regards, > > Rob Many thanks Rob. That fixed the cmake build. Best Regards Mike E ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Compiling on Fedora25
Hi All Finally upgraded to Fedora25 64 bit and trying to compile GnuCash maint. Having run: sudo dnf builddep gnucash -y sudo dnf install texinfo git intltool libdbi-devel guile-devel doxygen webkitgtk-devel -y Using autotools with configure --enable-debug --prefix=$HOME/progs/gnucash --enable-debug --enable-doxygen --enable-error-on-warning --enable-compile-warnings I get: swig-unittest-support-guile.c: In function ‘SWIG_Guile_ConvertPtr’: swig-unittest-support-guile.c:895:14: error: implicit declaration of function ‘SCM_POINTER_P’ [-Werror=implicit-function-declaration] } else if (SCM_POINTER_P(s)) { ^ swig-unittest-support-guile.c:896:15: error: implicit declaration of function ‘SCM_POINTER_VALUE’ [-Werror=implicit-function-declaration] *result = SCM_POINTER_VALUE(s); ^ swig-unittest-support-guile.c:896:13: error: assignment makes pointer from integer without a cast [-Werror=int-conversion] *result = SCM_POINTER_VALUE(s); This is with guile (GNU Guile) 2.0.13 from the Fedora repos. Compiling using cmake I get a different error messages: In file included from /usr/include/sys/types.h:25:0, from /home/mikee/Projects/gnucash/src/libqof/qof/md5.c:27: /usr/include/features.h:331:4: error: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Werror=cpp] # warning _FORTIFY_SOURCE requires compiling with optimization (-O) ^~~ Any thoughts? Regards Mike E ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Are There Plans For A GUI Overhaul?
On Thu, 20 Oct 2016 16:55:46 +0100 Wm via gnucash-develwrote: > On 20/10/2016 06:52, Thomas Baumgart wrote: > > Hi, > > > > On Thursday 20 October 2016 00:31:29 Lincoln A Baxter wrote: > > > >> IMO, you are asking the right (hard) questions... I'm interested in > >> seeing the response to the https://kmymoney.org/ question. Is this a > >> fork, or not? > > > > I can certainly answer that: No it is not a fork, even though some concepts > > are similar/inspired by GnuCash and it uses the same backends like > > AqBanking > > and libOFX provided as separate libraries. > > thank you > > I am aware that this can bring up feelings but is there a document > describing the motivation to develop separately? > > for all I know it could simply have been born of the KDE thing of doing > it yourself even if it wasn't necessary and you weren't going to do it > better :) > > I think some things could be borrowed both ways but maybe everyone is > just too old and grumpy to talk about it ... > Old? Grumpy? Me? Have we met? Mikee -- PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get=0xDB8F7CF1C67BBC0F ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: API for creating invoices?
On Mon, 3 Oct 2016 15:29:36 -0400 (EDT) Jon Daleywrote: > On Mon, 3 Oct 2016, Derek Atkins wrote: > > gnuc...@jon.limedaley.com writes: > >> I browsed the docs and mailing list and see various requests about > >> creating/modifying an invoice from the command line, but some of the > >> information is out of date, and the information that might be current > >> is sparse, and I'm a little scared off from the various warnings from > >> years ago that playing with the API might break the whole database... > > > > You can do it via C, Scheme, and/or Python. > > Are there any examples or documentation? > I put some random stuff on GitHub at https://github.com/EvansMike/pycash Read the disclaimer and make backups before using in there. None of it is approved by GnuCash and is solely for demo purposes. Mike E -- PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get=0xDB8F7CF1C67BBC0F ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Bug 756469
I occurs to me that the regex for with-quotes now also accepts fields without-quotes too, so the importer doesn't need the without-quotes options. Also I'm wondering if the custom regex option is required or likely to be ever used by anyone? I'd file a separate bug/enhancement for this. Mike E -- PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get=0x00CDB13500D7AB53 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Bug 756469
On Tue, 12 Jan 2016 17:48:58 +0100 Geert Janssens <geert.gnuc...@kobaltwit.be> wrote: > On Tuesday 12 January 2016 10:11:25 Derek Atkins wrote: > > Hi, > > > > On Tue, January 12, 2016 9:52 am, Mike Evans wrote: > > > Hi Geert. > > > > > > I'd appreciate some advice on this bug, since you were that last > > > person to touch the (makes my head hurt) regex. > > > > > > In file dialog-bi-import-gui.c line 328 The regex for description, > > > and notes is currently: > > > > > > ((?[^\",]*)|\"(?[^\"]*)\")\" > > > > This regex is basically looking for anything within double-quotes, > > except for another double-quote. > > > > The issue would be handling something like: > > > > """" > > > > I.e., in order to escape a double-quote you use a double-double-quote. > > This regex does not handle that case. So it's basically saying "get > > me everything between the double quotes (without acknowledging the > > double-double-quote scenario. > > > > > I'm not a regex guru but it seems to me that losing the [^\"] part > > > and just using . would accept the problem lines. This wouldn't > > > strip the extra " from the escaped quote, but it would at least be > > > imported and editable later. I'd have thought that just accepting > > > everything inside the quoted field would be the correct behaviour? > > > > Unfortunately I don't think that would work. The construct: > > > > [^\"]* > > > > says to match anything but a double-quote. More likely we need to > > change it to: > > > > (?([^\"]|\"\")*) > > > > I think this will tell it to match anything but a double-quote, or a > > double-double-quote, as many times as they occur. > > > > Can you try this? > > > > > Mike E > > > > -derek > > Wow Derek, you're fast... I saw your response on the list before I even > received Mike's original > question... > > Anyway, I would also go for your suggestion. Simply replacing [^\"] with a > "." could cause the > rexexp to match too much. > > Regards, > > Geert Thanks Geert and Derek That works just fine. I should now code the conversion of the accepted "" into a single " before creating the invoice. Many thanks Mike E -- PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get=0x00CDB13500D7AB53 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Flickering drop down boxes on mouse over
On Tue, 12 Jan 2016 12:42:02 +0100 Geert Janssens <geert.gnuc...@kobaltwit.be> wrote: > On Wednesday 30 December 2015 13:14:09 Mike Evans wrote: > > On Wed, 30 Dec 2015 09:40:48 +0100 > > > > Geert Janssens <geert.gnuc...@kobaltwit.be> wrote: > > > On Monday 28 December 2015 15:12:26 Mike Evans wrote: > > > > The dropdown selection boxes in a register or invoice view > > > > flicker, as if they're having multiple refreshes, each time the > > > > mouse pointer enters or leaves the box. Has anyone else > > > > experienced this? I'm Using Fedora18 32 bit OS. I'm not quite > > > > sure when this started, several weeks or so. Just asking here > > > > before I file a bug just in case it's not GnuCash but some other > > > > system glitch. > > > > > > > > Mike E > > > > > > I only got to testing this now. > > > > > > I'm seeing this as well on Fedora 22, 64bit. > > > > > > I never noticed this before because I'm usually using keyboard > > > navigation in the register views. > > > > > > Geert > > > > It appears this is related to display settings in KDE, at least in my > > case it is. Logging out and in using the failsafe options, in which > > I just get an xterm, GnuCash doesn't have this issue. Neither does my > > laptop running PCLinuxOS and KDE. > > > > I'm just remembering that some months ago KDE screwed up my settings > > (again) amongst the issues was the disappearance lots of icons. My > > usual recovery method is deleting .kde directory and starting again. > > I'm thinking that this is about the time the trouble started. I also > > note that the button to activate the dropdown is round not square > > like it used to be and on my laptop. Somewhere in my > > settings/themes/appearance setup there's probably a way to bring some > > sanity back to the desktop settings. Somewhere... > > > > Mike E > > If you find it, please share on the list so I can fix it here as well :) > > Geert Hi Geert, Happy new year. I never fixed it. Except I did change my desktop to Xfce and there's no more flickering. Not really fix though. I will say Kfce is a lot faster and uses less memory than KDE. I've not missed any of KDE's bells & whistles at all. I got my icons back by: yum reinstall hicolor-icon-theme . I've no idea as to how they got screwed up though and was likely not connected to the flickering issue at all. Mike -- PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get=0x00CDB13500D7AB53 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gnucash-docs maint: Change paper format to A4 for European PDFs.
On Thu, 05 Nov 2015 20:46:49 +0100 Geert Janssenswrote: > Damn, you beat me to it... :) > > Thanks for doing the others as well. > > Geert > > On Thursday 05 November 2015 14:39:16 John Ralls wrote: > > Updated via https://github.com/Gnucash/gnucash-docs/commit/8408cbac > > (commit) from > > https://github.com/Gnucash/gnucash-docs/commit/e72a420d (commit) > > > > > > > > commit 8408cbac47146b97f324f89f677fe743b96b78b5 > > Author: Mechtilde > > Date: Thu Nov 5 19:41:20 2015 +0100 > > > > Change paper format to A4 for European PDFs. > > > > Japanese already sets the paper size. > > > > > > I just noticed this change. In the UK though I still get a pdf formatted for USletter. I guess we don't really need an en_GB translation to get A4 pages but how do British manuals get to be formatted to A4? Using locale perhaps? Mike E -- PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get=0x00CDB13500D7AB53 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Flickering drop down boxes on mouse over
On Wed, 30 Dec 2015 09:40:48 +0100 Geert Janssens <geert.gnuc...@kobaltwit.be> wrote: > On Monday 28 December 2015 15:12:26 Mike Evans wrote: > > The dropdown selection boxes in a register or invoice view flicker, as > > if they're having multiple refreshes, each time the mouse pointer > > enters or leaves the box. Has anyone else experienced this? I'm Using > > Fedora18 32 bit OS. I'm not quite sure when this started, several > > weeks or so. Just asking here before I file a bug just in case it's > > not GnuCash but some other system glitch. > > > > Mike E > > I only got to testing this now. > > I'm seeing this as well on Fedora 22, 64bit. > > I never noticed this before because I'm usually using keyboard navigation in > the register views. > > Geert It appears this is related to display settings in KDE, at least in my case it is. Logging out and in using the failsafe options, in which I just get an xterm, GnuCash doesn't have this issue. Neither does my laptop running PCLinuxOS and KDE. I'm just remembering that some months ago KDE screwed up my settings (again) amongst the issues was the disappearance lots of icons. My usual recovery method is deleting .kde directory and starting again. I'm thinking that this is about the time the trouble started. I also note that the button to activate the dropdown is round not square like it used to be and on my laptop. Somewhere in my settings/themes/appearance setup there's probably a way to bring some sanity back to the desktop settings. Somewhere... Mike E -- PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get=0x00CDB13500D7AB53 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Flickering drop down boxes on mouse over
On Tue, 29 Dec 2015 06:58:52 -0800 (PST) david.carlson@gmail.comwrote: > I just read that 4K displays only refresh at 30 hz if they are connected > through a standard HDMI cable. Could you be seeing something along that line? > > HDMI? Dear me no. I don't have anything that new in the house. Just regular LCD monitors with VGA input. No TV either. Although I have updated my computer to a donated Dell Dimension 8300 lately. Same video card though. Thinks... Mike E -- PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get=0x00CDB13500D7AB53 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Flickering drop down boxes on mouse over
On Tue, 29 Dec 2015 14:13:21 +0100 "Frank H. Ellenberger" <frank.h.ellenber...@gmail.com> wrote: > Am 28.12.2015 um 16:12 schrieb Mike Evans: > > The dropdown selection boxes in a register or invoice view flicker, as if > > they're having multiple refreshes, each time the mouse pointer enters or > > leaves the box. Has anyone else experienced this? I'm Using Fedora18 32 bit > > OS. I'm not quite sure when this started, several weeks or so. Just asking > > here before I file a bug just in case it's not GnuCash but some other > > system glitch. > > > > Mike E > > > > I can confirm it for git Version 8838cee+ from 2015-12-27 > and Version df6326f+ from 2015-07-10 (2.6.7) > > FEll I've just gone back to a (random) commit in Jan 2014 and it still flickers. I can't believe it's been doing that for two years and I haven't noticed it so it must(?) be something has changed outside of GnuCash. Mike E -- PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get=0x00CDB13500D7AB53 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Flickering drop down boxes on mouse over
The dropdown selection boxes in a register or invoice view flicker, as if they're having multiple refreshes, each time the mouse pointer enters or leaves the box. Has anyone else experienced this? I'm Using Fedora18 32 bit OS. I'm not quite sure when this started, several weeks or so. Just asking here before I file a bug just in case it's not GnuCash but some other system glitch. Mike E -- PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get=0x00CDB13500D7AB53 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
FYI. Bitcoin news.
CFTC Holds that Bitcoin and Other Virtual Currencies Are a Commodity Covered by the Commodity Exchange Act. http://www.cftc.gov/PressRoom/PressReleases/pr7231-15 -- PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get=0x00CDB13500D7AB53 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Using LibreOffice for Documentation
On Fri, 04 Sep 2015 11:48:16 +0200 Geert Janssenswrote: > I never new something as a master document existed in libreoffice. I'm > learning a lot from this > thread :) > > Other than the concerns Tommy Trussell already mentioned I worry about > merging. > > Can you run this test: > 1. make two branches > 2. Make independent changes in both branches > 3. merge from one branch to the other > > > Regards, > > Geert This breaks things. My simple test: git checkout -b 1 edit git ci -a git checkout master git checkout -b 2 edit git ci -a git merge 1 warning: Cannot merge binary files: ch_loans.odt (HEAD vs. 1) Auto-merging ch_loans.odt CONFLICT (content): Merge conflict in ch_loans.odt Automatic merge failed; fix conflicts and then commit the result. Note the cannot merge part. I guess that resolves that then. No to LibreOffice docs, or I guess any non-plain text file format. I know we could unzip the odt files to get the plain text content and work with that but I'm it's not really a practical solution is it? Mike E -- PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get=0x00CDB13500D7AB53 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Using LibreOffice for Documentation
A new but related thread then. It seems many documenters are not prepared to accept anything but a WYSIWIG solution, even though I feel then learning the arcanery of LibreOffice is harder than learning Asciidoc. Oh well. LibreOffice was mentioned ealier, somewhere so I thought I'd experiment a bit. I've put the results of my experiment at https://github.com/EvansMike/gnucash-opendocs It's not a perfect conversion but reasonably good. Each file is still separate, and git trackable, and these are included into the master document "guide.odm". Just thought I'd throw it into the mix. Mike E ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Using AsciiDoc for Documentation
On Wed, 2 Sep 2015 22:06:30 -0400 "David T." <sunfis...@yahoo.com> wrote: > I mean, if there actually were a group of even 4 people actively working on > documentation in any given month, I would be surprised. Given this reality, > is it REALLY necessary to use industrial version control on two (admittedly > somewhat complex) documents? Regarding this... Running git log c180e4d1548857.. --format="%aN" --reverse | sort | uniq which gives all the authors this year, in gnucash-docs returns the following list Alex Aycinena Benjamin Melançon Carl Reinke Chris Good Cristian Marchi DanielDodson David David T Derek Atkins Dmitry Pavlov Frank H. Ellenberger Geert Janssens John Ralls Mark Simpson Martin Mainka Mechtilde Mechtilde Stehmann Mike Evans Raphael Kubo da Costa which is 17 (after removing duplicates). Mike E -- PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get=0x00CDB13500D7AB53 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Using AsciiDoc for Documentation
On Tue, 1 Sep 2015 13:44:39 -0500 Rob Gowin <r...@gowin.net> wrote: > > > On Sep 1, 2015, at 4:56 AM, Mike Evans <mi...@saxicola.co.uk> wrote: > >> [snip] > > > > Hi Rob > > > > Looks good to me. Still a few minor bugs with the Asciidoc. > > > > Some of the Figure titles are missing > > Second level bullet indents missing > > > > But these are minor and some tweaking of the XSL should fix that. Speaking > > of which, I notice the XSL isn't in github can you make that available > > somewhere so others can chip in with help? I'd also like to generate the > > Asciidoc locally so I can ensure both formats are from the same source for > > comparison purposes. > > > > Now you (we) have to convince others to use Asciidoc! > > > > I use Geany for my coding/writing and there is a Markdown plugin for > > preview, no Asciidoc at the moment though. I'm looking at the PEG code to > > see how difficult it would be to produce an Asciidoc previewer plugin. It > > may be beyond my learning tolerance though. > > > > Mike E > > > > > > > > -- > > PGP key: > > http://pgp.mit.edu:11371/pks/lookup?op=get=0x00CDB13500D7AB53 > > > Hi Mike, > > Thanks for taking a look. I have put the XSL file and a python > script to run the conversion process in a repository at > https://github.com/codesmythe/asciidoc-conversion. See the README > there for details. > > As for editors, I just use a command line converter and then > reload the generated HTML into a browser. I need to try some of the > live preview editors mentioned in the link you sent out yesterday. > > I'll look at the issues you mentioned in the next couple of days. > > Thanks, > > Rob > > > Hi Rob Bearing in mind this would only ever need to be run once for each document set and that Asciidoc may not be adopted anyway it's probably not worth spending a lot of effort on those final issues for the moment. They can likely be easily(ish) fixed manually after conversion. Mike E -- PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get=0x00CDB13500D7AB53 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Using AsciiDoc for Documentation
On Sun, 30 Aug 2015 19:16:24 -0500 Rob Gowin <r...@gowin.net> wrote: > [Hello List. Long time GnuCash user, -devel list lurker, > coming out of the shadows.] > > > On Aug 29, 2015, at 5:43 AM, Mike Evans <mi...@saxicola.co.uk> wrote: > > Another random thought then. > > > > I use asciidoc for pretty much all the docs I write, not much > > admittedly but it's easy to learn and can produce many output formats. > > I just used https://github.com/oreillymedia/docbook2asciidoc to > > convert the guide to asciidoc using: > > > > $ java -jar /home/mikee/Projects/docbook2asciidoc/saxon9he.jar > > -s gnucash-guide.xml -o gnucash-guide.asc > > /home/mikee/Projects/docbook2asciidoc/d2a.xsl chunk-output=true > > > > This produces an asccidoc file for each chapter plus the master page. > > > > [...] > > > > I'm not an expert on XML parsing using .xsl stylesheets but I suspect > > this could be easily(?) remedied by editing the d2a.xsl to correctly > > include the figures[...] > > I am also a fan of using AsciiDoc as a documentation format. A > while back I did some of the XSL hacking Mike refers to that is needed > to get a decent conversion from the existing DocBook files. It's to > the point where I would like to get some feedback. > > I've done a first-pass conversion of the English version of the T & CG to > AsciiDoc at https://github.com/codesmythe/gnucash-docs/tree/asciidoc/guide/C > . > You can click on the *.asc files there like ch_oview.asc to see GitHub's > rendered verison of the file, including non-SVG images. (Note that SVG files > and inter-chapter links don't work on GitHub's render.) You can click on the > 'Raw' button for a file to see the AsciiDoc source. The source needs clean > up > (lines too long, etc), but it is clean enough for folks to get an idea of > the > syntax. The GitHub web interace is useful because I think small edits could > be > done and sent as pull requests all from the web. > > Like Mike said, the AsciiDoc tools (asciidoctor, at http://asciidoctor.org > in > this case) support the generation of DocBook XML files, so it's relatively > simple to insert AsciiDoc support into the current document generation > flow. > The asciidoctor tool generates DocBook output, and the existing flow for > generating PDFs, HTML, EPUB, MOBI etc. works the same. My branch has the > changes to the various Makefile.am files to support this. Those interested > should be able to clone the repo, switch to the asciidoc branch and then > 'make > pdf' as usual. Note that the 'configure' script will expect to find the > asciidoctor program on the system. I think the generated PDF is reasonably > close to the original for a first pass proof of concept. I've tested the > flow > on OS X and Fedora 21. Dunno about Windows. > > Hopefully this little demo can move the documentation file format > discussion > forward a bit. :-) Thoughts? > > > Regards, > > Rob Hi Rob Looks good to me. Still a few minor bugs with the Asciidoc. Some of the Figure titles are missing Second level bullet indents missing But these are minor and some tweaking of the XSL should fix that. Speaking of which, I notice the XSL isn't in github can you make that available somewhere so others can chip in with help? I'd also like to generate the Asciidoc locally so I can ensure both formats are from the same source for comparison purposes. Now you (we) have to convince others to use Asciidoc! I use Geany for my coding/writing and there is a Markdown plugin for preview, no Asciidoc at the moment though. I'm looking at the PEG code to see how difficult it would be to produce an Asciidoc previewer plugin. It may be beyond my learning tolerance though. Mike E -- PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get=0x00CDB13500D7AB53 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Replacing Docbook
On Sat, 29 Aug 2015 16:52:48 +0200 Geert Janssens <geert.gnuc...@kobaltwit.be> wrote: > On Saturday 29 August 2015 06:38:53 John Ralls wrote: > > > On Aug 29, 2015, at 5:43 AM, Mike Evans <mi...@saxicola.co.uk> > > > wrote: > > > > > > Another random thought then. > > > > > > I use asciidoc for pretty much all the docs I write, not much > > > admittedly but it's easy to learn and can produce many output > > > formats. I just used > > > https://github.com/oreillymedia/docbook2asciidoc to convert the > > > guide to asciidoc using: > > > > > > $ java -jar /home/mikee/Projects/docbook2asciidoc/saxon9he.jar -s > > > gnucash-guide.xml -o gnucash-guide.asc > > > /home/mikee/Projects/docbook2asciidoc/d2a.xsl chunk-output=true > > > > > > This produces an asccidoc file for each chapter plus the master > > > page. Converting this to html using > > > > > > $ asciidoc gnucash-guide.asc > > > > > > produces the entire guide as html, of course many other output > > > formats are possible including docbook. The only issue is that > > > *none* of the figures are included. I'm not an expert on XML > > > parsing using .xsl stylesheets but I suspect this could be > > > easily(?) remedied by editing the d2a.xsl to correctly include the > > > figures, as I say I'm no expert here. Some of the (inevitable) > > > minor formatting issues can be solved manually. > > > > > > If solving the figures issue is possible then the documenters would > > > need to learn asciidoc markup. This is a lot easier than docbook > > > though and since all the files are just plain ascii tracking > > > changes in GIT are straightforward. The concept of separate files > > > for each chapter is also preserved. > > > > > > As I say, just a thought. > > > > > > Incidentally LibreOffice can also use multi-file documents/books, > > > but I agree that change tracking is a barrier. > > Mike, > > > > Gee, deja-vu: > > http://lists.gnucash.org/pipermail/gnucash-devel/2013-December/036626 > > .html and following. > > > Informative thread... :) > > It seems we're still rather stuck at the same spot. > > The only new element so far is the detail that started this whole discussion > again: doxigen > can now parse markdown. > > So yesterday I also did some first research on markdown as possible > alternative. > > Pros: > - relatively simple language so fairly easy to learn > - It's widely used so it seems to attract several developers to write tools > for it. While I haven't > immediately found true wysiwyg editors there are several editors available > (both online and > offline) that show live previews for all OS's we currently support. > - Convertible into most formats we care about, including docbook (via > doxigen). > > Cons: > - still a language to learn > - no true wysiwyg editors (at least I haven't found one yet) > > What I haven't investigated yet is how easy/hard it would be to convert the > existing > documentation, nor how it deals with images and links when used in offline > mode. > > Geert Some potentially useful asciidoc editors http://asciidoctor.org/docs/editing-asciidoc-with-live-preview/ Mike E -- PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get=0x00CDB13500D7AB53 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Replacing Docbook
On Sat, 29 Aug 2015 06:38:53 -0700 John Ralls jra...@ceridwen.us wrote: On Aug 29, 2015, at 5:43 AM, Mike Evans mi...@saxicola.co.uk wrote: Another random thought then. I use asciidoc for pretty much all the docs I write, not much admittedly but it's easy to learn and can produce many output formats. I just used https://github.com/oreillymedia/docbook2asciidoc to convert the guide to asciidoc using: $ java -jar /home/mikee/Projects/docbook2asciidoc/saxon9he.jar -s gnucash-guide.xml -o gnucash-guide.asc /home/mikee/Projects/docbook2asciidoc/d2a.xsl chunk-output=true This produces an asccidoc file for each chapter plus the master page. Converting this to html using $ asciidoc gnucash-guide.asc produces the entire guide as html, of course many other output formats are possible including docbook. The only issue is that *none* of the figures are included. I'm not an expert on XML parsing using .xsl stylesheets but I suspect this could be easily(?) remedied by editing the d2a.xsl to correctly include the figures, as I say I'm no expert here. Some of the (inevitable) minor formatting issues can be solved manually. If solving the figures issue is possible then the documenters would need to learn asciidoc markup. This is a lot easier than docbook though and since all the files are just plain ascii tracking changes in GIT are straightforward. The concept of separate files for each chapter is also preserved. As I say, just a thought. Incidentally LibreOffice can also use multi-file documents/books, but I agree that change tracking is a barrier. Mike, Gee, deja-vu: http://lists.gnucash.org/pipermail/gnucash-devel/2013-December/036626.html and following. Regards, John Ralls Oh dear, early stages of dementia perhaps? -- PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x00CDB13500D7AB53 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Replacing Docbook
On Fri, 28 Aug 2015 21:38:18 +0200 Geert Janssens geert.gnuc...@kobaltwit.be wrote: SNIP I did the same exercise just now. Note that I used the latest svn revision of docbook2odf (r253) which is slightly more recent than the ones found on the download page. The screenshots are all there on my system, although many of them are improperly sized. That's probably because we have been sloppy at that in our docbook version as well and just relied on the images being viewed at 100% size. That's probably not ok in odt which is geared towards printing. During the conversion there was an error for 4 pnm image files not being found. I suspect these are the images used to highlight warnings and tips and such. I didn't see those in the odt file. The image we had in multiple resolutions (the accounting equation) is added 3 times, probably because we had specified it 3 times in our source. The table of contents is missing as is the list of figures and tables. It's getting worse: all cross-references are gone. And worse: I did one single edit - remove the vertical docbook2odf banner. I did so by removing the page header in the page settings. This resulted in a git diff of a whopping +1351/-1368 line changes. Most of the changes are arbitrary like styles changing names, changing regional settings, adding soft-page-breaks,... Of course this can all be easily committed into git. However it will be rather difficult to follow changes made if the patches are so full of gratuitous changes. If we can't get libreoffice to make less noisy diffs, it's very unlikely it will be in improvement over the current situation. Regards, Geert Another random thought then. I use asciidoc for pretty much all the docs I write, not much admittedly but it's easy to learn and can produce many output formats. I just used https://github.com/oreillymedia/docbook2asciidoc to convert the guide to asciidoc using: $ java -jar /home/mikee/Projects/docbook2asciidoc/saxon9he.jar -s gnucash-guide.xml -o gnucash-guide.asc /home/mikee/Projects/docbook2asciidoc/d2a.xsl chunk-output=true This produces an asccidoc file for each chapter plus the master page. Converting this to html using $ asciidoc gnucash-guide.asc produces the entire guide as html, of course many other output formats are possible including docbook. The only issue is that *none* of the figures are included. I'm not an expert on XML parsing using .xsl stylesheets but I suspect this could be easily(?) remedied by editing the d2a.xsl to correctly include the figures, as I say I'm no expert here. Some of the (inevitable) minor formatting issues can be solved manually. If solving the figures issue is possible then the documenters would need to learn asciidoc markup. This is a lot easier than docbook though and since all the files are just plain ascii tracking changes in GIT are straightforward. The concept of separate files for each chapter is also preserved. As I say, just a thought. Incidentally LibreOffice can also use multi-file documents/books, but I agree that change tracking is a barrier. Mike E ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Replacing Docbook
On Fri, 28 Aug 2015 15:15:58 +0100 Mike Evans mi...@saxicola.co.uk wrote: On Fri, 28 Aug 2015 11:00:26 +0200 Geert Janssens geert.gnuc...@kobaltwit.be wrote: On Friday 28 August 2015 09:45:44 John Ralls wrote: On Aug 28, 2015, at 9:03 AM, Geert Janssens geert.gnuc...@kobaltwit.be wrote: Thanks for the heads up. That's certainly an interesting opportunity to check out. On the other hand I wonder if markdown has enough structure enforcement (for example to ensure contributors will really use header markup instead of bold/underline where needed). I do agree that docbook xml is a big hurdle for newcomers and even not really appealing to more experienced people. So if we can find a good middleground I'd be all for it. Here's another option I have been pondering for a while, and just now took the time to do some minimal research on: http://blog.riemann.cc/2013/04/23/versioning-of-openoffice-libreoff ice-documents-using-git/#comment-2209333934 http://blog.riemann.cc/2013/04/23/versioning-of-openoffice-libreof fice-documents-using-git/#comment-2209333934 Move away from docbook completely and instead save our documents in flat odt. Advantages: - This is a format that's easy to store and manage in git. - There is a free wysiwyg editor that's universally available: libreoffice. Most people learn how to use it relatively quickly as most of them have used word processors before. - libreoffice can export to pdf. I even installed a plugin once to convert odt to epub, which worked reasonably well. - libreoffice can also be used headless for document conversion so it can be integrated in automated build processes. - in theory libreoffice can even export to html (though I have no idea of the quality). I’ve used libre/openoffice to create html. It works reasonably well. Calibre’s docs say it can ingest ODT, which will take care of the ebook and mobi outputs. http://open.comsultia.com/docbook2odf/about http://open.comsultia.com/docbook2odf/about looks like the least-obsolete way to convert from DocBook to ODT. Its SVN repo was last updated in 2009 but our DocBook version is pretty old too so it will probably work OK. Any disadvantages? The first one is mentioned in a comment of the blog post I referred to: libreoffice saves soft page breaks. These tend to all shift up and down when making edits. So the diffs will be slightly cluttered. We may be able to fix these by simply filtering them out before committing, however that would again mean a manual action for the contributor. We may also just decide to live with them. That's the only disadvantage I'm currently aware of. A trial run will likely give us more insight and in worst case reveal potential show-stoppers. Geert I just tried docbook2odf with the guide and it does a reasonably good job. Some imgaes need resizing and there's a Generated by docbooktoodf side bar on every page. A little editing though and it should look OK. Using GIT with LibreOffice works quite well after installing some python utils. Mike E Oh, dear. More scrolling revealed loads of missing images. Mike E -- PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x00CDB13500D7AB53 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Replacing Docbook
On Fri, 28 Aug 2015 11:00:26 +0200 Geert Janssens geert.gnuc...@kobaltwit.be wrote: On Friday 28 August 2015 09:45:44 John Ralls wrote: On Aug 28, 2015, at 9:03 AM, Geert Janssens geert.gnuc...@kobaltwit.be wrote: Thanks for the heads up. That's certainly an interesting opportunity to check out. On the other hand I wonder if markdown has enough structure enforcement (for example to ensure contributors will really use header markup instead of bold/underline where needed). I do agree that docbook xml is a big hurdle for newcomers and even not really appealing to more experienced people. So if we can find a good middleground I'd be all for it. Here's another option I have been pondering for a while, and just now took the time to do some minimal research on: http://blog.riemann.cc/2013/04/23/versioning-of-openoffice-libreoff ice-documents-using-git/#comment-2209333934 http://blog.riemann.cc/2013/04/23/versioning-of-openoffice-libreof fice-documents-using-git/#comment-2209333934 Move away from docbook completely and instead save our documents in flat odt. Advantages: - This is a format that's easy to store and manage in git. - There is a free wysiwyg editor that's universally available: libreoffice. Most people learn how to use it relatively quickly as most of them have used word processors before. - libreoffice can export to pdf. I even installed a plugin once to convert odt to epub, which worked reasonably well. - libreoffice can also be used headless for document conversion so it can be integrated in automated build processes. - in theory libreoffice can even export to html (though I have no idea of the quality). I’ve used libre/openoffice to create html. It works reasonably well. Calibre’s docs say it can ingest ODT, which will take care of the ebook and mobi outputs. http://open.comsultia.com/docbook2odf/about http://open.comsultia.com/docbook2odf/about looks like the least-obsolete way to convert from DocBook to ODT. Its SVN repo was last updated in 2009 but our DocBook version is pretty old too so it will probably work OK. Any disadvantages? The first one is mentioned in a comment of the blog post I referred to: libreoffice saves soft page breaks. These tend to all shift up and down when making edits. So the diffs will be slightly cluttered. We may be able to fix these by simply filtering them out before committing, however that would again mean a manual action for the contributor. We may also just decide to live with them. That's the only disadvantage I'm currently aware of. A trial run will likely give us more insight and in worst case reveal potential show-stoppers. Geert I just tried docbook2odf with the guide and it does a reasonably good job. Some imgaes need resizing and there's a Generated by docbooktoodf side bar on every page. A little editing though and it should look OK. Using GIT with LibreOffice works quite well after installing some python utils. Mike E -- PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x00CDB13500D7AB53 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: How are Budgets Implemented in GNU Cash
On Thu, 16 Jul 2015 19:10:46 +1000 Matt Graham matt_graham2...@hotmail.com wrote: I would like to contribute to GNUCash, and get into the development side of the house. I figure that a (relatively) quick and easy contribution (that will also help me personally) is for me to create a patch to correct the bug where budgeted expenses don’t show up in the summary section at the bottom of the screen (https://bugzilla.gnome.org/show_bug.cgi?id=742352). My problem is that I cannot find (from the documentation) where the budget side of code is implemented within GNU Cash (even after much Googling). Can anyone steer me towards somewhere to look for more information about how Budgets are implemented? Thanks, Matt Have look in: http://svn.gnucash.org/docs/HEAD/group__budget.html src/engine/gnc-budget.c src/doc/budget.txt Not sure how up to date that document is though. -- Anti NSA? Use PGP. http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x00CDB13500D7AB53 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Make check fails in src/import-export
On Sun, 11 Jan 2015 19:02:22 +0100 Geert Janssens geert.gnuc...@kobaltwit.be wrote: On Sunday 11 January 2015 09:43:48 John Ralls wrote: On Jan 11, 2015, at 9:33 AM, Mike Evans mi...@saxicola.co.uk wrote: On Sun, 11 Jan 2015 09:16:19 -0800 John Ralls jra...@ceridwen.us wrote: On Jan 11, 2015, at 8:31 AM, Mike Evans mi...@saxicola.co.uk wrote: With the following output snippet: make[2]: Entering directory `/home/mikee/Projects/gnucash/build/src/import-export/test' PASS: test-link Backtrace: In ../../../src/app-utils/gnucash/app-utils.scm: 29: 0* (use-modules (gnucash gettext)) 29: 1 (eval-case (# # *unspecified*) (else #)) 29: 2 (begin (process-use-modules (list (list #))) *unspecified*) In unknown file: ?: 3* [process-use-modules (((gnucash gettext)))] ?: 4 (let* ((interfaces #)) (call-with-deferred-observers (lambda () #))) ?: 5* [map #procedure #f (mif-args) (((gnucash gettext)))] ?: 6* [#procedure #f (mif-args) ((gnucash gettext))] ?: 7* (or (apply resolve-interface mif-args) (error no such module mif-args)) ?: 8* [apply #procedure resolve-interface (name . args) ((gnucash gettext))] ?: 9 [resolve-interface (gnucash gettext)] ... ?: 10 (let* (# # # # ...) (and # #) (if # public-i #)) ?: 11* (and (or (not module) (not public-i)) (error no code for module name)) ?: 12 [error no code for module (gnucash gettext)] ... ?: 13 [scm-error misc-error #f ...] unnamed port: In procedure scm-error in expression (scm-error (quote misc-error) #f ...): unnamed port: no code for module (gnucash gettext) FAIL: test-import-parse == 1 of 2 tests failed Please report to gnucash-devel@gnucash.org == make[2]: *** [check-TESTS] Error 1 make[2]: Leaving directory `/home/mikee/Projects/gnucash/build/src/import-export/test' make[1]: *** [check-am] Error 2 make[1]: Leaving directory `/home/mikee/Projects/gnucash/build/src/import-export/test' make: *** [check-recursive] Error 1 Thoughts? Could be a problem with a cached .go. Try deleting ~/.cache/guile and $PREFIX/share/gnucash/scm/ccache. Regards, John Ralls Hi John. rm -rf /home/mikee/.cache/* rm -rf /home/mikee/.ccache/* rm /home/mikee/progs/gnucash-maint/share/gnucash/scm/cache rm /home/mikee/progs/gnucash-maint/share/gnucash/scm/ccache Still same results. But from the backtrace, I have no ../../../src/app-utils/gnucash/app-utils.scm . This file is at actually at ../../../src/app-utils/app-utils.scm Where is this path defined? Those links are made by the scm-links target in src/app-utils/Makefile.am. Maybe you need to do a clean build. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel Or remove the hidden file .scm-links The links will then be regenerated. Geert Thanks Geert John. I did a fresh build and all was well again. I've added tests for when the deposit or withdrawal fields are either empty or are just space(es). MikeE -- Anti NSA? Use PGP. http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x00CDB13500D7AB53 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Make check fails in src/import-export
With the following output snippet: make[2]: Entering directory `/home/mikee/Projects/gnucash/build/src/import-export/test' PASS: test-link Backtrace: In ../../../src/app-utils/gnucash/app-utils.scm: 29: 0* (use-modules (gnucash gettext)) 29: 1 (eval-case (# # *unspecified*) (else #)) 29: 2 (begin (process-use-modules (list (list #))) *unspecified*) In unknown file: ?: 3* [process-use-modules (((gnucash gettext)))] ?: 4 (let* ((interfaces #)) (call-with-deferred-observers (lambda () #))) ?: 5* [map #procedure #f (mif-args) (((gnucash gettext)))] ?: 6* [#procedure #f (mif-args) ((gnucash gettext))] ?: 7* (or (apply resolve-interface mif-args) (error no such module mif-args)) ?: 8* [apply #procedure resolve-interface (name . args) ((gnucash gettext))] ?: 9 [resolve-interface (gnucash gettext)] ... ?: 10 (let* (# # # # ...) (and # #) (if # public-i #)) ?: 11* (and (or (not module) (not public-i)) (error no code for module name)) ?: 12 [error no code for module (gnucash gettext)] ... ?: 13 [scm-error misc-error #f ...] unnamed port: In procedure scm-error in expression (scm-error (quote misc-error) #f ...): unnamed port: no code for module (gnucash gettext) FAIL: test-import-parse == 1 of 2 tests failed Please report to gnucash-devel@gnucash.org == make[2]: *** [check-TESTS] Error 1 make[2]: Leaving directory `/home/mikee/Projects/gnucash/build/src/import-export/test' make[1]: *** [check-am] Error 2 make[1]: Leaving directory `/home/mikee/Projects/gnucash/build/src/import-export/test' make: *** [check-recursive] Error 1 Thoughts? Mike E -- Anti NSA? Use PGP. http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x00CDB13500D7AB53 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Make check fails in src/import-export
On Sun, 11 Jan 2015 09:16:19 -0800 John Ralls jra...@ceridwen.us wrote: On Jan 11, 2015, at 8:31 AM, Mike Evans mi...@saxicola.co.uk wrote: With the following output snippet: make[2]: Entering directory `/home/mikee/Projects/gnucash/build/src/import-export/test' PASS: test-link Backtrace: In ../../../src/app-utils/gnucash/app-utils.scm: 29: 0* (use-modules (gnucash gettext)) 29: 1 (eval-case (# # *unspecified*) (else #)) 29: 2 (begin (process-use-modules (list (list #))) *unspecified*) In unknown file: ?: 3* [process-use-modules (((gnucash gettext)))] ?: 4 (let* ((interfaces #)) (call-with-deferred-observers (lambda () #))) ?: 5* [map #procedure #f (mif-args) (((gnucash gettext)))] ?: 6* [#procedure #f (mif-args) ((gnucash gettext))] ?: 7* (or (apply resolve-interface mif-args) (error no such module mif-args)) ?: 8* [apply #procedure resolve-interface (name . args) ((gnucash gettext))] ?: 9 [resolve-interface (gnucash gettext)] ... ?: 10 (let* (# # # # ...) (and # #) (if # public-i #)) ?: 11* (and (or (not module) (not public-i)) (error no code for module name)) ?: 12 [error no code for module (gnucash gettext)] ... ?: 13 [scm-error misc-error #f ...] unnamed port: In procedure scm-error in expression (scm-error (quote misc-error) #f ...): unnamed port: no code for module (gnucash gettext) FAIL: test-import-parse == 1 of 2 tests failed Please report to gnucash-devel@gnucash.org == make[2]: *** [check-TESTS] Error 1 make[2]: Leaving directory `/home/mikee/Projects/gnucash/build/src/import-export/test' make[1]: *** [check-am] Error 2 make[1]: Leaving directory `/home/mikee/Projects/gnucash/build/src/import-export/test' make: *** [check-recursive] Error 1 Thoughts? Could be a problem with a cached .go. Try deleting ~/.cache/guile and $PREFIX/share/gnucash/scm/ccache. Regards, John Ralls Hi John. rm -rf /home/mikee/.cache/* rm -rf /home/mikee/.ccache/* rm /home/mikee/progs/gnucash-maint/share/gnucash/scm/cache rm /home/mikee/progs/gnucash-maint/share/gnucash/scm/ccache Still same results. But from the backtrace, I have no ../../../src/app-utils/gnucash/app-utils.scm . This file is at actually at ../../../src/app-utils/app-utils.scm Where is this path defined? MikeE -- Anti NSA? Use PGP. http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x00CDB13500D7AB53 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Bug 734183
On Wed, 06 Aug 2014 18:01:52 +0200 Geert Janssens janssens-ge...@telenet.be wrote: On Wednesday 06 August 2014 16:00:21 Mike Evans wrote: HiGeert. n is set to 25 using gnc_exp_parser_parse (discount, n, NULL); just after it's set to gnc_numeric_zero (); Taking the zeroing line out doesn't change the behaviour though. Oh right. Probably this isn't working for me because my decimal separator is ,. Sorry for the false suggestion. Where discount is read from the file. When the invoice is opened after import the 25.00 is shown in the discount column but the price hasn't been discounted, the line total is still at original price. The gncEntryGetDocDiscountValue () function calls the gncEntry::gncEntryRecomputeValues() function which should set he discount to be applied. Yes, it does. As an aside This is a horribly backward way of doing things and source of various bugs. We should definitely fix this at some point. I fixed the import file for my locale and reran the debugger. The gncEntryRecomputeValues function effectively does nothing in this case because the entry has no Invoice tax table set. The recalculation only happens when there is either a bill or an invoice tax table. So that would explain why the discount is not substracted. Geert Ah found it by looking in the .gnucash xml file. The discount is saved as 25/1 and the price as 75/1. In gncEntryComputeValues() the denom is read from the currency, ie 100 so it divides 25 by the denom and gets the wrong answers which is effectively zero. Hence no discount. I need to run gnc_numeric_convert(...) to set the denom correctly. Thanks Geert, sometimes just asking the questions out loud is what's needed. :) Mike -- Anti NSA? Use PGP. http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x00CDB13500D7AB53 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Bug 734183
Hi All I'm having a little trouble tracking this down, (some of) the code for creating an entry with discount is shown below: entry = gncEntryCreate (book); gncEntryBeginEdit(entry); // More code here... gnc_exp_parser_parse (discount, n, NULL); gncEntrySetInvDiscount (entry, n); gncEntrySetInvDiscountType (entry, text2disc_type (disc_type)); gncEntrySetInvDiscountHow (entry, text2disc_how (disc_how)); gncEntryCommitEdit(entry); n = gncEntryGetDocDiscountValue (entry, FALSE, TRUE, FALSE); DEBUG( Discount Value: %.2f\n,gnc_numeric_to_double(n)); gncInvoiceAddEntry (invoice, entry); Having set the Discount, How and Type, the DEBUG line outputs - Discount Value: 0.00 it should be the actual calculated discount. Why isn't the discount being set. calculated? Is there a step I've missed? Looking through gnc_entry_ledger_save_cells(...) in gncEntryLedgerModel.c I can't see anything else that needs to be done to set the required values. Code is in: src/plugins/bi_import/dialoc-bi-import.c Mike -- Anti NSA? Use PGP. http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x00CDB13500D7AB53 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Bug 734183
On Wed, 06 Aug 2014 15:49:08 +0200 Geert Janssens janssens-ge...@telenet.be wrote: On Wednesday 06 August 2014 10:25:12 Mike Evans wrote: Hi All I'm having a little trouble tracking this down, (some of) the code for creating an entry with discount is shown below: entry = gncEntryCreate (book); gncEntryBeginEdit(entry); // More code here... gnc_exp_parser_parse (discount, n, NULL); gncEntrySetInvDiscount (entry, n); gncEntrySetInvDiscountType (entry, text2disc_type (disc_type)); gncEntrySetInvDiscountHow (entry, text2disc_how (disc_how)); gncEntryCommitEdit(entry); n = gncEntryGetDocDiscountValue (entry, FALSE, TRUE, FALSE); DEBUG( Discount Value: %.2f\n,gnc_numeric_to_double(n)); gncInvoiceAddEntry (invoice, entry); Having set the Discount, How and Type, the DEBUG line outputs - Discount Value: 0.00 it should be the actual calculated discount. Why isn't the discount being set. calculated? Is there a step I've missed? Looking through gnc_entry_ledger_save_cells(...) in gncEntryLedgerModel.c I can't see anything else that needs to be done to set the required values. Code is in: src/plugins/bi_import/dialoc-bi-import.c Mike Mike, I have ran the the master branch as of July 4 through gdb. It doesn't have all the code exactly as you pasted in your mail, but it's similar enough IMO. The line gnc_exp_parser_parse (discount, n, NULL); sets n to 0 (more strictly {0, 1}, a gnc_numeric). That doesn't seem correct, or at least not what you are expecting since discount has a value of 25.0. Maybe you should set an error variable instead of NULL in that function call and check its value for more clues. Geert HiGeert. n is set to 25 using gnc_exp_parser_parse (discount, n, NULL); just after it's set to gnc_numeric_zero (); Taking the zeroing line out doesn't change the behaviour though. Where discount is read from the file. When the invoice is opened after import the 25.00 is shown in the discount column but the price hasn't been discounted, the line total is still at original price. The gncEntryGetDocDiscountValue () function calls the gncEntry::gncEntryRecomputeValues() function which should set he discount to be applied. -- Anti NSA? Use PGP. http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x00CDB13500D7AB53 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Import CSV Bills Invoices - Notes field
On Wed, 18 Jun 2014 01:36:04 -0700 JP Liew jpl...@yahoo.com wrote: Hi all, I did a search and was not able to find an answer to my question. Basically, I would like to write an eBay or Paypal sales to GnuCash invoice converter that will export eBay/PayPal sales to GnuCash CSV file that can be imported by the Import Bills Invoices. The prototype works ok except I was not able to figure out how to deal with multi-line Notes. In GnuCash, a user can type multi-line notes, however in CSV, I was not able to find a way to code the CR / LF in the Notes field. If anyone has done this before, could you share some lights please? If not, can any let me know the actual src that is dealing with the part of the import please? https://github.com/Gnucash/gnucash/tree/master/src/import-export/csv-imp Cheers John Hi John. You should just be able to insert '\n' where you want the newline. Regarding e-bay to invoices, I wrote a utility to create Bills from ebay purchases, there may be something useful in there. https://github.com/EvansMike/pycash/tree/master/ebay2gnuCash Mike E -- Anti NSA? Use PGP. http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x00CDB13500D7AB53 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Compile fails latest maint 8d723f1b
My system is Fedora 18, 32bit. ../../../../src/libqof/qof/gnc-numeric.c:47:11: error: integer constant is so large that it is unsigned [-Werror] ../../../../src/libqof/qof/gnc-numeric.c:47:11: error: this decimal constant is unsigned only in ISO C90 [-Werror] cc1: all warnings being treated as errors Mike E -- Anti NSA? Use PGP. http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x00CDB13500D7AB53 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gnucash-docs master: Correct field format in python-import-fields.
On Thu, 05 Jun 2014 09:58:25 +0200 Geert Janssens janssens-ge...@telenet.be wrote: On Monday 02 June 2014 07:39:57 Mike Evans wrote: Updated via https://github.com/Gnucash/gnucash-docs/commit/f3dbb107 (commit) from https://github.com/Gnucash/gnucash-docs/commit/6a5083c3 (commit) commit f3dbb1071c46d409f4d7ecf060cb2c279572ed42 Author: Mike Evans mi...@millstreamcomputing.co.uk Date: Mon Jun 2 12:53:01 2014 +0100 Correct field format in python-import-fields. Summary of changes: guide/C/ch_import_business_data.xml | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) ___ gnucash-patches mailing list gnucash-patc...@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-patches Mike, Shouldn't this change have gone into the maint branch ? It looks like a bugfix to me. Or does it fix something that's only wrong on the master branch ? Geert Hi Geert. Yes it probably should. Do I merge this or cherry-pick into maint? Mike E -- Anti NSA? Use PGP. http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x00CDB13500D7AB53 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Make check files with python bindings.
On Fri, 16 May 2014 11:38:59 -0700 John Ralls jra...@ceridwen.us wrote: On May 16, 2014, at 9:24 AM, Mike Evans mi...@saxicola.co.uk wrote: make check-TESTS make[1]: Entering directory `/home/mikee/Projects/gnucash/build/src/optional/python-bindings/tests' Traceback (most recent call last): File ./runTests.py, line 8, in module from test import ImportError: cannot import name test_support FAIL: runTests.py == 1 of 1 test failed Please report to gnucash-devel@gnucash.org == make[1]: *** [check-TESTS] Error 1 make[1]: Leaving directory `/home/mikee/Projects/gnucash/build/src/optional/python-bindings/tests' make: *** [check-am] Error 2 This is on Fedora18. There is no module test_support. Modifying runTests.py.in as below fixes the test. #!/usr/bin/python import unittest import os os.environ[GNC_UNINSTALLED] = 1 #from test import test_support from test_book import TestBook from test_account import TestAccount from test_split import TestSplit from test_transaction import TestTransaction from test_business import TestBusiness def test_main(): #test_support.run_unittest(TestBook, TestAccount, TestSplit, TestTransaction, TestBusiness) unittest.main() if __name__ == '__main__': test_main() ### This is vaguely related to bug 730255. Adding a test for that bug causes the test to fail again. (As it should). Just wondering if I've understood the test system before I commit and push this. Just a guess: You’re using Python3, where the test_support module has been renamed “support”. If so, it should be: import sys if sys.version_info[0] 3: from test import test_support else: from test import support as test_support And uncomment the line test_support.run_unittest… Regards, John Ralls Hi John Python 2.7.3. from test import test_support ImportError: cannot import name test_support Mike Evans -- Anti NSA? Use PGP. http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x00CDB13500D7AB53 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Make check files with python bindings.
On Sat, 17 May 2014 13:06 +0200 Geert Janssens janssens-ge...@telenet.be wrote: Do you have the python-test package installed ? Fedora has separated the test support from python-devel. I ran into this a few months back on Fedora 19 (20?) as well. Geert Yes I do. Package python-test-2.7.3-13.fc18.i686 already installed and latest version On My system: rpm -qi --whatprovides /usr/lib/python2.7/test/test_support.py Name: python-libs Version : 2.7.3 Release : 13.fc18 ... So test support is installed it seems. I can import test but there are no modules in test. NB: Reading the Python docs at https://docs.python.org/2/library/test.html The top of the page says: ''' Note The test package is meant for internal use by Python only. It is documented for the benefit of the core developers of Python. Any use of this package outside of Python’s standard library is discouraged as code mentioned here can change or be removed without notice between releases of Python. ''' ? Mike Evans On Saturday 17 May 2014 11:40:52 Mike Evans wrote: On Fri, 16 May 2014 11:38:59 -0700 John Ralls jra...@ceridwen.us wrote: On May 16, 2014, at 9:24 AM, Mike Evans mi...@saxicola.co.uk wrote: make check-TESTS make[1]: Entering directory `/home/mikee/Projects/gnucash/build/src/optional/python-bindings/ tests' Traceback (most recent call last): File ./runTests.py, line 8, in module from test import ImportError: cannot import name test_support FAIL: runTests.py == 1 of 1 test failed Please report to gnucash-devel@gnucash.org == make[1]: *** [check-TESTS] Error 1 make[1]: Leaving directory `/home/mikee/Projects/gnucash/build/src/optional/python-bindings/ tests' make: *** [check-am] Error 2 This is on Fedora18. There is no module test_support. Modifying runTests.py.in as below fixes the test. #!/usr/bin/python import unittest import os os.environ[GNC_UNINSTALLED] = 1 #from test import test_support from test_book import TestBook from test_account import TestAccount from test_split import TestSplit from test_transaction import TestTransaction from test_business import TestBusiness def test_main(): #test_support.run_unittest(TestBook, TestAccount, TestSplit, TestTransaction, TestBusiness) unittest.main() if __name__ == '__main__': test_main() ### This is vaguely related to bug 730255. Adding a test for that bug causes the test to fail again. (As it should). Just wondering if I've understood the test system before I commit and push this. Just a guess: You’re using Python3, where the test_support module has been renamed “support”. If so, it should be: import sys if sys.version_info[0] 3: from test import test_support else: from test import support as test_support And uncomment the line test_support.run_unittest… Regards, John Ralls Hi John Python 2.7.3. from test import test_support ImportError: cannot import name test_support Mike Evans -- Anti NSA? Use PGP. http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x00CDB13500D7AB53 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Make check files with python bindings.
make check-TESTS make[1]: Entering directory `/home/mikee/Projects/gnucash/build/src/optional/python-bindings/tests' Traceback (most recent call last): File ./runTests.py, line 8, in module from test import ImportError: cannot import name test_support FAIL: runTests.py == 1 of 1 test failed Please report to gnucash-devel@gnucash.org == make[1]: *** [check-TESTS] Error 1 make[1]: Leaving directory `/home/mikee/Projects/gnucash/build/src/optional/python-bindings/tests' make: *** [check-am] Error 2 This is on Fedora18. There is no module test_support. Modifying runTests.py.in as below fixes the test. #!/usr/bin/python import unittest import os os.environ[GNC_UNINSTALLED] = 1 #from test import test_support from test_book import TestBook from test_account import TestAccount from test_split import TestSplit from test_transaction import TestTransaction from test_business import TestBusiness def test_main(): #test_support.run_unittest(TestBook, TestAccount, TestSplit, TestTransaction, TestBusiness) unittest.main() if __name__ == '__main__': test_main() ### This is vaguely related to bug 730255. Adding a test for that bug causes the test to fail again. (As it should). Just wondering if I've understood the test system before I commit and push this. Mike Evans -- Anti NSA? Use PGP. http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x00CDB13500D7AB53 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Business invoices over/pre payments
I've been struggling with paying multiple invoices with a single payment in version 2.6 and it doesn't work for me. I've been reverting to version 2.4.13 to process my invoices. Say I have two invoices the first for 400, the second for 600. I receive a singe payment, by bank transfer, of 1000. I open the payment dialog and pay 1000 against the first invoice. According to the mouseover text (below) the extra payment should be automatically assigned to the second invoice. This was the old behaviour and worked perfectly, matching up the reality of the 1000 deposit and paying off both invoices at a single stroke(or click). Now however I try to so the same in 2.6 and it doesn't put the overpayent towards the next invoice like it should. On attempting to pay the next invoice I see Pre-payment in the Process Payment dialog but no matter what I do with the Pre-payment it screws up my Bank register and doesn't get assigned to the invoice. Additionally, from the text below which states ...or if no invoice was selected... in either case I cannot make a payment without selecting an invoice. In short, the new invoice payment system is broken for me and I can't use version 2.6 for my business. mouse over text If you have selected an invoice, GnuCash will propose the amount still due for it. You can change this amount to create a partial payment or an over-payment. In case of an over-payment or if no invoice was selected, GnuCash will automatically assign the remaining amount to the first unpaid invoice for this company. If you have selected an invoice, GnuCash will propose the amount still due for it. You can change this amount to create a partial payment or an over-payment. In case of an over-payment or if no invoice was selected, GnuCash will automatically assign the remaining amount to the first unpaid invoice for this company. /mouse over text I thought I'd ask here in case I'd misunderstood the procedure before filing a bug report. Regards Mike E -- Anti NSA? Use PGP. http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x00CDB13500D7AB53 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Business invoices over/pre payments
On Wed, 30 Apr 2014 11:39:30 +0200 Geert Janssens janssens-ge...@telenet.be wrote: On Wednesday 30 April 2014 10:14:42 Mike Evans wrote: I've been struggling with paying multiple invoices with a single payment in version 2.6 and it doesn't work for me. I've been reverting to version 2.4.13 to process my invoices. I hope it's just due to poor documentation. Let's see... Say I have two invoices the first for 400, the second for 600. I receive a singe payment, by bank transfer, of 1000. I open the payment dialog and pay 1000 against the first invoice. Did you know you can select two invoices at the same time in the payment dialog ? If you have both invoices entered already that would be the easiest way to assign the payment to both invoices in one go. According to the mouseover text (below) the extra payment should be automatically assigned to the second invoice. This was the old behaviour and worked perfectly, matching up the reality of the 1000 deposit and paying off both invoices at a single stroke(or click). That old behaviour has been disabled by default because without it you have more control over which invoice gets paid by the overpayment. You can re-enable it via Preferences- Business. There's a separate checkbox to control the behaviour of invoices and bills. Now however I try to so the same in 2.6 and it doesn't put the overpayent towards the next invoice like it should. On attempting to pay the next invoice I see Pre-payment in the Process Payment dialog but no matter what I do with the Pre-payment it screws up my Bank register and doesn't get assigned to the invoice. Again, if you want to assign the pre-payment to your invoice you should select both the invoice and the pre-payment. That should render the amount to pay to zero and disable the transfer account list. If you now hit the ok button the payment will be assigned to the selected invoice without adding an extra line in your checkings account. Note that this only works correctly as of gnucash 2.6.3. Additionally, from the text below which states ...or if no invoice was selected... in either case I cannot make a payment without selecting an invoice. In short, the new invoice payment system is broken for me and I can't use version 2.6 for my business. I hope we're just dealing with ambiguous help texts here... mouse over text If you have selected an invoice, GnuCash will propose the amount still due for it. You can change this amount to create a partial payment or an over-payment. In case of an over-payment or if no invoice was selected, GnuCash will automatically assign the remaining amount to the first unpaid invoice for this company. If you have selected an invoice, GnuCash will propose the amount still due for it. You can change this amount to create a partial payment or an over-payment. In case of an over-payment or if no invoice was selected, GnuCash will automatically assign the remaining amount to the first unpaid invoice for this company. /mouse over text It looks to me this text has not been updated from the 2.4 era. In 2.6 you can select several invoice/payment lines together not one single invoice only. Additionally the over-payments are only automatically assigned to new invoices if the option is enabled in the preferences. Any suggestion for a better mouse over text ? Geert Hi Geert. Ah OK, that clears everything up. I didn't know about selecting multiple invoices and/or Pre-payments, or the Preferences option. It definitely needs to go in the documentation. As to mouse over text and the manual, I obviously need to have more experience with the new-fangled way of doing things before suggesting anything. :) The two paras below are just me confirming the behaviour, it all seems to work as intended. As a test in a new file I created two invoices of 400 each, posted them and received 1000 which I paid against invoice-01. Then selecting invoice-02 + Prepayment(of 600) again processed the payment. Now looking at my checking account I see 1000 in and 200 out. But I wanted to keep that 200 against the next invoice I give the customer. I can however delete that entry from the bank register and all is well again. Now reopening the test account, without saving (in order to try again) I do as above except, for invoice-02 I again select both the invoice and the Pre-payment and attempt to set it up so that the I get to keep the extra money. On opening the dialog, in the Amount section, Payment = 0.0 and refund = 200, but I want to keep the 200. The customer is happy that I do this obviously. Setting Refund to 0.0 greys out entire Transfer Account tree, which was a little confusing as I thought I'd screwed up again, but clicking OK processes the money the way I want. I get to keep the money! I assume you refer to Auto pay on posting in the Preferences
Re: Business invoices over/pre payments
On Wed, 30 Apr 2014 13:39:15 +0200 Geert Janssens janssens-ge...@telenet.be wrote: On Wednesday 30 April 2014 12:07:06 Mike Evans wrote: Hi Geert. Ah OK, that clears everything up. I didn't know about selecting multiple invoices and/or Pre-payments, or the Preferences option. It definitely needs to go in the documentation. As to mouse over text and the manual, I obviously need to have more experience with the new-fangled way of doing things before suggesting anything. :) The two paras below are just me confirming the behaviour, it all seems to work as intended. As a test in a new file I created two invoices of 400 each, posted them and received 1000 which I paid against invoice-01. Then selecting invoice-02 + Prepayment(of 600) again processed the payment. Now looking at my checking account I see 1000 in and 200 out. But I wanted to keep that 200 against the next invoice I give the customer. I can however delete that entry from the bank register and all is well again. Now reopening the test account, without saving (in order to try again) I do as above except, for invoice-02 I again select both the invoice and the Pre-payment and attempt to set it up so that the I get to keep the extra money. On opening the dialog, in the Amount section, Payment = 0.0 and refund = 200, but I want to keep the 200. The customer is happy that I do this obviously. Setting Refund to 0.0 greys out entire Transfer Account tree, which was a little confusing as I thought I'd screwed up again, but clicking OK processes the money the way I want. I get to keep the money! I assume you refer to Auto pay on posting in the Preferences dialog? This only works when posting a new invoice when a Pre-payment is already present. If the two invoices are already posted before the (over)payment then the automatic payment doesn't happen, as it used to. I had to unpost then re-post invoice-02 for this to work. Perhaps I mis-understood again. That's a subtle change in behaviour indeed. It works as follows: If you select any invoice in the payment dialog it will only evaluate those invoices for the payment. If you want the payment dialog to evaluate all open invoices (i.e. the old behaviour), you should ensure no invoice is selected at all. Aha but, the only way to have no invoices selected is to open the payment dialog via Business-Customer-Process Payment, when not currently in an invoice tab, then select a customer. But now the OK button is inactive and there's a warning that says I must select at least on document or pre-payment to process. Ah. I've just discovered that CTRL+L_Button toggles the selection. The above still applies though, inactive OK. It's been a couple of months since I have written this code and I can't remember exactly if I tested all variations with outstanding pre-payments as well. I *believe* the above should count for pre-payments as well. If you want full automatic assignment don't select any line in the payment dialog, only enter an amount. Thanks for clearing up my confusion Geert. I should open a bug (or two) for updating the manual and the mouseover texts so this doesn't get forgotten about. Please do, thank you. Geert -- Anti NSA? Use PGP. http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x00CDB13500D7AB53 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Python bindings: Account.getName() raises TypeError
On Mon, 17 Mar 2014 10:32:17 + Mike Evans mi...@saxicola.idps.co.uk wrote: On Mon, 17 Mar 2014 11:26:30 +0100 Felix Schwarz felix.schw...@oss.schwarz.eu wrote: Am 17.03.2014 11:21, schrieb Mike Evans: new_book_with_opening_balances.py works for me too on Fedora18 and SWIG Version 2.0.8. Which version of gnucash are you using? If I'm not mistaken the F18 gnucash is still 2.4, right? Compilied from sources, Git master Mike E I take it back. It was using the site-packages installed via yum, GnuCash 2.4.13. On removing the yum provided site-packages/gnucash dir and adding the correct path I get the same error as Felix Schwarz. Sorry for the confusion, I forgot I still had the GnuCash rpm installed. Mike E -- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Python bindings: Account.getName() raises TypeError
On Sun, 16 Mar 2014 13:41:42 -0700 David Osguthorpe david.osgutho...@gmail.com wrote: On Sun, Mar 16, 2014 at 08:54:10PM +0100, Felix Schwarz wrote: Am 16.03.2014 20:38, schrieb John Ralls: The signature of xaccAccountGetName is const char* xaccAccountGetName (const Account *); the const was added in 2005. A const Account * is not the same as an Account const *: The former means that the contents of the pointer won't change, the latter means that the pointer itself won't change (see https://www.cs.bu.edu/teaching/cpp/const/). Somewhere in the SWIG-generated Python-to-C translation code the argument type is wrong, but it's not directly in the stack trace from Python. It's more likely due to a change in SWIG than to a change in GnuCash. Thank you very much for the insights - seems really easy to miss. I'll take a look at the SWIG files and the generated code then. But that means it would be interesting if gnucash's example script works for anyone, right? If we had a success report this might provide some insight about the relevant swig changes. not all the example scripts work - but this one does for me (the business ones have issues) also you need slightly different arguments now because of the xml/sqlite possibility David new_book_with_opening_balances.py works for me too on Fedora18 and SWIG Version 2.0.8. Mike E -- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Python bindings: Account.getName() raises TypeError
On Mon, 17 Mar 2014 11:26:30 +0100 Felix Schwarz felix.schw...@oss.schwarz.eu wrote: Am 17.03.2014 11:21, schrieb Mike Evans: new_book_with_opening_balances.py works for me too on Fedora18 and SWIG Version 2.0.8. Which version of gnucash are you using? If I'm not mistaken the F18 gnucash is still 2.4, right? Compilied from sources, Git master Mike E -- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Poll: when to migrate code to the new server?
On Tue, 21 Jan 2014 11:52:12 -0500 Derek Atkins warl...@mit.edu wrote: Hi, The new-code server is just about ready for migration. I've got most of the services already installed and tested, (although some less vital services have not been fully tested yet). My main question is when to migrate? One thing to keep in mind is that the new server will not support subversion (except in a read-only fashion so existing trac URLs will work). This means that once we migrate the 2.4 series will be dead, unless we upgrade the build server to handle 2.4 from git. Migration will require downtime, probably a good 4 hours (or more) in order to make sure data isn't changing as the migration occurs. I've pre-copied most of the data already so subsequent rsyncs should be faster. But then I'll also need to test everything to make sure it's working, and I'll have to migrate/upgrade mediawiki by hand. So this is a long-winded way of asking when we think 2.4 will be completely done and when I should schedule the migration? I know 2.6.1 is planned for this weekend, so I'm assuming it'll be at least the following week, so maybe the weekend of Feb 1-2? -derek Fine by me too. Mike E -- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Documentation file format
On Sun, 15 Dec 2013 14:58:21 -0500 Mike Alexander m...@umich.edu wrote: On Dec 15, 2013, at 8:13 AM, Geert Janssens janssens-ge...@telenet.be wrote: Or if we want to stick with docbook, I searched for docbook wysiwyg. Most editors are proprietary and pricey. But there is also serna-free [1], which claims to be a near wysiwyg editor that can handle docbook 4 (according to a nabble thread from last year August [2]). I haven't had time to experiment with it though. They certainly are expensive. I used to be a developer on Arbortext's Epic product, now marketed as PTC Arbortext Editor. It would be a good tool for this, but it is very expensive. It's also essentially Windows only (there used to be a Linux version, but I'm not sure it's still maintained). Things like that would perhaps be overkill for this anyway. They are designed for very complex documents, like an aircraft parts manual. Because of this, they assume a support staff that can help with setup and customization. There is a page at http://www.firebirdsql.org/manual/docwritehowto-docbook-authoring-tools.html that lists a few cheap or free DocBook editors. Also http://www.happy-monkey.net/docbook/gui-editor.html claims there is a free personal edition of , but I can't find it. Mike XMLMind's XXE can be found via: http://www.xlingpaper.org/?page_id=51 Mike E -- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Documentation file format
On Fri, 13 Dec 2013 08:26:42 +0100 Christian Stimming christ...@cstimming.de wrote: I know I'm jumping in rather late in this thread, but here's my take on the ever-long question of our documentation file formats: I think the priority of the documentation file format should be: - to generate HTML and PDF output from it - and to make it easy for documentation writers to edit the text As secondary goals, I think it is nice to be able to generate epub and mobi output and also yelp's output from this (or does yelp read docbook natively?!), but I think those are not as important. Given these priorities, I think both our current documentation file format and also a potential wiki workflow might not be the best solution. Instead of the current file format (docbook xml, split into several files using xml entities) we should very well think to switch to some other solution that makes the text much more accessible for documentation writers. For example, if libreoffice/openoffice would be able to use the docbook xml file, except for the fact that it's split into multiple files using xml entities, then we should just as well drop the split file approach and merge the full text into one single docbook xml document. However, this wasn't the only problem with libreoffice, IIRC, but I'm not sure. If we just don't fine any up-to-date word processor that can work with the docbook xml, I would suggest to switch to a different file format instead, such as ODF or similar, and just continue working on the document with libreoffice et al. If a wiki approach is possible without too many extra steps in a workflow, that's fine as well, but I'm afraid it adds a whole lot of extra problems into the process. For example, what would be the process to generate a new gnucash-docs release package so that gnucash can be installed with at least as much offline available documentation as we have today? If there are solutions for this, then fine, a wiki based solution might be a good way to continue. Otherwise I'd suggest to simply switch to a better file format. Regards, Christian ___ Since no-one has mentioned it yet, what about asciidoc? It's much simpler that the xml we have now, is very easy to learn, it is plain text, it handles multi-part books, and AFAIK the current docbook can be converted to asciidoc without *too* much effort. It's just a thought because I use it for pretty much all the documentation I write. It's not WYSIWYG but it's a lot better than directly editing docbook.xml. I guess LibreOffice can be used as long as it doesn't introduce artifacts into the plain text, although a plain text editor would be better, vi|emacs|geany perhaps. Anyway, my 2p|2c Mike E -- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Backwards compatibility with new currency issue and bug 336843.
While testing bug 336843 patch for backwards compatibility with 2.4.13, I was getting this output below. The file fails to load. * 11:49:30 WARN gnc.io [valid_commodity()] Invalid commodity: 0 fraction * 11:49:30 WARN gnc.io [gnc_commodity_end_handler()] Invalid commodity parsed gnc:commodity version=2.0.0 cmdty:spaceISO4217/cmdty:space cmdty:id/cmdty:id cmdty:slots slot slot:keyuser_symbol/slot:key slot:value type=stringZK/slot:value /slot /cmdty:slots /gnc:commodity * 11:49:31 WARN gnc.backend [gnc_xml_be_load_from_file()] Syntax error in Xml File /home/mikee/Projects/gnucash-tutorial/data/test.gnucash * 11:49:31 CRIT GLib g_hash_table_foreach: assertion `version == hash_table-version' failed * 11:49:31 CRIT GLib g_hash_table_foreach: assertion `version == hash_table-version' failed * 11:49:31 CRIT GLib g_hash_table_foreach: assertion `version == hash_table-version' failed * 11:49:31 CRIT GLib g_hash_table_foreach: assertion `version == hash_table-version' failed It seemed clear this wasn't related to the patch so with a new test file, I first opened a new test file using trunk code, made a small change in a register (I added a space in a transaction description), saved the file and closed. On reopening with 2.4.13 I see the above output. The new ZMW currency was introduced in May with r22965, commit ab0cfdce5a. Reverting the commit fixes the problem, but obviously this is not a fix and the problem lies elsewhere. I'll file a bug for this, I mention here only as information for anyone following the bug 336843 thread. OS = Fedora 18. My GnuCash-2.4.13 is from the Fedora repo. and it's build date is Wed 24 Apr 2013 20:51:06 BST. Mike Evans. -- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
FYI internet speed tests.
Speeds are in Kilobytes so x 8 for Kilobits 2013-10-21 13:16:49 (388 KB/s) 2013-10-21 13:35:38 (798 KB/s) 2013-10-21 14:03:15 (783 KB/s) 2013-10-21 16:03:16 (756 KB/s) 2013-10-21 18:03:16 (790 KB/s) 2013-10-21 20:03:40 (291 KB/s) 2013-10-21 22:03:22 (536 KB/s) 2013-10-22 00:03:16 (786 KB/s) 2013-10-22 02:03:15 (797 KB/s) 2013-10-22 04:03:15 (796 KB/s) 2013-10-22 06:03:16 (797 KB/s) 2013-10-22 08:03:16 (791 KB/s) 2013-10-22 10:03:16 (798 KB/s) 2013-10-22 12:03:15 (795 KB/s) 2013-10-22 14:03:16 (795 KB/s) 2013-10-22 16:03:15 (789 KB/s) 2013-10-22 18:03:15 (792 KB/s) 2013-10-22 20:03:20 (608 KB/s) 2013-10-22 22:03:17 (730 KB/s) 2013-10-23 00:03:16 (797 KB/s) 2013-10-23 04:03:15 (798 KB/s) 2013-10-23 06:03:16 (790 KB/s) 2013-10-23 08:03:15 (798 KB/s) 2013-10-23 10:03:16 (751 KB/s) 2013-10-23 12:03:16 (792 KB/s) Slows down at about 8pm it seems. Mike E (neighbour) -- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: FYI internet speed tests.
On Wed, 23 Oct 2013 12:14:47 +0100 Mike Evans mi...@saxicola.idps.co.uk wrote: Speeds are in Kilobytes so x 8 for Kilobits 2013-10-21 13:16:49 (388 KB/s) 2013-10-21 13:35:38 (798 KB/s) 2013-10-21 14:03:15 (783 KB/s) 2013-10-21 16:03:16 (756 KB/s) 2013-10-21 18:03:16 (790 KB/s) 2013-10-21 20:03:40 (291 KB/s) 2013-10-21 22:03:22 (536 KB/s) 2013-10-22 00:03:16 (786 KB/s) 2013-10-22 02:03:15 (797 KB/s) 2013-10-22 04:03:15 (796 KB/s) 2013-10-22 06:03:16 (797 KB/s) 2013-10-22 08:03:16 (791 KB/s) 2013-10-22 10:03:16 (798 KB/s) 2013-10-22 12:03:15 (795 KB/s) 2013-10-22 14:03:16 (795 KB/s) 2013-10-22 16:03:15 (789 KB/s) 2013-10-22 18:03:15 (792 KB/s) 2013-10-22 20:03:20 (608 KB/s) 2013-10-22 22:03:17 (730 KB/s) 2013-10-23 00:03:16 (797 KB/s) 2013-10-23 04:03:15 (798 KB/s) 2013-10-23 06:03:16 (790 KB/s) 2013-10-23 08:03:15 (798 KB/s) 2013-10-23 10:03:16 (751 KB/s) 2013-10-23 12:03:16 (792 KB/s) Slows down at about 8pm it seems. Oops, wrong list! Still, someone might be interested. :) -- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Latest 2.5 build crashes at start
On Tue, 22 Oct 2013 09:56:52 +0200 Geert Janssens janssens-ge...@telenet.be wrote: On Monday 21 October 2013 10:53:06 Mike Evans wrote: The latest devel version crashes at start with: * 10:32:03 WARN gnc.scm *** GnuCash switched to a new preferences system *** * 10:32:03 WARN gnc.scm Attempt to migrate your preferences from the old to the new system * 10:32:03 OTHER GLib-GIO Settings schema 'org.gnucash.dialogs.import.ofx' is not installed Trace/breakpoint trap (core dumped) On Linux FC18. My config options are: OPTIONS=--enable-debug --with-html-engine=webkit --enable-python --enable-ofx --enable-aqbanking Any thoughts? Mike E Mike, I have run into this a couple of times as well. There seems to be a bug in the build macro for gsettings.xml files (which comes straight from glib). I don't know the exact details, but in some circumstances the schema files don't get compiled if there are already compiled schemas. So if you have built gnucash without ofx support before and then reconfigure to also build ofx support, the ofx schema won't be built. IIRC this can be worked around by removing the installation directory, running a make clean in the build directory and then build/install again. Note that the same can happen with the optional aqbanking support. If someone can pinpoint the exact cause and knows a fix that would of course even be better. Geert Thanks Geert and John I started doing a bisect yesterday, but I was interrupted, then I broke something so it won't build at all. :( Now the build fails with: swig-core-utils-python.c:3624:3: error: implicit declaration of function 'gnc_gconf_get_path_prefix' [-Werror=implicit-function-declaration] swig-core-utils-python.c: In function '_wrap_gnc_gconf_set_path_prefix': swig-core-utils-python.c:3643:3: error: implicit declaration of function 'gnc_gconf_set_path_prefix' [-Werror=implicit-function-declaration] I'll get back to it today. -- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Latest 2.5 build crashes at start
On Tue, 22 Oct 2013 12:01:52 +0200 Geert Janssens janssens-ge...@telenet.be wrote: On Tuesday 22 October 2013 10:39:12 Mike Evans wrote: On Tue, 22 Oct 2013 09:56:52 +0200 Geert Janssens janssens-ge...@telenet.be wrote: On Monday 21 October 2013 10:53:06 Mike Evans wrote: The latest devel version crashes at start with: * 10:32:03 WARN gnc.scm *** GnuCash switched to a new preferences system *** * 10:32:03 WARN gnc.scm Attempt to migrate your preferences from the old to the new system * 10:32:03 OTHER GLib-GIO Settings schema 'org.gnucash.dialogs.import.ofx' is not installed Trace/breakpoint trap (core dumped) On Linux FC18. My config options are: OPTIONS=--enable-debug --with-html-engine=webkit --enable-python --enable-ofx --enable-aqbanking Any thoughts? Mike E Mike, I have run into this a couple of times as well. There seems to be a bug in the build macro for gsettings.xml files (which comes straight from glib). I don't know the exact details, but in some circumstances the schema files don't get compiled if there are already compiled schemas. So if you have built gnucash without ofx support before and then reconfigure to also build ofx support, the ofx schema won't be built. IIRC this can be worked around by removing the installation directory, running a make clean in the build directory and then build/install again. Note that the same can happen with the optional aqbanking support. If someone can pinpoint the exact cause and knows a fix that would of course even be better. Geert Thanks Geert and John I started doing a bisect yesterday, but I was interrupted, then I broke something so it won't build at all. :( Now the build fails with: swig-core-utils-python.c:3624:3: error: implicit declaration of function 'gnc_gconf_get_path_prefix' [-Werror=implicit-function-declaration] swig-core-utils-python.c: In function '_wrap_gnc_gconf_set_path_prefix': swig-core-utils-python.c:3643:3: error: implicit declaration of function 'gnc_gconf_set_path_prefix' [-Werror=implicit-function-declaration] I'll get back to it today. You can remove swig-core-utils-python.c from your build directory and rebuild. This is an autogenerated file, which is only regenerated if core-utils.i has changed. Unfortunately core-utils.i includes a number of (c-)header files (*.h). If any of these files changes, this is not detected by our makefiles. One occasion where this happens is r23253. The function gnc_gconf_get_path_prefix is dropped from gnc_prefs.h in that commit. gnc_prefs.h is included in core-utils.i, but swig-core-utils-python.c is no regenerated automatically. Geert Thanks Geert. Compiling now after distclean and ./autogen ... -- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Latest 2.5 build crashes at start
The latest devel version crashes at start with: * 10:32:03 WARN gnc.scm *** GnuCash switched to a new preferences system *** * 10:32:03 WARN gnc.scm Attempt to migrate your preferences from the old to the new system * 10:32:03 OTHER GLib-GIO Settings schema 'org.gnucash.dialogs.import.ofx' is not installed Trace/breakpoint trap (core dumped) On Linux FC18. My config options are: OPTIONS=--enable-debug --with-html-engine=webkit --enable-python --enable-ofx --enable-aqbanking Any thoughts? Mike E -- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r23175 - gnucash/trunk/src/gnome - Fix bug 699450
On Wed, 18 Sep 2013 11:56:37 +0200 Geert Janssens janssens-ge...@telenet.be wrote: On Wednesday 18 September 2013 05:40:45 Mike Evans wrote: Author: mikee Date: 2013-09-18 05:40:44 -0400 (Wed, 18 Sep 2013) New Revision: 23175 Trac: http://svn.gnucash.org/trac/changeset/23175 Modified: gnucash/trunk/src/gnome/gnc-budget-view.c Log: Fix bug 699450 * Remove extra call to gtk_tree_view_append_column. (It is already called in gnc_tree_view_account_add_custom_column.) Author: Robert Ratliff ratliff.bo...@gmail.com Modified: gnucash/trunk/src/gnome/gnc-budget-view.c == = --- gnucash/trunk/src/gnome/gnc-budget-view.c 2013-09-17 23:26:10 UTC (rev 23174) +++ gnucash/trunk/src/gnome/gnc-budget-view.c 2013-09-18 09:40:44 UTC (rev 23175) @@ -1007,6 +1007,7 @@ GtkTreeViewColumn *col; GList *col_list; GList *totals_col_list; +ENTER(view %p, view); g_return_if_fail(view != NULL); priv = GNC_BUDGET_VIEW_GET_PRIVATE(view); @@ -1058,7 +1059,7 @@ col = gbv_create_totals_column(view, num_periods_visible); if (col != NULL) { -gtk_tree_view_append_column(priv-totals_tree_view, col); +/*gtk_tree_view_append_column(priv-totals_tree_view, col);*/ totals_col_list = g_list_append(totals_col_list, col); } If they aren't needed, can you remove the line completely instead of just commenting them out ? That leaves us with both better functioning and easier to read code. @@ -1077,10 +1078,11 @@ col = gbv_create_totals_column(view, -1); if (col != NULL) { -gtk_tree_view_append_column(priv-totals_tree_view, col); +/*gtk_tree_view_append_column(priv-totals_tree_view, col);*/ } } Same here. Geert ___ Hi Geert Yep, I just applied the patch as is, I'll remove the comments. Mike Evans -- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Problem loading file
On Tue, 06 Aug 2013 10:29:35 -0400 Derek Atkins warl...@mit.edu wrote: Geert, Geert Janssens janssens-ge...@telenet.be writes: The function gnc:restore-report-by-guid-with-custom-template was added recently by me in the 2.5 series and is used to restore open reports. The function is written to the meta file in the .gnucash/books directory matching your gnucash book. This file is parsed when GnuCash opens your data file. So yes, if you had open reports when testing gnucash 2.5.2, this will result in a crash when trying to open the same book under the same user account with gnucash 2.4.x afterwards. My first reaction was to dismiss this as only a developer inconvenience, but that is not the only case this can happen. A user trying gnucash 2.6 but reverting back to 2.4 for whatever reason could run into this. So I should probably add some code to the 2.4.x series to at least not crash. Can you create a bug report for this so it doesn't get forgotten ? (I don't have time now to fix this immediately, sorry). Is there some way to have the code check whether the API exists and exit gracefully if it does not? e.g.: guile (defined? 'gnc:restore-report-by-guid-with-custom-template) #f guile (defined? 'car) #t So you could only call the API if it's defined? That way you wouldn't require changes to 2.4. Thank you, Geert -derek I get the same problem and since I see no bug has been created for this, I'll create one myself. Mike E On 04-08-13 15:53, Cristian Marchi wrote: Thanks, that could be the problem as under Ubuntu I occasionally open the file with 2.5 unstable version (without saving it) while on windoes I've only the stable version. I will try to use your suggested methed by finding the differences. Thanks for the tip Il 04/08/2013 13:48, Guilherme Salgado ha scritto: I seem to remember seeing something like this when I tried to open a file on GnuCash 2.4.12 after having opened it on 2.5.3 (trunk). Luckily I had a recent backup of my ~/.gnucash and after diffing the two it became obvious what lines I had to remove to stop 2.4.12 from crashing. The fact that you can open it on Windows is probably because your equivalent of ~/.gnucash there hasn't been tainted by GnuCash 2.5.3 On 4 August 2013 05:08, Cristian Marchi cr...@libero.it wrote: I've a problem opening a file with GnuCash under Ubuntu 12.10. This is the message I get when opening it from the terminal: Backtrace: In current input: 1: 0* (let* ((options #)) (let* (#) (# option)) (let* (#) (# option)) ...) 1: 1 (gnc:restore-report-by-guid-with-custom-template 0 ...) unnamed port:1:897: In expression (gnc:restore-report-by-guid-with-custom-template 0 b1f15b2052c149df93e698fe85a81ea6 ...): unnamed port:1:897: Unbound variable: gnc:restore-report-by-guid-with-custom-template I see the GnuCash splash screen and tip of the day, but then it exits. I can open it without problem in Windows XP. I also tried to copy all settings file from XP to Ubuntu but I get the same error message. I got it working by removing the all the ~/.gnucash folder. Any idea of what's going on? ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel -- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GnuCash releases ?
On Fri, 29 Mar 2013 10:12:50 -0700 John Ralls jra...@ceridwen.us wrote: On Mar 28, 2013, at 11:30 PM, John Ralls jra...@ceridwen.us wrote: On Mar 27, 2013, at 5:34 PM, John Ralls jra...@ceridwen.us wrote: On Mar 27, 2013, at 1:07 PM, Christian Stimming christ...@cstimming.de wrote: Am Mittwoch, 27. März 2013, 18:45:41 schrieb Geert Janssens: Two come to mind: 2.4.12 The previous release dates back to July 2012. Not that much has been going on on stable, but there are a number of bugfixes waiting to be released. I have read several suggestions from users that we're waiting too long to release them. I'd agree it's time to put out what we have. +1 from me on this. Let's do a 2.4.12 ASAP. 2.5.0 This was discussed before. The only remaining major items are gconf-gsettings and the register rewrite. I think I'll need too much time to finish gsettings to delay 2.5.0 for it. I intend to get it ready for 2.5.1 or 2.5.2. The register rewrite isn't done, but can already be used for testing and feedback purposes. So I would ask for a release somewhere in april. Thoughts ? +1 on that one, too. Let's get trunk get some wider audience. I agree on both as well. I'll do a make distcheck on both trunk and 2.4 tomorrow and report if there are any issues. If it looks good, we can release at the weekend. I finally got both environments set up properly and got to make distcheck -- and both failed. The first round of problems is that trunk has some files that are in POTFILES.skip but are also distributed (that's after fixing an oversight when I added the scheme files to POTfILES.skip). 2.4 fails configure (configure: error: Cannot find Glib Gettext. Maybe you need to install the gettext package?) when in built from the tarball-created dist directory. It's way past bedtime now, so I'll have at it tomorrow. On the trunk build, the POTFILES complaints are about the source files to build a couple of stand-alone programs, fini and financial. These are built with a hand-rolled makefile in src/app-utils/calculation called Makefile.calc. It's not part of the regular build. When calculation was a separate module these sources were included as an EXTRA_DIST in the main Makefile.am, but that was dropped when Christian moved them into app-utils. Has anyone *ever* used or even built them? Unless someone speaks up really soon, the two files that are part of the library are moving up a level into app-utils and the rest of calculation is going into the bit-bucket. Regards, John Ralls Not me, never knew they existed. Mike E -- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GnuCash releases ?
On Wed, 27 Mar 2013 17:34:53 -0700 John Ralls jra...@ceridwen.us wrote: On Mar 27, 2013, at 1:07 PM, Christian Stimming christ...@cstimming.de wrote: Am Mittwoch, 27. März 2013, 18:45:41 schrieb Geert Janssens: Two come to mind: 2.4.12 The previous release dates back to July 2012. Not that much has been going on on stable, but there are a number of bugfixes waiting to be released. I have read several suggestions from users that we're waiting too long to release them. I'd agree it's time to put out what we have. +1 from me on this. Let's do a 2.4.12 ASAP. 2.5.0 This was discussed before. The only remaining major items are gconf-gsettings and the register rewrite. I think I'll need too much time to finish gsettings to delay 2.5.0 for it. I intend to get it ready for 2.5.1 or 2.5.2. The register rewrite isn't done, but can already be used for testing and feedback purposes. So I would ask for a release somewhere in april. Thoughts ? +1 on that one, too. Let's get trunk get some wider audience. I agree on both as well. I'll do a make distcheck on both trunk and 2.4 tomorrow and report if there are any issues. If it looks good, we can release at the weekend. Regards, John Ralls +1 from me. I've made some (useful?) minor fixes to 2.4 recently that should see daylight. More testers on trunk are very much needed too. Mike E -- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: SVN-GIT link broken?
On Sun, 24 Mar 2013 10:55:47 + Mike Evans mi...@saxicola.idps.co.uk wrote: On Sun, 24 Mar 2013 00:52:25 -0400 Mike Alexander m...@umich.edu wrote: Is the mechanism that pushes changes from SVN to GIT not working right? I checked in a change nearly 5 hours ago which shows up in SVN (it's r22832) but it hasn't appeared in the GIT repository yet. I checked it in using git svn dcommit as usual and everything looked normal. Mike ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel Yep, Got them both. Ah. Ignore the last one. Replied to the wrong mail. Ooops. :) -- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: CRLF issues on checkout (was Re: Gnucash 2.5/6 - jqplot)
On Sat, 23 Feb 2013 10:19:25 +0100 Geert Janssens janssens-ge...@telenet.be wrote: Op 23-02-13 05:52, John Ralls schreef: On Feb 22, 2013, at 11:14 AM, Geert Janssens janssens-ge...@telenet.be wrote: Op 22-02-13 19:45, Geert Janssens schreef: Op 22-02-13 19:23, Mike Evans schreef: Thanks for checking Geert. I removed my $HOME/.gitconfig and tried again with the same result. My git version is 1.7.6.5 on Fedora 15 not sure it that makes any difference. Anyway now we know where the problem is (me) I know the solution is local. Enough for today though I think. My git version is git-1.8.1.2-1.fc18.i686 on Fedora 18. I don't know if that makes a difference or not. What exact url are you using to clone from github ? Mine is g...@github.com:Gnucash/gnucash.git Any other devs seeing this ? Geert Additionally, can you check if the eol attribute is already supported in your git version ? It is mentioned in man gitattributes on my system and is the attribute I'm using to force consistent line endings. It may be a more recent addition. Yeah, I see it on OSX. When I follow the renormalizing procedure, I get warning: CRLF will be replaced by LF in src/report/jqplot/foo.js. The file will have its original line endings in your working directory. For all of the files that Mike listed. Curiously, changing the *.js entry in .gitattributes to crlf and repeating the procedure has no effect. It appears that you got those js files into the repo with crlf line endings. git version 1.7.9.6 (Apple Git-31.1) The eol attribute is documented in gitattributes(5) Regards, John Ralls Ok, that is very likely. Can you or Mike check in the proper conversions ? They don't show up on my system (which I don't understand why that is). Geert OK checked in as r22808 4317a28b55655 Mike E -- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash 2.5/6 - jqplot
On Thu, 21 Feb 2013 18:55:31 +0100 Geert Janssens janssens-ge...@telenet.be wrote: Op 21-02-13 18:19, Mike Evans schreef: On Thu, 21 Feb 2013 18:04:37 +0100 Geert Janssens janssens-ge...@telenet.be wrote: Op 21-02-13 16:54, Mike Evans schreef: A git|svn|brain issue follows. Having updated to the latest source using git-update script I can't change branches because some of the files have the wrong line endings, unless I commit the changes. I get this message: Please, commit your changes or stash them before you can switch branches. Git stash doesn't work and I get similar output to that shown below. A git diff gives the following output. warning: CRLF will be replaced by LF in src/report/jqplot/excanvas.min.js. The file will have its original line endings in your working directory. warning: CRLF will be replaced by LF in src/report/jqplot/jquery.jqplot.min.js. The file will have its original line endings in your working directory. SNIP src/report/jqplot/plugins/jqplot.ciParser.min.js. The file will have its original line endings in your working directory. diff --git src/report/jqplot/excanvas.min.js src/report/jqplot/excanvas.min.js index 83373a5..e699a26 100644 --- src/report/jqplot/excanvas.min.js +++ src/report/jqplot/excanvas.min.js @@ -1,3 +1,3 @@ -/* jqPlot @VERSION | (c) 2009-2013 Chris Leonello | jplot.com - jsDate | (c) 2010-2013 Chris Leonello +/* jqPlot @VERSION | (c) 2009-2013 Chris Leonello | jplot.com + jsDate | (c) 2010-2013 Chris Leonello Um. Not sure what to do or why this situation occurred in the first place. I thought git took care of line ending translations. I can commmit locally then dcommit but is that going to screw it up for anyone else? Advice needed. My love/hate relationship with GIT continues. Mike Evans Mike, These happen because the git configuration didn't have a definition for the line ending style for javascript files (.js). While working on the charts I added this definition. Some files that were already in git before now are checked out with different line endings. Can you try to run git checkout src/report/jqplot/*.js git checkout src/report/jqplot/plugins/*.js Does that fix the issue ? Geert Hi Geert Afraid not. Can I modify my config file manually? What do I add|change if so? Mike E It looks like the solution needs slightly more work. Read the part Re-normalizing a repo on this page: https://help.github.com/articles/dealing-with-line-endings Be sure to commit or stash your real changes before following this procedure. If at the end there are still files complaining about CRLF vs LF, you commit those. That would mean I have messed up in my commit. Geert Hi Geert After doing that and making things somewhat worse, that is, getting even more files with line ending issues I git cloned a fresh copy of gnucash from GitHub. A git status gives me: # On branch trunk # Changes not staged for commit: # (use git add file... to update what will be committed) # (use git checkout -- file... to discard changes in working directory) # # modified: src/report/jqplot/excanvas.min.js # modified: src/report/jqplot/jquery.jqplot.min.js # modified: src/report/jqplot/plugins/jqplot.BezierCurveRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.barRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.blockRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.bubbleRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.canvasAxisLabelRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.canvasAxisTickRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.canvasOverlay.min.js # modified: src/report/jqplot/plugins/jqplot.canvasTextRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.categoryAxisRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.ciParser.min.js # Same files with line ending issues, but at least no warnings. It can't be just me surely? Although sometimes it seems to be :) Mike Evans -- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash 2.5/6 - jqplot
On Fri, 22 Feb 2013 18:47:48 +0100 Geert Janssens janssens-ge...@telenet.be wrote: Op 22-02-13 14:43, Mike Evans schreef: On Thu, 21 Feb 2013 18:55:31 +0100 Geert Janssens janssens-ge...@telenet.be wrote: Op 21-02-13 18:19, Mike Evans schreef: On Thu, 21 Feb 2013 18:04:37 +0100 Geert Janssens janssens-ge...@telenet.be wrote: Op 21-02-13 16:54, Mike Evans schreef: A git|svn|brain issue follows. Having updated to the latest source using git-update script I can't change branches because some of the files have the wrong line endings, unless I commit the changes. I get this message: Please, commit your changes or stash them before you can switch branches. Git stash doesn't work and I get similar output to that shown below. A git diff gives the following output. warning: CRLF will be replaced by LF in src/report/jqplot/excanvas.min.js. The file will have its original line endings in your working directory. warning: CRLF will be replaced by LF in src/report/jqplot/jquery.jqplot.min.js. The file will have its original line endings in your working directory. SNIP src/report/jqplot/plugins/jqplot.ciParser.min.js. The file will have its original line endings in your working directory. diff --git src/report/jqplot/excanvas.min.js src/report/jqplot/excanvas.min.js index 83373a5..e699a26 100644 --- src/report/jqplot/excanvas.min.js +++ src/report/jqplot/excanvas.min.js @@ -1,3 +1,3 @@ -/* jqPlot @VERSION | (c) 2009-2013 Chris Leonello | jplot.com - jsDate | (c) 2010-2013 Chris Leonello +/* jqPlot @VERSION | (c) 2009-2013 Chris Leonello | jplot.com + jsDate | (c) 2010-2013 Chris Leonello Um. Not sure what to do or why this situation occurred in the first place. I thought git took care of line ending translations. I can commmit locally then dcommit but is that going to screw it up for anyone else? Advice needed. My love/hate relationship with GIT continues. Mike Evans Mike, These happen because the git configuration didn't have a definition for the line ending style for javascript files (.js). While working on the charts I added this definition. Some files that were already in git before now are checked out with different line endings. Can you try to run git checkout src/report/jqplot/*.js git checkout src/report/jqplot/plugins/*.js Does that fix the issue ? Geert Hi Geert Afraid not. Can I modify my config file manually? What do I add|change if so? Mike E It looks like the solution needs slightly more work. Read the part Re-normalizing a repo on this page: https://help.github.com/articles/dealing-with-line-endings Be sure to commit or stash your real changes before following this procedure. If at the end there are still files complaining about CRLF vs LF, you commit those. That would mean I have messed up in my commit. Geert Hi Geert After doing that and making things somewhat worse, that is, getting even more files with line ending issues I git cloned a fresh copy of gnucash from GitHub. A git status gives me: # On branch trunk # Changes not staged for commit: # (use git add file... to update what will be committed) # (use git checkout -- file... to discard changes in working directory) # # modified: src/report/jqplot/excanvas.min.js # modified: src/report/jqplot/jquery.jqplot.min.js # modified: src/report/jqplot/plugins/jqplot.BezierCurveRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.barRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.blockRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.bubbleRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.canvasAxisLabelRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.canvasAxisTickRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.canvasOverlay.min.js # modified: src/report/jqplot/plugins/jqplot.canvasTextRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.categoryAxisRenderer.min.js # modified: src/report/jqplot/plugins/jqplot.ciParser.min.js # Same files with line ending issues, but at least no warnings. It can't be just me surely? Although sometimes it seems to be :) Mike Evans Just to test I did the same: cloned a fresh copy from GitHub and it doesn't show any modified files. We seem to have a mystery here... Let's try to find what is different between your and my setup. The only difference I can imagine to cause this would be if you have configured line ending preferences locally. Is there some config parameter related to line endings in your $HOME/.gitconfig file (like autocrlf) ? I don't have anything in there. Geert Thanks for checking Geert. I removed my $HOME/.gitconfig and tried again with the same result. My git version is 1.7.6.5 on Fedora 15 not sure
Re: Bugzilla default/QA assignees
On Mon, 18 Feb 2013 20:05:31 -0800 John Ralls jra...@ceridwen.us wrote: On Feb 18, 2013, at 5:43 PM, Chris Shoemaker c.shoema...@cox.net wrote: +1 ;) Well, well. Don't you get stiff lurking behind that fern? ;-) Regards, John Ralls [1] https://bugzilla.gnome.org/buglist.cgi?query_format=advanced;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;bug_status=NEEDINFO;component=Budgets;product=GnuCash On Mon, Feb 18, 2013 at 05:09:20PM -0800, John Ralls wrote: The default assignee field is mostly used to determine who gets bugmail for a particular component. Some of the assignments make sense, like having me be the default for Mac bugs, some not so much, like Chris Shoemaker for budget bugs: He hasn't been around for a long time. It also makes it hard for non-bugzilla-admins to set themselves up for bugmail on new bugs, because the mechanism for doing so is to watch another user. Watching a real user means that you get bug mail not only for the bugs that that user is the default assignee,QA contact, or added to the CC list, but also for every bug that user comments on. Not really useful unless you're a stalker. The mainstream Gnome approach is to have fake users for default assignees; for example, the Gtk Quartz backend has gtk-quartz-ma...@gnome.bugs, which I watch so that I get bug mail for any of those. I propose doing the same for our gnucash components, with a per-component address for default assignee and a gnucash-bugs address for QA assignee to make it easy to get all bugmail. I'll change the components, but I can't create the users because I don't have privs for doing that. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel I see a new bug (Bug 693948) assigned to Mark Jenkins and as QA contact. I don't think Mark is actively developing anymore(?). Having assignee and QA as the same person probably isn't a good idea either. Mike Evans -- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash 2.5/6 - jqplot
On Thu, 21 Feb 2013 12:47:18 +0100 Geert Janssens janssens-ge...@telenet.be wrote: Op 12-02-13 18:46, Geert Janssens schreef: There was another feature that briefly appeared on the trunk branch: dynamic graphical reports with jqplot. I wonder whatever happened with it. The base for jqplot is in the code repo, and I also remember having seen some example reports using it. I can't find those anymore though. I wonder if the original author was unsure to invest further in it because his jqplot work triggered a long discussion on where to go with the current report system. Lots of possibilities were offered, but in the end we're still using the report system basically unchanged. Since there's still no clear plan for the report system on the horizon, I would love to see jqplot being used for our graphical reports. If the original author is still around, I'd love to hear from him (her?). Other than that, anyone interested in looking into what's needed to convert a report to jqplot ? Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel Well, it turns out I was too curious myself already, so I checked a bit further. I found the original mailinglist thread [1] and the missing patch to enable the jqplot alternatives for most of our chart types. Due to the age of the patch there were a few issues, but with some tweaking I managed to get it to work again. I like the result so much better than the old goffice based charts that I have chosen to remove the goffice based ones. The old list thread also pointed at some issues with the jqplot charts. I think I have fixed most of them, except the labels running over one another if there are lots of data points. If any other issues pop up, please let me know. And a random list of things that should/could be done still: - remove the gog code (should) - labels running over one another if there are many data points - dynamic sizing as an alternative option to the fixed width/height we now have to specify - some more code optimizations, like * linking to minimized versions of the js files * drop some unused/invalid chart options (in js code that is) - add/improve interaction to the charts Most of these are minor tweaks. Even as they are now, the jquery based charts are ready for feature freeze, IMO. Geert [1] https://lists.gnucash.org/pipermail/gnucash-devel/2011-March/031322.html ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel Lovely charts Geert. Two of the features I added in the Net Worth line chart are obsoleted/broken. Optional grid and optional data markers no longer work as advertised so I'll have to look at them or remove them. Not really sure if either are necessary anyway. All the charts could possibly use an alternate black and white stylesheet for printing, is this easier to achieve using jqplot? This is not new because of jqplot though. Mike Evans -- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Bugzilla default/QA assignees
On Thu, 21 Feb 2013 10:07:02 -0500 Derek Atkins warl...@mit.edu wrote: Mike Evans mi...@saxicola.idps.co.uk writes: I see a new bug (Bug 693948) assigned to Mark Jenkins and as QA contact. I don't think Mark is actively developing anymore(?). Having assignee and QA as the same person probably isn't a good idea either. I don't even know who Mark Jenkins is! He's certainly not a GnuCash committer. Mike Evans -derek I think he's this guy on this page. http://www.parit.ca/about-parit/ Did a lot of work on the python bindings I believe. commit 4fa2e8796 etc. -- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash 2.5/6 - jqplot
On Thu, 21 Feb 2013 14:18:38 + Mike Evans mi...@saxicola.idps.co.uk wrote: On Thu, 21 Feb 2013 12:47:18 +0100 Geert Janssens janssens-ge...@telenet.be wrote: Op 12-02-13 18:46, Geert Janssens schreef: There was another feature that briefly appeared on the trunk branch: dynamic graphical reports with jqplot. I wonder whatever happened with it. The base for jqplot is in the code repo, and I also remember having seen some example reports using it. I can't find those anymore though. I wonder if the original author was unsure to invest further in it because his jqplot work triggered a long discussion on where to go with the current report system. Lots of possibilities were offered, but in the end we're still using the report system basically unchanged. Since there's still no clear plan for the report system on the horizon, I would love to see jqplot being used for our graphical reports. If the original author is still around, I'd love to hear from him (her?). Other than that, anyone interested in looking into what's needed to convert a report to jqplot ? Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel Well, it turns out I was too curious myself already, so I checked a bit further. I found the original mailinglist thread [1] and the missing patch to enable the jqplot alternatives for most of our chart types. Due to the age of the patch there were a few issues, but with some tweaking I managed to get it to work again. I like the result so much better than the old goffice based charts that I have chosen to remove the goffice based ones. The old list thread also pointed at some issues with the jqplot charts. I think I have fixed most of them, except the labels running over one another if there are lots of data points. If any other issues pop up, please let me know. And a random list of things that should/could be done still: - remove the gog code (should) - labels running over one another if there are many data points - dynamic sizing as an alternative option to the fixed width/height we now have to specify - some more code optimizations, like * linking to minimized versions of the js files * drop some unused/invalid chart options (in js code that is) - add/improve interaction to the charts Most of these are minor tweaks. Even as they are now, the jquery based charts are ready for feature freeze, IMO. Geert [1] https://lists.gnucash.org/pipermail/gnucash-devel/2011-March/031322.html ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel Lovely charts Geert. Two of the features I added in the Net Worth line chart are obsoleted/broken. Optional grid and optional data markers no longer work as advertised so I'll have to look at them or remove them. Not really sure if either are necessary anyway. All the charts could possibly use an alternate black and white stylesheet for printing, is this easier to achieve using jqplot? This is not new because of jqplot though. Mike Evans A git|svn|brain issue follows. Having updated to the latest source using git-update script I can't change branches because some of the files have the wrong line endings, unless I commit the changes. I get this message: Please, commit your changes or stash them before you can switch branches. Git stash doesn't work and I get similar output to that shown below. A git diff gives the following output. warning: CRLF will be replaced by LF in src/report/jqplot/excanvas.min.js. The file will have its original line endings in your working directory. warning: CRLF will be replaced by LF in src/report/jqplot/jquery.jqplot.min.js. The file will have its original line endings in your working directory. warning: CRLF will be replaced by LF in src/report/jqplot/plugins/jqplot.BezierCurveRenderer.min.js. The file will have its original line endings in your working directory. warning: CRLF will be replaced by LF in src/report/jqplot/plugins/jqplot.barRenderer.min.js. The file will have its original line endings in your working directory. warning: CRLF will be replaced by LF in src/report/jqplot/plugins/jqplot.blockRenderer.min.js. The file will have its original line endings in your working directory. warning: CRLF will be replaced by LF in src/report/jqplot/plugins/jqplot.bubbleRenderer.min.js. The file will have its original line endings in your working directory. warning: CRLF will be replaced by LF in src/report/jqplot/plugins/jqplot.canvasAxisLabelRenderer.min.js. The file will have its original line endings in your working directory. warning: CRLF will be replaced by LF in src/report/jqplot/plugins/jqplot.canvasOverlay.min.js
Re: Gnucash 2.5/6 - jqplot
On Thu, 21 Feb 2013 18:04:37 +0100 Geert Janssens janssens-ge...@telenet.be wrote: Op 21-02-13 16:54, Mike Evans schreef: A git|svn|brain issue follows. Having updated to the latest source using git-update script I can't change branches because some of the files have the wrong line endings, unless I commit the changes. I get this message: Please, commit your changes or stash them before you can switch branches. Git stash doesn't work and I get similar output to that shown below. A git diff gives the following output. warning: CRLF will be replaced by LF in src/report/jqplot/excanvas.min.js. The file will have its original line endings in your working directory. warning: CRLF will be replaced by LF in src/report/jqplot/jquery.jqplot.min.js. The file will have its original line endings in your working directory. SNIP src/report/jqplot/plugins/jqplot.ciParser.min.js. The file will have its original line endings in your working directory. diff --git src/report/jqplot/excanvas.min.js src/report/jqplot/excanvas.min.js index 83373a5..e699a26 100644 --- src/report/jqplot/excanvas.min.js +++ src/report/jqplot/excanvas.min.js @@ -1,3 +1,3 @@ -/* jqPlot @VERSION | (c) 2009-2013 Chris Leonello | jplot.com - jsDate | (c) 2010-2013 Chris Leonello +/* jqPlot @VERSION | (c) 2009-2013 Chris Leonello | jplot.com + jsDate | (c) 2010-2013 Chris Leonello Um. Not sure what to do or why this situation occurred in the first place. I thought git took care of line ending translations. I can commmit locally then dcommit but is that going to screw it up for anyone else? Advice needed. My love/hate relationship with GIT continues. Mike Evans Mike, These happen because the git configuration didn't have a definition for the line ending style for javascript files (.js). While working on the charts I added this definition. Some files that were already in git before now are checked out with different line endings. Can you try to run git checkout src/report/jqplot/*.js git checkout src/report/jqplot/plugins/*.js Does that fix the issue ? Geert Hi Geert Afraid not. Can I modify my config file manually? What do I add|change if so? Mike E -- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash 2.5/6 - jqplot
On Thu, 21 Feb 2013 18:16:53 +0100 Geert Janssens janssens-ge...@telenet.be wrote: Op 21-02-13 15:18, Mike Evans schreef: Lovely charts Geert. Two of the features I added in the Net Worth line chart are obsoleted/broken. Optional grid and optional data markers no longer work as advertised so I'll have to look at them or remove them. Not really sure if either are necessary anyway. Thanks, most of the credit goes to Andy Clayton though, who did most of the work. I mostly tuned and updated it. About the options, that got dropped, I didn't notice them, sorry. It shouldn't be too hard to add them again. I'll fix it in a next round. All the charts could possibly use an alternate black and white stylesheet for printing, is this easier to achieve using jqplot? This is not new because of jqplot though. It depends, but I don't think I understand exactly what you would like to achieve here. Can you elaborate a bit ? Geert Charts don't print very well on a BW laser. They didn't before to be fair. For BW the lines, text, borders etc., need to be black (obviously) with a different line style (dash type) for each data line. Basically a user should be able to toggle between BW and colour in the chart preferences. Just curious as to how hard this would be to implement. I don't know how many people would need this, so it probably isn't a high priority anyway. Mike Evans -- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash 2.5/6
On Sun, 17 Feb 2013 13:55:40 -0800 (PST) Phil Longstaff phil.longst...@yahoo.ca wrote: I created https://bugzilla.gnome.org/show_bug.cgi?id=694047 and attached an initial patch to that. That should allow you to get it in. I'll need to learn more about git. Phil From: John Ralls jra...@ceridwen.us To: Robert Fewell 14ubo...@gmail.com; Geert Janssens janssens-ge...@telenet.be Cc: gnucash-devel@gnucash.org Devel gnucash-devel@gnucash.org Sent: Tuesday, February 12, 2013 2:22:39 PM Subject: Re: Gnucash 2.5/6 On Feb 9, 2013, at 1:45 PM, lsl 14ubo...@gmail.com wrote: I am still plodding on with this and it is progressing slowly, have uploaded another patch to the bug which also indicates roughly what is left to do. I am not sure of any time scales but the menu options can be disabled or the whole lot can be removed if it is holding other things up. Assuming it is still viable, I will continue and progress it as time permits. Is this mostly working? If so, let's get it into trunk and ditch the old register. That will at least let us get rid of the project Ridley deprecated libraries. It will also get more people banging on it, which will bring any problems to light. Pending that and Phil's budgeting, I'm thinking we can release 2.5.0 next week. Regards, John Ralls I just tested Robert Fewell's patch in Bug 673193 and I realised it makes my reverse sort (Bug 683881, commit 679d59e44) work obsolete as sorting order can be changed by simply clicking in the column header. If the TreeView is going to become the standard then think I should remove my commit and mark the bug as obsolete. Thoughts? Mike Evans -- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash 2.5/6
On Fri, 08 Feb 2013 10:13:01 +0100 Geert Janssens janssens-ge...@telenet.be wrote: On 07-02-13 19:32, John Ralls wrote: Geert mentioned in the Notification Emails thread that he'd like to get 2.6 released in less than a year, and Christian was pushing to do so this time *last* year. On the principle that Release is a misnomer. Software is never released, it escapes. [1], it's probably time to release 2.5.0 so that we can at least start down that road. Shall we say feature freeze now, string freeze in July, 2.6 release 1 November? Or is anyone actively working on features that should go in? What became of the rewrite of the register to GtkTreeView? Failing that, has anyone taken a shot at rewriting it with Cairo instead of libgnome? Note that I'm not proposing a Gtk3 migration for 2.6: We're doing that at Gramps, and MSWin is proving to be troublesome. In fact, it appears that no one is supporting Gtk3-MSWin at the moment. Regards, John Ralls [1] I don't know where that originated. My wife brought it with her from DEC, where it was apparently a truism. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel I like to see a 2.5.0 fairly soon as well. All features I had planned are basically done. They still need a bit of polishing, but are fully functional. The GtkTreeView based register currently has basic functionality, but I haven't seen additional improvements in a while. To be honest, I haven't gotten around to test it more thoroughly. Perhaps Robert Fewell can chime in here. I also recently pinged Phil on switching to GSettings. He said he was going to take that up. I have no additional details, though it would make a nice addition for 2.6 as it would allow us to drop gconf on Windows and OS X. If we want this for 2.6, it will probably need to be a minor first implementation, of the replace-the-current-gconf-code-as-is kind. Not a complete overhaul of our preferences system. I have no idea what plans Phil has exactly, so I'll leave it up to him to give more details of what he's up to and if he considers it realistic to have something for 2.5/2.6. Last item is on our Feature Schedule [1]: Reversed sort order by date for transaction, a feature Mike Evans has been working on. As far as I can see it's mostly done. I reviewed his patch and gave my feedback. I don't know what kept Mike from completing it. Even as is, the patch is usable and useful already. Re ^: This currently doesn't save the reverse sort setting between runs, and I really didn't like the empty_split being at the bottom when reverse sorting. It is functional for people wanting to compare their on-screen, reverse-sorted bank accounts though. I just ran out of time, enthusiasm, money... I'll commit it as is but subsequent commits mean that the patch is obsolete and I'll have to revisit the code again. I also marked Bug 682732 as a blocker because it simply doesn't work for me. I think we either revert to the old CSV importer or fix the new version. Perhaps others could test it and update the bug. Mike Evans Let's hear what the others have to say. Geert [1] http://wiki.gnucash.org/wiki/Release_Schedule#Feature_Checklist_for_2.6.0 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel -- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Github Migration
On Fri, 1 Feb 2013 21:48:33 -0800 John Ralls jra...@ceridwen.us wrote: On Feb 1, 2013, at 9:38 PM, John Ralls jra...@ceridwen.us wrote: On Feb 1, 2013, at 8:57 PM, Mike Alexander m...@umich.edu wrote: If not I get a bunch of unresolvable references on this step after which none of the transfer/xxx branches exist. Really? That's interesting. I'm testing that avenue now. Nope, I get the same result either way. New remote branches, new remote tags. Everything's fine. Regards, John Ralls ___ Migration fails for me. Cloned the new git repo. just fine but then I'm asked multiple times for my ssh password when doing git svn init ..., until I got locked out. I'll ask Derek for an unlock when he's online then try again. Any thoughts? Mike Evans -- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Github Migration
On Sun, 3 Feb 2013 09:15:41 -0500 Derek Atkins de...@ihtfp.com wrote: On Sun, February 3, 2013 8:11 am, Mike Evans wrote: Migration fails for me. Cloned the new git repo. just fine but then I'm asked multiple times for my ssh password when doing git svn init ..., until I got locked out. If you're asked for your password then things are wrong. Code will never accept a password, so if it asks you might as well quit out. If you quit then you might not get locked out. But this implies your ssh key isn't around. Can you just do a normal svn svn+ssh:// command from the same account? I'll ask Derek for an unlock when he's online then try again. Any thoughts? Check your SVN URL and SSH config locally? Although if you were able to get a git checkout from code then you SHOULD be able to use SVN -- the keys should be the same set. Mike Evans -derek Thanks Derek Just calling the same command after unlocking worked fine. I didn't do anything else to make it work. Now to move all my branches. Mike Evans -- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Git migration - github vs code.gnucash.org
On Wed, 31 Oct 2012 19:26:05 -0700 John Ralls jra...@ceridwen.us wrote: On Oct 31, 2012, at 7:33 AM, Geert Janssens janssens-ge...@telenet.be wrote: This discussion has been had multiple times before and frankly I hope this will be the last time. The previous discussion didn't end in an explicit consensus, but I think we were close to finding a compromise at least. A summary: - Nobody opposed to using github. In fact most developers are in favour of using it. - John indicated that github is good, but we shouldn't use the github issue tracker or pull requests. They appear to be a source of trouble. - Mostly Derek insists on having a canonical repository on code.gnucash.org as well. Others haven't explicitly agreed or disagreed on this. - Yawar proposed to have the main activity run on github, and pull periodically to code.gnucash.org. The latter can be considered canonical. Let's continue to build on this. I propose this setup: One master repo hosted on github. One canonical repo on code.gnucash.org pulls periodically from this master repo to keep in sync. Only selected developers have commit access to the github repository. This is all access control we need here. All others that wish to contribute have to fork/clone this repository and send in patches. It looks like we better don't use github's issue tracker and pull request mechanisms. John stated this explicitly on the previous discussion, but there is criticism on these tools also in other (large) projects. Instead we continue to use our own contribution process, being: patches have to be sent to bugzilla or the mailing list (the latter has a higher risk of getting lost). Issues should be tracked in bugzilla. Ideas and requests could be tracked in either bugzilla or uservoice. There is also a feature on github to annotate patches (write inline comments). I don't know it's advantages or drawbacks, but given the opinion on pull requests and issue tracker, it's probably safe to not promote the annotation tool so far. Instead discussion of patches continues on the mailing lists as is now. I have not really decided yet how to handle access control to the canonical repository on code.gnucash.org yet. In principle nobody needs to push anything to this repo. It should simply fully automatically pull from the github master repo. But just in case for maintenance or other situations, I think it makes sense to allow push access by the same developers that currently can commit to svn on code.gnucash.org. I have deliberately skipped implementation details in this mail (how to enforce access control, how to trigger push/pull requests,...). I first would like to come to a consensus on the concept. Then work out the details. So any issues with this proposal ? (If so, please use bugzilla, not the github issue tracker ;p ). Or if you agree, please state so as well, so we can get an idea if we can pursue this proposal or not. Sounds good to me. Regards, John Ralls This gets my vote. Bugzilla is a far better tracking system than Guthub, IMHO. Mike Evans -- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Trivia: If GnuCash were a commercial program...
On Thu, 13 Sep 2012 20:20:33 +0200 Geert Janssens janssens-ge...@telenet.be wrote: ... it is estimated it would have costed about 90 person years to develop :) At least that's what the program sloccount claims. This is obviously not scientific calculation, just for fun. The program is primarily meant to calculate the effective source lines of code (sloc) in a project. I have ran it on GnuCash, here's the full summary for those interested: Totals grouped by language (dominant language first): ansic: 260622 (77.04%) lisp: 42674 (12.61%) sh: 16955 (5.01%) python:6823 (2.02%) cpp: 6387 (1.89%) perl: 4835 (1.43%) Total Physical Source Lines of Code (SLOC)= 338,296 Development Effort Estimate, Person-Years (Person-Months) = 90.53 (1,086.36) (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05)) Schedule Estimate, Years (Months) = 2.97 (35.61) (Basic COCOMO model, Months = 2.5 * (person-months**0.38)) Estimated Average Number of Developers (Effort/Schedule) = 30.50 Total Estimated Cost to Develop = $ 12,229,349 (average salary = $56,286/year, overhead = 2.40). SLOCCount, Copyright (C) 2001-2004 David A. Wheeler SLOCCount is Open Source Software/Free Software, licensed under the GNU GPL. SLOCCount comes with ABSOLUTELY NO WARRANTY, and you are welcome to redistribute it under certain conditions as specified by the GNU GPL license; see the documentation for details. Please credit this data as generated using David A. Wheeler's 'SLOCCount'. Have fun ! Geert ___ Hi all I found this cost estimate the other day which has a similar cost estimate. http://www.ohloh.net/p/gnucash/estimated_cost Mike E ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash documentation
On Thu, 06 Sep 2012 11:49:43 +0200 Geert Janssens janssens-ge...@telenet.be wrote: Bug 661705 triggered me to look at our documentation build scripts and the state of our documentation repository in general. I noticed there was no 2.4 branch yet, although a number of commits in trunk were not meant for 2.4. So I have branched 2.4 just before the first commit that's not 2.4 related, and backported all relevant commits to the 2.4 branch as well. I wasn't sure about the business import features (which are optional in GnuCash). Are they available to 2.4 users as well ? Or perhaps only the invoice importer and not the owner importer ? If so, some additional commits may need to be backported as well. I think the importer stuff can safely be left as is for the 2.4 branch. Mike E Next, the bug that started all this, is now fixed both in 2.4 and trunk. It does affect distro's that ship recent versions of yelp. For that reason I would like to do a new stable documentation release soon (like in a week or so). Are there things that should be done in the documentation before I do this release ? Please let me know. Geert [1] https://bugzilla.gnome.org/show_bug.cgi?id=661705 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel -- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r22335 - gnucash-docs/trunk/guide/C - Move chapter on importing bills and invoices.
On Wed, 22 Aug 2012 09:24:28 -0400 Derek Atkins warl...@mit.edu wrote: Mike Evans mi...@saxicola.idps.co.uk writes: I believe this change broke the docs build last night. Are you sure the file isn't named import_business_data? -derek Oops. Looks like a typo. I'll fix ASAP. If you attempted to fix it, the fix didn't take. The docs build is still broken. Mike E -derek Just added the file to SVN. Mike E :( -- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r22335 - gnucash-docs/trunk/guide/C - Move chapter on importing bills and invoices.
On Tue, 21 Aug 2012 10:52:37 -0400 Derek Atkins warl...@mit.edu wrote: Hi, Mike Evans mi...@code.gnucash.org writes: Modified: gnucash-docs/trunk/guide/C/Makefile.am gnucash-docs/trunk/guide/C/ch_python_bindings.xml gnucash-docs/trunk/guide/C/gnucash-guide.xml Log: Move chapter on importing bills and invoices. Although there is some Python in this chapter it's not really about the Python Bindings. Modified: gnucash-docs/trunk/guide/C/Makefile.am === --- gnucash-docs/trunk/guide/C/Makefile.am 2012-08-20 15:50:23 UTC (rev 22334) +++ gnucash-docs/trunk/guide/C/Makefile.am 2012-08-20 16:28:58 UTC (rev 22335) @@ -22,6 +22,7 @@ ch_budgets.xml \ ch_oth_assets.xml \ ch_python_bindings.xml \ + ch_import_busisness_data.xml appendixa.xml \ appendixb.xml \ appendixc.xml \ I believe this change broke the docs build last night. Are you sure the file isn't named import_business_data? -derek Oops. Looks like a typo. I'll fix ASAP. Mike E -- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel