[GNC-dev] avoid the brain dead import

[Wm]

in case it is appropriate to your import, don't allow it to check every 
transaction in your existing file against the one you want to import and 
know is unique [1]


[1] who thought that was a good idea anyway ?

redefine your import as a multi=split, then it doesn't seem to do the 
zombie behavior.


results here?

12 line import as singles?  45 minutes

same tx as multi-split? as fast as I can press the buttons

why are imported tx being checked against the existing ones in the first 
place?  shouldn't a person know if they are introducing new tx to their 
file?  are we really presuming *all* our users are so dumb they just 
keep on importing the same tx over and over again ?


'kin hell, not a good view of the import writer about the presumed 
importer, I mean if they are so fucking stupid you'd be surprised they 
manage accounting at all




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

Re: [GNC-dev] Documentation Version Display

[David T. via gnucash-devel]

Adrien,

That seems reasonable, too, although there was recently a long discussion about 
which online document a user was viewing, suggesting that it’s not always clear.

As for “search juice,” I can’t possibly imagine how there would be a major 
negative impact by adding “Gnucash v. 3.2” immediately prior the two document 
titles—and I can’t imagine a search where this would negatively affect results. 
Honestly, I imagine most people would search for “gnucash help” or “gnucash 
tutorial.” Such a search presumably would be helped by this change, rather than 
hurt by it. Not being privy to Google’s search algorithms, I can’t say with 
authority, or course.

I am opposed to removing these links altogether. As I noted elsewhere, “current 
stable release” is not IMHO a universally-understood term. And, while I haven’t 
mentioned it before, I personally find the grid of cryptic icons lined up next 
to the document titles to be difficult to understand or use. On my screen, they 
are far too small for me to process visually; of the four in use, I only 
immediately recognize the PDF icon. The use of a tiny earth icon for HTML help 
is neither intuitive to me, nor clear to discern. Additionally, I am admittedly 
unfamiliar with either the Epub or Mobi formats or icons; however, if the goal 
is to universally communicate the availability of these formats, I don’t think 
this is the way. But I digress! 

The point is, these links clearly put the user into the online documents, which 
I think is valuable.

David

> On Aug 24, 2018, at 6:30 PM, Adrien Monteleone 
>  wrote:
> 
> David,
> 
> I agree the pages should have both the document title (per another thread) 
> and the version either in the header or footer.
> 
> But I can’t fathom clicking the ‘main’ documentation link and thinking that 
> I’m getting anything other than the most current version. If I knew I was 
> running an older version of the software and slightly down the page I see a 
> link for documentation for that version, I’m going to grab that one instead, 
> making a fairly safe assumption that the main link isn’t for me.
> 
> The only solution I can think of for this situation is to remove those two 
> links at the top of the page and users will then click the links for their 
> chosen version. (with each already well labeled) Adding the version to those 
> links is, to me, unnecessary clutter. (links should be as concise and 
> accurately descriptive as possible, and changing that link text each release 
> will reduce search juice for those links.)
> 
> Regards,
> Adrien
> 
>> On Aug 24, 2018, at 12:03 PM, David T. via gnucash-devel 
>>  wrote:
>> 
>> John, 
>> 
>> 
>>> On Aug 24, 2018, at 10:57 AM, John Ralls  wrote:
>>> 
>>> 
>>> 
 On Aug 24, 2018, at 5:51 AM, David T. via gnucash-devel 
  wrote:
 
 Hello,
 
 Today, I had the opportunity to examine the online Help text, where I saw 
 detailed information about the Transaction Report, which has recently 
 changed radically. The information provided on the online Help clearly 
 references the new version of this report, which I surmise because I am 
 still running 2.6.21, and I do not have this version of the report.
 
 Here is the problem: there is no indication in the online resources 
 (either in the document itself, or on Gnucash.org ) 
 the version of GnuCash to which the documentation refers. This could lead 
 to user confusion, as they see help that refers to functionality that they 
 do not have.
 
 I am sure that the stock answer here will be: “GnuCash is currently on 
 release 3.2, and therefore the documentation available at Gnucash.org 
  reflects the current release.” I respect that. 
 
 However, at any given time, there will be people who choose for one reason 
 or another not to upgrade to the latest and greatest version—or more 
 problematically, are unaware that they are not running the latest version. 
 These users would benefit from being informed *somewhere* that the 
 documentation that they are consulting is for a particular version. Is 
 there some way to add the version number to the header of the 
 documentation pages? (The footer is also an option, but is less preferable 
 online since the footer is often well off screen, and may not be noticed 
 by a distressed user trying to figure out a problem). If the version 
 covered were presented on screen on every page, then the user would have a 
 clear reminder of this.
>>> 
>>> David,
>>> 
>>> Sure there is.
>>> 
>>> On https://www.gnucash.org/docs.phtml there’s a huge header above each set 
>>> of document links: "GnuCash v3 (current stable release)”, “GnuCash v2.6 
>>> (old stable release)”,
>>> “Nightly Documentation Builds”, and “Older GnuCash Documentation”.
>> 
>> You overlook the large section above this which prominently proclaims the 
>> "two major 

Re: [GNC-dev] Documentation Version Display

[Adrien Monteleone]

David,

I agree the pages should have both the document title (per another thread) and 
the version either in the header or footer.

But I can’t fathom clicking the ‘main’ documentation link and thinking that I’m 
getting anything other than the most current version. If I knew I was running 
an older version of the software and slightly down the page I see a link for 
documentation for that version, I’m going to grab that one instead, making a 
fairly safe assumption that the main link isn’t for me.

