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

2023-01-08 Thread 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"

2023-01-08 Thread 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

2021-01-15 Thread 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

2020-09-14 Thread 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

2019-07-30 Thread 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

2019-07-29 Thread 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

2019-05-04 Thread 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

2019-05-04 Thread 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'

2019-05-01 Thread 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

2019-04-06 Thread 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

2019-04-05 Thread 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_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

2019-04-04 Thread 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_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)

2018-08-27 Thread 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)

2018-08-27 Thread 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?

2018-05-10 Thread 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

2017-10-14 Thread 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 <mi...@saxicola.co.uk> wrote:
> 
> > On Fri, 13 Oct 2017 16:13:54 +0100
> > Robert Fewell <14ubo...@gmail.com> wrote:
> >  
> > > Mike,
> > >
> > > Try this in your .gtk-3.0-gnucash.css file
> > >
> > > notebook tab label {
> > >   color: black;
> > > }
> > >
> > > Regards,
> > > Bob  
> >
> > Hi Bob.
> >
> > I can't find any such file. Fedora26.
> >
> > Cheers.
> > Mike E
> > ___
> > gnucash-devel mailing list
> > gnucash-devel@gnucash.org
> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> >  

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


Re: Font colours in 2.8

2017-10-14 Thread Mike Evans
On Sat, 14 Oct 2017 09:49:19 +0100
Mike Evans <mi...@saxicola.co.uk> wrote:

> On Fri, 13 Oct 2017 16:13:54 +0100
> Robert Fewell <14ubo...@gmail.com> wrote:
> 
> > Mike,
> > 
> > Try this in your .gtk-3.0-gnucash.css file
> > 
> > notebook tab label {
> >   color: black;
> > }
> > 
> > Regards,
> > Bob  
> 
> Hi Bob.
> 
> I can't find any such file. Fedora26.
> 
>
Update:

Adding that in 

gnucash/gnome-utils/ui/gnucash.css

works for me.

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


Re: Font colours in 2.8

2017-10-14 Thread 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

2017-10-13 Thread 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

2017-09-02 Thread 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

2017-08-30 Thread Mike Evans
On Wed, 30 Aug 2017 06:35:30 -0700
John Ralls <jra...@ceridwen.us> wrote:

> > On Aug 30, 2017, at 3:37 AM, Mike Evans <mi...@saxicola.co.uk> wrote:
> > 
> > Hi all.  Good job on all the hard work you guys are doing to produce 2.8.
> > 
> > I finally got round to compiling master and noticed a possible behaviour 
> > regression when printing/exporting reports as PDFs. On maint selecting 
> > "export to PDF" provides the user dialog with a pre-populated filename to 
> > export to consisting of the report name and the current date. On master the 
> > same action takes me to the standard print menu where I select from printer 
> > or pdf and have to fill in the filename manually.
> > 
> > I've not looked into the "why" of this as yet. Want to confirm this first 
> > just in case it's settings related somewhere I've missed/forgotten.  
> 
> Mike,
> 
> It’s because WebKit2 doesn’t expose the necessary API to do it separately. 
> They expose the functionality from the print dialog instead. We need to 
> remove the export to PDF actions and document that users should use “print” 
> instead.
> 
> Regards,
> John Ralls
> 

John 

That's a shame as I use that a lot for invoicing. Is there any mechanism to 
pass through a filename to the print dialog?

I'll open a bug then so this isn't forgotten and mark that as blocking Geerts 
tracker bug 778981.

Regards

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


Master: Printing of PDF Reports

2017-08-30 Thread 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 ?

2017-08-23 Thread 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

2017-08-19 Thread Mike Evans
On Thu, 17 Aug 2017 17:04:52 +0200
John Ralls <jra...@ceridwen.fremont.ca.us> wrote:

> > On Aug 17, 2017, at 2:47 PM, Mike Evans <mi...@saxicola.co.uk> wrote:
> > 
> > I just received this from HMRC.
> > 
> > Begin forwarded message:
> > 
> > Date: Thu, 17 Aug 2017 10:46:57 +
> > From: <sdst...@hmrc.gsi.gov.uk>
> > To: <sdst...@hmrc.gsi.gov.uk>
> > Subject: VAT Call for Software developers
> > 
> > 
> > Dear All,
> > 
> > I writing to tell you about a conference call that has been arranged for 
> > 11:00am on 05 September 2017.
> > 
> > You may be aware that the Government has proposed that businesses with a 
> > turnover above the VAT threshold (currently £85,000) will be mandated to 
> > keep digital records and submit data to HMRC through its secure API 
> > platform service. The changes will take place from April 2019 for VAT.
> > 
> > Current plans are to make the APIs available for private beta test in 
> > October 2017 and we want to advise interested software vendors about our 
> > thinking as well as provide them with an early opportunity to raise any 
> > issues or questions. It will of course also help us identify if your 
> > company is considering developing or enhancing a VAT product to support the 
> > proposals.
> > We can then arrange to work with you going forward, providing the usual 
> > technical assistance and other support needed to prepare for the pilot, 
> > from April 18 and  in readiness for the changes being mandated from April 
> > 2019.
> > 
> >  *   Only businesses with a turnover above the VAT threshold will have to 
> > keep digital records and only for VAT purposes. They will only need to do 
> > so from 2019.
> >  *   Other businesses will be able to file digitally on a voluntary basis 
> > for both VAT and Income Tax and NICs
> > 
> > Our current development schedule is as follows
> > 
> >  1.  October 2017 - private beta (API testing) with interested software 
> > vendors
> >  2.  April 2018 - public beta (pilot) data submission for VAT purposes (MVP 
> > to include unincorporated businesses); we will be inviting business 
> > volunteers throughout the year, anticipating that early adopters will 
> > already be using software and therefore likely to already be your 
> > customers. These will include both Tax Agents, their clients as well as 
> > unrepresented VAT businesses.
> >  3.  From April 2019 - data submission for VAT purposes (that is all 
> > VAT-registered businesses whether the business is unincorporated or not); 
> > Mandated for VAT registered businesses with a turnover above the VAT 
> > threshold, but all VAT registered businesses can use the service.
> > 
> > Please let me know if you intend to join the call so I can make the 
> > necessary arrangements. Please send your reply to this email no later than 
> > 17:00 on  24th August 2017.
> > 
> > 
> > Kind Regards
> > 
> > Dennis Dawkins |Senior Delivery Operations Lead| HMRC CDIO Digital - 
> > Software Developers Collaboration -  Software Developers Support Team 
> > (SDST) | 2nd Floor, Accounts Office Shipley, Victoria Street, Shipley BD98 
> > 8AA
> > 
> > The information in this e-mail and any attachments is confidential and may 
> > be subject to legal professional privilege. Unless you are the intended 
> > recipient or his/her representative you are not authorised to, and must 
> > not, read, copy, distribute, use or retain this message or any part of it. 
> > If you are not the intended recipient, please notify the sender immediately.
> > 
> > HM Revenue & Customs computer systems will be monitored and communications 
> > carried on them recorded, to secure the effective operation of the system 
> > and for lawful purposes.
> > 
> > The Commissioners for HM Revenue and Customs are not liable for any 
> > personal views of the sender.   
> 
> Mike,
> 
> Can you attend the conference call and raise the issue about per-application 
> secret keys that we've discussed here? I'd do it but I'll be back in 
> California by then and I'm seldom compos mentis at 3AM.
> 
> Regards,
> John Ralls
> 

I don't think I'm best (or at all) qualified for this. I know almost nothing 
about UK tax, other than having to file my returns each year. Maybe someone 
better qualified would like to volunteer.

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


Fw: VAT Call for Software developers

2017-08-17 Thread 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 

Re: UK specific: MTD - Making Tax Digital

2017-05-01 Thread Mike Evans
On Mon, 17 Apr 2017 20:06:15 +0100
Mike Evans <mi...@saxicola.co.uk> wrote:

> On Mon, 17 Apr 2017 19:34:36 +0100
> "Maf. King" <m...@chilwell.net> wrote:
> 
> > On Monday, 17 April 2017 16:39:02 BST Alain Williams wrote:  
> > > On Mon, Apr 17, 2017 at 04:00:20PM +0100, David Goodenough wrote:
> > > > Apparently they have effectively locked out open source software as 
> > > > there
> > > > is a per application (i.e. there would be one just for GnuCash) "secret"
> > > > that is used during the OAuth2 login.  Keeping that value secret is not
> > > > possible in open source (closed source just hard code it into their 
> > > > code)
> > > > so effectively open source can not be used.
 
The authorisation process is described at: 
https://developer.service.hmrc.gov.uk/api-documentation/docs/authorisation


I've CC'd this to the devel list.

Mike E

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


Re: Compiling on Fedora25

2017-04-15 Thread Mike Evans
On Sat, 15 Apr 2017 08:32:29 -0500
Rob Gowin <r...@gowin.net> wrote:

> On Sat, Apr 15, 2017 at 3:24 AM, Mike Evans <mi...@saxicola.co.uk> wrote:
> 
> >
> > Compiling using cmake I get a different error messages:
> >
> > In file included from /usr/include/sys/types.h:25:0,
> >  from /home/mikee/Projects/gnucash/
> > src/libqof/qof/md5.c:27:
> > /usr/include/features.h:331:4: error: #warning _FORTIFY_SOURCE requires
> > compiling with optimization (-O) [-Werror=cpp]
> >  #  warning _FORTIFY_SOURCE requires compiling with optimization (-O)
> > ^~~
> >
> > Any thoughts?
> >
> > Regards Mike E
> >  
> 
> Hi Mike,
> 
> Looks like I need to backport this commit on master to maint:
> https://github.com/Gnucash/gnucash/commit/992f3232ee90cfcf6484a0fdb4cf506168676a40
> 
> In the meantime as a workaround, on line 419 of the top level
> CMakeLists.txt file, you can change -D_FORTIFY_SOURCE=2 to
> -U_FORTIFY_SOURCE.to continue.
> 
> Regards,
> 
> Rob

Many thanks Rob. That fixed the cmake build.

Best Regards

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


Compiling on Fedora25

2017-04-15 Thread 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?

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


Re: API for creating invoices?

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


Re: Bug 756469

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


Re: Bug 756469

2016-01-13 Thread Mike Evans
On Tue, 12 Jan 2016 17:48:58 +0100
Geert Janssens <geert.gnuc...@kobaltwit.be> wrote:

> On Tuesday 12 January 2016 10:11:25 Derek Atkins wrote:
> > Hi,
> > 
> > On Tue, January 12, 2016 9:52 am, Mike Evans wrote:
> > > Hi Geert.
> > > 
> > > I'd appreciate some advice on this bug, since you were that last
> > > person to touch the (makes my head hurt) regex.
> > > 
> > > In file dialog-bi-import-gui.c line 328 The regex for description,
> > > and notes is currently:
> > > 
> > > ((?[^\",]*)|\"(?[^\"]*)\")\"
> > 
> > This regex is basically looking for anything within double-quotes,
> > except for another double-quote.
> > 
> > The issue would be handling something like:
> > 
> >   """"
> > 
> > I.e., in order to escape a double-quote you use a double-double-quote.
> > This regex does not handle that case.  So it's basically saying "get
> > me everything between the double quotes (without acknowledging the
> > double-double-quote scenario.
> > 
> > > I'm not a regex guru but it seems to me that losing the [^\"] part
> > > and just using . would accept the problem lines. This wouldn't
> > > strip the extra " from the escaped quote, but it would at least be
> > > imported and editable later.  I'd have thought that just accepting
> > > everything inside the quoted field would be the correct behaviour?
> > 
> > Unfortunately I don't think that would work.  The construct:
> > 
> >   [^\"]*
> > 
> > says to match anything but a double-quote.  More likely we need to
> > change it to:
> > 
> >   (?([^\"]|\"\")*)
> > 
> > I think this will tell it to match anything but a double-quote, or a
> > double-double-quote, as many times as they occur.
> > 
> > Can you try this?
> > 
> > > Mike E
> > 
> > -derek
> 
> Wow Derek, you're fast... I saw your response on the list before I even 
> received Mike's original 
> question...
> 
> Anyway, I would also go for your suggestion. Simply replacing [^\"] with a 
> "." could cause the 
> rexexp to match too much.
> 
> Regards,
> 
> Geert


Thanks Geert and Derek

That works just fine. I should now code the conversion of the accepted "" into 
a single " before creating the invoice.

Many thanks

Mike E

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


Re: Flickering drop down boxes on mouse over

2016-01-12 Thread Mike Evans
On Tue, 12 Jan 2016 12:42:02 +0100
Geert Janssens <geert.gnuc...@kobaltwit.be> wrote:

> On Wednesday 30 December 2015 13:14:09 Mike Evans wrote:
> > On Wed, 30 Dec 2015 09:40:48 +0100
> > 
> > Geert Janssens <geert.gnuc...@kobaltwit.be> wrote:
> > > On Monday 28 December 2015 15:12:26 Mike Evans wrote:
> > > > The dropdown selection boxes in a register or invoice view
> > > > flicker, as if they're having multiple refreshes, each time the
> > > > mouse pointer enters or leaves the box. Has anyone else
> > > > experienced this? I'm Using Fedora18 32 bit OS.  I'm not quite
> > > > sure when this started, several weeks or so. Just asking here
> > > > before I file a bug just in case it's not GnuCash but some other
> > > > system glitch.
> > > > 
> > > > Mike E
> > > 
> > > I only got to testing this now.
> > > 
> > > I'm seeing this as well on Fedora 22, 64bit.
> > > 
> > > I never noticed this before because I'm usually using keyboard
> > > navigation in the register views.
> > > 
> > > Geert
> > 
> > It appears this is related to display settings in KDE, at least in my
> > case it is.  Logging out and in using the failsafe options, in which
> > I just get an xterm, GnuCash doesn't have this issue. Neither does my
> > laptop running PCLinuxOS and KDE.
> > 
> > I'm just remembering that some months ago KDE screwed up my settings
> > (again) amongst the issues was the disappearance lots of icons. My
> > usual recovery method is deleting .kde directory and starting again.
> > I'm thinking that this is about the time the trouble started. I also
> > note that the button to activate the dropdown is round not square
> > like it used to be and on my laptop. Somewhere in my
> > settings/themes/appearance setup there's probably a way to bring some
> > sanity back to the desktop settings. Somewhere...
> > 
> > Mike E
> 
> If you find it, please share on the list so I can fix it here as well :)
> 
> Geert

Hi Geert, Happy new year.

I never fixed it. Except I did change my desktop to Xfce and there's no more 
flickering. Not really fix though. I will say Kfce is a lot faster and uses 
less memory than KDE.  I've not missed any of KDE's bells & whistles at all.
I got my icons back by: yum reinstall hicolor-icon-theme . I've no idea as to 
how they got screwed up though and was likely not connected to the flickering 
issue at all.

Mike

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


Re: gnucash-docs maint: Change paper format to A4 for European PDFs.

2016-01-01 Thread 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=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

2015-12-30 Thread Mike Evans
On Wed, 30 Dec 2015 09:40:48 +0100
Geert Janssens <geert.gnuc...@kobaltwit.be> wrote:

> On Monday 28 December 2015 15:12:26 Mike Evans wrote:
> > The dropdown selection boxes in a register or invoice view flicker, as
> > if they're having multiple refreshes, each time the mouse pointer
> > enters or leaves the box. Has anyone else experienced this? I'm Using
> > Fedora18 32 bit OS.  I'm not quite sure when this started, several
> > weeks or so. Just asking here before I file a bug just in case it's
> > not GnuCash but some other system glitch.
> > 
> > Mike E
> 
> I only got to testing this now.
> 
> I'm seeing this as well on Fedora 22, 64bit.
> 
> I never noticed this before because I'm usually using keyboard navigation in 
> the register views.
> 
> Geert

It appears this is related to display settings in KDE, at least in my case it 
is.  Logging out and in using the failsafe options, in which I just get an 
xterm, GnuCash doesn't have this issue. Neither does my laptop running 
PCLinuxOS and KDE.

I'm just remembering that some months ago KDE screwed up my settings (again) 
amongst the issues was the disappearance lots of icons. My usual recovery 
method is deleting .kde directory and starting again. I'm thinking that this is 
about the time the trouble started. I also note that the button to activate the 
dropdown is round not square like it used to be and on my laptop. Somewhere in 
my settings/themes/appearance setup there's probably a way to bring some sanity 
back to the desktop settings. Somewhere...

Mike E

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


Re: Flickering drop down boxes on mouse over

2015-12-29 Thread 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=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

2015-12-29 Thread Mike Evans
On Tue, 29 Dec 2015 14:13:21 +0100
"Frank H. Ellenberger" <frank.h.ellenber...@gmail.com> wrote:

> Am 28.12.2015 um 16:12 schrieb Mike Evans:
> > The dropdown selection boxes in a register or invoice view flicker, as if 
> > they're having multiple refreshes, each time the mouse pointer enters or 
> > leaves the box. Has anyone else experienced this? I'm Using Fedora18 32 bit 
> > OS.  I'm not quite sure when this started, several weeks or so. Just asking 
> > here before I file a bug just in case it's not GnuCash but some other 
> > system glitch.
> > 
> > Mike E
> > 
> 
> I can confirm it for git Version 8838cee+ from 2015-12-27
> and Version df6326f+ from 2015-07-10 (2.6.7)
> 
> FEll

I've just gone back to a (random) commit in Jan 2014 and it still flickers.  I 
can't believe it's been doing that for two years and I haven't noticed it so it 
must(?) be something has changed outside of GnuCash.

Mike E

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


Flickering drop down boxes on mouse over

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


FYI. Bitcoin news.

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


Re: Using LibreOffice for Documentation

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


Using LibreOffice for Documentation

2015-09-03 Thread 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

2015-09-03 Thread Mike Evans
On Wed, 2 Sep 2015 22:06:30 -0400
"David T." <sunfis...@yahoo.com> wrote:

>  I mean, if there actually were a group of even 4 people actively working on 
> documentation in any given month, I would be surprised. Given this reality, 
> is it REALLY necessary to use industrial version control on two (admittedly 
> somewhat complex) documents? 

Regarding this...

Running 
git log  c180e4d1548857.. --format="%aN" --reverse | sort | uniq
which gives all the authors this year, in gnucash-docs returns the following 
list

Alex Aycinena
Benjamin Melançon
Carl Reinke
Chris Good
Cristian Marchi
DanielDodson
David
David T
Derek Atkins
Dmitry Pavlov
Frank H. Ellenberger
Geert Janssens
John Ralls
Mark Simpson
Martin Mainka
Mechtilde
Mechtilde Stehmann
Mike Evans
Raphael Kubo da Costa

which is 17 (after removing duplicates).

Mike E



-- 
PGP key:
http://pgp.mit.edu:11371/pks/lookup?op=get=0x00CDB13500D7AB53  

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


Re: Using AsciiDoc for Documentation

2015-09-02 Thread Mike Evans
On Tue, 1 Sep 2015 13:44:39 -0500
Rob Gowin <r...@gowin.net> wrote:

> 
> > On Sep 1, 2015, at 4:56 AM, Mike Evans <mi...@saxicola.co.uk> wrote:
> >> [snip]
> > 
> > Hi Rob
> > 
> > Looks good to me. Still a few minor bugs with the Asciidoc.  
> > 
> > Some of the Figure titles are missing
> > Second level bullet indents missing
> > 
> > But these are minor and some tweaking of the XSL should fix that.  Speaking 
> > of which, I notice the XSL isn't in github can you make that available 
> > somewhere so others can chip in with help? I'd also like to generate the 
> > Asciidoc locally so I can ensure both formats are from the same source for 
> > comparison purposes.
> > 
> > Now you (we) have to convince others to use Asciidoc!
> > 
> > I use Geany for my coding/writing and there is a Markdown plugin for 
> > preview, no Asciidoc at the moment though.  I'm looking at the PEG code to 
> > see how difficult it would be to produce an Asciidoc previewer plugin.  It 
> > may be beyond my learning tolerance though.
> > 
> > Mike E
> > 
> > 
> > 
> > -- 
> > PGP key:
> > http://pgp.mit.edu:11371/pks/lookup?op=get=0x00CDB13500D7AB53  
> 
> 
> Hi Mike,
> 
> Thanks for taking a look. I have put the XSL file and a python
> script to run the conversion process in a repository at 
> https://github.com/codesmythe/asciidoc-conversion. See the README
> there for details.
> 
> As for editors, I just use a command line converter and then
> reload the generated HTML into a browser. I need to try some of the
> live preview editors mentioned in the link you sent out yesterday.
> 
> I'll look at the issues you mentioned in the next couple of days.
> 
> Thanks,
> 
> Rob
> 
> 
> 

Hi Rob

Bearing in mind this would only ever need to be run once for each document set 
and that Asciidoc may not be adopted anyway it's probably not worth spending a 
lot of effort on those final issues for the moment.  They can likely be 
easily(ish) fixed manually after conversion.  

Mike E

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


Re: Using AsciiDoc for Documentation

2015-09-01 Thread Mike Evans
On Sun, 30 Aug 2015 19:16:24 -0500
Rob Gowin <r...@gowin.net> wrote:

> [Hello List. Long time GnuCash user, -devel list lurker,
>  coming out of the shadows.]
> 
> > On Aug 29, 2015, at 5:43 AM, Mike Evans <mi...@saxicola.co.uk> wrote:
> > Another random thought then.
> >
> > I use asciidoc for pretty much all the docs I write, not much
> > admittedly but it's easy to learn and can produce many output formats.
> > I just used https://github.com/oreillymedia/docbook2asciidoc to
> > convert the guide to asciidoc using:
> >
> > $ java -jar /home/mikee/Projects/docbook2asciidoc/saxon9he.jar
> > -s gnucash-guide.xml -o gnucash-guide.asc
> > /home/mikee/Projects/docbook2asciidoc/d2a.xsl  chunk-output=true
> >
> > This produces an asccidoc file for each chapter plus the master page.
> >
> > [...]
> >
> > I'm not an expert on XML parsing using .xsl stylesheets but I suspect
> > this could be easily(?) remedied by editing the d2a.xsl to correctly
> > include the figures[...]
> 
> I am also a fan of using AsciiDoc as a documentation format. A
> while back I did some of the XSL hacking Mike refers to that is needed
> to get a decent conversion from the existing DocBook files. It's to
> the point where I would like to get some feedback.
> 
> I've done a first-pass conversion of the English version of the T & CG to
> AsciiDoc at https://github.com/codesmythe/gnucash-docs/tree/asciidoc/guide/C
> .
> You can click on the *.asc files there like ch_oview.asc to see GitHub's
> rendered verison of the file, including non-SVG images. (Note that SVG files
> and inter-chapter links don't work on GitHub's render.) You can click on the
> 'Raw' button for a file to see the AsciiDoc source. The source needs  clean
> up
> (lines too long, etc), but it is clean enough for folks to get an idea of
> the
> syntax. The GitHub web interace is useful because I think small edits could
> be
> done and sent as pull requests all from the web.
> 
> Like Mike said, the AsciiDoc tools (asciidoctor, at http://asciidoctor.org
> in
> this case) support the generation of DocBook XML files, so it's relatively
> simple to insert AsciiDoc support into the  current document generation
> flow.
> The asciidoctor tool generates DocBook output, and the existing flow for
> generating PDFs, HTML, EPUB, MOBI etc. works the same. My branch has the
> changes to the various Makefile.am files to support this. Those interested
> should be able to clone the repo, switch to the asciidoc branch and then
> 'make
> pdf' as usual. Note that the 'configure' script will expect to find the
> asciidoctor program on the system. I think the generated PDF is reasonably
> close to the original for a first pass proof of concept.  I've tested the
> flow
> on OS X and Fedora 21. Dunno about Windows.
> 
> Hopefully this little demo can move the documentation file format
> discussion
> forward a bit. :-) Thoughts?
> 
> 
> Regards,
> 
> Rob

Hi Rob

Looks good to me. Still a few minor bugs with the Asciidoc.  

Some of the Figure titles are missing
Second level bullet indents missing

But these are minor and some tweaking of the XSL should fix that.  Speaking of 
which, I notice the XSL isn't in github can you make that available somewhere 
so others can chip in with help? I'd also like to generate the Asciidoc locally 
so I can ensure both formats are from the same source for comparison purposes.

Now you (we) have to convince others to use Asciidoc!

I use Geany for my coding/writing and there is a Markdown plugin for preview, 
no Asciidoc at the moment though.  I'm looking at the PEG code to see how 
difficult it would be to produce an Asciidoc previewer plugin.  It may be 
beyond my learning tolerance though.

Mike E



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


Re: Replacing Docbook

2015-08-31 Thread Mike Evans
On Sat, 29 Aug 2015 16:52:48 +0200
Geert Janssens <geert.gnuc...@kobaltwit.be> wrote:

> On Saturday 29 August 2015 06:38:53 John Ralls wrote:
> > > On Aug 29, 2015, at 5:43 AM, Mike Evans <mi...@saxicola.co.uk>
> > > wrote:
> > > 
> > > Another random thought then.
> > > 
> > > I use asciidoc for pretty much all the docs I write, not much
> > > admittedly but it's easy to learn and can produce many output
> > > formats.  I just used
> > > https://github.com/oreillymedia/docbook2asciidoc to convert the
> > > guide to asciidoc using:
> > > 
> > > $ java -jar /home/mikee/Projects/docbook2asciidoc/saxon9he.jar -s
> > > gnucash-guide.xml -o gnucash-guide.asc
> > > /home/mikee/Projects/docbook2asciidoc/d2a.xsl  chunk-output=true
> > > 
> > > This produces an asccidoc file for each chapter plus the master
> > > page.  Converting this to html using
> > > 
> > > $ asciidoc  gnucash-guide.asc
> > > 
> > > produces the entire guide as html, of course many other output
> > > formats are possible including docbook.  The only issue is that
> > > *none* of the figures are included.  I'm not an expert on XML
> > > parsing using .xsl stylesheets but I suspect this could be
> > > easily(?) remedied by editing the d2a.xsl to correctly include the
> > > figures, as I say I'm no expert here.  Some of the (inevitable)
> > > minor formatting issues can be solved manually.
> > > 
> > > If solving the figures issue is possible then the documenters would
> > > need to learn asciidoc markup.  This is a lot easier than docbook
> > > though and since all the files are just plain ascii tracking
> > > changes in GIT are straightforward.  The concept of separate files
> > > for each chapter is also preserved.
> > > 
> > > As I say, just a thought.
> > > 
> > > Incidentally LibreOffice can also use multi-file documents/books,
> > > but I agree that change tracking is a barrier.
> > Mike,
> > 
> > Gee, deja-vu:
> > http://lists.gnucash.org/pipermail/gnucash-devel/2013-December/036626
> > .html and following.
> > 
> Informative thread... :)
> 
> It seems we're still rather stuck at the same spot.
> 
> The only new element so far is the detail that started this whole discussion 
> again: doxigen 
> can now parse markdown.
> 
> So yesterday I also did some first research on markdown as possible 
> alternative.
> 
> Pros:
> - relatively simple language so fairly easy to learn
> - It's widely used so it seems to attract several developers to write tools 
> for it. While I haven't 
> immediately found true wysiwyg editors there are several editors available 
> (both online and 
> offline) that show live previews for all OS's we currently support.
> - Convertible into most formats we care about, including docbook (via 
> doxigen).
> 
> Cons:
> - still a language to learn
> - no true wysiwyg editors (at least I haven't found one yet)
> 
> What I haven't investigated yet is how easy/hard it would be to convert the 
> existing 
> documentation, nor how it deals with images and links when used in offline 
> mode.
> 
> Geert

Some potentially useful asciidoc editors 
http://asciidoctor.org/docs/editing-asciidoc-with-live-preview/

Mike E

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


Re: Replacing Docbook

2015-08-29 Thread Mike Evans
On Sat, 29 Aug 2015 06:38:53 -0700
John Ralls jra...@ceridwen.us wrote:

 
  On Aug 29, 2015, at 5:43 AM, Mike Evans mi...@saxicola.co.uk wrote:
  
  Another random thought then.
  
  I use asciidoc for pretty much all the docs I write, not much admittedly 
  but it's easy to learn and can produce many output formats.  I just used 
  https://github.com/oreillymedia/docbook2asciidoc to convert the guide to 
  asciidoc using:
  
  $ java -jar /home/mikee/Projects/docbook2asciidoc/saxon9he.jar -s 
  gnucash-guide.xml -o gnucash-guide.asc 
  /home/mikee/Projects/docbook2asciidoc/d2a.xsl  chunk-output=true
  
  This produces an asccidoc file for each chapter plus the master page.  
  Converting this to html using 
  
  $ asciidoc  gnucash-guide.asc
  
  produces the entire guide as html, of course many other output formats are 
  possible including docbook.  The only issue is that *none* of the figures 
  are included.  I'm not an expert on XML parsing using .xsl stylesheets but 
  I suspect this could be easily(?) remedied by editing the d2a.xsl to 
  correctly include the figures, as I say I'm no expert here.  Some of the 
  (inevitable) minor formatting issues can be solved manually.
  
  If solving the figures issue is possible then the documenters would need to 
  learn asciidoc markup.  This is a lot easier than docbook though and since 
  all the files are just plain ascii tracking changes in GIT are 
  straightforward.  The concept of separate files for each chapter is also 
  preserved.
  
  As I say, just a thought.
  
  Incidentally LibreOffice can also use multi-file documents/books, but I 
  agree that change tracking is a barrier.
 
 Mike,
 
 Gee, deja-vu: 
 http://lists.gnucash.org/pipermail/gnucash-devel/2013-December/036626.html 
 and following.
 
 Regards,
 John Ralls
 
 

Oh dear, early stages of dementia perhaps?

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


Re: Replacing Docbook

2015-08-29 Thread Mike Evans
On Fri, 28 Aug 2015 21:38:18 +0200
Geert Janssens geert.gnuc...@kobaltwit.be wrote:
SNIP
 
 I did the same exercise just now. Note that I used the latest svn revision of 
 docbook2odf (r253) 
 which is slightly more recent than the ones found on the download page.
 
 The screenshots are all there on my system, although many of them are 
 improperly sized. 
 That's probably because we have been sloppy at that in our docbook version as 
 well and just 
 relied on the images being viewed at 100% size. That's probably not ok in odt 
 which is geared 
 towards printing.
 
 During the conversion there was an error for 4 pnm image files not being 
 found. I suspect 
 these are the images used to highlight warnings and tips and such. I didn't 
 see those in the odt 
 file.
 
 The image we had in multiple resolutions (the accounting equation) is added 3 
 times, probably 
 because we had specified it 3 times in our source.
 
 The table of contents is missing as is the list of figures and tables.
 
 It's getting worse: all cross-references are gone.
 
 And worse: I did one single edit - remove the vertical docbook2odf banner. I 
 did so by removing 
 the page header in the page settings.
 This resulted in a git diff of a whopping +1351/-1368 line changes. Most of 
 the changes are 
 arbitrary like styles changing names, changing regional settings, adding 
 soft-page-breaks,...
 
 Of course this can all be easily committed into git. However it will be 
 rather difficult to follow 
 changes made if the patches are so full of gratuitous changes.
 
 If we can't get libreoffice to make less noisy diffs, it's very unlikely it 
 will be in improvement 
 over the current situation.
 
 Regards,
 
 Geert

Another random thought then.

I use asciidoc for pretty much all the docs I write, not much admittedly but 
it's easy to learn and can produce many output formats.  I just used 
https://github.com/oreillymedia/docbook2asciidoc to convert the guide to 
asciidoc using:

$ java -jar /home/mikee/Projects/docbook2asciidoc/saxon9he.jar -s 
gnucash-guide.xml -o gnucash-guide.asc 
/home/mikee/Projects/docbook2asciidoc/d2a.xsl  chunk-output=true

This produces an asccidoc file for each chapter plus the master page.  
Converting this to html using 

$ asciidoc  gnucash-guide.asc

produces the entire guide as html, of course many other output formats are 
possible including docbook.  The only issue is that *none* of the figures are 
included.  I'm not an expert on XML parsing using .xsl stylesheets but I 
suspect this could be easily(?) remedied by editing the d2a.xsl to correctly 
include the figures, as I say I'm no expert here.  Some of the (inevitable) 
minor formatting issues can be solved manually.

If solving the figures issue is possible then the documenters would need to 
learn asciidoc markup.  This is a lot easier than docbook though and since all 
the files are just plain ascii tracking changes in GIT are straightforward.  
The concept of separate files for each chapter is also preserved.

As I say, just a thought.

Incidentally LibreOffice can also use multi-file documents/books, but I agree 
that change tracking is a barrier.

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


Re: Replacing Docbook

2015-08-28 Thread Mike Evans
On Fri, 28 Aug 2015 15:15:58 +0100
Mike Evans mi...@saxicola.co.uk wrote:

 On Fri, 28 Aug 2015 11:00:26 +0200
 Geert Janssens geert.gnuc...@kobaltwit.be wrote:
 
  On Friday 28 August 2015 09:45:44 John Ralls wrote:
On Aug 28, 2015, at 9:03 AM, Geert Janssens
geert.gnuc...@kobaltwit.be wrote:

Thanks for the heads up. That's certainly an interesting opportunity
to check out. On the other hand I wonder if markdown has enough
structure enforcement (for example to ensure contributors will
really use header markup instead of bold/underline where needed). I
do agree that docbook xml is a big hurdle for newcomers and even
not really appealing to more experienced people. So if we can find
a good middleground I'd be all for it.

Here's another option I have been pondering for a while, and just
now took the time to do some minimal research on:
http://blog.riemann.cc/2013/04/23/versioning-of-openoffice-libreoff
ice-documents-using-git/#comment-2209333934
http://blog.riemann.cc/2013/04/23/versioning-of-openoffice-libreof
fice-documents-using-git/#comment-2209333934

Move away from docbook completely and instead save our documents in
flat odt. Advantages: - This is a format that's easy to store and
manage in git.
- There is a free wysiwyg editor that's universally available:
libreoffice. Most people learn how to use it relatively quickly as
most of them have used word processors before. - libreoffice can
export to pdf. I even installed a plugin once to convert odt to
epub, which worked reasonably well. - libreoffice can also be used
headless for document conversion so it can be integrated in
automated build processes. - in theory libreoffice can even export
to html (though I have no idea of the quality).
   I’ve used libre/openoffice to create html. It works reasonably well.
   Calibre’s docs say it can ingest ODT, which will take care of the
   ebook and mobi outputs.
   
   http://open.comsultia.com/docbook2odf/about
   http://open.comsultia.com/docbook2odf/about looks like the
   least-obsolete way to convert from DocBook to ODT. Its SVN repo was
   last updated in 2009 but our DocBook version is pretty old too so it
   will probably work OK.
   
   Any disadvantages?
   
  The first one is mentioned in a comment of the blog post I referred to: 
  libreoffice saves soft 
  page breaks. These tend to all shift up and down when making edits. So the 
  diffs will be 
  slightly cluttered. We may be able to fix these by simply filtering them 
  out before committing, 
  however that would again mean a manual action for the contributor. We may 
  also just decide 
  to live with them.
  
  That's the only disadvantage I'm currently aware of. A trial run will 
  likely give us more insight 
  and in worst case reveal potential show-stoppers.
  
  Geert
 
 I just tried docbook2odf with the guide and it does a reasonably good job.  
 Some imgaes need resizing and there's a Generated by docbooktoodf side bar 
 on every page.  A little editing though and it should look OK.
 
 Using GIT with LibreOffice works quite well after installing some python 
 utils.
 
 Mike E 
 
Oh, dear.  More scrolling revealed loads of missing images.

Mike E


-- 
PGP key:
http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x00CDB13500D7AB53  

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


Re: Replacing Docbook

2015-08-28 Thread Mike Evans
On Fri, 28 Aug 2015 11:00:26 +0200
Geert Janssens geert.gnuc...@kobaltwit.be wrote:

 On Friday 28 August 2015 09:45:44 John Ralls wrote:
   On Aug 28, 2015, at 9:03 AM, Geert Janssens
   geert.gnuc...@kobaltwit.be wrote:
   
   Thanks for the heads up. That's certainly an interesting opportunity
   to check out. On the other hand I wonder if markdown has enough
   structure enforcement (for example to ensure contributors will
   really use header markup instead of bold/underline where needed). I
   do agree that docbook xml is a big hurdle for newcomers and even
   not really appealing to more experienced people. So if we can find
   a good middleground I'd be all for it.
   
   Here's another option I have been pondering for a while, and just
   now took the time to do some minimal research on:
   http://blog.riemann.cc/2013/04/23/versioning-of-openoffice-libreoff
   ice-documents-using-git/#comment-2209333934
   http://blog.riemann.cc/2013/04/23/versioning-of-openoffice-libreof
   fice-documents-using-git/#comment-2209333934
   
   Move away from docbook completely and instead save our documents in
   flat odt. Advantages: - This is a format that's easy to store and
   manage in git.
   - There is a free wysiwyg editor that's universally available:
   libreoffice. Most people learn how to use it relatively quickly as
   most of them have used word processors before. - libreoffice can
   export to pdf. I even installed a plugin once to convert odt to
   epub, which worked reasonably well. - libreoffice can also be used
   headless for document conversion so it can be integrated in
   automated build processes. - in theory libreoffice can even export
   to html (though I have no idea of the quality).
  I’ve used libre/openoffice to create html. It works reasonably well.
  Calibre’s docs say it can ingest ODT, which will take care of the
  ebook and mobi outputs.
  
  http://open.comsultia.com/docbook2odf/about
  http://open.comsultia.com/docbook2odf/about looks like the
  least-obsolete way to convert from DocBook to ODT. Its SVN repo was
  last updated in 2009 but our DocBook version is pretty old too so it
  will probably work OK.
  
  Any disadvantages?
  
 The first one is mentioned in a comment of the blog post I referred to: 
 libreoffice saves soft 
 page breaks. These tend to all shift up and down when making edits. So the 
 diffs will be 
 slightly cluttered. We may be able to fix these by simply filtering them out 
 before committing, 
 however that would again mean a manual action for the contributor. We may 
 also just decide 
 to live with them.
 
 That's the only disadvantage I'm currently aware of. A trial run will likely 
 give us more insight 
 and in worst case reveal potential show-stoppers.
 
 Geert

I just tried docbook2odf with the guide and it does a reasonably good job.  
Some imgaes need resizing and there's a Generated by docbooktoodf side bar on 
every page.  A little editing though and it should look OK.

Using GIT with LibreOffice works quite well after installing some python utils.

Mike E 

-- 
PGP key:
http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x00CDB13500D7AB53  

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


Re: How are Budgets Implemented in GNU Cash

2015-07-16 Thread Mike Evans
On Thu, 16 Jul 2015 19:10:46 +1000
Matt Graham matt_graham2...@hotmail.com wrote:

 I would like to contribute to GNUCash, and get into the development side of 
 the house.
 
 I figure that a (relatively) quick and easy contribution (that will also help 
 me personally) is for me to create a patch to correct the bug where budgeted 
 expenses don’t show up in the summary section at the bottom of the screen 
 (https://bugzilla.gnome.org/show_bug.cgi?id=742352).
 
 My problem is that I cannot find (from the documentation) where the budget 
 side of code is implemented within GNU Cash (even after much Googling). Can 
 anyone steer me towards somewhere to look for more information about how 
 Budgets are implemented?
 
 Thanks,
 
 Matt
Have look in:
http://svn.gnucash.org/docs/HEAD/group__budget.html 
src/engine/gnc-budget.c
src/doc/budget.txt

Not sure how up to date that document is though.

-- 
Anti NSA?  Use PGP.
http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x00CDB13500D7AB53  

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


Re: Make check fails in src/import-export

2015-01-12 Thread Mike Evans
On Sun, 11 Jan 2015 19:02:22 +0100
Geert Janssens geert.gnuc...@kobaltwit.be wrote:

 On Sunday 11 January 2015 09:43:48 John Ralls wrote:
   On Jan 11, 2015, at 9:33 AM, Mike Evans mi...@saxicola.co.uk
   wrote:
   
   On Sun, 11 Jan 2015 09:16:19 -0800
   
   John Ralls jra...@ceridwen.us wrote:
   On Jan 11, 2015, at 8:31 AM, Mike Evans mi...@saxicola.co.uk
   wrote:
   
   With the following output snippet:
   
   
   make[2]: Entering directory
   `/home/mikee/Projects/gnucash/build/src/import-export/test' PASS:
   test-link
   Backtrace:
   In ../../../src/app-utils/gnucash/app-utils.scm:
   29:  0* (use-modules (gnucash gettext))
   29:  1  (eval-case (# # *unspecified*) (else #))
   29:  2  (begin (process-use-modules (list (list #)))
   *unspecified*)
   
   In unknown file:
?:  3* [process-use-modules (((gnucash gettext)))]
?:  4  (let* ((interfaces #)) (call-with-deferred-observers
(lambda () #))) ?:  5* [map #procedure #f (mif-args)
(((gnucash gettext)))] ?:  6* [#procedure #f (mif-args)
((gnucash gettext))]
?:  7* (or (apply resolve-interface mif-args) (error no such
module mif-args)) ?:  8* [apply #procedure resolve-interface
(name . args) ((gnucash gettext))] ?:  9  [resolve-interface
(gnucash gettext)]

 ...

?: 10  (let* (# # # # ...) (and # #) (if # public-i #))
?: 11* (and (or (not module) (not public-i)) (error no code for
module name)) ?: 12  [error no code for module (gnucash
gettext)]

 ...

?: 13  [scm-error misc-error #f ...]
   
   unnamed port: In procedure scm-error in expression (scm-error
   (quote misc-error) #f ...): unnamed port: no code for module
   (gnucash gettext)
   FAIL: test-import-parse
   ==
   1 of 2 tests failed
   Please report to gnucash-devel@gnucash.org
   ==
   make[2]: *** [check-TESTS] Error 1
   make[2]: Leaving directory
   `/home/mikee/Projects/gnucash/build/src/import-export/test'
   make[1]: *** [check-am] Error 2
   make[1]: Leaving directory
   `/home/mikee/Projects/gnucash/build/src/import-export/test' make:
   *** [check-recursive] Error 1
   
   
   Thoughts?
   
   Could be a problem with a cached .go. Try deleting ~/.cache/guile
   and $PREFIX/share/gnucash/scm/ccache.
   
   Regards,
   John Ralls
   
   Hi John.
   
   rm -rf  /home/mikee/.cache/*
   rm -rf  /home/mikee/.ccache/*
   rm /home/mikee/progs/gnucash-maint/share/gnucash/scm/cache
   rm /home/mikee/progs/gnucash-maint/share/gnucash/scm/ccache
   
   Still same results.
   
   But from the backtrace, I have no
   ../../../src/app-utils/gnucash/app-utils.scm .  This file is at
   actually at ../../../src/app-utils/app-utils.scm  Where is this
   path defined?
  Those links are made by the scm-links target in
  src/app-utils/Makefile.am. Maybe you need to do a clean build.
  
  Regards,
  John Ralls
  
  
  ___
  gnucash-devel mailing list
  gnucash-devel@gnucash.org
  https://lists.gnucash.org/mailman/listinfo/gnucash-devel
 
 Or remove the hidden file .scm-links
 
 The links will then be regenerated.
 
 Geert

Thanks Geert  John.  I did a fresh build and all was well again.  I've added 
tests for when the deposit or withdrawal fields are either empty or are just 
space(es).

MikeE

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


Make check fails in src/import-export

2015-01-11 Thread 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 #procedure #f (mif-args) (((gnucash gettext)))]
   ?:  6* [#procedure #f (mif-args) ((gnucash gettext))]
   ?:  7* (or (apply resolve-interface mif-args) (error no such module 
mif-args))
   ?:  8* [apply #procedure resolve-interface (name . args) ((gnucash 
gettext))]
   ?:  9  [resolve-interface (gnucash gettext)]
...
   ?: 10  (let* (# # # # ...) (and # #) (if # public-i #))
   ?: 11* (and (or (not module) (not public-i)) (error no code for module 
name))
   ?: 12  [error no code for module (gnucash gettext)]
...
   ?: 13  [scm-error misc-error #f ...]

unnamed port: In procedure scm-error in expression (scm-error (quote 
misc-error) #f ...):
unnamed port: no code for module (gnucash gettext)
FAIL: test-import-parse
==
1 of 2 tests failed
Please report to gnucash-devel@gnucash.org
==
make[2]: *** [check-TESTS] Error 1
make[2]: Leaving directory 
`/home/mikee/Projects/gnucash/build/src/import-export/test'
make[1]: *** [check-am] Error 2
make[1]: Leaving directory 
`/home/mikee/Projects/gnucash/build/src/import-export/test'
make: *** [check-recursive] Error 1


Thoughts?

Mike E


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


Re: Make check fails in src/import-export

2015-01-11 Thread Mike Evans
On Sun, 11 Jan 2015 09:16:19 -0800
John Ralls jra...@ceridwen.us wrote:

 
  On Jan 11, 2015, at 8:31 AM, Mike Evans mi...@saxicola.co.uk wrote:
  
  With the following output snippet: 
  
  
  make[2]: Entering directory 
  `/home/mikee/Projects/gnucash/build/src/import-export/test'
  PASS: test-link
  Backtrace:
  In ../../../src/app-utils/gnucash/app-utils.scm:
   29:  0* (use-modules (gnucash gettext))
   29:  1  (eval-case (# # *unspecified*) (else #))
   29:  2  (begin (process-use-modules (list (list #))) *unspecified*)
  In unknown file:
?:  3* [process-use-modules (((gnucash gettext)))]
?:  4  (let* ((interfaces #)) (call-with-deferred-observers (lambda () 
  #)))
?:  5* [map #procedure #f (mif-args) (((gnucash gettext)))]
?:  6* [#procedure #f (mif-args) ((gnucash gettext))]
?:  7* (or (apply resolve-interface mif-args) (error no such module 
  mif-args))
?:  8* [apply #procedure resolve-interface (name . args) ((gnucash 
  gettext))]
?:  9  [resolve-interface (gnucash gettext)]
 ...
?: 10  (let* (# # # # ...) (and # #) (if # public-i #))
?: 11* (and (or (not module) (not public-i)) (error no code for module 
  name))
?: 12  [error no code for module (gnucash gettext)]
 ...
?: 13  [scm-error misc-error #f ...]
  
  unnamed port: In procedure scm-error in expression (scm-error (quote 
  misc-error) #f ...):
  unnamed port: no code for module (gnucash gettext)
  FAIL: test-import-parse
  ==
  1 of 2 tests failed
  Please report to gnucash-devel@gnucash.org
  ==
  make[2]: *** [check-TESTS] Error 1
  make[2]: Leaving directory 
  `/home/mikee/Projects/gnucash/build/src/import-export/test'
  make[1]: *** [check-am] Error 2
  make[1]: Leaving directory 
  `/home/mikee/Projects/gnucash/build/src/import-export/test'
  make: *** [check-recursive] Error 1
  
  
  Thoughts?
 
 Could be a problem with a cached .go. Try deleting ~/.cache/guile and 
 $PREFIX/share/gnucash/scm/ccache.
 
 Regards,
 John Ralls
 

Hi John.

rm -rf  /home/mikee/.cache/*
rm -rf  /home/mikee/.ccache/*
rm /home/mikee/progs/gnucash-maint/share/gnucash/scm/cache
rm /home/mikee/progs/gnucash-maint/share/gnucash/scm/ccache

Still same results.

But from the backtrace, I have no ../../../src/app-utils/gnucash/app-utils.scm 
.  This file is at actually at  
 ../../../src/app-utils/app-utils.scm  Where is this path defined?  




MikeE


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


Re: Bug 734183

2014-08-07 Thread Mike Evans
On Wed, 06 Aug 2014 18:01:52 +0200
Geert Janssens janssens-ge...@telenet.be wrote:

 On Wednesday 06 August 2014 16:00:21 Mike Evans wrote:
  
  HiGeert.
  
  
  n is set to 25 using gnc_exp_parser_parse (discount, n, NULL); just
  after it's set to gnc_numeric_zero ();  Taking the zeroing line out
  doesn't change the behaviour though.
  
 Oh right. Probably this isn't working for me because my decimal separator is 
 ,.
 
 Sorry for the false suggestion.
 
  Where discount is read from the file.  When the invoice is opened
  after import the 25.00 is shown in the discount column but the price
  hasn't been discounted, the line total is still at original price.
  
  The gncEntryGetDocDiscountValue () function calls the
  gncEntry::gncEntryRecomputeValues() function which should set he
  discount to be applied.
 
 Yes, it does. As an aside This is a horribly backward way of doing things and 
 source of various 
 bugs. We should definitely fix this at some point.
 
 I fixed the import file for my locale and reran the debugger. The 
 gncEntryRecomputeValues 
 function effectively does nothing in this case because the entry has no 
 Invoice tax table set. 
 The recalculation only happens when there is either a bill or an invoice tax 
 table.
 
 So that would explain why the discount is not substracted.
 
 Geert

Ah found it by looking in the .gnucash xml file.  The discount is saved as 25/1 
and the price as 75/1.  In gncEntryComputeValues() the denom is read from the 
currency, ie 100 so it divides 25 by the denom and gets the wrong answers which 
is effectively zero.  Hence no discount.  I need to run 
gnc_numeric_convert(...) to set the denom correctly.

Thanks Geert, sometimes just asking the questions out loud is what's needed. 
:)

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


Bug 734183

2014-08-06 Thread 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=getsearch=0x00CDB13500D7AB53  
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: Bug 734183

2014-08-06 Thread Mike Evans
On Wed, 06 Aug 2014 15:49:08 +0200
Geert Janssens janssens-ge...@telenet.be wrote:

 On Wednesday 06 August 2014 10:25:12 Mike Evans wrote:
  Hi All
  
  I'm having a little trouble tracking this down, (some of) the code for
  creating an entry with discount is shown below:
  
  entry = gncEntryCreate (book);
  gncEntryBeginEdit(entry);
  // More code here...
  gnc_exp_parser_parse (discount, n, NULL);
  gncEntrySetInvDiscount (entry, n);
  gncEntrySetInvDiscountType (entry, text2disc_type
  (disc_type)); gncEntrySetInvDiscountHow (entry, text2disc_how
  (disc_how)); gncEntryCommitEdit(entry);
  n = gncEntryGetDocDiscountValue (entry, FALSE, TRUE, FALSE);
  DEBUG( Discount Value: %.2f\n,gnc_numeric_to_double(n));
  gncInvoiceAddEntry (invoice, entry);
  
  Having set the Discount, How and Type, the DEBUG line outputs - 
  Discount Value: 0.00 it should be the actual calculated discount.
  
  Why isn't the discount being set. calculated?  Is there a step I've
  missed?
  
  Looking through gnc_entry_ledger_save_cells(...) in
  gncEntryLedgerModel.c I can't see anything else that needs to be done
  to set the required values.
  
  Code is in: src/plugins/bi_import/dialoc-bi-import.c
  
  Mike
 
 Mike,
 
 I have ran the the master branch as of July 4 through gdb. It doesn't have 
 all the code exactly 
 as you pasted in your mail, but it's similar enough IMO.
 
 The line
   gnc_exp_parser_parse (discount, n, NULL);
 sets n to 0 (more strictly {0, 1}, a gnc_numeric). That doesn't seem correct, 
 or at least not what 
 you are expecting since discount has a value of 25.0. Maybe you should set 
 an error variable 
 instead of NULL in that function call and check its value for more clues.
 
 Geert

HiGeert.


n is set to 25 using gnc_exp_parser_parse (discount, n, NULL); just after it's 
set to gnc_numeric_zero ();  Taking the zeroing line out doesn't change the 
behaviour though.

Where discount is read from the file.  When the invoice is opened after import 
the 25.00 is shown in the discount column but the price hasn't been discounted, 
the line total is still at original price.

The gncEntryGetDocDiscountValue () function calls the 
gncEntry::gncEntryRecomputeValues() function which should set he discount to be 
applied.
 
 


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


Re: Import CSV Bills Invoices - Notes field

2014-06-18 Thread Mike Evans
On Wed, 18 Jun 2014 01:36:04 -0700
JP Liew jpl...@yahoo.com wrote:

 Hi all, 
 
 I did a search and was not able to find an answer to my question. 
 
 Basically, I would like to write an eBay or Paypal sales to GnuCash 
 invoice converter that will export eBay/PayPal sales to GnuCash CSV file that 
 can be imported by the Import Bills  Invoices.  The prototype 
 works ok except I was not able to figure out how to deal with multi-line
  Notes. 
 
 In GnuCash, a user can type multi-line notes, however in CSV, I 
 was not able to find a way to code the CR / LF in the Notes field. 
 
 If anyone has done this before, could you share some lights please?
 If not, can any let me know the actual src that is dealing with the part of 
 the import please? 
 
 https://github.com/Gnucash/gnucash/tree/master/src/import-export/csv-imp
 
 
 Cheers 
 John 
  
Hi John.

You should just be able to insert '\n' where you want the newline.

Regarding e-bay to invoices, I wrote a utility to create Bills from ebay 
purchases, there may be something useful in there.

https://github.com/EvansMike/pycash/tree/master/ebay2gnuCash

Mike E


-- 
Anti NSA?  Use PGP.
http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x00CDB13500D7AB53  

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


Compile fails latest maint 8d723f1b

2014-06-09 Thread 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=getsearch=0x00CDB13500D7AB53  
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: gnucash-docs master: Correct field format in python-import-fields.

2014-06-05 Thread Mike Evans
On Thu, 05 Jun 2014 09:58:25 +0200
Geert Janssens janssens-ge...@telenet.be wrote:

 On Monday 02 June 2014 07:39:57 Mike Evans wrote:
  Updated  via  https://github.com/Gnucash/gnucash-docs/commit/f3dbb107
  (commit) from 
  https://github.com/Gnucash/gnucash-docs/commit/6a5083c3 (commit)
  
  
  
  commit f3dbb1071c46d409f4d7ecf060cb2c279572ed42
  Author: Mike Evans mi...@millstreamcomputing.co.uk
  Date:   Mon Jun 2 12:53:01 2014 +0100
  
  Correct field format in python-import-fields.
  
  
  
  Summary of changes:
   guide/C/ch_import_business_data.xml | 14 +++---
   1 file changed, 7 insertions(+), 7 deletions(-)
  
  ___
  gnucash-patches mailing list
  gnucash-patc...@gnucash.org
  https://lists.gnucash.org/mailman/listinfo/gnucash-patches
 
 Mike,
 
 Shouldn't this change have gone into the maint branch ?
 
 It looks like a bugfix to me. Or does it fix something that's only wrong on 
 the master branch ?
 
 Geert

Hi Geert.

Yes it probably should.  Do I merge this or cherry-pick into maint? 

Mike E

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


Re: Make check files with python bindings.

2014-05-17 Thread Mike Evans
On Fri, 16 May 2014 11:38:59 -0700
John Ralls jra...@ceridwen.us wrote:

 
 On May 16, 2014, at 9:24 AM, Mike Evans mi...@saxicola.co.uk wrote:
 
  make  check-TESTS
  make[1]: Entering directory 
  `/home/mikee/Projects/gnucash/build/src/optional/python-bindings/tests'
  Traceback (most recent call last):
   File ./runTests.py, line 8, in module
 from test import 
  ImportError: cannot import name test_support
  FAIL: runTests.py
  ==
  1 of 1 test failed
  Please report to gnucash-devel@gnucash.org
  ==
  make[1]: *** [check-TESTS] Error 1
  make[1]: Leaving directory 
  `/home/mikee/Projects/gnucash/build/src/optional/python-bindings/tests'
  make: *** [check-am] Error 2
  
  
  
  This is on Fedora18.  There is no module test_support.  Modifying 
  runTests.py.in as below fixes the test.
  
  #!/usr/bin/python
  
  import unittest
  import os
  
  os.environ[GNC_UNINSTALLED] = 1
  
  #from test import test_support
  
  from test_book import TestBook
  from test_account import TestAccount
  from test_split import TestSplit
  from test_transaction import TestTransaction
  from test_business import TestBusiness
  
  def test_main():
 #test_support.run_unittest(TestBook, TestAccount, TestSplit, 
  TestTransaction, TestBusiness)
 unittest.main()
  
  if __name__ == '__main__':
 test_main()
  ###
  
  This is vaguely related to bug 730255.  Adding a test for that bug causes 
  the test to fail again. (As it should).  
  
  Just wondering if I've understood the test system before I commit and push 
  this.
  
 
 Just a guess: You’re using Python3, where the test_support module has been 
 renamed “support”.
 
 If so, it should be:
 import sys
 
 if sys.version_info[0]  3:
   from test import test_support
 else:
   from test import support as test_support
 
 And uncomment the line test_support.run_unittest…
 
 Regards,
 John Ralls
 

Hi John

Python 2.7.3. 

from test import test_support
ImportError: cannot import name test_support

Mike Evans

 

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


Re: Make check files with python bindings.

2014-05-17 Thread Mike Evans
On Sat, 17 May 2014 13:06 +0200
Geert Janssens janssens-ge...@telenet.be wrote:

 Do you have the python-test package installed ? Fedora has separated the 
 test support from python-devel. I ran into this a few months back on 
 Fedora 19 (20?) as well.
 
 Geert
 
Yes I do.
Package python-test-2.7.3-13.fc18.i686 already installed and latest version

On My system:

rpm -qi --whatprovides /usr/lib/python2.7/test/test_support.py
Name: python-libs
Version : 2.7.3
Release : 13.fc18
...

So test support is installed it seems.  I can import test but there are no 
modules in test.

NB: Reading the Python docs at https://docs.python.org/2/library/test.html
The top of the page says:

'''
Note

The test package is meant for internal use by Python only. It is documented for 
the benefit of the core developers of Python. Any use of this package outside 
of Python’s standard library is discouraged as code mentioned here can change 
or be removed without notice between releases of Python.
'''
?

Mike Evans


 On Saturday 17 May 2014 11:40:52 Mike Evans wrote:
  On Fri, 16 May 2014 11:38:59 -0700
  
  John Ralls jra...@ceridwen.us wrote:
   On May 16, 2014, at 9:24 AM, Mike Evans mi...@saxicola.co.uk 
 wrote:
make  check-TESTS
make[1]: Entering directory
`/home/mikee/Projects/gnucash/build/src/optional/python-bindings/
tests'  
Traceback (most recent call last):
 File ./runTests.py, line 8, in module
 
   from test import

ImportError: cannot import name test_support
FAIL: runTests.py
==
1 of 1 test failed
Please report to gnucash-devel@gnucash.org
==
make[1]: *** [check-TESTS] Error 1
make[1]: Leaving directory
`/home/mikee/Projects/gnucash/build/src/optional/python-bindings/
tests' make: *** [check-am] Error 2



This is on Fedora18.  There is no module test_support.  Modifying
runTests.py.in as below fixes the test. 
#!/usr/bin/python

import unittest
import os

os.environ[GNC_UNINSTALLED] = 1

#from test import test_support

from test_book import TestBook
from test_account import TestAccount
from test_split import TestSplit
from test_transaction import TestTransaction
from test_business import TestBusiness

def test_main():
   #test_support.run_unittest(TestBook, TestAccount, TestSplit,
   TestTransaction, TestBusiness) unittest.main()

if __name__ == '__main__':
   test_main()

###

This is vaguely related to bug 730255.  Adding a test for that bug
causes the test to fail again. (As it should).

Just wondering if I've understood the test system before I commit
and push this. 
   Just a guess: You’re using Python3, where the test_support module
   has been renamed “support”.
   
   If so, it should be:
   import sys
   
   if sys.version_info[0]  3:
 from test import test_support
   
   else:
 from test import support as test_support
   
   And uncomment the line test_support.run_unittest…
   
   Regards,
   John Ralls
  
  Hi John
  
  Python 2.7.3.
  
  from test import test_support
  ImportError: cannot import name test_support
  
  Mike Evans
 



-- 
Anti NSA?  Use PGP.
http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x00CDB13500D7AB53  

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


Make check files with python bindings.

2014-05-16 Thread 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 module
from test import 
ImportError: cannot import name test_support
FAIL: runTests.py
==
1 of 1 test failed
Please report to gnucash-devel@gnucash.org
==
make[1]: *** [check-TESTS] Error 1
make[1]: Leaving directory 
`/home/mikee/Projects/gnucash/build/src/optional/python-bindings/tests'
make: *** [check-am] Error 2



This is on Fedora18.  There is no module test_support.  Modifying 
runTests.py.in as below fixes the test.

#!/usr/bin/python

import unittest
import os

os.environ[GNC_UNINSTALLED] = 1

#from test import test_support

from test_book import TestBook
from test_account import TestAccount
from test_split import TestSplit
from test_transaction import TestTransaction
from test_business import TestBusiness

def test_main():
#test_support.run_unittest(TestBook, TestAccount, TestSplit, 
TestTransaction, TestBusiness)
unittest.main()

if __name__ == '__main__':
test_main()
###

This is vaguely related to bug 730255.  Adding a test for that bug causes the 
test to fail again. (As it should).  

Just wondering if I've understood the test system before I commit and push this.


Mike Evans



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


Business invoices over/pre payments

2014-04-30 Thread 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.

mouse over text
If you have selected an invoice, GnuCash will propose the amount still due for 
it. You can change this amount to create a partial payment or an over-payment.
In case of an over-payment or if no invoice was selected, GnuCash will 
automatically assign the remaining amount to the first unpaid invoice for this 
company.
If you have selected an invoice, GnuCash will propose the amount still due for 
it. You can change this amount to create a partial payment or an over-payment.
In case of an over-payment or if no invoice was selected, GnuCash will 
automatically assign the remaining amount to the first unpaid invoice for this 
company.
/mouse over text

I thought I'd ask here in case I'd misunderstood the procedure before filing a 
bug report.

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


Re: Business invoices over/pre payments

2014-04-30 Thread Mike Evans
On Wed, 30 Apr 2014 11:39:30 +0200
Geert Janssens janssens-ge...@telenet.be wrote:

 On Wednesday 30 April 2014 10:14:42 Mike Evans wrote:
  I've been struggling with paying multiple invoices with a single
  payment in version 2.6 and it doesn't work for me.  I've been
  reverting to version 2.4.13 to process my invoices.
  
 I hope it's just due to poor documentation. Let's see...
 
  Say I have two invoices the first for 400, the second for 600.  I
  receive a singe payment, by bank transfer, of 1000.  I open the
  payment dialog and pay 1000 against the first invoice.
 Did you know you can select two invoices at the same time in the payment 
 dialog ?
 
 If you have both invoices entered already that would be the easiest way to 
 assign the payment 
 to both invoices in one go.
 
  According to
  the mouseover text (below) the extra payment should be automatically
  assigned to the second invoice.  This was the old behaviour and
  worked perfectly, matching up the reality of the 1000 deposit and
  paying off both invoices at a single stroke(or click).
  
 That old behaviour has been disabled by default because without it you have 
 more control 
 over which invoice gets paid by the overpayment. You can re-enable it via 
 Preferences-
 Business. There's a separate checkbox to control the behaviour of invoices 
 and bills.
 
  Now however I try to so the same in 2.6 and it doesn't put the
  overpayent towards the next invoice like it should.  On attempting to
  pay the next invoice I see Pre-payment in the Process Payment dialog
  but no matter what I do with the Pre-payment it screws up my Bank
  register and doesn't get assigned to the invoice.
  
 Again, if you want to assign the pre-payment to your invoice you should 
 select both the invoice 
 and the pre-payment. That should render the amount to pay to zero and disable 
 the transfer 
 account list. If you now hit the ok button the payment will be assigned to 
 the selected invoice 
 without adding an extra line in your checkings account.
 
 Note that this only works correctly as of gnucash 2.6.3.
 
  Additionally, from the text below which states ...or if no invoice
  was selected... in either case I cannot make a payment without
  selecting an invoice.
  
  In short, the new invoice payment system is broken for me and I can't
  use version 2.6 for my business.
  
 I hope we're just dealing with ambiguous help texts here...
 
  mouse over text
  If you have selected an invoice, GnuCash will propose the amount still
  due for it. You can change this amount to create a partial payment or
  an over-payment. In case of an over-payment or if no invoice was
  selected, GnuCash will automatically assign the remaining amount to
  the first unpaid invoice for this company. If you have selected an
  invoice, GnuCash will propose the amount still due for it. You can
  change this amount to create a partial payment or an over-payment. In
  case of an over-payment or if no invoice was selected, GnuCash will
  automatically assign the remaining amount to the first unpaid invoice
  for this company. /mouse over text
  
 It looks to me this text has not been updated from the 2.4 era. In 2.6 you 
 can select several 
 invoice/payment lines together not one single invoice only. Additionally the 
 over-payments are 
 only automatically assigned to new invoices if the option is enabled in the 
 preferences.
 
 Any suggestion for a better mouse over text ?
 
 
 Geert

Hi Geert.

Ah OK, that clears everything up.  I didn't know about selecting multiple 
invoices and/or Pre-payments, or the Preferences option.  It definitely needs 
to go in the documentation.

As to mouse over text and the manual, I obviously need to have more experience 
with the new-fangled way of doing things before suggesting anything. :)

The two paras below are just me confirming the behaviour, it all seems to work 
as intended.

As a test in a new file I created two invoices of 400 each, posted them and 
received 1000 which I paid against invoice-01.  Then selecting invoice-02 + 
Prepayment(of 600) again processed the payment.  Now looking at my checking 
account I see 1000 in and 200 out.  But I wanted to keep that 200 against the 
next invoice I give the customer.  I can however delete that entry from the 
bank register and all is well again.

Now reopening the test account, without saving (in order to try again)  I do as 
above except, for invoice-02 I again select both the invoice and the 
Pre-payment and attempt to set it up so that the I get to keep the extra money. 
 On opening the dialog, in the Amount section, Payment = 0.0 and refund = 200, 
but I want to keep the 200. The customer is happy that I do this obviously.  
Setting Refund to 0.0 greys out entire Transfer Account tree, which was a 
little confusing as I thought I'd screwed up again, but clicking OK processes 
the money the way I want.  I get to keep the money!

I assume you refer to Auto pay on posting in the Preferences

Re: Business invoices over/pre payments

2014-04-30 Thread Mike Evans
On Wed, 30 Apr 2014 13:39:15 +0200
Geert Janssens janssens-ge...@telenet.be wrote:

 On Wednesday 30 April 2014 12:07:06 Mike Evans wrote:
  
  Hi Geert.
  
  Ah OK, that clears everything up.  I didn't know about selecting
  multiple invoices and/or Pre-payments, or the Preferences option.  It
  definitely needs to go in the documentation.
  
  As to mouse over text and the manual, I obviously need to have more
  experience with the new-fangled way of doing things before suggesting
  anything. :)
  
  The two paras below are just me confirming the behaviour, it all seems
  to work as intended.
  
  As a test in a new file I created two invoices of 400 each, posted
  them and received 1000 which I paid against invoice-01.  Then
  selecting invoice-02 + Prepayment(of 600) again processed the
  payment.  Now looking at my checking account I see 1000 in and 200
  out.  But I wanted to keep that 200 against the next invoice I give
  the customer.  I can however delete that entry from the bank register
  and all is well again.
  
  Now reopening the test account, without saving (in order to try again)
   I do as above except, for invoice-02 I again select both the invoice
  and the Pre-payment and attempt to set it up so that the I get to
  keep the extra money.  On opening the dialog, in the Amount section,
  Payment = 0.0 and refund = 200, but I want to keep the 200. The
  customer is happy that I do this obviously.  Setting Refund to 0.0
  greys out entire Transfer Account tree, which was a little confusing
  as I thought I'd screwed up again, but clicking OK processes the
  money the way I want.  I get to keep the money!
  
  I assume you refer to Auto pay on posting in the Preferences dialog?
This only works when posting a new invoice when a Pre-payment is
  already present.  If the two invoices are already posted before the
  (over)payment then the automatic payment doesn't happen, as it used
  to.  I had to unpost then re-post invoice-02 for this to work. 
  Perhaps I mis-understood again.
  
 That's a subtle change in behaviour indeed. It works as follows:
 If you select any invoice in the payment dialog it will only evaluate those 
 invoices for the 
 payment. If you want the payment dialog to evaluate all open invoices (i.e. 
 the old behaviour), 
 you should ensure no invoice is selected at all.

Aha but, the only way to have no invoices selected is to open the payment 
dialog via Business-Customer-Process Payment, when not currently in an 
invoice tab, then select a customer.  But now the OK button is inactive and 
there's a warning that says I must select at least on document or pre-payment 
to process.

Ah. I've just discovered that CTRL+L_Button toggles the selection.  The above 
still applies though, inactive OK.

 
 It's been a couple of months since I have written this code and I can't 
 remember exactly if I 
 tested all variations with outstanding pre-payments as well. I *believe* the 
 above should 
 count for pre-payments as well. If you want full automatic assignment don't 
 select any line in 
 the payment dialog, only enter an amount.
  
  Thanks for clearing up my confusion Geert.  I should open a bug (or
  two) for updating the manual and the mouseover texts so this doesn't
  get forgotten about.
  
 Please do, thank you.
 
 Geert
 



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


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

2014-03-18 Thread Mike Evans
On Mon, 17 Mar 2014 10:32:17 +
Mike Evans mi...@saxicola.idps.co.uk wrote:

 On Mon, 17 Mar 2014 11:26:30 +0100
 Felix Schwarz felix.schw...@oss.schwarz.eu wrote:
 
  
  Am 17.03.2014 11:21, schrieb Mike Evans:
   new_book_with_opening_balances.py works for me too on Fedora18 and SWIG 
   Version 2.0.8.
  
  Which version of gnucash are you using? If I'm not mistaken the F18 gnucash 
  is
  still 2.4, right?
  
 Compilied from sources, Git master
 
 Mike E
 

I take it back.  It was using the site-packages installed via yum, GnuCash 
2.4.13.  On removing the yum provided site-packages/gnucash dir and adding the 
correct path I get the same error as Felix Schwarz.  Sorry for the confusion, I 
forgot I still had the GnuCash rpm installed.

Mike E

-- 
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


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

2014-03-17 Thread Mike Evans
On Sun, 16 Mar 2014 13:41:42 -0700
David Osguthorpe david.osgutho...@gmail.com wrote:

 On Sun, Mar 16, 2014 at 08:54:10PM +0100, Felix Schwarz wrote:
  
  Am 16.03.2014 20:38, schrieb John Ralls:
   The signature of xaccAccountGetName is const char* xaccAccountGetName 
   (const Account *); the const was added in 2005. A const Account * is 
   not the same as an Account const *: The former means that the contents 
   of the pointer won't change, the latter means that the pointer itself 
   won't change (see https://www.cs.bu.edu/teaching/cpp/const/).
   
   Somewhere in the SWIG-generated Python-to-C translation code the argument 
   type is wrong, but it's not directly in the stack trace from Python. It's 
   more likely due to a change in SWIG than to a change in GnuCash.
  
  Thank you very much for the insights - seems really easy to miss. I'll take 
  a
  look at the SWIG files and the generated code then.
  
  But that means it would be interesting if gnucash's example script
works for anyone, right? If we had a
  success report this might provide some insight about the relevant swig 
  changes.
  
 
 not all the example scripts work - but this one does for me
 (the business ones have issues)
 
 also you need slightly different arguments now because of the xml/sqlite 
 possibility
 
 David

new_book_with_opening_balances.py works for me too on Fedora18 and SWIG Version 
2.0.8.

Mike E

-- 
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


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

2014-03-17 Thread Mike Evans
On Mon, 17 Mar 2014 11:26:30 +0100
Felix Schwarz felix.schw...@oss.schwarz.eu wrote:

 
 Am 17.03.2014 11:21, schrieb Mike Evans:
  new_book_with_opening_balances.py works for me too on Fedora18 and SWIG 
  Version 2.0.8.
 
 Which version of gnucash are you using? If I'm not mistaken the F18 gnucash is
 still 2.4, right?
 
Compilied from sources, Git master

Mike E

-- 
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: Poll: when to migrate code to the new server?

2014-01-21 Thread Mike Evans
On Tue, 21 Jan 2014 11:52:12 -0500
Derek Atkins warl...@mit.edu wrote:

 Hi,
 
 The new-code server is just about ready for migration.  I've got most of
 the services already installed and tested, (although some less vital
 services have not been fully tested yet).
 
 My main question is when to migrate?  One thing to keep in mind is that
 the new server will not support subversion (except in a read-only
 fashion so existing trac URLs will work).  This means that once we
 migrate the 2.4 series will be dead, unless we upgrade the build server
 to handle 2.4 from git.
 
 Migration will require downtime, probably a good 4 hours (or more) in
 order to make sure data isn't changing as the migration occurs.  I've
 pre-copied most of the data already so subsequent rsyncs should be
 faster.  But then I'll also need to test everything to make sure it's
 working, and I'll have to migrate/upgrade mediawiki by hand.
 
 So this is a long-winded way of asking when we think 2.4 will be
 completely done and when I should schedule the migration?  I know 2.6.1
 is planned for this weekend, so I'm assuming it'll be at least the
 following week, so maybe the weekend of Feb 1-2?
 
 -derek
 

Fine by me too.

Mike E

-- 
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: Documentation file format

2013-12-16 Thread Mike Evans
On Sun, 15 Dec 2013 14:58:21 -0500
Mike Alexander m...@umich.edu wrote:

 On Dec 15, 2013, at 8:13 AM, Geert Janssens janssens-ge...@telenet.be wrote:
  
  Or if we want to stick with docbook, I searched for docbook wysiwyg. Most 
  editors are 
  proprietary and pricey. But there is also serna-free [1], which claims to 
  be a near wysiwyg 
  editor that can handle docbook 4 (according to a nabble thread from last 
  year August [2]). I 
  haven't had time to experiment with it though.
 
 They certainly are expensive.  I used to be a developer on Arbortext's Epic 
 product, now marketed as PTC Arbortext Editor.  It would be a good tool for 
 this, but it is very expensive.  It's also essentially Windows only (there 
 used to be a Linux version, but I'm not sure it's still maintained).  Things 
 like that would perhaps be overkill for this anyway.  They are designed for 
 very complex documents, like an aircraft parts manual.  Because of this, they 
 assume a support staff that can help with setup and customization.
 
 There is a page at 
 http://www.firebirdsql.org/manual/docwritehowto-docbook-authoring-tools.html
  that lists a few cheap or free DocBook editors.  Also 
 http://www.happy-monkey.net/docbook/gui-editor.html claims there is a free 
 personal edition of  , but I can't find it.
 
 Mike
 
 

XMLMind's XXE can be found via: http://www.xlingpaper.org/?page_id=51

Mike E
-- 
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: Documentation file format

2013-12-13 Thread Mike Evans
On Fri, 13 Dec 2013 08:26:42 +0100
Christian Stimming christ...@cstimming.de wrote:

 I know I'm jumping in rather late in this thread, but here's my take  
 on the ever-long question of our documentation file formats:
 
 I think the priority of the documentation file format should be:
 - to generate HTML and PDF output from it
 - and to make it easy for documentation writers to edit the text
 
 As secondary goals, I think it is nice to be able to generate epub and  
 mobi output and also yelp's output from this (or does yelp read  
 docbook natively?!), but I think those are not as important.
 
 Given these priorities, I think both our current documentation file  
 format and also a potential wiki workflow might not be the best  
 solution. Instead of the current file format (docbook xml, split into  
 several files using xml entities) we should very well think to switch  
 to some other solution that makes the text much more accessible for  
 documentation writers. For example, if libreoffice/openoffice would be  
 able to use the docbook xml file, except for the fact that it's split  
 into multiple files using xml entities, then we should just as well  
 drop the split file approach and merge the full text into one single  
 docbook xml document.
 
 However, this wasn't the only problem with libreoffice, IIRC, but I'm  
 not sure. If we just don't fine any up-to-date word processor that can  
 work with the docbook xml, I would suggest to switch to a different  
 file format instead, such as ODF or similar, and just continue working  
 on the document with libreoffice et al.
 
 If a wiki approach is possible without too many extra steps in a  
 workflow, that's fine as well, but I'm afraid it adds a whole lot of  
 extra problems into the process. For example, what would be the  
 process to generate a new gnucash-docs release package so that gnucash  
 can be installed with at least as much offline available documentation  
 as we have today? If there are solutions for this, then fine, a wiki  
 based solution might be a good way to continue. Otherwise I'd suggest  
 to simply switch to a better file format.
 
 Regards,
 
 Christian
 
 ___

Since no-one has mentioned it yet, what about asciidoc?  It's much simpler that 
the xml we have now, is very easy to learn, it is plain text, it handles 
multi-part books, and AFAIK the current docbook can be converted to asciidoc 
without *too* much effort.

It's just a thought because I use it for pretty much all the documentation I 
write.  It's not WYSIWYG but it's a lot better than directly editing 
docbook.xml.  I guess LibreOffice can be used as long as it doesn't introduce 
artifacts into the plain text, although a plain text editor would be better, 
vi|emacs|geany perhaps.

Anyway, my 2p|2c

Mike E

-- 
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Backwards compatibility with new currency issue and bug 336843.

2013-11-10 Thread 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 gnc.io [valid_commodity()] Invalid commodity: 0 fraction
* 11:49:30  WARN gnc.io [gnc_commodity_end_handler()] Invalid commodity parsed
gnc:commodity version=2.0.0
  cmdty:spaceISO4217/cmdty:space
  cmdty:id/cmdty:id
  cmdty:slots
slot
  slot:keyuser_symbol/slot:key
  slot:value type=stringZK/slot:value
/slot
  /cmdty:slots
/gnc:commodity
* 11:49:31  WARN gnc.backend [gnc_xml_be_load_from_file()] Syntax error in 
Xml File /home/mikee/Projects/gnucash-tutorial/data/test.gnucash
* 11:49:31  CRIT GLib g_hash_table_foreach: assertion `version == 
hash_table-version' failed
* 11:49:31  CRIT GLib g_hash_table_foreach: assertion `version == 
hash_table-version' failed
* 11:49:31  CRIT GLib g_hash_table_foreach: assertion `version == 
hash_table-version' failed
* 11:49:31  CRIT GLib g_hash_table_foreach: assertion `version == 
hash_table-version' failed

It seemed clear this wasn't related to the patch so with a new test file, I 
first opened a new test file using trunk code, made a small change in a 
register (I added a space in a transaction description), saved the file and 
closed.  On reopening with 2.4.13 I see the above output.

The new ZMW currency was introduced in May with r22965, commit ab0cfdce5a.  
Reverting the commit fixes the problem, but obviously this is not a fix and 
the problem lies elsewhere.

I'll file a bug for this, I mention here only as information for anyone 
following the bug 336843 thread.

OS = Fedora 18.  My GnuCash-2.4.13 is from the Fedora repo. and it's build date 
is Wed 24 Apr 2013 20:51:06 BST.

Mike Evans.




-- 
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


FYI internet speed tests.

2013-10-23 Thread 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: FYI internet speed tests.

2013-10-23 Thread Mike Evans
On Wed, 23 Oct 2013 12:14:47 +0100
Mike Evans mi...@saxicola.idps.co.uk wrote:

 Speeds are in Kilobytes so x 8 for Kilobits
 
 
 2013-10-21 13:16:49 (388 KB/s)
 2013-10-21 13:35:38 (798 KB/s)
 2013-10-21 14:03:15 (783 KB/s)
 2013-10-21 16:03:16 (756 KB/s)
 2013-10-21 18:03:16 (790 KB/s)
 2013-10-21 20:03:40 (291 KB/s)
 2013-10-21 22:03:22 (536 KB/s)
 2013-10-22 00:03:16 (786 KB/s)
 2013-10-22 02:03:15 (797 KB/s)
 2013-10-22 04:03:15 (796 KB/s)
 2013-10-22 06:03:16 (797 KB/s)
 2013-10-22 08:03:16 (791 KB/s)
 2013-10-22 10:03:16 (798 KB/s)
 2013-10-22 12:03:15 (795 KB/s)
 2013-10-22 14:03:16 (795 KB/s)
 2013-10-22 16:03:15 (789 KB/s)
 2013-10-22 18:03:15 (792 KB/s)
 2013-10-22 20:03:20 (608 KB/s)
 2013-10-22 22:03:17 (730 KB/s)
 2013-10-23 00:03:16 (797 KB/s)
 2013-10-23 04:03:15 (798 KB/s)
 2013-10-23 06:03:16 (790 KB/s)
 2013-10-23 08:03:15 (798 KB/s)
 2013-10-23 10:03:16 (751 KB/s)
 2013-10-23 12:03:16 (792 KB/s)
 
 
 Slows down at about 8pm it seems.
 
 

Oops, wrong list!  Still, someone might be interested. :)

-- 
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: Latest 2.5 build crashes at start

2013-10-22 Thread Mike Evans
On Tue, 22 Oct 2013 09:56:52 +0200
Geert Janssens janssens-ge...@telenet.be wrote:

 On Monday 21 October 2013 10:53:06 Mike Evans wrote:
  The latest devel version crashes at start with:
  
  * 10:32:03  WARN gnc.scm *** GnuCash switched to a new preferences
  system *** * 10:32:03  WARN gnc.scm Attempt to migrate your
  preferences from the old to the new system * 10:32:03 OTHER
  GLib-GIO Settings schema 'org.gnucash.dialogs.import.ofx' is not
  installed Trace/breakpoint trap (core dumped)
  
  On Linux FC18.
  
  My config options are:
  
  OPTIONS=--enable-debug --with-html-engine=webkit --enable-python
  --enable-ofx  --enable-aqbanking
  
  Any thoughts?
  
  Mike E
 
 Mike,
 
 I have run into this a couple of times as well. There seems to be a bug 
 in the build macro for gsettings.xml files (which comes straight from 
 glib).
 
 I don't know the exact details, but in some circumstances the schema 
 files don't get compiled if there are already compiled schemas. So if 
 you have built gnucash without ofx support before and then reconfigure 
 to also build ofx support, the ofx schema won't be built.
 
 IIRC this can be worked around by removing the installation directory, 
 running a make clean in the build directory and then build/install 
 again.
 
 Note that the same can happen with the optional aqbanking support.
 
 If someone can pinpoint the exact cause and knows a fix that would of 
 course even be better.
 
 Geert

Thanks Geert and John

I started doing a bisect yesterday, but I was interrupted, then I broke 
something so it won't build at all. :(  


Now the build fails with:
swig-core-utils-python.c:3624:3: error: implicit declaration of function 
'gnc_gconf_get_path_prefix' [-Werror=implicit-function-declaration]
swig-core-utils-python.c: In function '_wrap_gnc_gconf_set_path_prefix':
swig-core-utils-python.c:3643:3: error: implicit declaration of function 
'gnc_gconf_set_path_prefix' [-Werror=implicit-function-declaration]

I'll get back to it today.


-- 
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: Latest 2.5 build crashes at start

2013-10-22 Thread Mike Evans
On Tue, 22 Oct 2013 12:01:52 +0200
Geert Janssens janssens-ge...@telenet.be wrote:

 On Tuesday 22 October 2013 10:39:12 Mike Evans wrote:
  On Tue, 22 Oct 2013 09:56:52 +0200
  
  Geert Janssens janssens-ge...@telenet.be wrote:
   On Monday 21 October 2013 10:53:06 Mike Evans wrote:
The latest devel version crashes at start with:

* 10:32:03  WARN gnc.scm *** GnuCash switched to a new
preferences
system *** * 10:32:03  WARN gnc.scm Attempt to migrate your
preferences from the old to the new system * 10:32:03 OTHER
GLib-GIO Settings schema 'org.gnucash.dialogs.import.ofx' is not
installed Trace/breakpoint trap (core dumped)

On Linux FC18.

My config options are:

OPTIONS=--enable-debug --with-html-engine=webkit --enable-python
--enable-ofx  --enable-aqbanking

Any thoughts?

Mike E
   
   Mike,
   
   I have run into this a couple of times as well. There seems to be a
   bug in the build macro for gsettings.xml files (which comes
   straight from glib).
   
   I don't know the exact details, but in some circumstances the schema
   files don't get compiled if there are already compiled schemas. So
   if
   you have built gnucash without ofx support before and then
   reconfigure to also build ofx support, the ofx schema won't be
   built.
   
   IIRC this can be worked around by removing the installation
   directory, running a make clean in the build directory and then
   build/install again.
   
   Note that the same can happen with the optional aqbanking support.
   
   If someone can pinpoint the exact cause and knows a fix that would
   of
   course even be better.
   
   Geert
  
  Thanks Geert and John
  
  I started doing a bisect yesterday, but I was interrupted, then I
  broke something so it won't build at all. :(
  
  
  Now the build fails with:
  swig-core-utils-python.c:3624:3: error: implicit declaration of
  function 'gnc_gconf_get_path_prefix'
  [-Werror=implicit-function-declaration] swig-core-utils-python.c: In
  function '_wrap_gnc_gconf_set_path_prefix':
  swig-core-utils-python.c:3643:3: error: implicit declaration of
  function 'gnc_gconf_set_path_prefix'
  [-Werror=implicit-function-declaration]
  
  I'll get back to it today.
 You can remove swig-core-utils-python.c from your build directory and 
 rebuild. This is an autogenerated file, which is only regenerated if 
 core-utils.i has changed.
 
 Unfortunately core-utils.i includes a number of (c-)header files (*.h). 
 If any of these files changes, this is not detected by our makefiles. 
 One occasion where this happens is r23253. The function 
 gnc_gconf_get_path_prefix is dropped from gnc_prefs.h in that commit. 
 gnc_prefs.h is included in core-utils.i, but swig-core-utils-python.c is 
 no regenerated automatically.
 
 Geert

Thanks Geert.  Compiling now after distclean and ./autogen ...



-- 
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Latest 2.5 build crashes at start

2013-10-21 Thread Mike Evans
The latest devel version crashes at start with:

* 10:32:03  WARN gnc.scm *** GnuCash switched to a new preferences system ***
* 10:32:03  WARN gnc.scm Attempt to migrate your preferences from the old to 
the new system
* 10:32:03 OTHER GLib-GIO Settings schema 'org.gnucash.dialogs.import.ofx' is 
not installed
Trace/breakpoint trap (core dumped)

On Linux FC18.  

My config options are:

OPTIONS=--enable-debug --with-html-engine=webkit --enable-python --enable-ofx  
--enable-aqbanking

Any thoughts?

Mike E

-- 
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: r23175 - gnucash/trunk/src/gnome - Fix bug 699450

2013-09-18 Thread Mike Evans
On Wed, 18 Sep 2013 11:56:37 +0200
Geert Janssens janssens-ge...@telenet.be wrote:

 On Wednesday 18 September 2013 05:40:45 Mike Evans wrote:
  Author: mikee
  Date: 2013-09-18 05:40:44 -0400 (Wed, 18 Sep 2013)
  New Revision: 23175
  Trac: http://svn.gnucash.org/trac/changeset/23175
  
  Modified:
 gnucash/trunk/src/gnome/gnc-budget-view.c
  Log:
  Fix bug 699450
  
  * Remove extra call to gtk_tree_view_append_column. (It is already
called in gnc_tree_view_account_add_custom_column.)
  
  Author: Robert Ratliff ratliff.bo...@gmail.com
  
  Modified: gnucash/trunk/src/gnome/gnc-budget-view.c
  
 ==
 =
  --- gnucash/trunk/src/gnome/gnc-budget-view.c   2013-09-17 23:26:10 UTC
  (rev 23174) +++ gnucash/trunk/src/gnome/gnc-budget-view.c   2013-09-18
  09:40:44 UTC (rev 23175) @@ -1007,6 +1007,7 @@
   GtkTreeViewColumn *col;
   GList *col_list;
   GList *totals_col_list;
  +ENTER(view %p, view);
  
   g_return_if_fail(view != NULL);
   priv = GNC_BUDGET_VIEW_GET_PRIVATE(view);
  @@ -1058,7 +1059,7 @@
   col = gbv_create_totals_column(view, num_periods_visible);
   if (col != NULL)
   {
  -gtk_tree_view_append_column(priv-totals_tree_view, col);
  +/*gtk_tree_view_append_column(priv-totals_tree_view,
  col);*/ totals_col_list = g_list_append(totals_col_list, col); }
  
 
 If they aren't needed, can you remove the line completely instead of just 
 commenting them out 
 ? That leaves us with both better functioning and easier to read code.
 
  @@ -1077,10 +1078,11 @@
   col = gbv_create_totals_column(view, -1);
   if (col != NULL)
   {
  -gtk_tree_view_append_column(priv-totals_tree_view, col);
  +/*gtk_tree_view_append_column(priv-totals_tree_view,
  col);*/ }
   }
 
 Same here.
 
 Geert
 ___


Hi Geert

Yep, I just applied the patch as is, I'll remove the comments.

Mike Evans


-- 
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: Problem loading file

2013-08-09 Thread Mike Evans
On Tue, 06 Aug 2013 10:29:35 -0400
Derek Atkins warl...@mit.edu wrote:

 Geert,
 
 Geert Janssens janssens-ge...@telenet.be writes:
 
  The function gnc:restore-report-by-guid-with-custom-template was added
  recently by me in the 2.5 series and is used to restore open
  reports. The function is written to the meta file in the
  .gnucash/books directory matching your gnucash book. This file is
  parsed when GnuCash opens your data file.
 
  So yes, if you had open reports when testing gnucash 2.5.2, this will
  result in a crash when trying to open the same book under the same
  user account with gnucash 2.4.x afterwards.
 
  My first reaction was to dismiss this as only a developer
  inconvenience, but that is not the only case this can happen. A user
  trying gnucash 2.6 but reverting back to 2.4 for whatever reason could
  run into this. So I should probably add some code to the 2.4.x series
  to at least not crash. Can you create a bug report for this so it
  doesn't get forgotten ? (I don't have time now to fix this
  immediately, sorry).
 
 Is there some way to have the code check whether the API exists and
 exit gracefully if it does not?  e.g.:
 
 guile (defined? 'gnc:restore-report-by-guid-with-custom-template)
 #f
 guile (defined? 'car)
 #t
 
 So you could only call the API if it's defined?  That way you wouldn't
 require changes to 2.4.
 
  Thank you,
 
  Geert
 
 -derek

I get the same problem and since I see no bug has been created for this, I'll 
create one myself.

Mike E
 
  On 04-08-13 15:53, Cristian Marchi wrote:
  Thanks, that could be the problem as under Ubuntu I occasionally
  open the file with 2.5 unstable version (without saving it) while on
  windoes I've only the stable version. I will try to use your
  suggested methed by finding the differences.
 
  Thanks for the tip
 
  Il 04/08/2013 13:48, Guilherme Salgado ha scritto:
  I seem to remember seeing something like this when I tried to open a
  file on GnuCash 2.4.12 after having opened it on 2.5.3 (trunk).
  Luckily I had a recent backup of my ~/.gnucash and after diffing the
  two it became obvious what lines I had to remove to stop 2.4.12 from
  crashing.
 
  The fact that you can open it on Windows is probably because your
  equivalent of ~/.gnucash there hasn't been tainted by GnuCash 2.5.3
 
  On 4 August 2013 05:08, Cristian Marchi cr...@libero.it wrote:
  I've a problem opening a file with GnuCash under Ubuntu
  12.10. This is the
  message I get when opening it from the terminal:
 
  Backtrace:
  In current input:
  1: 0* (let* ((options #)) (let* (#) (# option)) (let* (#) (#
  option))
  ...)
  1: 1  (gnc:restore-report-by-guid-with-custom-template 0 ...)
 
  unnamed port:1:897: In expression
  (gnc:restore-report-by-guid-with-custom-template 0
  b1f15b2052c149df93e698fe85a81ea6 ...):
  unnamed port:1:897: Unbound variable:
  gnc:restore-report-by-guid-with-custom-template
 
  I see the GnuCash splash screen and tip of the day, but then it exits.
 
  I can open it without problem in Windows XP. I also tried to copy all
  settings file from XP to Ubuntu but I get the same error message.
  I got it working by removing the all the ~/.gnucash folder.
 
  Any idea of what's going on?
  ___
  gnucash-devel mailing list
  gnucash-devel@gnucash.org
  https://lists.gnucash.org/mailman/listinfo/gnucash-devel
 
  ___
  gnucash-devel mailing list
  gnucash-devel@gnucash.org
  https://lists.gnucash.org/mailman/listinfo/gnucash-devel
 
  ___
  gnucash-devel mailing list
  gnucash-devel@gnucash.org
  https://lists.gnucash.org/mailman/listinfo/gnucash-devel
 
 
 



-- 
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: GnuCash releases ?

2013-03-29 Thread Mike Evans
On Fri, 29 Mar 2013 10:12:50 -0700
John Ralls jra...@ceridwen.us wrote:

 
 On Mar 28, 2013, at 11:30 PM, John Ralls jra...@ceridwen.us wrote:
 
  
  On Mar 27, 2013, at 5:34 PM, John Ralls jra...@ceridwen.us wrote:
  
  
  On Mar 27, 2013, at 1:07 PM, Christian Stimming christ...@cstimming.de 
  wrote:
  
  Am Mittwoch, 27. März 2013, 18:45:41 schrieb Geert Janssens:
  Two come to mind:
  
  2.4.12
  The previous release dates back to July 2012. Not that much has been 
  going
  on on stable, but there are a number of bugfixes waiting to be released. 
  I
  have read several suggestions from users that we're waiting too long to
  release them. I'd agree it's time to put out what we have.
  
  +1 from me on this. Let's do a 2.4.12 ASAP.
  
  2.5.0
  This was discussed before. The only remaining major items are
  gconf-gsettings and the register rewrite. I think I'll need too much 
  time
  to finish gsettings to delay 2.5.0 for it. I intend to get it ready for
  2.5.1 or 2.5.2. The register rewrite isn't done, but can already be used
  for testing and feedback purposes. So I would ask for a release somewhere
  in april.
  
  Thoughts ?
  
  +1 on that one, too. Let's get trunk get some wider audience.
  
  I agree on both as well. I'll do a make distcheck on both trunk and 2.4 
  tomorrow and report if there are any issues. If it looks good, we can 
  release at the weekend.
  
  
  I finally got both environments set up properly and got to make distcheck 
  -- and both failed. The first round of problems is that trunk has some 
  files that are in POTFILES.skip but are also distributed (that's after 
  fixing an oversight when I added the scheme files to POTfILES.skip). 2.4 
  fails configure (configure: error: Cannot find Glib Gettext.  Maybe you 
  need to install the gettext package?) when in built from the 
  tarball-created dist directory.
  
  It's way past bedtime now, so I'll have at it tomorrow.
 
 On the trunk build, the POTFILES complaints are about the source files to 
 build a couple of stand-alone programs, fini and financial. These are built 
 with a hand-rolled makefile in src/app-utils/calculation called 
 Makefile.calc. It's not part of the regular build. When calculation was a 
 separate module these sources were included as an EXTRA_DIST in the main 
 Makefile.am, but that was dropped when Christian moved them into app-utils.
 
 Has anyone *ever* used or even built them?
 
 Unless someone speaks up really soon, the two files that are part of the 
 library are moving up a level into app-utils and the rest of calculation is 
 going into the bit-bucket.
 
 Regards,
 John Ralls
 

Not me, never knew they existed.

Mike E
-- 
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

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


Re: GnuCash releases ?

2013-03-28 Thread Mike Evans
On Wed, 27 Mar 2013 17:34:53 -0700
John Ralls jra...@ceridwen.us wrote:

 
 On Mar 27, 2013, at 1:07 PM, Christian Stimming christ...@cstimming.de 
 wrote:
 
  Am Mittwoch, 27. März 2013, 18:45:41 schrieb Geert Janssens:
  Two come to mind:
  
  2.4.12
  The previous release dates back to July 2012. Not that much has been going
  on on stable, but there are a number of bugfixes waiting to be released. I
  have read several suggestions from users that we're waiting too long to
  release them. I'd agree it's time to put out what we have.
  
  +1 from me on this. Let's do a 2.4.12 ASAP.
  
  2.5.0
  This was discussed before. The only remaining major items are
  gconf-gsettings and the register rewrite. I think I'll need too much time
  to finish gsettings to delay 2.5.0 for it. I intend to get it ready for
  2.5.1 or 2.5.2. The register rewrite isn't done, but can already be used
  for testing and feedback purposes. So I would ask for a release somewhere
  in april.
  
  Thoughts ?
  
  +1 on that one, too. Let's get trunk get some wider audience.
 
 I agree on both as well. I'll do a make distcheck on both trunk and 2.4 
 tomorrow and report if there are any issues. If it looks good, we can release 
 at the weekend.
 
 Regards,
 John Ralls
 
 
+1 from me.  I've made some (useful?) minor fixes to 2.4 recently that should 
see daylight.  More testers on trunk are very much needed too.

Mike E 


-- 
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

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


Re: SVN-GIT link broken?

2013-03-24 Thread Mike Evans
On Sun, 24 Mar 2013 10:55:47 +
Mike Evans mi...@saxicola.idps.co.uk wrote:

 On Sun, 24 Mar 2013 00:52:25 -0400
 Mike Alexander m...@umich.edu wrote:
 
  Is the mechanism that pushes changes from SVN to GIT not working right? 
  I checked in a change nearly 5 hours ago which shows up in SVN (it's 
  r22832) but it hasn't appeared in the GIT repository yet.  I checked it 
  in using git svn dcommit as usual and everything looked normal.
  
  Mike
   
  ___
  gnucash-devel mailing list
  gnucash-devel@gnucash.org
  https://lists.gnucash.org/mailman/listinfo/gnucash-devel
 
 Yep, Got them both.
 

Ah.  Ignore the last one.  Replied to the wrong mail.  Ooops.  :)



-- 
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: CRLF issues on checkout (was Re: Gnucash 2.5/6 - jqplot)

2013-02-23 Thread Mike Evans
On Sat, 23 Feb 2013 10:19:25 +0100
Geert Janssens janssens-ge...@telenet.be wrote:

 Op 23-02-13 05:52, John Ralls schreef:
  On Feb 22, 2013, at 11:14 AM, Geert Janssens
  janssens-ge...@telenet.be wrote:
 
  Op 22-02-13 19:45, Geert Janssens schreef:
  Op 22-02-13 19:23, Mike Evans schreef:
  Thanks for checking Geert.  I removed my $HOME/.gitconfig and
  tried again with the same result.  My git version is 1.7.6.5 on
  Fedora 15 not sure it that makes any difference.  Anyway now we
  know where the problem is (me) I know the solution is local.
  Enough for today though I think.
  My git version is git-1.8.1.2-1.fc18.i686 on Fedora 18. I don't
  know if that makes a difference or not.
 
  What exact url are you using to clone from github ?
  Mine is g...@github.com:Gnucash/gnucash.git
 
  Any other devs seeing this ?
 
  Geert
  Additionally, can you check if the eol attribute is already
  supported in your git version ? It is mentioned in man
  gitattributes on my system and is the attribute I'm using to
  force consistent line endings. It may be a more recent addition.
 
  Yeah, I see it on OSX.  When I follow the renormalizing
  procedure, I get warning: CRLF will be replaced by LF in
  src/report/jqplot/foo.js. The file will have its original line
  endings in your working directory. For all of the files that Mike
  listed. Curiously, changing the *.js entry in .gitattributes to
  crlf and repeating the procedure has no effect. It appears that you
  got those js files into the repo with crlf line endings.
 
  git version 1.7.9.6 (Apple Git-31.1)
  The eol attribute is documented in gitattributes(5)
 
  Regards,
  John Ralls
 
 Ok, that is very likely. Can you or Mike check in the proper
 conversions ? They don't show up on my system (which I don't
 understand why that is).
 
 Geert

OK checked in as r22808 4317a28b55655

Mike E

-- 
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: Gnucash 2.5/6 - jqplot

2013-02-22 Thread Mike Evans
On Thu, 21 Feb 2013 18:55:31 +0100
Geert Janssens janssens-ge...@telenet.be wrote:

 Op 21-02-13 18:19, Mike Evans schreef:
  On Thu, 21 Feb 2013 18:04:37 +0100
  Geert Janssens janssens-ge...@telenet.be wrote:
 
  Op 21-02-13 16:54, Mike Evans schreef:
  A git|svn|brain issue follows.
 
  Having updated to the latest source using git-update script I
  can't change branches because some of the files have the wrong
  line endings, unless I commit the changes.
  I get this message:
  Please, commit your changes or stash them before you can switch
  branches.
 
  Git stash doesn't work and I get similar output to that shown
  below.
 
  A git diff gives the following output.
 
  warning: CRLF will be replaced by LF in
  src/report/jqplot/excanvas.min.js. The file will have its original
  line endings in your working directory. warning: CRLF will be
  replaced by LF in src/report/jqplot/jquery.jqplot.min.js. The file
  will have its original line endings in your working directory.
  SNIP
  src/report/jqplot/plugins/jqplot.ciParser.min.js. The file will
  have its original line endings in your working directory. diff
  --git src/report/jqplot/excanvas.min.js
  src/report/jqplot/excanvas.min.js index 83373a5..e699a26 100644
  --- src/report/jqplot/excanvas.min.js +++
  src/report/jqplot/excanvas.min.js @@ -1,3 +1,3 @@ -/* jqPlot
  @VERSION | (c) 2009-2013 Chris Leonello | jplot.com
  -   jsDate | (c) 2010-2013 Chris Leonello
  +/* jqPlot @VERSION | (c) 2009-2013 Chris Leonello | jplot.com
  +   jsDate | (c) 2010-2013 Chris Leonello
 
 
  Um.  Not sure what to do or why this situation occurred in the
  first place. I thought git took care of line ending translations.
  
  I can commmit locally then dcommit but is that going to screw it
  up for anyone else?
 
  Advice needed.  My love/hate relationship with GIT continues.
 
 
  Mike Evans
 
  Mike,
 
  These happen because the git configuration didn't have a definition
  for the line ending style for javascript files (.js). While working
  on the charts I added this definition. Some files that were already
  in git before now are checked out with different line endings.
 
  Can you try to run
  git checkout src/report/jqplot/*.js
  git checkout src/report/jqplot/plugins/*.js
 
  Does that fix the issue ?
 
  Geert
  Hi Geert
 
  Afraid not.  Can I modify my config file manually?  What do I
  add|change if so?
 
  Mike E
 It looks like the solution needs slightly more work. Read the part 
 Re-normalizing a repo on this page:
 
 https://help.github.com/articles/dealing-with-line-endings
 
 Be sure to commit or stash your real changes before following this 
 procedure. If at the end there are still files complaining about CRLF
 vs LF, you commit those. That would mean I have messed up in my
 commit.
 
 Geert

Hi Geert

After doing that and making things somewhat worse, that is, getting even
more files with line ending issues I git cloned a fresh copy of gnucash from 
GitHub.

A git status gives me:

# On branch trunk
# Changes not staged for commit:
#   (use git add file... to update what will be committed)
#   (use git checkout -- file... to discard changes in working directory)
#
#   modified:   src/report/jqplot/excanvas.min.js
#   modified:   src/report/jqplot/jquery.jqplot.min.js
#   modified:   src/report/jqplot/plugins/jqplot.BezierCurveRenderer.min.js
#   modified:   src/report/jqplot/plugins/jqplot.barRenderer.min.js
#   modified:   src/report/jqplot/plugins/jqplot.blockRenderer.min.js
#   modified:   src/report/jqplot/plugins/jqplot.bubbleRenderer.min.js
#   modified:   
src/report/jqplot/plugins/jqplot.canvasAxisLabelRenderer.min.js
#   modified:   
src/report/jqplot/plugins/jqplot.canvasAxisTickRenderer.min.js
#   modified:   src/report/jqplot/plugins/jqplot.canvasOverlay.min.js
#   modified:   src/report/jqplot/plugins/jqplot.canvasTextRenderer.min.js
#   modified:   src/report/jqplot/plugins/jqplot.categoryAxisRenderer.min.js
#   modified:   src/report/jqplot/plugins/jqplot.ciParser.min.js
#

Same files with line ending issues, but at least no warnings.  It can't be just 
me surely?  
Although sometimes it seems to be :)

Mike Evans

-- 
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: Gnucash 2.5/6 - jqplot

2013-02-22 Thread Mike Evans
On Fri, 22 Feb 2013 18:47:48 +0100
Geert Janssens janssens-ge...@telenet.be wrote:

 Op 22-02-13 14:43, Mike Evans schreef:
  On Thu, 21 Feb 2013 18:55:31 +0100
  Geert Janssens janssens-ge...@telenet.be wrote:
 
  Op 21-02-13 18:19, Mike Evans schreef:
  On Thu, 21 Feb 2013 18:04:37 +0100
  Geert Janssens janssens-ge...@telenet.be wrote:
 
  Op 21-02-13 16:54, Mike Evans schreef:
  A git|svn|brain issue follows.
 
  Having updated to the latest source using git-update script I
  can't change branches because some of the files have the wrong
  line endings, unless I commit the changes.
  I get this message:
  Please, commit your changes or stash them before you can switch
  branches.
 
  Git stash doesn't work and I get similar output to that shown
  below.
 
  A git diff gives the following output.
 
  warning: CRLF will be replaced by LF in
  src/report/jqplot/excanvas.min.js. The file will have its
  original line endings in your working directory. warning: CRLF
  will be replaced by LF in
  src/report/jqplot/jquery.jqplot.min.js. The file will have its
  original line endings in your working directory.
  SNIP
  src/report/jqplot/plugins/jqplot.ciParser.min.js. The file will
  have its original line endings in your working directory. diff
  --git src/report/jqplot/excanvas.min.js
  src/report/jqplot/excanvas.min.js index 83373a5..e699a26 100644
  --- src/report/jqplot/excanvas.min.js +++
  src/report/jqplot/excanvas.min.js @@ -1,3 +1,3 @@ -/* jqPlot
  @VERSION | (c) 2009-2013 Chris Leonello | jplot.com
  -   jsDate | (c) 2010-2013 Chris Leonello
  +/* jqPlot @VERSION | (c) 2009-2013 Chris Leonello | jplot.com
  +   jsDate | (c) 2010-2013 Chris Leonello
 
 
  Um.  Not sure what to do or why this situation occurred in the
  first place. I thought git took care of line ending
  translations. 
  I can commmit locally then dcommit but is that going to screw it
  up for anyone else?
 
  Advice needed.  My love/hate relationship with GIT continues.
 
 
  Mike Evans
 
  Mike,
 
  These happen because the git configuration didn't have a
  definition for the line ending style for javascript files (.js).
  While working on the charts I added this definition. Some files
  that were already in git before now are checked out with
  different line endings.
 
  Can you try to run
  git checkout src/report/jqplot/*.js
  git checkout src/report/jqplot/plugins/*.js
 
  Does that fix the issue ?
 
  Geert
  Hi Geert
 
  Afraid not.  Can I modify my config file manually?  What do I
  add|change if so?
 
  Mike E
  It looks like the solution needs slightly more work. Read the part
  Re-normalizing a repo on this page:
 
  https://help.github.com/articles/dealing-with-line-endings
 
  Be sure to commit or stash your real changes before following this
  procedure. If at the end there are still files complaining about
  CRLF vs LF, you commit those. That would mean I have messed up in
  my commit.
 
  Geert
  Hi Geert
 
  After doing that and making things somewhat worse, that is, getting
  even more files with line ending issues I git cloned a fresh copy
  of gnucash from GitHub.
 
  A git status gives me:
 
  # On branch trunk
  # Changes not staged for commit:
  #   (use git add file... to update what will be committed)
  #   (use git checkout -- file... to discard changes in working
  directory) #
  #   modified:   src/report/jqplot/excanvas.min.js
  #   modified:   src/report/jqplot/jquery.jqplot.min.js
  #   modified:
  src/report/jqplot/plugins/jqplot.BezierCurveRenderer.min.js #
  modified:   src/report/jqplot/plugins/jqplot.barRenderer.min.js
  #   modified:
  src/report/jqplot/plugins/jqplot.blockRenderer.min.js #
  modified:   src/report/jqplot/plugins/jqplot.bubbleRenderer.min.js
  #   modified:
  src/report/jqplot/plugins/jqplot.canvasAxisLabelRenderer.min.js
  #   modified:
  src/report/jqplot/plugins/jqplot.canvasAxisTickRenderer.min.js
  #   modified:
  src/report/jqplot/plugins/jqplot.canvasOverlay.min.js #
  modified:
  src/report/jqplot/plugins/jqplot.canvasTextRenderer.min.js #
  modified:
  src/report/jqplot/plugins/jqplot.categoryAxisRenderer.min.js
  #   modified:
  src/report/jqplot/plugins/jqplot.ciParser.min.js #
 
  Same files with line ending issues, but at least no warnings.  It
  can't be just me surely? Although sometimes it seems to be :)
 
  Mike Evans
 
 Just to test I did the same: cloned a fresh copy from GitHub and it 
 doesn't show any modified files. We seem to have a mystery here...
 
 Let's try to find what is different between your and my setup.
 
 The only difference I can imagine to cause this would be if you have 
 configured line ending preferences locally. Is there some config 
 parameter related to line endings in your $HOME/.gitconfig file (like 
 autocrlf) ? I don't have anything in there.
 
 Geert

Thanks for checking Geert.  I removed my $HOME/.gitconfig and tried
again with the same result.  My git version is 1.7.6.5 on Fedora 15 not
sure

Re: Bugzilla default/QA assignees

2013-02-21 Thread Mike Evans
On Mon, 18 Feb 2013 20:05:31 -0800
John Ralls jra...@ceridwen.us wrote:

 
 On Feb 18, 2013, at 5:43 PM, Chris Shoemaker c.shoema...@cox.net
 wrote:
 
  +1 ;)
 
 Well, well. Don't you get stiff lurking behind that fern?  ;-)
 
 Regards,
 John Ralls
 
 [1]
 https://bugzilla.gnome.org/buglist.cgi?query_format=advanced;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;bug_status=NEEDINFO;component=Budgets;product=GnuCash
 
  
  On Mon, Feb 18, 2013 at 05:09:20PM -0800, John Ralls wrote:
  The default assignee field is mostly used to determine who gets
  bugmail for a particular component. Some of the assignments make
  sense, like having me be the default for Mac bugs, some not so
  much, like Chris Shoemaker for budget bugs: He hasn't been around
  for a long time.
  
  It also makes it hard for non-bugzilla-admins to set themselves up
  for bugmail on new bugs, because the mechanism for doing so is to
  watch another user. Watching a real user means that you get bug
  mail not only for the bugs that that user is the default
  assignee,QA contact, or added to the CC list, but also for every
  bug that user comments on. Not really useful unless you're a
  stalker.
  
  The mainstream Gnome approach is to have fake users for default
  assignees; for example, the Gtk Quartz backend has
  gtk-quartz-ma...@gnome.bugs, which I watch so that I get bug mail
  for any of those. I propose doing the same for our gnucash
  components, with a per-component address for default assignee and
  a gnucash-bugs address for QA assignee to make it easy to get all
  bugmail.
  
  I'll change the components, but I can't create the users because I
  don't have privs for doing that.
  
  Regards,
  John Ralls
  
  
  ___
  gnucash-devel mailing list
  gnucash-devel@gnucash.org
  https://lists.gnucash.org/mailman/listinfo/gnucash-devel
 
 
 ___
 gnucash-devel mailing list
 gnucash-devel@gnucash.org
 https://lists.gnucash.org/mailman/listinfo/gnucash-devel

I see a new bug (Bug 693948) assigned to Mark Jenkins and as QA contact.
I don't think Mark is actively developing anymore(?).  Having assignee
and QA as the same person probably isn't a good idea either.

Mike Evans 

-- 
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: Gnucash 2.5/6 - jqplot

2013-02-21 Thread Mike Evans
On Thu, 21 Feb 2013 12:47:18 +0100
Geert Janssens janssens-ge...@telenet.be wrote:

 Op 12-02-13 18:46, Geert Janssens schreef:
  There was another feature that briefly appeared on the trunk
  branch: dynamic graphical reports with jqplot. I wonder whatever
  happened with it.
 
  The base for jqplot is in the code repo, and I also remember having 
  seen some example reports using it. I can't find those anymore
  though.
 
  I wonder if the original author was unsure to invest further in it 
  because his jqplot work triggered a long discussion on where to go 
  with the current report system. Lots of possibilities were offered, 
  but in the end we're still using the report system basically 
  unchanged. Since there's still no clear plan for the report system
  on the horizon, I would love to see jqplot being used for our
  graphical reports.
 
  If the original author is still around, I'd love to hear from him
  (her?).
 
  Other than that, anyone interested in looking into what's needed to 
  convert a report to jqplot ?
 
  Geert
  ___
  gnucash-devel mailing list
  gnucash-devel@gnucash.org
  https://lists.gnucash.org/mailman/listinfo/gnucash-devel
 
 Well, it turns out I was too curious myself already, so I checked a
 bit further.
 
 I found the original mailinglist thread [1] and the missing patch to 
 enable the jqplot alternatives for most of our chart types. Due to
 the age of the patch there were a few issues, but with some tweaking
 I managed to get it to work again. I like the result so much better
 than the old goffice based charts that I have chosen to remove the
 goffice based ones.
 
 The old list thread also pointed at some issues with the jqplot
 charts. I think I have fixed most of them, except the labels running
 over one another if there are lots of data points. If any other
 issues pop up, please let me know.
 
 And a random list of things that should/could be done still:
 - remove the gog code (should)
 - labels running over one another if there are many data points
 - dynamic sizing as an alternative option to the fixed width/height
 we now have to specify
 - some more code optimizations, like
* linking to minimized versions of the js files
* drop some unused/invalid chart options (in js code that is)
 - add/improve interaction to the charts
 
 Most of these are minor tweaks. Even as they are now, the jquery
 based charts are ready for feature freeze, IMO.
 
 Geert
 
 
 [1]
 https://lists.gnucash.org/pipermail/gnucash-devel/2011-March/031322.html
 ___ gnucash-devel mailing
 list gnucash-devel@gnucash.org
 https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Lovely charts Geert.  Two of the features I added in the Net Worth line
chart are obsoleted/broken.  Optional grid and optional data markers no
longer work as advertised so I'll have to look at them or remove
them.  Not really sure if either are necessary anyway. 

All the charts could possibly use an alternate black and white
stylesheet for printing, is this easier to achieve using jqplot?  This
is not new because of jqplot though.

Mike Evans



-- 
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: Bugzilla default/QA assignees

2013-02-21 Thread Mike Evans
On Thu, 21 Feb 2013 10:07:02 -0500
Derek Atkins warl...@mit.edu wrote:

 Mike Evans mi...@saxicola.idps.co.uk writes:
 
  I see a new bug (Bug 693948) assigned to Mark Jenkins and as QA
  contact. I don't think Mark is actively developing anymore(?).
  Having assignee and QA as the same person probably isn't a good
  idea either.
 
 I don't even know who Mark Jenkins is!  He's certainly not a GnuCash
 committer.
 
  Mike Evans 
 
 -derek
 

I think he's this guy on this page.
http://www.parit.ca/about-parit/

Did a lot of work on the python bindings I believe.
commit 4fa2e8796 etc.


-- 
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: Gnucash 2.5/6 - jqplot

2013-02-21 Thread Mike Evans
On Thu, 21 Feb 2013 14:18:38 +
Mike Evans mi...@saxicola.idps.co.uk wrote:

 On Thu, 21 Feb 2013 12:47:18 +0100
 Geert Janssens janssens-ge...@telenet.be wrote:
 
  Op 12-02-13 18:46, Geert Janssens schreef:
   There was another feature that briefly appeared on the trunk
   branch: dynamic graphical reports with jqplot. I wonder whatever
   happened with it.
  
   The base for jqplot is in the code repo, and I also remember
   having seen some example reports using it. I can't find those
   anymore though.
  
   I wonder if the original author was unsure to invest further in
   it because his jqplot work triggered a long discussion on where
   to go with the current report system. Lots of possibilities were
   offered, but in the end we're still using the report system
   basically unchanged. Since there's still no clear plan for the
   report system on the horizon, I would love to see jqplot being
   used for our graphical reports.
  
   If the original author is still around, I'd love to hear from him
   (her?).
  
   Other than that, anyone interested in looking into what's needed
   to convert a report to jqplot ?
  
   Geert
   ___
   gnucash-devel mailing list
   gnucash-devel@gnucash.org
   https://lists.gnucash.org/mailman/listinfo/gnucash-devel
  
  Well, it turns out I was too curious myself already, so I checked a
  bit further.
  
  I found the original mailinglist thread [1] and the missing patch
  to enable the jqplot alternatives for most of our chart types. Due
  to the age of the patch there were a few issues, but with some
  tweaking I managed to get it to work again. I like the result so
  much better than the old goffice based charts that I have chosen to
  remove the goffice based ones.
  
  The old list thread also pointed at some issues with the jqplot
  charts. I think I have fixed most of them, except the labels running
  over one another if there are lots of data points. If any other
  issues pop up, please let me know.
  
  And a random list of things that should/could be done still:
  - remove the gog code (should)
  - labels running over one another if there are many data points
  - dynamic sizing as an alternative option to the fixed width/height
  we now have to specify
  - some more code optimizations, like
 * linking to minimized versions of the js files
 * drop some unused/invalid chart options (in js code that is)
  - add/improve interaction to the charts
  
  Most of these are minor tweaks. Even as they are now, the jquery
  based charts are ready for feature freeze, IMO.
  
  Geert
  
  
  [1]
  https://lists.gnucash.org/pipermail/gnucash-devel/2011-March/031322.html
  ___ gnucash-devel
  mailing list gnucash-devel@gnucash.org
  https://lists.gnucash.org/mailman/listinfo/gnucash-devel
 
 Lovely charts Geert.  Two of the features I added in the Net Worth
 line chart are obsoleted/broken.  Optional grid and optional data
 markers no longer work as advertised so I'll have to look at them or
 remove them.  Not really sure if either are necessary anyway. 
 
 All the charts could possibly use an alternate black and white
 stylesheet for printing, is this easier to achieve using jqplot?  This
 is not new because of jqplot though.
 
 Mike Evans
 
 
 

A git|svn|brain issue follows.

Having updated to the latest source using git-update script I can't
change branches because some of the files have the wrong line endings,
unless I commit the changes. 
I get this message: 
Please, commit your changes or stash them before you can switch
branches. 

Git stash doesn't work and I get similar output to that shown below.  

A git diff gives the following output.

warning: CRLF will be replaced by LF in src/report/jqplot/excanvas.min.js.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in src/report/jqplot/jquery.jqplot.min.js.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in 
src/report/jqplot/plugins/jqplot.BezierCurveRenderer.min.js.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in 
src/report/jqplot/plugins/jqplot.barRenderer.min.js.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in 
src/report/jqplot/plugins/jqplot.blockRenderer.min.js.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in 
src/report/jqplot/plugins/jqplot.bubbleRenderer.min.js.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in 
src/report/jqplot/plugins/jqplot.canvasAxisLabelRenderer.min.js.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in 
src/report/jqplot/plugins/jqplot.canvasOverlay.min.js

Re: Gnucash 2.5/6 - jqplot

2013-02-21 Thread Mike Evans
On Thu, 21 Feb 2013 18:04:37 +0100
Geert Janssens janssens-ge...@telenet.be wrote:

 Op 21-02-13 16:54, Mike Evans schreef:
  A git|svn|brain issue follows.
 
  Having updated to the latest source using git-update script I can't
  change branches because some of the files have the wrong line
  endings, unless I commit the changes.
  I get this message:
  Please, commit your changes or stash them before you can switch
  branches.
 
  Git stash doesn't work and I get similar output to that shown below.
 
  A git diff gives the following output.
 
  warning: CRLF will be replaced by LF in
  src/report/jqplot/excanvas.min.js. The file will have its original
  line endings in your working directory. warning: CRLF will be
  replaced by LF in src/report/jqplot/jquery.jqplot.min.js. The file
  will have its original line endings in your working directory.
SNIP
  src/report/jqplot/plugins/jqplot.ciParser.min.js. The file will
  have its original line endings in your working directory. diff
  --git src/report/jqplot/excanvas.min.js
  src/report/jqplot/excanvas.min.js index 83373a5..e699a26 100644 ---
  src/report/jqplot/excanvas.min.js +++
  src/report/jqplot/excanvas.min.js @@ -1,3 +1,3 @@ -/* jqPlot
  @VERSION | (c) 2009-2013 Chris Leonello | jplot.com
  -   jsDate | (c) 2010-2013 Chris Leonello
  +/* jqPlot @VERSION | (c) 2009-2013 Chris Leonello | jplot.com
  +   jsDate | (c) 2010-2013 Chris Leonello
 
 
  Um.  Not sure what to do or why this situation occurred in the
  first place. I thought git took care of line ending translations.
 
  I can commmit locally then dcommit but is that going to screw it up
  for anyone else?
 
  Advice needed.  My love/hate relationship with GIT continues.
 
 
  Mike Evans
 
 Mike,
 
 These happen because the git configuration didn't have a definition
 for the line ending style for javascript files (.js). While working
 on the charts I added this definition. Some files that were already
 in git before now are checked out with different line endings.
 
 Can you try to run
 git checkout src/report/jqplot/*.js
 git checkout src/report/jqplot/plugins/*.js
 
 Does that fix the issue ?
 
 Geert

Hi Geert

Afraid not.  Can I modify my config file manually?  What do I add|change
if so?

Mike E





-- 
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: Gnucash 2.5/6 - jqplot

2013-02-21 Thread Mike Evans
On Thu, 21 Feb 2013 18:16:53 +0100
Geert Janssens janssens-ge...@telenet.be wrote:

 Op 21-02-13 15:18, Mike Evans schreef:
  Lovely charts Geert.  Two of the features I added in the Net Worth
  line chart are obsoleted/broken.  Optional grid and optional data
  markers no longer work as advertised so I'll have to look at them
  or remove them.  Not really sure if either are necessary anyway.
 Thanks, most of the credit goes to Andy Clayton though, who did most
 of the work. I mostly tuned and updated it.
 
 About the options, that got dropped, I didn't notice them, sorry. It 
 shouldn't be too hard to add them again. I'll fix it in a next round.
  All the charts could possibly use an alternate black and white
  stylesheet for printing, is this easier to achieve using jqplot?
  This is not new because of jqplot though.
 It depends, but I don't think I understand exactly what you would
 like to achieve here. Can you elaborate a bit ?
 
 Geert

Charts don't print very well on a BW laser. They didn't before to be
fair. For BW the lines, text, borders etc., need to be black
(obviously) with a different line style (dash type) for each data line.
Basically a user should be able to toggle between BW and colour in the
chart preferences.  Just curious as to how hard this would be to
implement.

I don't know how many people would need this, so it probably isn't a
high priority anyway.

Mike Evans


-- 
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: Gnucash 2.5/6

2013-02-18 Thread Mike Evans
On Sun, 17 Feb 2013 13:55:40 -0800 (PST)
Phil Longstaff phil.longst...@yahoo.ca wrote:

 I created https://bugzilla.gnome.org/show_bug.cgi?id=694047 and
 attached an initial patch to that.  That should allow you to get it
 in.  I'll need to learn more about git.
 
 Phil
 
 
 
  From: John Ralls jra...@ceridwen.us
 To: Robert Fewell 14ubo...@gmail.com; Geert Janssens
 janssens-ge...@telenet.be Cc: gnucash-devel@gnucash.org Devel
 gnucash-devel@gnucash.org Sent: Tuesday, February 12, 2013 2:22:39
 PM Subject: Re: Gnucash 2.5/6
  
 
 On Feb 9, 2013, at 1:45 PM, lsl 14ubo...@gmail.com wrote:
 
  I am still plodding on with this and it is progressing slowly, have
  uploaded another patch to the bug which also indicates roughly what
  is left to do. I am not sure of any time scales but the menu
  options can be disabled or the whole lot can be removed if it is
  holding other things up.
  
  Assuming it is still viable, I will continue and progress it as time
  permits.
 
 Is this mostly working? If so, let's get it into trunk and ditch the
 old register. That will at least let us get rid of the project Ridley
 deprecated libraries. It will also get more people banging on it,
 which will bring any problems to light.
 
 Pending that and Phil's budgeting, I'm thinking we can release 2.5.0
 next week.
 
 Regards,
 John Ralls
 
 

I just tested Robert Fewell's patch in Bug 673193 and I realised it
makes my reverse sort (Bug 683881, commit 679d59e44) work obsolete as
sorting order can be changed by simply clicking in the column header.
If the TreeView is going to become the standard then think I should
remove my commit and mark the bug as obsolete. 

Thoughts?

Mike Evans


-- 
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

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


Re: Gnucash 2.5/6

2013-02-08 Thread Mike Evans
On Fri, 08 Feb 2013 10:13:01 +0100
Geert Janssens janssens-ge...@telenet.be wrote:

 On 07-02-13 19:32, John Ralls wrote:
  Geert mentioned in the Notification Emails thread that he'd like to
  get 2.6 released in less than a year, and Christian was pushing to
  do so this time *last* year. On the principle that Release is a
  misnomer. Software is never released, it escapes. [1], it's
  probably time to release 2.5.0 so that we can at least start down
  that road. Shall we say feature freeze now, string freeze in July,
  2.6 release 1 November?
 
  Or is anyone actively working on features that should go in? What
  became of the rewrite of the register to GtkTreeView? Failing that,
  has anyone taken a shot at rewriting it with Cairo instead of
  libgnome? Note that I'm not proposing a Gtk3 migration for 2.6:
  We're doing that at Gramps, and MSWin is proving to be troublesome.
  In fact, it appears that no one is supporting Gtk3-MSWin at the
  moment.
 
  Regards,
  John Ralls
 
  [1] I don't know where that originated. My wife brought it with her
  from DEC, where it was apparently a truism.
  ___ gnucash-devel
  mailing list gnucash-devel@gnucash.org
  https://lists.gnucash.org/mailman/listinfo/gnucash-devel
 I like to see a 2.5.0 fairly soon as well. All features I had planned 
 are basically done. They still need a bit of polishing, but are fully 
 functional.
 
 The GtkTreeView based register currently has basic functionality, but
 I haven't seen additional improvements in a while. To be honest, I
 haven't gotten around to test it more thoroughly. Perhaps Robert
 Fewell can chime in here.
 
 I also recently pinged Phil on switching to GSettings. He said he was 
 going to take that up. I have no additional details, though it would 
 make a nice addition for 2.6 as it would allow us to drop gconf on 
 Windows and OS X. If we want this for 2.6, it will probably need to
 be a minor first implementation, of the
 replace-the-current-gconf-code-as-is kind. Not a complete overhaul of
 our preferences system. I have no idea what plans Phil has exactly,
 so I'll leave it up to him to give more details of what he's up to
 and if he considers it realistic to have something for 2.5/2.6.
 
 Last item is on our Feature Schedule [1]: Reversed sort order by
 date for transaction, a feature Mike Evans has been working on. As
 far as I can see it's mostly done. I reviewed his patch and gave my
 feedback. I don't know what kept Mike from completing it. Even as is,
 the patch is usable and useful already.

Re ^: This currently doesn't save the reverse sort setting between runs,
and I really didn't like the empty_split being at the bottom when
reverse sorting.  It is functional for people wanting to compare their
on-screen, reverse-sorted bank accounts though.  I just ran out of
time, enthusiasm, money... I'll commit it as is but subsequent commits
mean that the patch is obsolete and I'll have to revisit the code again.

I also marked Bug 682732 as a blocker because it simply doesn't work
for me. I think we either revert to the old CSV importer or fix the new
version.  Perhaps others could test it and update the bug.

Mike Evans


 
 Let's hear what the others have to say.
 
 Geert
 
 [1] 
 http://wiki.gnucash.org/wiki/Release_Schedule#Feature_Checklist_for_2.6.0
 ___
 gnucash-devel mailing list
 gnucash-devel@gnucash.org
 https://lists.gnucash.org/mailman/listinfo/gnucash-devel



-- 
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: Github Migration

2013-02-03 Thread Mike Evans
On Fri, 1 Feb 2013 21:48:33 -0800
John Ralls jra...@ceridwen.us wrote:

 
 On Feb 1, 2013, at 9:38 PM, John Ralls jra...@ceridwen.us wrote:
 
  
  On Feb 1, 2013, at 8:57 PM, Mike Alexander m...@umich.edu wrote:
  
  If not I get a bunch of unresolvable references on this step after
  which none of the transfer/xxx branches exist.
  Really? That's interesting. I'm testing that avenue now.
 
 Nope, I get the same  result either way. New remote branches, new
 remote tags. Everything's fine.
 
 Regards,
 John Ralls
 
 
 
 ___
Migration fails for me.

Cloned the new git repo. just fine but then I'm asked multiple times for
my ssh password when doing git svn init ..., until I got locked out.

I'll ask Derek for an unlock when he's online then try again.
Any thoughts?

Mike Evans

-- 
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: Github Migration

2013-02-03 Thread Mike Evans
On Sun, 3 Feb 2013 09:15:41 -0500
Derek Atkins de...@ihtfp.com wrote:

 
 On Sun, February 3, 2013 8:11 am, Mike Evans wrote:
 
  Migration fails for me.
 
  Cloned the new git repo. just fine but then I'm asked multiple
  times for my ssh password when doing git svn init ..., until I
  got locked out.
 
 If you're asked for your password then things are wrong.  Code will
 never accept a password, so if it asks you might as well quit out.
 If you quit then you might not get locked out.
 
 But this implies your ssh key isn't around.  Can you just do a normal
 svn svn+ssh:// command from the same account?
 
  I'll ask Derek for an unlock when he's online then try again.
  Any thoughts?
 
 Check your SVN URL and SSH config locally?  Although if you were able
 to get a git checkout from code then you SHOULD be able to use SVN --
 the keys should be the same set.
 
  Mike Evans
 
 -derek
 

Thanks Derek

Just calling the same command after unlocking worked fine.  I didn't do
anything else to make it work.  Now to move all my branches.

Mike Evans

-- 
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: Git migration - github vs code.gnucash.org

2012-11-01 Thread Mike Evans
On Wed, 31 Oct 2012 19:26:05 -0700
John Ralls jra...@ceridwen.us wrote:

 
 On Oct 31, 2012, at 7:33 AM, Geert Janssens
 janssens-ge...@telenet.be wrote:
 
  This discussion has been had multiple times before and frankly I
  hope this will be the last time.
  
  The previous discussion didn't end in an explicit consensus, but I
  think we were close to finding a compromise at least. A summary:
  
  - Nobody opposed to using github. In fact most developers are in
  favour of using it.
  - John indicated that github is good, but we shouldn't use the
  github issue tracker or pull requests. They appear to be a source
  of trouble.
  - Mostly Derek insists on having a canonical repository on
  code.gnucash.org as well. Others haven't explicitly agreed or
  disagreed on this.
  - Yawar proposed to have the main activity run on github, and pull
  periodically to code.gnucash.org. The latter can be considered
  canonical.
  
  Let's continue to build on this. I propose this setup:
  
  One master repo hosted on github. One canonical repo on
  code.gnucash.org pulls periodically from this master repo to keep
  in sync.
  
  Only selected developers have commit access to the github
  repository. This is all access control we need here.
  
  All others that wish to contribute have to fork/clone this
  repository and send in patches.
  
  It looks like we better don't use github's issue tracker and pull
  request mechanisms. John stated this explicitly on the previous
  discussion, but there is criticism on these tools also in other
  (large) projects. Instead we continue to use our own contribution
  process, being: patches have to be sent to bugzilla or the mailing
  list (the latter has a higher risk of getting lost). Issues should
  be tracked in bugzilla. Ideas and requests could be tracked in
  either bugzilla or uservoice.
  
  There is also a feature on github to annotate patches (write inline
  comments). I don't know it's advantages or drawbacks, but given the
  opinion on pull requests and issue tracker, it's probably safe to
  not promote the annotation tool so far. Instead discussion of
  patches continues on the mailing lists as is now.
  
  I have not really decided yet how to handle access control to the
  canonical repository on code.gnucash.org yet. In principle nobody
  needs to push anything to this repo. It should simply fully
  automatically pull from the github master repo. But just in case
  for maintenance or other situations, I think it makes sense to
  allow push access by the same developers that currently can commit
  to svn on code.gnucash.org.
  
  I have deliberately skipped implementation details in this mail
  (how to enforce access control, how to trigger push/pull
  requests,...). I first would like to come to a consensus on the
  concept. Then work out the details.
  
  So any issues with this proposal ? (If so, please use bugzilla, not
  the github issue tracker ;p ). Or if you agree, please state so as
  well, so we can get an idea if we can pursue this proposal or not.
 
 Sounds good to me.
 
 Regards,
 John Ralls
 

This gets my vote.  Bugzilla is a far better tracking system than
Guthub, IMHO.

Mike Evans

-- 
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: Trivia: If GnuCash were a commercial program...

2012-09-14 Thread Mike Evans
On Thu, 13 Sep 2012 20:20:33 +0200
Geert Janssens janssens-ge...@telenet.be wrote:

 ... it is estimated it would have costed about 90 person years to develop :)
 
 At least that's what the program sloccount claims. This is obviously not 
 scientific calculation, just for fun. The program is primarily meant to 
 calculate the effective source lines of code (sloc) in a project. I have 
 ran it on GnuCash, here's the full summary for those interested:
 
 Totals grouped by language (dominant language first):
 ansic:   260622 (77.04%)
 lisp: 42674 (12.61%)
 sh:   16955 (5.01%)
 python:6823 (2.02%)
 cpp:   6387 (1.89%)
 perl:  4835 (1.43%)
 
 
 
 
 Total Physical Source Lines of Code (SLOC)= 338,296
 Development Effort Estimate, Person-Years (Person-Months) = 90.53 (1,086.36)
   (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
 Schedule Estimate, Years (Months) = 2.97 (35.61)
   (Basic COCOMO model, Months = 2.5 * (person-months**0.38))
 Estimated Average Number of Developers (Effort/Schedule)  = 30.50
 Total Estimated Cost to Develop   = $ 12,229,349
   (average salary = $56,286/year, overhead = 2.40).
 SLOCCount, Copyright (C) 2001-2004 David A. Wheeler
 SLOCCount is Open Source Software/Free Software, licensed under the GNU GPL.
 SLOCCount comes with ABSOLUTELY NO WARRANTY, and you are welcome to
 redistribute it under certain conditions as specified by the GNU GPL 
 license;
 see the documentation for details.
 Please credit this data as generated using David A. Wheeler's 'SLOCCount'.
 
 Have fun !
 
 Geert
 ___

Hi all

I found this cost estimate the other day which has a similar cost estimate.

http://www.ohloh.net/p/gnucash/estimated_cost

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


Re: Gnucash documentation

2012-09-06 Thread Mike Evans
On Thu, 06 Sep 2012 11:49:43 +0200
Geert Janssens janssens-ge...@telenet.be wrote:

 Bug 661705 triggered me to look at our documentation build scripts
 and the state of our documentation repository in general.
 
 I noticed there was no 2.4 branch yet, although a number of commits
 in trunk were not meant for 2.4. So I have branched 2.4 just before
 the first commit that's not 2.4 related, and backported all relevant
 commits to the 2.4 branch as well.
 
 I wasn't sure about the business import features (which are optional
 in GnuCash). Are they available to 2.4 users as well ? Or perhaps
 only the invoice importer and not the owner importer ? If so, some
 additional commits may need to be backported as well.

I think the importer stuff can safely be left as is for the 2.4 branch.
Mike E

 
 Next, the bug that started all this, is now fixed both in 2.4 and
 trunk. It does affect distro's that ship recent versions of yelp. For
 that reason I would like to do a new stable documentation release
 soon (like in a week or so).
 
 Are there things that should be done in the documentation before I do 
 this release ? Please let me know.
 
 Geert
 
 [1] https://bugzilla.gnome.org/show_bug.cgi?id=661705
 ___
 gnucash-devel mailing list
 gnucash-devel@gnucash.org
 https://lists.gnucash.org/mailman/listinfo/gnucash-devel



-- 
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: r22335 - gnucash-docs/trunk/guide/C - Move chapter on importing bills and invoices.

2012-08-22 Thread Mike Evans
On Wed, 22 Aug 2012 09:24:28 -0400
Derek Atkins warl...@mit.edu wrote:

 Mike Evans mi...@saxicola.idps.co.uk writes:
 
  I believe this change broke the docs build last night.
  
  Are you sure the file isn't named import_business_data?
  
  -derek
  
 
  Oops.  Looks like a typo.  I'll fix ASAP.
 
 If you attempted to fix it, the fix didn't take.  The docs build is
 still broken.
 
  Mike E
 
 -derek
 

Just added the file to SVN.

Mike E :(

-- 
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: r22335 - gnucash-docs/trunk/guide/C - Move chapter on importing bills and invoices.

2012-08-21 Thread Mike Evans
On Tue, 21 Aug 2012 10:52:37 -0400
Derek Atkins warl...@mit.edu wrote:

 Hi,
 
 Mike Evans mi...@code.gnucash.org writes:
 
  Modified:
 gnucash-docs/trunk/guide/C/Makefile.am
 gnucash-docs/trunk/guide/C/ch_python_bindings.xml
 gnucash-docs/trunk/guide/C/gnucash-guide.xml
  Log:
  Move chapter on importing bills and invoices.
 
  Although there is some Python in this chapter it's not really about
  the Python Bindings.
 
  Modified: gnucash-docs/trunk/guide/C/Makefile.am
  ===
  --- gnucash-docs/trunk/guide/C/Makefile.am  2012-08-20
  15:50:23 UTC (rev 22334) +++
  gnucash-docs/trunk/guide/C/Makefile.am  2012-08-20 16:28:58
  UTC (rev 22335) @@ -22,6 +22,7 @@ ch_budgets.xml \
  ch_oth_assets.xml \
  ch_python_bindings.xml \
  +   ch_import_busisness_data.xml
  appendixa.xml \
  appendixb.xml \
  appendixc.xml \
 
 I believe this change broke the docs build last night.
 
 Are you sure the file isn't named import_business_data?
 
 -derek
 

Oops.  Looks like a typo.  I'll fix ASAP.

Mike E



-- 
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


  1   2   3   >