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

[David T. via gnucash-devel]

David,

I haven’t advocated for renaming the documents. I changed a couple of headings 
on the main wiki page.

There are two documents, 

1) the Help Manual
and
2) the Tutorial and Concepts Guide

as outlined at gnucash.org .

One might refer to them respectively as the “Help” and the “Guide”. There is no 
"Help Guide.”

As for Adrien’s question regarding what goes where, there was a discussion a 
few years back on precisely this issue—i.e., on what exactly is meant by "Help 
Manual” and “Tutorial and Concepts Guide” and what, therefore should go into 
each document. I can’t put my hands on that thread right now, but the upshot 
was that the Help was seen by most as the place that identifies “this button 
does this function” kinds of instruction, while the Guide is intended to 
contain “if I am trying to accomplish goal X, here is how to do that.” These 
categories are admittedly fuzzy around the edges. I admit that I am more of a 
“how do I do X” kind of person, and so have worked most on upgrading the Guide.

Finally, the website was redesigned  years ago, and the current 
generic addressing scheme was implemented at that time. I commented on it at 
the time, but we never came to any resolutions. I suspect some kind of batter 
and breadcrumb solution (along with a flash frying in a nice deep fryer) might 
help with navigation. When I am directing someone to a specific page in the 
documentation, I right-click the link to the page in question, and copy  the 
link. That provides the full URL.

David

> On Aug 20, 2018, at 7:52 PM, David Carlson  
> wrote:
> 
> I too am confused now.  First, I think David  > stated in the other documentation thread that the
> document names need to be clarified, and that may be part of why I am
> confused.  I think that the short names seem to be Guide and Tutorial,
> which, if they were used consistently, would work for me.  I may be wrong
> about the names.
> 
> Second, I think that there may be an alias issue, and I am not sure where I
> am sometimes because of that. In my last foray into online documentation I
> was specifically trying to get to the current stable (Release 3) version of
> the documentation, and when I repeat my itinerary as I tried to describe in
> previous posts, I do end up in pages identified as ../v3/..  So I am
> puzzled that Adrien does not seem to get to the same place, or how some of
> my previous attempts to document the trip do not seem to be leading to
> pages identified as ../v3/..
> 
> Third, I think that document title and chapter numbers do not appear on
> every page in each form of the documentation, and that has not helped me to
> keep track of where I am.
> 
> Fourth, the label on the link in the tip just below figure 4.3 of the help
> manual is named Tutorial and Concepts Guide and it does seem to point to
> the Tutorial ../v3/..section 4.2, so it seems correct for the current
> document structure.
> 
> I am not trying to rant, just document my confusion and agreement that
> simplification would be helpful.
> 
> David C
> 
> On Mon, Aug 20, 2018 at 4:30 PM, Adrien Monteleone <
> adrien.montele...@lusfiber.net> wrote:
> 
>> Hmm.. Not sure how I missed that recently. (I’ve read it before)
>> 
>> But then if it’s there, I wonder why so many questions still? Perhaps the
>> organization or presentation isn’t very discoverable? User laziness?
>> 
>> Also, I still don’t think after several years that I’m clear on the
>> difference between the Help Manual and the Tutorial & Concepts Guide. I get
>> what their names imply and I understand the explanation on the website, but
>> here is a case of info that I would expect to find in the other document.
>> This is info about the GUI itself, not ‘how to use’ GnuCash to accomplish
>> an accounting task. (which the name “Tutorial & Concepts Guide” implies and
>> even the website itself defines as the document’s function)
>> 
>> Should this be relocated to the Help Manual?
>> 
>> Regards,
>> Adrien
>> 
>>> On Aug 20, 2018, at 3:44 PM, D  wrote:
>>> 
>>> And you will find said documentation in the Guide at 2.3.3.
>>> 
>>> David
>>> 
>>> On August 20, 2018, at 2:32 PM, Derek Atkins  wrote:
>>> 
>>> 
>>> On Mon, August 20, 2018 2:20 pm, Adrien Monteleone wrote:
 Of course, that all makes sense.
 
 The other improvements, specifically how to resize columns, particularly
 the Description column I think should be documented. There are enough
 questions on the list about it to address the topic.
>>> 
>>> Absolutely!
>>> 
 Regards,
 Adrien
>>> 
 Please remember to CC this list on all your replies.
 You can do this by using Reply-To-List or Reply-All.
>>> 
>>> -derek
>>> --
>>>  Derek Atkins 617-623-3745
>>>  de...@ihtfp.com www.ihtfp.com
>>>  Computer and Internet Security Consultant
>> 
>> ___
>> gnucash-devel mailing list
>> gnucash-devel@gnucash.org
>> 

Re: [GNC-dev] Main WIki Page edit

[David T. via gnucash-devel]

OK. I have looked over this issue with an eye to clarifying the text, and I 
believe that the User Documentation section should be simplified. As currently 
written, as you all have noted, the User Documentation section includes 
different layers of content, presented at the same tier of coverage. Thus, the 
Help and Tutorial are presented alongside two wiki pages and two glossaries. 
That’s inconsistent. 

So, first up is to level things off. That means eliminating the separate 
headings for the Glossaries, the FAQ and Using Gnucash, and changing the main 
section to refer to the wiki at the same level as the Help and Tutorial. In the 
interest of helping people in dire need, I choose to retain the references to 
the FAQ and Using GnuCash pages, but as a descriptive list under the wiki in 
general (I will note that I also changed the Getting Help page to parallel this 
approach). As suggested, mention of the Glossaries isn’t particularly 
appropriate here, so I remove it altogether. [FWIW, I think the proper approach 
would be to make sure that all uses of special terminology in the wiki and the 
documentation receive reference to their glossary definitions, ideally as tool 
tips—but that solution is beyond my ability]

I also don’t like “User Documentation” since we aren’t documenting users, so I 
prefer “Documentation for Users”, which requires the following heading to be 
changed to “Documentation for Developers”

Here is my final suggestion for the section in question:

=== Documentation for Users ===
GnuCash offers two major pieces of documentation: 
* [http://www.gnucash.org/viewdoc.phtml?doc=help The Help Manual] - a quick 
reference manual for specific tasks, and
* [http://www.gnucash.org/viewdoc.phtml?doc=guide The Tutorial and Concepts 
Guide] - an in-depth guide to the concepts. It is highly recommended to read at 
least the first chapters of the guide.
The [http://www.gnucash.org/docs.phtml Documentation page on the gnucash.org 
''website''] also contains these documents in
* '''other languages:''' de, it, ja, pt; 
* '''other formats:''' ''PDF'', ''ePub'' or ''mobi''; as well as
* '''other releases:''' nightly (unstable),  previous and earlier stable 
releases.
The GnuCash wiki includes extensive information regarding all aspects of 
GnuCash, contributed by the developers and users of GnuCash. Information in the 
wiki covers a broad variety of topics, and includes detailed technical 
information, as well as information that applies to specific use cases. Of 
particular interest on the wiki are: 
* The [[FAQ|GnuCash FAQ]], which contains a collection of frequently asked 
questions about GnuCash, including administration, accounting, and glossary 
questions, and
* [[Using GnuCash]], which collects real life experiences using GnuCash. You 
may find (user) solutions here that are not covered by the documentation.

=== Documentation for Developers ===


> On Aug 18, 2018, at 8:53 AM, D via gnucash-devel  
> wrote:
> 
> The glossary entry has historically been included separately on this page. 
> When I last suggested changes for the page, it didn't occur to me to remove 
> that separate section and incorporate references to them (there are two 
> glossaries: one in the Guide, and the one on the wiki, each with slightly 
> didn't vintage) in other locations.
> 
> Incorporating these references into other sections makes sense to me. It 
> simplifies the main page structure a little, and reflects the fact that the 
> glossaries are part of the Guide and wiki, respectively.
> 
> I'll look into a rewrite, and send it in for adjustment in the next few days.
> 
> David T.
> 
> On August 18, 2018, at 7:15 AM, Adrien Monteleone 
>  wrote:
> 
> In combination with making the T glossary sentence a part the Official 
> documentation paragraph, I think the second sentence should be moved down to 
> the Developer Documentation paragraph.
> 
> Also, the following line needs a number correction:
> 
> "The Documentation page on the gnucash.org website also contains ~~this~~ 
> _these_ documents in”
> 
> I’d do either myself, but I see the main page is above my pay grade. (I’m 
> sure for very good reason)
> 
> Regards,
> Adrien
> 
>> On Aug 18, 2018, at 8:53 AM, John Ralls  wrote:
>> 
>> 
>> 
>>> On Aug 17, 2018, at 11:45 PM, David T. via gnucash-devel 
>>>  wrote:
>>> 
>>> 
>>> 
>>>> On Aug 17, 2018, at 11:29 AM, Frank H. Ellenberger 
>>>>  wrote:
>>>> 
>>>> Am 16.08.2018 um 20:37 schrieb David T. via gnucash-devel:
>>>>> Hello,
>>>>> 
>>>>> I was reviewing the Wiki today to try to figure out where a page on the 
>>>>> SQL formats might get attached, and I noticed a change to the Glossary 
>>>>> section that makes fo

Re: [GNC-dev] Main WIki Page edit

[David T. via gnucash-devel]

> On Aug 17, 2018, at 11:29 AM, Frank H. Ellenberger 
>  wrote:
> 
> Am 16.08.2018 um 20:37 schrieb David T. via gnucash-devel:
>> Hello,
>> 
>> I was reviewing the Wiki today to try to figure out where a page on the SQL 
>> formats might get attached, and I noticed a change to the Glossary section 
>> that makes for awkward English.
>> 
>> As currently entered, the section reads:
>> 
>> Above GnuCash Tutorial and Concepts Guide includes a comprehensive Glossary: 
>> [https://www.gnucash.org/docs/v2.6/C/gnucash-guide/gnc-gloss.html Released] 
>> or [https://code.gnucash.org/docs/C/gnucash-guide/gnc-gloss.html Maintainer] 
>> version.
>> 
>> However, it used to say:
>> 
>> The GnuCash Tutorial and Concepts Guide includes a comprehensive Glossary: 
>> [https://www.gnucash.org/docs/v2.6/C/gnucash-guide/gnc-gloss.html Released] 
>> or [https://code.gnucash.org/docs/C/gnucash-guide/gnc-gloss.html Maintainer] 
>> version.
>> 
>> I would like to ask that someone with edit permissions on the wiki home page 
>> to please change the word “Above” back to “The” to make the section read 
>> more idiomatically.
>> 
>> David T.
> 
> IMHO it is also bad style to have:
> The Tutorial and Concepts Guide - an in-depth guide to the concepts.
> :
> The GnuCash Tutorial and Concepts Guide includes a comprehensive
> Glossary: Released or Maintainer version.
> 

We differ in our opinion here. I stand by my recommendation.

David

> ~Frank
> 

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

Re: [GNC-dev] Wiki Home page

[David T. via gnucash-devel]

Frank,

You imply that the use of Eclipse somehow renders the documentation process 
simple enough for a user to identify a typo and get it fixed. I flat out 
disagree, and I think that using disingenuous language on the wiki home page is 
not going to change the reality: implementing a change in the documentation is 
a Process.

I still think the heading should be reverted to “Developing the Documentation”, 
and I am copying gnucash-devel as you requested.

David


> On Aug 17, 2018, at 11:23 AM, Frank H. Ellenberger 
>  wrote:
> 
> Hi David,
> 
> Am 16.08.2018 um 20:52 schrieb David T.:
>> Frank,
>> 
>> As you will see on gnucash-devel, I had reason to examine the wiki home page 
>> today, and noticed some of the changes you have implemented there over the 
>> last year or so. I wanted to discuss off list with you one of those changes.
>> 
>> You changed “Developing the Documentation” to “Improving the Documentation” 
>> with the note that “developing sounds so high-flown”. I think you’re wrong 
>> here, and I’d like you to change that back to “Developing.” 
>> 
>> Here’s why I think that:
>> 
>> IF improving the documentation simply involved opening a Word file, changing 
>> the text or formatting using a WYSIWIG editor, and saving the result, THEN 
>> I’d agree on referring to it as “Improving the Documentation.”
>> 
>> HOWEVER, it simply isn’t that easy—as outlined on our own wiki page. That 
>> page includes guidance on: the installation of several specialized software 
>> packages, the creation of accounts at github and Bugzilla, the use of 
>> version control software, the editing of DocBook XML text files, the XSLT 
>> validation of your edits, etc. etc. etc.
> 
> Using a recent Eclipse CDT bundle should have everything, which is required:
> a Git module,
> a Bugzilla connector,
> a WYSIWIG XML editor,
> a module for autotools (configuer, make, ...).
> You could ask Geert about his success with KDevelop.
> 
>> Simply put, the documentation update process *IS* complicated and 
>> “high-flown”—and to imply otherwise is misleading.
> 
> The idea behind the change:
> We should not already on the main page scare off potential contributors.
> They should decide it while reading the respective pages.
> 
> And it should also address "Hey, I found a typo."
> 
>> Please revert the heading to “Developing the Documentation.”
> 
> If you still think, it should be reverted, address it to gnucash-devel.
> 
>> Thanks,
>> David
>> 
> Regards
> Frank
> 

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

Re: [GNC-dev] Documentation update problems

[David T. via gnucash-devel]

For what it’s worth, I was able to dig out the old xmllint/xsltproc commands 
and test and view my edits. 

I’d still love to know how I’ve f**ked up my development environment so that 
the currently-sanctioned approach (make|make clean|make install|make hay while 
the sun shines) doesn’t work.

Perhaps this is another instance of not trying to teach old dogs new tricks.

David


> On Aug 16, 2018, at 11:41 PM, David T. via gnucash-devel 
>  wrote:
> 
> Hello,
> 
> If I am working on updating the documentation, it must be time for me to bang 
> my head against some command line hiccup!  Yup! Right on time.
> 
> Following my handy-dandy git cheat sheet, I’ve pulled from 
> github.com/gnucash/gnucash-docs <http://github.com/gnucash/gnucash-docs> and 
> pushed to github.com/sunfish62/gnucash-docs 
> <http://github.com/sunfish62/gnucash-docs>. I then entered all my edits to 
> ch_basics.xml and saved. 
> 
> Next, I went to the wiki 
> (https://wiki.gnucash.org/wiki/Documentation_Update_Instructions#Validate_Your_Changes
>  
> <https://wiki.gnucash.org/wiki/Documentation_Update_Instructions#Validate_Your_Changes>)
>  and found the instructions to “make check” the guide. So, in Terminal, I cd 
> to my build directory for the guide 
> (/Volumes/Media/Development/Gnucash/gnucash-docs/build/guide) and issue “make 
> clean”
> 
> This is what I get:
> 
> cd .. && /Applications/Xcode.app/Contents/Developer/usr/bin/make  am--refresh
> CDPATH="${ZSH_VERSION+.}:" && cd .. && /bin/sh 
> /Volumes/Media/Development/Gnucash/gnucash-docs/missing aclocal-1.15 
> cd .. && /bin/sh /Volumes/Media/Development/Gnucash/gnucash-docs/missing 
> automake-1.15 --gnu
> configure.ac:6: error: required file './config.guess' not found
> configure.ac:6:   'automake --add-missing' can install 'config.guess'
> configure.ac:6: error: required file './config.sub' not found
> configure.ac:6:   'automake --add-missing' can install 'config.sub'
> xmldocs.make:54: warning: shell ls ${srcdir}/${figdir}/*.png: non-POSIX 
> variable name
> xmldocs.make:54: (probably a GNU make extension)
> guide/C/Makefile.am:42:   'xmldocs.make' included from here
> xmldocs.make:85: warning: shell ls ${srcdir}/${figdir}/*.png: non-POSIX 
> variable name
> xmldocs.make:85: (probably a GNU make extension)
> guide/C/Makefile.am:42:   'xmldocs.make' included from here
> xmldocs.make:54: warning: shell ls ${srcdir}/${figdir}/*.png: non-POSIX 
> variable name
> xmldocs.make:54: (probably a GNU make extension)
> guide/de/Makefile.am:40:   'xmldocs.make' included from here
> xmldocs.make:85: warning: shell ls ${srcdir}/${figdir}/*.png: non-POSIX 
> variable name
> xmldocs.make:85: (probably a GNU make extension)
> guide/de/Makefile.am:40:   'xmldocs.make' included from here
> xmldocs.make:54: warning: shell ls ${srcdir}/${figdir}/*.png: non-POSIX 
> variable name
> xmldocs.make:54: (probably a GNU make extension)
> guide/it/Makefile.am:11:   'xmldocs.make' included from here
> xmldocs.make:85: warning: shell ls ${srcdir}/${figdir}/*.png: non-POSIX 
> variable name
> xmldocs.make:85: (probably a GNU make extension)
> guide/it/Makefile.am:11:   'xmldocs.make' included from here
> xmldocs.make:54: warning: shell ls ${srcdir}/${figdir}/*.png: non-POSIX 
> variable name
> xmldocs.make:54: (probably a GNU make extension)
> guide/ja/Makefile.am:37:   'xmldocs.make' included from here
> xmldocs.make:85: warning: shell ls ${srcdir}/${figdir}/*.png: non-POSIX 
> variable name
> xmldocs.make:85: (probably a GNU make extension)
> guide/ja/Makefile.am:37:   'xmldocs.make' included from here
> xmldocs.make:54: warning: shell ls ${srcdir}/${figdir}/*.png: non-POSIX 
> variable name
> xmldocs.make:54: (probably a GNU make extension)
> guide/pt/Makefile.am:43:   'xmldocs.make' included from here
> xmldocs.make:85: warning: shell ls ${srcdir}/${figdir}/*.png: non-POSIX 
> variable name
> xmldocs.make:85: (probably a GNU make extension)
> guide/pt/Makefile.am:43:   'xmldocs.make' included from here
> xmldocs.make:54: warning: shell ls ${srcdir}/${figdir}/*.png: non-POSIX 
> variable name
> xmldocs.make:54: (probably a GNU make extension)
> guide/ru/Makefile.am:37:   'xmldocs.make' included from here
> xmldocs.make:85: warning: shell ls ${srcdir}/${figdir}/*.png: non-POSIX 
> variable name
> xmldocs.make:85: (probably a GNU make extension)
> guide/ru/Makefile.am:37:   'xmldocs.make' included from here
> xmldocs.make:54: warning: shell ls ${srcdir}/${figdir}/*.png: non-POSIX 
> variable name
> xmldocs.make:54: (probably a GNU make extension)
> help/C/Makefile.am:33:   'xmldocs.make' included from here
> xmldocs.make:85: warning: shell ls ${srcdir}/${figdir}/*.png: non-POSIX 
> 

[GNC-dev] Documentation update problems

[David T. via gnucash-devel]

Hello,

If I am working on updating the documentation, it must be time for me to bang 
my head against some command line hiccup!  Yup! Right on time.

Following my handy-dandy git cheat sheet, I’ve pulled from 
github.com/gnucash/gnucash-docs  and 
pushed to github.com/sunfish62/gnucash-docs 
. I then entered all my edits to 
ch_basics.xml and saved. 

Next, I went to the wiki 
(https://wiki.gnucash.org/wiki/Documentation_Update_Instructions#Validate_Your_Changes
 
)
 and found the instructions to “make check” the guide. So, in Terminal, I cd to 
my build directory for the guide 
(/Volumes/Media/Development/Gnucash/gnucash-docs/build/guide) and issue “make 
clean”

This is what I get:

cd .. && /Applications/Xcode.app/Contents/Developer/usr/bin/make  am--refresh
CDPATH="${ZSH_VERSION+.}:" && cd .. && /bin/sh 
/Volumes/Media/Development/Gnucash/gnucash-docs/missing aclocal-1.15 
 cd .. && /bin/sh /Volumes/Media/Development/Gnucash/gnucash-docs/missing 
automake-1.15 --gnu
configure.ac:6: error: required file './config.guess' not found
configure.ac:6:   'automake --add-missing' can install 'config.guess'
configure.ac:6: error: required file './config.sub' not found
configure.ac:6:   'automake --add-missing' can install 'config.sub'
xmldocs.make:54: warning: shell ls ${srcdir}/${figdir}/*.png: non-POSIX 
variable name
xmldocs.make:54: (probably a GNU make extension)
guide/C/Makefile.am:42:   'xmldocs.make' included from here
xmldocs.make:85: warning: shell ls ${srcdir}/${figdir}/*.png: non-POSIX 
variable name
xmldocs.make:85: (probably a GNU make extension)
guide/C/Makefile.am:42:   'xmldocs.make' included from here
xmldocs.make:54: warning: shell ls ${srcdir}/${figdir}/*.png: non-POSIX 
variable name
xmldocs.make:54: (probably a GNU make extension)
guide/de/Makefile.am:40:   'xmldocs.make' included from here
xmldocs.make:85: warning: shell ls ${srcdir}/${figdir}/*.png: non-POSIX 
variable name
xmldocs.make:85: (probably a GNU make extension)
guide/de/Makefile.am:40:   'xmldocs.make' included from here
xmldocs.make:54: warning: shell ls ${srcdir}/${figdir}/*.png: non-POSIX 
variable name
xmldocs.make:54: (probably a GNU make extension)
guide/it/Makefile.am:11:   'xmldocs.make' included from here
xmldocs.make:85: warning: shell ls ${srcdir}/${figdir}/*.png: non-POSIX 
variable name
xmldocs.make:85: (probably a GNU make extension)
guide/it/Makefile.am:11:   'xmldocs.make' included from here
xmldocs.make:54: warning: shell ls ${srcdir}/${figdir}/*.png: non-POSIX 
variable name
xmldocs.make:54: (probably a GNU make extension)
guide/ja/Makefile.am:37:   'xmldocs.make' included from here
xmldocs.make:85: warning: shell ls ${srcdir}/${figdir}/*.png: non-POSIX 
variable name
xmldocs.make:85: (probably a GNU make extension)
guide/ja/Makefile.am:37:   'xmldocs.make' included from here
xmldocs.make:54: warning: shell ls ${srcdir}/${figdir}/*.png: non-POSIX 
variable name
xmldocs.make:54: (probably a GNU make extension)
guide/pt/Makefile.am:43:   'xmldocs.make' included from here
xmldocs.make:85: warning: shell ls ${srcdir}/${figdir}/*.png: non-POSIX 
variable name
xmldocs.make:85: (probably a GNU make extension)
guide/pt/Makefile.am:43:   'xmldocs.make' included from here
xmldocs.make:54: warning: shell ls ${srcdir}/${figdir}/*.png: non-POSIX 
variable name
xmldocs.make:54: (probably a GNU make extension)
guide/ru/Makefile.am:37:   'xmldocs.make' included from here
xmldocs.make:85: warning: shell ls ${srcdir}/${figdir}/*.png: non-POSIX 
variable name
xmldocs.make:85: (probably a GNU make extension)
guide/ru/Makefile.am:37:   'xmldocs.make' included from here
xmldocs.make:54: warning: shell ls ${srcdir}/${figdir}/*.png: non-POSIX 
variable name
xmldocs.make:54: (probably a GNU make extension)
help/C/Makefile.am:33:   'xmldocs.make' included from here
xmldocs.make:85: warning: shell ls ${srcdir}/${figdir}/*.png: non-POSIX 
variable name
xmldocs.make:85: (probably a GNU make extension)
help/C/Makefile.am:33:   'xmldocs.make' included from here
xmldocs.make:54: warning: shell ls ${srcdir}/${figdir}/*.png: non-POSIX 
variable name
xmldocs.make:54: (probably a GNU make extension)
help/de/Makefile.am:20:   'xmldocs.make' included from here
xmldocs.make:85: warning: shell ls ${srcdir}/${figdir}/*.png: non-POSIX 
variable name
xmldocs.make:85: (probably a GNU make extension)
help/de/Makefile.am:20:   'xmldocs.make' included from here
xmldocs.make:54: warning: shell ls ${srcdir}/${figdir}/*.png: non-POSIX 
variable name
xmldocs.make:54: (probably a GNU make extension)
help/it/Makefile.am:11:   'xmldocs.make' included from here
xmldocs.make:85: warning: shell ls ${srcdir}/${figdir}/*.png: non-POSIX 
variable name
xmldocs.make:85: (probably a GNU make extension)
help/it/Makefile.am:11:   'xmldocs.make' included from here
xmldocs.make:54: warning: shell ls 

[GNC-dev] Wiki Proposal

[David T. via gnucash-devel]

Sorry to bombard the list with so many messages!

As you’ve no doubt surmised, I am back to digging into the various 
documentation for GnuCash, including the Guide and the wiki. 

In reference to editing the "XML Format” wiki page, Geert mentioned preferring 
that the wiki cover information about the current release and one or two 
previous releases. 

I personally agree with that idea; it would give a clear guideline for what 
should stay, and what should be removed.

However, determining what those versions should be might be difficult for some 
of us (like me!). I think it would be useful to have a simple, public, 
statement (on the home page?) of the currently-supported versions. This 
statement could be autoupdated as new versions are released.

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

[GNC-dev] Windows Wiki page

[David T. via gnucash-devel]

Hello,

I had reason to click on the Windows wiki page 
(https://wiki.gnucash.org/wiki/Windows 
), and I think that there is a lot of 
information parked there that should be placed elsewhere or removed. I am 
hesitant to edit this page in part because I do not use Windows, and cannot 
speak from personal experience. Furthermore, I would like to get input from the 
group before I undertake a major edit on the page.

Information that should placed elsewhere includes sections 1.3, 1.4 and 1.7. 
These sections explain general functionality that should be available to all GC 
users through the FAQ. Windows-specific notes could be incorporated into the 
resulting pages.

In addition, I think the Q/A format is stilted and not helpful on this page. I 
would rewrite it as straightforward prose.

Finally, I see a lot of elements that are dated (F::Q, sections 2 and 3), and I 
see mention that issues related to older versions are moved to an Older issues 
page. They underscore the fact that such structures lend themselves to 
obsolescence, since information gets added to these structures, but is rarely 
pruned or updated. Perhaps the older issues could simply be deleted, and the 
wiki focus on providing information on the currently-supported versions?

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

[GNC-dev] Main WIki Page edit

[David T. via gnucash-devel]

Hello,

I was reviewing the Wiki today to try to figure out where a page on the SQL 
formats might get attached, and I noticed a change to the Glossary section that 
makes for awkward English.

As currently entered, the section reads:

Above GnuCash Tutorial and Concepts Guide includes a comprehensive Glossary: 
[https://www.gnucash.org/docs/v2.6/C/gnucash-guide/gnc-gloss.html Released] or 
[https://code.gnucash.org/docs/C/gnucash-guide/gnc-gloss.html Maintainer] 
version.

However, it used to say:

The GnuCash Tutorial and Concepts Guide includes a comprehensive Glossary: 
[https://www.gnucash.org/docs/v2.6/C/gnucash-guide/gnc-gloss.html Released] or 
[https://code.gnucash.org/docs/C/gnucash-guide/gnc-gloss.html Maintainer] 
version.

I would like to ask that someone with edit permissions on the wiki home page to 
please change the word “Above” back to “The” to make the section read more 
idiomatically.

David T.

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

Re: [GNC-dev] New balsheet (and P report), API considerations, and (slow?) KVP in Account.cpp

[David T. via gnucash-devel]

Hi,

I admit that I haven’t been following the details of thsi thread that closely, 
but it would seem to me that if a user has selected price source “Latest,” then 
the report will of necessity include an Unrealized Gains line in order to 
balance, as John said. I agree with his suggestion that Unrealized Gains might 
not belong in a Balance Sheet report, but I note that as a personal user of 
GnuCash, I am rather interested in the current value of my empire, ephemeral 
though it may be. I’m eager to see how rich I am Right Now! Bwa Ha Ha Ha!

Seriously, though, since “Balance Sheet” seems to be a commonly-used term in 
accounting to refer to a particular general type of report and content (I base 
this on the fact that Googling “Balance Sheet report definition” yields 
numerous accounting websites with explanations of what a balance sheet is and 
does), perhaps there could be a separately-identified and named report to give 
the armchair trader the putative value of their holdings as of a given date. 
Then the Balance Sheet could be dedicated to the real world situation (i.e., no 
need for the PriceDB at all—just use the transaction prices), while the new 
report could include unrealized gains explicitly. A descriptive name (“Trade 
Value”? “Speculative Value”? “Castles in the Sand”?) could help make clear the 
difference between the two.

David

> On Aug 16, 2018, at 7:30 AM, John Ralls  wrote:
> 
> Chris,
> 
> That’s because you used price source = “latest” which uses the most recent 
> price in the pricedb for the purchase as well as the valuation.
> 
> Regards,
> John Ralls
> 
>> On Aug 16, 2018, at 12:58 AM, Christopher Lam  
>> wrote:
>> 
>> Hi John
>> 
>> Just to be a pain again... I found a small discrepancy - (This is different 
>> from the previously noted missing-capital-gains situation)
>> 
>> if trading-accounts are enabled,
>> a single 100AAPL purchase @ $100 each dated 01/01/18
>> a new increased price $200 on 01/06/18 is recorded, 
>> price-source is 'latest' to pick up the new price
>> There's no trade sale yet -- this means 'trading gains' is $0 -- indeed the 
>> book will not have any Trading accounts yet.
>> 
>> I'd expect the balance-sheet to record the increased price as 'unrealized 
>> gain'.
>> 
>> Yet the balance-sheet just displays an increased FUNDS valuation at $20,000 
>> (i.e. total assets = $2) without a corresponding increase in 
>> right-hand-side (ie total equity+liability=$1).
>> 
>> I'd think the 'correct' balance sheet with trading-accounts enabled, 
>> *should* still report Unrealized Gains, no?
>> 
>> 
>> On 13/08/18 22:51, John Ralls wrote:
>>> 
>>> 
 On Aug 12, 2018, at 10:04 PM, Christopher Lam >>> > wrote:
 
 Hi Jralls
 
 So just wish to double check my understanding of gnucash's data format for 
 a balance-sheet on date X
 
 There are two possibilities for displaying the right-hand-side
 
 Liabilities + Equity + Retained Earnings + Trading Balances
 Liabilities + Equity + Retained Earnings + Unrealized Gains
 "Retained Earnings" should be NULL if the user has properly closed the 
 books on the balance sheet date X.
 
 In my understanding, "Trading Balances" and "Unrealized Gains" are one and 
 the same -- in balance-sheet.scm the unrealized-gain-collector is only 
 populated if book->trading-accounts setting is disabled. (btw this causes 
 a 'bug' whereby a book with 'enable-trading-accounts', but was later 
 switched to 'disable-trading-accounts' will then add both the 
 unrealized-gain-collector and the trading-balance the right-hand-side).
 
 This seems to be deconstruct current balance-sheet?
 
 (I can't seem to find any unrealized-gain issue... from using different 
 price-sources... perhaps this is beyond my understanding.)
 
 
 On 11/08/18 22:41, John Ralls wrote:
> Chris,
> 
> Remember that we’ve long advised users that they need not close their 
> books, they can run a balance sheet report for any day. IMO removing that 
> capability would be a major breakage.
> 
> I suspect that you needed to use trading accounts because you didn’t book 
> the trading gains and losses as income. Users should do that regardless 
> of using trading accounts and doing so should make it unnecessary for the 
> balance sheet report to include trading accounts.
> 
> Unrealized gains are another matter entirely and are a result of using 
> prices from the price database instead of actual cost from the 
> transaction data. IMO the balance sheet report shouldn’t be taking prices 
> from the price db and shouldn’t be able to see unrealized gains, but if 
> price source is going to be an option then an unrealized gains line flows 
> from that so that users don’t waste a bunch of time chasing an imbalance 
> caused by price differences.
> 
> 

Re: [GNC-dev] Location of XML Schema

[David T. via gnucash-devel]

Ah! Thank you! I have updated the links.

On a more substantial note: I see that this page makes significant reference to 
changes in XML implementation from version 1.9 forward. An examination of the 
page history shows that most of the content was developed in 2006. 

At this point, I believe that this information is essentially unimportant, 
since we are now at version 3.2 [2.8 in the old numeration]. My inclination 
would be to drastically reduce (or eliminate altogether) this discussion as no 
longer relevant to the user base. However, I recognize that there may be a 
desire to retain this information for historical purposes, and I put the 
question to the developer base: what would you prefer happens with the 
information on this page?

Cheers,
David

> On Aug 14, 2018, at 12:34 PM, Derek Atkins  wrote:
> 
> It moved to libgnucash/doc/...
> 
> -derek
> Sent using my mobile device. Please excuse any typos.
> On August 14, 2018 3:31:45 PM "David T."  wrote:
> 
>> Hello,
>> 
>> In preparation for writing up data storage information to address Bug 
>> 777893, I consulted the Wiki at wiki.gnucash.org/wiki/GnuCash_XML_format 
>> , and found a reference to 
>> "a non-normative RELAX NG schema for the XML file format (gnucash-v2.rnc).” 
>> Unfortunately, the link 
>> (https://github.com/Gnucash/gnucash/blob/master/src/doc/xml/gnucash-v2.rnc 
>> ) 
>> is dead, and I cannot locate it with any of my search juju.
>> 
>> Has this file gone away, and if so, could someone with better understanding 
>> of the subject correct the wiki to reflect the current state of the art?
>> 
>> Thanks!
>> 
>> David
>> ___
>> 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] Request of keeping a 2.6 branch still alive (Re: branch-2.6)

[David T. via gnucash-devel]

+1 on all fronts. Thank you Adrien.

> On Jun 3, 2018, at 10:02 AM, Adrien Monteleone 
>  wrote:
> 
> Folks,
> 
> Perhaps my comments are not wanted, or out of place, but as an active user, 
> someone who contributes a bit of assistance on the mailing list, and just 
> someone who in general helps people less knowledgable with software 
> selections and support, I have to ask, “Christian, did you consider the 
> impact on complete newbies who might stumble upon and install, for whatever 
> reason, the 2.6.x branch?” Or even someone who is still running it and 
> contemplating an upgrade? As someone who helps out mom and pop businesses 
> adopt GnuCash, the prospect of installing a full major version behind, bugs 
> and all, less functionality, et cetera, and WASTING their time would leave me 
> and them, nothing short of extremely perturbed when we eventually find out 
> there is a more recent version. (*I* know now, but *they* won’t and they 
> might not find me until afterwards, and what of others like me just entering 
> this journey?) Sure, *I* can see where it would be ’nice’ to maintain an 
> older version for certain ‘cut-off’ compatibility reasons, but those *are* 
> the reason for a fork. (really, though, your initial stated reason was a 
> compiling problem, which I though John answered adequately) I sure don’t want 
> to have to repeatedly explain to people that 2.6.x is not supported if there 
> is an ‘official’ branch in the Git repo available. (not that newbies would be 
> looking there mind you, but one thing I’ve learned with this project is you 
> can’t count on what you expect from how people ‘find’ you or install the 
> software.)
> 
> I’m not a dev so I have a less than important perspective, but perhaps you 
> should be aware, that there are some out here who aren’t devs who would not 
> be appreciative of more than one official version that wasn’t actually an 
> actively and officially supported version. I don’t know of any software 
> project where that is acceptable. (If it isn’t supported, it isn’t 
> ‘official’) It isn’t a matter of what is possible that can function or not, 
> it’s a matter of expectation of what is supported and what isn’t. If the main 
> devs don’t want to, or don’t have the resources to, support more than one 
> version, then the answer is a fork. Please consider you might be making life 
> unpleasant for more than just whatever you are willing to take one. You are 
> obligating many others and you are creating an expectation you can’t even 
> fully scope, much less fulfill. (or even at least initially be called to 
> fulfill) Others are going have to have to deal with this ‘old version’ for as 
> long as it exists, not just you.
> 
> Regards,
> Adrien
> 
> 
> 
>> On Jun 2, 2018, at 7:28 PM, John Ralls  wrote:
>> 
>> 
>> 
>>> On Jun 2, 2018, at 2:05 PM, Christian Stimming  
>>> wrote:
>>> 
>>> Am Samstag, 2. Juni 2018, 08:16:35 schrieb John Ralls:
>> But why do we keep a "gnucash" repo at all and not only everyone's
>> personal
>> repository? Of course there is some sort of project belonging. My
>> proposal
>> is to still keep the 2.6 branch a little bit more alive, and one or two
>> maintenance releases might be spun off from there. I'd be the one who
>> does
>> the housekeeping there, as discussed already.
> 
> Considering you do offer to take care of that 2.6 branch I can live with
> having one. If John disagrees you may need to make it a core policy
> decision request and check for a broader opinion there.
 
 I disagree for the user and contributor confusion reasons already stated,
 because I think that the old Windows build system should be retired, and
 because I think Christian has forgotten how much work goes into support and
 won’t have time to devote to it.
 
 If Christian wants to fork GnuCash to maintain 2.6.x, he’s free to do so,
 but it should be clear to all that it’s Christian’s fork and not “Official"
 GnuCash. It’s much clearer and cleaner if the fork lives in Christian’s own
 public repository with its own bug tracker and its own support mailing
 list. It’s 10 minutes work to set all of that up on Github, so what’s the
 point of keeping it in the Github repository?
>>> 
>>> *sigh* Of course there is already a private fork, just as everyone else 
>>> around 
>>> here is free to privately fork anything that he/she wants. 
>>> https://github.com/cstim/gnucash/tree/branch-2.6
>>> However, that's not the point of our common project gnucash. "Official", as 
>>> you call it.
>>> 
>>> Talking of core policy decision: Ultimately the decision is about whether 
>>> there might be another 2.6.x release after the 2.6.20 in April, which in 
>>> turn 
>>> is the reason for the existence of any 2.6 branch. John, it seems you 
>>> decided 
>>> that there should not be any such release anymore under any circumstances. 
>>> Had 
>>> this been a decision following 

Re: [GNC-dev] GDPR and gnucash as a project

[David T. via gnucash-devel]

Geert,

I am not fluent with the issues of the GDPR, but I have had a lifetime of 
considering intellectual property issues (as a librarian). Personal 
contributions of ideas, thoughts, or intellectual content are IMHO NOT personal 
data, even when signed by an individual’s name*. Those would fall under 
intellectual property/copyright rules rather than personal data. It is my 
understanding also that use of GPL addresses the question of IP rights in code 
and documentation; if a user contributes to the GC project in these areas, they 
do so with this release understood. It is also my understanding that unless 
someone explicitly states otherwise, their posting of information in a public 
place (such as a website, wiki, mailing list, etc.) would constitute permission 
to release that information generally.

David T.

* - I would be extremely surprised to find that a user’s name, in and of 
itself, would constitute protected personal information. 

> On May 22, 2018, at 6:02 PM, Geert Janssens  
> wrote:
> 
> Yesterday John raised some concerns about GDPR compliance of the gnucash 
> project itself.
> 
> This is a different question from the one Mike Evans asked in April this year 
> about GDPR compliance by people *using* gnucash.
> 
> This requires some thought as the GDPR has many aspects.
> 
> The essence of the GDPR (global data protection regulation) is to regulate 
> the 
> processing of EU citizen's personal data.
> 
> The first question this raises is which personal data does the gnucash 
> project 
> process ? So far I have come up with:
> - e-mail addresses on the gnucash mailing lists
> - user accounts in bugzilla
> - user accounts in our wiki
> - user accounts on Uservoice
> The above are pretty clear. There are others that are less clear to me 
> whether 
> they constitute personal data or not:
> - the actual messages people send to mailing lists and which are stored in a 
> public archive
> - the actual comments on bugs
> - the actual page edits in wiki
> And also what about things like our irc channel ? Does that fall under 
> processing personal data ? We don't really run the irc channel, we only use 
> it. But on the other hand we do publish irc logs. Does GDPR apply to those ? 
> I 
> can't tell really.
> And the same question could be asked about our code itself in a way. Does a 
> code contribution represent personal data ? Each commit logs an e-mail 
> address 
> of a committer which can't easily be removed.
> 
> Once we have established what constitutes personal data we need to formulate 
> a 
> "privacy policy" in which we explain how we process this data and whether 
> third parties are involved (think github, uservoice, travis-ci, our social 
> media presence,...).
> 
> An open source project is a bit in an odd situation because we do almost 
> everything in public so there's very little being kept private. We publish 
> archives of our mailing list conversations, irc logs, commits and so on. We 
> have to inform our users of this in a clear manner. The good thing is we only 
> do keep the absolute minimum amount of information to function: a username 
> (which can be an e-mail address) and a password is usually sufficient. Unless 
> the message content also falls under personal data.
> 
> We also require explicit consent to use the personal data. We're reasonably 
> good in this respect as for all services we offer we require the user to opt-
> in. We will never use for example mail addresses gathered from bugzilla user 
> accounts to automatically enroll the same people in a mailing list. We 
> probably should more clearly indicate what people subscribe to in each case 
> while they are registering. So when registering for a mailing list, it should 
> be pretty clear that anything the person contributes will end up on a public 
> web page. The same goes for all other services we offer and make use of.
> 
> Next a person should be allowed to make corrections to the personal data we 
> were provided with and "the right to be forgotten". For user accounts in the 
> various services we offer this is not really a problem. Most of these do 
> allow 
> the user to change passwords, user names or e-mail addresses. However if the 
> message content is also part of private data it becomes much harder. In that 
> case the question becomes whether a user can request a mail message to be 
> removed from our mailing list archive. I have no answer to this.
> 
> Next there is the requirement to protect children. I don't know for sure if 
> this applies to us. If it does our registration processes should ask a 
> minimum 
> age and require consent of a parent or equivalent in order to continue with 
> the registration. This is mostly mentioned in the context of social networks. 
> But as we publish all communication in public it may apply to us as well.
> 
> And finally in case of data breaches we should inform the affected people of 
> this. Again one I don't know 

Re: [GNC-dev] Register text selection

[David T. via gnucash-devel]

Geert,

> On May 22, 2018, at 1:22 PM, Geert Janssens  
> wrote:
> 
> Op maandag 21 mei 2018 19:44:57 CEST schreef David T.:
> > > On May 21, 2018, at 6:14 PM, Geert Janssens  > > >
> > > wrote:> 
> > > Op maandag 21 mei 2018 13:08:05 CEST schreef Robert Fewell:
> > >> I have been looking at getting the middle mouse button to work for
> > >> pasting
> > >> selected text and whilst trying to do that started to wonder about the
> > >> existing preselected text.
> > >> 
> > >> Currently...
> > >> If you open a register, the blank transaction date text is preselected.
> > >> If you start Gnucash with saved open registers, the last register in the
> > >> list to load has the blank date text preselected, this may not be the
> > >> current open register.
> > 
> > I would like to point out that I find *this* aspect of the register behavior
> > highly confusing.
>  
> I had to re-read the description to get what you guys mean. I have *never* 
> seen this precise behavior as described by Bob.
>  
> When I open gnucash the any keypresses I type before using my mouse will 
> always go to the currently active tab. If that's a register tab it will alter 
> the data field as that's the field selected by default.
>  
> The only variation I can think of would be if you have configured gnucash to 
> open each tab in a separate window. I don't do that and haven't tested how it 
> behaves in that case.

I am talking about multiple tabs open in one main window.

Here is the way I can demonstrate the problem.

Open GnuCash and close all tabs except the main Chart of Accounts.

Now, in sequence, open:
1) Your Checking account
2) Your Cash account

This will result in your GnuCash having the following tabs, in order: Accounts, 
Checking, Cash.

Next, click on the Checking account tab.
Click Reconcile, and OK in the Reconcile Information Window. Next, in the 
Reconcile window, immediately click Cancel.

Now, the status bar at the bottom will show the date. Press Tab. Enter a number 
(like 12345). The status bar will show the number you are entering, ***but the 
register on screen will NOT show any change.*** This is because the data is 
going into the Cash tab at the bottom. 

I am attaching a screen shot of my GnuCash at this particular juncture, which 
shows: 

* the Checking account register (as indicated in the title bar at the top)
* the status bar with my “12345” entry indicated
* the register itself, which shows NO 12345.

If I access the Cash tab, the information is there. Interestingly, if one 
clicks the Cancel button while still viewing the Checking register, there is no 
effect on the (hidden) transaction that is being edited. You can only cancel 
the transaction when it is in the current view.

David T.

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

Re: [GNC-dev] Register text selection

[David T. via gnucash-devel]

> On May 21, 2018, at 6:14 PM, Geert Janssens  
> wrote:
> 
> Op maandag 21 mei 2018 13:08:05 CEST schreef Robert Fewell:
>> I have been looking at getting the middle mouse button to work for pasting
>> selected text and whilst trying to do that started to wonder about the
>> existing preselected text.
>> 
>> Currently...
>> If you open a register, the blank transaction date text is preselected.
>> If you start Gnucash with saved open registers, the last register in the
>> list to load has the blank date text preselected, this may not be the
>> current open register.
>> 

I would like to point out that I find *this* aspect of the register behavior 
highly confusing. The “Select a field in a register that is not the current 
one” problem crops up at other times. I am not certain, but I think it happens 
when a modal dialog is closed. It is extremely frustrating to be working in a 
register that is not the bottom-most and then discover that your typing is 
going into a register that is NOT the one you are currently working in! 
Moreover, you may not even be aware that you are changing a transaction that is 
out of sight—and if you choose to leave GnuCash at this juncture, you will get 
a mysterious dialog asking if you want to save your changes (huh? what changes? 
I guess I better!). And THEN, you have no idea the next time what happened in 
that OTHER register.

I am grateful that someone else has seen this behavior and commented on it. I’d 
like to see it changed.

David T.



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

Re: [GNC-dev] pricedb policy

[David T. via gnucash-devel]

The ONLY way to change the value in a transaction is to change it in the 
transaction itself—either by changing the number of shares, the actual price 
per share, or the total amount in the transaction (and note that the UI will 
ask you about this if you change one without changing the others). The price db 
doesn’t and shouldn’t push changes into existing real transactions.

Changing the valuation in a transaction based on a price db change is the path 
to madness.

The price db is for reporting on potential valuation. The transactions 
represent what actually happened. If I paid $100 for 10 shares of ABC stock, it 
doesn’t matter that the going price for ABC on the same day is $1 per share—I’m 
still out $100 (and pretty gullible, too, I’d say).

David T.


> On May 13, 2018, at 7:20 PM, Adrien Monteleone 
>  wrote:
> 
> Christopher,
> 
> I’ll add a complication for you.
> 
> Suppose one enters a transaction and later realizes the price source was not 
> correct.
> 
> Does editing the originally generated user:price affect the transactions in 
> the register? Are they in-sync or now unrelated?
> 
> If editing user:price does not change the register, does that mean you have 
> to edit the register entries (or use correcting entries) and if so, does this 
> alter the original user:price? (or add another?)
> 
> If the two get out of sync, how do you determine what is the true source to 
> use to regenerate upon loading and Check?
> 
> Regards,
> Adrien
> 
>> On May 13, 2018, at 5:34 AM, Christopher Lam  
>> wrote:
>> 
>> Hi Devs
>> 
>> I wish to enquire about policy on pricedb.
>> 
>> As far as I can understand, pricedb receives entries from 3 different
>> sources:
>> 
>> 1. from entering transactions into the register, if the transaction
>> involves a foreign currency conversion or stock. e.g. originating account
>> is GBP, target currency is USD --> creates a pricedb entry GBP/USD. (can't
>> determine which one is deemed to be the base currency). These pricedb
>> entries are tagged "user:price" or "user:xfer-dialog".
>> 
>> 2. from online sources eg alphavantage. This requires careful setup, and
>> seems to create price entries for all foreign currencies / commodities,
>> compared to the book currency (in my case AUD). These are tagged
>> "Finance::Quote".
>> 
>> 3. entries added by the user. These are tagged "user:price-editor".
>> 
>> From my review of code so far, pricedb entries are rather important in
>> reports... an incorrect pricedb entry will lead to incorrect foreign
>> currency reporting, even if the transaction contains the exact transfer
>> amount.
>> 
>> My concerns relate to (1) above. I believe these transactional prices are
>> always more accurate than online quotes, because they describe the exact
>> prices achieved.
>> 
>> But it's buggy, e.g. if there are 2 transactions involving GBP/USD on the
>> same day, the second entered price will overwrite the first. (<- according
>> to my last test)
>> 
>> I'd think it would be important for accuracy that, upon book opening, and
>> Check, the user:price data should be *overwritten* by the actual
>> prices obtained from the transactions. Moreover if there are several
>> transactions involving commodities, Check should **add** relevant
>> amounts to ensure accurate pricing.
>> 
>> e.g.
>> 01/01/2018 Transfer 100 GBP to 150 USD (generates pricing 1.5 USD/GBP)
>> 01/01/2018 Transfer 100 GBP to 152 USD (generates pricing 1.52 USD/GBP)
>> 
>> should generate a price for "200 GBP to 302 USD -> pricing 1.51 USD/GBP)
>> 
>> Unfortunately I don't do C so cannot help with coding, but would think that*
>> the "user:price" prices should *always* be regenerated from the transaction
>> amounts during Check & Repair and upon loading datafile.*
>> 
>> Thoughts?
>> ___
>> gnucash-devel mailing list
>> gnucash-devel@gnucash.org
>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>> 
> 
> 
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[GNC-dev] Unknown Compressor error on startup

[David T. via gnucash-devel]

Hello,

I am using GC 2.6.19 on Mac OS X 10.13.4.

In an effort to test the effect of some commands I put into 
~/Library/Application Support/Gnucash/config.user, I opened GC from a terminal 
window. Interestingly, when I did so, I received the following errors in the 
terminal window:

/BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleFSCompression/AppleFSCompression-96.30.2/Common/ChunkCompression.cpp:50:
 Error: unsupported compressor 8
/BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleFSCompression/AppleFSCompression-96.30.2/Libraries/CompressData/CompressData.c:353:
 Error: Unknown compression scheme encountered for file 
'/System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/Exceptions.plist'
/BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleFSCompression/AppleFSCompression-96.30.2/Common/ChunkCompression.cpp:50:
 Error: unsupported compressor 8
/BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleFSCompression/AppleFSCompression-96.30.2/Libraries/CompressData/CompressData.c:353:
 Error: Unknown compression scheme encountered for file 
'/System/Library/CoreServices/CoreTypes.bundle/Contents/Library/AppExceptions.bundle/Exceptions.plist’

Googling the first error turns up a number of sites where other applications 
under OSX report the same error, as well as one on Apple’s discussion site: 
https://discussions.apple.com/thread/8159669 


I am insufficiently skilled to be able to determine whether this is applicable 
to GnuCash or whether it’s a problem that needs fixing.

Cheers,
David

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

Re: [GNC-dev] Proposed updates to Wiki Build#Ubuntu pages

[David T. via gnucash-devel]

David, 
It's a wiki, so please sign up and make your contributions! You don't need to 
worry about messing things up, since changes can be rolled back. Frankly, it's 
a whole lot easier to edit what you've written than to come up with the text 
whole cloth. 
David T.
 
 
  On Thu, Apr 19, 2018 at 10:12, DaveC49 wrote:   
John, Geert and whoever maintains the  Wiki Build#Ubuntu_16.04
  pages.

I would like to propose some edits to the above Wiki page section in the
light of my recent experiences building Guncash v3.0 which may help others
building it in future.

My major problems I encountered were in getting googletest and googlemock
installed and running smoothly, not having fully removed libraries from
2.6.19 and the right choice of relative reference to the top level
CmakLists.txt. 

I think the main reason Google doesn't recommend installing googletest and
googlemock as shared libraries is because of their reluctance to get dragged
into any maintenance issues on the various Linux distros rather than with
any inherent problems with shared libraries as such. 

In version 1.8.0 the move to a single repository and download for googlemock
and googleletest makes the installation as shared libraries fairly easy on
Ubuntu systems.  I am guessing the patch to GncADDTest and the
CmakeLists.txtin ~/common/test-core to detect shared libraries won't be in
the stable version until v3.1 is released. 

I would propose adding a note to the dependencies secion on the above page
referencing the ability to use shared libraries with v1.8.0 and referencing
an additional wki page addressing setting up for using googlemock and
googletest for building GnuCash which could have a section for setting up
GTEST_ROOT and GMOCK_ROOT if not using shared libraries  and or v 1.7.0 and
a section on setting up shared libraries for v 1.8.0. I put a tutorial up on
the Linux Mint Forum for that as I found the info available on many online
source and forums was a) very skettchy and b) sometimes confusing or
misleading which i could either reference or just incorporate directly.

I also propose putting a note re removing previous libraries. I had relied
on a Linux Mint menu uninstall option which worked with the distro installed
version but not with 2.6.19 which i had built. Another possibility is to
reference a page with instructions on how to remove files relative to the
install prefix.

The third proposal  would be to have some explanatory notes, possibly with
some examples, on the positioning of the build directory relative to the
source directory. My experience with this is that unlike the documentation
build, there does not appear to be a need to have the build directory
outside the source directory. This could either go on the Cmake page
https://wiki.gnucash.org/wiki/CMake

If you are happy with the above proposals or can suggest other approaches, I
am willing to have a go at editing the Wiki if I can be granted the
appropriate permissions to edit the pages and create the requisite new
pages.

David Cousens



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

Re: gnucash wiki access

[David T. via gnucash-devel]

John,

The Captcha problem essentially freezes the wiki from the perspective of adding 
or modifying links; contributors can’t (for example) fix erroneous links like 
the one for OFX on the Glossary page that links to a 404. That’s a problem that 
only grows worse.

David

> On Apr 3, 2018, at 9:36 PM, John Ralls  wrote:
> 
> 
> 
>> On Apr 3, 2018, at 9:12 AM, pjlbyrne  wrote:
>> 
>> Hi,
>> 
>> I found a typo on the gnucash wiki so I attempted to register in order to
>> fix it.
>> 
>> Firstly, the captcha box on the registration form appears to be broken. It
>> refers to an 'obsolete version 1 captcha' and has a link to the newer
>> version.
>> 
>> Secondly, I did get an account on the wiki but I don't seem to have
>> permission to edit pages. How do I acquire this please?
>> 
>> Perhaps these 2 issues are related?
> 
> They're not. The captcha issue was raised a couple of weeks ago but Derek 
> hasn't had a chance to fix it yet.
> 
> There's a one-week "cooling off period" between getting an account and it 
> being authorized for editing. That was in place as an anti-spam measure 
> before we required applying for an account and hasn't yet been removed.
> 
> 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: trial balance - how to find mismatch question

[David T. via gnucash-devel]

BTW, quixotic, while based on the famous Don Quixote, is a non-proper 
(improper?) adjective, and thus does not need capitalization. Whether you 
pronounce it “key-hotic” or “quick-sotic” depends on your personal 
predilection, as I undetstand it.

David

> On Mar 6, 2018, at 7:57 AM, David Carlson  wrote:
> 
> David T, I guess you do not have any IRA's or 401-K's as the IRS requires 
> every custodian to file either a "Fair Market Value" form or a form 5498 
> which includes the fair market value for each account.  The "as of" time is 
> calendar year end.
> 
> When you turn 70-1/2 you get to take a "Required Minimum Distribution" each 
> year based on a formula outlined in Publication 590-B which uses the Fair 
> Market Value and an actuarial table.  If you do not take the RMD, you pay a 
> fine and take it anyway.
> 
> While I would not depend on GnuCash to make an accurate report without 
> checking on every part of the data that it used to make the calculation and 
> check it in an external spreadsheet where I can actually see every number, I 
> like to try to verify that my custodians used the method I think they should 
> use to calculate realized gains long and short where needed and to accurately 
> report FMV so that my RMD is correct.
> 
> I did not intend to be unwitting about the problems with getting an accurate 
> balance report out of GnuCash, you are correct to call it Quixotic, and I 
> would capitalize that adjective, if it is one.  In fact, I was trying to 
> underline some of the issues that I have personally experienced.
> 
> David C
> 
> On Mon, Mar 5, 2018 at 8:08 PM, David T.  > wrote:
> David Carlson,
> 
> > On Mar 6, 2018, at 4:27 AM, David Carlson  > > wrote:
> >
> > Adrien, I think that you summarized the problem with "nearest in time"
> > nicely.  Wm, no doubt, had tongue in cheek when he was assigning a high
> > value to future prices.  You clarify that reports are often run "as of"
> > historical dates (and often need to match accounting reports submitted to
> > government agencies) thus could be exposed to erroneous values assigned
> > after the "as of" date by the "nearest in time" criterion.
> 
> Can you clarify the reports that you submit to governmental agencies that use 
> market value? My government (the US) doesn’t require any reporting of asset 
> market value that I am aware of. As far as I know, the only reporting that is 
> required is actual, realized, gains—and not book value of holdings. And as 
> far as I understand, GnuCash doesn’t use price db entries to track this 
> information; the preferred methods (as outlined in various sources) is to 
> enter the gains literally, based on the price entered and stored in the 
> transactions.
> 
> >
> > Your final note that ideally the prices would always be downloaded on the
> > date they are needed for the report is true, but as a practical matter it
> > is sometimes difficult to do, as the prices are often posted on the
> > internet several hours after the respective closing bell, and now that the
> > F:Q module is sometimes unable to acquire some prices on the first pass, it
> > is sometimes problematic whether it has even succeeded in getting all the
> > needed prices.  If it is done by a chron job, the job would need very
> > intelligent error handling capability to be confident about success.
> 
> Here, I think you unwittingly point to a significant problem inherent in 
> trying to track market value of even a moderate portfolio: there is no means 
> of determining the effective valuation date. If, as Adrien points out, you 
> retrieve prices monthly, then the values can be almost a month out of date. 
> If, as you point out, some prices fail to update, then some may be from last 
> week, while others from today. So, obtaining an accurate valuation is a 
> significant challenge. Perhaps this suggests that the entire portfolio 
> valuation proposal is quixotic in its goal of Absolute Valuation, and should 
> be considered only as a rough guide at best?
> 
> David T.
> 
> 
> >
> > If a developer wanted to expand the scope of the price download module to
> > allow downloading "as of" prices for arbitrary historical dates, I think
> > many of us would buy him a beer.  Alas, right now I fear that the currently
> > active developers have too many other things on their plates.
> >
> > David C
> >
> 
> 

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

Re: trial balance - how to find mismatch question

[David T. via gnucash-devel]

David,

I have IRAs, but I do not *manage* IRAs. The custodian is the entity with whom 
I maintain my IRA, and so I do not need to report an IRA valuation. THEY do.

So, it is true—I do not act as custodian for others’ retirement accounts. I 
wonder whether this is common for the GnuCash user base. 

David T.

> On Mar 6, 2018, at 7:57 AM, David Carlson  wrote:
> 
> David T, I guess you do not have any IRA's or 401-K's as the IRS requires 
> every custodian to file either a "Fair Market Value" form or a form 5498 
> which includes the fair market value for each account.  The "as of" time is 
> calendar year end.
> 
> When you turn 70-1/2 you get to take a "Required Minimum Distribution" each 
> year based on a formula outlined in Publication 590-B which uses the Fair 
> Market Value and an actuarial table.  If you do not take the RMD, you pay a 
> fine and take it anyway.
> 
> While I would not depend on GnuCash to make an accurate report without 
> checking on every part of the data that it used to make the calculation and 
> check it in an external spreadsheet where I can actually see every number, I 
> like to try to verify that my custodians used the method I think they should 
> use to calculate realized gains long and short where needed and to accurately 
> report FMV so that my RMD is correct.
> 
> I did not intend to be unwitting about the problems with getting an accurate 
> balance report out of GnuCash, you are correct to call it Quixotic, and I 
> would capitalize that adjective, if it is one.  In fact, I was trying to 
> underline some of the issues that I have personally experienced.
> 
> David C
> 
> On Mon, Mar 5, 2018 at 8:08 PM, David T.  > wrote:
> David Carlson,
> 
> > On Mar 6, 2018, at 4:27 AM, David Carlson  > > wrote:
> >
> > Adrien, I think that you summarized the problem with "nearest in time"
> > nicely.  Wm, no doubt, had tongue in cheek when he was assigning a high
> > value to future prices.  You clarify that reports are often run "as of"
> > historical dates (and often need to match accounting reports submitted to
> > government agencies) thus could be exposed to erroneous values assigned
> > after the "as of" date by the "nearest in time" criterion.
> 
> Can you clarify the reports that you submit to governmental agencies that use 
> market value? My government (the US) doesn’t require any reporting of asset 
> market value that I am aware of. As far as I know, the only reporting that is 
> required is actual, realized, gains—and not book value of holdings. And as 
> far as I understand, GnuCash doesn’t use price db entries to track this 
> information; the preferred methods (as outlined in various sources) is to 
> enter the gains literally, based on the price entered and stored in the 
> transactions.
> 
> >
> > Your final note that ideally the prices would always be downloaded on the
> > date they are needed for the report is true, but as a practical matter it
> > is sometimes difficult to do, as the prices are often posted on the
> > internet several hours after the respective closing bell, and now that the
> > F:Q module is sometimes unable to acquire some prices on the first pass, it
> > is sometimes problematic whether it has even succeeded in getting all the
> > needed prices.  If it is done by a chron job, the job would need very
> > intelligent error handling capability to be confident about success.
> 
> Here, I think you unwittingly point to a significant problem inherent in 
> trying to track market value of even a moderate portfolio: there is no means 
> of determining the effective valuation date. If, as Adrien points out, you 
> retrieve prices monthly, then the values can be almost a month out of date. 
> If, as you point out, some prices fail to update, then some may be from last 
> week, while others from today. So, obtaining an accurate valuation is a 
> significant challenge. Perhaps this suggests that the entire portfolio 
> valuation proposal is quixotic in its goal of Absolute Valuation, and should 
> be considered only as a rough guide at best?
> 
> David T.
> 
> 
> >
> > If a developer wanted to expand the scope of the price download module to
> > allow downloading "as of" prices for arbitrary historical dates, I think
> > many of us would buy him a beer.  Alas, right now I fear that the currently
> > active developers have too many other things on their plates.
> >
> > David C
> >
> 
> 

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

Re: trial balance - how to find mismatch question

[David T. via gnucash-devel]

David Carlson,

> On Mar 6, 2018, at 4:27 AM, David Carlson  wrote:
> 
> Adrien, I think that you summarized the problem with "nearest in time"
> nicely.  Wm, no doubt, had tongue in cheek when he was assigning a high
> value to future prices.  You clarify that reports are often run "as of"
> historical dates (and often need to match accounting reports submitted to
> government agencies) thus could be exposed to erroneous values assigned
> after the "as of" date by the "nearest in time" criterion.

Can you clarify the reports that you submit to governmental agencies that use 
market value? My government (the US) doesn’t require any reporting of asset 
market value that I am aware of. As far as I know, the only reporting that is 
required is actual, realized, gains—and not book value of holdings. And as far 
as I understand, GnuCash doesn’t use price db entries to track this 
information; the preferred methods (as outlined in various sources) is to enter 
the gains literally, based on the price entered and stored in the transactions.

> 
> Your final note that ideally the prices would always be downloaded on the
> date they are needed for the report is true, but as a practical matter it
> is sometimes difficult to do, as the prices are often posted on the
> internet several hours after the respective closing bell, and now that the
> F:Q module is sometimes unable to acquire some prices on the first pass, it
> is sometimes problematic whether it has even succeeded in getting all the
> needed prices.  If it is done by a chron job, the job would need very
> intelligent error handling capability to be confident about success.

Here, I think you unwittingly point to a significant problem inherent in trying 
to track market value of even a moderate portfolio: there is no means of 
determining the effective valuation date. If, as Adrien points out, you 
retrieve prices monthly, then the values can be almost a month out of date. If, 
as you point out, some prices fail to update, then some may be from last week, 
while others from today. So, obtaining an accurate valuation is a significant 
challenge. Perhaps this suggests that the entire portfolio valuation proposal 
is quixotic in its goal of Absolute Valuation, and should be considered only as 
a rough guide at best?

David T.


> 
> If a developer wanted to expand the scope of the price download module to
> allow downloading "as of" prices for arbitrary historical dates, I think
> many of us would buy him a beer.  Alas, right now I fear that the currently
> active developers have too many other things on their plates.
> 
> David C
> 

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

Re: trial balance - how to find mismatch question

[David T. via gnucash-devel]

David, Adrien, 
I, too, have encountered many discrepancies in my books with the Trial Balance 
report. I was not able to hammer them out. I gave up, and rely on brokerage 
reports for gains, and assume that the imbalance in the report is due to my 
incomplete understanding of the principles behind it.  
Adrien, I mistakenly said that there would be an imbalance entry on the report, 
but you are noting precisely the discrepancy that I found. 

David T. 
 
 
  On Fri, Feb 16, 2018 at 15:58, David Carlson 
wrote:   Adrien,

I am glad that you took the time to research how the report works for the
data you were able to provide to it.

You have found some valid concerns.  I had not looked at that report for
quite some time.

As another user with a lot of stock trades, I sometimes use that report to
find an issue, although I have developed a process involving outside
spreadsheets to calculate realized gains per security account as GnuCash
calculates them and net gains as the IRS wants them, so I rarely need the
report now.  The last time that I used the report I found that when I had a
security account with not-so-simple combinations of lots being traded or
when I had an account involving reinvested dividends it was still
problematic whether I actually matched and resolved all the gains
correctly.  I deliberately avoided going down the Trading Accounts rabbit
hole at that time, but it may be worthwhile to give that a fresh look.

Today I am using Windows GnuCash release 2.6.18, and I found that the
report has changed since sometime in the early 2.6 series when I last used
it.  For all I know, it may be different again in release 2.6.19 and in
2.7/3.0 coming out soon.

Having given you my perspective, I did notice that the report currently
uses the 'nearest in time' estimate of the date to use when extracting
values from the currency and commodity tables.  That estimate is a poor
method to use in my opinion because that often points to a future date when
there is no value for the target date.  This happens frequently when target
dates fall on weekends or holidays.  It is possible that Adrien's residual
imbalance may be at least exacerbated by this point.

Also, I want to thank David T for noticing that in my earlier comments I
was referring to the unrealized gain imbalance value that this report
produces rather than the Imbalance accounts that get created when
individual transactions are incomplete as sometimes happens in transaction
imports.  That difference is critical to this discussion.  I did fail to
make that point clear then.

For completeness I should also mention that there are other parameters or
variables available to adjust in this report which may or may not result in
differences in the final values reported by a certain instance of the
report operating on a certain set of data.

There is an option section on adjusting entries and closing entries.  How
does the report identify these?  There are three report variations under
the general tab and there is a whole new section on merchandising that
could impact a report in an undesired way for users that accidentally
format some data incorrectly.  There is no help to let the user ascertain
how or if these things affect him.

I will stop here.


David C

On Fri, Feb 16, 2018 at 2:20 AM, Adrien Monteleone <
adrien.montele...@gmail.com> wrote:

> At least on my version of the Trial Balance report, there is no ‘Imbalance
> entry’ specifically.
>
> There is at the bottom, the Imbalance-XXX and Orphan-XXX accounts listed
> along with the others.
>
> There is also a line for ‘Unrealized Gains’ or ‘Unrealized Losses’ (I have
> the latter, even though the report duration was a single day with no price
> changes, I gave up trying to figure that one out)
>
> The ‘imbalance’ I’m speaking of trying to resolve, or at least finally
> attributed to a rounding error with the XAG account, was simply the
> difference between what the report shows as Total Debits & Total Credits.
> (note, these aren’t labeled as such on the report - but they appear at the
> bottom, and that’s clearly what they are) There is no figure on the report
> that shows this difference. I had to calculate it manually. When I decided
> to audit the report for each account is when I found the foreign currency
> account out of whack. The remaining difference was attributable entirely to
> the ‘unrealized losses’ line.
>
> So, the full difference between debits and credits is the SUM of the
> ‘Unrealized Gains/Losses’ line and the discrepancy due to rounding.
>
> At least in my case.
>
> So there are two problems with the report:
>
> 1) There should be no losses or gains if there were no trading
> transactions. Certainly, this is impossible if there is only one day on the
> range of the report and the price is the same. If all you have are opening
> entries and you attempt to run a trial balance for that same day, you can’t
> have either a gain or a loss, unrealized or not.

Re: trial balance - how to find mismatch question

[David T. via gnucash-devel]

I don’t believe I’ve seen anywhere in this thread any attempt to explain that 
there is a difference between IMBALANCE-XXX (an indication that you have 
transactions that lacked a balancing split) and the Imbalance entry in the 
Trial Balance report. This latter most likely indicates (as David C. has 
hinted) that your books have capital or currency gains or losses that haven’t 
been entered into the books. If you buy a stock for $100 using a balanced 
transaction, and later sell that share for $150 (we wish!) in a balanced 
transaction, GnuCash will wonder where you got an additional $50. Both 
transactions balance, but the books don’t. That is why you usually have an 
entry (either as a separate transaction, or as splits in the sell transaction) 
that account for this gain.

Of course, it can get complex. 

David T.

> On Feb 16, 2018, at 7:31 AM, Christopher Lam  
> wrote:
> 
> Hi Adrien, could you distil this to a minimal test file and submit in a bug
> report and include relevant report and report parameters? C
> 
> On 16 Feb 2018 10:09, "Adrien Monteleone" 
> wrote:
> 
>> How timely.
>> 
>> Any way to solve this or do I just chalk it up?
>> 
>> Regards,
>> Adrien
>> 
>>> On Feb 15, 2018, at 8:00 PM, David Carlson 
>> wrote:
>>> 
>>> If you have multiple currencies  or if you buy and sell commodities or
>> securities  there is another level of opportunities for issues.
>>> 
>>> David  C
>>> 
>>> On Feb 15, 2018 5:55 PM, "Adrien Monteleone" <
>> adrien.montele...@gmail.com> wrote:
>>> I just noticed the subject was wrong due to a user-digest error,
>> re-applying the original.
>>> 
>>> ———
>>> 
>>> I’m having a bit of issue understanding the point of the trial-balance
>> report in modern times. (I generally don’t use it as I mentioned)
>>> 
>>> If each transaction self-balances, that is, debits = credits, how is it
>> possible to add up the debits individually and the credits individually and
>> not get a result that still balances? You can’t add up 1+2+3 = 5 and 1+2+3
>> = 6. It’s a mathematical impossibility.
>>> 
>>> In addition, if you enter a transaction that doesn’t balance, Gnucash
>> forces it to balance by using either the imbalance or orphan accounts. So
>> at least you’re alerted to amounts you need to fix, but technically, debits
>> still equal credits.
>>> 
>>> Let’s assume I entered a transaction backwards and debited my cash
>> account instead of crediting it, and credited an expense account instead of
>> debiting it. This should not affect the trial-balance. Sure, the amounts
>> are wrong for each account, but they still balance. Debits still equal
>> credits.
>>> 
>>> If I transpose two digits (the divisible by ‘9’ trick) then as long as
>> my individual transaction I did this in balances, it still shouldn’t show
>> up as an imbalance on the trial-balance report. The other side would ALSO
>> have to be transposed or incorrect to match it. Gnucash won’t save the
>> transaction unless it’s balanced.
>>> 
>>> I can’t see what possible error could produce individually balanced
>> transactions (required by Gnucash) and yet still have a trial-balance where
>> the debits do not equal credits AND both the imbalance account and orphan
>> accounts are empty.
>>> 
>>> (note, I understand why this report is run with paper records because
>> you’re copying stuff all over the place and might do so incorrectly. But
>> this isn’t the case with Gnucash)
>>> 
>>> Regards,
>>> Adrien
>>> 
 On Feb 15, 2018, at 5:06 PM, Adrien Monteleone <
>> adrien.montele...@gmail.com> wrote:
 
 The 1899 date seems to make me think that has something to do with a
>> setting in your OS concerning how to interpret 2-year dates. (I don’t think
>> Gnucash has this option, it might be hard coded)
 
 Try running the report again and make sure to enter the full 4-digit
>> date and not just ’16’. Also, test with 12/30/2016 and 01/01/2017 and see
>> if it does the same thing or only on exactly 12/31/2016. You might have
>> some corrupt data. That might even be the source date of the imbalance.
 
 I just entered those two dates in the same report and it worked fine,
>> so this wouldn’t be a generic bug to the app, though it might be a bug for
>> a certain platform. (I’m on macOS 10.13 at the moment)
 
 Since you’ve narrowed down to a few weeks, I’d just take a look at the
>> General Ledger which contains all transactions from all accounts. Click on
>> View > Filter By… and set your date range. (maybe even a day before and
>> after just to be thorough) Also be sure to check all boxes on the Status
>> tab in the Filter options. You want to see all transactions for that date
>> range. Then just look over them and see if anything looks out of place. In
>> particular, look for either the amount you are out of balance by or half
>> that amount if the variance is an even number. (meaning you have an entry
>> that is 

Permissions for gnc-fq-update

[David T. via gnucash-devel]

Hello,

In my quixotic quest to try and get quote retrieval working again on my Mac, 
I’ve been looking at ways to remove and reload all the Perl underlying 
Finance::Quote. (As John noted to me recently, there isn’t any uninstall 
command in CPAN, unfortunately). In this process, I ran into numerous 
discussions online that strongly recommend *against* invoking CPAN with root 
privileges for reasons I don’t quite understand [beyond the generic ‘don’t run 
things as root’], and with solutions I also don’t quite understand. My level of 
understanding notwithstanding, the advice is unambiguous.

In the course of this process, I opened up gnc-fq-update, and see immediately 
that it wants CPAN run with root access. Is this necessary? Given what I’ve 
read online, is this advised?

I ask out of curiousity, and to learn more.

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

Re: price.date, transaction.post_date and neutral time

[David T. via gnucash-devel]

Wm, Sebastien,

I profess to not paying too much attention to this thread, but IIRC, there was 
a time when the price entered into transactions was NOT entered into the price 
DB, which meant that users would often get useless reports on commodities, 
since the reports use price DB entries to calculate figures. The workaround was 
to add transaction-generated prices to the Price DB as well, thus (seemingly) 
killing two birds with one mouse click. I suspect that when John did work to 
decide on a new timezone neautral solution to the timestamp issue, he didn’t 
adjust this code as well.

Given the nature of these entries (i.e., added from the transaction to document 
a price that was valid at some arbitrary point in the past), I don’t see how a 
specific time could be added (as it might be with F::Q prices). Ditto 
manually-added prices.

Cheers,
David


> On Feb 14, 2018, at 3:19 AM, Wm via gnucash-devel  
> wrote:
> 
> On 13/02/2018 18:12, Sébastien de Menten wrote:
>> r/2012/2018/ (it was a typo)
> 
> ok
> 
>> My point is that a price entered via the price editor (manually) is handled
>> differently than a price generated via a transaction 
> 
> Isn't that a good thing ? I shouldn't have to say again that the price db is 
> just for reference, it doesn't change the tx just their valuations at a point 
> in time for reporting purposes.  From a strict accounting POV gnc doesn't 
> need the price db at all because you are allowed to value your assets at 
> however much you want.  The tax lady may disagree, of course :)
> 
> > > and may be (haven't
>> tested) different than a price downloaded via the Finance:Quote module.
> 
> It will almost certainly be different, different exchanges have different 
> prices, there are people that make a lot of money noticing the small 
> differences between exchanges and trading based on those differences.
> 
>> And indeed, as the time component is meaningless (yet different in function
>> on the price creation method), it shouldn't be stored OR, if for legacy
>> reason it should be kept, it could at least be stored consistently (across
>> price creation method) using for instance the "neutral time" approach used
>> for the post_date.
>> If not, any extract of price data (direct SQL, XML, piecash, ...) is
>> complex to use.
> 
> I don't see the complexity. Why don't you just discard the time component as 
> it is essentially meaningless after 24 or 48 hours ?
> 
> Isn't your typo a good observation in that it shows that time isn't the 
> significant part of the price record ?
> 
> P.S. I don't like arguing with you, Sebastien, it is better when we agree :)
> 
> -- 
> Wm
> 
> ___
> 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: Scope of GNUCash

[David T. via gnucash-devel]

Matt,

I again applaud your promise (threat?! ;) ) to update the slim information 
about the Budget section. As you do, be sure to look through the list archives 
and the wiki for any information you might draw in to the Tutorial; there have 
been numerous discussions over the years about how to use them. Personally, I 
would love an explanation of how the Budget reports can be used; I have never 
been able to figure them out (beyond a few rudiments).

Cheers,
David

> On Feb 14, 2018, at 2:53 AM, Matt Graham  wrote:
> 
>  I think I would love to sit down in a pub with the three of you (Wm, 
> Adrien, and Mike). I think we could have such awesome semi-drunken 
> discussions about the nature of life, the universe and everything!
> 
> I think you have basically answered my question, and I think we all basically 
> agree on the rough direction things *should* go in (separate interacting 
> packages). I’m just not sure how to help make it happen (I’m an enthusiastic 
> amateur when it comes to programming). I think I’ll start by updating the 
> budget part of the tuts and concept guide like I have promised elsewhere, and 
> then start looking into how the C++ modules have been structured (to see what 
> connection will be possible within the 3.0 releases).
> 
> Thanks and regards,
> 
> Matt
> 
> From: Adrien Monteleone
> Sent: Wednesday, 14 February 2018 2:31 AM
> To: gnucash-devel
> Subject: Re: Scope of GNUCash
> 
> Michael,
> 
> I agree completely on the separation point, especially with regard to 
> controls.
> 
> I’ve seen first hand when sales clerks have the ability to void and edit 
> their own transactions from a point of sales system. I can’t imagine the 
> damage that WOULD be done if they also had the ability to access the 
> inventory system AND the general accounting software. (even just the ability 
> to partially close a ticket is dangerous)
> 
> As for interoperability, the devil is always in the details but I see three 
> main hangups. First, any software should be able to import it’s own exports. 
> Second, any software with imports should be able to allow the user an easy 
> way to map fields and save that mapping for future use. Third, importing and 
> exporting should be possible to schedule or trigger without manual user 
> intervention. (so apps can talk to each other reliably without lag)
> 
> I think 3.0 is going to partially address the first and second case. I don’t 
> think the third is contemplated yet. The third is also dangerous for 
> accounting so it should be very carefully implemented and certainly not a 
> default condition.
> 
> Regards,
> Adrien
> 
>> On Feb 13, 2018, at 8:10 AM, Mike or Penny Novack 
>>  wrote:
>> 
>> On 2/13/2018 2:55 AM, Wm via gnucash-devel wrote:
>> 
>>> 
 A couple of times I have noticed that people have said "That's not what 
 GNUCash is for". It begs the question - where is it defined what GNUCash 
 is and isn't for? The charter for GNUCash doesn't seem to ever been 
 formalised.
>>> There is a long term plan, we never write it down because people ask us 
>>> about it :) Is it intended that people should establish a complementary but 
>>> separate project for functionality they want, but is not included in 
>>> GNUCash scope?
>>> 
>>> I don't see why not if that is what they want to do.
>> 
>> Since I have been one of the people arguing for "separation" (I think this 
>> is being misunderstood) I want to clarify the reasons and what I mean when I 
>> use the term.
>> 
>> a) I do NOT mean that needs to be a separate project. Could be part of a 
>> PACKAGE (even installed together) but not a single program.
>> 
>> b) The reason for separate "packages" that interact with each other rather 
>> than a single program (that a user is or is not allowed to use) is so that 
>> ONE "system" (interacting parts) can be used for all. Those people who are 
>> running "one man band" businesses do not see the problem, do not see why 
>> things like (proposed extensions) like "inventory", "point of sales", 
>> "payroll",  etc. cannot be PART of the "general ledger" program. Call these 
>> "one man band" users businesses of class A.
>> 
>> But there is another sort of business user, call these class B. They have 
>> employees, they have division of responsibility and authority. They may have 
>> need of safeguards. I am not meaning JUST businesses since even a larger 
>> non-profit (call these class C, they might have other needs too) might need 
>> safeguards making embezzlement more difficult.
>> 
>> These need separation. They need to be able to have people "log in and use" 
>> things like an inventory system or "point of sales" system WITHOUT being 
>> able to access "general ledger. Does not have to be a very large small 
>> business before it has people waiting on customers, stocking inventory, etc. 
>> These 

Re: RFP: Generic Comparison Report

[David T. via gnucash-devel]

Chris,

I think that users would like to know what is happening on this front. Users 
are very interested in these developments, and there are far more readers on 
users, who may have additional suggestions for use-cases and features. Given 
the fact that there are current threads on the user list that ask this very 
question, it seems to me unhelpful to split this off to the devel list, where 
those users will not learn of this.

For what it’s worth, I have yet to see or use the new transaction report, since 
my system hates both me and custom reports. I doubt most normal users are aware 
of the new version of the report and its features, for the same reasons.

David

> On Feb 10, 2018, at 11:24 AM, Christopher Lam  
> wrote:
> 
> Hi D
> 
> Wish to move to devel, technical and policy details abound.
> 
> There's already work done to enable periodic subtotals comparison. This 
> feature has been named "Subtotal Summary Grid". This is done by reusing and 
> augmenting the (most excellent) transaction report's grouping and subtotals. 
> I'm not sure whether this allows 100% coverage of users' requirements for 
> periodic comparison, but I suspect it would.
> For example, setting accounts = expense accounts (+ children), primary-key = 
> account, secondary-key = date, secondary-subtotals = monthly, 
> subtotal-summary-grid = enabled -> will provide a nice 2D grid whereby Y-axis 
> = accounts, X-axis = monthly expense subtotals. This feature will reuse the 
> subtotals already generated within the transaction report, therefore any 
> errors in subtotals are not from my code. Example at 
> https://imgur.com/a/unDAD 
> Unfortunately it was completed after string and feature-freeze for upcoming 
> 3.0 -- I'm afraid that inclusion into 3.0 isn't guaranteed yet. Although, as 
> I have notified devs, if this feature is renamed "Grid", it could be written 
> into 3.0. The translated string "Grid" already exists.
> 
> If you wish to experiment, the code is currently available at 
> https://github.com/Gnucash/gnucash/pull/266/commits/4d2ee75b4fa138c0534ae739089d4df70d6d4117
>  
> 
>  - (note, this commit link isn't permanent).
> 
> C
> 
> On 10/02/18 13:35, D via gnucash-user wrote:
>> Hello,
>> 
>> I want to raise a discussion here about the creation of a generic comparison 
>> report. 
>> 
>> I would preface this discussion by saying that, although I am a long time 
>> user of Gnucash, I have repeatedly demonstrated my utter inability to 
>> generate useful code for the project, so any ultimate action on the results 
>> of this discussion would have to be applied by someone else.
>> 
>> As we have seen recently, and as I have seen repeatedly over the years, one 
>> of the more common requests for reporting is to be able to see numbers from 
>> different time periods in order to evaluate a financial situation.
>> 
>> As far as I can tell, other than the multi column report, nothing of the 
>> sort exists in Gnucash. I started thinking that it might be good to begin 
>> the process of detailing what features might go into such a report in order 
>> to make it generally useful, with the idea of perhaps stirring up someone's 
>> interest in creating such a report.
>> 
>> Some initial ideas include:
>> 
>> * Definable periods. Should be able to set the unit period, with options for 
>> common units (month, quarter, year).
>> * Definable numbers of periods.
>> * Definable accounts, but with some common groupings (Assets, Liabilities, 
>> Investments... Are there others?)
>> * Perhaps the option to use another report as a template? I have no idea how 
>> that might work, but the fact that folks seem to want side by side balance 
>> sheets suggests this to me.
>> 
>> Does anyone else think this would be helpful? Is it a reasonable idea? Is it 
>> something that someone in the community with Scheme skills is interested in 
>> pursuing? Are there other elements that would make this a better idea? Are 
>> there elements that are absurdly difficult or impossible?
>> 
>> Cheers,
>> David
>> ___
>> gnucash-user mailing list
>> gnucash-u...@gnucash.org 
>> To update your subscription preferences or to unsubscribe:
>> https://lists.gnucash.org/mailman/listinfo/gnucash-user 
>> 
>> If you are using Nabble or Gmane, please see 
>> https://wiki.gnucash.org/wiki/Mailing_Lists 
>>  for more information.
>> -
>> Please remember to CC this list on all your replies.
>> You can do this by using Reply-To-List or Reply-All.
> 

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

Re: GnuCash Opens Dirty?

[David T. via gnucash-devel]

So,  gnucash cannot run without an active file? It seems odd to have the 
program create the beginnings of a file without my invoking File->New. 
Nevertheless, marking the stub file clean seems like a fine solution. 
David

 
 
  On Sun, Feb 4, 2018 at 22:49, John Ralls<jra...@ceridwen.us> wrote:   That’s 
exactly what it does: It opens with no file rather than the default of opening 
with the last-opened file/database. Then it creates an empty book ready for you 
to start populating with new accounts.  It would be a minor change to mark that 
book as clean. That should suppress the request to save something that doesn’t 
really need saving. I’m inclined to think that it would also be better to 
display an accounts page instead of an empty notebook.

Regards,
John Ralls


> On Feb 4, 2018, at 8:35 AM, David T. via gnucash-devel 
> <gnucash-devel@gnucash.org> wrote:
> 
> David C.,
> 
> It is apparently my mistake, but I understood the “--nofile” command line 
> argument to mean “Open GnuCash with no file.” 
> 
> As in: No. File. Nothing. And if I have Nothing in my file, what, pray tell, 
> is there to save? 
> 
> David T.
> 
> P.S. — For yucks, I executed “Gnucash --nofile” and immediately saved 
> “Nofile” and opened it in a text editor. Here it is, creating the root 
> account without a file:
> 
> 
>     xmlns:gnc="http://www.gnucash.org/XML/gnc <http://www.gnucash.org/XML/gnc>"
>    xmlns:act="http://www.gnucash.org/XML/act <http://www.gnucash.org/XML/act>"
>    xmlns:book="http://www.gnucash.org/XML/book 
><http://www.gnucash.org/XML/book>"
>    xmlns:cd="http://www.gnucash.org/XML/cd <http://www.gnucash.org/XML/cd>"
>    xmlns:cmdty="http://www.gnucash.org/XML/cmdty 
><http://www.gnucash.org/XML/cmdty>"
>    xmlns:price="http://www.gnucash.org/XML/price 
><http://www.gnucash.org/XML/price>"
>    xmlns:slot="http://www.gnucash.org/XML/slot 
><http://www.gnucash.org/XML/slot>"
>    xmlns:split="http://www.gnucash.org/XML/split 
><http://www.gnucash.org/XML/split>"
>    xmlns:sx="http://www.gnucash.org/XML/sx <http://www.gnucash.org/XML/sx>"
>    xmlns:trn="http://www.gnucash.org/XML/trn <http://www.gnucash.org/XML/trn>"
>    xmlns:ts="http://www.gnucash.org/XML/ts <http://www.gnucash.org/XML/ts>"
>    xmlns:fs="http://www.gnucash.org/XML/fs <http://www.gnucash.org/XML/fs>"
>    xmlns:bgt="http://www.gnucash.org/XML/bgt <http://www.gnucash.org/XML/bgt>"
>    xmlns:recurrence="http://www.gnucash.org/XML/recurrence 
><http://www.gnucash.org/XML/recurrence>"
>    xmlns:lot="http://www.gnucash.org/XML/lot <http://www.gnucash.org/XML/lot>"
>    xmlns:addr="http://www.gnucash.org/XML/addr 
><http://www.gnucash.org/XML/addr>"
>    xmlns:owner="http://www.gnucash.org/XML/owner 
><http://www.gnucash.org/XML/owner>"
>    xmlns:billterm="http://www.gnucash.org/XML/billterm 
><http://www.gnucash.org/XML/billterm>"
>    xmlns:bt-days="http://www.gnucash.org/XML/bt-days 
><http://www.gnucash.org/XML/bt-days>"
>    xmlns:bt-prox="http://www.gnucash.org/XML/bt-prox 
><http://www.gnucash.org/XML/bt-prox>"
>    xmlns:cust="http://www.gnucash.org/XML/cust 
><http://www.gnucash.org/XML/cust>"
>    xmlns:employee="http://www.gnucash.org/XML/employee 
><http://www.gnucash.org/XML/employee>"
>    xmlns:entry="http://www.gnucash.org/XML/entry 
><http://www.gnucash.org/XML/entry>"
>    xmlns:invoice="http://www.gnucash.org/XML/invoice 
><http://www.gnucash.org/XML/invoice>"
>    xmlns:job="http://www.gnucash.org/XML/job <http://www.gnucash.org/XML/job>"
>    xmlns:order="http://www.gnucash.org/XML/order 
><http://www.gnucash.org/XML/order>"
>    xmlns:taxtable="http://www.gnucash.org/XML/taxtable 
><http://www.gnucash.org/XML/taxtable>"
>    xmlns:tte="http://www.gnucash.org/XML/tte <http://www.gnucash.org/XML/tte>"
>    xmlns:vendor="http://www.gnucash.org/XML/vendor 
><http://www.gnucash.org/XML/vendor>">
> 1
> 
> a75807d572ced056657e14cf61730861
> 1
> 1
> 
>  template
>  template
>  template
>  template
>  1
> 
> 
>  Root Account
>  27174afb49511a6a82c3da7274337c90
>  ROOT
> 
> 
> 
> 
> 
> 
> 
> 
> 
>> On Feb 3, 2018, at 7:03 PM, David Carlson <david.carlson@gmail.com 
>> <mailto:david.carlson@gmail.com>> wrote:
>> 
>> BTW, I am running 2.6.

Re: GnuCash Opens Dirty?

[David T. via gnucash-devel]

David C.,

It is apparently my mistake, but I understood the “--nofile” command line 
argument to mean “Open GnuCash with no file.” 

As in: No. File. Nothing. And if I have Nothing in my file, what, pray tell, is 
there to save? 

David T.

P.S. — For yucks, I executed “Gnucash --nofile” and immediately saved “Nofile” 
and opened it in a text editor. Here it is, creating the root account without a 
file:


http://www.gnucash.org/XML/gnc <http://www.gnucash.org/XML/gnc>"
 xmlns:act="http://www.gnucash.org/XML/act <http://www.gnucash.org/XML/act>"
 xmlns:book="http://www.gnucash.org/XML/book 
<http://www.gnucash.org/XML/book>"
 xmlns:cd="http://www.gnucash.org/XML/cd <http://www.gnucash.org/XML/cd>"
 xmlns:cmdty="http://www.gnucash.org/XML/cmdty 
<http://www.gnucash.org/XML/cmdty>"
 xmlns:price="http://www.gnucash.org/XML/price 
<http://www.gnucash.org/XML/price>"
 xmlns:slot="http://www.gnucash.org/XML/slot 
<http://www.gnucash.org/XML/slot>"
 xmlns:split="http://www.gnucash.org/XML/split 
<http://www.gnucash.org/XML/split>"
 xmlns:sx="http://www.gnucash.org/XML/sx <http://www.gnucash.org/XML/sx>"
 xmlns:trn="http://www.gnucash.org/XML/trn <http://www.gnucash.org/XML/trn>"
 xmlns:ts="http://www.gnucash.org/XML/ts <http://www.gnucash.org/XML/ts>"
 xmlns:fs="http://www.gnucash.org/XML/fs <http://www.gnucash.org/XML/fs>"
 xmlns:bgt="http://www.gnucash.org/XML/bgt <http://www.gnucash.org/XML/bgt>"
 xmlns:recurrence="http://www.gnucash.org/XML/recurrence 
<http://www.gnucash.org/XML/recurrence>"
 xmlns:lot="http://www.gnucash.org/XML/lot <http://www.gnucash.org/XML/lot>"
 xmlns:addr="http://www.gnucash.org/XML/addr 
<http://www.gnucash.org/XML/addr>"
 xmlns:owner="http://www.gnucash.org/XML/owner 
<http://www.gnucash.org/XML/owner>"
 xmlns:billterm="http://www.gnucash.org/XML/billterm 
<http://www.gnucash.org/XML/billterm>"
 xmlns:bt-days="http://www.gnucash.org/XML/bt-days 
<http://www.gnucash.org/XML/bt-days>"
 xmlns:bt-prox="http://www.gnucash.org/XML/bt-prox 
<http://www.gnucash.org/XML/bt-prox>"
 xmlns:cust="http://www.gnucash.org/XML/cust 
<http://www.gnucash.org/XML/cust>"
 xmlns:employee="http://www.gnucash.org/XML/employee 
<http://www.gnucash.org/XML/employee>"
 xmlns:entry="http://www.gnucash.org/XML/entry 
<http://www.gnucash.org/XML/entry>"
 xmlns:invoice="http://www.gnucash.org/XML/invoice 
<http://www.gnucash.org/XML/invoice>"
 xmlns:job="http://www.gnucash.org/XML/job <http://www.gnucash.org/XML/job>"
 xmlns:order="http://www.gnucash.org/XML/order 
<http://www.gnucash.org/XML/order>"
 xmlns:taxtable="http://www.gnucash.org/XML/taxtable 
<http://www.gnucash.org/XML/taxtable>"
 xmlns:tte="http://www.gnucash.org/XML/tte <http://www.gnucash.org/XML/tte>"
 xmlns:vendor="http://www.gnucash.org/XML/vendor 
<http://www.gnucash.org/XML/vendor>">
1

a75807d572ced056657e14cf61730861
1
1

  template
  template
  template
  template
  1


  Root Account
  27174afb49511a6a82c3da7274337c90
  ROOT









> On Feb 3, 2018, at 7:03 PM, David Carlson <david.carlson@gmail.com 
> <mailto:david.carlson@gmail.com>> wrote:
> 
> BTW, I am running 2.6.18 in windows and I do not recall the warning referring 
> to any changes.
> 
> David C
> 
> On Sat, Feb 3, 2018 at 7:54 AM, David Carlson <david.carlson@gmail.com 
> <mailto:david.carlson@gmail.com>> wrote:
> I just had that experience as I was not logged in to my file server when I 
> started GnuCash and I still think that my earlier comment is true.  GnuCash 
> is offering to save the empty file. The interesting thing, though, is that 
> because the file was unnamed it did not have a asterisk in the filename space 
> on the top banner.
> 
> David C
> 
> On Sat, Feb 3, 2018 at 7:41 AM, David Carlson <david.carlson@gmail.com 
> <mailto:david.carlson@gmail.com>> wrote:
> David,
> 
> I think that a non-existent file with no data is not the same as a file that 
> has been created with no data.  A created file has some structure and some 
> defaults set.  GnuCash is thus saying that it is not a properly saved file 
> with no data.
> 
> David C
> 
> On Sat, Feb 3, 2018 at 1:56 AM, David T. via gnucash-devel 
> <gnucash-devel@gnucash.org <mailto:gnucash-devel@gnucash.org>> wrote:
> Hello,
> 
> When I open GnuCash with no file (i.e., “gnucas

Wiki is down

[David T. via gnucash-devel]

… not responsive…

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

GnuCash Opens Dirty?

[David T. via gnucash-devel]

Hello,

When I open GnuCash with no file (i.e., “gnucash --nofile”), I find that if I 
immediately attempt to open a different file or exit the program altogether 
(i.e., without doing anything to the current session), I am warned that all 
changes to the current file will be lost. Given that I: a) have made no 
changes, and b) have “nofile” open at the time, this dialog is absurd. 

GnuCash should NOT consider “nofile” to be dirty, and thus should NOT ask that 
I save “nofile”. I don’t see any bugs filed for this.

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

WIki Page discrepancies

[David T. via gnucash-devel]

Hello,

More on the two Git pages (“Git” and “An Introduction to Git”)(Thanks, Geert!).

I notice that “An Introduction to Git” says that there are 2 important 
branches: master and maint, whereas “Git” says that there are three: master, 
maint, and unstable, with the note that unstable only exists when a new major 
release is imminent. I will assume that the latter is more right (insofar as it 
goes into more technical detail about the git branching that the project uses), 
but should the Intro page be changed to be more in line with the main Git page? 
Something like this:

There are two primary branches in the GnuCash repositories:
 master 
   is the default branch in git. New features and their documentation should be 
based on this branch.
 maint
   is the second important branch. Bugfixes, translations, and improvements to 
the documentation should usually be applied on this branch.

A third branch, unstable will exist when a major release is imminent, but is 
used for beta releases.

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

Captcha Error Redux

[David T. via gnucash-devel]

On January 13, there were a number of folks with errors with the Captcha 
verification on the wiki. I am having this problem again; what were the steps 
taken to fix this?

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

Wiki Page title

[David T. via gnucash-devel]

Hello,

As noted recently, I have begun to work on the main Git pages (“Git," and "Git 
for Newbies") on the Wiki. One of the edits I would like to make is to change 
the title from “Git for Newbies” to “An Introduction to Git.” I want to do this 
because I feel the term “Newbie” is disparaging, and does nothing to encourage 
new contributors. Unfortunately, the one thing that I don’t seem to be able to 
change is the page title. Or am I missing something?

TIA,
David

P.S., If “Git for Newbies” becomes “An Introduction to Git,” it may be that 
“Git” becomes something else as well, such as “Using Git for GnuCash 
Development.” 
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: "What's New" for 3.0

[David T. via gnucash-devel]

John,

That all sounds great!

Thanks for all you and the team do.

David

> On Jan 22, 2018, at 8:35 PM, John Ralls  wrote:
> 
> David,
> 
> A reminder of what we (I think it was a collaboration between Cristian Marchi 
> and Christian Stimming) did last time: 
> https://www.gnucash.org/2.6-release-tour.phtml 
> .
> 
> As a stand-alone page IMO it can stay up forever; it becomes part of history 
> along with the release notices that included a link to it.
> 
> We might consider a block/banner of some sort on the home page announcing the 
> new major version with a pointer to the “what’s new” page. *That* should get 
> removed after 6 months (2 minor releases) or so.
> 
> Regards,
> John Ralls
> 
> 
>> On Jan 22, 2018, at 2:38 AM, David T. > > wrote:
>> 
>> John,
>> 
>> I agree that the website would be a better place to promote this new report 
>> as well as other changes. Of course, there is already a News page that 
>> gathers the release notes for users, but perhaps with the Big Jump it would 
>> be preferable to have a special top-level page added. It would be nice if 
>> there were some kind of “freshness dating” for this, so that it isn’t still 
>> up on display in 2021…
>> 
>> David T.
>> 
>> 
>>> On Jan 22, 2018, at 7:16 AM, John Ralls >> > wrote:
>>> 
>>> It's about time to think about the side stuff that goes with a major 
>>> release. Chris Lam has offered a PR 
>>> (https://github.com/Gnucash/gnucash-docs/pull/106 
>>> ) documenting his 
>>> substantial enhancements to the Transaction Report and included a bunch of 
>>> "NEW! in 3.0" bullets. Given the way documentation is(n't) maintained I 
>>> think it wise not to bury something like that in a chapter, and besides we 
>>> need a summary document explaining everything that's changed between 2.6 
>>> and 3.0.
>>> 
>>> We had until the 2.6.14 docs a "What's New section in the Guide's overview 
>>> chapter that had last been updated for Version 2.2. It obviously turned 
>>> into an embarrassing example of how we keep such things up-to-date. I don't 
>>> think we should do it again.
>>> 
>>> How about a "What's New in 3.0" page on the website? If we go with that, 
>>> what's the best way to collaborate in building it?
>>> 
>>> 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: Capital Gains FAQ entry

[David T. via gnucash-devel]

Alen,

I appreciate your message, as well as your effort and attitude.

I have worked over the years to improve the official documentation (that is, 
the Help Manual and the Guide), and make those documents as accurate, clear, 
and up to date as possible. Although there is still a lot of work that can be 
done to improve these documents, they still represent the place where the most 
amount of editorial and writing effort have been expended by the GnuCash 
community. Because of this (and because of my own background in technical 
writing), I tend to prefer information in those documents—if it exists—over 
information that is put on the wiki. When duplication occurs, I believe that 
the information in the docs should be used (and referred to) and wiki 
information changed to reference the docs, rather than keeping information in 
multiple places.

I want to acknowledge that my opinion on this is not necessarily that of the 
rest of the community, and that others like to see more complete information on 
the wiki, at the cost of some duplication.

With regards to the Lots issue, I think that in the longer run, the Concept of 
Lots page should be removed altogether from the wiki, and any remaining special 
information on it should be put into the Guide in Chapter 9. Such an action 
would require someone to go through both, and incorporate information from the 
Wiki page into the existing chapter in a meaningful manner. I also believe that 
the Guide section “Selling Shares” covers gains and lots in MUCH greater detail 
than the original FAQ entry ever did. I recommend that you take a closer look 
at it. That was why I opted to remove the Wiki text altogether.

In regards to Uservoice, there already is a reference on the wiki to it. If you 
look at the main Wiki page under “Filing Bugs and Enhancement Requests” you 
will see reference to the Uservoice page. It would probably be nice to improve 
the visibility of that link. Such a change will require a special request, 
however, as the main Wiki page is locked from Edits by Mortals. Or were you 
proposing adding that link to www.gnucash.org ?

David T.

> On Jan 22, 2018, at 2:11 PM, Alen Siljak  wrote:
> 
> Thanks, David. I'm refraining from deleting any text unless it is glaringly 
> obvious that it is wrong.
> What I'm trying to do is to link various related pieces of information 
> together. As you say, sometimes it can be contradictory because one side is 
> quite outdated. I believe that, with having links, this would become easier 
> to navigate and eventually correct.
> Sometimes I run into a page describing some concept and I can not find it 
> afterwards.
> Multiple entry points to documentation are also extremely confusing to me - 
> faq, wiki, user docs, doxygen, txt files, descriptions in the repo, etc. So, 
> I guess, the ability to clean up is equally important as adding new text. :)
>  
> The Lots Concept guide page, which I linked to the Concept of Lots wiki page, 
> contains the most complete explanation of the lots concept and the 
> *implementation*, which is currently in GnuCash. From that point it is very 
> valuable although it may be outdated. And I never saw any link to that page 
> elsewhere.
> It is a bit difficult (for me, at least) to distinguish between user and 
> developer documentation. Because, as a user, I had terrible problems working 
> with Lots - transactions would appear duplicate out of the blue, transactions 
> would be split automatically, etc. None of what's happening was obvious until 
> I read the mentioned description. So, once a few details were known, I had no 
> issues with the Lots any longer. Not able to reproduce the issues I was 
> experiencing before and report as bugs because now I don't remember the way I 
> tried to do it instinctively.
>  
> In addition, it would be handy to have useful links on the home page. For 
> example, Uservoice is missing and I think this is quite handy for end users 
> to have input into the desired features. While it does not guarantee the 
> implementation, at least it shows where the demand is.
>  
> Hope what I wrote here makes sense. These are mostly observations from my 
> short recent experience and not a direct reference to what you wrote earlier.
> Thank you for making the changes you just did. This just proves that adding 
> the links between related topics helps to clean up the things a bit. For 
> example, someone who only reads the FAQ would have a different understanding 
> of capital gains process than someone who happened to search for Lots and 
> read a different page. Now, at least, they should be a bit more aligned.
>  
> Cheers
>  
> Sent: Sunday, January 21, 2018 at 6:35 PM
> From: "David T." 
> To: cicko 
> Cc: gnucash-devel@gnucash.org
> Subject: Capital Gains FAQ entry
> Cicko,
> 
> I see that you have gotten involved in working on the wiki; fabulous!
> 
> I recently 

Capital Gains FAQ entry

[David T. via gnucash-devel]

Cicko,

I see that you have gotten involved in working on the wiki; fabulous! 

I recently received a notice that you had edited the FAQ on handling capital 
gains, by adding a reference to the wiki page “Concept of Lots”. 

Naturally, having received the announcement of the page change, I took a look 
at both the FAQ section and the Concept of Lots page, and found a number of 
problems.

First, the FAQ itself is quite dated, mentioning the status of gains as of 
version 1.8. Since the Tutorial & Concept Guide represents the most complete 
and up-to-date version of the documentation, I have added these references and 
removed the original paragraph.

Next, it goes into quite a bit of detail on how to enter gains—topics that are 
now covered in quite some detail in the Tutorial & Concepts Guide. SInce "9.7. 
Selling Shares” is so thorough, the examples given in the FAQ are both 
incomplete and redundant. Consequently, I am removing the example in the FAQ, 
and pointing to the Tutorial a second time, since it has so many detailed 
examples.

Finally, I wonder whether it is wise to link to the “Concept of Lots” page, as 
it appears to be a description of how the implementer of the Lots feature went 
about it. Some of this information does appear to be unique, however, so I 
didn’t touch your reference to it. Long term, I think the information on this 
page should be separated so that the technical, development, information was 
placed on a technical page, and the user-focused information placed in the 
documentation set.

Anyhow, I just wanted to let you know why I went into this section and changed 
it just after you had.

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

Re: Wrong link in docs

[David T. via gnucash-devel]

As that is part of the Help manual, a bug would be appropriate. I have 
submitted one: Bug 792756 (https://bugzilla.gnome.org/show_bug.cgi?id=792756 
)

Thanks!

David T.

> On Jan 21, 2018, at 9:16 PM, cicko  wrote:
> 
> In the documentation, page  Lots in Account
>   , the link
> in the following sentence:
> 
> "See Tutorial and Concepts Guide, Automatic Calculation of Capital Gain or
> Loss Using Lots for more details. "
> 
> points to a non-existing page. Is this something that should go to bugs or
> is a notification here enough?
> Cheers 
> 
> 
> 
> --
> Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

Documentation Update Instructions Wiki page

[David T. via gnucash-devel]

Hello,

I am sending out this message to alert folks that I have implemented a 
substantial update to the Documentation Update Instructions wiki page 
(https://wiki.gnucash.org/wiki/Documentation_Update_Instructions 
). 

In the past, I have noted the inconsistencies on this page, with one-time steps 
and OS-specific steps intermingled with repeated and generally-applicable ones. 
Most recently (last May), I identified several steps that I felt interrupted 
the procedure description and belonged elsewhere. In general, the page content 
is largely unchanged, although it has been rearranged substantially. I have 
attempted to offload some subjects to new pages, and cross-referenced other 
existing pages on the wiki (most notably the Git page). 

It is my hope that the rearrangement makes more sense for documentation 
contributors.

Highlights of the changes:

* I have moved information about Git from this page and added references 
pointing to https://wiki.gnucash.org/wiki/Git 
, 
* I removed some basic information about setting up a Bugzilla account, and 
moved other information about Bugzilla and added references pointing to 
https://wiki.gnucash.org/wiki/Bugzilla .
* I have moved information about setting up a build environment and added 
references pointing to 
https://wiki.gnucash.org/wiki/Initializing_Documentation_Build_Environment 

* I have moved information about creating a patch to 
https://wiki.gnucash.org/wiki/Preparing_A_Documentation_Patch 
, and added a 
reference to https://wiki.gnucash.org/wiki/Git#Pull_Requests 
.

I honestly hope that these changes are considered useful. I apologize for 
embedding such a lot of changes into one commit, but I didn’t see any easy way 
to stage it in smaller chunks.

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

Re: GnuCash Draft Concept Guide, or, Whose WIki Is This, Anyway?

[David T. via gnucash-devel]

Frank,

Thank you for your reply. 

I will start with an overall observation: I think that you and I see the 
GnuCash documentation realm in fundamentally different ways. 

I believe that the wiki and what I will refer to as the official documentation 
(defined as the Tutorial & Concepts Guide and the Help Manual) should primarily 
serve complementary roles, with information in the official docs taking 
precedence. To me, the wiki supplements the official docs. The wiki amplifies 
the official docs by providing information that is of limited interest to the 
broader community (such as methods for handling some esoteric accounting issue 
in GnuCash, or a technical issue on a specific platform). To me, information 
(such as the wiki glossary) should be removed in favor of material that is 
entered as part of the official documentation set.

I think that you see the wiki as a primary information source for users, and as 
such, you think it should contain its own more or less complete set of 
information about the program and its functions. I may be wrong about this, but 
I believe you have expressed opinions that seem to support this idea.

This means that information can be put in both the wiki and the official 
documentation without a problem for you. However, I do have a problem with 
keeping information in two places: it is a challenge to keep both sets of 
information up to date and in sync with one another—and it makes for more work 
for someone to maintain this synchronization. Your words below suggesting that 
the work is too much for you to manage only supports my point.

As for the specific example of the term “reconciliation’: You say that there is 
something missing from the documentation realm regarding this topic, and want 
to add information to the wiki and the glossary. I, however, see that 
Reconciliation has an entire section (4.4 in the Guide) dedicated to it. It is 
fully explained there as an aspect of Transactions. This section is also 
referenced in the chapter on Checkbooks, section 5.4. As you note, adding 
“reconciliation” to the glossary might be useful; that, however, doesn’t seem 
to me to be a legitimate reason to retain the Draft Concept Guide in its 
entirety.

On the issue of the Guide Glossary, I will note that this section is literally 
version 1, made completely based on the Wiki glossary and my own ideas of terms 
that could use definition for users. (I’ll note that I had thought that 
‘reconciliation’ was a common enough term that it didn’t need an entry in the 
Glossary. I am happy to have someone suggest otherwise, and will take steps to 
add it to the Guide Glossary). Since the Guide Glossary was based directly on 
the Wiki Glossary, I felt that the Wiki Glossary was superceded, and thus I 
deleted most of the Wiki content and added a note to consult the Guide 
Glossary. You overrode that decision, and I respected your wish to retain the 
duplicated information (despite the fact that I disagreed and still disagree 
with your assessment). 

I will note that it was never my intention that this version be considered the 
final one, and I would hope that others in the community with vested interests 
and different perspectives might have taken it upon themselves to contribute to 
the enhancement of the glossary to make it more complete (i.e., with more terms 
in it) and more useful (as in ensuring that first use of terms in the 
documentation referred to the glossary where necessary). 

There are methods for others to bring such enhancements to the docs—either by 
learning how to edit and submit documentation changes (as I somewhat have), or 
by submitting documentation bugs. 

As for scanning the Draft Concept Guide for such keywords, if I were to 
consider taking on such a task, I would go through the current versions of the 
documentation for such terms, rather than a ten-year old version. As I noted in 
another thread recently, that doesn’t sound like something I would want to 
spend my time on, however.

Finally, the GnuCash Wiki (and GnuCash in general) is no doubt a better place 
as a result of your contributions, and as you know, I have been quite 
collaborative in making some of your contributions read more idiomatically in 
English. In a reflection of my priorities, I have focused my energies in the 
Tutorial & Concept Guide. Given our different philosophies regarding the 
documentation roles, I think it might be better if *I* were the one to drop out 
of the Wiki world. I seem mostly to stir up trouble.

David


> On Dec 3, 2017, at 1:26 AM, Frank H. Ellenberger 
>  wrote:
> 
> Hi,
> 
> Am 01.12.2017 um 04:55 schrieb David Thomas:
>> Frank,
>> 
>> I am struggling right now to find the right way to bring up the issue of the 
>> Gnucash Draft Concept Guide, which still resides on the wiki.
>> 
>> As you know, I have proposed on numerous occasions (most recently, two and a 
>> half weeks ago) to have these pages removed from the 

GnuCash Draft Concept Guide, or, Whose WIki Is This, Anyway?

[David T. via gnucash-devel]

Frank,

I am struggling right now to find the right way to bring up the issue of the 
Gnucash Draft Concept Guide, which still resides on the wiki.

As you know, I have proposed on numerous occasions (most recently, two and a 
half weeks ago) to have these pages removed from the wiki, since they are out 
of date, inaccurate, poorly written, superceded, and can turn up in search 
results, giving users incorrect information about Gnucash and its features and 
functions. 

In that recent thread, four people responded to my request to remove the Draft 
Concept Guide. Only you appeared to support retaining these pages, although 
your primary concern was with the mechanical aspects of Google’s search 
algorithm, upon which I have no expertise to comment. (I will note that fixing 
one search engine result set does not preclude some OTHER search engine now or 
in the future from finding and returning these pages despite your best 
intentions). 

You actually offered to move these pages to your own user area, but John noted 
that might not actually hide the results.

Two days ago, I went to the wiki to search for information about creating 
reconciliation reports in response to a question on the user list, and when I 
entered “reconciliation” into the wiki’s OWN search box, 4 of the first 5 hits 
were for the Draft Concept Guide.

Since there had been no support for your position to keep the pages, and since 
you had had two and a half weeks to take whatever action you had proposed to do 
(and not taken any), I felt it was time to address the Draft Concept Guide 
issue directly. 

I did not delete the pages outright (since I do not have the rights to do 
that), but I did what I considered to be the next best thing, which was to 
replace all the text in those pages with the latin nonsense that printers have 
used for hundreds of years to mock up page layouts (“Lorem ipsum”). I even made 
sure to retain the various structural elements in the pages, going so far as to 
replace headings and bullet points with latin phrases of similar length.

Since, as far as I understand, your only reason for retaining these pages is to 
serve as some sort of model for the Gnucash community to use for wiki pages, my 
technique allowed these model pages to be retained *without* their turning up 
in any search results, anywhere. So, that’s the best of both worlds, right?

Apparently not, as within hours, you had gone and reverted all my changes.

So, I have a few questions to ask of you, Frank, and of the community.

1) First, Frank: What exactly is so special to you about these pages? Why do 
you insist that they remain forever on the wiki? The only reason I have heard 
from you is this idea that the pages could provide wiki page template examples. 
But, my most recent changes preserved the template aspect without retaining the 
problematic language—and you still reverted the changes. So, there seems to be 
something *else* with these pages that makes you feel so protective. What is 
it? My recent changes seem to prove that there is something in the text itself 
that you are attached to. Can you explain clearly what that attachment is?

2) Frank, in the past, you have chastised me for reverting changes that you had 
made on wiki pages, and informed me that it is considered rude to do so. So, 
why are you so consistently rude to me? This is not the first time that you 
have reverted my changes.

3) To the community: Whose Wiki is this, anyway? I have presented to the 
community on separate occasions my reasons for wanting to remove these pages, 
and I have heard from most of the developer community that these pages could be 
removed. The only person opposed to this appears to be Frank. However, Frank’s 
wishes on this issue (and others regarding the Wiki) apparently take precedence 
over everyone else’s, such that if Frank doesn’t agree, then it won’t happen. 
That doesn’t sound much like a collaboration.

4) To the community: Again, I put the question to the group: what purpose and 
procedures are supposed to apply to the wiki? There appear to be numerous 
unwritten rules about how to engage with the process (see for example question 
2), and apparently I have broken those rules in this and other cases. It is 
frustrating to be encouraged to contribute to the wiki only to have those 
contributions rejected summarily. Establishing clear procedures and guidelines 
for contribution and workflow management seem to be in order—certainly if you 
expect non-developers to contribute back to the GnuCash community. 

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

Re: Translation...

[David T. via gnucash-devel]

> On Nov 14, 2017, at 4:15 AM, Frank H. Ellenberger 
> <frank.h.ellenber...@gmail.com> wrote:
> 
> Hi all,
> 
> Am 11.11.2017 um 07:26 schrieb David T. via gnucash-devel:
>> Thomas,
>> 
>> I am not an expert on any of this, but I think that referring to a “split” 
>> as a “transaction line” ("ligne de transaction”) would be the most 
>> appropriate. 
>> 
>> GnuCash uses the term “split” in a decidedly specific manner—which the Guide 
>> takes pains to explain (cf. 2.2.3 and the Glossary, for example). I believe 
>> that the "transaction line” terminology best reflects the underlying concept.
> 
> David, can you check the guide so that always the first occurrence of
> the glossary entries in the text is linked to the glossary entry?
> 

I’ll take it into consideration, although that task would not be something I 
particularly enjoy.

>> 
>> David T.
>> 
>>> On Nov 11, 2017, at 4:08 AM, Christopher Lam <christopher@gmail.com> 
>>> wrote:
>>> 

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

Please, Oh, Please, Can we delete the (10 year old and counting) Draft Concept Guide on the Wiki?

[David T. via gnucash-devel]

Okay,

Once again, I search Google for some aspect of GnuCash functionality, and ONCE 
AGAIN, one of the top hits there is the 10 year old Draft Concept Guide lurking 
on the wiki. Not the ACTUAL, CURRENTLY-MAINTAINED Tutorial and Concept Guide. 
No. The ***Draft Concept Guide*** (ostensibly invisible on the gnucash wiki).

As my subject line suggests, I believe this set of pages should BE REMOVED FROM 
THE WIKI. I know, I know—I’ve said it before. But, since the pages are still 
there, it bears repeating.

I continue to question what purpose this inaccurate, outdated, unmaintained, 
and misleading set of pages serves. The only reason I have heard is that they 
might serve as a set of templates for other pages. I think that this is a 
specious argument; first, there does not seem to be much on the wiki that uses 
many wiki features; and second, if users need more technical guidance, there 
are numerous sources online to serve as guidance.

I say, “Draft Concept Guide—BEGONE!”

David

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

Re: Translation...

[David T. via gnucash-devel]

Thomas,

I am not an expert on any of this, but I think that referring to a “split” as a 
“transaction line” ("ligne de transaction”) would be the most appropriate. 

GnuCash uses the term “split” in a decidedly specific manner—which the Guide 
takes pains to explain (cf. 2.2.3 and the Glossary, for example). I believe 
that the "transaction line” terminology best reflects the underlying concept.

David T.

> On Nov 11, 2017, at 4:08 AM, Christopher Lam  
> wrote:
> 
> Forwarding to devel who will have more idea about the specifics of
> translating. I'm not a core developer.
> 
> The gnucash UI already has French UI -- see
> https://www.gnucash.org/docs/v2.6/C/gnucash-help/chang-lang.html about
> switching language. The french term being used is 'transaction répartie'.
> 
> https://wiki.gnucash.org/wiki/Translation will explain how to contribute to
> translations, especially the tutorial and concepts guide.
> 
> Your help is very welcome!
> 
> -- Forwarded message --
> From: Thomas Mann 
> Date: 10 November 2017 at 22:22
> Subject: Re: Translation...
> To: Christopher Lam 
> 
> 
> Dear Christopher,
> 
> I would be happy to help. How could I do that ?
> 
> I had a look to the .po file, last night. I felt like making lots of
> changes. But, what about people who get used of the current translation? It
> looks important to me not to disturb those who feel comfortable (because
> used to) entering their daily transactions.
> 
> Creating and using my own translation to feel more secure with these
> strange accounting rules is possible. But it looks a bit weird.
> 
> I have an extra problem with the translation of "GnuCash Tutorial and
> Concepts Guide". I am intending to complete it to part II included (the
> draft translation is achieved to chapter 7). The vocabulary is very
> important. I think the concepts are complicated enough to deserve easy to
> read translation. Unfortunately, some concepts are not common to the
> languages.
> 
> For example, I look in dictionaries, accounting books for a translation of
> the word "split". It seems that French-speaking accountants did not feel a
> need for that very word. I'm not sure it is a good idea for some software
> to introduce a foreign word that would rarely be used elsewhere. The word
> "split" can be avoided by distributing its meaning, on the one hand "spread
> transaction" and, on the other hand "transaction line".  This introduces
> major differences in the text that I don't want to impair.
> 
> These difficulties, which are the reason I decided to begin translating,
> have been troubled when starting to perform the exercises to include
> "translated" screen shots.
> 
> So the manual translation must rely on 1) the source English text, 2)
> accounting vocabulary, 3) software translation. For now, this is a very
> unstable situation.
> 
> As I said at the top of this message, "I would be happy to help". But, I
> don't want to be a load for GnuCash Project, a troublemaker for current
> users...
> 
> I'm interested in your opinion.
> 
> Regards,
> 
> Le 10/11/2017 à 12:16, Christopher Lam a écrit :
> 
> Hi Thomas
> 
> 
>>   Two major problems:
>> * The accounting vocabulary has been mixed up and add difficulties to
>>   the simple work of understanding accounting concepts. An example:
>>   the name given to the registers is, in fact, the name accountants
>>   give to the main book that sums up all the transactions of all
>>   accounts. Another example, the word "Transaction" is not used in
>>   this context, and have a different meaning (transaction is more
>>   like a "deal"). Examples are numerous. It is so confusing that I
>>   thought it could be useful to create my own .po file and recompile
>>   the whole thing.
>> 
> 
> It will be useful to have a native speaker explain concepts and use correct
> words. Thank you for your contribution!
> 
> 
>> 
>> * But another problem appears : some columns have been inverted. For
>>   example,asset account register columns have weird title AND are
>>   reversed. So, it is difficult to understand the titles and the user
>>   cannot rely on "Debit" on left and "Credit" on right. How is that
>>   possible?
>> 
>> 
> Are you relating to the register for a bank account? The register
> debit/credit, for most individuals, is confusing, and does not match the
> bank statement which presents the bank's (well, duh) statement of your
> account, rather than your own statement. The following explains it all:
> 
> http://www.finweb.com/banking-credit/debit-reversed-in-
> banking-accounting.html#axzz4y1epdNbF
> https://www.accountingcoach.com/debits-and-credits/explanation
> https://en.wiktionary.org/wiki/debit
> 
> In formal accounting, for an asset account such as bank, debits will
> *increase* it. But the usual bank statement received by the account holder
> will state the opposite. Hence, 

Re: Branching unstable

[David T. via gnucash-devel]

If we are talking about report work, will bug 773198 get addressed here?

> On Sep 13, 2017, at 7:36 PM, Derek Atkins  wrote:
> 
> Geert Janssens  writes:
> 
>> On woensdag 13 september 2017 06:27:23 CEST John Ralls wrote:
>>> I think we’re pretty close to being ready to create the “unstable” branch
>>> from which we’ll do the 2.7 releases. There remain a couple of minor test
>>> issues to resolve but I hope to get those done in the next day or two, with
>>> a 2.7.0 release this weekend unless something blows up in my face.
>>> 
>> Good job!
>> 
>>> Does anyone else have anything hanging out that should get committed/merged
>>> before the branch gets created?
>>> 
>> I don't have anything critical to merge still. I plan to do some more 
>> bugfixing, but that shouldn't block creating the unstable branch. In 
>> particular the python bindings are acting up.
>> 
>> Perhaps Christopher Lam's report work can still be merged before the 
>> unstable 
>> branch is created.
> 
> Any chance Doug's reports could be added, too?
> 
>> Geert
> 
> -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


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

Re: New Account Dialog

[David T. via gnucash-devel]

Alex, 
Nice to see this moving forward. I think John's comment about the combo for 
parent  might be good. 
Personally, I think the account name and code would be better placed first; my 
opinion is that I have accessed this dialog box to add a new account, and not 
its parent. Thus, to me it makes more sense to enter that first, and then 
parent info. 
This order feels to me like me first asking you your mother's name when I meet 
you on the street. It just feels odd. 
David
 
 
  On Sat, Sep 2, 2017 at 5:25, John Ralls wrote:   
> On Sep 1, 2017, at 4:25 PM, Alex Aycinena  wrote:
> 
> (note: I used an 'edit account' dialog instead of a 'new account' dialog, 
> without thinking, but it shouldn't make any difference, it just doesn't have 
> an opening balance notebook tab):

It also has a label instead of a combo box for commodity.

Since GtkComboBoxes can display tree views as well as list views, how about 
making the parent account a combo box too?

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

Re: Intended behavior of automatic decimal point (bug 120940)

[David T. via gnucash-devel]

According to Wikipedia, there is no single format predominant. The green areas 
in the picture below use commas, while the blue use a period. If the picture 
doesn’t make it through, Europe, West Africa and South America predominantly 
use commas, whereas The US, UK, East/Southern Africa, India, China and 
Australia use the period.

Your markup and changes are fine, although I think “decimal sign” would be 
simpler as just “decimal,” leaving “decimal separator” in the second spot.

Finally, can I assume that this function correctly inserts a comma when the 
locale recommends it, or is it always a period?

David



> On Jul 30, 2017, at 3:51 AM, Frank H. Ellenberger 
>  wrote:
> 
> Am 29.07.2017 um 13:13 schrieb David T.:
>> How about:
>> 
>> Note: When a calculation is entered in the Amount field, the decimal is 
>> added to every operand that omits a decimal.
>> 
>> David
> 
> 
>  When a calculation is entered in the
>Amount field, the decimal sign is inserted into
>every operand that omits a decimal separator.
>  
> 
> 
> might be more precise.
> 
> BTW: are all english speaking regions using the point as decimal separator?
> 
> Frank

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

Re: Intended behavior of automatic decimal point (bug 120940)

[David T. via gnucash-devel]

How about:

Note: When a calculation is entered in the Amount field, the decimal is added 
to every operand that omits a decimal.

David

> On Jul 29, 2017, at 12:43 AM, Frank H. Ellenberger 
>  wrote:
> 
> Hi all,
> 
> Am 28.07.2017 um 14:28 schrieb Christoph R:
>>> I agree that the only sane way to have auto-decimal is to disable it if the 
>>> input is a formula. The other sane approach is to remove it completely.
>> 
>> I cast my vote again: I never found the current behaviour buggy. I actually 
>> think it is pretty consistent: Any number without a point is shifted. 
>> Anything with a point is normal. Easy to understand for me.
>> 
>> And I would hate to loose the auto-decimal functionality. It saves me a ton 
>> of typing.
>> 
>> Cheers,
>> Christoph
> 
> ... like the addition machines, the accountants used in my childhood.
> 
> Perhaps one of you could attach an improvement of the documentation to
> the bug, to make it clear.
> 
> Regards
> Frank
> ___
> gnucash-devel mailing list
> gn

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

Re: Wiki collissions; was: GnuCash page Git has been changed by Sunfish62

[David T. via gnucash-devel]

> On Jul 28, 2017, at 10:24 AM, Frank H. Ellenberger 
>  wrote:
> 
> Hi David,
> Am 28.07.2017 um 05:45 schrieb David T.:
>> Frank,
>> 
>> I beg to differ about reverting your edits. I have never knowingly reverted 
>> any of your edits. (I have had you revert mine, however) 
> 
> ,,, after you replaced wiki:Glossary by a link to Guide/Glossary which
> had only half of its content. ;-) And I reinserted your complements
> after the revert.

My point is that *I* haven’t reverted changes; *you* have. I don’t plan on 
rehashing our differences on the content of  that page.

> My suggestion for Wiki collission:
> 
> When you get the collission meassage, copy your changeset to the talk
> page of the other user and ask him to apply it.
> 
> If you agree, this yould be written to Wiki_Tips or better a new page
> Wiki_Policy.
> 

As I stated before, I was unaware of any collisions in the first place; had I 
been aware of them, I would have waited for you to complete your edits before 
attempting my own. Thus, I don’t see a need for a policy on this—although I 
would welcome a more general discussion about wiki policy, since there are 
definitely differing ideas on what should be in the wiki, how that information 
should be maintained over time, and how it should coordinate with other forms 
of documentation.

David

>> 
>> David
> 
> Frank

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

Re: Patches versus Pull Requests

[David T. via gnucash-devel]

Thanks John.

I will look at ways to rewrite these sections to reflect current practices and 
preferences. It probably will mostly entail switching the sequence of 
information (putting pull requests first), and then offloading the details of 
the patch process into a separate page for those still wishing to find that.

David

> On Jul 27, 2017, at 10:28 PM, John Ralls <jra...@ceridwen.us> wrote:
> 
> 
>> On Jul 27, 2017, at 9:45 AM, David T. via gnucash-devel 
>> <gnucash-devel@gnucash.org> wrote:
>> 
>> Hello,
>> 
>> In going over some of the wiki information, I ran into a section that goes 
>> into some detail about preparing patches for submission. 
>> 
>> While this is, no doubt, still a valid way of submitting changes, is this: 
>> a) how the project prefers such changes to be submitted, and b) something 
>> that anyone is actively using?
>> 
>> If the answers are “no” and “not many,” then perhaps this information could 
>> be removed from the wiki?
> 
> It's still valid and although we do see more pull requests than patches on 
> bugs we still need the procedure available as long as we continue to use 
> Gnome's bugzilla.
> 
> Besides if one is doing a drive-by patch for a bug it's a lot easier to just 
> run git format-patch than to fork gnucash in Github and create a PR.
> 
> Regards,
> John Ralls
> 

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

Re: GnuCash page Git has been changed by Sunfish62

[David T. via gnucash-devel]

Frank,

I beg to differ about reverting your edits. I have never knowingly reverted any 
of your edits. (I have had you revert mine, however) 

It is true that I have changed things you’ve written, to improve their English 
grammar and readability. I wouldn’t believe that such changes would require any 
written justifications, beyond the general change name “Editing to improve 
readability” which is what I have been doing. If you need me to explain the 
changes to you, point me to one, and I will gladly explain my choices.

In this particular case, I received a notice that the Git page on the wiki had 
been changed by your addition of the sentence explaining the github repository. 
I looked at that (single) change on the wiki, and thought the sentence belonged 
in a different spot. Note that I didn’t revert that edit; I moved the text. 
Further examination of the text turned up areas that I thought needed 
improvement with the text flow. So I began to edit the content to reflect my 
ideas. 

I was not aware that:
1) you were still in process of changing the page, 
2) the wiki would alert me of your first edit, but none of the following ones, 
or
3) the earlier version would not indicate that there were later edits to 
consider.

As a consequence, I edited the earlier form of the page, rather than your last 
version. I apologize for that. I will be more careful in the future.

David

> On Jul 28, 2017, at 2:29 AM, Frank H. Ellenberger 
>  wrote:
> 
> David,
> 
> because it is not the first time you are reverting a bunch of my
> commits, I want to ask you for your reason:
> 
> a) was it by accident - using some unsynchronized offline editor, or
> b) you disliked my changes, then you should explain it, or
> c) you dislike me or
> d) what else?
> 
> Regards
> Frank
> 
>  Weitergeleitete Nachricht 
> Betreff: GnuCash page Git has been changed by Sunfish62
> Datum: Thu, 27 Jul 2017 16:38:19 +
> Von: GnuCash 
> Antwort an: bureauc...@gnucash.org
> An: Fell 
> 
> Dear Fell,
> 
> The GnuCash page Git has been changed on 27 July 2017 by Sunfish62, see
> https://wiki.gnucash.org/wiki/Git for the current revision.
> See
> https://wiki.gnucash.org/wiki/index.php?title=Git=next=12840
> to view this change.
> 
> See https://wiki.gnucash.org/wiki/index.php?title=Git=0=12840
> for all changes since your last visit.
> 
> Editor's summary: /* Improve sequence of text */
> :

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

Patches versus Pull Requests

[David T. via gnucash-devel]

Hello,

In going over some of the wiki information, I ran into a section that goes into 
some detail about preparing patches for submission. 

While this is, no doubt, still a valid way of submitting changes, is this: a) 
how the project prefers such changes to be submitted, and b) something that 
anyone is actively using?

If the answers are “no” and “not many,” then perhaps this information could be 
removed from the wiki?

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

Re: Intended behavior of automatic decimal point (bug 120940)

[David T. via gnucash-devel]

Christoph,
I disagree, and clearly the people on the bug don't see it that way either. 
I think of the decimal placement as applying to the final number in the field 
(as a sort of edit mask, if you will), rather than a preprocessing function 
that would apply to every element in an equation. 
The current behavior yields different decimal placement results in the same 
register, which is highly confusing. 
Put another way, the current behavior would result in the decimal being moved 
four places on an entry like "1200/35", which would be at variance with the 
actual setting. 
I can't see how that is appropriate. 
David

 
 
  On Thu, Jul 27, 2017 at 11:04, Christoph R<subscriptions+lis...@rohland.net> 
wrote:   I do not even see this as a bug. Any number without a decimal point is 
divided by 100. Which makes the input “20.44/2” in fact 20.44/0.02 which is 
1,022.00
Cheers,
Christoph

Am 26.07.2017 um 09:58 schrieb David T. via gnucash-devel 
<gnucash-devel@gnucash.org>:
Sumit, 
As I understand it, the example you gave  (560 becomes 5.60) is intended 
behavior. And, as far as I am concerned, the explanation in the help is 
sufficient, if not inspiring. 
It seems to me the problem in the underlying bug is that the decimal algorithm 
needs to be applied after any calculations, but that is not how it's being 
done. The age of the bug suggests that the feature is not heavily used, or that 
users have worked around the oddity. 
David



 On Wed, Jul 26, 2017 at 11:50, Sumit Bhardwaj<bhardw...@gmail.com> wrote:   
​Hi,

In an attempt to fix a long-standing bug (
https://bugzilla.gnome.org/show_bug.cgi?id=120940), I looked at the code
and have a question on intended behavior of automatic decimal point.

From the doc (http://gnucash.org/viewdoc.phtml?doc=help), I see this
description for automatic decimal point.

*Automatic Decimal Point:* This option will automatically insert a

decimal point into numbers you type in.​

It's not clear from the help that "560" will be converted to "5.60" with
automatic decimal points set to 2. Is that the intended behavior? If so,
should we edit the help?

There is a bug in handling the fractions when auto-decimal points. I can
try to fix that, but wanted to get the developers' take on the intended
behavior first.

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

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

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

Re: Intended behavior of automatic decimal point (bug 120940)

[David T. via gnucash-devel]

Sumit, 
As I understand it, the example you gave  (560 becomes 5.60) is intended 
behavior. And, as far as I am concerned, the explanation in the help is 
sufficient, if not inspiring. 
It seems to me the problem in the underlying bug is that the decimal algorithm 
needs to be applied after any calculations, but that is not how it's being 
done. The age of the bug suggests that the feature is not heavily used, or that 
users have worked around the oddity. 
David

 
 
  On Wed, Jul 26, 2017 at 11:50, Sumit Bhardwaj wrote:   
​Hi,

In an attempt to fix a long-standing bug (
https://bugzilla.gnome.org/show_bug.cgi?id=120940), I looked at the code
and have a question on intended behavior of automatic decimal point.

From the doc (http://gnucash.org/viewdoc.phtml?doc=help), I see this
description for automatic decimal point.
> *Automatic Decimal Point:* This option will automatically insert a
decimal point into numbers you type in.​

It's not clear from the help that "560" will be converted to "5.60" with
automatic decimal points set to 2. Is that the intended behavior? If so,
should we edit the help?

There is a bug in handling the fractions when auto-decimal points. I can
try to fix that, but wanted to get the developers' take on the intended
behavior first.

Thanks,
Sumit
___
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: OT "Concept Guide"; was: Time Frame on Wiki Edits

[David T. via gnucash-devel]

Frank, 
Indeed, I am wrong. I apologize for the inaccurate noise. 
David

 
 
  On Wed, Jun 21, 2017 at 7:54, Frank H. 
Ellenberger<frank.h.ellenber...@gmail.com> wrote:   Hi David,

Am 20.06.2017 um 04:59 schrieb David T. via gnucash-devel:
> [Aside: I will note that this link—present on the Wiki main landing page—is a 
> direct contradiction to Frank’s assertions that this outdated erroneous 
> information is hidden to the general public.] 

You are confounding "Concept Guide draft" /Overview etc., which became
part of the docs [1], with [How to work on the] "Concept Guide" both by
former documenter BengtT from 2006 . The latter is linked and got
regular updates by the respective documenters.

[1]
https://github.com/Gnucash/gnucash-docs/commit/fcd8658edf9140ab1e54156bac3551c23ba3b9a1
ff.

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

Re: Time Frame on Wiki Edits

[David T. via gnucash-devel]

Adrien,

Thanks for the input.

If it were up to me, I would delete the wiki Concept Guide and all its related 
pages and references, but others in the community disagree with me on that. 
[Aside: I will note that this link—present on the Wiki main landing page—is a 
direct contradiction to Frank’s assertions that this outdated erroneous 
information is hidden to the general public.] 

As for the other two sections, it seems to me that we as a community need to 
have a clear sense of what we want to do with old discussions about features 
that may or may not have been implemented. I believe that the history can be 
useful, but the way it is integrated right now is troubling to me. The 
information gets into the wiki in current discussion form, and then never gets 
turned into historical narrative, making it seem as if discussions from 2002 
about what budgeting might be (in 2002) are actually current. 

David

> On Jun 20, 2017, at 12:07 AM, Adrien Monteleone <adrien.montele...@gmail.com> 
> wrote:
> 
> David,
> 
> It seems the edits you committed took care of most of the 
> spelling/grammatical errors I noticed. I fixed a remaining one in the 
> External Documentation section.
> 
> Concerning content, do we still need to point to the three ‘particular 
> enhancement’ discussions at the bottom of the page? If anything, perhaps they 
> should be listed under Old Discussions since all three of them have been 
> implemented and their pages are dated by several years to a decade. I’d also 
> think the Concept Guide link should perhaps have more to do with 
> Documentation than an application feature. Perhaps it should be under 
> Developing Documentation, or even not on this page at all and linked from the 
> Developing Documentation page.
> 
> Just a thought.
> 
> Regards,
> Adrien
> 
>> On Jun 14, 2017, at 9:01 AM, David T. <sunfis...@yahoo.com> wrote:
>> 
>> Thanks for the feedback. I’ve modified the page and incorporated most of 
>> your changes. If there are specific typos or grammatical errors, could you 
>> either fix them or point them out? My eyes aren’t what they used to be!
>> 
>> David
>> 
>>> On Jun 14, 2017, at 12:02 AM, Adrien Monteleone 
>>> <adrien.montele...@gmail.com> wrote:
>>> 
>>> I see a few typos and grammatical errors, so I wouldn’t say it’s ready for 
>>> publication yet.
>>> 
>>> As for organization, perhaps change [Scripting and Programming] to 
>>> [“Advanced” Usage] or [“Advanced” Usage - Scripting & Programming]
>>> 
>>> I’d expect to find the info on Logging and Stack Trace to be either under 
>>> Help or Filing Bugs. You could then probably eliminate the odd sounding 
>>> ‘Error Seaching’ (sic) heading.
>>> 
>>> Also the way [Getting Involved in the Project] reads, the rest of the 
>>> material that follows should be nested under it, which might be odd. 
>>> Perhaps just keep the sentence but remove that heading entirely. It doesn’t 
>>> seem necessary. Or since all of those topics including developing code are 
>>> "getting involved” replace the main heading—[Developing for GnuCash] with 
>>> [Getting Involved in the Project] or something similar like [Contributing 
>>> to GnuCash]. The other headings and text can remain as is.
>>> 
>>> Overall though, this is laid out much better than the current version.
>>> 
>>> -Adrien
>>> 
>>> 
>>>> On Jun 13, 2017, at 11:17 AM, David T. via gnucash-devel 
>>>> <gnucash-devel@gnucash.org> wrote:
>>>> 
>>>> Hello,
>>>> 
>>>> Two weeks ago, after a flurry of discussion in this list, I and Don 
>>>> (doncram) worked to put together a modified wiki landing page, which was 
>>>> placed as a sandbox page at https://wiki.gnucash.org/wiki/GnuCash/sandbox 
>>>> <https://wiki.gnucash.org/wiki/GnuCash/sandbox>.
>>>> 
>>>> Since that time, there has been no further activity on any front, and 
>>>> although two weeks is not a very long time to let this season (as it 
>>>> were), I do wonder whether the Developer team has any sense of what amount 
>>>> of time constitutes “the right” amount of time for such a proposal to sit 
>>>> before the changes are sent live. I’d like to get the page pushed out 
>>>> before it gets lost in the mists of time…
>>>> 
>>>> David
>>>> 
>>>> @doncram: once it’s time to move this along, how exactly does one convert 
>>>> the sandbox to its real counterpart?
>>>> ___

Re: Website Platform Discussion

[David T. via gnucash-devel]

Derek,

> On Jun 16, 2017, at 10:33 PM, Derek Atkins  wrote:
> 
> Adrien Monteleone  writes:
> 
>>> A side effect of the content being in a db rather than in git is it is no 
>>> longer stored in a distributed way. So it will be important to implement a 
>>> backup plan for the data.
>> 
>> The site host should provide a facility for this either through
>> cPanel/Plex, or you can set a cron job via SSH. Many have options to
>> schedule backups to an offsite FTP server.
>> 
>> You’d need to regularly back up both the db and the site structure.
> 
> Okay, so... what's the actual benefit of migrating www.gnucash.org to a
> CMS?  Right now we can easily update the website remotely, have
> translations, images, etc.  And it doesn't require Linas to do much
> maintenance work.  The content is quazi-static, so it really doesn't
> need a lot of updates.  It's not like the application is changing it's
> look at feel every couple months!
> 

As the one who started this, I’d say the immediate payoff with regard to the 
issues you raise is limited. However, I had made some suggestions on Bugzilla 
about changing the website (and possibly the wiki as well) that were beginning 
to take on more substantial nature. At that point, the idea of looking more 
generally at ways to facilitate change on the website/wiki seemed appropriate.


I will note that one of the problems I see with the website/wiki presence is 
precisely its static nature. Pages and information seem to get on the sites and 
never change or get updated. A number of the wiki pages I was just looking at 
had references to “new” features for v1.8, along with links to discussions in 
the mailing lists ca. 2002. There were references to resources that have long 
ago disappeared off the Internet, as well as discussions about issues that are 
no longer relevant to GnuCash in 2017—like discussions about code to create SQL 
data from an XML data file, which while perhaps still interesting, are 
nonetheless rendered rather moot with the incorporation of the SQL back end in 
2.4.

As for the ongoing maintenance of a cms, I agree that it can be a pain. 
However, at least with Drupal, I find the process pretty quick to manage (in 
fact, I just installed an update today), and assuming that the GnuCash site 
would continue to be a basic site, it would likely not require many additional 
modules—thus keeping the update routines simpler. Moreover, with a bundled cms, 
you have web developers who are maintaining awareness of security issues and 
pushing out fixes for them. In this day of increased threat vectors online, can 
we be sure that the GnuCash site is immune to these new threats?

Whether a new platform would encourage the community to maintain a vibrant web 
presence or not is of course debatable. but I think it’s a fair one to have.

David


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

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

Website Platform Discussion

[David T. via gnucash-devel]

In Bug 783240, I made some suggestions about modifying the website structure to 
improve the new user experience. As the discussion has developed, the 
implications of some of the suggestions have become more substantial, and John 
Ralls suggested that we bring the discussion to the devel list for broader 
discussion. Most significantly, John raised the possibility of changing the 
website from being a hand-coded PHP site, to one that uses a content management 
system (CMS). 

I think a CMS would be a good idea, assuming that the GnuCash website’s look 
and feel can be reasonably approximated—or an alternative look and feel can be 
accepted as the new norm. Having built websites manually, then coding my own 
php sites, and finally using a CMS, I can vouch for the benefits of a CMS. 
Creating and managing content and features is much easier with an established 
CMS. Creating a new version in a CMS that is tightly locked down would allow 
the focus to be on the content but still allow a broader number of contributors 
to possibly add to the GnuCash web presence—something that the current system 
doesn’t do well. As I see it, the GnuCash website doesn’t offer any significant 
special formatting or whiz-bang web features, so I think its basic content 
could be ported without a herculean effort. 

Two major questions occur to me: 

How would the current version control method of website management port over to 
a CMS? and,
How would translations be handled in a CMS? 

I am sure there are other big questions as well...

There are numerous CMS platforms out there; I am personally familiar with 
Drupal, and know that it can quickly provide a robust and feature-laden 
website. It seems to have tools for managing page translations, although I 
admit to only a superficial glance at what’s there, and I am not sure how that 
issue would get handled for the GnuCash use case. It even has the potential for 
providing a wiki experience, which might allow these two pieces of the GnuCash 
web experience to become more closely linked.

I welcome your comments!

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

Re: Time Frame on Wiki Edits

[David T. via gnucash-devel]

Thanks for the feedback. I’ve modified the page and incorporated most of your 
changes. If there are specific typos or grammatical errors, could you either 
fix them or point them out? My eyes aren’t what they used to be!

David

> On Jun 14, 2017, at 12:02 AM, Adrien Monteleone <adrien.montele...@gmail.com> 
> wrote:
> 
> I see a few typos and grammatical errors, so I wouldn’t say it’s ready for 
> publication yet.
> 
> As for organization, perhaps change [Scripting and Programming] to 
> [“Advanced” Usage] or [“Advanced” Usage - Scripting & Programming]
> 
> I’d expect to find the info on Logging and Stack Trace to be either under 
> Help or Filing Bugs. You could then probably eliminate the odd sounding 
> ‘Error Seaching’ (sic) heading.
> 
> Also the way [Getting Involved in the Project] reads, the rest of the 
> material that follows should be nested under it, which might be odd. Perhaps 
> just keep the sentence but remove that heading entirely. It doesn’t seem 
> necessary. Or since all of those topics including developing code are 
> "getting involved” replace the main heading—[Developing for GnuCash] with 
> [Getting Involved in the Project] or something similar like [Contributing to 
> GnuCash]. The other headings and text can remain as is.
> 
> Overall though, this is laid out much better than the current version.
> 
> -Adrien
> 
> 
>> On Jun 13, 2017, at 11:17 AM, David T. via gnucash-devel 
>> <gnucash-devel@gnucash.org> wrote:
>> 
>> Hello,
>> 
>> Two weeks ago, after a flurry of discussion in this list, I and Don 
>> (doncram) worked to put together a modified wiki landing page, which was 
>> placed as a sandbox page at https://wiki.gnucash.org/wiki/GnuCash/sandbox 
>> <https://wiki.gnucash.org/wiki/GnuCash/sandbox>.
>> 
>> Since that time, there has been no further activity on any front, and 
>> although two weeks is not a very long time to let this season (as it were), 
>> I do wonder whether the Developer team has any sense of what amount of time 
>> constitutes “the right” amount of time for such a proposal to sit before the 
>> changes are sent live. I’d like to get the page pushed out before it gets 
>> lost in the mists of time…
>> 
>> David
>> 
>> @doncram: once it’s time to move this along, how exactly does one convert 
>> the sandbox to its real counterpart?
>> ___
>> gnucash-devel mailing list
>> gnucash-devel@gnucash.org
>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> 
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

Time Frame on Wiki Edits

[David T. via gnucash-devel]

Hello,

Two weeks ago, after a flurry of discussion in this list, I and Don (doncram) 
worked to put together a modified wiki landing page, which was placed as a 
sandbox page at https://wiki.gnucash.org/wiki/GnuCash/sandbox 
.

Since that time, there has been no further activity on any front, and although 
two weeks is not a very long time to let this season (as it were), I do wonder 
whether the Developer team has any sense of what amount of time constitutes 
“the right” amount of time for such a proposal to sit before the changes are 
sent live. I’d like to get the page pushed out before it gets lost in the mists 
of time…

David

@doncram: once it’s time to move this along, how exactly does one convert the 
sandbox to its real counterpart?
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Wiki/Website Suggestions

[David T. via gnucash-devel]

Hello,

I just posted Bug 783240 to suggest some improvements to the home page. I am 
suggesting these changes because of discussions and developments with the wiki 
and its landing page. 

It seems to me that the website Home page and the Documentation page include a 
lot of information that overlaps with the wiki, and I wonder if the roles and 
content for these various pages couldn’t be reconsidered. I will note that a 
number of the links on the website home page already link to the wiki, and I 
think this process could be extended.

Specifically, I think these two website pages should focus primarily on getting 
the new user informed at a macro level, whereas the wiki page(s) should point 
the user to information at a more detailed level. Mostly this means that the 
web pages would point to the wiki pages for those looking for more detailed 
assistance.

Ideally, the information in each place would support, reinforce, and refer to 
the information in the other, rather than duplicate it. Removing the 
duplication will make maintenance easier as well. Bug 783240 is what I see as a 
first step toward this; I would expect to modify the wiki landing page some 
more and turn it into a brief introductory narrative. Then the detailed lists 
might be moved to separate subpages, which would also allow the web site to 
link to these resources directly.

I welcome comments, both here and on the bug.

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

Re: Wiki Landing Page

[David T. via gnucash-devel]

Don, 
Your points about the Documentation web page are well-taken. I will consider 
what changes might be made there to better direct new users--in a separate 
thread. 
FWIW,  I am sunfish62 on the wiki. 
David

 
 
  On Tue, May 30, 2017 at 9:14, doncram wrote:   
To David T. and John --- Okay I have to apologize.  I didn't look carefully at 
the "Documentation" page at the website.  Each time I went there, I saw just 
the first section, whose entire text is:

There are two major GnuCash documentation packages to help users:
   
   - The Help Manual
   - The Tutorial and Concepts Guide

The Help Manual is designed to be a quick reference of how to accomplish 
specific tasks and how to use the features in GnuCash. The Concepts Guide is 
designed to be an in depth guide to the concepts behind using GnuCash with a 
tutorial to show how to put those concepts into practice.

Additionally, you can talk to someone via IRC at irc.gnome.org channel #gnucash 
about your question. Another resource is the English or Deutsch GnuCash wikis.

You can also send an email to the gnucash-user mailing list if you cannot find 
a satisfactory answer to your question within either the Help Manual or the 
Tutorial and Concepts Guide. We want feedback from you, it is also through your 
comments that we know how to improve the documentation.

GnuCash's documentation has been created by its community. See the Writing 
Documentation page if you are interested in contributing to this effort.

​That seemed to wrap it all up, i thought it was done, I did not see the 
following sections which have other stuff.  So I was completely wrong in my 
comments.  (It is a possible small side thing, that maybe the "Documentation" 
page there is confusing, because it confused me, but that is off-topic here.)  
I am sincerely sorry for being confused and causing confusion.
About the current draft webpage, at 
http://wiki.gnucash.org/wiki/GnuCash/sandbox, I am glad to see that "sunfish62" 
edited there already, fixing or improving from how I had left it.  Perhaps it 
is good to go now.  I think I should bug out now.
sincerely,Don

On Mon, May 29, 2017 at 10:45 PM, David T.  wrote:

Don,

On May 29, 2017, at 10:24 PM, doncram  wrote:
About the suggested content now at http://wiki.gnucash.org/wiki/ 
GnuCash/sandbox, one objection that I have is that it refers readers to a 
Documentation page at the main gnucash.org website which provides nothing for 
them (it only contains links to the Help manual and the Tutorial and Concept 
Guide, and no other documentation). Specifically, the current content includes:
"For the latest documentation (i.e., unstable releases of the documentation), 
or to get documentation for other languages or earlier releases, see the 
[http://www.gnucash.org/docs. phtml Documentation] page on the GnuCash.org 
website."
It seems like a false statement, that a reader could get latest documentation 
or anything else there.  The content already does link to versions of the Help 
manual and the Tutorial and Concept Guide.  Are you suggesting those are not 
the latest versions?  Should the content clarify what versions they are?   

I agree with John’s comments about the utility of the main website 
documentation page. 
Moreover, the wiki links to the Help and Guide are to the most recent *stable* 
release of the documentation. As you may know, the documentation uses the same 
bug management process and version control to manage the docs. Changes that are 
accepted in the docs but not yet published in the official release (the 
“Nightly Documentation Builds”) may describe features that have not been 
implemented in the current release. This parallels the idea of the program’s 
nightly builds. They are called “unstable” for a reason, and this term is used 
in this project and in others to denote this. I have modified the sentence a 
little to bring this out a little more, but I do believe that it is clear what 
is on the web page. 
David


I am sort of afraid it may be impossible to come to any agreement about any 
wording, because there are too many people involved (and I guess I am now part 
of the problem).  I do hope that I am helping by suggesting that a clear 
proposal needs to be made by a complete new version at the sandbox.  The 
version there is deficient in my view in this one small way, at least.  --Don




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

Re: Wiki Landing Page

[David T. via gnucash-devel]

Don,

> On May 29, 2017, at 10:24 PM, doncram  wrote:
> 
> About the suggested content now at 
> http://wiki.gnucash.org/wiki/GnuCash/sandbox 
> , one objection that I have is 
> that it refers readers to a Documentation page at the main gnucash.org 
>  website which provides nothing for them (it only 
> contains links to the Help manual and the Tutorial and Concept Guide, and no 
> other documentation). Specifically, the current content includes:
> 
> "For the latest documentation (i.e., unstable releases of the documentation), 
> or to get documentation for other languages or earlier releases, see the 
> [http://www.gnucash.org/docs.phtml  
> Documentation] page on the GnuCash.org website."
> 
> It seems like a false statement, that a reader could get latest documentation 
> or anything else there.  The content already does link to versions of the 
> Help manual and the Tutorial and Concept Guide.  Are you suggesting those are 
> not the latest versions?  Should the content clarify what versions they are?  
>  

I agree with John’s comments about the utility of the main website 
documentation page. 

Moreover, the wiki links to the Help and Guide are to the most recent *stable* 
release of the documentation. As you may know, the documentation uses the same 
bug management process and version control to manage the docs. Changes that are 
accepted in the docs but not yet published in the official release (the 
“Nightly Documentation Builds”) may describe features that have not been 
implemented in the current release. This parallels the idea of the program’s 
nightly builds. They are called “unstable” for a reason, and this term is used 
in this project and in others to denote this. I have modified the sentence a 
little to bring this out a little more, but I do believe that it is clear what 
is on the web page. 

David

> 
> I am sort of afraid it may be impossible to come to any agreement about any 
> wording, because there are too many people involved (and I guess I am now 
> part of the problem).  I do hope that I am helping by suggesting that a clear 
> proposal needs to be made by a complete new version at the sandbox.  The 
> version there is deficient in my view in this one small way, at least.  --Don
> 

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

Re: Wiki Landing Page

[David T. via gnucash-devel]

OK, I have created wiki.gnucash.org/wiki/Wikihomesandbox 
<http://wiki.gnucash.org/wiki/Wikihomesandbox> with my proposed changes. 

David

> On May 28, 2017, at 10:35 AM, David T. via gnucash-devel 
> <gnucash-devel@gnucash.org> wrote:
> 
> I'll put my proposed page up in a day or two. I just hope it doesn't become 
> the next "Draft Concept guide" on the wiki. 
> Is there a way to set a "destroy by" date on a wiki page? 
> David
> 
> 
> 
>  On Sun, May 28, 2017 at 9:09, John Ralls<jra...@ceridwen.us> wrote:   
> 
> On May 27, 2017, at 5:03 PM, doncram <donc...@gmail.com> wrote:
> Could someone please open a page at
> http://wiki.gnucash.org/wiki/GnuCash/sandbox  for me and David T. to edit
> at.  :)  I am not allowed to create a new page.  Or I can wait a few more
> days and see whether I automatically get rights to create new wiki pages,
> which I was told may happen after being emailconfirmed for a week.
> 
> 
> 
> David T. can create a page should he feels so motivated.
> 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: Wiki Landing Page

[David T. via gnucash-devel]

beginning of the page.4) We could quibble over whether the mailing lists 
constitute documentation or not. I felt the lists were more support-oriented 
than documentation oriented, although I conceded that many questions on the 
list are answered by suggesting the user search the list achives.5) There is no 
GnuCash-user search interface, beyond Google.
David


Note that Documentation available includes:   Help manual (available within 
your downloaded GnuCash software, in whatever version that is)   Help manual ( 
http://www.gnucash.org/ viewdoc.phtml?doc=help  , with version not identified ) 
  Help manual version 2.6 (specifically available somewhere within the website 
)   Help manual version latest version in progress (available within GnuCash, 
if you download the working, non-stable version of GnuCash?  Not available 
online? Or available somewhere within http://code.gnucash.org/docs/ ?)   
Tutorial and Concepts Guide (available within your downloaded GnuCash software, 
in whatever version that is)   Tutorial and Concepts Guide ( 
http://www.gnucash.org/ viewdoc.phtml?doc=guide , with version not identified ) 
  Tutorial and Concepts Guide version 2.6 (specifically available within the 
website, somewhere)   Tutorial and Concepts Guide latest version in progress 
(available within GnuCash, if you download the working, non-stable version of 
GnuCash?  Not available online?  Or available somewhere within 
http://code.gnucash.org/docs/ ?)   Glossary, within the Tutorial and Concepts 
Guide   Glossary at the Wiki, which states that it may have more ( 
http://wiki.gnucash.org/wiki/ Glossary )   FAQ at the Wiki
   Gnucash-user email list archive by month from July 2000 ( 
https://lists.gnucash.org/ pipermail/gnucash-user/ )   Gnucash-user search 
interface (available where?)Note "Support" available is different, and includes 
the email lists and IRC chat.
Could someone please create a Wiki subpage at Talk:GnuCash/sandbox (i.e. 
http://wiki.gnucash.org/wiki/ Talk:GnuCash/sandbox) where David T. and I and 
anyone else could edit the proposal?  I suggest calling it "sandbox" in 
parallel to how, in Wikipedia, development of revisions to protected templates 
is done.  When we have a complete version there, fully functional with all 
links and so on, and have reached some consensus about it being ready (via 
discussion at Talk:GnuCash and/or here in gnucash-devel), then it will be easy 
for an administrator to copy it over to the main page.
Developing a proposed new version within the Wiki is consistent with the plan 
envisaged at the Talk page of the main page, which states:Please add your 
suggested changes here and we will commit them as soon as possible (usually in 
less than a few hours).--Cstim 04:53, 27 January 2006 (EST)

But I think it is helpful to have a complete new version in a Wiki page, ready 
to be copied over, rather than requesting changes piecemeal on the Talk page or 
on the gnucash-devel email list.  It is too cumbersome to request them that 
way, and requested change might not work, because it hasn't been demonstrated 
in a sandbox.  I would develop the sandbox if someone would please create a 
sandbox page. :)
cheers, Don
On Fri, May 26, 2017 at 2:30 AM, David T. via gnucash-devel 
<gnucash-devel@gnucash.org> wrote:

I would like to propose substantial changes to the Wiki landing page 
(https://wiki.gnucash.org/wiki /GnuCash <https://wiki.gnucash.org/wiki 
/GnuCash>), a page I can’t edit. I apologize in advance for the length and 
complexity of this email, but that’s the price to pay for control.

For ease of analysis, I have put

{Begin}--- and
{END}---

around the proposed wiki text. I should also note that there are many minor 
edits in my texts, beyond the higher-level reorganization. Finally, I include 
comments about changes in a section immediately after that section.

Now, on to the edits!

First off, the complexity of the page recommends an opening table of contents 
with the following (linked) top level headings:

1) Available Documentation
1.x) Wiki Translation
2) Installation
3) Support Options
4) Developing for GnuCash

This table of contents should include secondary headings as appropriate.

Note that I propose demoting the Wiki Translation section as a subsection of 
Available Documentation, since the wikis are, after all, a part of the 
documentation. I wonder whether there is a better way to handle this, though. I 
recognize that it is important to get speakers of other languages to their 
native language sites, but I wonder if there is a way to mimic what 
www.gnucash.org does, with language links at the top?

Additionally, I recommend promoting Installation to a primary level since this 
is a subject that comes up regularly, and this will bring this 
always-contentious issue into more prominence.

Stylistically overall, the page needs bullet entries to begin with a name of 
the entity being described. For exampl

Re: Wiki Landing Page

[David T. via gnucash-devel]

ki/Glossary> 
> )
>FAQ at the Wiki
>Gnucash-user email list archive by month from July 2000 ( 
> https://lists.gnucash.org/pipermail/gnucash-user/ 
> <https://lists.gnucash.org/pipermail/gnucash-user/> )
>Gnucash-user search interface (available where?)
> Note "Support" available is different, and includes the email lists and IRC 
> chat.
> 
> Could someone please create a Wiki subpage at Talk:GnuCash/sandbox (i.e. 
> http://wiki.gnucash.org/wiki/Talk:GnuCash/sandbox 
> <http://wiki.gnucash.org/wiki/Talk:GnuCash/sandbox>) where David T. and I and 
> anyone else could edit the proposal?  I suggest calling it "sandbox" in 
> parallel to how, in Wikipedia, development of revisions to protected 
> templates is done.  When we have a complete version there, fully functional 
> with all links and so on, and have reached some consensus about it being 
> ready (via discussion at Talk:GnuCash and/or here in gnucash-devel), then it 
> will be easy for an administrator to copy it over to the main page.
> 
> Developing a proposed new version within the Wiki is consistent with the plan 
> envisaged at the Talk page of the main page, which states:
> Please add your suggested changes here and we will commit them as soon as 
> possible (usually in less than a few hours).--Cstim 
> <http://wiki.gnucash.org/wiki/User:Cstim> 04:53, 27 January 2006 (EST)
> 
> But I think it is helpful to have a complete new version in a Wiki page, 
> ready to be copied over, rather than requesting changes piecemeal on the Talk 
> page or on the gnucash-devel email list.  It is too cumbersome to request 
> them that way, and requested change might not work, because it hasn't been 
> demonstrated in a sandbox.  I would develop the sandbox if someone would 
> please create a sandbox page. :)
> 
> cheers, Don
> 
> On Fri, May 26, 2017 at 2:30 AM, David T. via gnucash-devel 
> <gnucash-devel@gnucash.org <mailto:gnucash-devel@gnucash.org>> wrote:
> I would like to propose substantial changes to the Wiki landing page 
> (https://wiki.gnucash.org/wiki/GnuCash 
> <https://wiki.gnucash.org/wiki/GnuCash> 
> <https://wiki.gnucash.org/wiki/GnuCash 
> <https://wiki.gnucash.org/wiki/GnuCash>>), a page I can’t edit. I apologize 
> in advance for the length and complexity of this email, but that’s the price 
> to pay for control.
> 
> For ease of analysis, I have put
> 
> {Begin}--- and
> {END}---
> 
> around the proposed wiki text. I should also note that there are many minor 
> edits in my texts, beyond the higher-level reorganization. Finally, I include 
> comments about changes in a section immediately after that section.
> 
> Now, on to the edits!
> 
> First off, the complexity of the page recommends an opening table of contents 
> with the following (linked) top level headings:
> 
> 1) Available Documentation
> 1.x) Wiki Translation
> 2) Installation
> 3) Support Options
> 4) Developing for GnuCash
> 
> This table of contents should include secondary headings as appropriate.
> 
> Note that I propose demoting the Wiki Translation section as a subsection of 
> Available Documentation, since the wikis are, after all, a part of the 
> documentation. I wonder whether there is a better way to handle this, though. 
> I recognize that it is important to get speakers of other languages to their 
> native language sites, but I wonder if there is a way to mimic what 
> www.gnucash.org <http://www.gnucash.org/> does, with language links at the 
> top?
> 
> Additionally, I recommend promoting Installation to a primary level since 
> this is a subject that comes up regularly, and this will bring this 
> always-contentious issue into more prominence.
> 
> Stylistically overall, the page needs bullet entries to begin with a name of 
> the entity being described. For example, under Wiki Translation, the bullets 
> should begin with “German Language Wiki,” “Spanish Language Wiki,” and 
> “Portugese Language Wiki.” This convention should be applied consistently in 
> each section, and will allow the table of contents to make sense.
> 
> Under Available Documentation, I propose the following:
> 
> {BEGIN}-
> 1. Available Documentation
> 1.1 Official GnuCash Documentation. GnuCash offers two major pieces of 
> documentation:
> • The Help Manual {linked} - a quick reference manual for specific 
> tasks, and
> • The Tutorial and Concepts Guide {link} - an in-depth guide to the 
> concepts. It is highly recommended to read at least the first chapters of the 
> guide.
> For the latest documentation (i.e., unstable releases of th

Wiki Landing Page

[David T. via gnucash-devel]

I would like to propose substantial changes to the Wiki landing page 
(https://wiki.gnucash.org/wiki/GnuCash 
), a page I can’t edit. I apologize in 
advance for the length and complexity of this email, but that’s the price to 
pay for control.

For ease of analysis, I have put 

{Begin}--- and 
{END}---

around the proposed wiki text. I should also note that there are many minor 
edits in my texts, beyond the higher-level reorganization. Finally, I include 
comments about changes in a section immediately after that section.

Now, on to the edits!

First off, the complexity of the page recommends an opening table of contents 
with the following (linked) top level headings:

1) Available Documentation
1.x) Wiki Translation
2) Installation
3) Support Options
4) Developing for GnuCash