The only solution I can think of for this situation is to remove those two 
links at the top of the page and users will then click the links for their 
chosen version. (with each already well labeled) Adding the version to those 
links is, to me, unnecessary clutter. (links should be as concise and 
accurately descriptive as possible, and changing that link text each release 
will reduce search juice for those links.)

Regards,
Adrien

> On Aug 24, 2018, at 12:03 PM, David T. via gnucash-devel 
>  wrote:
> 
> John, 
> 
> 
>> On Aug 24, 2018, at 10:57 AM, John Ralls  wrote:
>> 
>> 
>> 
>>> On Aug 24, 2018, at 5:51 AM, David T. via gnucash-devel 
>>>  wrote:
>>> 
>>> Hello,
>>> 
>>> Today, I had the opportunity to examine the online Help text, where I saw 
>>> detailed information about the Transaction Report, which has recently 
>>> changed radically. The information provided on the online Help clearly 
>>> references the new version of this report, which I surmise because I am 
>>> still running 2.6.21, and I do not have this version of the report.
>>> 
>>> Here is the problem: there is no indication in the online resources (either 
>>> in the document itself, or on Gnucash.org ) the 
>>> version of GnuCash to which the documentation refers. This could lead to 
>>> user confusion, as they see help that refers to functionality that they do 
>>> not have.
>>> 
>>> I am sure that the stock answer here will be: “GnuCash is currently on 
>>> release 3.2, and therefore the documentation available at Gnucash.org 
>>>  reflects the current release.” I respect that. 
>>> 
>>> However, at any given time, there will be people who choose for one reason 
>>> or another not to upgrade to the latest and greatest version—or more 
>>> problematically, are unaware that they are not running the latest version. 
>>> These users would benefit from being informed *somewhere* that the 
>>> documentation that they are consulting is for a particular version. Is 
>>> there some way to add the version number to the header of the documentation 
>>> pages? (The footer is also an option, but is less preferable online since 
>>> the footer is often well off screen, and may not be noticed by a distressed 
>>> user trying to figure out a problem). If the version covered were presented 
>>> on screen on every page, then the user would have a clear reminder of this.
>> 
>> David,
>> 
>> Sure there is.
>> 
>> On https://www.gnucash.org/docs.phtml there’s a huge header above each set 
>> of document links: "GnuCash v3 (current stable release)”, “GnuCash v2.6 (old 
>> stable release)”,
>> “Nightly Documentation Builds”, and “Older GnuCash Documentation”.
> 
> You overlook the large section above this which prominently proclaims the 
> "two major GnuCash documentation packages” and provides direct links to each 
> of these ***without making any statement of version***. Moreover, the 
> structure of the page would imply that the documents behind *these* links are 
> somehow different from the ones beneath the "current stable release” header. 
> Perhaps the ones at the top are newer and better? It’s difficult to tell. 
> I’ll note that the links behind these entries even differ, making it 
> practically speaking impossible for a user to know whether these two 
> documents are in fact the same. I would finally suggest that “current stable 
> release” is not as universal a term as many in this community think it is. I 
> believe that many users wouldn’t know what it signifies.
> 
> 
>> 
>> Once you’re browsing the document, go to “About this Document” from the 
>> table of contents. After “Legal Notice” and “Feedback” you’ll find 
>> “History”, the top entry of which indicates the exact release for which the 
>> documentation applies.
> 
> The About this document appears only on the main TOC page. What about the 
> rest of the document? Users don’t always access our online help via the main 
> TOC.
> 
>> 
>> Of course it’s possible to add the version into the header. I suppose the 
>> simplest would be to change the chapter titles e.g. “Chapter 4. GnuCash 
>> Windows & Menus Overview” to “Chapter 4. GnuCash v3.2  Windows & Menus 
>> Overview”, just change the chapter title from 
>>  Windows  Menus Overview
>> to
>>   Windows  Menus Overview
>> Chapter titles (“Getting Started”) that don’t include the application tag 
>> would need to be reworded, e.g. “Getting Started with GnuCash 3.2”.
> 
> How hard would it 

Re: [GNC-dev] Documentation Version Display

[D via gnucash-devel]

On August 24, 2018, at 2:11 PM, John Ralls  wrote:

>
>
>On Aug 24, 2018, at 10:49 AM, David T.  wrote:
>
>On Aug 24, 2018, at 1:35 PM, John Ralls  wrote:
>
>On Aug 24, 2018, at 10:03 AM, David T.  wrote:
>
>John, 
>On Aug 24, 2018, at 10:57 AM, John Ralls  wrote:
>On Aug 24, 2018, at 5:51 AM, David T. via gnucash-devel 
> wrote:
>Hello,
>Today, I had the opportunity to examine the online Help text, where I saw 
>detailed information about the Transaction Report, which has recently changed 
>radically. The information provided on the online Help clearly references the 
>new version of this report, which I surmise because I am still running 2.6.21, 
>and I do not have this version of the report.
>Here is the problem: there is no indication in the online resources (either in 
>the document itself, or on Gnucash.org ) the version of 
>GnuCash to which the documentation refers. This could lead to user confusion, 
>as they see help that refers to functionality that they do not have.
>I am sure that the stock answer here will be: “GnuCash is currently on release 
>3.2, and therefore the documentation available at Gnucash.org 
> reflects the current release.” I respect that. 
>However, at any given time, there will be people who choose for one reason or 
>another not to upgrade to the latest and greatest version—or more 
>problematically, are unaware that they are not running the latest version. 
>These users would benefit from being informed *somewhere* that the 
>documentation that they are consulting is for a particular version. Is there 
>some way to add the version number to the header of the documentation pages? 
>(The footer is also an option, but is less preferable online since the footer 
>is often well off screen, and may not be noticed by a distressed user trying 
>to figure out a problem). If the version covered were presented on screen on 
>every page, then the user would have a clear reminder of this.
>David,
>Sure there is.
>On https://www.gnucash.org/docs.phtml there’s a huge header above each set of 
>document links: "GnuCash v3 (current stable release)”, “GnuCash v2.6 (old 
>stable release)”,
>“Nightly Documentation Builds”, and “Older GnuCash Documentation”.
>You overlook the large section above this which prominently proclaims the "two 
>major GnuCash documentation packages” and provides direct links to each of 
>these ***without making any statement of version***. Moreover, the structure 
>of the page would imply that the documents behind *these* links are somehow 
>different from the ones beneath the "current stable release” header. Perhaps 
>the ones at the top are newer and better? It’s difficult to tell. I’ll note 
>that the links behind these entries even differ, making it practically 
>speaking impossible for a user to know whether these two documents are in fact 
>the same. I would finally suggest that “current stable release” is not as 
>universal a term as many in this community think it is. I believe that many 
>users wouldn’t know what it signifies.
>Once you’re browsing the document, go to “About this Document” from the table 
>of contents. After “Legal Notice” and “Feedback” you’ll find “History”, the 
>top entry of which indicates the exact release for which the documentation 
>applies.
>The About this document appears only on the main TOC page. What about the rest 
>of the document? Users don’t always access our online help via the main TOC.
>Of course it’s possible to add the version into the header. I suppose the 
>simplest would be to change the chapter titles e.g. “Chapter 4. GnuCash 
>Windows & Menus Overview” to “Chapter 4. GnuCash v3.2  Windows & Menus 
>Overview”, just change the chapter title from 
> Windows  Menus Overview
>to
>  Windows  Menus Overview
>Chapter titles (“Getting Started”) that don’t include the application tag 
>would need to be reworded, e.g. “Getting Started with GnuCash 3.2”.
>How hard would it be to have each header get a second line with  
>programmatically added during the generation process?
>Chapter 4. GnuCash Windows & Menus Overview
>v3.2
>
>David,
>
>Good point about the top two links. I’ve modified them to be versioned. I’ll 
>add some clarifying text after I figure out how to not break the translations 
>in the process.
>
>The header line would be a third in most cases, the first being the section, 
>see e.g. https://www.gnucash.org/docs/v3/C/gnucash-help/acct-create.html. I 
>think that would be pretty ugly. Note that in light of your objection that 
>users don’t always access the online help via the main ToC that there are also 
>mid-page anchors; users going there (often via context help) won’t see either 
>the header or the footer. OTOH unless the packager has screwed up, the help 
>accessed via context help should be the version associated with the GnuCash 
>version being used.
>
>Regards,
>
>John Ralls
>
>John,
>
>I see your point about adding Yet Another Line to the header. What about 

Re: [GNC-dev] Documentation Version Display

[John Ralls]

> On Aug 24, 2018, at 10:49 AM, David T.  wrote:
> 
> 
> 
>> On Aug 24, 2018, at 1:35 PM, John Ralls > > wrote:
>> 
>> 
>> 
>>> On Aug 24, 2018, at 10:03 AM, David T. >> > wrote:
>>> 
>>> John, 
>>> 
>>> 
 On Aug 24, 2018, at 10:57 AM, John Ralls >>> > wrote:
 
 
 
> On Aug 24, 2018, at 5:51 AM, David T. via gnucash-devel 
> mailto:gnucash-devel@gnucash.org>> wrote:
> 
> Hello,
> 
> Today, I had the opportunity to examine the online Help text, where I saw 
> detailed information about the Transaction Report, which has recently 
> changed radically. The information provided on the online Help clearly 
> references the new version of this report, which I surmise because I am 
> still running 2.6.21, and I do not have this version of the report.
> 
> Here is the problem: there is no indication in the online resources 
> (either in the document itself, or on Gnucash.org  
> >) the version of GnuCash to 
> which the documentation refers. This could lead to user confusion, as 
> they see help that refers to functionality that they do not have.
> 
> I am sure that the stock answer here will be: “GnuCash is currently on 
> release 3.2, and therefore the documentation available at Gnucash.org 
>  > 
> reflects the current release.” I respect that. 
> 
> However, at any given time, there will be people who choose for one 
> reason or another not to upgrade to the latest and greatest version—or 
> more problematically, are unaware that they are not running the latest 
> version. These users would benefit from being informed *somewhere* that 
> the documentation that they are consulting is for a particular version. 
> Is there some way to add the version number to the header of the 
> documentation pages? (The footer is also an option, but is less 
> preferable online since the footer is often well off screen, and may not 
> be noticed by a distressed user trying to figure out a problem). If the 
> version covered were presented on screen on every page, then the user 
> would have a clear reminder of this.
 
 David,
 
 Sure there is.
 
 On https://www.gnucash.org/docs.phtml  
 there’s a huge header above each set of document links: "GnuCash v3 
 (current stable release)”, “GnuCash v2.6 (old stable release)”,
 “Nightly Documentation Builds”, and “Older GnuCash Documentation”.
