Re: Using AsciiDoc for Documentation

2015-09-02 Thread David T. 

> On Sep 2, 2015, at 8:57 PM, John Ralls  wrote:
> 
> 
>> On Sep 2, 2015, at 10:36 AM, David T.  wrote:
>> 
>> 
>>> On Sep 2, 2015, at 9:45 AM, John Ralls  wrote:
>>> 
>>> 
 On Sep 2, 2015, at 2:55 AM, Mike Evans  wrote:
 
 On Tue, 1 Sep 2015 13:44:39 -0500
 Rob Gowin  wrote:
 
> 
>> On Sep 1, 2015, at 4:56 AM, Mike Evans  wrote:
>>> [snip]
>> 
>> Hi Rob
>> 
>> Looks good to me. Still a few minor bugs with the Asciidoc.  
>> 
>> Some of the Figure titles are missing
>> Second level bullet indents missing
>> 
>> But these are minor and some tweaking of the XSL should fix that.  
>> Speaking of which, I notice the XSL isn't in github can you make that 
>> available somewhere so others can chip in with help? I'd also like to 
>> generate the Asciidoc locally so I can ensure both formats are from the 
>> same source for comparison purposes.
>> 
>> Now you (we) have to convince others to use Asciidoc!
>> 
>> I use Geany for my coding/writing and there is a Markdown plugin for 
>> preview, no Asciidoc at the moment though.  I'm looking at the PEG code 
>> to see how difficult it would be to produce an Asciidoc previewer 
>> plugin.  It may be beyond my learning tolerance though.
>> 
>> Mike E
>> 
>> 
>> 
>> -- 
>> PGP key:
>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x00CDB13500D7AB53  
> 
> 
> Hi Mike,
> 
> Thanks for taking a look. I have put the XSL file and a python
> script to run the conversion process in a repository at 
> https://github.com/codesmythe/asciidoc-conversion. See the README
> there for details.
> 
> As for editors, I just use a command line converter and then
> reload the generated HTML into a browser. I need to try some of the
> live preview editors mentioned in the link you sent out yesterday.
> 
> I'll look at the issues you mentioned in the next couple of days.
> 
> Thanks,
> 
> Rob
> 
> 
> 
 
 Hi Rob
 
 Bearing in mind this would only ever need to be run once for each document 
 set and that Asciidoc may not be adopted anyway it's probably not worth 
 spending a lot of effort on those final issues for the moment.  They can 
 likely be easily(ish) fixed manually after conversion.  
>>> 
>>> Well, let’s poll the person most likely to make use of the switch:
>>> 
>>> David Carlson, please have a look at http://asciidoc.org/userguide.html, 
>>> starting at section 8, and tell us if you’d be able to easily edit 
>>> documents in that format.
>>> 
>>> Regards,
>>> John Ralls
>>> 
>>> 
>>> ___
>>> gnucash-devel mailing list
>>> gnucash-devel@gnucash.org
>>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>> 
>> Although I am not named above, I will note that a quick examination of the 
>> asciidoc pages fails to turn up a readily-available OS X (as in “Here is the 
>> dmg. Download it and install it like other Mac apps.”) version of the 
>> program. I’ve been down the Fink/Homebrew/MacPorts rabbit hole before (most 
>> notably with GnuCash itself), and I can honestly say that I will not be 
>> using asciidoc for creating or managing documentation. My life is too short 
>> for that.
> 
> I don’t know that you’d need to run asciidoc itself. That would be part of 
> the documentation build process. You’d just need to use a text editor to 
> create or edit a file with asciidoc markup in it instead of Docbook markup. 
> The question is “is asciidoc’s markup preferable to you over Docbook?”
> 
> Regards,
> John Ralls
> 

John,

I’ve looked at the documentation a little. It looks a lot like the wiki syntax. 
I personally don’t feel strongly about one format over another, except inasmuch 
as I have already spent a good bit of time learning the current documentation 
syntax.

Frankly, for me the problem has never been whether the documentation uses one 
obscure text-formatting format or another. I’ve been editing HTML code and any 
of a multitude of other text markup languages in text editors for decades. I 
just look at what’s already there, and copy it until I eventually get it 
learned. 

