Re: [GNC-dev] Register Documentation Improvements (was Re: [GNC]Column widths again)

[Christopher Lam]

> So does GitHub (it’s the pencil icon to the right of Raw/Blame/History), 
> which also has a desktop front-end, https://desktop.github.com/ 
>  and a button on a file’s webpage that opens the 
> file in Github Desktop.
> I haven’t tried any of them, but perhaps David T. might like to and give us a 
> non-developer perspective.

I can confirm that 1 year ago I was hacking transaction.scm in Windows, using 
Notepad++, pasting changes into the GitHub.com web-based editor, checking edits 
using the Preview tab, until I learned enough command-line git, then emacs, 
then emacs-magit...
___
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)

[D via gnucash-devel]

So. I just tried this out on bug 791169. I believe it worked?

On August 23, 2018, at 11:47 PM, John Ralls  wrote:

David,


It’s git. It’s never difficult to remove stuff, but on the website there’s no 
reflow to get back what you’ve deleted, so take a  little more care than usual. 
(Well, there is, but not from the web interface: 
https://medium.com/git-tips/githubs-reflog-a9ff21ff765f)


You’ve already got a clone and you made a PR a week ago, so you’re most of the 
way there already.


{Optional} Create a branch in your repo on the website: Click on the “branch” 
drop down and enter a new branch name.


Now pick a file and click on the pencil. Make an edit or two. Scroll to the 
bottom where you’ll find two edit boxes, one for the commit summary and another 
for a detailed message and a radio to commit your changes or to create a new 
branch and a PR all in one go, which is why I marked “create a branch” as 
optional.


This method creates one commit per file. If your change is more complex and you 
want to have edits of more than one file in a single commit, there’s a 
work-around at 
https://stackoverflow.com/questions/17815895/can-i-edit-two-files-then-make-one-commit-using-github-web-based-editor.


When you’re done playing, just change the branch back to master and click the 
“# branches”  in the bar on the root page. You’ll get a list of current 
branches with a red trash can on the right side. Click the trash can to delete 
your play branch.


Regards,

John Ralls



On Aug 23, 2018, at 2:44 PM, David T.  wrote:


Hmm.

Let me see if I understand this correctly. You’re saying that I could make 
edits on my own forked copy of gnucash-docs, save those changes, and get them 
to the official gnucash-docs *all from the github website*?

*If* I understand it correctly, then this would be a big improvement from my 
perspective. After all, I’ve never objected to adding the obscure codes; it’s 
always been getting the changes in. It does sound promising, but I hesitate to 
take it on, simply because at this point, I am a trained hamster who knows how 
to get a result in one way and one way only. 

I will look for a simple doc update to try it out on; that way, when I 
miraculously find the one way to screw it up, it won’t be difficult to remove.

David

On Aug 23, 2018, at 9:55 AM, John Ralls  wrote:



On Aug 23, 2018, at 6:37 AM, Geert Janssens  wrote:

Op donderdag 23 augustus 2018 15:08:54 CEST schreef Derek Atkins:

Geert Janssens  writes:

[snip]

So I'm open for alternatives that would equally handle version
control, but is easier for documentation writers to cope with.

This can be a completely different tool that feels more intuitive or
it can be a system layered on top of git which would hide git's
technicalities. For example a web interface that offers online
documentation editing and that behind the scenes stores changes in
git. I don't know of such project off-hand though, but it may be worth
looking around for.

Those who need more advanced access can clone the git repo and work
locally.

I wonder how hard it would be to write a web interface on top of git
that abstracts away most of the git work to enable easier access?

-derek


It looks like gitlab does something like this already...

At least on Gnome's gitlab there are buttons to edit or open a webide. They 
only work on pages you have write access of course. However you can always 
fork a repo to get one with write access.


So does GitHub (it’s the pencil icon to the right of Raw/Blame/History), which 
also has a desktop front-end, https://desktop.github.com/ 
 and a button on a file’s webpage that opens the 
file in Github Desktop.

I haven’t tried any of them, but perhaps David T. might like to and give us a 
non-developer perspective.

Regards,
John Ralls
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel



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

Re: [GNC-dev] Register Documentation Improvements (was Re: [GNC] Column widths again)

[John Ralls]

David,

It’s git. It’s never difficult to remove stuff, but on the website there’s no 
reflow to get back what you’ve deleted, so take a  little more care than usual. 
(Well, there is, but not from the web interface: 
https://medium.com/git-tips/githubs-reflog-a9ff21ff765f 
)

You’ve already got a clone and you made a PR a week ago, so you’re most of the 
way there already.

{Optional} Create a branch in your repo on the website: Click on the “branch” 
drop down and enter a new branch name.

Now pick a file and click on the pencil. Make an edit or two. Scroll to the 
bottom where you’ll find two edit boxes, one for the commit summary and another 
for a detailed message and a radio to commit your changes or to create a new 
branch and a PR all in one go, which is why I marked “create a branch” as 
optional.

This method creates one commit per file. If your change is more complex and you 
want to have edits of more than one file in a single commit, there’s a 
work-around at 
https://stackoverflow.com/questions/17815895/can-i-edit-two-files-then-make-one-commit-using-github-web-based-editor
 
.

When you’re done playing, just change the branch back to master and click the 
“# branches”  in the bar on the root page. You’ll get a list of current 
branches with a red trash can on the right side. Click the trash can to delete 
your play branch.

Regards,
John Ralls


> On Aug 23, 2018, at 2:44 PM, David T.  wrote:
> 
> Hmm.
> 
> Let me see if I understand this correctly. You’re saying that I could make 
> edits on my own forked copy of gnucash-docs, save those changes, and get them 
> to the official gnucash-docs *all from the github website*?
> 
> *If* I understand it correctly, then this would be a big improvement from my 
> perspective. After all, I’ve never objected to adding the obscure codes; it’s 
> always been getting the changes in. It does sound promising, but I hesitate 
> to take it on, simply because at this point, I am a trained hamster who knows 
> how to get a result in one way and one way only. 
> 
> I will look for a simple doc update to try it out on; that way, when I 
> miraculously find the one way to screw it up, it won’t be difficult to remove.
> 
> David
> 
>> On Aug 23, 2018, at 9:55 AM, John Ralls  wrote:
>> 
>> 
>> 
>>> On Aug 23, 2018, at 6:37 AM, Geert Janssens  
>>> wrote:
>>> 
>>> Op donderdag 23 augustus 2018 15:08:54 CEST schreef Derek Atkins:
 Geert Janssens  writes:
 
 [snip]
 
> So I'm open for alternatives that would equally handle version
> control, but is easier for documentation writers to cope with.
> 
> This can be a completely different tool that feels more intuitive or
> it can be a system layered on top of git which would hide git's
> technicalities. For example a web interface that offers online
> documentation editing and that behind the scenes stores changes in
> git. I don't know of such project off-hand though, but it may be worth
> looking around for.
> 
> Those who need more advanced access can clone the git repo and work
> locally.
 I wonder how hard it would be to write a web interface on top of git
 that abstracts away most of the git work to enable easier access?
 
 -derek
>>> 
>>> It looks like gitlab does something like this already...
>>> 
>>> At least on Gnome's gitlab there are buttons to edit or open a webide. They 
>>> only work on pages you have write access of course. However you can always 
>>> fork a repo to get one with write access.
>> 
>> So does GitHub (it’s the pencil icon to the right of Raw/Blame/History), 
>> which also has a desktop front-end, https://desktop.github.com/ 
>>  and a button on a file’s webpage that opens 
>> the file in Github Desktop.
>> 
>> I haven’t tried any of them, but perhaps David T. might like to and give us 
>> a non-developer perspective.
>> 
>> Regards,
>> John Ralls
>> ___
>> gnucash-devel mailing list
>> gnucash-devel@gnucash.org
>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> 

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

Re: [GNC-dev] Register Documentation Improvements (was Re: [GNC] Column widths again)

[David T.]

Hmm.

Let me see if I understand this correctly. You’re saying that I could make 
edits on my own forked copy of gnucash-docs, save those changes, and get them 
to the official gnucash-docs *all from the github website*?

*If* I understand it correctly, then this would be a big improvement from my 
perspective. After all, I’ve never objected to adding the obscure codes; it’s 
always been getting the changes in. It does sound promising, but I hesitate to 
take it on, simply because at this point, I am a trained hamster who knows how 
to get a result in one way and one way only. 

I will look for a simple doc update to try it out on; that way, when I 
miraculously find the one way to screw it up, it won’t be difficult to remove.

David

> On Aug 23, 2018, at 9:55 AM, John Ralls  wrote:
> 
> 
> 
>> On Aug 23, 2018, at 6:37 AM, Geert Janssens  
>> wrote:
>> 
>> Op donderdag 23 augustus 2018 15:08:54 CEST schreef Derek Atkins:
>>> Geert Janssens  writes:
>>> 
>>> [snip]
>>> 
 So I'm open for alternatives that would equally handle version
 control, but is easier for documentation writers to cope with.
 
 This can be a completely different tool that feels more intuitive or
 it can be a system layered on top of git which would hide git's
 technicalities. For example a web interface that offers online
 documentation editing and that behind the scenes stores changes in
 git. I don't know of such project off-hand though, but it may be worth
 looking around for.
 
 Those who need more advanced access can clone the git repo and work
 locally.
>>> I wonder how hard it would be to write a web interface on top of git
>>> that abstracts away most of the git work to enable easier access?
>>> 
>>> -derek
>> 
>> It looks like gitlab does something like this already...
>> 
>> At least on Gnome's gitlab there are buttons to edit or open a webide. They 
>> only work on pages you have write access of course. However you can always 
>> fork a repo to get one with write access.
> 
> So does GitHub (it’s the pencil icon to the right of Raw/Blame/History), 
> which also has a desktop front-end, https://desktop.github.com/ 
>  and a button on a file’s webpage that opens the 
> file in Github Desktop.
> 
> I haven’t tried any of them, but perhaps David T. might like to and give us a 
> non-developer perspective.
> 
> Regards,
> John Ralls
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

Re: [GNC-dev] Register Documentation Improvements (was Re: [GNC] Column widths again)

[John Ralls]

> On Aug 23, 2018, at 10:25 AM, 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,

Thanks, I'd forgotten about that. I just tested and Github's online editor is 
able to render the adoc, so from that standpoint it's equivalent. Since it's 
supposed to be fully compatible with DocBook (though it requires an external 
tool like pandoc to convert from DocBook to Asciidoc) it will be a better fit 
with the existing sources that would any of the other plain-text markup choices.

What about it, (potential) documenters? Is any markup language acceptable or 
does the solution have to be WYSIWYG with buttons and menus for styling?

Regards,
John Ralls

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

[GNC-dev] Python C++ bindings - Re: Python: About Wrapping SWIG Objects (GncNumeric)

[c . holtermann]

Am 2018-08-23 16:52, schrieb c.holterm...@gmx.de:

Am 2018-08-06 16:14, schrieb John Ralls:

On Aug 6, 2018, at 5:19 AM, c.holterm...@gmx.de wrote:

Am 2018-08-06 11:35, schrieb Geert Janssens:

Op maandag 6 augustus 2018 05:32:27 CEST schreef John Ralls:

> On Aug 5, 2018, at 5:17 PM, c.holterm...@gmx.de wrote:
>
> Hello,
>
> after some time I get back to the gnucash python bindings.
>
> I worked on a str method for GncNumeric. It's in the example_script
> dir
> (https://github.com/Gnucash/gnucash/blob/maint/bindings/python/example_sc
> ripts/str_methods.py) I changed it to python3.
I read at the beginning of this file you chose to implement it as an 
example

script which - if found useful - could be added to gnucash_core.
You have my blessing to include it in gnucash_core :)