>>> 
>>> You overlook the large section above this which prominently proclaims the 
>>> "two major GnuCash documentation packages” and provides direct links to 
>>> each of these ***without making any statement of version***. Moreover, the 
>>> structure of the page would imply that the documents behind *these* links 
>>> are somehow different from the ones beneath the "current stable release” 
>>> header. Perhaps the ones at the top are newer and better? It’s difficult to 
>>> tell. I’ll note that the links behind these entries even differ, making it 
>>> practically speaking impossible for a user to know whether these two 
>>> documents are in fact the same. I would finally suggest that “current 
>>> stable release” is not as universal a term as many in this community think 
>>> it is. I believe that many users wouldn’t know what it signifies.
>>> 
>>> 
 
 Once you’re browsing the document, go to “About this Document” from the 
 table of contents. After “Legal Notice” and “Feedback” you’ll find 
 “History”, the top entry of which indicates the exact release for which 
 the documentation applies.
>>> 
>>> The About this document appears only on the main TOC page. What about the 
>>> rest of the document? Users don’t always access our online help via the 
>>> main TOC.
>>> 
 
 Of course it’s possible to add the version into the header. I suppose the 
 simplest would be to change the chapter titles e.g. “Chapter 4. GnuCash 
 Windows & Menus Overview” to “Chapter 4. GnuCash v3.2  Windows & Menus 
 Overview”, just change the chapter title from 
  Windows  Menus Overview
 to
   Windows  Menus Overview
 Chapter titles (“Getting Started”) that don’t include the application tag 
 would need to be reworded, e.g. “Getting Started with GnuCash 3.2”.
>>> 
>>> How hard would it be to have each header get a second line with 
>>>  programmatically added during the generation process?
>>> 
>>> Chapter 4. GnuCash Windows & Menus Overview
>>> v3.2
>> 
>> David,
>> 
>> Good point about the top two links. I’ve modified them to be versioned. I’ll 
>> add some clarifying text after I figure out how to not break the 
>> translations in the process.
>> 
>> The header line would be a third 

Re: [GNC-dev] Documentation Version Display

[David T. via gnucash-devel]

> On Aug 24, 2018, at 1:35 PM, John Ralls  wrote:
> 
> 
> 
>> On Aug 24, 2018, at 10:03 AM, David T. > > wrote:
>> 
>> John, 
>> 
>> 
>>> On Aug 24, 2018, at 10:57 AM, John Ralls >> > wrote:
>>> 
>>> 
>>> 
 On Aug 24, 2018, at 5:51 AM, David T. via gnucash-devel 
 mailto:gnucash-devel@gnucash.org>> wrote:
 
 Hello,
 
 Today, I had the opportunity to examine the online Help text, where I saw 
 detailed information about the Transaction Report, which has recently 
 changed radically. The information provided on the online Help clearly 
 references the new version of this report, which I surmise because I am 
 still running 2.6.21, and I do not have this version of the report.
 
 Here is the problem: there is no indication in the online resources 
 (either in the document itself, or on Gnucash.org  
 >) the version of GnuCash to 
 which the documentation refers. This could lead to user confusion, as they 
 see help that refers to functionality that they do not have.
 
 I am sure that the stock answer here will be: “GnuCash is currently on 
 release 3.2, and therefore the documentation available at Gnucash.org 
  > reflects 
 the current release.” I respect that. 
 
 However, at any given time, there will be people who choose for one reason 
 or another not to upgrade to the latest and greatest version—or more 
 problematically, are unaware that they are not running the latest version. 
 These users would benefit from being informed *somewhere* that the 
 documentation that they are consulting is for a particular version. Is 
 there some way to add the version number to the header of the 
 documentation pages? (The footer is also an option, but is less preferable 
 online since the footer is often well off screen, and may not be noticed 
 by a distressed user trying to figure out a problem). If the version 
 covered were presented on screen on every page, then the user would have a 
 clear reminder of this.
>>> 
>>> David,
>>> 
>>> Sure there is.
>>> 
>>> On https://www.gnucash.org/docs.phtml  
>>> there’s a huge header above each set of document links: "GnuCash v3 
>>> (current stable release)”, “GnuCash v2.6 (old stable release)”,
>>> “Nightly Documentation Builds”, and “Older GnuCash Documentation”.
>> 
>> You overlook the large section above this which prominently proclaims the 
>> "two major GnuCash documentation packages” and provides direct links to each 
>> of these ***without making any statement of version***. Moreover, the 
>> structure of the page would imply that the documents behind *these* links 
>> are somehow different from the ones beneath the "current stable release” 
>> header. Perhaps the ones at the top are newer and better? It’s difficult to 
>> tell. I’ll note that the links behind these entries even differ, making it 
>> practically speaking impossible for a user to know whether these two 
>> documents are in fact the same. I would finally suggest that “current stable 
>> release” is not as universal a term as many in this community think it is. I 
>> believe that many users wouldn’t know what it signifies.
>> 
>> 
>>> 
>>> Once you’re browsing the document, go to “About this Document” from the 
>>> table of contents. After “Legal Notice” and “Feedback” you’ll find 
>>> “History”, the top entry of which indicates the exact release for which the 
>>> documentation applies.
>> 
>> The About this document appears only on the main TOC page. What about the 
>> rest of the document? Users don’t always access our online help via the main 
>> TOC.
>> 
>>> 
>>> Of course it’s possible to add the version into the header. I suppose the 
>>> simplest would be to change the chapter titles e.g. “Chapter 4. GnuCash 
>>> Windows & Menus Overview” to “Chapter 4. GnuCash v3.2  Windows & Menus 
>>> Overview”, just change the chapter title from 
>>>  Windows  Menus Overview
>>> to
>>>   Windows  Menus Overview
>>> Chapter titles (“Getting Started”) that don’t include the application tag 
>>> would need to be reworded, e.g. “Getting Started with GnuCash 3.2”.
>> 
>> How hard would it be to have each header get a second line with  
>> programmatically added during the generation process?
>> 
>> Chapter 4. GnuCash Windows & Menus Overview
>> v3.2
> 
> David,
> 
> Good point about the top two links. I’ve modified them to be versioned. I’ll 
> add some clarifying text after I figure out how to not break the translations 
> in the process.
> 
> The header line would be a third in most cases, the first being the section, 
> see e.g. https://www.gnucash.org/docs/v3/C/gnucash-help/acct-create.html 
> . I 