This table of contents should include secondary headings as appropriate.

Note that I propose demoting the Wiki Translation section as a subsection of 
Available Documentation, since the wikis are, after all, a part of the 
documentation. I wonder whether there is a better way to handle this, though. I 
recognize that it is important to get speakers of other languages to their 
native language sites, but I wonder if there is a way to mimic what 
www.gnucash.org does, with language links at the top?

Additionally, I recommend promoting Installation to a primary level since this 
is a subject that comes up regularly, and this will bring this 
always-contentious issue into more prominence.

Stylistically overall, the page needs bullet entries to begin with a name of 
the entity being described. For example, under Wiki Translation, the bullets 
should begin with “German Language Wiki,” “Spanish Language Wiki,” and 
“Portugese Language Wiki.” This convention should be applied consistently in 
each section, and will allow the table of contents to make sense.

Under Available Documentation, I propose the following:

{BEGIN}-
1. Available Documentation
1.1 Official GnuCash Documentation. GnuCash offers two major pieces of 
documentation: 
• The Help Manual {linked} - a quick reference manual for specific 
tasks, and
• The Tutorial and Concepts Guide {link} - an in-depth guide to the 
concepts. It is highly recommended to read at least the first chapters of the 
guide.
For the latest documentation (i.e., unstable releases of the 
documentation), or to get documentation for other languages or earlier 
releases, see the Documentation page on the GnuCash.org website {link}.