> Well I found it interesting to think these things through. Maybe someone
> can tell me about the mysterious "later on" in the cited comment. At this
> point I find it useful to have a way from the instance to the wrapping
> object through some kind of link as I suggested in the patch to
> function_class.
Christoph,
The person who wrote the first two lines of that, Mark Jenkins, was 
the
original source of the Python bindings. He was never a regular dev, 
he just
got 16 patches committed between 2007 and 2012, 10 of which touched 
the
python bindings. Your history with them is almost as long as 
his--in fact
you have *12* commits--and pretty much no one else has done 
anything

serious with them.

Hopefully Mark is still around on the list to clarify.

In other words, if anyone knows, it’s you!

True :)
Just to add some more confusion, there’s now a C++ class GncNumeric 
that
handles the actual implementation of many of the gnc_numeric.* 
functions. I
believe that SWIG can’t see it, only the C wrapper functions are 
exposed to

SWIG.
It would be a very useful experiment to wrap the C++ GncNumeric 
class directly
rather than it's c wrapper gnc_numeric_xxx. Python doesn't need the 
c

compatibility layer it represents.
Geert


Geert,

unfortunately your mail went to my spam folder for whatever reason. 
Trying to
do C++ bindings for python sounds very interesting. I'd like to try 
that when
I find the time for a simple example type. I don't know if GncNumeric 
would
be a good candidate. I'll have a look at it. Thanks for the blessing 
:-)