Re: [GNC-dev] [Gnucash/gnucash-docs] Adding reconciliation to glossary (#110)

[John Ralls]

> On Aug 24, 2018, at 10:18 AM, David T. via gnucash-devel 
>  wrote:
> 
> Thanks for the hand-holding…
> 
> Round 3. It looks like this one is on the right branch…
> 
> Now, as for whether this process is easier than the older way, I am not 
> entirely convinced. The elimination of the extra layer of maintaining the 
> local repository and development platform is likely to make the web-edit 
> process more generally accessible, however.
> 
> There still remains the issue of needing to muck around with DocBook XML 
> tagging, but as I have said before, that hasn’t my main barrier to 
> contribution. It would be nice if a writer could do their edits in a word 
> processor of choice and then pump out valid DocBook markup for inclusion in 
> the docs.

That would be nice indeed, but the only such solution that I’m aware of is an 
old plugin for LibreOffice and it doesn’t work very well; as I said earlier the 
pandoc pre- and post-processing approach doesn’t round-trip very well either.

We could, I suppose, switch to docx format for the document source and use 
either pandoc or a custom xslt stylesheet to convert that to DocBook, but I 
worry that different word processors or even different versions of the same 
word processor might make a bunch of extraneous changes to the document that 
are invisible in the word processor display but would make for ugly change sets.

Regards,
John Ralls

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

Re: [GNC-dev] Documentation Version Display

[John Ralls]

> On Aug 24, 2018, at 10:03 AM, David T.  wrote:
> 
> John, 
> 
> 
>> On Aug 24, 2018, at 10:57 AM, John Ralls  wrote:
>> 
>> 
>> 
>>> On Aug 24, 2018, at 5:51 AM, David T. via gnucash-devel 
>>>  wrote:
>>> 
>>> Hello,
>>> 
>>> Today, I had the opportunity to examine the online Help text, where I saw 
>>> detailed information about the Transaction Report, which has recently 
>>> changed radically. The information provided on the online Help clearly 
>>> references the new version of this report, which I surmise because I am 
>>> still running 2.6.21, and I do not have this version of the report.
>>> 
>>> Here is the problem: there is no indication in the online resources (either 
>>> in the document itself, or on Gnucash.org ) the 
>>> version of GnuCash to which the documentation refers. This could lead to 
>>> user confusion, as they see help that refers to functionality that they do 
>>> not have.
>>> 
>>> I am sure that the stock answer here will be: “GnuCash is currently on 
>>> release 3.2, and therefore the documentation available at Gnucash.org 
>>>  reflects the current release.” I respect that. 
>>> 
>>> However, at any given time, there will be people who choose for one reason 
>>> or another not to upgrade to the latest and greatest version—or more 
>>> problematically, are unaware that they are not running the latest version. 
>>> These users would benefit from being informed *somewhere* that the 
>>> documentation that they are consulting is for a particular version. Is 
>>> there some way to add the version number to the header of the documentation 
>>> pages? (The footer is also an option, but is less preferable online since 
>>> the footer is often well off screen, and may not be noticed by a distressed 
>>> user trying to figure out a problem). If the version covered were presented 
>>> on screen on every page, then the user would have a clear reminder of this.
>> 
>> David,
>> 
>> Sure there is.
>> 
>> On https://www.gnucash.org/docs.phtml there’s a huge header above each set 
>> of document links: "GnuCash v3 (current stable release)”, “GnuCash v2.6 (old 
>> stable release)”,
>> “Nightly Documentation Builds”, and “Older GnuCash Documentation”.
> 
> You overlook the large section above this which prominently proclaims the 
> "two major GnuCash documentation packages” and provides direct links to each 
> of these ***without making any statement of version***. Moreover, the 
> structure of the page would imply that the documents behind *these* links are 
> somehow different from the ones beneath the "current stable release” header. 
> Perhaps the ones at the top are newer and better? It’s difficult to tell. 
> I’ll note that the links behind these entries even differ, making it 
> practically speaking impossible for a user to know whether these two 
> documents are in fact the same. I would finally suggest that “current stable 
> release” is not as universal a term as many in this community think it is. I 
> believe that many users wouldn’t know what it signifies.
> 
> 
>> 
>> Once you’re browsing the document, go to “About this Document” from the 
>> table of contents. After “Legal Notice” and “Feedback” you’ll find 
>> “History”, the top entry of which indicates the exact release for which the 
>> documentation applies.
> 
> The About this document appears only on the main TOC page. What about the 
> rest of the document? Users don’t always access our online help via the main 
> TOC.
> 
>> 
>> Of course it’s possible to add the version into the header. I suppose the 
>> simplest would be to change the chapter titles e.g. “Chapter 4. GnuCash 
>> Windows & Menus Overview” to “Chapter 4. GnuCash v3.2  Windows & Menus 
>> Overview”, just change the chapter title from 
>>  Windows  Menus Overview
>> to
>>   Windows  Menus Overview
>> Chapter titles (“Getting Started”) that don’t include the application tag 
>> would need to be reworded, e.g. “Getting Started with GnuCash 3.2”.
> 
> How hard would it be to have each header get a second line with  
> programmatically added during the generation process?
> 
> Chapter 4. GnuCash Windows & Menus Overview
> v3.2