I will admit that as I age, I get less happy with the mental overhead of trying 
to imagine what things will ultimately look like—and I would hazard a guess 
that the language in the documents suffers because people have to spend mental 
cycles filtering out markup and imagining how things will look, rather than on 
what is actually being said. So, having a WYSIWIG editor would benefit the 
docs, I believe.

Ultimately, though, the problem for me with updating GnuCash documentation has 
always been about the workflow surrounding the actual editing. [I am reasonably 
sure that the developer list and those who must suffer with my mangling of the 
update/patching process would agree with my self-assessmen

Re: Using AsciiDoc for Documentation

2015-09-02 Thread Buddha Buck 
On Wed, Sep 2, 2015 at 10:20 AM Geert Janssens 
wrote:

> As with markup the primary drawback I currently see is the lack of a
> wysiwyg capable editor
> that's present on all platforms we support.
>

By "markup" here do you mean "Markdown"?

If so, there are a number of wysiwyg-like editors available, presuming that
two panes, one with the plain markdown, the other a real-time rendered
preview, is sufficient.

Atom (http://www.atom.io) is a very capable "hackable" editor which
supports Markdown with preview pane out of the box. It's open source and
supports Linux, Mac, and Windows

Remarkable (https://remarkableapp.github.io/
) is a Windows/Linux open
source Markdown editor with live preview, and also will export HTML and PDF
out of the box. It does not claim MacOS support.

CuteMarkEd (https://cloose.github.io/CuteMarkEd/) uses Qt as it's platform,
and thus supports Linux, Windows, and possibly Mac if compiled from source.
It has similar features as the others.

 I also haven't been paying close attention so I don't know if pandoc (
http://pandoc.org/index.html) has been evaluated for document conversion.
It seems to support converting every input file format under discussion to
every output file format under discussion. Did I miss the discussion?
___
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 John Ralls 

> On Sep 2, 2015, at 10:36 AM, David T.  wrote:
> 
> 
>> On Sep 2, 2015, at 9:45 AM, John Ralls  wrote:
>> 
>> 
>>> On Sep 2, 2015, at 2:55 AM, Mike Evans  wrote:
>>> 
>>> On Tue, 1 Sep 2015 13:44:39 -0500
>>> Rob Gowin  wrote:
>>> 
 
> On Sep 1, 2015, at 4:56 AM, Mike Evans  wrote:
>> [snip]
> 
> Hi Rob
> 
> Looks good to me. Still a few minor bugs with the Asciidoc.  
> 
> Some of the Figure titles are missing
> Second level bullet indents missing
> 
> But these are minor and some tweaking of the XSL should fix that.  
> Speaking of which, I notice the XSL isn't in github can you make that 
> available somewhere so others can chip in with help? I'd also like to 
> generate the Asciidoc locally so I can ensure both formats are from the 
> same source for comparison purposes.
> 
> Now you (we) have to convince others to use Asciidoc!
> 
> I use Geany for my coding/writing and there is a Markdown plugin for 
> preview, no Asciidoc at the moment though.  I'm looking at the PEG code 
> to see how difficult it would be to produce an Asciidoc previewer plugin. 
>  It may be beyond my learning tolerance though.
> 
> Mike E
> 
> 
> 
> -- 
> PGP key:
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x00CDB13500D7AB53  
 
 
 Hi Mike,
 
 Thanks for taking a look. I have put the XSL file and a python
 script to run the conversion process in a repository at 
 https://github.com/codesmythe/asciidoc-conversion. See the README
 there for details.
 
 As for editors, I just use a command line converter and then
 reload the generated HTML into a browser. I need to try some of the
 live preview editors mentioned in the link you sent out yesterday.
 
 I'll look at the issues you mentioned in the next couple of days.
 
 Thanks,
 
 Rob
 
 
 
>>> 
>>> Hi Rob
>>> 
>>> Bearing in mind this would only ever need to be run once for each document 
>>> set and that Asciidoc may not be adopted anyway it's probably not worth 
>>> spending a lot of effort on those final issues for the moment.  They can 
>>> likely be easily(ish) fixed manually after conversion.  
>> 
>> Well, let’s poll the person most likely to make use of the switch:
>> 
>> David Carlson, please have a look at http://asciidoc.org/userguide.html, 
>> starting at section 8, and tell us if you’d be able to easily edit documents 
>> in that format.
>> 
>> Regards,
>> John Ralls
>> 
>> 
>> ___
>> gnucash-devel mailing list
>> gnucash-devel@gnucash.org
>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> 
> Although I am not named above, I will note that a quick examination of the 
> asciidoc pages fails to turn up a readily-available OS X (as in “Here is the 
> dmg. Download it and install it like other Mac apps.”) version of the 
> program. I’ve been down the Fink/Homebrew/MacPorts rabbit hole before (most 
> notably with GnuCash itself), and I can honestly say that I will not be using 
> asciidoc for creating or managing documentation. My life is too short for 
> that.

I don’t know that you’d need to run asciidoc itself. That would be part of the 
documentation build process. You’d just need to use a text editor to create or 
edit a file with asciidoc markup in it instead of Docbook markup. The question 
is “is asciidoc’s markup preferable to you over Docbook?”

Regards,
John Ralls


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

Re: Rounding in the price db.

2015-09-02 Thread John Ralls 

> On Sep 2, 2015, at 1:18 PM, David Carlson  wrote:
> 
> On 9/1/2015 10:01 PM, John Ralls wrote:
>>> SNIP...
>> David,
>> 
>> Quotes from F::Q are supposed to overwrite user entries for the day, but 
>> although F::Q is quite capable of retrieving historical quotes, GnuCash 
>> doesn’t use that facility. So if you create a transaction with a date_posted 
>> in the past and there isn’t already an F::Q quote for that day then the 
>> price generated from that transaction won’t get overwritten later on. On the 
>> other hand, if you do have an F::Q quote already on that day then the user 
>> price won’t get written to the price db.
>> 
>> Umm, are you able to build from git? This code is currently on a feature 
>> branch so it isn’t going to get into the nightlies for you to test with 
>> otherwise. I think I understand the first test-case well enough to run tests 
>> myself, but I need more detail on the second (the duplicate-and-modify) one 
>> to test it.
>> 
>> Regards,
>> John Ralls
> 
> John,
> I am not ready to try git, but if it does get to nightly or weekly
> windows builds, I could try that.
> 
> That second case comes from a habit I developed years ago that once I
> have a transaction with a structure that I like but it is in the 'wrong'
> account for my current needs, I will clone it there then change the date
> and accounts one by one until it is 'correct.'  Sometimes I will stop
> and create a new account if I did not create all the accounts ahead of
> time.  Since I don't have a fixed routine to do this, I may change any
> transaction field in any order, then I often need to save before
> finishing to switch to a different account register to complete the
> transaction.  This is most likely to happen when I sell a security that
> I have not sold from that brokerage account in the past, but that is not
> the only time it happens. 
> 
> Prior to the 2.6 .x releases, that did not cause any issues in the price
> data, but now there are cases where GnuCash wants to set a price (or
> quantity?) for a 'wrong' security before I am ready, and it may also add
> entries to the price database.  If GnuCash discards transaction derived
> prices when there are 'better' prices already present, that is fine with
> me.  Otherwise I would request that GnuCash ask if I want to record the
> price in the database before that happens.  I think that there is a
> difference between 'User" prices entered directly into the database
> compared to prices derived indirectly from transactions.  If the derived
> price(s) disappear if (all of the) the source transactions for that date
> disappear or change, that would be ok too.
> 
> Actually, when directly editing the price database, the user can select
> whether the price is characterized as High, Low, Last, NAV, etc.  Only
> Last or NAV type 'User' prices would need to be 'stickier' than F:Q
> prices or indirectly derived prices, in my opinion.

David,

Git’s the easy part. *Building* is the hard part, especially on Windows. I’m 
not quite ready to merge but I will soon so that you can test it before the 
release.

Your use case is an interesting one. It actually points up a weakness in the 
Transfer Dialog, which assumes that the “other” account has been set in the 
transaction. We might want to defer running the dialog until the transaction 
edit is completed instead of when exiting the Credit or Debit cell.

Prices have a source and a type field. The source can be “Finance::Quote”, 
“user:invoice-post”, “user:stock-split”, “user:xfer-dialog”, 
“user:split-register”, or “user:price-editor”. The current code treats all of 
the “user:foo” sources the same and prefers F::Q to any of them. Early in this 
thread we discussed making two flavors of user:xfer-dialog so that cases where 
the users entered the price directly could be differentiated from those where 
she entered the amount of the “other” currency and the former preferred over 
the latter. I haven’t implemented that yet, and your point about 
user:price-editor being preferred over all others is a good one.

Regards,
John Ralls


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

Re: Rounding in the price db.

2015-09-02 Thread David Carlson 
On 9/1/2015 10:01 PM, John Ralls wrote:
>> SNIP...
> David,
>
> Quotes from F::Q are supposed to overwrite user entries for the day, but 
> although F::Q is quite capable of retrieving historical quotes, GnuCash 
> doesn’t use that facility. So if you create a transaction with a date_posted 
> in the past and there isn’t already an F::Q quote for that day then the price 
> generated from that transaction won’t get overwritten later on. On the other 
> hand, if you do have an F::Q quote already on that day then the user price 
> won’t get written to the price db.
>
> Umm, are you able to build from git? This code is currently on a feature 
> branch so it isn’t going to get into the nightlies for you to test with 
> otherwise. I think I understand the first test-case well enough to run tests 
> myself, but I need more detail on the second (the duplicate-and-modify) one 
> to test it.
>
> Regards,
> John Ralls

John,
I am not ready to try git, but if it does get to nightly or weekly
windows builds, I could try that.

That second case comes from a habit I developed years ago that once I
have a transaction with a structure that I like but it is in the 'wrong'
account for my current needs, I will clone it there then change the date
and accounts one by one until it is 'correct.'  Sometimes I will stop
and create a new account if I did not create all the accounts ahead of
time.  Since I don't have a fixed routine to do this, I may change any
transaction field in any order, then I often need to save before
finishing to switch to a different account register to complete the
transaction.  This is most likely to happen when I sell a security that
I have not sold from that brokerage account in the past, but that is not
the only time it happens. 

Prior to the 2.6 .x releases, that did not cause any issues in the price
data, but now there are cases where GnuCash wants to set a price (or
quantity?) for a 'wrong' security before I am ready, and it may also add
entries to the price database.  If GnuCash discards transaction derived
prices when there are 'better' prices already present, that is fine with
me.  Otherwise I would request that GnuCash ask if I want to record the
price in the database before that happens.  I think that there is a
difference between 'User" prices entered directly into the database
compared to prices derived indirectly from transactions.  If the derived
price(s) disappear if (all of the) the source transactions for that date
disappear or change, that would be ok too.

Actually, when directly editing the price database, the user can select
whether the price is characterized as High, Low, Last, NAV, etc.  Only
Last or NAV type 'User' prices would need to be 'stickier' than F:Q
prices or indirectly derived prices, in my opinion.

David C
___
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 David T. 

> On Sep 2, 2015, at 9:45 AM, John Ralls  wrote:
> 
> 
>> On Sep 2, 2015, at 2:55 AM, Mike Evans  wrote:
>> 
>> On Tue, 1 Sep 2015 13:44:39 -0500
>> Rob Gowin  wrote:
>> 
>>> 
 On Sep 1, 2015, at 4:56 AM, Mike Evans  wrote:
> [snip]
 
 Hi Rob
 
 Looks good to me. Still a few minor bugs with the Asciidoc.  
 
 Some of the Figure titles are missing
 Second level bullet indents missing
 
 But these are minor and some tweaking of the XSL should fix that.  
 Speaking of which, I notice the XSL isn't in github can you make that 
 available somewhere so others can chip in with help? I'd also like to 
 generate the Asciidoc locally so I can ensure both formats are from the 
 same source for comparison purposes.
 
 Now you (we) have to convince others to use Asciidoc!
 
 I use Geany for my coding/writing and there is a Markdown plugin for 
 preview, no Asciidoc at the moment though.  I'm looking at the PEG code to 
 see how difficult it would be to produce an Asciidoc previewer plugin.  It 
 may be beyond my learning tolerance though.
 
 Mike E
 
 
 
 -- 
 PGP key:
 http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x00CDB13500D7AB53  
>>> 
>>> 
>>> Hi Mike,
>>> 
>>> Thanks for taking a look. I have put the XSL file and a python
>>> script to run the conversion process in a repository at 
>>> https://github.com/codesmythe/asciidoc-conversion. See the README
>>> there for details.
>>> 
>>> As for editors, I just use a command line converter and then
>>> reload the generated HTML into a browser. I need to try some of the
>>> live preview editors mentioned in the link you sent out yesterday.
>>> 
>>> I'll look at the issues you mentioned in the next couple of days.
>>> 
>>> Thanks,
>>> 
>>> Rob
>>> 
>>> 
>>> 
>> 
>> Hi Rob
>> 
>> Bearing in mind this would only ever need to be run once for each document 
>> set and that Asciidoc may not be adopted anyway it's probably not worth 
>> spending a lot of effort on those final issues for the moment.  They can 
>> likely be easily(ish) fixed manually after conversion.  
> 
> Well, let’s poll the person most likely to make use of the switch:
> 
> David Carlson, please have a look at http://asciidoc.org/userguide.html, 
> starting at section 8, and tell us if you’d be able to easily edit documents 
> in that format.
> 
> Regards,
> John Ralls
> 
> 
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Although I am not named above, I will note that a quick examination of the 
asciidoc pages fails to turn up a readily-available OS X (as in “Here is the 
dmg. Download it and install it like other Mac apps.”) version of the program. 
I’ve been down the Fink/Homebrew/MacPorts rabbit hole before (most notably with 
GnuCash itself), and I can honestly say that I will not be using asciidoc for 
creating or managing documentation. My life is too short for that.

David (T.)
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Using LaTex for Documentation

2015-09-02 Thread Ted Creedon 
I hack using word and do a word to latex conversion

If you want I can setup a tooling stream, I presume that the permuted index 
needs to be created after conversion

Send me a file to convert

Tedc

From: Geert Janssens 
Sent: Wednesday, September 2, 2015 8:39:34 AM
To: gnucash-devel@gnucash.org
Cc: John Ralls; Ted Creedon
Subject: Re: Using LaTex for Documentation


On Tuesday 01 September 2015 07:07:13 John Ralls wrote:

> > On Sep 1, 2015, at 3:38 AM, Ted Creedon 

> > wrote:

> >

> > whats wrong with Latex?

> >

> > It works fine and produces a permuted index too

>

> Besides being even geekier and harder to convert to ePub and HTML than

> Docbook? Probably nothing much.

>

For me the geeky nature is not relevant.



I care about an easy way to write documentation ideally wysiwym (as opposed to 
wysiwyg) and easy to merge patches.



For latex documents I found LyX [1], which seems to be a free wysiwym editor 
available on all major platforms. I haven't found ways yet to convert from 
docbook to latex, so getting started may be a bigger hurdle here. There is 
dblatex but my first run failed to do the conversion. It may work after some 
more tweaking.



The conversion to epub should not be too hard. Generating pdf from latex is the 
natural flow of things and there are lots of pdf to epub convertors around. So 
I presume one of them will be able to do the job.



Html is less clear. There's a document (last modified in 2007) which documents 
a process to convert from latex to docbook [3] which would extend our current 
workflow. I is unfortunately based on lyx 1.2.0, which is ancient and in 
addition it brings in a lot of dependencies.



Then this page lists several latex to html converters [4]. I haven't gotten 
around to test them so I can't say much for the quality of the generated html.



Geert



[1] https://en.wikipedia.org/wiki/LyX

http://www.lyx.org/

[2] http://dblatex.sourceforge.net/

[3] http://www.karakas-online.de/mySGML/

[4] http://www.tex.ac.uk/FAQ-LaTeX2HTML.html
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Using LaTex for Documentation

2015-09-02 Thread Geert Janssens 
On Tuesday 01 September 2015 07:07:13 John Ralls wrote:
> > On Sep 1, 2015, at 3:38 AM, Ted Creedon 
> > wrote:
> > 
> > whats wrong with Latex?
> > 
> > It works fine and produces a permuted index too
> 
> Besides being even geekier and harder to convert to ePub and HTML than
> Docbook? Probably nothing much.
> 
For me the geeky nature is not relevant.

I care about an easy way to write documentation ideally wysiwym (as opposed to 
wysiwyg) and 
easy to merge patches.

For latex documents I found LyX [1], which seems to be a free wysiwym editor 
available on all 
major platforms. I haven't found ways yet to convert from docbook to latex, so 
getting started 
may be a bigger hurdle here. There is dblatex but my first run failed to do the 
conversion. It 
may work after some more tweaking.

The conversion to epub should not be too hard. Generating pdf from latex is the 
natural flow of 
things and there are lots of pdf to epub convertors around. So I presume one of 
them will be 
able to do the job.

Html is less clear. There's a document (last modified in 2007) which documents 
a process to 
convert from latex to docbook [3] which would extend our current workflow. I is 
unfortunately 
based on lyx 1.2.0, which is ancient and in addition it brings in a lot of 
dependencies.

Then this page lists several latex to html converters [4]. I haven't gotten 
around to test them 
so I can't say much for the quality of the generated html.

Geert

[1] https://en.wikipedia.org/wiki/LyX
http://www.lyx.org/
[2] http://dblatex.sourceforge.net/
[3] http://www.karakas-online.de/mySGML/
[4] http://www.tex.ac.uk/FAQ-LaTeX2HTML.html
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Using LaTex for Documentation

2015-09-02 Thread Derek Atkins 
Ted Creedon  writes:

> I find I quite easy to use and the typesetting is superb. Especially
> if equations are needed.

I know of no equations required for the GnuCash documentation.

> Xml is a hack

How do you go from (La)TeX to HTML or ePub?  I only know how to get to
DVI, PS (via DVI), and PDF (via DVI or directly using pdflatex).

> Ted

-derek

> 
> From: John Ralls 
> Sent: Tuesday, September 1, 2015 7:07:13 AM
> To: Ted Creedon
> Cc: gnucash-devel@gnucash.org
> Subject: Re: Using LaTex for Documentation
>
>> On Sep 1, 2015, at 3:38 AM, Ted Creedon  wrote:
>>
>> whats wrong with Latex?
>>
>> It works fine and produces a permuted index too
>
> Besides being even geekier and harder to convert to ePub and HTML than
> Docbook? Probably nothing much.
>
> Regards,
> John Ralls
>
>
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
>

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

Re: Doxygen Warnings

2015-09-02 Thread Derek Atkins 
John Ralls  writes:

>> On Sep 1, 2015, at 2:53 PM, Matt Graham  wrote:
>> 
>> Thanks John,
>> 
>> I'm running doxygen directly on the src directory of the code.
>> 
>> Windows 8.1 at the moment. I'm travelling for work at the moment,
>> when I get home over the weekend I'll try it on my gentoo box too
>
> Matt,
>
> That probably explains your trouble. You can either use `make docs` or
> copy all of the configuration from it into your Doxygen setup. Make
> will be easier if you have a Mingw build setup, but getting that might
> not be worth it just to run Doxygen.

For the record the server calls doxygen directly (after using the
makefile to generate doxygen.cfg from the input file).  The script
basically does:

git fetch
git reset --hard origin/master
# Compute the version from the configure script
VERSION=`grep AC_INIT configure.ac | awk '{print $2}' | sed -e 's/\[//' -e 's/\]
,//'`
touch Makefile
make -f Makefile.am doxygen.cfg top_srcdir=$top_srcdir VERSION="$VERSION"
doxygen doxygen.cfg

So... it *should* be safe to run doxygen directly.

I'll note that the nightly script does redirect all output to /dev/null,
so it wont report any warnings!  It will only report an outright
failure.  I.e., it's quite possible that there are hundreds of warnings
in there.

> Regards,
> John Ralls

-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

Re: Using AsciiDoc for Documentation

2015-09-02 Thread Geert Janssens 
On Wednesday 02 September 2015 06:45:38 John Ralls wrote:
> > On Sep 2, 2015, at 2:55 AM, Mike Evans  wrote:
> > 
> > On Tue, 1 Sep 2015 13:44:39 -0500
> > 
> > Rob Gowin  wrote:
> >>> On Sep 1, 2015, at 4:56 AM, Mike Evans  wrote:
>  [snip]
> >>> 
> >>> Hi Rob
> >>> 
> >>> Looks good to me. Still a few minor bugs with the Asciidoc.
> >>> 
> >>> Some of the Figure titles are missing
> >>> Second level bullet indents missing
> >>> 
> >>> But these are minor and some tweaking of the XSL should fix that. 
> >>> Speaking of which, I notice the XSL isn't in github can you make
> >>> that available somewhere so others can chip in with help? I'd
> >>> also like to generate the Asciidoc locally so I can ensure both
> >>> formats are from the same source for comparison purposes.
> >>> 
> >>> Now you (we) have to convince others to use Asciidoc!
> >>> 
> >>> I use Geany for my coding/writing and there is a Markdown plugin
> >>> for preview, no Asciidoc at the moment though.  I'm looking at
> >>> the PEG code to see how difficult it would be to produce an
> >>> Asciidoc previewer plugin.  It may be beyond my learning
> >>> tolerance though.
> >>> 
> >>> Mike E
> >> 
> >> 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.
> Well, let’s poll the person most likely to make use of the switch:
> 
> David Carlson, please have a look at
> http://asciidoc.org/userguide.html, starting at section 8, and tell
> us if you’d be able to easily edit documents in that format.
> 
David T. is currently actively working on the English documentation. And I also 
saw patches 
by Chris Good recently. Additionally Mechtilde Stehmann is working on the 
German 
translation as well.

All good candidates to let us know how they perceive asciidoc/markup versus the 
current 
docbook format. I'm not sure they are all subscribed to the devel list so 
exceptionally I have 
addressed them directly in addition to the list.

Regards,

Geert
___
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 Geert Janssens 
On Wednesday 02 September 2015 10:55:34 Mike Evans wrote:
> On Tue, 1 Sep 2015 13:44:39 -0500
> 
> Rob Gowin  wrote:
> > > On Sep 1, 2015, at 4:56 AM, Mike Evans  wrote:
> > >> [snip]
> > > 
> > > Hi Rob
> > > 
> > > Looks good to me. Still a few minor bugs with the Asciidoc.
> > > 
> > > Some of the Figure titles are missing
> > > Second level bullet indents missing
> > > 
> > > But these are minor and some tweaking of the XSL should fix that. 
> > > Speaking of which, I notice the XSL isn't in github can you make
> > > that available somewhere so others can chip in with help? I'd
> > > also like to generate the Asciidoc locally so I can ensure both
> > > formats are from the same source for comparison purposes.
> > > 
> > > Now you (we) have to convince others to use Asciidoc!
> > > 
> > > I use Geany for my coding/writing and there is a Markdown plugin
> > > for preview, no Asciidoc at the moment though.  I'm looking at
> > > the PEG code to see how difficult it would be to produce an
> > > Asciidoc previewer plugin.  It may be beyond my learning
> > > tolerance though.
> > > 
> > > Mike E
> > 
> > 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

Mike, Rob,

Thanks for enthusiastically evaluating asciidoc. Until now I haven't had the 
chance to look at it 
and just did so superficially. 

In general I'm open for all alternatives if they represent a step forward in 
our documentation 
needs.

I remember Christian Stimming rejecting asciidoc in the original discussion 
because it still 
requires the user to learn a markup structure, which he considered too much of 
a barrier for 
new contributors.

Having said that, it seems asciidoc has more or less the same advantages and 
disadvantages 
as markup. It looks to be slightly more expressive than markup.

As with markup the primary drawback I currently see is the lack of a wysiwyg 
capable editor 
that's present on all platforms we support.

I agree with John we should ask the opinion of those users that are currently 
expressing interest 
in contributing to the documentation.

Regards,

Geert
___
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 John Ralls 

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

I guess the other test you guys need to do is to go back to Docbook, since that 
seems to be the gateway for generating everything we need besides HTML.

Regards,
John Ralls


___
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 John Ralls 

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

Well, let’s poll the person most likely to make use of the switch:

David Carlson, please have a look at http://asciidoc.org/userguide.html, 
starting at section 8, and tell us if you’d be able to easily edit documents in 
that format.

Regards,
John Ralls


___
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  wrote:

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

Hi Rob

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

Mike E

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