Python has its own rational numbers so the only thing the Python
bindings need is a way to convert to-and-from that to GncNumeric for
communicating with the rest of the GnuCash API.

I suggest QofSession as the first C++ class to play with SWIGing. It’s
fairly simple and using it is the first step in using the bindings.

Regards,
John Ralls


Hello,

I've created an experimental branch in my fork of gnucash to create 
swig python
bindings for c++ files. As suggested I started with QofSessionImpl for 
which I
have created an example file to create a file and an account. I also 
included

GncNumeric. There's no example for that yet. It's very raw. I disabled
some errors.
It's more of a proof of concept but it's a step on the way.
https://github.com/c-holtermann/gnucash/tree/ch-python

regards,

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


Hello,

I've moved the python c++ specifics to a separate branch in my fork. It
is https://github.com/c-holtermann/gnucash/tree/python-c%2B%2B.

regards,

Christoph Holtermann
___
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)

[Rob Gowin]

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

[John Ralls]

> On Aug 23, 2018, at 12:37 AM, Geert Janssens  
> wrote:
> 
> Op dinsdag 21 augustus 2018 20:50:38 CEST schreef Geert Janssens:
>> Op dinsdag 21 augustus 2018 17:49:57 CEST schreef Adrien Monteleone:
>>> but is there a list of ’needs’ of the
>>> developers to use when evaluating methods?
>> 
>> I don't think it's ever been formally written down. But here is a first
>> list:
>> 
>> - it should be as easy as possible to use by non-technical people
>> - it should allow multiple output formats. A few the come to mind:
>> html, pdf, epub, mobi, windows compressed help, xml for yelp,...
>> - it should support both on-screen output as printable output. This is
>> mostly relevant for image resolutions.
>> - it should support the usual typical documentation constructs, like
>> chapters, sections, subsections, indexes, links, tables, images,...
>> - it should be manageable. That is there should be mechanisms to support
>> multiple versions of one document simultaneously. A typical use case is that
>> some feature gets documented that is in both the current version and the
>> future one, so this document snippet should be in both versions of the
>> documentation as well. While a snippet that's only for the newer version
>> should only be in the future version of the documentation. And after a few
>> months it should still be obvious which snippets have been integrated in
>> which versions.
>> - I would like to see a WYSIWYM ("what you see is what you mean") kind of
>> editor for the documentation process.
>> 
>> This is non-exhaustive and I expect the other developers may have even more
>> requirements.
>> 
> Add a way to relatively easily manage translations of the documentation.

