Re: [GNC-dev] UK VAT and "Making Tax Difficult"

[Mike Evans]

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"

[Mike Evans]

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

[Mike Evans]

> 
> > 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

[Mike Evans]

> 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

[Mike Evans]

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

[Mike Evans]

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

[Mike Evans]

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

[Mike Evans]

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'

[Mike Evans]

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

[Mike Evans]

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

[Mike Evans]

On Sat, 6 Apr 2019 23:29:30 +0800
Christopher Lam  wrote:

> On Sat, 6 Apr 2019 at 17:49, Mike Evans  wrote:
> 
> > For VAT there are examples at
> > https://developer.service.hmrc.gov.uk/api-documentation/docs/api/service/vat-api/1.0#_submit-vat-return-for-period_post_accordion
> > although I've not tested anything there yet.  I've only tested the Self
> > Assessment API at
> > https://developer.service.hmrc.gov.uk/api-documentation/docs/api/service/self-assessment-api/2.0#selfemployment-business_get-a-selfemployment-periodic-update_get_accordion
> > in the posted Python scripts.
> >
> > For creating a test user for VAT this looks like the page
> > https://developer.service.hmrc.gov.uk/api-documentation/docs/api/service/api-platform-test-user/1.0#_create-a-test-user-which-is-an-individual_post_accordion
> > I'll try that with some python later.
> >
> > Have you registered as a developer with HMRC? What's your solution to the
> > client_secret problem?
> >
> >  
> All these are "bridging software" problems.
> I'm prepared to export from income-gst-statement to period-summary.json or
> period-summary.csv
> Bridging software will take the above summaries, handle passwords/keys, and
> authenticate/send to HMRC.
> The VAT return examples are trivial to generate.
> 
> C

OK, I'm clear now. I misunderstood what you intended to do.

Mike E
___
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

[Mike Evans]

On Sat, 6 Apr 2019 11:29:20 +0800
Christopher Lam  wrote:

> I have it in my near todo.txt to add export-json from
> income-gst-statement.scm which calculates net & VAT amounts.
> 
> I will *not* be writing bridging software.
Good, also interesting, in that I never considered exporting from the reports. 
I guess for self assessment the data could be exported from the same report ? 
But then I'm not good with scheme.

I was becoming concerned that by the time this becomes compulsory (which it 
already is for VAT. Although the gov. have allowed a further breaking in time) 
no one would have written this for GnuCash, hence the Python bridge. I really 
did not want to buy another computer running Windows 10, plus an accounting 
package to submit my small self employed earnings. I could employ an tax agent 
every quarter to submit for me I suppose.  I guess that applies to many GnuCash 
users.

> 
> If anyone can find the exact json format expected for HMRC I'll get it done.

For VAT there are examples at 
https://developer.service.hmrc.gov.uk/api-documentation/docs/api/service/vat-api/1.0#_submit-vat-return-for-period_post_accordion
 although I've not tested anything there yet.  I've only tested the Self 
Assessment API at 
https://developer.service.hmrc.gov.uk/api-documentation/docs/api/service/self-assessment-api/2.0#selfemployment-business_get-a-selfemployment-periodic-update_get_accordion
 in the posted Python scripts.

For creating a test user for VAT this looks like the page 
https://developer.service.hmrc.gov.uk/api-documentation/docs/api/service/api-platform-test-user/1.0#_create-a-test-user-which-is-an-individual_post_accordion
 I'll try that with some python later.

Have you registered as a developer with HMRC? What's your solution to the 
client_secret problem?

Mike E
___
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

[Mike Evans]

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&more_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

[Mike Evans]

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&more_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)

[Mike Evans]

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)

[Mike Evans]

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?

[Mike Evans]

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

[Mike Evans]

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  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

[Mike Evans]

On Sat, 14 Oct 2017 09:49:19 +0100
Mike Evans  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

[Mike Evans]

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

[Mike Evans]

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