David,

Good point about the top two links. I’ve modified them to be versioned. I’ll 
add some clarifying text after I figure out how to not break the translations 
in the process.

The header line would be a third in most cases, the first being the section, 
see e.g. https://www.gnucash.org/docs/v3/C/gnucash-help/acct-create.html. I 
think that would be pretty ugly. Note that in light of your objection that 
users don’t always access the online help via the main ToC that there are also 
mid-page anchors; users going there (often via context help) won’t see either 
the header or the footer. OTOH unless the packager has screwed up, the help 
accessed via context help should be the version associated with the GnuCash 
version being used.

Regards,
John Ralls

Re: [GNC-dev] [Gnucash/gnucash-docs] Adding reconciliation to glossary (#110)

[David T. via gnucash-devel]

Thanks for the hand-holding…

Round 3. It looks like this one is on the right branch…

Now, as for whether this process is easier than the older way, I am not 
entirely convinced. The elimination of the extra layer of maintaining the local 
repository and development platform is likely to make the web-edit process more 
generally accessible, however.

There still remains the issue of needing to muck around with DocBook XML 
tagging, but as I have said before, that hasn’t my main barrier to 
contribution. It would be nice if a writer could do their edits in a word 
processor of choice and then pump out valid DocBook markup for inclusion in the 
docs.

David

> On Aug 24, 2018, at 12:52 PM, Geert Janssens  
> wrote:
> 
> Op vrijdag 24 augustus 2018 18:13:46 CEST schreef David T.:
>> Geert,
>> 
>> I went ahead and closed the PR.
>> 
>> First problem: once I closed the PR, I could not locate the changes I made;
>> there doesn’t appear to be a way to locate those changes. Did Github delete
>> them altogether? Oh, wait. I see the changes in the Closed PR section,
>> although I don’t know how I leverage that.
>> 
> The changes are still in your own fork. I suppose you were still looking in 
> the Gnucash/gnucash-docs repository instead of sunfish62/gnucash-docs as you 
> did see the closed PR.
> 
> If you go to your own fork under the code tab, here is the dropdown box named 
> "Branch" with the name of the currently selected branch. If you click on it 
> you will also find your "Bug-791169---Add-reconciliation-definition". If you 
> click on that one, your original commit will re-appear.
> 
>> In this case, the change was pretty simple, so I just recreated it from
>> scratch (I probably would be much crankier if the changes were more
>> substantial!). I went to my fork, (re) added my changes, clicked the Commit
>> and create PR option. I named the branch bug-791169 and gave the commit the
>> name “Bug 791169 - Adding Reconciliation definition to Glossary” [BTW,
>> github tells me that making my commit name longer than 50 characters shows
>> me to be the amateur I am].
> 
> Huh, that makes me an amateur equally, because I don't check the length of 
> the 
> name either when committing changes directly from the command line :)
> Git doesn't complain about that, only github does...
> 
>> 
>> Now, I have a PR against my own fork. I would rather issue the PR against
>> Gnucash/gnucash-docs, but don’t see how to get there.
>> 
> I suppose this is because you selected the wrong base fork while generating 
> the pull request. The names are a bit confusing I admit. But the direction of 
> the arrow between the forks should give a clue:
> you want changes from the repository on the right to be included in the 
> repository on the left (no doubt this interface was made by someone whose 
> natural language reads from right to left...).
> 
> So you can
> 1. close the PR against your own repo
> 2. ensure you're in your own repo
> 3. select the branch with your commit (that should now be "bug-791169") 
> 4. start a PR. This time make sure the left-hand side fork is Gnucash/gnucash-
> docs, with branch maint and the right-hand side fork is your repo and branch.
> 
>> Kinks in the hose!
>> 
> We're working on ironing them out.
> 
> Geert
> 
> 

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

Re: [GNC-dev] Documentation Version Display

[Adrien Monteleone]

Without cluttering up titles and chapter names, utilizing the footer of each 
page to include the version number would work as well.

Regards,
Adrien

> On Aug 24, 2018, at 9:57 AM, John Ralls  wrote:
> 
> 
> 
>> On Aug 24, 2018, at 5:51 AM, David T. via gnucash-devel 
>>  wrote:
>> 
>> Hello,
>> 
>> Today, I had the opportunity to examine the online Help text, where I saw 
>> detailed information about the Transaction Report, which has recently 
>> changed radically. The information provided on the online Help clearly 
>> references the new version of this report, which I surmise because I am 
>> still running 2.6.21, and I do not have this version of the report.
>> 
>> Here is the problem: there is no indication in the online resources (either 
>> in the document itself, or on Gnucash.org ) the version 
>> of GnuCash to which the documentation refers. This could lead to user 
>> confusion, as they see help that refers to functionality that they do not 
>> have.
>> 
>> I am sure that the stock answer here will be: “GnuCash is currently on 
>> release 3.2, and therefore the documentation available at Gnucash.org 
>>  reflects the current release.” I respect that. 
>> 
>> However, at any given time, there will be people who choose for one reason 
>> or another not to upgrade to the latest and greatest version—or more 
>> problematically, are unaware that they are not running the latest version. 
>> These users would benefit from being informed *somewhere* that the 
>> documentation that they are consulting is for a particular version. Is there 
>> some way to add the version number to the header of the documentation pages? 
>> (The footer is also an option, but is less preferable online since the 
>> footer is often well off screen, and may not be noticed by a distressed user 
>> trying to figure out a problem). If the version covered were presented on 
>> screen on every page, then the user would have a clear reminder of this.
> 
> David,
> 
> Sure there is.
> 
> On https://www.gnucash.org/docs.phtml there’s a huge header above each set of 
> document links: "GnuCash v3 (current stable release)”, “GnuCash v2.6 (old 
> stable release)”,
> “Nightly Documentation Builds”, and “Older GnuCash Documentation”.
> 
> Once you’re browsing the document, go to “About this Document” from the table 
> of contents. After “Legal Notice” and “Feedback” you’ll find “History”, the 
> top entry of which indicates the exact release for which the documentation 
> applies.
> 
> Of course it’s possible to add the version into the header. I suppose the 
> simplest would be to change the chapter titles e.g. “Chapter 4. GnuCash 
> Windows & Menus Overview” to “Chapter 4. GnuCash v3.2  Windows & Menus 
> Overview”, just change the chapter title from 
>  Windows  Menus Overview
> to
>   Windows  Menus Overview
>  Chapter titles (“Getting Started”) that don’t include the application tag 
> would need to be reworded, e.g. “Getting Started with GnuCash 3.2”.
> 
> 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] [Gnucash/gnucash-docs] Adding reconciliation to glossary (#110)

[David T. via gnucash-devel]

Geert,

I went ahead and closed the PR. 

First problem: once I closed the PR, I could not locate the changes I made; 
there doesn’t appear to be a way to locate those changes. Did Github delete 
them altogether? Oh, wait. I see the changes in the Closed PR section, although 
I don’t know how I leverage that.

In this case, the change was pretty simple, so I just recreated it from scratch 
(I probably would be much crankier if the changes were more substantial!). I 
went to my fork, (re) added my changes, clicked the Commit and create PR 
option. I named the branch bug-791169 and gave the commit the name “Bug 791169 
- Adding Reconciliation definition to Glossary” [BTW, github tells me that 
making my commit name longer than 50 characters shows me to be the amateur I 
am].

Now, I have a PR against my own fork. I would rather issue the PR against 
Gnucash/gnucash-docs, but don’t see how to get there.

Kinks in the hose!

David

> On Aug 24, 2018, at 11:08 AM, Geert Janssens  > wrote:
> 
> Thanks David to run the experiment of working directly on github.
> 
> That allows me to write my review there as well :)
> 
> I have two remarks:
> 
> We generally ask "commits" to reference the bug they fix if there is one. I 
> see you have chosen to reference the bug in your branch name instead. The 
> best way to do this is to use the bug and bug title as commit title (the 
> first field in the "Commit changes" frame on the edit page).
> Any further clarifications or comments can be added in the second field.
> Your PR is crossing branches. That is, you created your commit starting from 
> the maint branch (good, as this change is useful for gnucash 3.x and up) and 
> then created a PR against master. That should be avoided.
> So even though the github interface is cleaner a minimal understanding of git 
> branches is still needed when unsing the integrated editor. This is in no way 
> meant to comment on your effort. Rather I'm using your experiment to draw 
> conclusions and discover pitfalls.
> 
> Do you want to continue the experiment and see if you can correct this ?
> I don't think you can change the commit message unless you redo the commit. 
> You don't have to, I'll do so when pulling your PR.
> However you can test how hard you feel it is to fix the PR to be against the 
> proper branch. If you want to, the way to do so is to close this PR, go back 
> to your "Bug-791169---Add-Reconciliation-definition" branch and create a new 
> PR, this time against the maint branch.
> 
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub 
> , or 
> mute the thread 
> .
> 

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

Re: [GNC-dev] Alpha Vantage as Data Source for Finance::Quote (F::Q)

[John Ralls]

> On Aug 23, 2018, at 6:58 PM, AlphaVantage Support  
> wrote:
> 
> Hello Team GnuCash,
> 
> Greetings from Team Alpha Vantage.
> 
> First of all, thank you so much for using Alpha Vantage as a data source
> for the *Finance::Quote (F::Q) *feature in GnuCash. We are thrilled to be
> part of such a groundbreaking project!
> 
> To better serve the GnuCash community, we are happy to provide a generous
> API rate limit for GnuCash users at a significantly discounted price
> compared to that of our standard premium API key
> . Our mission is to democratize
> access to financial market data and would be honored to join forces with
> you along the way.
> 
> Could you please kindly advise on how to best relay the information to the
> GnuCash users?

This is a good start, many of them read this list, but we have several lists, 
see https://wiki.gnucash.org/wiki/Mailing_Lists 
, and of course not all users read 
any of the lists.

We can easily make an announcement on our website and add instructions to our 
wiki on how to get “GnuCash pricing”, just reply with the information.

Finance::Quote is actually a perl module available from CPAN and used by a 
number of FOSS finance projects. You can find its code at 
https://github.com/finance-quote/finance-quote; you’ll be particularly 
interested in 
https://github.com/finance-quote/finance-quote/blob/master/lib/Finance/Quote/AlphaVantage.pm.
 I’ve copied Erik Colson, the Finance::Quote developer on this reply.

The current way F::Q retrieves quotes from Alpha Vantage isn’t optimal for 
either end: Because your batch-quote facility is limited to US markets during 
trading hours he’s using historical quotes, one at a time, and throwing away 
most of the data since he only wants the latest one. Perhaps if you worked 
together you could create a custom API to your service that would provide 
exactly what F::Q needs and associate special F::Q API keys that can access 
only that API. That would allow you to minimize your expense in supporting F::Q 
users and dissuade folks who don’t use Finance::Quote from availing themselves 
of the F::Q discounted price.

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

Re: [GNC-dev] Documentation Version Display

[John Ralls]

> On Aug 24, 2018, at 5:51 AM, David T. via gnucash-devel 
>  wrote:
> 
> Hello,
> 
> Today, I had the opportunity to examine the online Help text, where I saw 
> detailed information about the Transaction Report, which has recently changed 
> radically. The information provided on the online Help clearly references the 
> new version of this report, which I surmise because I am still running 
> 2.6.21, and I do not have this version of the report.
> 
> Here is the problem: there is no indication in the online resources (either 
> in the document itself, or on Gnucash.org ) the version 
> of GnuCash to which the documentation refers. This could lead to user 
> confusion, as they see help that refers to functionality that they do not 
> have.
> 
> I am sure that the stock answer here will be: “GnuCash is currently on 
> release 3.2, and therefore the documentation available at Gnucash.org 
>  reflects the current release.” I respect that. 
> 
> However, at any given time, there will be people who choose for one reason or 
> another not to upgrade to the latest and greatest version—or more 
> problematically, are unaware that they are not running the latest version. 
> These users would benefit from being informed *somewhere* that the 
> documentation that they are consulting is for a particular version. Is there 
> some way to add the version number to the header of the documentation pages? 
> (The footer is also an option, but is less preferable online since the footer 
> is often well off screen, and may not be noticed by a distressed user trying 
> to figure out a problem). If the version covered were presented on screen on 
> every page, then the user would have a clear reminder of this.

David,

Sure there is.

 On https://www.gnucash.org/docs.phtml there’s a huge header above each set of 
document links: "GnuCash v3 (current stable release)”, “GnuCash v2.6 (old 
stable release)”,
“Nightly Documentation Builds”, and “Older GnuCash Documentation”.

Once you’re browsing the document, go to “About this Document” from the table 
of contents. After “Legal Notice” and “Feedback” you’ll find “History”, the top 
entry of which indicates the exact release for which the documentation applies.

Of course it’s possible to add the version into the header. I suppose the 
simplest would be to change the chapter titles e.g. “Chapter 4. GnuCash Windows 
& Menus Overview” to “Chapter 4. GnuCash v3.2  Windows & Menus Overview”, just 
change the chapter title from 
 Windows  Menus Overview
to
  Windows  Menus Overview
  Chapter titles (“Getting Started”) that don’t include the application tag 
would need to be reworded, e.g. “Getting Started with GnuCash 3.2”.

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)

[Adrien Monteleone]

> On Aug 23, 2018, at 3:00 AM, Geert Janssens  
> wrote:
> 
> 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.

Such a thing does exist.

I’ve been investigating this for some client projects that use Wordpress. There 
are plugins that interface with git for version control both for the site as a 
whole and for specific pages/posts. Wordpress itself has a revisions control 
built in, though it doesn’t work with git out of the box, you can see who made 
what changes and revert specific ones if needed.

I think I also found some time ago that Wikimedia has plugins for generating 
the needed formats.

Regards,
Adrien


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


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

[GNC-dev] Documentation Version Display

[David T. via gnucash-devel]

Hello,

Today, I had the opportunity to examine the online Help text, where I saw 
detailed information about the Transaction Report, which has recently changed 
radically. The information provided on the online Help clearly references the 
new version of this report, which I surmise because I am still running 2.6.21, 
and I do not have this version of the report.

Here is the problem: there is no indication in the online resources (either in 
the document itself, or on Gnucash.org ) the version of 
GnuCash to which the documentation refers. This could lead to user confusion, 
as they see help that refers to functionality that they do not have.

I am sure that the stock answer here will be: “GnuCash is currently on release 
3.2, and therefore the documentation available at Gnucash.org 
 reflects the current release.” I respect that. 

However, at any given time, there will be people who choose for one reason or 
another not to upgrade to the latest and greatest version—or more 
problematically, are unaware that they are not running the latest version. 
These users would benefit from being informed *somewhere* that the 
documentation that they are consulting is for a particular version. Is there 
some way to add the version number to the header of the documentation pages? 
(The footer is also an option, but is less preferable online since the footer 
is often well off screen, and may not be noticed by a distressed user trying to 
figure out a problem). If the version covered were presented on screen on every 
page, then the user would have a clear reminder of this.

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

[GNC-dev] Alpha Vantage as Data Source for Finance::Quote (F::Q)

[AlphaVantage Support]

Hello Team GnuCash,

Greetings from Team Alpha Vantage.

First of all, thank you so much for using Alpha Vantage as a data source
for the *Finance::Quote (F::Q) *feature in GnuCash. We are thrilled to be
part of such a groundbreaking project!

To better serve the GnuCash community, we are happy to provide a generous
API rate limit for GnuCash users at a significantly discounted price
compared to that of our standard premium API key
. Our mission is to democratize
access to financial market data and would be honored to join forces with
you along the way.

Could you please kindly advise on how to best relay the information to the
GnuCash users?

Thanks,

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