That's almost a new subject entirely. Except for Italian, the "translated" 
documents are more like "rewritten in another language". I think that's a good 
thing because it affords a more natural, idiomatic experience to readers, but I 
imagine (I have to imagine, I'm nowhere near fluent enough in any language 
other than English to have experience) that it's also more work on the part of 
the foreign-language authors.

The alternative is to run gettext on the doc sources and have a po file for the 
translation. Cristian Marchi set that up for Italian, but it has an unfortunate 
side effect: If the translation isn't kept up to date with the documentation 
progressively more of it becomes "fuzzy" and reverts to English. I tried for a 
while to do fresh it.po builds, but it was soon clear that it was a bad idea 
and so we're back to using a mostly frozen, monolithic, it/gnucash-guide.xml 
and it/gnucash-help.xml from 2.4.

Regards,
John Ralls

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

[John Ralls]

> On Aug 23, 2018, at 12:45 AM, Geert Janssens  
> wrote:
> 
> Op dinsdag 21 augustus 2018 21:24:25 CEST schreef John Ralls:
>>> On Aug 21, 2018, at 11:50 AM, Geert Janssens 
>>> wrote: - it should allow multiple output formats. A few the come to mind:
>>> html, pdf, epub, mobi, windows compressed help, xml for yelp,...
>> 
>> We don't need a single tool to do that; in fact we don't use a single tool
>> now. We create Windows compressed html (.chm) with HTML Help Workshop from
>> the xslt-created HTML and mobi with calibre from the xslt-created epub.
>> 
> It appears while writing down the requirements, I was more considering our 
> documentation system as a whole, not just a single tool. I agree this can 
> consist of several tools glued together.
> 
> I think what matters is the people actually writing the documentation should 
> have to learn as few as possible to keep the barrier for contribution very 
> low. More on that in reply to your other message.
> 
>> That aside, I think we should reconsider windows compressed help.
>> Microsoft's own Windows 10 applications seem to open the browser to the
>> relevant documentation page on www.microsoft.com and the help browser is
>> still decorated with Windows 2000 frame and controls. It looks quite
>> jarring. We could more easily just open the documents in a GtkWebkitWebView
>> just like reports.
> 
> I'm all for this. In fact I have proposed this in the past. That also rids us 
> of one of the more annoying build dependencies on Windows (HtmlHelp).
> 
> It would be nice if our html version of the docs would get some css love in 
> that case though. Wading through plain rendered html is an equally 2000'ish 
> experience.