1.2 GnuCash Wikis 
(Parts of) this wiki have been translated into other languages or 
contain information for one specific language only. 
• The German Wiki {link} de/GnuCash Deutsche Wiki-Seiten, im Entstehen.
• The Spanish Wiki {link} es/GnuCash Wiki español.
• The Portugese Wiki {link} pt/GnuCash Sítio Wiki em Português, em 
andamento.

1.3 The GnuCash FAQ {link} contains the collection of frequently asked 
questions about GnuCash, including administration, accounting, and glossary 
questions.

1.4 Using GnuCash collects real life experiences using GnuCash. You may find 
(user) solutions here that are not covered by the documentation.

1.5 The Wiki Glossary explains some often used terms, with additional terms 
useful for developers, documentation writers, and translators.

1.6 More Specific Topics [NOTE: I think this needs re-thinking generally; I 
believe these pages should be linked in elsewhere altogether. In the interest 
of moving the discussion along, I have kept them here, but see below]
• "Normal” Usage
• Keyboard Shortcuts
• Using Scheduled Transactions
• Online Banking: Setting up OFXDirectConnect in GnuCash 2 and 
AqBanking (FinTS/HBCI)
• Trading Accounts (New since 2.3.8/2.4.0)
• Scripting and Programming
• How to create some Custom Reports
• Python Bindings
• Notes about the C API
• The GnuCash API
• Error Seaching
• Logging messages and filtering detail.
• Getting a Stack Trace.
1.7 External Documentation Resources
• GnuCash Quick Start Guide For Business Users. 
• Also, business users might be interested in a book by PacktPub, UK: 
GnuCash 2.4 Small Business Accounting, by Ashok Ramachandran.
• List to external international documentation and a somewhat outdated 
list of available online documentation.