[Mike Evans]

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

[Mike Evans]

On Wed, 30 Aug 2017 06:35:30 -0700
John Ralls  wrote:

> > On Aug 30, 2017, at 3:37 AM, Mike Evans  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

[Mike Evans]

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 ?

[Mike Evans]

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

[Mike Evans]

On Thu, 17 Aug 2017 17:04:52 +0200
John Ralls  wrote:

> > On Aug 17, 2017, at 2:47 PM, Mike Evans  wrote:
> > 
> > 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.   
> 
> 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

[Mike Evans]

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 to include unincorporated businesses); we will be 

Re: UK specific: MTD - Making Tax Digital

[Mike Evans]

On Mon, 17 Apr 2017 20:06:15 +0100
Mike Evans  wrote:

> On Mon, 17 Apr 2017 19:34:36 +0100
> "Maf. King"  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

[Mike Evans]

On Sat, 15 Apr 2017 08:32:29 -0500
Rob Gowin  wrote:

> On Sat, Apr 15, 2017 at 3:24 AM, Mike Evans  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

[Mike Evans]

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?

[Mike Evans]

On Thu, 20 Oct 2016 16:55:46 +0100
Wm via gnucash-devel  wrote:

> 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&search=0xDB8F7CF1C67BBC0F 
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: API for creating invoices?

[Mike Evans]

On Mon, 3 Oct 2016 15:29:36 -0400 (EDT)
Jon Daley  wrote:

> 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&search=0xDB8F7CF1C67BBC0F 
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Bug 756469

[Mike Evans]

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&search=0x00CDB13500D7AB53  
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Bug 756469

[Mike Evans]

On Tue, 12 Jan 2016 17:48:58 +0100
Geert Janssens  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&search=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

[Mike Evans]

On Tue, 12 Jan 2016 12:42:02 +0100
Geert Janssens  wrote:

> On Wednesday 30 December 2015 13:14:09 Mike Evans wrote:
> > On Wed, 30 Dec 2015 09:40:48 +0100
> > 
> > Geert Janssens  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&search=0x00CDB13500D7AB53  
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Bug 756469

[Mike Evans]

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:

((?[^\",]*)|\"(?[^\"]*)\")\"

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? 

Mike E


-- 
PGP key:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=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.

[Mike Evans]

On Thu, 05 Nov 2015 20:46:49 +0100
Geert Janssens  wrote:

> 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&search=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

[Mike Evans]

On Wed, 30 Dec 2015 09:40:48 +0100
Geert Janssens  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&search=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

[Mike Evans]

On Tue, 29 Dec 2015 06:58:52 -0800 (PST)
david.carlson@gmail.com  wrote:


> 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&search=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

[Mike Evans]

On Tue, 29 Dec 2015 14:13:21 +0100
"Frank H. Ellenberger"  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&search=0x00CDB13500D7AB53  
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Flickering drop down boxes on mouse over

[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

-- 
PGP key:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x00CDB13500D7AB53  
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

FYI. Bitcoin news.

[Mike Evans]

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&search=0x00CDB13500D7AB53  
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Using LibreOffice for Documentation

[Mike Evans]

On Fri, 04 Sep 2015 11:48:16 +0200
Geert Janssens  wrote:

> 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&search=0x00CDB13500D7AB53  
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Using AsciiDoc for Documentation

[Mike Evans]

On Thu, 03 Sep 2015 12:29:15 +0200
Geert Janssens  wrote:

> On Thursday 03 September 2015 01:28:59 Buddha Buck wrote:
> > On Wed, Sep 2, 2015 at 10:20 AM Geert Janssens
> > 
> > wrote:
> > > As with markup the primary drawback I currently see is the lack of a
> > > wysiwyg capable editor
> > > that's present on all platforms we support.
> > 
> > By "markup" here do you mean "Markdown"?
> > 
> Indeed. I don't know why I started using it markup all of a sudden...
> 

Small note regarding Markdown, It doesn't support tables.  Plus a few other 
things that Asciidoc does.  There is Multimarkdown though, which supports more 
structures.

Mike E
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Using LibreOffice for Documentation

[Mike Evans]

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

[Mike Evans]

On Wed, 2 Sep 2015 22:06:30 -0400
"David T."  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&search=0x00CDB13500D7AB53  

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Using AsciiDoc for Documentation

[Mike Evans]

On Tue, 1 Sep 2015 13:44:39 -0500
Rob Gowin  wrote:

> 
> > On Sep 1, 2015, at 4:56 AM, Mike Evans  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&search=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&search=0x00CDB13500D7AB53  
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Using AsciiDoc for Documentation

[Mike Evans]

On Sun, 30 Aug 2015 19:16:24 -0500
Rob Gowin  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  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&search=0x00CDB13500D7AB53  
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Replacing Docbook

[Mike Evans]

On Sat, 29 Aug 2015 16:52:48 +0200
Geert Janssens  wrote:

> On Saturday 29 August 2015 06:38:53 John Ralls wrote:
> > > On Aug 29, 2015, at 5:43 AM, Mike Evans 
> > > 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&search=0x00CDB13500D7AB53  
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Replacing Docbook

[Mike Evans]

On Sat, 29 Aug 2015 06:38:53 -0700
John Ralls  wrote:

> 
> > On Aug 29, 2015, at 5:43 AM, Mike Evans  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=get&search=0x00CDB13500D7AB53  
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Replacing Docbook

[Mike Evans]

On Fri, 28 Aug 2015 21:38:18 +0200
Geert Janssens  wrote:
<>
> 
> 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

[Mike Evans]

On Fri, 28 Aug 2015 15:15:58 +0100
Mike Evans  wrote:

> On Fri, 28 Aug 2015 11:00:26 +0200
> Geert Janssens  wrote:
> 
> > On Friday 28 August 2015 09:45:44 John Ralls wrote:
> > > > On Aug 28, 2015, at 9:03 AM, Geert Janssens
> > > >  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=get&search=0x00CDB13500D7AB53  

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Replacing Docbook

[Mike Evans]

On Fri, 28 Aug 2015 11:00:26 +0200
Geert Janssens  wrote:

> On Friday 28 August 2015 09:45:44 John Ralls wrote:
> > > On Aug 28, 2015, at 9:03 AM, Geert Janssens
> > >  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
> > >  > > 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
> >  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=get&search=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

[Mike Evans]

On Thu, 16 Jul 2015 19:10:46 +1000
"Matt Graham"  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=get&search=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

[Mike Evans]

On Sun, 11 Jan 2015 19:02:22 +0100
Geert Janssens  wrote:

> On Sunday 11 January 2015 09:43:48 John Ralls wrote:
> > > On Jan 11, 2015, at 9:33 AM, Mike Evans 
> > > wrote:
> > > 
> > > On Sun, 11 Jan 2015 09:16:19 -0800
> > > 
> > > John Ralls  wrote:
> > >>> On Jan 11, 2015, at 8:31 AM, Mike Evans 
> > >>> 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 #
> > >>>  (((gnucash gettext)))] ?:  6* [#
> > >>>  ((gnucash gettext))]
> > >>>  ?:  7* (or (apply resolve-interface mif-args) (error "no such
> > >>>  module" mif-args)) ?:  8* [apply # > >>>  (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 ...]
> > >>> 
> > >>> : In procedure scm-error in expression (scm-error
> > >>> (quote misc-error) #f ...): : 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=get&search=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

[Mike Evans]

On Sun, 11 Jan 2015 09:16:19 -0800
John Ralls  wrote:

> 
> > On Jan 11, 2015, at 8:31 AM, Mike Evans  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 # (((gnucash gettext)))]
> >   ?:  6* [# ((gnucash gettext))]
> >   ?:  7* (or (apply resolve-interface mif-args) (error "no such module" 
> > mif-args))
> >   ?:  8* [apply # ((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 ...]
> > 
> > : In procedure scm-error in expression (scm-error (quote 
> > misc-error) #f ...):
> > : 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=get&search=0x00CDB13500D7AB53  
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Make check fails in src/import-export

[Mike Evans]

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 # (((gnucash gettext)))]
   ?:  6* [# ((gnucash gettext))]
   ?:  7* (or (apply resolve-interface mif-args) (error "no such module" 
mif-args))
   ?:  8* [apply # ((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 ...]

: In procedure scm-error in expression (scm-error (quote 
misc-error) #f ...):
: 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=get&search=0x00CDB13500D7AB53  
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Bug 612214 and Bug 726674 - duplicates?

[Mike Evans]

On Tue, 12 Aug 2014 22:32:40 +1000
John Mamutil  wrote:

> Hi Please take me off this mailing list.
> 
> It is too complicated for me - way over my head.
> 
> Thanks,
> 
> John
> 
> >
> 
> 
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Just follow the link at the bottom of this mail and hit the unsubscribe button 
near the bottom of the page.

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: Bug 734183

[Mike Evans]

On Wed, 06 Aug 2014 18:01:52 +0200
Geert Janssens  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=get&search=0x00CDB13500D7AB53  
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Bug 734183

[Mike Evans]

On Wed, 06 Aug 2014 15:49:08 +0200
Geert Janssens  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=get&search=0x00CDB13500D7AB53  
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Bug 734183

[Mike Evans]

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=get&search=0x00CDB13500D7AB53  
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Import CSV Bills & Invoices - Notes field

[Mike Evans]

On Wed, 18 Jun 2014 01:36:04 -0700
JP Liew  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=get&search=0x00CDB13500D7AB53  

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Compile fails latest maint 8d723f1b

[Mike Evans]

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=get&search=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.

[Mike Evans]

On Thu, 05 Jun 2014 09:58:25 +0200
Geert Janssens  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 
> > 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=get&search=0x00CDB13500D7AB53  
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Make check files with python bindings.

[Mike Evans]

On Sat, 17 May 2014 16:43:23 -0700
John Ralls  wrote:

> 
> On May 17, 2014, at 4:34 AM, Mike Evans  wrote:
> 
> > On Sat, 17 May 2014 13:06 +0200
> > Geert Janssens  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.
> 
> Finally checked my F18 VM, which is 64-bit so it’s 
> /usr/lib64/python2.7/test/test_support.py. It’s present and "from test import 
> test_support” works. /usr/lib/python2.7/test also exists, but it’s empty. 
> Check where (if?) test_support.py is installed and that it’s reachable on 
> sys.path.
> 
> Regards,
> John Ralls
> 

Thanks John and Geert.

I checked if the "test" that I was finding was the "test" I shoulda been 
finding, and nope, it isn't.  It's a different module and help(test) gives me:

NAME
test - Tests for 'biblio.webquery', using nose.

FILE

/usr/lib/python2.7/site-packages/biblio.webquery-0.4.3b-py2.7.egg/test/__init__.py

PACKAGE CONTENTS
test_errors

So I'm loading that one first it seems.  I use biblio.webquery as part of a 
book cataloguing program I wrote some time ago.  Thanks John for the prompting 
to check sys.path.  Now to figure out how to get the right one loaded in each 
program.  Just deleting the bogus module will do for now and hope that my 
librarian keeps working.

Cheers

Mike Evans

-- 
Anti NSA?  Use PGP.
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x00CDB13500D7AB53  
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Make check files with python bindings.

[Mike Evans]

On Sat, 17 May 2014 13:06 +0200
Geert Janssens  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  wrote:
> > > On May 16, 2014, at 9:24 AM, Mike Evans  
> 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 
> > > >  
> > > >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=get&search=0x00CDB13500D7AB53  

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Make check files with python bindings.

[Mike Evans]

On Fri, 16 May 2014 11:38:59 -0700
John Ralls  wrote:

> 
> On May 16, 2014, at 9:24 AM, Mike Evans  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 
> >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=get&search=0x00CDB13500D7AB53  
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Make check files with python bindings.

[Mike Evans]

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 
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=get&search=0x00CDB13500D7AB53  
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Business invoices over/pre payments

[Mike Evans]

On Wed, 30 Apr 2014 13:39:15 +0200
Geert Janssens  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=get&search=0x00CDB13500D7AB53  
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Business invoices over/pre payments

[Mike Evans]

On Wed, 30 Apr 2014 11:39:30 +0200
Geert Janssens  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...
> 
> > 
> > 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. 
> > 
> 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 

Business invoices over/pre payments

[Mike Evans]

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.


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.


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=get&search=0x00CDB13500D7AB53  
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Python bindings: Account.getName() raises TypeError

[Mike Evans]

On Mon, 17 Mar 2014 10:32:17 +
Mike Evans  wrote:

> On Mon, 17 Mar 2014 11:26:30 +0100
> Felix Schwarz  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

[Mike Evans]

On Mon, 17 Mar 2014 11:26:30 +0100
Felix Schwarz  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: Python bindings: Account.getName() raises TypeError

[Mike Evans]

On Sun, 16 Mar 2014 13:41:42 -0700
David Osguthorpe  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: Poll: when to migrate code to the new server?

[Mike Evans]

On Tue, 21 Jan 2014 11:52:12 -0500
Derek Atkins  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

[Mike Evans]

On Sun, 15 Dec 2013 14:58:21 -0500
Mike Alexander  wrote:

> On Dec 15, 2013, at 8:13 AM, Geert Janssens  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 
> 
>  that lists a few cheap or free DocBook editors.  Also 
>  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

[Mike Evans]

On Fri, 13 Dec 2013 07:03:26 -0800
John Ralls  wrote:

> 
> On Dec 13, 2013, at 2:41 AM, Mike Evans  wrote:
> 
> > On Fri, 13 Dec 2013 08:26:42 +0100
> > Christian Stimming  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.
> >> 
> > 
> > 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
> 
> Looks like it would work. What do you see as the advantages over better-known 
> markups like markdown and wiki? How would we get the existing DocBook 
> documents into ascitext format?

Advantages: The WIKI way seems prone to the problems already
discussed.  Why Acsiidoc?  I can't give specific technical advantages
over markdown but there are easy-to-use tools to produce html, docbook,
e-book files etc.  I've not used markdown enough to make a meaningful 
comparison.

Conversion: I found a conversion tool that I *thought* might do the job,
SaxonHE9, a java tool (ugh), but it doesn't do it very well.  I tried a couple 
of pages.  Some post conversion cleanup was needed to remove artifacts but, the 
major issue was that image placeholders went missing. So not good enough to 
make it an easy convert.  More research required on that one.


Mike E

http://www.methods.co.nz/asciidoc/index.html

-- 
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

[Mike Evans]

On Fri, 13 Dec 2013 08:26:42 +0100
Christian Stimming  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.

[Mike Evans]

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  [valid_commodity()] Invalid commodity: 0 fraction
* 11:49:30  WARN  [gnc_commodity_end_handler()] Invalid commodity parsed

  ISO4217
  
  

  user_symbol
  ZK

  

* 11:49:31  WARN  [gnc_xml_be_load_from_file()] Syntax error in 
Xml File /home/mikee/Projects/gnucash-tutorial/data/test.gnucash
* 11:49:31  CRIT  g_hash_table_foreach: assertion `version == 
hash_table->version' failed
* 11:49:31  CRIT  g_hash_table_foreach: assertion `version == 
hash_table->version' failed
* 11:49:31  CRIT  g_hash_table_foreach: assertion `version == 
hash_table->version' failed
* 11:49:31  CRIT  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

Re: 2.6 roadmap

[Mike Evans]

On Tue, 05 Nov 2013 11:25:55 +0100
Geert Janssens  wrote:

> On Monday 04 November 2013 14:06:52 John Ralls wrote:
> > On Nov 4, 2013, at 1:34 PM, Geert Janssens  
> wrote:
> > > With 2.5.7 out of the door, I would like to look ahead at 2.6.
> > > 
> > > I have just gone through the open bugs targeting the 2.6 milestone
> > > and reduced the set from 21 to 14. Some of the bugs I removed were
> > > actually bugs against register2 which is not a feature for 2.6 any
> > > more. Some need more info before we can decide (now marked as
> > > NEEDINFO).
> > > 
> > > Are these bugs the remaining issues for 2.6 or is someone still
> > > working on something that should get included ?
> > > 
> > > In these bugs I don't see anything that would still introduce major
> > > translation changes.
> > > 
> > > There may be one translation issue left though: normally the
> > > gsettings schemas are translatable, but they currently aren't
> > > properly marked for translation. If I do that, this will include
> > > lots of translatable strings. Most of them were already in the
> > > gconf schema, so ideally most translations will simply be reused
> > > from before. I haven't tested this though.
> > > 
> > > Question is: can we do a string freeze now, or should we wait for
> > > this to get fixed ?
> > > 
> > > 
> > > From earlier conversations, the last plan was to release 2.6 by the
> > > end of the year. Is this realistic ?
> > 
> > We should wait for you to fix the strings.
> > 
> I've run some tests. If I add the gsettings schemas to the translatable 
> strings, well translated languages get between 50 and 70  new fuzzy or 
> untranslated strings. It's less for languages for which translations are 
> less complete. That's not too bad given that gsettings schemas contain 
> well over 300 translatable strings.
> 
> I can add these strings today so we can continue with calling the 
> string/feature freeze.
> 
> I don't know the translation process too well. What is needed for 
> translators to be able to start on the translations in 2.5.x ? I seem to 
> remember we should provide a tarball with up to date po files or 
> something ? I'm even wondering if we shouldn't release a 2.5.8 right 
> after the last strings are added and call that the base for translators 
> ?
> 
> > As long as there aren’t any killer bugs, I think the December 3
> > release can be RC1 and plan for 2.6 between Christmas and New Year’s
> > Eve.
> > 
> Looks good to me.
> 
> > I’ll do a review of the 2.5 bugs this week and add anything serious to
> > the roadmap. I’ve also just found a crash in the SX editor that I’m
> > debugging right now.
> > 
> Ok
> 
> Geert
> 

I'll try and revisit the python path bug before then too, but since it's 
non-critical it won't stop the release.

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: FYI internet speed tests.

[Mike Evans]

On Wed, 23 Oct 2013 12:14:47 +0100
Mike Evans  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

FYI internet speed tests.

[Mike Evans]

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: Latest 2.5 build crashes at start

[Mike Evans]

On Tue, 22 Oct 2013 12:01:52 +0200
Geert Janssens  wrote:

> On Tuesday 22 October 2013 10:39:12 Mike Evans wrote:
> > On Tue, 22 Oct 2013 09:56:52 +0200
> > 
> > Geert Janssens  wrote:
> > > On Monday 21 October 2013 10:53:06 Mike Evans wrote:
> > > > The latest devel version crashes at start with:
> > > > 
> > > > * 10:32:03  WARN  *** GnuCash switched to a new
> > > > preferences
> > > > system *** * 10:32:03  WARN  Attempt to migrate your
> > > > preferences from the old to the new system * 10:32:03 OTHER
> > > >  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

Re: Latest 2.5 build crashes at start

[Mike Evans]

On Tue, 22 Oct 2013 09:56:52 +0200
Geert Janssens  wrote:

> On Monday 21 October 2013 10:53:06 Mike Evans wrote:
> > The latest devel version crashes at start with:
> > 
> > * 10:32:03  WARN  *** GnuCash switched to a new preferences
> > system *** * 10:32:03  WARN  Attempt to migrate your
> > preferences from the old to the new system * 10:32:03 OTHER
> >  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

Latest 2.5 build crashes at start

[Mike Evans]

The latest devel version crashes at start with:

* 10:32:03  WARN  *** GnuCash switched to a new preferences system ***
* 10:32:03  WARN  Attempt to migrate your preferences from the old to 
the new system
* 10:32:03 OTHER  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

[Mike Evans]

On Wed, 18 Sep 2013 11:56:37 +0200
Geert Janssens  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 
> > 
> > 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

[Mike Evans]

On Tue, 06 Aug 2013 10:29:35 -0400
Derek Atkins  wrote:

> Geert,
> 
> Geert Janssens  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  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 ...)
> 
>  :1:897: In expression
>  (gnc:restore-report-by-guid-with-custom-template 0
>  "b1f15b2052c149df93e698fe85a81ea6" ...):
>  :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 ?

[Mike Evans]

On Fri, 29 Mar 2013 10:12:50 -0700
John Ralls  wrote:

> 
> On Mar 28, 2013, at 11:30 PM, John Ralls  wrote:
> 
> > 
> > On Mar 27, 2013, at 5:34 PM, John Ralls  wrote:
> > 
> >> 
> >> On Mar 27, 2013, at 1:07 PM, Christian Stimming  
> >> 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 ?

[Mike Evans]

On Wed, 27 Mar 2013 17:34:53 -0700
John Ralls  wrote:

> 
> On Mar 27, 2013, at 1:07 PM, Christian Stimming  
> 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?

[Mike Evans]

On Sun, 24 Mar 2013 10:55:47 +
Mike Evans  wrote:

> On Sun, 24 Mar 2013 00:52:25 -0400
> Mike Alexander  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: SVN->GIT link broken?

[Mike Evans]

On Sun, 24 Mar 2013 00:52:25 -0400
Mike Alexander  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.

-- 
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 Tax Invoice for Australia (Bug 695610)

[Mike Evans]

On Mon, 11 Mar 2013 19:28:12 +1100
alphamega  wrote:

> Hi there,
> 
> Australia has some unique requirements for businesses preparing tax invoices.
> I've searched through the archives and this keeps coming up again and again 
> and
> again. People submit patches and fixes again and again, but these changes 
> don't
> seem to actually make it to the release versions of GnuCash. 
> 
> GnuCash 2.4.11 was released in July 2012. Here is a summary of previous bug
> reports on this issue, which should have made it into this release, but 
> didn't:
> 
> Dmitry Smirnov reported this and even submitted a patch back in 2012-02-13. 
> See
> this bug, which was closed 31/03/2012 with patches committed: 
> https://bugzilla.gnome.org/show_bug.cgi?id=670008
> 
> Another invoice template was supplied in response to this bug report in April
> 2012:
> https://bugzilla.gnome.org/show_bug.cgi?id=585101
> 
> And this guy gave up completely!
> https://bugzilla.gnome.org/show_bug.cgi?id=402670
> 
> Anyway, I incorporated all of the patches and changes I could find (thanks
> Dmitry), put myself through a crash course in guile/scheme programming, added 
> a
> bunch of enhancements of my own, and came up with... well this patch. Now,
> I'm not really a developer, so I did the best I could with the time I had
> available.
> 
> So here's a summary of the files attached to bug 695610:
> 1. taxinvoice-australia-v1.2.patch: A patch that can be applied to the
> taxinvoice.scm / taxinvoice.eguile.scm / taxinvoice.css files (in the
> guile-modules/gnucash/report directory). Note that I didn't check out the svn
> repo, I just made my changes to the version that comes with 2.4.11.
> 2. The resulting taxinvoice.scm, taxinvoice.eguile.scm and taxinvoice.css
> files.
> 3. A sample invoice PDF that's created if you just use the defaults.
> 
> Things you should know:
> 1. I needed a way to print the company's bank details so that my customers 
> can 
> pay the invoice via bank deposit. There is no field for this, nor is there a 
> way to
> nominate an asset account as the primary bank account for invoices, nor a way
> to nominate an asset account for a customer to pay into. So I'm using the
> company address field instead.
> 2. Because of point 1, I'm using the company website field as the company
> address field.
> 3. The tax rate is an invoice entry specific item, but in Australia, most
> invoices I see have the tax rate as a "subtotal row". I'm sure there's a 
> better
> way to do this, but if you select the "row: Tax Rate" option, you'll get a
> hardcoded "10%". Change this in taxinvoice.eguile.scm, search for
> "taxrate-val".   
> 4. I got tired of changing the default labels to suit Australia each time I
> wanted to generate an invoice, so I changed the defaults to suit Australia. To
> undo this, just change taxinvoice.scm so that all occurrences of "GST" becomes
> "Tax".
> 5. Many columns are now unchecked by default. Again, this was my preference,
> but you can undo this in taxinvoice.scm. Search for "Elements page options",
> then change #f to #t for each one you want checked by default (and vice 
> versa).
> 
> Here's link to the bug report:
> https://bugzilla.gnome.org/show_bug.cgi?id=695610#c0
> 
> Cheers
> A.
> ___


Dmitry's work in bug #670008 wasn't included in the 2.4.11 release
because it was based on the trunk code which, if I remember correctly,
wasn't back portable to 2.4.  This doesn't work when applied to trunk,
but is fine in 2.4.  See though my comments regarding some minor
issues with this in the bug report.

This could be applied against 2.4 but I'm not sure if 2.4.12 is ever
going to be released.  And may violate the rule against major changes
within a version.

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: CRLF issues on checkout (was Re: Gnucash 2.5/6 - jqplot)

[Mike Evans]

On Sat, 23 Feb 2013 10:19:25 +0100
Geert Janssens  wrote:

> Op 23-02-13 05:52, John Ralls schreef:
> > On Feb 22, 2013, at 11:14 AM, Geert Janssens
> >  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

[Mike Evans]

On Fri, 22 Feb 2013 18:47:48 +0100
Geert Janssens  wrote:

> Op 22-02-13 14:43, Mike Evans schreef:
> > On Thu, 21 Feb 2013 18:55:31 +0100
> > Geert Janssens  wrote:
> >
> >> Op 21-02-13 18:19, Mike Evans schreef:
> >>> On Thu, 21 Feb 2013 18:04:37 +0100
> >>> Geert Janssens  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 ..." to update what will be c

Re: Gnucash 2.5/6 - jqplot

[Mike Evans]

On Thu, 21 Feb 2013 18:55:31 +0100
Geert Janssens  wrote:

> Op 21-02-13 18:19, Mike Evans schreef:
> > On Thu, 21 Feb 2013 18:04:37 +0100
> > Geert Janssens  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 ..." to update what will be committed)
#   (use "git checkout -- ..." 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

[Mike Evans]

On Thu, 21 Feb 2013 18:16:53 +0100
Geert Janssens  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 B&W laser. They didn't before to be
fair. For B&W 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 B&W 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 - jqplot

[Mike Evans]

On Thu, 21 Feb 2013 18:04:37 +0100
Geert Janssens  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

[Mike Evans]

On Thu, 21 Feb 2013 14:18:38 +
Mike Evans  wrote:

> On Thu, 21 Feb 2013 12:47:18 +0100
> Geert Janssens  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

Re: Bugzilla default/QA assignees

[Mike Evans]

On Thu, 21 Feb 2013 10:07:02 -0500
Derek Atkins  wrote:

> Mike Evans  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

[Mike Evans]

On Thu, 21 Feb 2013 12:47:18 +0100
Geert Janssens  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