I've been having another look at https://pandoc.org/. It consumes several 
flavors of markdown and wiki markup as well as DocBook. It emits an impressive 
range of output formats including DocBook, GNU texinfo (which is completely 
unrelated to TeX), LaTeX, HTML, and Epub; the only deficiency from our view 
would be that it doesn't directly emit PDF. It can do so indirectly via LaTeX 
or we could generate DocBook and continue to use Apache XML-Format-Objects.

My original thought was that contributors could use it to convert the current 
DocBook sources to Microsoft Word or LibreOffice format, edit in a familiar 
word processor, and then use pandoc to convert back to DocBook. That didn't 
work out very well in testing. 

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.

Regards,
John Ralls

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

Re: [GNC-dev] Python: About Wrapping SWIG Objects (GncNumeric)

[c . holtermann]

Am 2018-08-06 16:14, schrieb John Ralls:

On Aug 6, 2018, at 5:19 AM, c.holterm...@gmx.de wrote:

Am 2018-08-06 11:35, schrieb Geert Janssens:

Op maandag 6 augustus 2018 05:32:27 CEST schreef John Ralls:

> On Aug 5, 2018, at 5:17 PM, c.holterm...@gmx.de wrote:
>
> Hello,
>
> after some time I get back to the gnucash python bindings.
>
> I worked on a str method for GncNumeric. It's in the example_script
> dir
> (https://github.com/Gnucash/gnucash/blob/maint/bindings/python/example_sc
> ripts/str_methods.py) I changed it to python3.
I read at the beginning of this file you chose to implement it as an 
example

script which - if found useful - could be added to gnucash_core.
You have my blessing to include it in gnucash_core :)

> Well I found it interesting to think these things through. Maybe someone
> can tell me about the mysterious "later on" in the cited comment. At this
> point I find it useful to have a way from the instance to the wrapping
> object through some kind of link as I suggested in the patch to
> function_class.
Christoph,
The person who wrote the first two lines of that, Mark Jenkins, was 
the
original source of the Python bindings. He was never a regular dev, 
he just
got 16 patches committed between 2007 and 2012, 10 of which touched 
the
python bindings. Your history with them is almost as long as his--in 
fact

you have *12* commits--and pretty much no one else has done anything
serious with them.

Hopefully Mark is still around on the list to clarify.

In other words, if anyone knows, it’s you!

True :)
Just to add some more confusion, there’s now a C++ class GncNumeric 
that
handles the actual implementation of many of the gnc_numeric.* 
functions. I
believe that SWIG can’t see it, only the C wrapper functions are 
exposed to