{END}--

I recommend that the section currently in Documentation called “Some more 
specific topics:” should be moved off this page altogether. 
The “Normal” Usage and Scripting and Programming sections could be moved to the 
Using GnuCash page, and the Error Searching section should be moved below to 
the Support Options section, or to the page on filing a 

Re: Gnucash wiki

[David T. via gnucash-devel]

Templates do sound like an improvement, although I would be concerned with some 
of these huge wiki pages (like the Documentation Update Instructions page) that 
the box will be at the top, and someone will link into the page such that the 
box wouldn’t show.

If you set up the templates or explained how to set them up and implement them, 
I would consider helping out. Can’t guarantee anything.

David

> On May 19, 2017, at 5:49 PM, Geert Janssens  
> wrote:
> 
> Hi Buddha,
> 
> I didn't even know of the existence of templates. The ones you suggest are a 
> good start IMO.
> 
> As for Wiki's containing everything, I only follow up to "that is not readily 
> available elsewhere". In the latter case I would prefer to be pointed at the 
> proper source (for example to the Guide, or another external reference).
> 
> Let's see what others can still add...
> 
> Regards,
> 
> Geert
> 
> On donderdag 18 mei 2017 20:12:52 CEST Buddha Buck wrote:
>> I just went and looked at the Wiki, to get an idea of what the task is.
>> 
>> I'm all for Wikis containing everything, as long as it is clearly
>> identified and organized. Currently, I agree that the Wiki doesn't meet
>> that standard. Even the front page is a "mixed bag" of content, and
>> could/should be organized better. As you point out, figuring out the
>> necessary organization is difficult.
>> 
>> I think that for starters the creation of a few templates that can be
>> dropped onto pages to help classify content and make it visible would help.
>> For instance, create a Template:Historical template which (a) adds the
>> article to the "Historical" category, and (b) displays a box at the top of
>> the page saying that the content of the page applies to a past version of
>> GnuCash and is not current documentation. Then Wiki editors can look at a
>> page (on, say, using lots for managing stock transactions) and drop in the
>> template so that future readers who stumble upon it can clearly see it's
>> probably not what they are looking for.
>> 
>> Based on the things you've noticed, I can suggest a few templates to make:
>> 
>>   - Template:Historical
>>   - Template:Version|vernum|endvernum  (for marking that a page is useful
>>   for GnuCash between versions vernum and endvernum, both optional).
>>   - Template:InDevelopment (for marking pages that refer to features that
>>   are in development, but haven't been released)
>>   - Template:Os|ostype (for marking pages with OS-specific information
>>   - Template:MarkedForDeletion
>> 
>> I can also see categories related to
>> 
>>   - Category:HowTo
>>   - Category:Development
>>   - Category:Documentation
>>   - Category:Announcement
>>   - Category:Events
>>   - Category:CanSomeoneElseLookAtThisPlease
>> 
>> 221 content pages doesn't sound like a lot. I'd be willing to do some of
>> the work to set up the templates and categories (once we nail down what we
>> want) and start working through the pages and tagging them with categories
>> and templates.
>> 
>> 
>> On Thu, May 18, 2017 at 1:25 PM Geert Janssens 
>> 
>> wrote:
>>> Hi,
>>> 
>>> A recent thread on a page in our wiki on lots raised the potential pitfall
>>> of
>>> having draft pages in our wiki as rightfully pointed out by David T.
>>> 
>>> I don't consider me a wiki maintainer really though I have contributed to
>>> some
>>> pages. This minor incident did get me thinking though. And I want to
>>> discuss
>>> the following question with a broader audience:
>>> 
>>> What do we want our wiki to be ?
>>> 
>>> A few statistics [0] for those interested in contributing to this
>>> discussion:
>>> 
>>> 1. The wiki currently has 221 real content pages [1] of varying quality
>>> and
>>> usefulness.
>>> 2. In addition there are 310 additional related pages like redirects, talk
>>> pages,...
>>> 3. There are 12 admins, of which only a handful is still active as far as
>>> I
>>> know (and I didn't know *I* was one of them)
>>> 4. Looking at the content pages list, I find about 53 pages are ancient
>>> release announcements or readme files for obsolete gnucash versions.
>>> 
>>> In its current form it's a mixed bag of all kinds of content
>>> - pages attempting to guide contributors in helping out in different forms
>>> - pages attempting to help users with common or less common issues
>>> - reports of past events
>>> - some of these pages are generic, others are platform dependent,...
>>> - however most pages don't specify their intent clearly so in several
>>> cases
>>> it's difficult to judge whether the page is for what you are looking for
>>> or
>>> not
>>> - some pages have current information, others are for historical interest
>>> only
>>> - ...
>>> 
>>> So what do we want to achieve with the wiki ?
>>> Do we manage to achieve it ?
>>> 
>>> I believe we would be beneficial find an answer to these questions so we
>>> can
>>> more clearly guide the content creation in the wiki.
>>> 
>>> From what I see the 

Re: Some history of wikis: was: lots

[David T. via gnucash-devel]

Frank,

I strongly believe that having outdated, unmaintained—and ultimately 
WRONG—information available to the casual user is the wrong approach to take. 

How an English translation of a German draft of the English Guide got onto the 
main GnuCash wiki (in English) in the first place is puzzling to me, especially 
since the Guide has existed since the early 2000s (going by the copyrights). It 
would seem that such draft language should have been proposed as a change to 
the documentation through the bug process. If the wiki was being used as a 
sounding board for these proposed changes, then they should have been removed 
from the wiki once the discussed changes had either been implemented or 
dismissed. They should not be a permanent part of the wiki.

I also believe that having the same information in two (or more) places is a 
recipe for someone having to straighten out later (like now). The information 
in the draft concept guide on the wiki has been incorporated into the official 
Tutorial and Concepts Guide for quite a long time now. I’m not even sure why 
they exist at all. It looks to my uneducated eye as if they are an English 
translation of a German draft of the English Guide, which was put up on a 
German Linux wiki back before 2008. 

It’s not entirely clear to me, but it sounds like you’re saying that these 
outdated, incorrect and ultimately wrong pages need to stay forever in the wiki 
because the discussion page that asked about them (in 2007) refers to them. 
Similarly, you want the GnuCash wiki to forever keep these outdated, incorrect 
and wrong pages because some OTHER outdated, unmaintained (since 2008) wiki 
pages refer to them. That’s circular reasoning, and makes no sense to me. A 
wiki isn’t supposed to be a place where pages can only be created or changed, 
but never removed.

Simply put, it’s time for these pages to go, and the talk page and linuxwik.de 
 can remove the references to them as well. Since I have 
no connection to linuxwiki.de , someone with a connection 
to them should suggest this to them.

David

> On May 19, 2017, at 6:13 AM, Frank H. Ellenberger 
>  wrote:
> 
> Hi,
> 
> Am 18.05.2017 um 04:45 schrieb David T. via gnucash-user:
>> Robert,
>> 
>> I will note two points about the page to which you refer:
>> 
>> 1) this page is a section of the wiki that contains an old,
>> *non-current* draft of the User Guide which was created in 2007, and,
> 
> No, https://wiki.gnucash.org/wiki/Special:WhatLinksHere/Concept_of_Lots
> refers
> https://wiki.gnucash.org/wiki/Talk:GnuCash#Where_does_the_Devel_link_belongs.3F
> 
> It was tansferred from http://linuxwiki.de/GnuCash/DevelTexts which
> again was used before Derek set up wiki.gnucash.org/wiki. That page has
> the following disclaimer:
> "NOTE: This page is probably very out of date. The current english
> GnuCash wiki is on http://wiki.gnucash.org/wiki , online since December
> 2005. If you want to contribute to any of the discussions below, please
> move the content from here to http://wiki.gnucash.org/wiki and continue
> the discussion there."
> 
> 
>> 2) the section that you quote is, I believe, intended as as proposal
>> to improve the lots features (although it’s difficult to tell because
>> of the fractured English used throughout the page).
>> 
>> I would strongly recommend that you consult the current Concept Guide
>> and Tutorial at http://www.gnucash.org/viewdoc.phtml?doc=guide
>> 
> 
> Note: This link returns the incomplete german translation "GnuCash Kurs
> und Konzepte" for me. Better use
> http://www.gnucash.org/viewdoc.phtml?rev=2.6=C=guide (frame) or
> https://www.gnucash.org/docs/v2.6/C/gnucash-guide/ (direct)
> or
> 
>> David
>> 
>> P.S. -> To the Wiki gurus: I have suggested in the past that having
>> these “Draft Guide” pages on the Wiki can be problematic and cause
>> troubles, but was told that they are not linked directly in the main
>> Wiki. Apparently some people can still find them and get the wrong
>> impression about GnuCash funtionality. I reiterate my recommendation
>> for the removal of these pages from the wiki.
> 
> IMHO We should not break the deep links of http://linuxwiki.de/GnuCash
> but feel free to redirect them to somewhere else
> 
>>> On May 17, 2017, at 11:09 PM, Robert Hoogendoorn
>>>  wrote:
>>> 
>>> Thanks David for your quick reply,
>>> 
>>> 1. I read about the marking of lots on this site,
>>> http://wiki.gnucash.org/wiki/Concept_of_Lots
> ...
> I cc the devel list as discussion about the wiki belongs there.
> Geert already started the thread
> http://lists.gnucash.org/pipermail/gnucash-devel/2017-May/040650.html
> 
> Regards
> Frank

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

Re: Some Assistance Please

[David T. via gnucash-devel]

> On May 2, 2017, at 8:16 PM, Derek Atkins <warl...@mit.edu> wrote:
> 
> David,
> 
> First, sorry to come at this late...
> 
> "David T. via gnucash-devel" <gnucash-devel@gnucash.org> writes:
> 
>> Hello,
>> 
>> Once again, the documentation bug has bit me, and I am trying to use
>> the accepted GnuCash toolset to implement a change to the Guide.
> 
> Excellent.  Thank you for your ongoing support!!
> 
>> Most recently, this toolset has been changed to use “make”, and when I
>> attempt to refresh my memory by going to the wiki page, I fail to find
>> an explanation that makes sense to me.
> 
> I would just point out that this hasn't changed.  This method has been
> in place for well over a decade, probably closer to two.

OK, I think the page on the wiki has been changed to prefer the make toolset in 
recent times.

> 
> [snip]
>> P.S.: I continue to think that the wiki page is poorly-constructed for
>> general users. In specific, I object to the high-level structure that
>> embeds the initial setup steps with the ongoing editorial process. In
>> my situation, I find it impossible to separate the setup commands from
>> those that I actually need to proceed.
> 
> As the guy who maintains the wiki instance (I run the hardware/OS for
> the wiki and maintain the mediawiki software installation), I'm not sure
> I understand what you mean by "separate the setup commands from those
> that [you] actually need to proceed".  What do you mean by this?  Also,
> what do you mean by "high level structure that embeds the initial setup
> steps with the ongoing editorial process.”?

Here’s what I mean:

On the Documentation Update instructions, section 3 contains 17 different 
steps. 

Step 3.1: Create a Bugzilla Bug is a step that should be undertaken with every 
proposed change to the documentation. 

Step 3.2: Clone the Documentation, however, is (presumably) a one-time setup. 
Steps 3.3-3.5 similarly are one-time setups (unless you’re a screwup like me, 
and then you get to do them over and over again). 

Steps 3.6-3.10 are again repeated for each change to the docs. 

Step 3.11 is a step that is not technically part of the documentation process 
at all, since it only applies to one family of GnuCash’s supported operating 
systems. Mac and Windows writers don’t perform this step, and the fact that I 
have been contributing changes for years without conducting these tests 
underscores the fact that they aren’t a required part of the Documentation 
Update process.

Steps 3.12 and following are back to steps taken on each change—although at 
this point, I wonder whether people are preparing patches and attaching them to 
Bugzilla bugs (steps 3.15-3.17), or whether everyone has moved to the Github 
pull request method.

I’ll leave the rest of the topic chalked up to one of those online moments when 
I saw and felt things that probably were not intended by anyone in the way I 
took them.

David 

> 
> -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: Wiki decision workflow; was: Some Assistance Please

[David T. via gnucash-devel]

So, apparently, there is a decision-making process in place. I’m not sure how 
it might be improved, since this is quite literally the first I have heard 
about it. 

Since you seem to be one of the folks in charge of the decisions on the wiki, 
perhaps *you* might consider how to improve the process, so that you encourage 
engagement, rather than discourage it.

David

> On Apr 27, 2017, at 7:49 PM, Frank H. Ellenberger 
>  wrote:
> 
> David,
> 
> let me try to describe the current state:
> 
> some of us watch almost daily
> http://wiki.gnucash.org/wiki/Special:RecentChanges
> to prevent spam and avoid misleading information.
> 
> (That is the place, where your commits didn't appear in the first
> quarter year of your activity, so you were almost invisible like a ninja.)
> 
> If we are unshure, how to handle a special case, we collect opinions on
> irc://irc.gimp.org/gnucash
> usually at european evening/american afternoon time.
> 
> If a problem is more comlex, we open a bugilla entry to collect the
> different aspects.
> 
> If we think we need a broader base to find a decision we open a thread
> at gnucash-devel if mostly contributors are affected or gnucash-user else.
> 
> If I reedit a commit of a serious user, not a spammer, and the reason is
> not obvious by my commit, I add a note on the users talk page.
> 
> Perhaps I should add the hint "Feel free to open a discussion on the
> respective mailing list."
> 
> How, do you think, can we improve this?
> 
> Frank
> 

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

Re: Some Assistance Please

[David T. via gnucash-devel]

Frank, 

I don't know what you mean by "ninja status", and I don't particularly care, 
but I do know that without some mechanism for resolving disagreements on 
content, a wiki doesn't really function well, since it leaves the resolution of 
such disagreements to the person who is willing to push harder for their way. 
As far as I have seen, GnuCash’s wiki lacks such mechanisms. 

David

P.S. This isn’t the venue to discuss our differences about the Wiki Glossary 
again.

On Thu, Apr 27, 2017 at 3:35, Frank H. Ellenberger
<frank.h.ellenber...@gmail.com> wrote:
David,

I am really sorry, but you and 2 other authors got by accident a
ninja-like status for a few month in the wiki. So your changes did not
appear on
http://wiki.gnucash.org/wiki/Special:RecentChanges  
<http://wiki.gnucash.org/wiki/Special:RecentChanges>. Else we would have
given you earlier some advice, were we thought your changes might have
issues.

And I am pretty sure, I and almost every other contributor has made some
mistakes, special at the beginning and will more than likely do others
in the future.

Am 26.04.2017 um 18:51 schrieb David T. via gnucash-devel:
> I am somewhat hesitant to take this on; my experience editing Gnucash
> wiki pages is decidedly negative. When last I engaged in the
> editorial process on this particular page, my perspective was not
> considered relevant to the focus of the page.

I do not remember what you are referring here.


> And recently, changes I made to the Glossary were determined to be
> incorrect, and the bulk of them removed altogether. I am not
> interested in putting in the effort of editing a complex wiki
> document only to have that work discarded.


Are you talking about this changeset?
http://wiki.gnucash.org/wiki/index.php?title=Glossary=revision=12417=12414
 
<http://wiki.gnucash.org/wiki/index.php?title=Glossary=revision=12417=12414>

From the view of documentation writer it is a good idea to convert the
glossary from the wiki into chapter of the docs and replace the wiki
content by a link to the chapter in the docs, to have only one place to
maintain.

OTOH, a note is much faster published via the wiki than over the docs:
* Is my git repo up to date?
* Which branch should I use in this case?
* Which docbooks tags should I use?
* which make commands are required?
* Which git commands are required?

As another aspect: it is usually much faster to create a wiki link than
an external link.

And there are entries like "g-wrap" which would be annoying in the
official docs, because they are obsolete. But while traveling through
the source tree or searching something else in the email archive you
might find notes referencing this term. Then, IMHO, the wiki glossary
should tell you "(replaced by swig for gnucash >= 2.2.0)"

HTH
Frank

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

Re: Some Assistance Please

[David T. via gnucash-devel]

Geert,

See below.

> On Apr 26, 2017, at 5:54 PM, Geert Janssens  
> wrote:
> 
> By doing so you may have implicitly configured your source directory 
> resulting 
> in the errors below. As a rule of thumb, avoid running any "make" command in 
> your source tree. The only commands that make sense there are git commands to 
> manage your commits (including pushing and pulling from/to upstream) and "./
> autogen.sh" in the root level of your source tree.
> 
> "configure" on the other hand should always be called from within the root of 
> your build directory. From then on "make " can be called from any 
> directory in your build tree.
> 
> And to avoid any confusion "from within the root of your build directory" 
> means you cd into your build directory and then invoke configure. As 
> configure 
> itself is not in your build directory, but in your source directory, you'll 
> need to call it with its full path. This gives:
> cd ~/Development/GnuCash/build
> ~/Development/Gnucash/docs/configure
> 
>> When
>> I changed over to ~/Development/GnuCash/build/guide/C and entered “make
>> html” (per the wiki), I received an error:
>> 
>> configure: error: source directory already configured; run "make distclean"
>> there first
>> 
>> I went to the docs folder and entered “make distclean” and got some output.
>> I then returned to build/guide/C and tried again. I get the same error. No
>> combination of make commands seems to move the process along.
> 
> You may have to call make distclean directly in
> ~/Development/GnuCash/build/guide/C

> if that is where you accidentally ran configure from before. Note you will 
> only be able to run make distclean successfully once in each configured 
> directory. That command will throw away all filed that were automatically 
> generated by autogen.sh and configure (not your manual changes to the source 
> files though, which is good).
> 
> If you hesitate which directories you may have run configure in, you can 
> search for a file called config.log. Each directory that contains this file 
> was at some point in the past "configured" as the error message suggests. 
> With 
> the exception of your true build directory in each of these directories you 
> can run make distclean once.

I attempted to use the above directions, without any success.

> 
> That's one approach to clean up, using the tools provided by make and friends 
> itself. Another approach would be to use git instead. Git knows which files 
> belong in your source tree and which ones are generated.
> 
> *** Important *** If you want to use the git way, first make sure *all* your 
> current changes are committed at least locally. That is all your changes 
> should have been git add'ed and git commit'ed. git status should only show 
> you 
> untracked files for which you know you didn't edit/create them manually. 
> Anything that's not committed will be deleted.
> 
> From there on it's easy.
> Cd into your source directory
> run "git clean -fx"
> rerun "./autogen.sh"
> cd into your build directory
> run ~/Development/Gnucash/docs/configure
> cd to wherever in your build tree you want to run a make command
> execute the make command
> 

This set of directions worked.

> 
> I sympathize. Unfortunately I'm no longer in a position to be able to 
> estimate 
> what works for general users as you call it. It seems this is also a variable 
> term. Some users like lots of context, others prefer a short list of 
> commands. 
> What structure would you propose ? Are you willing to attempt a restructuring 
> of the page to something you see better fit ? Don't worry if some of the info 
> your would write there is not completely correct. We can adjust this as we 
> continue. I just would love to find a structure that works well for a wide 
> audience first.

I am somewhat hesitant to take this on; my experience editing Gnucash wiki 
pages is decidedly negative. When last I engaged in the editorial process on 
this particular page, my perspective was not considered relevant to the focus 
of the page. And recently, changes I made to the Glossary were determined to be 
incorrect, and the bulk of them removed altogether. I am not interested in 
putting in the effort of editing a complex wiki document only to have that work 
discarded.

David

> 
> Regards,
> 
> Geert

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

Some Assistance Please

[David T. via gnucash-devel]

Hello,

Once again, the documentation bug has bit me, and I am trying to use the 
accepted GnuCash toolset to implement a change to the Guide. 

Most recently, this toolset has been changed to use “make”, and when I attempt 
to refresh my memory by going to the wiki page, I fail to find an explanation 
that makes sense to me.

My environment is as follows:

OS: Mac
Git clone saved in ~/Development/Gnucash/docs
Build directory in ~/Development/GnuCash/build
upstream: github.com/Gnucash/gnucash-docs
origin: github.com/sunfish62/gnucash-docs

Specifically, if I have an already-existing installation of the downloaded 
documentation source that I have pushed and pulled into alignment with github, 
and I have finished editing the source files, what are the precise commands I 
need to invoke to get a tested and compiled local documentation set? 

Today, I used “make check” from ~/Development/Gnucash/docs/guide/C and all 
seemed to work; I got no errors following the actual xmllint command. When I 
changed over to ~/Development/GnuCash/build/guide/C and entered “make html” 
(per the wiki), I received an error:

configure: error: source directory already configured; run "make distclean" 
there first

I went to the docs folder and entered “make distclean” and got some output. I 
then returned to build/guide/C and tried again. I get the same error. No 
combination of make commands seems to move the process along.

Thanks,
David

P.S.: I continue to think that the wiki page is poorly-constructed for general 
users. In specific, I object to the high-level structure that embeds the 
initial setup steps with the ongoing editorial process. In my situation, I find 
it impossible to separate the setup commands from those that I actually need to 
proceed.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: unable to find the file

[David T. via gnucash-devel]

Deepak,

You need to provide a little more context. There are a lot of possible reasons 
for this error. For example, did you rename your file in your operating system? 
Did you move it? Did you delete it? Is it in a location (e.g., a network drive 
or USB stick) that is not currently available? 

So, start by telling us what operating system you are using, what GnuCash 
version you are using, and how you arrived at the error.

David

> On Apr 16, 2017, at 6:44 PM, deepak jain via gnucash-devel 
>  wrote:
> 
>  i am unable to open the files. it says that the file can not be found
>   Deepak Jain
> ___
> 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: Building System Requirements

[David T. via gnucash-devel]

Stephen,

I’m no expert, but you might start by looking at: 
https://wiki.gnucash.org/wiki/Building 

David T.

> On Apr 7, 2017, at 11:17 PM, Stephen Brown  
> wrote:
> 
> Hi John
>> There's no need to debug the GnuCash build system, it's not broken. It does
>> error out when the system on which it's run doesn't meet the requirements
>> for building, and being able to understand and correct those errors is a
>> prerequisite for using it.
>> 
>> Regards,
>> John Ralls
> 
> What system meets the requirements for building GNUCash?
> 
> Yours Sincerely
> Stephen Grant Brown
> ___
> 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: RIP Trunk Branch

[David T. via gnucash-devel]

Just a reminder to check the wiki for references to trunk (a quick search there 
turns up 17 page references), and make sure they are corrected/updated. It 
would be best for someone to make these changes who actually understands what 
those changes should look like (i.e., probably not me, unfortunately).

David

> On Mar 24, 2017, at 4:21 AM, John Ralls  wrote:
> 
> We removed the 'trunk' branch from the GnuCash repository today. It was 
> equivalent to 'master' and retained as a holdover from subversion, from which 
> we'd converted to Git 3 years ago.
> 
> Until today code.gnucash.org's refs/HEADS pointed to refs/heads/trunk. 
> Github's has pointed to refs/heads/master almost since the conversion, so the 
> following applies only to the few devs who have cloned directly from code: To 
> reset refs/HEAD in your local repo, run
>  git set-head origin -a
> If you have a tracking branch pointed at trunk you'll need to change it with
>  git branch -u origin/master 
> where  is the name of your tracking branch.
> 
> 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: gnucash master: Multiple changes pushed

[David T. via gnucash-devel]

> On Feb 21, 2017, at 10:06 PM, John Ralls  wrote:
> 
> 
>> On Feb 21, 2017, at 8:43 AM, Derek Atkins  wrote:
>> 
>> It's weird that this isn't caught by the *compiler* -- isn't an unused
>> parameter a warning/error?
> 
> It is by default, but we turn it off in configure.ac lines 1570 (C++) and 
> 1581 (C) because we have so many unused variables littering our code.
> 
> Regards,
> John Ralls

John,

I’m not going to add much to this discussion, except to ask if the removal of 
unused variables is: a) something worthy of doing, and b) something that could 
be delegated to a non-programmer in such a way that they would not *ahem* fuck 
things up worse? Iff both are true, then I would be willing to take a stab in 
some way. But only if that actually helps with Real Development, and doesn’t 
hurt the cause.

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