SWIG.
It would be a very useful experiment to wrap the C++ GncNumeric class 
directly

rather than it's c wrapper gnc_numeric_xxx. Python doesn't need the c
compatibility layer it represents.
Geert


Geert,

unfortunately your mail went to my spam folder for whatever reason. 
Trying to
do C++ bindings for python sounds very interesting. I'd like to try 
that when
I find the time for a simple example type. I don't know if GncNumeric 
would
be a good candidate. I'll have a look at it. Thanks for the blessing 
:-)


Python has its own rational numbers so the only thing the Python
bindings need is a way to convert to-and-from that to GncNumeric for
communicating with the rest of the GnuCash API.

I suggest QofSession as the first C++ class to play with SWIGing. It’s
fairly simple and using it is the first step in using the bindings.

Regards,
John Ralls


Hello,

I've created an experimental branch in my fork of gnucash to create swig 
python
bindings for c++ files. As suggested I started with QofSessionImpl for 
which I
have created an example file to create a file and an account. I also 
included
GncNumeric. There's no example for that yet. It's very raw. I disabled 
some errors.

It's more of a proof of concept but it's a step on the way.
https://github.com/c-holtermann/gnucash/tree/ch-python

regards,

Christoph Holtermann
___
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)

[John Ralls]

> On Aug 23, 2018, at 6:37 AM, Geert Janssens  
> wrote:
> 
> Op donderdag 23 augustus 2018 15:08:54 CEST schreef Derek Atkins:
>> Geert Janssens  writes:
>> 
>> [snip]
>> 
>>> So I'm open for alternatives that would equally handle version
>>> control, but is easier for documentation writers to cope with.
>>> 
>>> This can be a completely different tool that feels more intuitive or
>>> it can be a system layered on top of git which would hide git's
>>> technicalities. For example a web interface that offers online
>>> documentation editing and that behind the scenes stores changes in
>>> git. I don't know of such project off-hand though, but it may be worth
>>> looking around for.
>>> 
>>> Those who need more advanced access can clone the git repo and work
>>> locally.
>> I wonder how hard it would be to write a web interface on top of git
>> that abstracts away most of the git work to enable easier access?
>> 
>> -derek
> 
> It looks like gitlab does something like this already...
> 
> At least on Gnome's gitlab there are buttons to edit or open a webide. They 
> only work on pages you have write access of course. However you can always 
> fork a repo to get one with write access.

So does GitHub (it’s the pencil icon to the right of Raw/Blame/History), which 
also has a desktop front-end, https://desktop.github.com/ 
 and a button on a file’s webpage that opens the 
file in Github Desktop.

I haven’t tried any of them, but perhaps David T. might like to and give us a 
non-developer perspective.

Regards,
John Ralls
___
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)

[Geert Janssens]

Op donderdag 23 augustus 2018 15:08:54 CEST schreef Derek Atkins:
> Geert Janssens  writes:
> 
> [snip]
> 
> > So I'm open for alternatives that would equally handle version
> > control, but is easier for documentation writers to cope with.
> > 
> > This can be a completely different tool that feels more intuitive or
> > it can be a system layered on top of git which would hide git's
> > technicalities. For example a web interface that offers online
> > documentation editing and that behind the scenes stores changes in
> > git. I don't know of such project off-hand though, but it may be worth
> > looking around for.
> > 
> > Those who need more advanced access can clone the git repo and work
> > locally.
> I wonder how hard it would be to write a web interface on top of git
> that abstracts away most of the git work to enable easier access?
> 
> -derek

It looks like gitlab does something like this already...

At least on Gnome's gitlab there are buttons to edit or open a webide. They 
only work on pages you have write access of course. However you can always 
fork a repo to get one with write access.

Geert


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

[Derek Atkins]

Geert Janssens  writes:

[snip]
> So I'm open for alternatives that would equally handle version
> control, but is easier for documentation writers to cope with.
>
> This can be a completely different tool that feels more intuitive or
> it can be a system layered on top of git which would hide git's
> technicalities. For example a web interface that offers online
> documentation editing and that behind the scenes stores changes in
> git. I don't know of such project off-hand though, but it may be worth
> looking around for.
>
> Those who need more advanced access can clone the git repo and work locally.

I wonder how hard it would be to write a web interface on top of git
that abstracts away most of the git work to enable easier access?

-derek

-- 
   Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
   Member, MIT Student Information Processing Board  (SIPB)
   URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
   warl...@mit.eduPGP key available
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

[GNC-dev] Bug 796778 Patch

[David Cousens]

Hi, 

I have attached a patch file with changes to 
gnucash/import-export/import-main-matcher.c and 
gnucash/gtkbuilder/dialog-import.glade for adding multiple selection 
capability to the import-matcher with the ability to assign a single 
transfer  account to the selected transactions to the Bug report
(https://bugs.gnucash.org/show_bug.cgi?id=796778). 

Transactions can be selected by any combination of Ctrl-click , Shift -click 
and click and mouse drag. Using either a Right click on the importer or the 
Shift-F10 GTK Popup menu shortcut will bring up a popupmenu with a single 
entry "Assign a transfer account". Clicking on that initiates selecting a 
transfer account and then assigning it to all transactions in the selection. 

Control is the returned to the import matcher where another group of 
transactions can be selected and the process repeated until all transactions 
have a transfer account applied. Clicking OK will then import the 
transactions as usual. 

The orignial double-click to input a transfer account for a single 
transaction is unaffectedby the above changes.  I have tested the above 
changes with "File->Import->Import OFX/QFX". and they work fine.  They 
should also apply to any of the transaction import formats as they were 
changes only to the import-main-matcher which seems to be common to the 
other formats 

I was looking for an appropriate point to modify the documentation, but I 
could not find a section on the importing of transactions from files in 
either the Tutorial and Concepts Guide or the Help Manual. Chapter 6 of the 
Help Manual on Common Transaction operations would seem to me to be a 
logical point to document importing transactions from OFX/QFX or CSV files, 
for example either before or after 6.15 Online Actions. 
e.g. 
6.16 Importing Transactions from Files followed by 
6.17  General Journal. 

Unless the documentation team has another suggestion or already has work in 
progress on this, I am willing to have a go at producing some documentation 
of the importing of transactions from files. 

David Cousens 



-
David Cousens
--
Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
___
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)

[Geert Janssens]

Op dinsdag 21 augustus 2018 21:36:58 CEST schreef John Ralls:
> > On Aug 21, 2018, at 11:50 AM, Geert Janssens 
> > wrote:
> > Aside from that they also expect there writers to work with git.
> 
> Version control is an obvious hard requirement. I don't know if it
> completely fulfills your "manageability" requirement, but it's crucial in a
> collaborative environment to be able to track who-did-what-when and to be
> able to restore an earlier version if something goes awry.
> 
In my requirements I deliberately wrote "manageability". Today we use git for 
this and from my developer's point of view it has all the features we need. So 
I consider it an excellent candidate. Unfortunately most non-developers 
experience it as a major hurdle.

So I'm open for alternatives that would equally handle version control, but is 
easier for documentation writers to cope with.

This can be a completely different tool that feels more intuitive or it can be 
a system layered on top of git which would hide git's technicalities. For 
example a web interface that offers online documentation editing and that 
behind the scenes stores changes in git. I don't know of such project off-hand 
though, but it may be worth looking around for.

Those who need more advanced access can clone the git repo and work locally.


> That said I'm perfectly happy to copy a rewritten section of a document into
> my working directory and create a commit out of it on behalf of a
> non-technical author who can't get their head around git.

Of course. Same for me. Anything that lowers the barrier.

Geert


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

[Geert Janssens]

Op dinsdag 21 augustus 2018 21:24:25 CEST schreef John Ralls:
> > On Aug 21, 2018, at 11:50 AM, Geert Janssens 
> > wrote: - it should allow multiple output formats. A few the come to mind:
> > html, pdf, epub, mobi, windows compressed help, xml for yelp,...
> 
> We don't need a single tool to do that; in fact we don't use a single tool
> now. We create Windows compressed html (.chm) with HTML Help Workshop from
> the xslt-created HTML and mobi with calibre from the xslt-created epub.
> 
It appears while writing down the requirements, I was more considering our 
documentation system as a whole, not just a single tool. I agree this can 
consist of several tools glued together.