Re: wiki login difficulties

[David T. via gnucash-devel]

I had the same problem. Clear your cookies and try again. 

> On Feb 14, 2017, at 6:29 AM, Tommy Trussell  wrote:
> 
> Hi -- the revision list for my username says it's been over a year since I
> edited something in the GnuCash wiki. I know this isn't right as I can see
> MUCH more recent edits I made on the Ubuntu page. Weird.
> 
> In any case I am unable to log in at the moment. Have logins been locked
> for some reason? I get an error when I try to use the password reset page.
> 
> Wiki username: twt
> ___
> 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: Issues with Placeholder Accounts

[David T. via gnucash-devel]

> On Feb 11, 2017, at 2:40 PM, Geert Janssens  
> wrote:
> David,
> 
> I agree with you on this. The current behavior in gnucash is inconsistent and 
> that should be improved. I also think this is a big challenge because this 
> "detail" touches almost all parts of the engine code...
> 
> I propose you record your findings in a bug report including all situations 
> you have encountered so far in which gnucash is changing placeholder 
> accounts. 
> This is not something that will be solved with an easy fix.
> 
> As for your extension to AR/AP accounts this is even harder. Ideally the user 
> interface for business features would handle everything business related so 
> the user would never need to alter anything in these accounts. However this 
> is 
> not the case so sometimes it's still necessary to manually make changes in 
> these accounts. I'm not sure what would be required to get that completely 
> worked out, but I believe again this is a fairly big change.
> 
> Regards,
> 
> Geert

Geert,

I have submitted two separate bugs—one for the Scrub Lots issue (bug 778480), 
the other for the more general issue of editing splits for Placeholder accounts 
(bug 778481). I think the two are related, but probably better addressed 
separately.

Offhand, I don’t know if there are other such situations.

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

Re: Issues with Placeholder Accounts

[David T. via gnucash-devel]

> On Feb 11, 2017, at 6:04 AM, Chris Good  wrote:
> Hi David,
> 
> The Help manual says:
> 
> A Placeholder means this account is not used for transaction data.
> Transactions may not be posted to this account, only to sub-accounts of this
> account not marked themselves as Placeholder.
> 
> My feelings are...
> 
> Maybe the manual should be changed to say you cannot add *additional*
> transactions via the register (or import?).
> 
> I assume since you have a placeholder stock account with transactions, that
> the UI doesn't check if there are existing transactions before allowing it
> to be changed to a placeholder account.
> I think that is useful functionality that should remain.
> 
> If a placeholder stock account already has transactions, then presumably you
> have made it a placeholder to stop yourself adding new transactions.
> Adding capital gain transactions via scrubbing is really just properly
> completing the sale transaction, so I don't see a need for a change there.
> 
> Regards, Chris Good

Chris,

Not sure where in the Help manual you’re looking; I see a note about 
placeholder accounts in 5.4.1, and another in 6.3.1 (both of which I wrote) 
that do not have the text you cite.

Regardless of what the Help manual says, the placeholder flag makes an account 
read-only. At least that’s what I have been told over the years on the lists.

This can be done with ANY account, regardless of whether there are transactions 
in the account. The Help manual citation you included is wrong. 

My reason for setting this flag on closed and zeroed out accounts is because of 
the behavior documented in bug 397135, and included in the Help text at 5.4.1 
and 6.3.1. Setting an account to Placeholder prevents it from appearing in the 
combo list in an account register. And, yes, I am also interested in not adding 
new transactions to these accounts as well.

Further, my complaint isn’t with the process of flagging an account as a 
placeholder account; my complaint is that once the account has been flagged as 
placeholder, there are circumstances in which transactions can be posted and 
altered in the account. 

I also don’t agree with your assessment of scrubbing being a completion of the 
transaction. Scrubbing adds new transactions to an account. Sometimes many. 
Adding a transaction to a read-only account means that the account is no longer 
read only. 

I don’t think that that is simply a matter of documentation. Either an account 
is read only, or it is not.

David


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

Issues with Placeholder Accounts

[David T. via gnucash-devel]

Hello, 

I will preface this email with a reminder that I am not a developer, and 
apologize ahead of time if my understanding of GnuCash functionality is flawed. 
That said...

In the course of trying to corral a problem with Unrealized Gains reporting, I 
have been dealing with accounts that have had the Placeholder flag set. As 
folks here are no doubt aware, this flag sets the account to read-only status, 
and indeed, when I open one of these accounts, I am informed of that fact in a 
dialog box.

However, there are numerous situations in which GnuCash does not respect this. 
For example: it is possible to create multiple transactions in a Commodity type 
account by using the lots feature and scrubbing the account. Similarly, one can 
edit the split in a placeholder account by accessing the transaction from the 
far account, which is not set to placeholder. I don’t know whether there are 
other such exceptional circumstances.

Both of these undermine the concept of a placeholder account, and raise some 
interesting thoughts for me. 

First, I think the lots feature needs to take this flag into account; it is 
quite easy to scrub an account and generate numerous gains transactions in a 
placeholder account, which might cause major problems for an unsuspecting user.

Second, I wonder where the placeholder flag is evaluated; it appears to be at 
the register or perhaps transaction level, but really, it should be evaluated 
at the split. Changing this is, I am sure, likely to be a painful fix, but I 
think it ultimately would yield a more consistent result. Evaluating at the 
split would prevent my second scenario from going through.

Third, I wonder if this “Placeholder for people but not processes” concept 
might not be leveraged to address the fragility of A/R and A/P business 
features. That is, have these accounts sets to Placeholder so that users do not 
edit these transactions directly (something that Derek notes he has been 
repeating on the lists for ten years), but use processes to modify the data 
entered into these accounts. Please be aware that I am not a business user, so 
I only am going on third party information on this. If this is in fact how it 
is set up, or if the idea is fundamentally dumb, I apologize.

David

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

Re: gnucash-docs maint: Bug 777891 - Guide Glossary lacks proper ID tag or mention in Basics Chapter.

[David T. via gnucash-devel]

When I put this in, I accidentally committed the Overview without the related 
Glossary change, thus creating a broken reference. I caught it immediately and 
committed the glossary change as well in a second commit. Geert “squashed” the 
two commits (his term) before committing; is it possible that somehow the first 
commit went through, but the second didn’t? Otherwise, it’s a pretty minor 
change.

David

> On Feb 7, 2017, at 10:33 PM, Derek Atkins  wrote:
> 
> Geert,
> I believe this broke the docs build; it failed last night.
> 
> -derek
> 
> Geert Janssens  writes:
> 
>> Updated   via  https://github.com/Gnucash/gnucash-docs/commit/f8e2df0d 
>> (commit)
>>  from  https://github.com/Gnucash/gnucash-docs/commit/0c8c66f9 (commit)
>> 
>> 
>> 
>> commit f8e2df0d822e4de5ed1ca2285bd00acbab30d73c
>> Author: David Thomas 
>> Date:   Mon Feb 6 21:31:39 2017 +0500
>> 
>>Bug 777891 - Guide Glossary lacks proper ID tag or mention in Basics 
>> Chapter.
>> 
>>This patch adds the appropriate tag in the glossary, and references the 
>> glossary in the Overview Chapter.
>> 
>> diff --git a/guide/C/ch_oview.xml b/guide/C/ch_oview.xml
>> index f0395fa..8e9ab47 100644
>> --- a/guide/C/ch_oview.xml
>> +++ b/guide/C/ch_oview.xml
>> @@ -406,6 +406,10 @@
>> 
>> 
>>
>> +   - Glossary of terms used 
>> in 
>> +   
>> +   
>> +   
>>- Guide for former 
>> >  class="registered">Quicken, MS Money or other 
>> QIF
>> users
>> diff --git a/guide/C/gnc-glossary.xml b/guide/C/gnc-glossary.xml
>> index 07b7902..2681ac0 100644
>> --- a/guide/C/gnc-glossary.xml
>> +++ b/guide/C/gnc-glossary.xml
>> @@ -7,7 +7,7 @@
>>   Translators:
>>(translators put your name and email here)
>> -->
>> -
>> +
>>Glossary
>>   This is a glossary of common terms used in 
>> .
>>   Some entries here are taken from Wikipedia (> url="http://en.wikipedia.org"/>).
>> 
>> 
>> 
>> Summary of changes:
>> guide/C/ch_oview.xml | 4 
>> guide/C/gnc-glossary.xml | 2 +-
>> 2 files changed, 5 insertions(+), 1 deletion(-)
>> 
>> ___
>> gnucash-changes mailing list
>> gnucash-chan...@gnucash.org
>> https://lists.gnucash.org/mailman/listinfo/gnucash-changes
>> 
>> 
> 
> -- 
>   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

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

Re: Using make with docs

[David T. via gnucash-devel]

> On Feb 7, 2017, at 11:59 AM, Chris Good  wrote:
> Hi David T,
> 
> I had made some changes to the Documentation Update Instructions sections
> dealing with "make check" + "make html" to make it clearer that these
> commands should be run from within the build directory structure.
> Feel free to improve further if you think necessary.
> 
> I'll say again, IMHO I think the instructions re setting up the build system
> belong in this page. Maybe grouping them under a new heading, something like
> "Build System One-Time Setup", would be a slight be an improvement.
> 
> Regards, Chris Good

OK. The directions on make are getting better. 

You and I simply disagree on the overall content of this page.

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

Re: Document Update Instructions have been revised

[David T. via gnucash-devel]

> On Feb 7, 2017, at 7:14 PM, Frank H. Ellenberger 
>  wrote:
> 
> Hi David,
> 
> Am 07.02.2017 um 11:29 schrieb David T.:
>> Chris, No. I haven't tried John's suggestion. My current mac is five
>> years old, and I had already downloaded the full xcode upgrade when
>> John made the suggestion. I'll note that the wiki still instructs mac
>> users to install the full xcode suite. If it's no longer true, then
>> the wiki needs correction. David
> 
> Go for it. You are the Mac experts. ;-)
> 
> ~Frank

Frank,

I’m no expert, and I haven’t tested John’s solution, so I don’t know whether 
it’s true.

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

Re: documentation bug 687820

[David T. via gnucash-devel]

Once again, Geert, you come to clarify. Indeed, I was not aware that this was a 
comma-delimited list. With only one dependency, that is not clear from the 
page. 

Once again, I prove that there is nothing too simple that I can’t screw up.

David

> On Feb 7, 2017, at 3:40 PM, Geert Janssens <geert.gnuc...@kobaltwit.be> wrote:
> 
> Op dinsdag 7 februari 2017 10:17:38 CET schreef David T. via gnucash-devel:
>> Frank, 
>> I'm pretty sure those features are not opened to mere mortals, at least, I
>> can't see them. That's what I meant when I said I could only edit an
>> existing dependency entry.  David T.
>> 
> When I open bugs, I see Depends and Blocks. If there's no dependency yet, 
> both 
> fields are plain text fields in which you can enter a comma separated list of 
> bug numbers. If there's already a dependency (for example bug 687820 depends 
> on closed bug 777318) the info will change to a list of clickable bug numbers 
> and an "edit" option. When I click on the "edit" option the field changes 
> back 
> to a text field with a comma separated list of bugs it depends on. As there's 
> only one bug, there's no commas either of course. I have no added one more 
> dependency on your newest proposal to merge the introductory chapters. I did 
> this starting from that bug and entering "687820" in the Blocks field.
> 
> From your earlier attempts it looks like you have the proper privileges to 
> alter both fields. Perhaps it wasn't clear the fields expect a comma 
> separated 
> list ? Or is there still something else (which is possible because I have 
> Developer privileges) ?
> 
> Regards,
> 
> Geert

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

RE: Document Update Instructions have been revised

[David T. via gnucash-devel]

Chris, 
No. I haven't tried John's suggestion. My current mac is five years old, and I 
had already downloaded the full xcode upgrade when John made the suggestion. 
I'll note that the wiki still instructs mac users to install the full xcode 
suite. If it's no longer true, then the wiki needs correction.
David
 
 
  On Tue, Feb 7, 2017 at 13:01, Chris Good wrote:   
From: John Ralls [mailto:jra...@ceridwen.us] 
Sent: Friday, 27 January 2017 1:40 AM
To: sunfis...@yahoo.com
Cc: Chris Good ; Frank H. Ellenberger 
; GnuCash Developers 
Subject: Re: Document Update Instructions have been revised

  

  


On Jan 25, 2017, at 11:55 PM, David T.  wrote:

  

  

  


On Thu, Jan 26, 2017 at 8:26, John Ralls

 wrote:

  

Indeed. But you don't need all of it, just the command-line tools.

  

Regards,

John Ralls

  

  

  

I'm not sure you can get one without first getting the other. At least, I 
haven't been able to. 



Assuming that you don't already have Xcode installed, try running 

  clang foo.cpp

in Terminal. That should pop up a dialog box offering to install them for you.

  

Regards,

John Ralls

  

Hi David,

  

Did you manage to install the Xcode command line tools without having to 
install the full Xcode or did you have to use John’s ‘clang foo.cpp’ method?

I think we should document this either way.

  

Regards, Chris Good

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

Re: documentation bug 687820

[David T. via gnucash-devel]

Frank, 
I'm pretty sure those features are not opened to mere mortals, at least, I 
can't see them. That's what I meant when I said I could only edit an existing 
dependency entry. 
David T.
 
 
  On Tue, Feb 7, 2017 at 10:50, Frank H. 
Ellenberger wrote:   Davids,

Am 07.02.2017 um 03:16 schrieb david.carlson@gmail.com:
> Sounds Like we need clarification on how to use those fields to best
> advantage. David C Sent from my LG G Pad 7.0 LTE, an AT 4G LTE
> tablet
> 
> 
> 
> -- Original message--From: DavidDate: Mon, Feb 6, 2017 7:53
> PMTo: David Carlson;Frank H. Ellenberger;Cc:
> gnucash-devel@gnucash.org;Subject:Re: documentation bug 687820 David,
> Frank,I was trying to add the new bug as a dependency of the older
> one (as Frank did earlier), but my view only offers an edit option,
> which removed the earlier dependency. I wanted to keep the earlier
> dependency to keep the pieces linked, so I changed it back, knowing
> that someone would note it here and maybe add the dependency in
> additionally. FWIW, I also tried the See Also option on the offhand
> chance it would go into the dependencies spot, but it didn't.David

Let me try ...

https://bugzilla.gnome.org/ says in the upper right corner:
 version 4.4.12

So https://www.bugzilla.org/docs/4.4/en/html/ should be the right manual.

https://www.bugzilla.org/docs/4.4/en/html/bug_page.html below:
 18. *Dependencies: If this bug cannot be fixed unless other bugs are
fixed (depends on), or this bug stops other bugs being fixed (blocks),
their numbers are recorded here.

So you can edit lists in "Depends on" and "Blocks".
To visualize more complex dependencies use "tree". e.g.
https://bugzilla.gnome.org/showdependencytree.cgi?id=570303_resolved=1

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

Re: Using make with docs

[David T. via gnucash-devel]

Geert,

> On Feb 6, 2017, at 10:10 PM, Geert Janssens <geert.gnuc...@kobaltwit.be> 
> wrote:
> 
> Op maandag 6 februari 2017 21:28:24 CET schreef David T. via gnucash-devel:
>> Hello,
>> 
>> The recently-updated Documentation Update Instructions page on the wiki—as
>> detailed as they are—nonetheless leave something to be desired when one
>> reaches step 10. You see, up until this point, a great deal of energy is
>> put into showing how one can use “make check” in different ways to test
>> either the Guide, or the Help, or the different translations.
>> 
>> Once you get to actually compiling these docs, though, the directions dry up
>> and just tell the user to "make html” in "the appropriate directory within
>> the build directory structure.” (ADWTBDS)
>> 
>> Two points:
>> 
>> 1) when I issue “make check”, I am in the working directory, and if you’re
>> stupid or inattentive (both of which apparently apply to me), you issue the
>> “make html” command without first changing to the ADWTBDS.
> Acutally, make check is also meant to be run in the build directory. *All* 
> make commands are intended to be executed in the build directory or one if 
> its 
> subdirectories. I'm not sure this is very clearly specified in the wiki page.
> 
> The fact you can run "make check" in your working directory implies you have 
> in the past run configure in your working directory. By that action you have 
> configured your working directory to double as a build directory. It would 
> simplify your life if you remove these configure actions from the working 
> directory again. By doing so, running "make " there would give an 
> error like this:
> make: *** No rule to make target 'check'.  Stop.
> 

No doubt this has something to do with earlier setup issues (steps 3 & 4). Or 
it has to do with the fact that the earlier method (calling xmllint and 
xsltproc directly) was invoked in the working directory, with output directed 
to a different folder directly, and I learned that way and kept doing it (like 
the proverbial lemming of Arthur Clarke’s short story).

I reiterate my wish to see documentation that covers *setting up a build 
system* separated from information *directly related to the documentation 
update process*. Having a separate setup page would allow those of us who 
struggle with every aspect of this process to be able to get set up, and then 
focus on screwing up only the actual steps for updating, rather than the whole 
shebang.


> That should solve your problem of accidentally building the html docs in your 
> git working directory.
> 
> The easiest way to remove the files set up by configure would be:
> - cd into to root of your local git repository (the level where you see guide 
> and help as subdirectories)
> - run: "make distclean" (without the quotes)
> - and finally rerun "./autogen.sh" (again without the quotes)
> 
>> This results in
>> the docs being built right there in the working directory. Not horrible,
>> but potentially messy (especially if you forget to remove the folder before
>> going back to git).
>> 
>> 2) If I change to my build directory, “make html” builds all the docs, which
>> is a collossal waste of time when all I want to do is compile the Guide in
>> (say) English—which is all I worked on in the first place. I personally
>> don’t plan on ever editing the Portugese, German, Italian, or Japanese
>> translations.
>> 
>> So, two questions:
>> 
>> 1) Is there a way to configure the make command to use my build directory as
>> its destination, while running from the working directory?
> Not that I know of.
>> 2) Is there a
>> way to make just the html of one portion of the docs, without making all
>> docs in all languages?
> Yes. You can do so by invoking "make html" in the exact build subdirectory 
> that matches the subdirectory in your git repository. For example to build 
> the 
> English guide as html, you would starting from your build directory
> cd guide/C
> make html
> 
> "The appropriate directory in the build directory structure" was meant to 
> suggest exactly that. I see the way it's formulated is still too developer-
> mind oriented. Sorry about that. Perhaps "the equivalent subdirectory under 
> the build directory" is more clear ? How would you propose to better describe 
> this ?
> 
> Geert


Thank you for clearly outlining to me (once more!) how to handle these issues. 
I will look into better ways of wording things to make it clearer to others.

Cheers,
David

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

Using make with docs

[David T. via gnucash-devel]

Hello,

The recently-updated Documentation Update Instructions page on the wiki—as 
detailed as they are—nonetheless leave something to be desired when one reaches 
step 10. You see, up until this point, a great deal of energy is put into 
showing how one can use “make check” in different ways to test either the 
Guide, or the Help, or the different translations. 

Once you get to actually compiling these docs, though, the directions dry up 
and just tell the user to "make html” in "the appropriate directory within the 
build directory structure.” (ADWTBDS) 

Two points:

1) when I issue “make check”, I am in the working directory, and if you’re 
stupid or inattentive (both of which apparently apply to me), you issue the 
“make html” command without first changing to the ADWTBDS. This results in the 
docs being built right there in the working directory. Not horrible, but 
potentially messy (especially if you forget to remove the folder before going 
back to git).

2) If I change to my build directory, “make html” builds all the docs, which is 
a collossal waste of time when all I want to do is compile the Guide in (say) 
English—which is all I worked on in the first place. I personally don’t plan on 
ever editing the Portugese, German, Italian, or Japanese translations.

So, two questions:

1) Is there a way to configure the make command to use my build directory as 
its destination, while running from the working directory?
2) Is there a way to make just the html of one portion of the docs, without 
making all docs in all languages?

TIA,
David

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

Re: New Documentation Bug

[David T. via gnucash-devel]

Frank,

I agree that the wiki would be a better place to document this; that is why I 
raised the subject here. The bug in question discusses adding information to 
the Guide and Help, and I am wary of adding ephemeral information to the 
documentation, given how long the cycle ends up being, and how things in the 
docs seem to take on a life of their own.

On the other hand, it is also clear to me that most users don’t seem to access 
the wiki when they run into problems, and I worry that relegating this 
information there will make the transition more difficult for new users.

David

> On Jan 31, 2017, at 8:32 AM, John Ralls  wrote:
> 
> 
>> On Jan 30, 2017, at 11:51 AM, Frank H. Ellenberger 
>>  wrote:
>> 
>> Hi,
>> 
>> Am 30.01.2017 um 18:25 schrieb Geert Janssens:
>>> Op maandag 30 januari 2017 21:35:20 CET schreef David T.:
 It occurs to me, though, that John’s comments regarding possible 
 repackaging
 for the Mac make me wonder more generally whether information that is
 intended to be short term (such as this) really belongs in the
 documentation. I am reminded of the What’s New section, which was recently
 removed from the Guide in acknowledgement of the website being a better
 location for this. Temporary transitory information such as this is a poor
 fit in the documentation, as it either forces some person to monitor and
 change the information all the time (which is a challenge), or it ends up
 being dated and misleading to users.
 
>>> This took me by surprise. I didn't see any mention of John's intentions to 
>>> change this. Had to dig back in the archives to find this indeed buried in 
>>> the 
>>> "Change storage format of existing data" thread, which I admit to have 
>>> skimmed 
>>> only before due to time restraints. That's good news of course!
>>> 
 I do not know what the best solution in this broader situation is; I am 
 open
 to suggestions. In the meantime, I will see whether I can work out language
 that both addresses the issue and mitigates the editorial burden.
>>> 
>>> Well, current documentation is for the 2.6 release in which the sql backend 
>>> on 
>>> OSX only supports sqlite. So that's the information which should be in the 
>>> 2.6 
>>> docs. I believe this can be one short note at the spot where you explain 
>>> which 
>>> sql types are supported. It doesn't need much elaboration.
>>> 
>>> If John does find the time to fix this for 2.8 (which I surely hope!), the 
>>> accompanying documentation needs an update. The trick will be to remember 
>>> at 
>>> that point this needs updating...
>>> 
>>> Alternatively you can hold off the PR for this piece of information until 
>>> it 
>>> will be more clear whether or not this will happen for 2.8.
>>> 
>>> I can't think of better options ATM.
>>> 
>>> Geert
>> 
>> In the wiki I would write something like "Since version 2.x.y the Quartz
>> package includes SQLite support."
>> 
> 
> "2.x.y" would be 2.4.0.
> 
> Regards,
> John Ralls
> 

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

Re: New Documentation Bug

[David T. via gnucash-devel]

Geert, 
That is still the case. 
David

 
 
  On Mon, Jan 30, 2017 at 15:14, Geert Janssens<geert.gnuc...@kobaltwit.be> 
wrote:   Op zondag 29 januari 2017 08:28:39 CET schreef John Ralls:
> > On Jan 29, 2017, at 12:42 AM, David T. via gnucash-devel
> > <gnucash-devel@gnucash.org> wrote:
> > 
> > Hi,
> > 
> > I just submitted a new documentation bug (bug 777893) to add information
> > about the SQL back end to the documentation.
> > 
> > I am aware of the long-standing issues regarding the SQL back end, but it
> > seems to me that the basic functionality of these back ends has
> > stabilized enough that information about them needs to get in to the
> > documentation. In short, it is time to get something in the docs, so that
> > users new and old can get information that is clear and accurate.
> > 
> > The reason I am sending this message to the devel list is that this topic
> > will need the perspective and input from as many expert users and
> > developers as possible to ensure that the information added for these
> > features is clear about both the status of the feature as well as its
> > limitations. The documentation needs to be carefully worded so that users
> > can make informed decisions about the data format they ultimately choose.
> > 
> > So, please look at the bug, reply here, or make suggestions on wording as
> > you see fit.
> ISTM what needs to be covered is:
> 
> 1. Additional dependencies on Linux.
> 2. There are no automatic backups Users must arrange to make periodic
> snapshots themselves. 3. No simultaneous multi-user access.
> 4. Required privs on MySQL/Maria and Postgres.
> 5. Users of MySQL/Maria and Postgres are expected to either be competent
> DBAs or have a competent DBA available to help them; the GnuCash team can't
> help with DB management issues.
> 
Does the OS X/Quarz version of gnucash ship with full support for all three 
dbi backends ? Last time I tried (which was ages ago!) only sqlite was 
available.

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

Documentation Docbook Question

[David T. via gnucash-devel]

Hello,

In working on Bug 777318, I noticed some small issues with the recently-added 
glossary (which is all my creation).

First, I noticed that it lacks the appropriate section name (“gnc-gloss”).

Next, I noticed that the file lacks a chapter tag.

Third, I noticed that 1.3 About This Book in the Overview chapter does not 
include a reference to the glossary.

I discovered these in reverse order. First, I noticed that the glossary wasn’t 
in the overview, so I added the reference there, and received errors from 
xmllint.

Then I looked at the glossary file to add the id to a section heading, but then 
noticed the lack of a chapter tag.

The question is: does the glossary have to have a chapter tag? The Guide 
compiles cleanly without it, but I wonder whether there will be a problem 
later. Moreover, without the chapter tag, I’m not sure where the section name 
should be inserted. Would I add it directly to the glossary tag that is already 
there?

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

Re: GnuCash page Documentation Update Instructions has been changed by Sunfish62

[David T. via gnucash-devel]

Geert,

Thanks as always for providing a clear explanation of the situation. You have 
gently shown me where I have misunderstood the process, and make it clearer to 
me. 

I have entered a version that I think does a reasonable job of promoting 
git-maint as the commonly-used mode, but also explaining when git-master might 
be used. I also included a reference to Git#Branches for the curious.

Chris, does that work for you? I hope so!

…Now on to the next areas…

David

P.S. Chris, you don’t need to apologize to me for being argumentative; I can be 
obnoxiously argumentative as well—for which I apologize as well.

> On Jan 27, 2017, at 2:06 PM, Geert Janssens  
> wrote:
> 
> Op vrijdag 27 januari 2017 11:09:10 CET schreef Chris Good & David T:
>> On another point, you commented on the page that I took
>> away information about committing to master. A few things on this: First,
>> for documentation, a non commit contributor is only going to be documenting
>> existing features, so they will ALWAYS be using maint. One of the wiki
>> pages for git states this; I was merely making this agree with that.
>> Second, the pages on git already go into this in more detail (which, by the
>> way, was why I suggested having one git wiki page earlier), so adding it
>> here only muddies the water. Third, you did precisely this with regard to
>> the user of xmllint/xsltproc and make. David
>> 
>> Non commit  contributors are not the only ones to use this page.
>> Both Git and Git_For_Newbies say:
>>  maint
>>Bugfixes, translations, improvements of the documentation should
>> *usually* be applied on this branch.
> For sake of the discussion I will add the exact rule would be that you should 
> document a feature on the same branch as it is available on in the gnucash 
> repository, with maint taking priority over master if it's available on both.
> 
> It's true that currently most new documentation is written for features that 
> have already been released in a stable gnucash version (and hence are on the 
> maint branch), so this documentation should go on the maint branch as well. 
> However this is partly because the documentation is running behind so much 
> and 
> the current writers are still catching up (for which I'm immensely grateful!)
> 
> There is a period in each development cycle where this is not so obvious. 
> When 
> we start releasing development snaphots - the next one being 2.7.0 somewhere 
> later this year - documenters are invited to look at the new features that 
> weren't previously released and write documentation for those. Similar to how 
> translators mostly work on the maint branch, except during the prerelease 
> period. Both are examples of when to create patches against the master branch.
> 
> If you find a way to express this distinction concisely and clearly, I'd love 
> to have this at least mentioned in some way indeed.
> 
> Geert

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

Re: Document Update Instructions have been revised

[David T. via gnucash-devel]

 
 
  On Thu, Jan 26, 2017 at 8:26, John Ralls wrote:
Indeed. But you don't need all of it, just the command-line tools.
Regards,John Ralls


I'm not sure you can get one without first getting the other. At least, I 
haven't been able to.   
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Documentation Update Instructions

[David T. via gnucash-devel]

Chris, 
I explained my reasoning behind that on the other thread. 

 
 
  On Thu, Jan 26, 2017 at 11:00, Chris Good wrote:   
Hi David,

  

Re 
http://wiki.gnucash.org/wiki/Documentation_Update_Instructions#Step_1_Create_a_Bugzilla_Bug_for_the_Documentation_Change

  

I think you should leave in the info about using version “git-master” when 
updating documentation that will only apply to the next stable series.

  

Regards, Chris Good

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

Re: Depreciation Chapter in the Guide

[David T. via gnucash-devel]

Frank, 
I found the thread I was thinking of, but I had remembered it backward. In an 
October discussion about capital gains, John wondered about deleting the 
capital gains chapter, since the information there was not useful. He mentioned 
the depreciation chapter as one reason why the cap gains chapter could be 
deleted. 
My apologies. 
David
P.s. I'll take your word about the subprime crisis. 
 
 
  On Thu, Jan 26, 2017 at 2:25, Frank H. 
Ellenberger<frank.h.ellenber...@gmail.com> wrote:   Hi David,

Am 23.01.2017 um 18:23 schrieb David T. via gnucash-devel:
> Hello,
> 
> Just revisiting bug 687820, and trying to update the overall roadmap
> to 2017. ISTR at one point John suggesting that the chapter on
> Depreciation (chapter 20) would be better off scrapped. I wanted to
> check whether that sentiment is generally held, or whether it should
> remain.
> 
> David

where, please?

I am absolutly against removing it. It is a fundamental accounting
technic and it should be explained how to do it in GnuCash.

Currently I see at least 2 important use cases:

In DE the smallest selfemployed has to depraciate his Laptop over 3
years, his car over 5 years, in short every asset valued over ~100€.

When you track the value of your real estate and the related mortgage,
you can handle a situation like the subprime crisis much better. You
could see the danger much earlier.

~Frank

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

Moving Forward with Documentation Bug 687820

[David T. via gnucash-devel]

Hello,

Nearly five years ago, I created Bug 687820 in a more innocent time. In that 
bug, I outlined an ambitious plan to restructure the Tutorial and Concepts 
Guide, which received a modicum of positive support when I initially submitted 
it.  

At this time, I think that I am comfortable enough with the editorial process 
to actively begin this migration. To that end, I would like to proceed by 
submitting separate bugs for each of the large changes I originally wrapped in 
that one bug. The first of these is Bug 777318, in which I propose merging two 
Business chapters. I welcome feedback here or on the bugs in question in 
regards to the bugs.

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

Re: Document Update Instructions have been revised

[David T. via gnucash-devel]

Hi Frank,

> On Jan 23, 2017, at 1:09 PM, Frank H. Ellenberger 
>  wrote:
> 
> Hi all,
> 
> just a few ideas:
> I found by accident the 10 years old
> http://wiki.gnucash.org/wiki/Concept_Guide_draft/Overview ff., which is
> an example for using subpages in a template
> http://wiki.gnucash.org/wiki/Template:Cgtoc .
> 

Wow. I think that set of pages should probably just go away? The Concept Guide 
has moved well beyond these drafts.


> Don't confuse it with the more recent
> http://wiki.gnucash.org/wiki/Concept_Guide which is more a todo list and
> ancestor of the Document Update Instructions

The to do list is also dated, but might still be of use. I don’t know whether 
it should be updated or scrapped.

> 
> Recently I was asking myself and Gert, if we should move the nice
> written sections about
> #The_Make_Utility
> #Step_3_Generate_configure_Script
> #Step_4_Make_a_Build_Directory_Structure_and_the_Makefiles
> in the basic existing page http://wiki.gnucash.org/wiki/Build_System
> or a new page Autotools and linking it from Building_Gnucash and
> Translation, too.
> That would have the benefit there would be only one page to maintain
> almost everything about the autotools components. OTOH some users could
> be distracted by the jumping between the pages.
> 
> Your opinion?

The Build System page is too technically-focused and too sparse for my limited 
abilities, and in the context of the docs process, it won’t be of help to the 
people who want only to update the docs (that’s me). 

> 
> I understand that the pull request is the adequate way for a longtime
> contributor on the mailing list like  you, David. But it would be too
> much overhead to create an github account, a ssh key, ... to send a
> patch for a typo by a random reader.

First, setting up the github account was pretty simple (even for me). 

Second, there is simply no way that a “random reader” is EVER going to make a 
change to the documentation. There is a HUGE jump from typing a Word document 
or an email to using a version control system to edit and manage XML files from 
a remote repository. I know, because I have struggled long and hard to 
understand the little of this all that I do. As I said earlier, as a 
non-programmer, I can say that the ONLY way I’ve been able to contribute 
consistently has been through the git pull process.

David

> 
> Regards
> Frank

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