I think what matters is the people actually writing the documentation should 
have to learn as few as possible to keep the barrier for contribution very 
low. More on that in reply to your other message.

> That aside, I think we should reconsider windows compressed help.
> Microsoft's own Windows 10 applications seem to open the browser to the
> relevant documentation page on www.microsoft.com and the help browser is
> still decorated with Windows 2000 frame and controls. It looks quite
> jarring. We could more easily just open the documents in a GtkWebkitWebView
> just like reports.

I'm all for this. In fact I have proposed this in the past. That also rids us 
of one of the more annoying build dependencies on Windows (HtmlHelp).

It would be nice if our html version of the docs would get some css love in 
that case though. Wading through plain rendered html is an equally 2000'ish 
experience.

Geert


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

[Geert Janssens]

Op dinsdag 21 augustus 2018 20:50:38 CEST schreef Geert Janssens:
> Op dinsdag 21 augustus 2018 17:49:57 CEST schreef Adrien Monteleone:
> > but is there a list of ’needs’ of the
> > developers to use when evaluating methods?
> 
> I don't think it's ever been formally written down. But here is a first
> list:
> 
> - it should be as easy as possible to use by non-technical people
> - it should allow multiple output formats. A few the come to mind:
> html, pdf, epub, mobi, windows compressed help, xml for yelp,...
> - it should support both on-screen output as printable output. This is
> mostly relevant for image resolutions.
> - it should support the usual typical documentation constructs, like
> chapters, sections, subsections, indexes, links, tables, images,...
> - it should be manageable. That is there should be mechanisms to support
> multiple versions of one document simultaneously. A typical use case is that
> some feature gets documented that is in both the current version and the
> future one, so this document snippet should be in both versions of the
> documentation as well. While a snippet that's only for the newer version
> should only be in the future version of the documentation. And after a few
> months it should still be obvious which snippets have been integrated in
> which versions.
> - I would like to see a WYSIWYM ("what you see is what you mean") kind of
> editor for the documentation process.
> 
> This is non-exhaustive and I expect the other developers may have even more
> requirements.
> 
Add a way to relatively easily manage translations of the documentation.

Regards,

Geert


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

Re: [GNC-dev] Python: About Wrapping SWIG Objects (GncNumeric)

[cicko]

Christoph Holtermann wrote
> I'm willing to now and then do something for the python bindings. I 
> don't feel like an expert. But surely I'd like to talk and think things
> through 
> about them. Maybe someone is interested. I saw that there were some people 
> asking questions about the bindings on this list. Maybe they don't commit
> but 
> still work with the bindings. So my question remains and maybe someone has
> an 
> idea.

Christoph,

I, for example, am quite interested in accessing GnuCash via Python. So, on
first sight, Python bindings seem an interesting option.
In practice, though, I did not find much motivation to spend time on it,
unfortunately. The main reason for that is that I need my (Python) code to
run on Windows, Linux, and Android. And to run equally well.
Since the bindings are available only on Linux, that's a very limiting
factor. So I've limited my work to only reading the GnuCash data. Additional
functionality is dispersed across various small projects that keep extra
information in their own databases (i.e. Asset Allocation). This works well
on Android and I can get my Portfolio Value report or Security Analysis by
running a Python script on my phone (sounds weird, I know).
To run on all platforms I'm using Sebastien's Piecash library.
Additional step would be to add some sort of (native) GUI on all the
platforms. I've already looked into that a bit, but nothing tickles my fancy
yet.

Having the ability to write data to GnuCash would be fantastic. However, I
don't think it's going to happen on multiple platforms any time soon.
Naturally, it is possible to write to GnuCash database but that is not
exactly the same as using GnuCash's business logic.

One thing I would like to improve on next is the process of getting the
transactions from the mobile app (MoneyManagerEx for Android) into GnuCash.
Python bindings would be perfect for that, to avoid lengthy process of .qif
import. I could adapt the Android app to provide GnuCash-specific export
file, for example. But if this would work only on Linux, it would be a very
small return on the investment of time and effort. 



--
Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel