Re: [GNC-dev] Develop support for Import/Export using .xbrl?

[David T. via gnucash-devel]

Brian

Not that I'm an expert, but I figured I'd do your work for you and read over 
the XBRL wikipedia article. 

A few things pop out at me:
1) XBRL appears to be a framework for financial reports. There's a ton of 
discussion in the article about developing taxonomies and extensibility, but 
little detail on what the structures are or should be. This supports John's 
concern that there isn't *one* structure. 
2) The primary use case presented in the article is for annual statements for 
SEC filings, again supporting John's question about who the primary audience is 
(big businesses) 
3) Initial tests of the spec found a high level of inaccuracy in the uses by 
businesses, with a more recent analysis by Charles Hoffman in 2017 finding 
"just" 10% inaccuracies. Nevertheless, the EU established 2020 as a deadline 
for companies to add xbrl tags to their reports. I have no idea if they have, 
but is this something the small Gnucash developer pool should take on? I don't 
think so...

⁣David T.​

On Jan 27, 2024, 4:40 AM, at 4:40 AM, briancady413--- via gnucash-devel 
 wrote:
>I don't know these answers, but maybe they can be found
>here:https://en.wikipedia.org/wiki/XBRLhttps://en.wikipedia.org/wiki/XBRL_International
>
>Brian-
>
>
>
>On Friday, January 26, 2024 at 06:20:44 PM EST, John Ralls
> wrote:  
> 
> 
>
>> On Jan 26, 2024, at 12:42 PM, Frank H. Ellenberger
> wrote:
>> 
>> 
>> 
>> Am 25.01.24 um 19:59 schrieb John Ralls:
>>> Not really, it looks like a big-business thing.
>> OTOH I sem more and more governments requesting data for tex
>declaration in xbrl format.
>> Prehaps we should start with xbrl as a report format?
>> 
>
>Do these governments use the *same* XBRL format or does each country
>have its own variant? Do they really apply to individuals and very
>small businesses like the UK's MTD initiative?
>
>Next, are they F/LOSS friendly or do they, like the UK's MTD, require
>the generating program to include some secret token?
>
>Regards,
>John Ralls
>
>  
>___
>gnucash-devel mailing list
>gnucash-devel@gnucash.org
>https://lists.gnucash.org/mailman/listinfo/gnucash-devel
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Is ellipsis in Loan Repayment Options intended?

[David T. via gnucash-devel]

Boy, does that look painful. Although I understand the intention, the results 
aren't actually grammatical.

There's the comma splice in the title text: "Do you utilize an escrow account, 
if so an account must be specified..."

Then, adding the tail end for the various options results in gibberish: "... if 
so an account must be specified ... pay taxes"-- doesn't make sense. 

So this is just a fail on all levels. 

It would be preferable if this were rewritten to use more formal language. 

Like:

Title: Escrow Account Settings

Content
If your loan utilizes an escrow account, enter the necessary information here. 

Use Escrow Account
  Escrow account 
Escrow includes Taxes
Escrow includes Insurance
Escrow includes PMI
Escrow includes other expenses

I'll admit I have never used this assistant, so I don't know why each option 
includes a secondary check box, or what effect the choices have, but I'll leave 
that to others. 


⁣David T. ​

On May 12, 2023, 8:04 PM, at 8:04 PM, john  wrote:
>Brian,
>
>The ellipses indicate that the title is finished by each of the choices
>and the omission of the word "to". It's perhaps not the best usage, but
>it's valid English and I suppose an attempt to make the assistant feel
>more conversational that the more conventional title and enumerated
>choices.
>
>Regards,
>John Ralls
>
>
>> On May 12, 2023, at 7:03 AM, BrianHsu  wrote:
>> 
>> Hi,
>> 
>> During the translation, I found that Loan Repayment Options has lots
>> of ellipsis, for example, it displays ...pay "Taxes"? / ... pay
>"PMI"?
>> as the shown in the attached screenshot.
>> 
>> Even the first sentence of that page is "if so an account must be
>> specified...", ends with ellipsis. It's very unusual in an assistant
>> window.
>> 
>> Visually it's very cumbersome, and seems to me it serves no purpose
>> (for example, make it grammatically correctly in English) or any
>> special meaning.
>> 
>> Since English is not my native language, I'm wondering, is this
>intended or not?
>> 
>> -- 
>> Best regards,
>> 
>> 許洛豪（Brian Hsu）
>> ___
>> 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: [GNC-dev] Help with Git repos and versioning

[David T. via gnucash-devel]

I'm not an expert, but you might note the renaming of branches that was 
discussed here:

https://lists.gnucash.org/pipermail/gnucash-devel/2022-November/046401.html

And here:

https://lists.gnucash.org/pipermail/gnucash-devel/2023-March/046599.html

⁣David T. ​

On Apr 16, 2023, 9:21 AM, at 9:21 AM, Kevin Buckley  
wrote:
>I have a directory, from within which I do the occassional git pull
>againstt the GnuCash GitHub repo.
>
>I just did one, and now see the following
>
>$ git remote -v
>origin  https://github.com/Gnucash/gnucash.git (fetch)
>origin  https://github.com/Gnucash/gnucash.git (push)
>
>$ git status -s -b
>## stable...origin/stable
>
>$ git describe --abbrev=1
>5.0-71-gf4f48
>
>All looks good, but then I started looking around.
>
>The README I have starts with
>
>
>  GnuCash README file.
>
>The current stable series is GnuCash 4.x.
>
>
>should I have one that says 5.x ?
>
>
>I also downloaded a 5.0 source tarball, and saw that the README is the
>same in there, but also saw in the Changelog
>
>2023-03-25 John Ralls
>
>* Release GnuCash 5.0 (HEAD -> master, tag: 5.0)
>
>2023-03-25 John Ralls
>
>* Merge branch 'maint'
>
>
>but, if I chechout the maint branch in my local directory, I see
>
>$ git checkout maint
>$ git describe --abbrev=1
>4.13-1-g52ded
>
>amd I am aware that's there's been a 4.14, as well as the 5.0
>
>FWIW, the latest commit I can see in my maint branch is
>
>commit 52deda868ff042a2815cc6b91464a1d3415a447b (HEAD -> maint,
>origin/maint, origin/HEAD)
>Author: Christopher Lam 
>Date:   Sun Dec 18 11:39:51 2022 +0800
>
>and then when I went looking at
>
>https://github.com/Gnucash/gnucash
>
>I couldn't see the "maint" branch.
>
>Have I lost a reference somehwere ?
>
>Kevin
>___
>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] Repository Branch Changes

[David T. via gnucash-devel]

Thanks, John. I appreciate all your effort and eloquence. 

⁣David T. ​

On Mar 27, 2023, 7:44 PM, at 7:44 PM, john  wrote:
>Docs: Yes, as it would be confusing to have different branch names in
>code and doc.
>
>Accidental pushes: I'm looking into that. I think I can do that in the
>post-commit hook.
>
>Wiki articles: Thanks for the reminder.
>
>Regards,
>John Ralls
>
>
>> On Mar 26, 2023, at 8:36 PM, David T. via gnucash-devel
> wrote:
>> 
>> Out of idle curiosity (since I'm not actively working on these things
>any more), are these changes applying to the docs platform as well? 
>> 
>> And are there mechanisms that can prevent the sporadic developer who
>might have an existing clone locally from pushing to these outdated
>branches? I imagine that there are many clones out there in the hands
>of such intermittent developers.
>> 
>> Also, ISTR that there are extensive instruction guides to development
>on the wiki. I'll hope that those will get appropriate updates to
>reflect the new naming conventions...
>> 
>> ⁣David T. ​
>> 
>> On Mar 27, 2023, 2:54 AM, at 2:54 AM, John Ralls 
>wrote:
>>> I've created new `stable` branches in gnucash.git and
>gnucash-docs.git
>>> and changed Github's default branch to them. This is effectively a
>>> rename of master; when Derek has time he'll delete the master
>branches
>>> from code and Github.
>>> 
>>> You can modify your local repositories with:
>>> git branch -D maint
>>> git branch -m master stable
>>> git fetch origin
>>> git branch -u origin/stable stable
>>> git remote set-head origin -a
>>> 
>>> and optionally to clean things up:
>>> git remote prune origin
>>> 
>>> Please do this ASAP to avoid inadvertently pushing anything to maint
>or
>>> master!
>>> 
>>> 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
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Repository Branch Changes

[David T. via gnucash-devel]

Out of idle curiosity (since I'm not actively working on these things any 
more), are these changes applying to the docs platform as well? 

And are there mechanisms that can prevent the sporadic developer who might have 
an existing clone locally from pushing to these outdated branches? I imagine 
that there are many clones out there in the hands of such intermittent 
developers.

Also, ISTR that there are extensive instruction guides to development on the 
wiki. I'll hope that those will get appropriate updates to reflect the new 
naming conventions...

⁣David T. ​

On Mar 27, 2023, 2:54 AM, at 2:54 AM, John Ralls  wrote:
>I've created new `stable` branches in gnucash.git and gnucash-docs.git
>and changed Github's default branch to them. This is effectively a
>rename of master; when Derek has time he'll delete the master branches
>from code and Github.
>
>You can modify your local repositories with:
>git branch -D maint
>git branch -m master stable
>git fetch origin
>git branch -u origin/stable stable
>git remote set-head origin -a
>
>and optionally to clean things up:
>git remote prune origin
>
>Please do this ASAP to avoid inadvertently pushing anything to maint or
>master!
>
>Regards,
>John Ralls
>
>___
>gnucash-devel mailing list
>gnucash-devel@gnucash.org
>https://lists.gnucash.org/mailman/listinfo/gnucash-devel
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Missing column header labels after resizing columns (Windows 10, GC version 4.12)

[David T. via gnucash-devel]

Scott, 

I am glad you have an understanding of how such software communities operate. 

You stated that there was a bug; I was under the impression that you were 
referring to the embedded settings in the registry, and so I was offering you 
background on the reasons for this behavior and why it might not be a bug. 

I see now that you may be referring to the fact that columns can be made to 
disappear without obvious means to restore them. I know that this behavior has 
been noted numerous times in the past on the lists, so it's been known for 
quite some time. That it remains implies that no one has come up with a 
principled way to manage the situation without causing other features to break. 

Related to this, but slightly to the side: I know that there have been 
different approaches to managing column widths across accounts, and suspect 
that storing per account column settings plays into the problem of ultra narrow 
columns that you've encountered. 

I imagine that if you could suggest an improved way to handle ultra narrow 
columns, it would help developers focus on providing coding that does that. 

Since GnuCash is FOSS, I'm not selling anything ;)

⁣David T. ​

On Dec 5, 2022, 3:53 PM, at 3:53 PM, Scott Traurig  
wrote:
>David, and others,
>
>I am very familiar with various FOSS communities and offerings. I am a
>recently retired engineer, chief engineer of a very high-tech company
>for
>the last 20 years with over 100 engineers on staff. I have the greatest
>respect, admiration, and appreciation for software developers and the
>challenges of software development in a highly heterogeneous,
>multi-platform environment.
>
>So far I have observed no appreciable, functional differences or
>limitations between the Linux and Windows versions of GnuCash, don't
>sell
>yourselves short!
>
>Thanks,
>
>Scott
>
>
>
>On Mon, Dec 5, 2022 at 12:21 AM David T.  wrote:
>
>> Respectfully, the problem is that GnuCash stores and handles its
>metadata
>> in a variety of ways as a consequence of its cross platform nature
>and its
>> development history.
>>
>> GnuCash was originally (and remains primarily to this day) developed
>on
>> Linux, and has been ported to Windows to meet the needs of a broader
>user
>> base. The Linux-based settings environment is radically different
>from
>> Windows, and the (small number of) developers for GnuCash have had to
>find
>> solutions to manage these differences. These solutions have had to
>change
>> over time. This has resulted in the confusing system in place today.
>>
>> That portions of the software settings linger on Windows after
>> uninstalling is annoying, but not generally catastrophic. Indeed,
>since a
>> GnuCash upgrade on Windows is basically an uninstall/install process,
>most
>> users would be greatly inconvenienced if their custom settings
>(stored in
>> the registry) were removed upon upgrading.
>>
>> As a volunteer managed software package, GnuCash relies on the heroic
>> efforts of a very small developer base to keep it up to date.
>> Unfortunately, there aren't developer teams dedicated to building
>full
>> cross platform functionality, so users must accept these limitations
>and
>> take up the slack.
>>
>> If, in your opinion, the information regarding the registry entries
>on
>> Windows is poorly documented, I'd recommend that you update the wiki
>to
>> meet your specifications. The likelihood that the (small,
>Linux-focused)
>> dev team will prioritize a corner case such as yours is small. There
>are
>> simply many higher priorities.
>>
>> David T.
>> On Dec 5, 2022, at 06:52, David Carlson 
>> wrote:
>>>
>>> Scott,
>>>
>>> If you still have a copy of the offending registry files in your
>trash
>>> folder, recover it and  put it in your bug report.  It could help a
>>> developer find out what went wrong.
>>>
>>> On Sun, Dec 4, 2022 at 8:37 PM Scott Traurig
>
>>> wrote:
>>>
>>>  David,

  Please look again. The metadata file that John referred me to is
>*exactly*
  the same one as in the FAQ.

  I was just able to solve the problem a few minutes ago by deleting
>the
  registry information under HKEY_CURRENT_USER/software/Gsettings.
>That was
  where the problem was. I did not try to identify precisely which
>registry
  key was at fault, I do not have sufficient knowledge of the
>software to do
  so efficiently. Instead I uninstalled, deleted the registry info,
>manually
  deleted the %appdata%/gnucash folder for good measure, then
>reinstalled.

  And, because this bug (and it is a bug) affects literally every
>book on
  the machine, I will have to grab another machine here that I am
>not using
  for production, install GnuCash, and try to replicate it there so
>I can
  submit a proper bug report.

  Thanks,

  Scott

  On Sun, Dec 4, 2022 at 9:15 PM David Carlson
>
  wrote:

  Scott,
>
>  The metadata file that John referred you to is not FAQ that you

Re: [GNC-dev] Missing column header labels after resizing columns (Windows 10, GC version 4.12)

[David T. via gnucash-devel]

Respectfully, the problem is that GnuCash stores and handles its metadata in a 
variety of ways as a consequence of its cross platform nature and its 
development history. 

GnuCash was originally (and remains primarily to this day) developed on Linux, 
and has been ported to Windows to meet the needs of a broader user base. The 
Linux-based settings environment is radically different from Windows, and the 
(small number of) developers for GnuCash have had to find solutions to manage 
these differences. These solutions have had to change over time. This has 
resulted in the confusing system in place today. 

That portions of the software settings linger on Windows after uninstalling is 
annoying, but not generally catastrophic. Indeed, since a GnuCash upgrade on 
Windows is basically an uninstall/install process, most users would be greatly 
inconvenienced if their custom settings (stored in the registry) were removed 
upon upgrading. 

As a volunteer managed software package, GnuCash relies on the heroic efforts 
of a very small developer base to keep it up to date. Unfortunately, there 
aren't developer teams dedicated to building full cross platform functionality, 
so users must accept these limitations and take up the slack.

If, in your opinion, the information regarding the registry entries on Windows 
is poorly documented, I'd recommend that you update the wiki to meet your 
specifications. The likelihood that the (small, Linux-focused) dev team will 
prioritize a corner case such as yours is small. There are simply many higher 
priorities.

David T.​

On Dec 5, 2022, 06:52, at 06:52, David Carlson  
wrote:
>Scott,
>
>If you still have a copy of the offending registry files in your trash
>folder, recover it and  put it in your bug report.  It could help a
>developer find out what went wrong.
>
>On Sun, Dec 4, 2022 at 8:37 PM Scott Traurig 
>wrote:
>
>> David,
>>
>> Please look again. The metadata file that John referred me to is
>*exactly*
>> the same one as in the FAQ.
>>
>> I was just able to solve the problem a few minutes ago by deleting
>the
>> registry information under HKEY_CURRENT_USER/software/Gsettings. That
>was
>> where the problem was. I did not try to identify precisely which
>registry
>> key was at fault, I do not have sufficient knowledge of the software
>to do
>> so efficiently. Instead I uninstalled, deleted the registry info,
>manually
>> deleted the %appdata%/gnucash folder for good measure, then
>reinstalled.
>>
>> And, because this bug (and it is a bug) affects literally every book
>on
>> the machine, I will have to grab another machine here that I am not
>using
>> for production, install GnuCash, and try to replicate it there so I
>can
>> submit a proper bug report.
>>
>> Thanks,
>>
>> Scott
>>
>> On Sun, Dec 4, 2022 at 9:15 PM David Carlson
>
>> wrote:
>>
>>> Scott,
>>>
>>> The metadata file that John referred you to is not FAQ that you
>checked
>>> but a file on your hard drive.  The exact location depends on your
>os.
>>> Look under Configuration section of
>
>>> to find it.
>>>
>>> On Sun, Dec 4, 2022 at 6:11 PM Scott Traurig
>
>>> wrote:
>>>
 Hi John,

 Respectfully, this is beyond the user-list. That list has come up
>dry,
 and
 the conventional FAQ answer is not working.

 The relevant FAQ entry:

 <


>https://wiki.gnucash.org/wiki/FAQ#Q:_How_do_I_resize_my_register_columns.3F_Why_can_I_not_shrink_the_description_column.3F
 >

 That FAQ entry looked promising, but it did not solve the problem.
>There
 are no entries in the .gcm file showing zero width to edit.

 Worse, uninstalling GnuCash and deleting the entire C:\Users\my
>user
 name\AppData\Roaming\GnuCash directory, including all .gcm files
>such
 that
 they would be reconstituted from scratch, does not work either.

 Interestingly, somewhere in the system it remembers what book I had
>open
 even through an uninstall/reinstall cycle. I suspect it has
>something to
 do
 with that.

 And whatever/wherever that data is, it also transcends books. If I
>create
 an entirely new book, it also immediately has the exact same
>missing
 column
 label problem

 It's also worth noting that the columns themselves are visible with
 normal
 appearing widths. Only the labels are missing. I've attached a
>screen
 shot.

 Is there another directory somewhere, or a set of registry entries,
>that
 also need to be deleted?

 Thank you,

 Scott


 On Sun, Dec 4, 2022 at 6:11 PM john  wrote:

 > That's a user-list question. I've changed the CC for your
>convenience.
 >
 > The file you're looking for is the book's metadata file, see
 > https://wiki.gnucash.org/wiki/Metadata_File. It stores among
>other
 things
 > window sizes and column widths for registers.
 >
 > Regards,
 > John 

Re: [GNC-dev] Git branches

[David T. via gnucash-devel]

No problem. I don't profess to be much of an expert on these points. Thanks for 
replying. 

⁣David T. ​

On Nov 14, 2022, 9:23 PM, at 9:23 PM, john  wrote:
>David,
>
>Unfortunately that's ambiguous without explaining that in that
>particular context release means major release series. In ordinary
>usage the current release is 4.12; it can't get any more commits. The
>next release is 4.13 and will release off what we now call the maint
>branch.
>
>Regards,
>John Ralls
>
>
>> On Nov 14, 2022, at 10:05 AM, David T. via gnucash-devel
> wrote:
>> 
>> Not that my opinion carries much weight on this, but
>"current-release" and "next-release" might be a reasonable set of
>options that are less wordy but still clear?
>> ⁣
>> David T.​
>> 
>> On Nov 14, 2022, 19:17, at 19:17, Geert Janssens
> wrote:
>>> This had been brewing in my mind as well, so thanks for bringing
>this
>>> up.
>>> 
>>> When I considered alternative branch names I initially thought of
>>> "stable" vs "development" 
>>> or "devel" with an optional "unstable" at times of pre-releases. 
>>> 
>>> However when thinking this through some more I started wondering
>>> whether we really 
>>> should limit ourselves to just two (or three) branch names.
>>> 
>>> We could also name our branches "4.x", "5.x" and so on to indicate
>the
>>> release series this 
>>> branch is for. At some point we just stop using the older branches.
>We
>>> can choose to drop 
>>> them or just leave them in the git history as it suits is best.
>>> 
>>> Both naming schemes have advantages and drawbacks. I like the direct
>>> relationship 
>>> between branch name and releases that will be on it for the latter
>>> scheme. Although I admit 
>>> this relationship doesn't hold for the pre-releases, unless we make
>>> that a separate branch for 
>>> those like eg "4.9xx".
>>> 
>>> Regards,
>>> 
>>> Geert
>>> 
>>> Op zondag 13 november 2022 21:40:14 CET schreef john:
>>>> Since Geert brought up our relationship with Github I thought it
>>> timely to
>>>> start a discussion about a related trend: The name of the git
>>> repository's
>>>> primary branches. There's an ongoing effort in the software
>>> development
>>>> community for the last 25-30 years or so to remove the terms master
>>> and
>>>> slave; originally when used together (as in processes) but more
>>> recently
>>>> when used alone. This recently includes the name of the primary
>>> branch in a
>>>> git repository. The Gitlab folks have a nice summary at
>>>> 
>>>
>https://about.gitlab.com/blog/2021/03/10/new-git-default-branch-name/.
>>>> 
>>>> 'Master' was the standard when we started using git 10 years ago
>and
>>> so we
>>>> adopted it and still use it. Aside from the cultural sensitivity
>>> issues
>>>> (primarily in the United States because of our unfortunate history
>>> with
>>>> forced importation and enslavement of Africans) it has proved to be
>a
>>> bit
>>>> confusing to new contributors.
>>>> 
>>>> The new standard default is 'main'. I think that would be fine for
>>> htdocs
>>>> where we have master and beta: Main would better express that
>that's
>>> the
>>>> branch that you see when you visit https://www.gnucash.org
>>>> <https://www.gnucash.org/>. The gnucash-on-foo repositories for the
>>> build
>>>> processes have only master branches so it doesn't really matter
>what
>>> the
>>>> branch is called.
>>>> 
>>>> I don't think 'main' is the right name for gnucash or gnucash-docs
>>> because
>>>> it does nothing about the confusion factor. Note that the default
>>> branch on
>>>> those two is maint but we still use master for the next major
>>> release's
>>>> branch. The most expressive titles would be current-major-release
>and
>>>> next-major-release but they're a bit wordy; OTOH just current (or
>>> curr) and
>>>> next leave a new contributor to ask current and next what? maint is
>>> concise
>>>> and not terrible for a branch that gets only bug fixes and small
>>> features.
>>>> Lots of generic names for the next-major-release branch (future,
>>> devel or
>>>> development, major-change) come to mind but I'm not sure that any
>of
>>> them
>>>> clearly express the intent of the branch.
>>>> 
>>>> Comments?
>>>> 
>>>> 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
>> ___
>> 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] Git branches

[David T. via gnucash-devel]

Not that my opinion carries much weight on this, but "current-release" and 
"next-release" might be a reasonable set of options that are less wordy but 
still clear?
⁣
David T.​

On Nov 14, 2022, 19:17, at 19:17, Geert Janssens  
wrote:
>This had been brewing in my mind as well, so thanks for bringing this
>up.
>
>When I considered alternative branch names I initially thought of
>"stable" vs "development" 
>or "devel" with an optional "unstable" at times of pre-releases. 
>
>However when thinking this through some more I started wondering
>whether we really 
>should limit ourselves to just two (or three) branch names.
>
>We could also name our branches "4.x", "5.x" and so on to indicate the
>release series this 
>branch is for. At some point we just stop using the older branches. We
>can choose to drop 
>them or just leave them in the git history as it suits is best.
>
>Both naming schemes have advantages and drawbacks. I like the direct
>relationship 
>between branch name and releases that will be on it for the latter
>scheme. Although I admit 
>this relationship doesn't hold for the pre-releases, unless we make
>that a separate branch for 
>those like eg "4.9xx".
>
>Regards,
>
>Geert
>
>Op zondag 13 november 2022 21:40:14 CET schreef john:
>> Since Geert brought up our relationship with Github I thought it
>timely to
>> start a discussion about a related trend: The name of the git
>repository's
>> primary branches. There's an ongoing effort in the software
>development
>> community for the last 25-30 years or so to remove the terms master
>and
>> slave; originally when used together (as in processes) but more
>recently
>> when used alone. This recently includes the name of the primary
>branch in a
>> git repository. The Gitlab folks have a nice summary at
>>
>https://about.gitlab.com/blog/2021/03/10/new-git-default-branch-name/.
>> 
>> 'Master' was the standard when we started using git 10 years ago and
>so we
>> adopted it and still use it. Aside from the cultural sensitivity
>issues
>> (primarily in the United States because of our unfortunate history
>with
>> forced importation and enslavement of Africans) it has proved to be a
>bit
>> confusing to new contributors.
>> 
>> The new standard default is 'main'. I think that would be fine for
>htdocs
>> where we have master and beta: Main would better express that that's
>the
>> branch that you see when you visit https://www.gnucash.org
>> . The gnucash-on-foo repositories for the
>build
>> processes have only master branches so it doesn't really matter what
>the
>> branch is called.
>> 
>> I don't think 'main' is the right name for gnucash or gnucash-docs
>because
>> it does nothing about the confusion factor. Note that the default
>branch on
>> those two is maint but we still use master for the next major
>release's
>> branch. The most expressive titles would be current-major-release and
>> next-major-release but they're a bit wordy; OTOH just current (or
>curr) and
>> next leave a new contributor to ask current and next what? maint is
>concise
>> and not terrible for a branch that gets only bug fixes and small
>features.
>> Lots of generic names for the next-major-release branch (future,
>devel or
>> development, major-change) come to mind but I'm not sure that any of
>them
>> clearly express the intent of the branch.
>> 
>> Comments?
>> 
>> 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
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

[GNC-dev] Updating Flatpak on Chrome book (WAS Re: [GNC] GnuCash Windows Bundle 4.11-1 Released)

[David T. via gnucash-devel]

Abe,

It's preferable to start a new thread, honestly. 

You should look at https://wiki.gnucash.org/wiki/Flatpak especially the section 
on installation, and see whether it addresses your issue. 

David T.


On July 3, 2022 9:25:43 AM EDT, Abe Sternberg  wrote:
>I'd like to take this discussion in a slightly different direction if
>permitted.
>
>I have updated my Windows version without a problem however, I also run
>GnuCash, v 4.8, on my Chromebook, for travel, and can't figure out how to
>upgrade
>it to version 4.11.  I used Flathub for the original install.
>
>Does anyone have any suggestions or ideas?
>
>Much appreciated,
>Abe
>
>On Sat, Jul 2, 2022 at 7:28 PM Fross, Michael  wrote:
>
>> Looks good on this end John.  Thank you very much!
>>
>> Michael
>>
>> On Sat, Jul 2, 2022 at 4:40 PM Gyle McCollam  wrote:
>>
>> > John, Thanks to you and all involved with keeping this programing going.
>> >
>> >
>> > Thank You,
>> >
>> > Gyle McCollam
>> >
>> > Gyle McCollam
>> >
>> > gmccol...@live.com   email
>> >
>> > 
>> > From: gnucash-user 
>> on
>> > behalf of John Ralls 
>> > Sent: Saturday, July 2, 2022 4:33 PM
>> > To: gnucash-annou...@lists.gnucash.org <
>> gnucash-annou...@lists.gnucash.org
>> > >
>> > Cc: gnucash-devel ; Gnucash Users <
>> > gnucash-u...@gnucash.org>
>> > Subject: [GNC] GnuCash Windows Bundle 4.11-1 Released
>> >
>> > This fixes https://bugs.gnucash.org/show_bug.cgi?id=798559, Online
>> > Actions missing from menus.
>> >
>> > It restores File>Import>MT940 and other SWIFT formats, Actions>Online
>> > Actions, and Tools>Online Banking Setup.
>> >
>> > 63d98c5873e58191cbac5c6ba4f269528c67911d0d63e2dd114e2f1c12c328a7
>> > gnucash-4.11-1.setup.exe
>> >
>> > Downloads:
>> > https://code.gnucash.org/builds/win32/releases/gnucash-4.11-1.setup.exe
>> >
>> >
>> https://downloads.sourceforge.net/gnucash/gnucash%20%28stable%29/4.11/gnucash-4.11-1.setup.exe
>> >
>> >
>> https://github.com/Gnucash/gnucash/releases/download/4.11/gnucash-4.11-1.setup.exe
>> >
>> > Regards,
>> > John Ralls
>> >
>> > ___
>> > 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-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-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-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: [GNC-dev] Cookbooks

[David T. via gnucash-devel]

Frank,

The entire Guide was originally written as a step-by-step "cookbook" 
with sections in each chapter "putting it all together." Those sections 
have slowly disappeared over time, in large part because they were 
overly specific (an existing example is the section that uses a Degas 
painting as an example of capital gains?!?), or used informal language 
that obscured the underlying concepts they were trying to explain. 
Putting case studies on the wiki is far and away a better solution than 
re-cluttering the Guide with information that only a few will need.


David T.

On 9/28/2020 12:02 PM, Frank H. Ellenberger wrote:



Am 28.09.20 um 16:35 schrieb Christopher Lam:

I'm not convinced the generic Guide is an appropriate location for such
country-specific recipes.

Neither you nor your draft told us explicitly that it is an Aussi thing. ;-)



The wiki is fine but has poor organisation.

I created Category:AU‎ and Category:GST/VAT on behalf of you and
populated the later after a simple search.
https://wiki.gnucash.org/wiki/Category:GST/VAT gives you an impression.


Hence my original query above.

Contrast: https://beancount.github.io/docs/

We do not have the human resources to maintain another set of docs.

But I would like to use "Cookbook & Examples" as title of a new part of
the Guide.

~Frank

___
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] Cookbooks

[David T. via gnucash-devel]

David,

Adding to the Appendices is, I think, a serious mistake. The Appendices 
are where good intentions go to be ignored and forever enshrined in 
2006. Take a look at the history and content of, for example, Appendices 
A and B for example.


David T.

On 9/28/2020 9:52 AM, David Carlson wrote:
Perhaps it would be better to format it as an appendix with 
reference(s) in appropriate places in the body of the Guide.  This 
would allow more detail for those who are interested without boring 
those who do not need the information.


On Mon, Sep 28, 2020 at 8:36 AM D. via gnucash-devel 
mailto:gnucash-devel@gnucash.org>> wrote:


I agree with Frank's suggestions. The Guide would be the best spot
(probably in the Business Setup area of chapter 13). And you do
need to expand abbreviations at the first instance.

From an editorial perspective, I think a little more explanatory
background would help users understand the purpose here. Also,
full account hierarchies are important (unless the GST account is
a top level account?).

David T.


 Original Message 
From: "Frank H. Ellenberger" mailto:frank.h.ellenber...@gmail.com>>
Sent: Mon Sep 28 09:20:21 EDT 2020
To: Christopher Lam mailto:christopher@gmail.com>>
Cc: gnucash-devel mailto:gnucash-devel@gnucash.org>>
Subject: Re: [GNC-dev] Cookbooks

Hi Chris,

in theory the Guide is the right place, but if you think it still
needs
improvement, you can put it in the wiki.

Note on your draft: Abbreviations should be defined on the first usage
or, if they are used in different places in the glossary and
linked from
the first occurrence in each page.

Regards
Frank

Am 28.09.20 um 14:05 schrieb Christopher Lam:
> Devel,
> Is there a suitable place where we could direct users to use
recipes to get
> going quickly?
> See draft, attached.

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



--
David Carlson

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

Re: [GNC-dev] Cookbooks

[David T. via gnucash-devel]

Sure. Wiki is fine.

I wasn't aware that it was country-specific, which certainly affects its 
proper placement. Probably that detail would be useful--as in, "Here is 
a quick how-to for managing GST in Genovia. It may also prove useful for 
other jurisdictions, such as Latveria and Wakanda."


David T.

On 9/28/2020 11:36 AM, John Ralls wrote:



On Sep 28, 2020, at 7:35 AM, Christopher Lam  wrote:

I'm not convinced the generic Guide is an appropriate location for such
country-specific recipes. The wiki is fine but has poor organisation.

Hence my original query above.

Contrast: https://beancount.github.io/docs/

That's supposed to be an example of good organization? Good grief.

I agree with you and disagree with David and Frank about putting articles like 
that in the guide. The Wiki is the right place for it. Add a link to 
https://wiki.gnucash.org/wiki/Using_GnuCash to help make it discoverable.

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

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

Re: [GNC-dev] [GNC] Transaction Report Sign Reverses

[David T. via gnucash-devel]

Chris,

Thanks for returning to this.

I see that this is a patch file for trep-engine.scm. My only experience 
using patches was when I was on a Mac; now I am on Windows, and wonder 
which tools to use to apply your patch.


Moreover, I am using 3.5, and do not find trep-engine.scm anywhere in 
C:\Program Files (x86)\gnucash. Does "recent build" mean?? GC 3.7?


Best,

David T.

On 10/13/2019 6:51 PM, Christopher Lam wrote:
Hi David, I'd had a review of transaction-report and can attempt fix 
signs for subtotals when sorting by 'account name'.
The difficult issue remains how to handle reversals when sorting by 
'other account name'. I think it's buggy and not sure how to handle it.

Try this patch to trep-engine.scm in a recent build.



On Mon, 12 Aug 2019 at 08:45, David T. > wrote:


Well, it seems odd to me that "Double" display (as Adrien
noted)(thank you, Adrien!) is able to display the figures as the
user prefers. It is also odd to me that the report knows to switch
the values of the individual transactions, but is unable to
remember that fact when it comes to the totals. That right there
is the problem.

As for the FAQ, it seems to me that there is a mistake in the
example there: the GnuCash option is to change signs for Income
*and* Expenses. But the example provided reverses Income but not
Expenses. Were it to reverse both sets of accounts as the
preference indicates, then the math should work out correctly
($100+10-20=$90). Or am I missing something here?

Why is it not possible to perform the calculation for totals and
then apply a display modifier so that the user sees numbers as
they prefer?

The current solution is a poor one.

On 8/12/2019 11:12 AM, Christopher Lam wrote:


https://wiki.gnucash.org/wiki/FAQ#Q:_Why_does_the_Transaction_Report_.27Sign_Reversal.27_setting_not_work_on_subtotals


This issue could be fixed if the scenario addressed in this FAQ
can be resolved. I don't really know how to handle that
particular case.

On Mon., 12 Aug. 2019, 13:02 David T. via gnucash-user,
mailto:gnucash-u...@gnucash.org>> wrote:

Hello,

I am trying to create a YTD Capital Gains report, and am
encountering a
problem with how the Transaction Report implements the Sign
Reverses
setting.

I recall some time back a discussion about the fact that the
Sign
Reverses setting reverses signs in these reports in a
confusing way.
There was some discussion about reversing the individual
transactions
but not the totals. Although I do not recall the specifics of
the
discussion, I am encountering the same situation now, where the
transactions themselves respect the user setting, but the
totals do not.
To say this is confusing is an understatement.

It seems to me that other financial applications must have
encountered
the problem of displaying income to users as a positive value
(since
that is how most of us view income!) while still finding a
way to
display the correct accounting information.

To display my YTD report of Capital Gains, I ran a
Transaction Report
and selected the Income:Realized Gains accounts for the
current year.
The result shows losses as positive numbers, and gains as
negative. I
don't know about you, but my expectation is reversed from
this. If I
change the Sign Reverses setting to Income and Expense, then the
transactions switch, but the totals do not. This result was
the gist of
the discussion in an earlier thread. Bleah!

Now, I know that I can copy the data, paste it into another
program and
change all the settings to my heart's content, but I am
looking for a
way to run a report in GnuCash that directly and
unambiguously shows me
whether I have gained money (a positive) or lost it (a
negative) over
the current year. Does anyone have suggestions?

FWIW, I attempted to turn this report around and have a
report that
lists transactions in the asset accounts, filtered by the
Income:Realized Gains accounts, but that seems to report only
the Asset
account currency--in this case, the mutual fund or stock
shares involved
on the Gain/Loss transaction. Unfortunately, that's not the
actual
Gain/Loss value...

It would be nice if the sign reverses setting could be fixed.
Barring
that, does anyone have a workaround report setup that can
give me a
sensible YTD Capital Gains total as described?

David T.

___
gnucash-user mailing list
 

Re: [GNC-dev] Budget accumulate amounts

[David T. via gnucash-devel]

"Show Accumulated Amounts"
would be my preference. 
David
 
 
  On Wed, Aug 21, 2019 at 9:09, Adrien 
Monteleone wrote:   How about: ‘report amounts 
as YTD’

If ‘Year’ isn’t necessarily a consistent concept, then something like you 
suggested, ‘report/use accumulated amounts’ would work.

I can play with it soon. (as well as test the First Day of Week fix) Now I 
guess I just need to set up a build workflow for Mac. (I’ve built on Ubuntu 
several times, but never tried on Mac yet)

Regards,
Adrien

> On Aug 20, 2019 w34d232, at 9:46 PM, Christopher Lam 
>  wrote:
> 
> Dear All
> 
> The current maint for upcoming 3.7 includes an upgrade to the basic budget
> report; it incorporates calculations to accumulate budgeted and actual
> amounts from the beginning of the budget period. The aim is to incorporate
> Phil Longstaff's budget-ytd strategy into the main budget report. I have
> labelled the option "General"/"Use envelope budgeting".
> 
> I am fairly certain that my calculations are correct but would like some
> confirmation. Moreover I am not happy with the option name. What should it
> be?
> e.g. "Accumulate amounts across periods", "Use accumulated amounts".
> 
> Suggestions welcome!

___
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] Import Main Matcher

[David T. via gnucash-devel]

To echo one part of John's comment, I recommend that any description of this 
process belongs in the Guide, and not the Help or on the wiki. Since chapter 3 
of the Guide is called "Importing into Gnucash," I would probably suggest to 
put it there.
David T. 

 
 
  On Wed, Aug 14, 2019 at 8:56, John Ralls wrote:   

> On Aug 13, 2019, at 6:25 PM, David Cousens  wrote:
> 
> At present the transaction importing documentation in the Help manual has no
> full description of how the import main matcher goes about the process of
> searching for and matching an imported transaction to an existing
> transaction or how it assigns a transfer account using the original mapping
> process or the more recent Bayesian approach. 
> 
> I am in the process of going through the code at present for my own
> edification and could create an expanded description of these processes in
> their current state either for inclusion in the Help manual or  as a Wiki
> page. My concern is that a detailed explanantion in the importing
> transaction section of the help manual may make that section too long
> winded. If that is not a significant issue, that would be my personal
> preference.
> 
> Does anyone have any strong preferences as to which is the better option ?

I'd rather not document internals in the T Implementation details aren't 
something that users need to worry about, so document there what it does, but 
not how. 

How belongs in comments in the code. Exported functions should have 
Doxygen-formatted comments so that they add to the API documentation 
(https://code.gnucash.org/docs/MAINT), local functions may also have 
non-Doxygen comments. Beware that a lot of our code follows the Gnome dispatch 
model where a static function is exported via a hand-written vtable, usually 
placed near the bottom of the source file. Those functions are really public 
and rate Doxygen documentation.

Bigger-picture documentation of a module's design also belongs in 
Doxygen-formatted comments. If you're not familiar with Doxygen see 
http://www.doxygen.nl/.

Regards,
John Ralls

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

Re: [GNC-dev] Reports Naming Problem

[David T. via gnucash-devel]

Actually, John, I was renaming the report in its options page and saving 
the result. I tried both the Save button and the Save As button without 
success (expecting in the latter case to get a second saved report under 
the new name, allowing me to delete the first).


In the olden days, the report title was the controlling aspect of a 
stored report, and I was changing that, expecting it to propagate 
through. Old habits die hard.


Best,

David

On 8/12/2019 11:41 PM, John Ralls wrote:



On Aug 12, 2019, at 9:23 AM, David T. via gnucash-devel 
 wrote:

Sending this to -Dev because of the technical aspect of the problem...

Over the years, my Saved Reports list had gotten unruly, with various one-off 
reports littering the folder. In an effort to figure out which reports were 
still valid, I undertook to open every report and delete those that were no 
longer useful to me.

However, the process was long, so I needed some way to flag the reports that I *had* 
vetted, and I chose to add an asterisk ("*") to the end of the report title. 
This postfix tagging worked fine; the tagged reports showed up in the list of reports 
with their new names, and they all ran just fine.

Now, having completed the process, I no longer need to keep track of which 
reports have been checked, and I thought I might remove these tags. 
Unfortunately, renaming the report (either by removing the text, or by adding 
some other text in its place) doesn't work; the asterisk remains regardless.

I realize that I can go into the saved-reports-2.8 file and manually rename 
them all, but that seemingly defeats the purpose of a user interface...

This is from the "saved report configurations" dialog using the "rename" button 
that looks like an edit icon?

I can add and remove asterisks from a report name there with no issues. It 
doesn't seem to matter whether I quit GnuCash between edits.

Regards,
John Ralls


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

[GNC-dev] Reports Naming Problem

[David T. via gnucash-devel]

Sending this to -Dev because of the technical aspect of the problem...

Over the years, my Saved Reports list had gotten unruly, with various 
one-off reports littering the folder. In an effort to figure out which 
reports were still valid, I undertook to open every report and delete 
those that were no longer useful to me.


However, the process was long, so I needed some way to flag the reports 
that I *had* vetted, and I chose to add an asterisk ("*") to the end of 
the report title. This postfix tagging worked fine; the tagged reports 
showed up in the list of reports with their new names, and they all ran 
just fine.


Now, having completed the process, I no longer need to keep track of 
which reports have been checked, and I thought I might remove these 
tags. Unfortunately, renaming the report (either by removing the text, 
or by adding some other text in its place) doesn't work; the asterisk 
remains regardless.


I realize that I can go into the saved-reports-2.8 file and manually 
rename them all, but that seemingly defeats the purpose of a user 
interface...


David

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

[GNC-dev] Delete wiki page

[David T. via gnucash-devel]

Hello,

I'd like to ask that the MacOS/FinkManual page be deleted from the wiki. It 
covers building gnucash 2.0 and earlier, and includes a large note at the top 
saying that the information is outdated. 

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

Re: [GNC-dev] GnuCash 3 on Linux

[David T. via gnucash-devel]

Adrien,
Using configuration files as a mechanism for working around the significant 
shortcomings of the reports ecosystem in Gnucash is tortured logic, at best. To 
be clear, I understand the challenges facing the team-- as well as accept that 
I am unable to effect change in these areas.  Nevertheless, I am disinclined to 
paper over these shortcomings by accepting such workarounds.

Furthermore, as I understand it, saved reports use the GUID of an account to 
refer to them, so any attempts at using a saved report from one file in another 
is likely doomed to fail. 


Or perhaps you're talking about settings associated with the standard reports? 
I profess I do not know how settings for these are stored-- although the fact 
that they are not stored with the actual saved reports (like the saved reports 
themselves) simply underscores the piecemeal mechanisms used for the reports. 

Your points about multiple user access are a red herring.  Since Gnucash 
doesn't support multiple users, there's no point in speculating on how we might 
circumvent this limitation.  

Gnucash does, however, support one user having multiple data files, and in this 
case, a user opening file B will see all the (useless) saved reports for file A.

Finally, the points originally raised regarding the scattershot storage of data 
that are integral to a set of books (whether reports, settings, or other data) 
remain.  

David T. 

 
 
  On Sun, Feb 24, 2019 at 9:14, Adrien 
Monteleone wrote:   One might want the same 
configuration in many respects and the same options on various reports to be 
’saved’ (since there is no other way to accomplish this task) as user 
configured defaults to be useful across various books.

Some people have separate files for many entities and they shouldn’t have to 
re-create all of that work for each one. You might always want to roll up child 
totals to the parent or not show zero balance accounts for example, regardless 
of the entity you are running reports for. Your accountant might always want to 
see reports following a certain format, different from the GnuCash defaults, 
regardless of the entity.

But I also see the case where multiple users might access the same data file 
and you’d want them all to have the same configuration for the book options and 
a standard set of reports to be able to run.

Certainly, there is room for improvement for a multi-user environment. (which 
GnuCash does not officially support at present from my understanding)

Perhaps the user environment itself should be an option which would determine 
where the various configurations are stored. (or more likely, how they are 
stored, as they should probably all be located *with* the data file, though not 
necessarily a part of it.)

Another option, specific to reports would be the ability to create a ‘custom 
default’ set of options. This would allow the creation of new books without 
having to 'remake the wheel’. (I understand ‘custom default’ may sound absurd 
to some, but think of this more like a ’template’.)

Regards,
Adrien

> On Feb 23, 2019, at 8:53 PM, David T. via gnucash-devel 
>  wrote:
> 
> Storing configuration data separately from the financial data and on a user 
> (as opposed to a book) basis is questionable.
> 
> Storing saved reports separately from the financial data and on a user basis 
> makes no sense at all. A saved report for one file will be meaningless in 
> another. This issue has come up many times on the lists. 
> 
> The fact that we even need a wiki page dedicated to file and configuration 
> locations-- let alone one as long and convoluted as the one we have (and 
> which needs additional diagramming)-- only underscores this problem. 
> 
> I want to be clear that I am truly grateful that Chris has decided to work on 
> reports, and I have great respect for his ability to work with Scheme. I've 
> yet to succeed in either editing an existing report or getting a third party 
> report installed on my Mac. 13 years of futility on that front!
> 
> David T. 
> 

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

Re: [GNC-dev] GnuCash 3 on Linux

[David T. via gnucash-devel]

While I take exception to Wm's tone and language, I agree with his overall 
assessment of the reports and configuration management.


Storing configuration data separately from the financial data and on a user (as 
opposed to a book) basis is questionable. 

Storing saved reports separately from the financial data and on a user basis 
makes no sense at all. A saved report for one file will be meaningless in 
another. This issue has come up many times on the lists. 

The fact that we even need a wiki page dedicated to file and configuration 
locations-- let alone one as long and convoluted as the one we have (and which 
needs additional diagramming)-- only underscores this problem. 

I want to be clear that I am truly grateful that Chris has decided to work on 
reports, and I have great respect for his ability to work with Scheme. I've yet 
to succeed in either editing an existing report or getting a third party report 
installed on my Mac. 13 years of futility on that front!

David T. 

 
 
  On Sun, Feb 24, 2019 at 7:55, David Cousens wrote:  
 Wm,

If you draw a diagram from the information in the wiki page
https://wiki.gnucash.org/wiki/Configuration_Locations
where the  meta data and report data is stored becomes fairly obvious and is
fairly simple. 

There was considerable discussion in the forums at the time the changes were
being made from 2.6 to 3.0. Not all users had the same report startegy you
were thinking of. Some users used the same report configurations with
different books. Going with the OS's recommendations has the advantage that
your backup strategy may be more general than that for a single app.

Note it is the report configuration which is saved in the configuration
locations not the report instance itself - that is in the book/main data
file and/or reconstructed from the data there when it is displayed.

It is fairly simple to store a copy of user and configuarion locations
contents with each data file if you really require the user and config data
to be backed up along with the data file.

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

[GNC-dev] Dormant Bugzilla Accounts

[David T. via gnucash-devel]

This message is probably directed to Derek…

In the course of editing the wiki on the subject of Bugzilla accounts, the 
question arose as to how many gnome.bugzilla.org  
accounts had been ported over to bugs.gnucash.org  
and remained in dormant status—and if there are still many of these, have the 
powers that manage these issues made any kind of determination on how these 
accounts will be handled now, should the account holder seek access again? 

It would seem to me that after a certain period of time, any accounts that 
remained unaccessed should be considered unused, and the account disabled. The 
user would then have to register from start again as if they were new users. 
Others felt that it would be appropriate to continue the original model for 
several years. 

Can someone inform me what practice will be followed in this regard?

The manner in which this issue is handled will affect the language and content 
of the wiki with regards to the Bugzilla wiki page, and I want to be sure that 
whatever gets put there reflects the practice and goals of the developer base.

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

[GNC-dev] gnucash.org logins

[David T. via gnucash-devel]

Hello,

I have noticed that the logins for bugs.gnucash.org  
and wiki.gnucash.org  are different. The former 
requires an email address; the latter allows user names. Is there any way to 
have these two logins be the same?

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

Re: [GNC-dev] Help manual improvements

[David T. via gnucash-devel]

David,
The file association feature is a recent (ish) addition, which explains the 
lack of documentation about it. 
There is an enhancement request pending since mid 2018 (bug 796660) noting this 
omission. Unfortunately, no one has taken up the cause. 
I asked a similar question at the beginning of 2018 
(lists.gnucash.org/pipermail/gnucash-user/2018-january/074200.html), and the 
reply from Geert summarizes the status as of that point. He notes specifically 
that the ability to remove an association was added for the 3.0 release.  There 
have also been changes to the path settings, but I don't have those in my brain 
right now. 
David T. 

 
 
  On Thu, Jan 31, 2019 at 5:00, David Carlson 
wrote:   addendum:

I have also found that I made an association using release 2.6.19 in
Windows 7 but it cannot be opened with release 2.6.17 in Ubuntu 16.04
because it is an absolute address including the Windows assigned Drive
letter to the remote server.  I assume that the Ubuntu file address also
includes the mount point address as well, so it would not be accessible
from Windows.  Is it possible to use relative addressing if the GnuCash
data file and the associated file[s] are on the same server?

David Carlson

On Wed, Jan 30, 2019 at 4:58 PM David Carlson 
wrote:

> I just created my first link from a transaction entry to an external file
> and I discovered that there is a symbol "w" shown in the A box to the right
> of the Notes field, at least in the two line view.  However, this is not
> mentioned in the help manual under the F1 key.  In fact, all I could find
> was the mention under the Account Register Transactions Menu section
> Associate File With Transaction and Associate Location with Transaction
> descriptions do not tell how to discover which transactions have files or
> locations associated with them.
>
> Also, is it possible to search for transactions with associated files or
> locations or to edit the link if it is incorrect?
>
> Please consider elaborating on this subject when upgrading the
> documentation.
>
> Also, how do you get to the Tutorial and Concepts Guide from the F1 Key?
>
> I was using release 2.6.17 in Ubuntu 16.04 to perform this association.
>
> David Carlson
>
___
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] [GNC] Debian package

[David T. via gnucash-devel]

Guys--
I'd recommend one list or the other-- not both.  Getting two copies of every 
one of your comments is too much. 
I've stripped gnucash-users from my reply because I think it better fits as a 
devel thread. 
David t. 

 
 
  On Tue, Jan 22, 2019 at 21:14, Colin Law wrote:   On Tue, 
22 Jan 2019 at 15:34, Stephen M. Butler  wrote:
>
> Looks like the dependency list from the mainline is missing a few
> entries.  I'll check that out.
>
> Also, here are the files for the debian folder used in the build.  Any
> suggestions or corrections would be appreciated.  Wondering if there is
> a way to package this all together instead of having three .deb files?

Sorry, I don't really know much about deb files.

Colin


Colin

>
> --Steve
>
>
> --
> Stephen M Butler, PMP, PSM
> stephen.m.butle...@gmail.com
> kg...@arrl.net
> 253-350-0166
> ---
> GnuPG Fingerprint:  8A25 9726 D439 758D D846 E5D4 282A 5477 0385 81D8
>
>
___
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

[GNC-dev] Tax Report Options: Payer Name Source Option

[David T. via gnucash-devel]

Hello,

On the Tax Report Options dialog, there is an option named “Payer Name Source” 
that once allowed the user to select “Current Account” or “Parent Account” as 
needed. This option, when set to “Parent Account" would force the TXF report to 
roll the information in a child account up to its parent (i.e., 
Expenses:Charity:MyCharity would display in the TXF report under 
Expenses:Charity).

I say “once” because I cannot seem to get this option now to activate; it is 
always greyed out. I have checked this in GC3.4 and GC2.6.19 on MacOS Mojave; 
it is not active in either. I know that it worked at some point, since I used 
it. Now, I cannot get it active to set.

Ideas?

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

[GNC-dev] Full Screen oddities GC3.4, Mac Mojave

[David T. via gnucash-devel]

Hi. 

I have found that GnuCash 3.4 behaves idiosyncratically when using full screen 
mode on MacOS. 

When in full screen mode, GC spawns every child window as full screen as well. 
This is rather jarring when the window in question is a question dialog (e.g., 
Do you want to create a new account? Y/N). Furthermore, attempts to exit full 
screen mode (e.g., by pressing Escape) can cause GC to crash (Bug #797059).

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

Re: [GNC-dev] The variable gnc_fq_update is not defined.

[David T. via gnucash-devel]

Odd. The message I received from the list had the image.

Rather than belabor the issue, I can say that the only additional bit of 
information in the dialog is that the message is followed by “(-2753)”, and the 
buttons are “Edit” and “OK”

David

> On Jan 12, 2019, at 9:25 PM, John Ralls  wrote:
> 
> No joy on the attachment. Maybe put it on pastebin or as a GitHub gist and 
> post a link?
> 
> Regards,
> John Ralls
> 
> 
>> On Jan 11, 2019, at 10:50 PM, David T. via gnucash-devel 
>>  wrote:
>> 
>> I will try again on the attachment…
>> 
>> 
>> 
>>> On Jan 12, 2019, at 12:02 PM, David T. via gnucash-devel 
>>>  wrote:
>>> 
>>> Hello,
>>> 
>>> Just downloaded Gnucash-3.4-1.dmg from Sourceforge. I opened the DMG, 
>>> copied Gnucash.app and “FinanceQuote Update.app” to Applications. I decided 
>>> that I might as well run FinanceQuote Update.app, since I haven’t done so 
>>> in some time. When I double-click /Applications/FinanceQuote Update.app, I 
>>> get the above error (screenshot hopefully attached). I’m not sure what 
>>> could have caused this problem.
>>> 
>>> 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
> 

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

Re: [GNC-dev] The variable gnc_fq_update is not defined.

[David T. via gnucash-devel]

I will try again on the attachment…



> On Jan 12, 2019, at 12:02 PM, David T. via gnucash-devel 
>  wrote:
> 
> Hello,
> 
> Just downloaded Gnucash-3.4-1.dmg from Sourceforge. I opened the DMG, copied 
> Gnucash.app and “FinanceQuote Update.app” to Applications. I decided that I 
> might as well run FinanceQuote Update.app, since I haven’t done so in some 
> time. When I double-click /Applications/FinanceQuote Update.app, I get the 
> above error (screenshot hopefully attached). I’m not sure what could have 
> caused this problem.
> 
> 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

[GNC-dev] The variable gnc_fq_update is not defined.

[David T. via gnucash-devel]

Hello,

Just downloaded Gnucash-3.4-1.dmg from Sourceforge. I opened the DMG, copied 
Gnucash.app and “FinanceQuote Update.app” to Applications. I decided that I 
might as well run FinanceQuote Update.app, since I haven’t done so in some 
time. When I double-click /Applications/FinanceQuote Update.app, I get the 
above error (screenshot hopefully attached). I’m not sure what could have 
caused this problem.

David

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

Re: [GNC-dev] Reports -- Cleanup

[David T. via gnucash-devel]

Stephen,
I'm sure I would welcome improvement in the reports. 
I don't have many concrete points here, except to suggest that the ideal UI 
point for a reconciliation report would be at the end of the reconciliation 
process. A check box on the reconcile window would trigger the report, 
automatically passing the current account and reconciliation dates along to the 
report. 
David T.
 
 
  On Tue, Jan 8, 2019 at 4:21, Stephen M. Butler wrote:   I 
think one of the developers here mentioned that there is a lot of
duplication in the reports arena.  I concur.  At first it was very
confusing as to which was the "correct" one.  Finally figured out none
where -- according to the in house SME (pronounced "smee" and standing
for Subject Matter Expert) and needed to roll my own.  Of which, I only
have the Balance Sheet sorta working like she wants it.

Following some email exchange via the bug reporting system regarding the
Transaction report module, I agree that it has too many options already
and requires a near programmer to figure out which options need to be
set what way to get something close to desirable.

Please note that I'm not a smee in this arena and, with my project
manager hat on, my wife barely qualifies.  There are others on this
mailing list better qualified who will have differing opinions. 

However, here are my thoughts:

1.  A transaction report (however it is organized) should always show
the split amount.  I propose that the Amount (None, Single, Double)
option be removed and the report always produces the Amount in two
columns Debit to the left and Credit to the right. 

2.  The Multi-line versus Single-line option may add confusion.  If one
wants to group the splits in a transaction together, then the report
should be organized that way.  When one picks the multi-line option, the
report becomes hard to read and understand especially as the other
splits are not included in the totals.  I suggest that Single-line be
the reporting style and the multi-line (meaning -- as best I can
determine -- multi-splits) removed.

These are just two of many simplifications that could be made to help
guide the end-user into the reports they need rather than letting them
create a report that is useless to them and anybody else.

Along those lines, I see this code needing to generate the following
types of reports:

A.  Transaction Journal -- this one lists the transactions within the
date range in date order and keeps all the splits together on the
report.  A printed version of the General Ledger screen (in multi-split
mode).

B.  Reconciliation Report -- rather than have the user pick the
accounts, a first pass should show the Dates within Accounts for which
there were reconciliations done (with the date range selected).  Let the
user select one or more of these to be reported, but each selection
becomes its own report or page.  Usually show the transactions
reconciled on that date (by account and in date order) optionally
followed by the transactions not yet reconciled within that account.

C.  Account Details -- here the user should pick the account(s) for
which the detailed transaction should be shown for the date range selected.

There may be a couple more variants, but if we start thinking about what
a bookkeeper/accountant needs we can reduce the number of options
available and thus remove complexity from the reports (at least this
particular one).

As a software engineer, I love to gold plate things.  As a project
manager, I realize that gold plates rarely provide the end user with
something useful.  Hey, but it looks good!

So, which options on the transaction report do you never use?  Which
options do you always set one particular way?

--Steve

-- 
Stephen M Butler, PMP, PSM
stephen.m.butle...@gmail.com
kg...@arrl.net
253-350-0166
---
GnuPG Fingerprint:  8A25 9726 D439 758D D846 E5D4 282A 5477 0385 81D8


___
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] Interest

[David T. via gnucash-devel]

Um, I wouldn't see putting this as a direct link of the top page of the wiki. 
It's a rather specific use case. Without digging into the wiki, I'd see it more 
as something from the Using Gnucash page, or the FAQ.

 
 
  On Sat, Dec 15, 2018 at 13:06, Geert Janssens 
wrote:   Op zaterdag 15 december 2018 08:23:55 CET schreef David Cousens:
> Frank
> I really can't see a logical place in the Wiki to add something on non
> interest bearing loans. If under Localization, I will need someone to create
> a link to a page I can put it together on as I don't have edit rights on
> the wiki front page but I can edit pages linked from it. Perhaps a title
> like "Non Interest Bearing Loans"
> 
> David

David,

I believe it works the other way around:
You first create your page and then someone with rights can add it to the 
front page.

You can create a new page by searching for it. As it's new the search results 
will have an option to create it. As far as I understand, we give page 
creation rights to every wiki editor.

Regards,

Geert


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

Re: [GNC-dev] Interest

[David T. via gnucash-devel]

Hamid,
I cannot comment on Michael's points; however, I think the point that others 
are making is that the loan assistant is meant to assist users in setting up 
*transactions* for an interest-bearing loan. 
Account setup-- including whether an account is classed as a liability-- is 
separate from how the transactions are handled. If you have a loan, you will 
put it as a liability and see it there in your chart of accounts. 
There is no bias against non-interest loans; there just is no reason to 
accommodate them in this assistant. Adding a note in the documentation-- 
perhaps in the wiki on the FAQ or on "Using Gnucash" pages might help others 
understand this. 
David
 
 
  On Wed, Dec 12, 2018 at 9:38, Hamidreza Jafari wrote: 
  I didn't follow Michael D Novack. Though I can clarify on some issues that 
were mentioned.

1 - Translation is not complete, my usage of the app is not exhaustive to try 
its ins and outs. I questioned if GnuCash is built with the mindset of priming 
interest over non-interest. The string I mentioned has either redundant 
information or contradicting information.

2 - I do not intend to draw lines but rather to question the line itself. That 
way agreement is facilitated or disagreement shows its hidden points of 
conflict.

3 - If GnuCash has a part dedicated to loans, a user would be happy to have 
all info about his loans under a Loans section rather than keeping notes to 
himself in roundabout ways. Accounting is a form of bookkeeping but usage of 
computing machines has provided some nifty features not possible with books. I 
talked about extending and refactoring to provide support if missing. This is 
about development not usage.

Hamid

On چهارشنبه ۱۲ دسامبر ۲۰۱۸ ۰:۴۱:۰۸ (+0330) Frank H. Ellenberger wrote:
> Hello Michael,
> 
> Am 11.12.18 um 16:32 schrieb Michael or Penny Novack:
> > On 12/11/2018 7:05 AM, Hamidreza Jafari wrote:
> >> Enter the annual interest rate in percent. Accepts values from 0.001 -
> >> 100.
> >> The Mortgage Assistant does not support zero-interest loans.
> >> 
> >> What's the situation?
> >> 
> >> Hamid
> > 
> > Needed for more than just Islam BUT perhaps this belongs in the "user"
> > discussion as maybe no programming involved.
> 
> If one of our translators comes up with such a question, there might -
> not must - something be suboptimal with our MsgIds, their documentation
> or our user doocumentation.
> 
> > You would need/use the "mortgage assistant" only for an amortizing loan
> > WITH interest. Just because you might be thinking of a loan as for the
> > same purpose as a mortgage (buying a house, etc.) does not make it one
> > as the term is being used in gnucash.
> 
> I would go further than Hamid. If you see the deposit facility rate at
> https://www.ecb.europa.eu/stats/policy_and_exchange_rates/key_ecb_interest_r
> ates/html/index.en.html
> 
> it is time to drop the restriction and allow zero and negative interest
> rates.
> 
> > Put your question on the other list as a "how do I do in gnucash"
> > spelling out ALL of the conditions of this loan. I'm not a Muslim but do
> > have an understanding of some of the forms of "no interest" loans and so
> > understand that while no interest MAY be conditions of "profit sharing"
> > if the property involved is sold before the loan paid off. Or in the
> > condition of losses if not forbidden as "iron sheep" contracts << that's
> > just to show you I do know something about traditional societies >>
> > 
> > Michael D Novack
> 
> ~Frank
> 
> ___
> 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: [GNC-dev] Wiki page removal

[David T. via gnucash-devel]

Ah. Ok. I guess I could do that next time!

 
 
  On Mon, Dec 3, 2018 at 17:34, Geert Janssens 
wrote:   Op maandag 3 december 2018 12:32:56 CET schreef David T. via 
gnucash-devel:
> Hello,
> I am requesting that someone with delete rights on the wiki remove
> wiki.gnucash.org/wiki/MacOSXInstallation
> Note the "X" in the url; I have duplicated the content into
> wiki.gnucash.org/wiki/MacOSInstallation
> and changed all referring pages to this.  This is to match Apple's
> nomenclature.  David
> 
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

David,

Thanks for cleaning up. I have made the original page redirect to the renamed 
page instead to avoid invalid links from outside of the wiki to this page.

Geert



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

[GNC-dev] Wiki page removal

[David T. via gnucash-devel]

Hello,
I am requesting that someone with delete rights on the wiki remove
wiki.gnucash.org/wiki/MacOSXInstallation
Note the "X" in the url; I have duplicated the content into
wiki.gnucash.org/wiki/MacOSInstallation
and changed all referring pages to this.  This is to match Apple's 
nomenclature. 
David

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

Re: [GNC-dev] Wiki:Dependencies

[David T. via gnucash-devel]

Never mind. I am stupid sometimes, and can’t read at others.

> On Oct 28, 2018, at 2:57 PM, David T. via gnucash-devel 
>  wrote:
> 
> Hello,
> 
> The wiki page on dependencies (https://wiki.gnucash.org/wiki/Dependencies 
> <https://wiki.gnucash.org/wiki/Dependencies>) includes a table that covers 
> dependencies up until version 2.4.0. Does anyone on the devel list have a 
> more up-to-date listing that could be inserted there?
> 
> David T.
> ___
> 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] Wiki:Dependencies

[David T. via gnucash-devel]

Hello,

The wiki page on dependencies (https://wiki.gnucash.org/wiki/Dependencies 
) includes a table that covers 
dependencies up until version 2.4.0. Does anyone on the devel list have a more 
up-to-date listing that could be inserted there?

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

[GNC-dev] Compatibility Question

[David T. via gnucash-devel]

Hello,

I am looking at 
https://wiki.gnucash.org/wiki/FAQ#Q:_Can_I_exchange_Gnucash_file_with_any_other_version_of_GnuCash.3F
 

 and I wondered whether there are any additional limitations in the downgrade 
path between 3.x and versions of 2.6.x? ISTR reading about some limits there.

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

[GNC-dev] Wiki Page: Configuration Locations

[David T. via gnucash-devel]

Hello,

The Configurations Locations wiki page 
(https://wiki.gnucash.org/wiki/Configuration_Locations 
), added in April 2018, 
appears primarily to cover information for GnuCash version 3 and up. I am not 
expert enough to say this with authority, but numerous examples (e.g., for the 
GTK aspects) suggest this.

Given that earlier versions of GnuCash are still supported, would someone with 
knowledge of this information be willing to add detail covering earlier 
versions? 

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

Re: [GNC-dev] Customizing GnuCash's Appearance and the Wiki

[David T. via gnucash-devel]

John,

Thanks. Given that we have decreed that the wiki should cover current versions 
(which are defined as 3.x, 2.6.x and sometimes 2.4.x), then my assumption is 
true enough for wikiland.

David

> On Oct 13, 2018, at 7:48 PM, John Ralls  wrote:
> 
> 
> 
>> On Oct 13, 2018, at 4:14 AM, David T. via gnucash-devel 
>>  wrote:
>> 
>> Hello,
>> 
>> I am hoping to clean up the FAQ section on customizing GC’s appearance, but 
>> I need a little background information first. My hope is to gather 
>> appearance customization into two separate pages. The first has already been 
>> created for GTK3 (which is appropriately named “GTK3”). I would like to 
>> think it should be possible to create another page for customization prior 
>> to GnuCash version 3 called “GTK2.” So, my first question is: is it accurate 
>> to say that all customization for earlier versions of GnuCash used GTK2? I 
>> certainly don’t want to mischaracterize the tools.
>> 
>> Once I have determined this, I plan to move information to these pages, and 
>> strip down the FAQ to refer readers to the appropriate page based on their 
>> GC version. Thus, the question on register colors and the question on the 
>> gtk resource file will have their information pushed into the two GTK pages.
> 
> It’s not quite true but it’s close enough: GnuCash started using Gtk2 with 
> GnuCash 2.0.
> 
> Regards,
> John Ralls

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

[GNC-dev] Customizing GnuCash's Appearance and the Wiki

[David T. via gnucash-devel]

Hello,

I am hoping to clean up the FAQ section on customizing GC’s appearance, but I 
need a little background information first. My hope is to gather appearance 
customization into two separate pages. The first has already been created for 
GTK3 (which is appropriately named “GTK3”). I would like to think it should be 
possible to create another page for customization prior to GnuCash version 3 
called “GTK2.” So, my first question is: is it accurate to say that all 
customization for earlier versions of GnuCash used GTK2? I certainly don’t want 
to mischaracterize the tools.

Once I have determined this, I plan to move information to these pages, and 
strip down the FAQ to refer readers to the appropriate page based on their GC 
version. Thus, the question on register colors and the question on the gtk 
resource file will have their information pushed into the two GTK pages.

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

Re: [GNC-dev] Delete WIki pages

[David T. via gnucash-devel]

Since you can delete pages, you probably get an infinitely larger paycheck than 
I do. ;)

Thanks.

David

> On Oct 13, 2018, at 4:29 PM, Geert Janssens  
> wrote:
> 
> Thanks for bringing this up. I have removed the obsolete pages although I 
> doubt I'm paid more than you for doing so ;)
> 
> Geert
> 
> Op zaterdag 13 oktober 2018 11:27:24 CEST schreef David T. via gnucash-devel:
>> Hello,
>> 
>> Someone above my pay grade should delete:
>> 
>> https://wiki.gnucash.org/wiki/Upgrade_from_1.8.9_to_1.8.10_and_HBCI_online_b
>> anking_support
>> <https://wiki.gnucash.org/wiki/Upgrade_from_1.8.9_to_1.8.10_and_HBCI_online
>> _banking_support> https://wiki.gnucash.org/wiki/Talk:GAAP
>> <https://wiki.gnucash.org/wiki/Talk:GAAP>
>> 
>> In addition, please remove the following line from the base wiki page (which
>> appears five lines from the end):
>> 
>> "* [[Upgrade from 1.8.9 to 1.8.10 and HBCI online banking support]]”
>> 
>> I’m pretty sure no one is in need of this information at this time.
>> 
>> 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

[GNC-dev] Delete WIki pages

[David T. via gnucash-devel]

Hello,

Someone above my pay grade should delete:

https://wiki.gnucash.org/wiki/Upgrade_from_1.8.9_to_1.8.10_and_HBCI_online_banking_support
 

https://wiki.gnucash.org/wiki/Talk:GAAP 


In addition, please remove the following line from the base wiki page (which 
appears five lines from the end):

"* [[Upgrade from 1.8.9 to 1.8.10 and HBCI online banking support]]”

I’m pretty sure no one is in need of this information at this time.

David
___
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]

Hello,

I have a general question about building. Forgive me if this is naive. The last 
time I used Linux was last century, and I believe that Linux has changed just a 
tad since then.

Since GnuCash is now developed over git, can't users|developers|writers|yetis 
use git for most distros to obtain source code and compile it on their 
machines? IOW, rather than offer voluminous directions on how to obtain the 
sources and compile GnuCash on every variant of YetiCompute, could we simply 
advise the majority of the community (yetis included) to use git to clone our 
repos and compile using git? It seems to me to be a colossal waste of community 
effort to attempt to account for every flavor of every distro. I contrast this 
with the (IMHO correct) stance on encryption, in which circumstance we advise 
users to find appropriate encryption tools, rather than build a half-crap 
version of our own.

Focusing our efforts on *a* GnuCash Way of building the program would simplify 
the wiki immensely.

> On Sep 18, 2018, at 12:18 PM, Adrien Monteleone 
>  wrote:
>> 
>>> The main building page is a massive tome. I did start breaking out some
>>> parts of it into smaller logical chunks when I updated the BuildUbuntu16.04
>>> ( which covers 16.04, 18.04 and Linux MInt 18 and 19 in effect.). 
>> 
>> Shouldn’t it be renamed to BuildUbuntu then?
> 
> I agree, the link text/page title is confusing and there have already been 
> questions about what instructions to use for building on 18.04.(yes, I see 
> that it says this is for 18.04 as well, but clearly someone didn’t or they 
> wouldn’t have asked)

If we continue with the Massive Tome Approach, I would recommend a title of 
“Building on Ubuntu"

> 
> If replacing content with a link to a dedicated page is desired practice for 
> cleaning up the wiki, then I’d propose all of the material for building on 
> Ubuntu be moved to that page, that it be renamed simply BuildUbuntu and that 
> the main build page be left with a link to it for the Ubuntu section. As it 
> is, the original build page still contains long outdated info. I would have 
> instead expected to see the most current instructions there and then maybe a 
> link for older versions.
> 
> Along with that, if older material for older systems and versions isn’t going 
> to be moved to its own ‘archive’ page, then it should always appear down the 
> page in chronological order. The current state of the build instructions is a 
> bit messy in that regard.

Older content should be removed altogether, not archived.


> 
> Regards,
> Adrien
> ___
> 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] ImpEx Sample files

[David T. via gnucash-devel]

> On Sep 18, 2018, at 11:46 AM, Frank H. Ellenberger 
>  wrote:
> 
> DTA
> https://de.wikipedia.org/wiki/Datentr%C3%A4geraustauschverfahren
> Was introduced by the german bank association ZKA
> - today: https://die-dk.de/en/ -
> in 1976 for magnetic tapes, later floppies, ...
> 2016-02-01 it was officially abandoned and replaced by
> B2B:
> https://en.wikipedia.org/wiki/Electronic_Banking_Internet_Communication_Standard,
> else: the above-mentioned ISO20022 (XML-Format).
> 
> While the wikipedia page describes the structure IMHO there is no need
> to document a abandoned format.
> 

If the format is abandoned, does GnuCash have to import it?


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

Re: [GNC-dev] Documentation Redo

[David T. via gnucash-devel]

Hello,

Once again, my words have gotten the better of me. I apologize for the length 
of this message...

I have to admit that I do not understand what part of this research qualifies 
it for an IgNobel—was it the “well, duh!” aspect, or was it that these folks 
took seven years to determine this, or was it that they were able to convince 
some funding agency to support it the whole time?

Setting that aside for a moment, it *is* useful to acknowledge that most 
people’s help preference is “to click around and get help when I need it.” TBH, 
that’s my style—although once I’ve done that a while, I am quite likely to sit 
down and read in more depth. While I doubt anyone is eager to strip out 
features from GnuCash (Budgets, anyone?), I think we *can* consider that 
perhaps our assistance modes might need to be reconsidered.

I have been focused on moving detailed information OUT of Help and putting it 
INTO the Guide, based on my own preferences and experiences with GnuCash. 
Perhaps that is misguided, insofar as most users aren’t turning to this 
resource consistently.

Assuming that a well-written but overlooked Guide is the proverbial falling 
tree in the forest, how should we be leading the Roaming Clicker to our oasis 
of Help? I think it is clear from the list traffic that we have quite a bit of 
room for improvement: new users regularly ask for help on topics that have 
coverage in the Help, the Guide and/or the wiki. So, we need to be looking for 
Something Better.

Bearing in mind the amount of work already placed in the existing 
documentation, I believe that we can establish a clear Assistance Continuum 
that uses context help to direct users to specific sections of the Guide. I 
have mentioned  this in other discussions recently, but I want to reiterate it 
here. We should transition the Context Help to contain brief descriptions with 
a “For more on this topic, see” link to the Guide in every instance. I believe 
this would support the needs of Roaming Clickers reasonably well, using the 
resources we have already got.

One major impediment to this is the linking features in our sources. There is 
little that can be done about this, however, short of changing our platform 
altogether—which past experience shows is doomed to stir up a lot of discussion 
with no ultimate change (“Full of sound and fury” comes to mind). As I see it, 
one of the major challenges in creating links is that we currently have no 
naming practices for the documents. This causes burdens: which elements receive 
tags? how do we form the names to assign? and on the other side, what name do I 
need to put in to link to the other? If we can establish *what* should get 
labels, and *how* we label them, I believe it would smooth a great deal of this 
process out. (Even better would be a means to use variables for these, so that 
references could automagically be generated without a user keying in a long 
link label. How cool would that be?).

The wild card in this Assistance Continuum is the wiki. There is a lot of 
useful information there; how would a user know to find it? Placing an actual 
link to the wiki is doomed to fail, since the wiki is by nature dynamic. Is 
there some way to add a canned search of the wiki to context help? This canned 
search would allow the user to retrieve information on the wiki as it existed 
at the time of the search, rather than at the time of the help authorship.

I imagine here that the Context Help writer would enter a couple of terms into 
a slot in the Help entry that would then be tacked on to a wiki search (and, 
yes, I am already thinking that a structured storage such as SQL might be a 
better approach to manage this). I will note that such wiki search 
functionality would of necessity require improvement of the wiki search 
feature, and perhaps a restructuring of how the wiki is created. My attempt to 
search the wiki for the entry on adjusting column widths 
(https://wiki.gnucash.org/wiki/FAQ#Q:_How_do_I_resize_my_register_columns.3F_Why_can_I_not_shrink_the_description_column.3F)
 was less than successful. Any search I entered at the wiki search box returned 
a link to the general FAQ page, which doesn’t help. Similar attempts using 
Google were unsuccessful as well (why *are* the pdf copies of the documentation 
stored on wiki.gnucash.org as well at www.gnucash.org—or are they the same 
files?).

Cheers,
David

> On Sep 16, 2018, at 11:11 PM, John Ralls  wrote:
> 
> So the IgNobel Prizes are out, and the “winner" of the literature prize is
> "Life Is Too Short to RTFM: How Users Relate to Documentation and "Excess 
> Features in Consumer Products”, 
> https://academic.oup.com/iwc/article/28/1/27/2363584 
> .
> 
> Maybe instead of doing a rewrite we should just bin the lot and put the 
> effort into stripping GnuCash down to the bare essentials.
> 
> 
> ;-)
> 
> Regards,
> John Ralls
> 
> 
> 

Re: [GNC-dev] Git Questions With Documentation

[David T. via gnucash-devel]

David,

I am glad that you are taking on this aspect of the docs. Thank you.

I would like to note to you (and reiterate for the larger group) the following 
important information:

I am a POOR CHOICE to be considered some kind of documentation expert. While I 
have a great deal of editorial experience, and have reasonable technical 
writing sensibilities, I have demonstrated over the years a profound and 
preternatural ability to mess up this documentation process. Placing your trust 
in my skills and abilities is likely to lead to trouble.

David

> On Sep 18, 2018, at 9:00 AM, David Cousens  wrote:
> 
> Hi Frank,
> 
> The problem I was having is that until David Ts changes are merged into the 
> main repo
> I can't pull them using either GitHub or GitKraken to my local repo from the 
> GnuCash-docs github.
> 
> I use Gitkraken and it has just allowed me to clone 
> https://github.com/sunfish62/gnucash-docs into a second repo on my
> computer so I should be able to feed any material to him through that. David 
> suggested I add sections on the other
> import  facilities i.e. DTAUS MT940 and MT942 I'm happy to do that but it 
> will be easier if I can do the changes here
> then send david a pull request. 
> 
> One problem I will have is getting sample files for the MT940, MT942 and 
> DTAUS formats so I can run through the
> interfaces. I have a friend who was a manager with Deutsche Bank a few years 
> ago but Klaus is now working for another
> company in Melbourne.
> 
> If you know where I can find any sample files I would appreciate getting hold 
> of them.  It would be good to have a
> collection of  sample files for testing Gnucash in any case as part of the 
> program. No problem for the internal ones
> that Gnucash can export. 
> Best wishes 
> David (Cousens)
> 
> On Tue, 2018-09-18 at 13:15 +0200, Frank H. Ellenberger wrote:
>> Hi David Cousens,
>> 
>> Am 18.09.18 um 10:36 schrieb David Cousens:
>>> David,
>>> 
>>> It was the master branch which was 139 commits behind. I looked at the maint
>>> branch and noticed it was up to date.
>>> 
>>> I have tried forking your repository but as I already had a fork of the main
>>> gnucash-docs repository github wasn't letting me fork your repository
>>> separately. It basically told me I already had that repository so no go. I
>>> could delete my copy of the main Gnucash repository and maybe then it would
>>> let me do it.
>> 
>> You can at least pull branches of forks like "BugXXX" in the repo on
>> your local machine. Usually you do not want to pull the maint and master
>> branch from forks under the same name.
>> 
>> I don't know, if it can also be done on the Github Web interface.
>> Perhaps David T. and Geert should document their progress in the wiki?
>> 
>>> One other way to do it may be to create the bug branch for the doc update   
>>> in the main Gnucash repository if John and Geert are willing to do that.   
>> 
>> David T. already pulled your work in
>> https://github.com/Gnucash/gnucash-docs/pull/115/commits
>> 
>>> something along the lines of the approach in the answer to this may be
>>> useful.
>>> https://stackoverflow.com/questions/14865283/proper-git-workflow-scheme-with-multiple-developers-working-on-same-tas
>>> k.
>>> 
>>> David Cousens
>> 
>> Frank
>> 
> ___
> 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] Documentation update problems

[David T. via gnucash-devel]

John, 

Thank you for stepping in. This looks much better now, and I believe I 
understand it, maybe. I have added a link to this page from the broader 
Documentation Update Instructions page (so it won’t be lonely).

David

> On Sep 17, 2018, at 3:04 PM, John Ralls  wrote:
> 
> 
> 
>> On Sep 17, 2018, at 10:49 AM, David T. via gnucash-devel 
>>  wrote:
>> 
>> Frank,
>> 
>>> On Sep 17, 2018, at 12:23 PM, Frank H. Ellenberger 
>>>  wrote:
>>> 
>>> Am 17.09.18 um 17:24 schrieb David T.:
>>>> 
>>>> I worked a bit on Build Tools to make the flow seem more natural; see 
>>>> whether you agree. 
>>> 
>>> I am no fan of "__NOTOC__" because I want often send a deep link (read
>>> page#section) to a user on IRC or MLs.
>> 
>> I think that the addition of a table of contents for a simple page is a 
>> waste of space, and pushes actual content off screen. 
>> 
>>> 
>>> The order was historical, so one could add "CMake has the following
>>> benefits over autotools …”
>>> 
>> 
>> I changed the order so that information about compiling the program would be 
>> covered before the information about compiling the documentation. I don’t 
>> see any text that lists CMake benefits versus Autotools, so perhaps this is 
>> no longer an issue?
>> 
>>>> With the rearrangement, I remain unclear on the last portion of the 
>>>> Autotools section, beginning with “So there remain 3 basic steps”
>>>> 
>>>> Does the following changed text capture your intent?
>>>> 
>>>> 
>>>> 
>>>> When using Autotools, there are 3 commonly-used commands:
>>>> 
>>>> • autogen.sh, which should be run after you check out a copy of the 
>>>> repository. 
>>>> • configure [options], which should be run after you install updates of 
>>>> your tools {not sure which tools?} or modify either makefile.am or 
>>>> configure.ac
>>>> • make , which is run after making edits. Common targets are all, 
>>>> check, and install.
>>>> 
>>>> Note that which build directory you use will affect the scope and output 
>>>> of your command.
>>>> 
>>>> 
>>>> I will note that for me, I *still* don’t know when I am required to re-run 
>>>> autogen.sh or configure; is there any downside to simply running them 
>>>> every time I mess around with the docs?
>>> 
>>> Because I saw the waekness, I worked on the section again. Can you reload?
>>> And yes, apply Johns answer. I will leave the page for now.
>> 
>> I saw your changes, but they continue to be unclear to me. Let me expand on 
>> my difficulties below
>> 
>> So there remain 3 basic steps:  <— it is unclear from the context what 
>> “remain” refers to. Remaining from what? Previously, we describe two 
>> “parts”; here we refer to “3 steps”—are these the same things?
>> 
>> <— in general, when listing “3 basic steps,” it is best for the enumerated 
>> list elements to *start* with what is being enumerated. That was a core part 
>> of the suggested text I provided above, and one I feel strongly about. As I 
>> decipher it, the three steps (which I referred to as “commands”) are 
>> autogen.sh, configure, and make. Is that correct?
>> 
>> After checking out of the repository run ./autogen.sh.
>> autogen.sh <https://github.com/Gnucash/gnucash-docs/blob/maint/autogen.sh> 
>> checks for the existence of autotools and (probably other build tools like 
>> intltool) and prepares your directory to use them. 
>> After you updatedat least one of the in the file mentioned tools, you should 
>> rerun it.  <— there is at least a typo here; "at least one of the” … what? 
>> “in the file mentioned tools” … what is a “file mentioned tool”?
>> Decide, which build directory to use and run the following steps in your 
>> build dir.  <— I have a problem here, insofar as it sounds as if this advice 
>> applies to step 2, but is listed as a subsidiary of step 1. Or is this a 
>> more general explanation to the effect of the note text I provided in my 
>> earlier rewrite (see above)?
>> After you
>> 
>> installed updates of not in autogen.sh mentioned tools or used libraries or  
>> <— I can’t make this out. Are you trying to say “installed updates in tools 
>> other than autogen.sh or installed other libraries”?
>> modified makefile.am or configure.ac
>> run configure [options].
>> Tip
>> configure --help will give you the full list of possible options.
>> Finally after your edits run make . Some common targets are all, 
>> check, install.
>> 
> 
> I've rewritten the page in a way that I hope is clearer and more correct for 
> David to use as a starting point.
> 
> Regards,
> John Ralls
> 

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

Frank,

> On Sep 17, 2018, at 12:23 PM, Frank H. Ellenberger 
>  wrote:
> 
> Am 17.09.18 um 17:24 schrieb David T.:
>> 
>> I worked a bit on Build Tools to make the flow seem more natural; see 
>> whether you agree. 
> 
> I am no fan of "__NOTOC__" because I want often send a deep link (read
> page#section) to a user on IRC or MLs.

I think that the addition of a table of contents for a simple page is a waste 
of space, and pushes actual content off screen. 

> 
> The order was historical, so one could add "CMake has the following
> benefits over autotools …”
> 

I changed the order so that information about compiling the program would be 
covered before the information about compiling the documentation. I don’t see 
any text that lists CMake benefits versus Autotools, so perhaps this is no 
longer an issue?

>> With the rearrangement, I remain unclear on the last portion of the 
>> Autotools section, beginning with “So there remain 3 basic steps”
>> 
>> Does the following changed text capture your intent?
>> 
>> 
>> 
>> When using Autotools, there are 3 commonly-used commands:
>> 
>> • autogen.sh, which should be run after you check out a copy of the 
>> repository. 
>> • configure [options], which should be run after you install updates of your 
>> tools {not sure which tools?} or modify either makefile.am or configure.ac
>> • make , which is run after making edits. Common targets are all, 
>> check, and install.
>> 
>> Note that which build directory you use will affect the scope and output of 
>> your command.
>> 
>> 
>> I will note that for me, I *still* don’t know when I am required to re-run 
>> autogen.sh or configure; is there any downside to simply running them every 
>> time I mess around with the docs?
> 
> Because I saw the waekness, I worked on the section again. Can you reload?
> And yes, apply Johns answer. I will leave the page for now.

I saw your changes, but they continue to be unclear to me. Let me expand on my 
difficulties below

So there remain 3 basic steps:  <— it is unclear from the context what “remain” 
refers to. Remaining from what? Previously, we describe two “parts”; here we 
refer to “3 steps”—are these the same things?

<— in general, when listing “3 basic steps,” it is best for the enumerated list 
elements to *start* with what is being enumerated. That was a core part of the 
suggested text I provided above, and one I feel strongly about. As I decipher 
it, the three steps (which I referred to as “commands”) are autogen.sh, 
configure, and make. Is that correct?

After checking out of the repository run ./autogen.sh.
autogen.sh  
checks for the existence of autotools and (probably other build tools like 
intltool) and prepares your directory to use them. 
After you updatedat least one of the in the file mentioned tools, you should 
rerun it.  <— there is at least a typo here; "at least one of the” … what? “in 
the file mentioned tools” … what is a “file mentioned tool”?
Decide, which build directory to use and run the following steps in your build 
dir.  <— I have a problem here, insofar as it sounds as if this advice applies 
to step 2, but is listed as a subsidiary of step 1. Or is this a more general 
explanation to the effect of the note text I provided in my earlier rewrite 
(see above)?
After you

installed updates of not in autogen.sh mentioned tools or used libraries or  <— 
I can’t make this out. Are you trying to say “installed updates in tools other 
than autogen.sh or installed other libraries”?
modified makefile.am or configure.ac
run configure [options].
Tip
configure --help will give you the full list of possible options.
Finally after your edits run make . Some common targets are all, check, 
install.




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

Re: [GNC-dev] Git Questions With Documentation

[David T. via gnucash-devel]

David,

I did not see this message previously; it got flagged as spam.

> On Sep 15, 2018, at 6:12 PM, David Cousens  wrote:
> 
> David 
> 
> Main reason I pushed it through to the current Help manual is that I had it 
> completed to slot in there already apart
> from a bit of minor debugging. If the current vesion of the guide continues 
> for v3.3 I thought it was worth having it in
> the help manual at least. I agree it is really material for the guide. I had 
> a look at your Github repository but I
> coudn't see a branch for the new guide and you were 139 commits behind the 
> maint on the Gnucash github, so I figured it
> was easier to put it there and you can extract it from there.

I think you might have been comparing my fork of the program here, rather than 
my fork of gnucash-docs. AFAICT, my gnucash-docs fork of maint is even with the 
main repo, and my branch for bug-796855 is 5 commits ahead of gnucash-docs.

> Changes are in Help_ch_Transactions.xml. I can send you
> the code that you can slot into an appropriate position in the guide or 
> formulate it as a pull request.  It is mainly
>  and  structures that should slot into an existing chapter 
> structure without any problem. I'll attach the
> XML file here as well.

I will try to dump your addition directly into mine shortly and see how that 
goes. If it happens smoothly, we can proceed from there.

> 
> There is one reference to a figure which is missing in the Import QIF section 
> as for some reason i couldn't pull it off
> the wiki and a few points where a couple of pics of the import matcher would 
> make things even clearer. I'll put together
> a patch for that. Probably worth waiting for the new guide to do that.
> 
> David Cousens

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

Frank,

> On Sep 17, 2018, at 10:47 AM, Frank H. Ellenberger 
>  wrote:
> 
> Hi David,
> 
> Am 17.09.18 um 14:59 schrieb David T.:
>> Hello,
>> 
>> Can anyone give me clear language on when and why a documentation creator 
>> would need to reissue the commands in Initializing Documentation Build 
>> Environment? I’d like to clear this issue up on the wiki before it gets lost.
>> 
>> David
> 
> because of some general confusion about the term make i.e. in
> https://wiki.gnucash.org/wiki/The_Make_Utility, I created recently
> https://wiki.gnucash.org/wiki/Build_Tools. It might still be incomplete
> or contain errors, so improvements are welcome. Feel free to link it,
> where ever required.

I worked a bit on Build Tools to make the flow seem more natural; see whether 
you agree. 

With the rearrangement, I remain unclear on the last portion of the Autotools 
section, beginning with “So there remain 3 basic steps”

Does the following changed text capture your intent?



When using Autotools, there are 3 commonly-used commands:

• autogen.sh, which should be run after you check out a copy of the repository. 
• configure [options], which should be run after you install updates of your 
tools {not sure which tools?} or modify either makefile.am or configure.ac
• make , which is run after making edits. Common targets are all, 
check, and install.

Note that which build directory you use will affect the scope and output of 
your command.


I will note that for me, I *still* don’t know when I am required to re-run 
autogen.sh or configure; is there any downside to simply running them every 
time I mess around with the docs?

David

P.S. - As a professionally-trained librarian, I hesitate to engage in 
categorization of the wiki. I am not prepared to develop a logical taxonomy for 
the wiki at this time, and half-baked taxonomies grate upon my sensibilities.


> 
> You might also counter check the recent changes in
> Documentation_Update_Instructions:
> https://wiki.gnucash.org/wiki/index.php?title=Documentation_Update_Instructions=revision=14469=13948
> 
> and other pages of
> https://wiki.gnucash.org/wiki/Category:Development .
> 
> N.B.: It would be nice, if you would add categories to
> https://wiki.gnucash.org/wiki/Initializing_Documentation_Build_Environment
> 
>>> On Sep 14, 2018, at 10:21 AM, David T.  wrote:
>>> 
>>> Frank, Geert,
>>> 
>>> I am finally following up on this thread, and I’d like to note that the 
>>> information that Frank says “got lost,” and which Geert has re-entered on 
>>> this page were actually moved to a different page 
>>> (https://wiki.gnucash.org/wiki/Initializing_Documentation_Build_Environment 
>>> )
>>>  and the reference to this information was moved up to Section 2. Setting 
>>> Up Your System.
>>> 
>>> Here we have an example of how duplicative information ends up in our 
>>> ecosystem!
> 
> That is a nice example, why you should make smaller changes. Instead of
> "Major rewrite of entire page" it would be better readable, if you would
> use separate steps of logical units:
> Move Section x in a new page;
> Move section y to appropriate position;
> Rewordening of section z; ...
> 
> :
> 
> 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]

Hello,

Can anyone give me clear language on when and why a documentation creator would 
need to reissue the commands in Initializing Documentation Build Environment? 
I’d like to clear this issue up on the wiki before it gets lost.

David

> On Sep 14, 2018, at 10:21 AM, David T.  wrote:
> 
> Frank, Geert,
> 
> I am finally following up on this thread, and I’d like to note that the 
> information that Frank says “got lost,” and which Geert has re-entered on 
> this page were actually moved to a different page 
> (https://wiki.gnucash.org/wiki/Initializing_Documentation_Build_Environment 
> <https://wiki.gnucash.org/wiki/Initializing_Documentation_Build_Environment>) 
> and the reference to this information was moved up to Section 2. Setting Up 
> Your System.
> 
> Here we have an example of how duplicative information ends up in our 
> ecosystem!
> 
> For the future, we should change the Documentation Update Instructions in 
> this section to point instead to the separate page set up for it. However, 
> there needs to be a clear instruction here as to why a user might need to 
> re-prepare their build environment. I, for one, have no idea why my build 
> environment was broken. I had already followed those directions previously 
> (as evidenced by the existence of the build folder structure on my system), 
> so what broke them? I imagine something along the lines of:
> 
> “If you have not built the documentation before, or if you {have changed some 
> miniscule aspect of your system | are incompetent like David T.}, it is 
> usually necessary to reconfigure your build environment as outlined in 
> Initializing Documentation Build Environment.”
> 
> Cheers,
> David
> 
>> On Aug 17, 2018, at 3:25 PM, Frank H. Ellenberger 
>> mailto:frank.h.ellenber...@gmail.com>> wrote:
>> 
>> Am 17.08.2018 um 09:18 schrieb Geert Janssens:
>>> Op vrijdag 17 augustus 2018 08:41:05 CEST schreef David T. via 
>>> gnucash-devel:
>> :
>> 
>>>> I’m not sure why there’s a “missing” in the initial command, and I don’t
>>>> know where config.guess is supposed to be—and I won’t even try to guess.
>>>> 
>>>> I would love to have some guidance.
>>>> 
>>> 
>>> I went to look at the wiki page and unfortunately it's incomplete. You get 
>>> this error because a few essential commands have been omitted.
>>> 
>>> I have added a section that should fill the gap. Can you proofread this:
>>> https://wiki.gnucash.org/wiki/ <https://wiki.gnucash.org/wiki/>
>>> Documentation_Update_Instructions#Prepare_The_Build_Directory
>>> And report back any issues you experience ?
>>> 
>>> It's written these steps are usually done early in in the set up process, 
>>> but 
>>> you can still run them right now and then retry the validation.
>>> 
>>> Geert
>> 
>> Yeah, the missing section got lost in
>> https://wiki.gnucash.org/wiki/index.php?title=Documentation_Update_Instructions=revision=13215=12785
>>  
>> <https://wiki.gnucash.org/wiki/index.php?title=Documentation_Update_Instructions=revision=13215=12785>
>> 
>> OTOH it was a major improvement of the readability.
>> 
>> Regards
>> Frank
>> 
> 

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

Re: [GNC-dev] README Overview; was: Gnome HIG

[David T. via gnucash-devel]

> On Sep 15, 2018, at 1:22 PM, John Ralls  wrote:
> 
> 
> 
>> Furthermore, in the interest of eliminating bit rot and in using the right 
>> tool for the right job, I would strip the README back drastically to cover 
>> only basic technical details on downloading, installing, and running 
>> GnuCash. Everything else should go, IMHO.
> 
> With pointers to where to find the other information, of course...
> 
> Regards,
> John Ralls


Of course! Always my intention.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] README Overview; was: Gnome HIG

[David T. via gnucash-devel]

And if we’re going there, the main project includes numerous README files in 
gnucash/doc, all of which need similar treatment. README files for WIN32, HCBI 
and OFX should IMHO be removed altogether in favor of other venues (didn’t HBCI 
get replaced by FinTS in, like, 2002?).

David

> On Sep 15, 2018, at 1:21 PM, David T.  wrote:
> 
> 
> 
>> On Sep 15, 2018, at 12:55 PM, David T. via gnucash-devel 
>>  wrote:
>> 
>> 
>> 
>>> On Sep 15, 2018, at 5:29 AM, Frank H. Ellenberger 
>>>  wrote:
>>> 
>>> As we are already there,
>>> 
>>> one of you Davids might also review
>>> https://github.com/Gnucash/gnucash/blob/maint/README section overview,
>>> 
>>> and probably  files in
>>> https://github.com/Gnucash/gnucash/tree/maint/doc
>>> https://github.com/Gnucash/gnucash-docs/blob/maint/gnucash-docs.spec.in
>>> ...
>>> which borrow the intro
>>> 
>>> There have been "shiny new features" of 1.x which no one any longer
>>> would mention for the 3.x series.
>>> 
>> 
>> Honestly, I think the text in the README would more accurately reflect 
>> John’s concerns about the breathless tone found in the Guide, and so I am 
>> more likely to put *that* text into the Guide, rather go the other way. 
>> 
>> Furthermore, in the interest of eliminating bit rot and in using the right 
>> tool for the right job, I would strip the README back drastically to cover 
>> only basic technical details on downloading, installing, and running 
>> GnuCash. Everything else should go, IMHO.
>> 
>> David
>> 
> 
> To be specific: in the main README, I would eliminate the Overview 
> altogether, and replace it with:
> 
> GnuCash is a double entry personal and small business financial management 
> package.
> 
> Home Page:
> http://www.gnucash.org/
> 
> Precompiled binaries:
> http://www.gnucash.org/download
> 
> That is it.
> 
> All the remaining sections should be altered to refer readers to the fuller 
> and more up-to-date information as it resides elsewhere (most notably, on the 
> wiki or website).
> 
>> ___
>> 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] Gnome HIG

[David T. via gnucash-devel]

That sounds like program development. I only do documentation. 

> On Sep 14, 2018, at 3:37 PM, Adrien Monteleone 
>  wrote:
> 
> Since John indicated there is not an effort to adhere to the current Gnome 
> HIG, that statement should probably be removed. (as they don’t conform any 
> longer)
> 
> But there are a few places where I think they can be simplified, particularly 
> some items in the Actions menu should probably be moved to Tools.
> 
> Regards,
> Adrien
> 
>> On Sep 14, 2018, at 1:57 PM, David T. via gnucash-devel 
>>  wrote:
>> 
>> Hello,
>> 
>> In the course of another arduous and lengthy thread, the question of the 
>> Gnome HIG came up. I attach the text in question below.
>> 
>> My question is whether the Guide needs changing at 1.2.1, where it says:
>> Easy to Use Menus: GnuCash menus conform to the GNOME Human Interface 
>> Guidelines. This means that they are simple and similar in appearance to 
>> many other GNOME applications. 
>> 
>> Is this statement inaccurate? Should it be removed?
>> 
>> David
>> 
>>  
>> Previous discussion:
>> 
>> I don't know about allowing room for it, but it's pretty far in the future 
>> because we still have too many Gnome dependencies in the core and too many 
>> MVC violations to be able to implement a different toolkit.
>> 
>> Regards,
>> John Ralls
>> 
>> 
>>> On Sep 11, 2018, at 10:23 AM, Adrien Monteleone 
>>> mailto:adrien.montele...@lusfiber.net>> 
>>> wrote:
>>> 
>>> Then I misunderstood some earlier discussions about the UI, at least with 
>>> respect to Linux. What toolkit is envisioned to be used? What layout 
>>> principles? Or are those questions so far in the future as to not be worth 
>>> spending time allowing room for?
>>> 
>>> Regards,
>>> Adrien
>>> 
>>>> On Sep 11, 2018, at 12:18 PM, John Ralls >>> <mailto:jra...@ceridwen.us>> wrote:
>>>> 
>>>> 
>>>> 
>>>>> On Sep 11, 2018, at 10:09 AM, Adrien Monteleone 
>>>>> mailto:adrien.montele...@lusfiber.net>> 
>>>>> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Sep 11, 2018, at 8:13 AM, David T. via gnucash-devel 
>>>>>> mailto:gnucash-devel@gnucash.org>> wrote:
>>>>>> 
>>>>>> In other words, unless there is a change in function, there is no need 
>>>>>> to change the functional description. It seems to me that putting text 
>>>>>> that doesn’t change into code is essentially a one-time process. Not 
>>>>>> necessarily easy, but once completed, not particularly obtrusive. 
>>>>>> Putting the functional description into code has the added benefit, 
>>>>>> perhaps, of alerting developers to the fact that if they change a 
>>>>>> feature, the description (right there in the code) needs an update as 
>>>>>> well.
>>>>> 
>>>>> While the principles might not change, or even the name/label of certain 
>>>>> buttons, the UI layout (where those buttons are, the fact that they are 
>>>>> buttons instead of menu entries, etc.) will very likely change as the 
>>>>> Gnome HIG is more faithfully implemented. But those code changes 
>>>>> shouldn’t affect anything generally in the Guide, and should auto update 
>>>>> the context help if it is drawn from the code itself. If not, then 
>>>>> consider that attempts to corral GnuCash within the confines of the Gnome 
>>>>> HIG, will produce such changes you’re thinking won’t happen.
>>>> 
>>>> Why do you think we're going to "more faithfully implement" the Gnome HIG? 
>>>> One of our long-term goals is to remove our Gnome dependencies. 
>>>> 
>>>> 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

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

Re: [GNC-dev] README Overview; was: Gnome HIG

[David T. via gnucash-devel]

> On Sep 15, 2018, at 12:55 PM, David T. via gnucash-devel 
>  wrote:
> 
> 
> 
>> On Sep 15, 2018, at 5:29 AM, Frank H. Ellenberger 
>>  wrote:
>> 
>> As we are already there,
>> 
>> one of you Davids might also review
>> https://github.com/Gnucash/gnucash/blob/maint/README section overview,
>> 
>> and probably  files in
>> https://github.com/Gnucash/gnucash/tree/maint/doc
>> https://github.com/Gnucash/gnucash-docs/blob/maint/gnucash-docs.spec.in
>> ...
>> which borrow the intro
>> 
>> There have been "shiny new features" of 1.x which no one any longer
>> would mention for the 3.x series.
>> 
> 
> Honestly, I think the text in the README would more accurately reflect John’s 
> concerns about the breathless tone found in the Guide, and so I am more 
> likely to put *that* text into the Guide, rather go the other way. 
> 
> Furthermore, in the interest of eliminating bit rot and in using the right 
> tool for the right job, I would strip the README back drastically to cover 
> only basic technical details on downloading, installing, and running GnuCash. 
> Everything else should go, IMHO.
> 
> David
> 

To be specific: in the main README, I would eliminate the Overview altogether, 
and replace it with:

GnuCash is a double entry personal and small business financial management 
package.

Home Page:
http://www.gnucash.org/

Precompiled binaries:
http://www.gnucash.org/download

That is it.

All the remaining sections should be altered to refer readers to the fuller and 
more up-to-date information as it resides elsewhere (most notably, on the wiki 
or website).

> ___
> 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] README Overview; was: Gnome HIG

[David T. via gnucash-devel]

> On Sep 15, 2018, at 5:29 AM, Frank H. Ellenberger 
>  wrote:
> 
> As we are already there,
> 
> one of you Davids might also review
> https://github.com/Gnucash/gnucash/blob/maint/README section overview,
> 
> and probably  files in
> https://github.com/Gnucash/gnucash/tree/maint/doc
> https://github.com/Gnucash/gnucash-docs/blob/maint/gnucash-docs.spec.in
> ...
> which borrow the intro
> 
> There have been "shiny new features" of 1.x which no one any longer
> would mention for the 3.x series.
> 

Honestly, I think the text in the README would more accurately reflect John’s 
concerns about the breathless tone found in the Guide, and so I am more likely 
to put *that* text into the Guide, rather go the other way. 

Furthermore, in the interest of eliminating bit rot and in using the right tool 
for the right job, I would strip the README back drastically to cover only 
basic technical details on downloading, installing, and running GnuCash. 
Everything else should go, IMHO.

David

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

Re: [GNC-dev] Git Questions With Documentation

[David T. via gnucash-devel]

David,

A couple of points.

Why not put this directly into the new chapter in the Guide, rather than into 
the Help? This is precisely the kind of detailed information that belongs IMHO 
in the Guide rather than Help. I know it’s not in Maint yet, but it will be 
shortly.

Next, in the interest of completeness, your list should include *all* import 
formats, and stub sections for those formats later on. Someone else can provide 
detail later on, but the basic description needs to be complete.

Otherwise, this looks great. Thanks!

David T.


> On Sep 14, 2018, at 9:29 PM, David Cousens  wrote:
> 
> David ,
> 
> I have completed the import section as an addition to the Help  manual  CH
> 6. I have put a pull request to gnucash-docs on Github to incorporate it
> into maint as the changes for the multiple selection may possibly go into
> the next release.
> 
> Once it has been pulled into the main Github repository as Bug 796856.  I
> think you will be able to get it by rebasing your repository to the maint
> branch of the gnucash-docs Github repository. I only know enough git to be
> dangerous so am not the best source of advice on how exactly to do that at
> this stage. I am starting to understand what is going on now. I have used
> git for quite a few years to my own repository but am now getting used to
> the 3 way operation for code and documentation updates to GnuCash.
> 
> 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

[GNC-dev] Gnome HIG

[David T. via gnucash-devel]

Hello,

In the course of another arduous and lengthy thread, the question of the Gnome 
HIG came up. I attach the text in question below.

My question is whether the Guide needs changing at 1.2.1, where it says:
Easy to Use Menus: GnuCash menus conform to the GNOME Human Interface 
Guidelines. This means that they are simple and similar in appearance to many 
other GNOME applications. 

Is this statement inaccurate? Should it be removed?

David

 
Previous discussion:

I don't know about allowing room for it, but it's pretty far in the future 
because we still have too many Gnome dependencies in the core and too many MVC 
violations to be able to implement a different toolkit.

Regards,
John Ralls


> On Sep 11, 2018, at 10:23 AM, Adrien Monteleone 
> mailto:adrien.montele...@lusfiber.net>> 
> wrote:
> 
> Then I misunderstood some earlier discussions about the UI, at least with 
> respect to Linux. What toolkit is envisioned to be used? What layout 
> principles? Or are those questions so far in the future as to not be worth 
> spending time allowing room for?
> 
> Regards,
> Adrien
> 
>> On Sep 11, 2018, at 12:18 PM, John Ralls > <mailto:jra...@ceridwen.us>> wrote:
>> 
>> 
>> 
>>> On Sep 11, 2018, at 10:09 AM, Adrien Monteleone 
>>> mailto:adrien.montele...@lusfiber.net>> 
>>> wrote:
>>> 
>>> 
>>> 
>>>> On Sep 11, 2018, at 8:13 AM, David T. via gnucash-devel 
>>>> mailto:gnucash-devel@gnucash.org>> wrote:
>>>> 
>>>> In other words, unless there is a change in function, there is no need to 
>>>> change the functional description. It seems to me that putting text that 
>>>> doesn’t change into code is essentially a one-time process. Not 
>>>> necessarily easy, but once completed, not particularly obtrusive. Putting 
>>>> the functional description into code has the added benefit, perhaps, of 
>>>> alerting developers to the fact that if they change a feature, the 
>>>> description (right there in the code) needs an update as well.
>>> 
>>> While the principles might not change, or even the name/label of certain 
>>> buttons, the UI layout (where those buttons are, the fact that they are 
>>> buttons instead of menu entries, etc.) will very likely change as the Gnome 
>>> HIG is more faithfully implemented. But those code changes shouldn’t affect 
>>> anything generally in the Guide, and should auto update the context help if 
>>> it is drawn from the code itself. If not, then consider that attempts to 
>>> corral GnuCash within the confines of the Gnome HIG, will produce such 
>>> changes you’re thinking won’t happen.
>> 
>> Why do you think we're going to "more faithfully implement" the Gnome HIG? 
>> One of our long-term goals is to remove our Gnome dependencies. 
>> 
>> Regards,
>> John Ralls
> 




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

Re: [GNC-dev] Yet another documentation compiling oddity

[David T. via gnucash-devel]

Sure. I defer to you. I was merely trying to anticipate that removal of 
“index.html” in the guide would cause some disruption.

> On Sep 14, 2018, at 12:10 PM, John Ralls  wrote:
> 
> 
> 
>> On Sep 14, 2018, at 7:55 AM, David T. via gnucash-devel 
>> mailto:gnucash-devel@gnucash.org>> wrote:
>> 
>> Hello,
>> 
>> As I am toiling through the depths of the documentation generation process, 
>> I am struck by the fact that the base page of the Help is “help.html”, while 
>> the base page for the guide is “index.html”.
>> 
>> For consistency, I suggest naming the guide base page “guide.html”; 
>> moreover, I suggest having a simple “index.html” placed in the documentation 
>> root folder (for me, that will be gnucash-docs/build”):
>> 
>> 
>> 
>> 
>>  > alink="#FF”>
>>  
>>> class="application">GnuCash Documentation
>>  
>>  
>>
>>> class="application">GnuCash Help 
>> Manual
>>Context menu and system help for 
>> GnuCash. 
>>
>>
>>> class="application">GnuCash 
>> Tutorial and Concepts Guide
>>Tutorial and Concept Guide for GnuCash, 
>> which provides in depth descriptions.
>>
>>  
>> 
>> 
> 
> Not quite. Remember that the documentation build is written to create the 
> documentation part of the website. 
> 
> We should change the name of gnucash-guide/index.html, but we should also 
> insert an index.html into every directory that raises an error to prevent 
> direct browsing; user access should be via https://www.gnucash.org/docs.phtml 
> <https://www.gnucash.org/docs.phtml> only. The generation of those index.html 
> files could be separated from the actual build both to avoid slowing the 
> build and to allow documenters to navigate separately from the TOCs in their 
> own build products.
> 
> I don’t think anything would be gained by having convenience index.html files 
> in the container directories for documenter browsing.
> 
> Regards,
> John Ralls
> 

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

[GNC-dev] Yet another documentation compiling oddity

[David T. via gnucash-devel]

Hello,

As I am toiling through the depths of the documentation generation process, I 
am struck by the fact that the base page of the Help is “help.html”, while the 
base page for the guide is “index.html”.

For consistency, I suggest naming the guide base page “guide.html”; moreover, I 
suggest having a simple “index.html” placed in the documentation root folder 
(for me, that will be gnucash-docs/build”):




  GnuCash 
Documentation
  
  
  
  GnuCash Help 
Manual
  Context menu and system help for 
GnuCash. 
  
  
  GnuCash Tutorial 
and Concepts Guide
  Tutorial and Concept Guide for GnuCash, 
which provides in depth descriptions.
  
  


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

Re: [GNC-dev] Documentation Build Oddity

[David T. via gnucash-devel]

> On Sep 14, 2018, at 10:28 AM, Frank H. Ellenberger 
>  wrote:
> 
> 
> 
> Am 14.09.18 um 15:57 schrieb David T. via gnucash-devel:
>> For fullest consistency, I would opt to have each of the formats placed in 
>> their own folder, named for tehir format:
>> 
>> epub *
>> html
>> mobi *
>> pdf *
> 
> *: Why do you want to create a directory for one file?

“For fullest consistency”: if you’re going to put one format into a folder, put 
every one in a folder. 

> 
>> 
>> (adding "gnucash-guide” is redundant, since the folder hierarchy already 
>> separates help from guide)
> 
> But both end on https://code.gnucash.org/docs/C/.
> ISTR we had to name the xmls - for yelp and naming them
> different depending on their output format would complicate the make files.

My build folder hierarchy is:

build
  \guide
\C
\de
[etc.]
  \help
\C
\de
[etc.]

IOW, the guide and help have separate hierarchies in build. I have no 
connection to code.gnucash.org, and have no knowledge as to how the information 
is stored there. ISTM that the structures of build environments should be 
consistent across systems.

> 
> Regards
> Frank
> 

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

Re: [GNC-dev] Issues with FOP - PDF generation

[David T. via gnucash-devel]

John,

> On Sep 14, 2018, at 10:11 AM, John Ralls  wrote:
> 
> 
> 
>> On Sep 14, 2018, at 4:49 AM, D via gnucash-devel  
>> wrote:
>> 
>> That seems odd; the install page at Apache says it's a java app, and 
>> installation consists of copying jar files. No mention of /usr/bin...
>> 
>> Unfortunately, MacOS is different. Maybe John has advice for me...
> 
> I build the docs for distribution on a Linux VM so I’ve never installed FOP 
> directly on MacOS. 
> 
> The catch is the invocation of FOP: The instructions on the page you gave 
> just copy jars to ~/Library/Java/Extensions and say to invoke it with 
>  java  java org.apache.fop.cli.Main -fo
> pdf.make wants to just say “fop” so you need a to arrange for that with a 
> two-line shell file
>  #!/bin/sh
>  java  java org.apache.fop.cli.Main -fo $@
> named fop and somewhere on the path.
> 
> Regards,
> John Ralls

Thanks for the info. I went the Brew route, which put the executable in 
/usr/local/bin for me.

David

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

Frank, Geert,

I am finally following up on this thread, and I’d like to note that the 
information that Frank says “got lost,” and which Geert has re-entered on this 
page were actually moved to a different page 
(https://wiki.gnucash.org/wiki/Initializing_Documentation_Build_Environment 
<https://wiki.gnucash.org/wiki/Initializing_Documentation_Build_Environment>) 
and the reference to this information was moved up to Section 2. Setting Up 
Your System.

Here we have an example of how duplicative information ends up in our ecosystem!

For the future, we should change the Documentation Update Instructions in this 
section to point instead to the separate page set up for it. However, there 
needs to be a clear instruction here as to why a user might need to re-prepare 
their build environment. I, for one, have no idea why my build environment was 
broken. I had already followed those directions previously (as evidenced by the 
existence of the build folder structure on my system), so what broke them? I 
imagine something along the lines of:

“If you have not built the documentation before, or if you {have changed some 
miniscule aspect of your system | are incompetent like David T.}, it is usually 
necessary to reconfigure your build environment as outlined in Initializing 
Documentation Build Environment.”

Cheers,
David

> On Aug 17, 2018, at 3:25 PM, Frank H. Ellenberger 
>  wrote:
> 
> Am 17.08.2018 um 09:18 schrieb Geert Janssens:
>> Op vrijdag 17 augustus 2018 08:41:05 CEST schreef David T. via gnucash-devel:
> :
> 
>>> I’m not sure why there’s a “missing” in the initial command, and I don’t
>>> know where config.guess is supposed to be—and I won’t even try to guess.
>>> 
>>> I would love to have some guidance.
>>> 
>> 
>> I went to look at the wiki page and unfortunately it's incomplete. You get 
>> this error because a few essential commands have been omitted.
>> 
>> I have added a section that should fill the gap. Can you proofread this:
>> https://wiki.gnucash.org/wiki/
>> Documentation_Update_Instructions#Prepare_The_Build_Directory
>> And report back any issues you experience ?
>> 
>> It's written these steps are usually done early in in the set up process, 
>> but 
>> you can still run them right now and then retry the validation.
>> 
>> Geert
> 
> Yeah, the missing section got lost in
> https://wiki.gnucash.org/wiki/index.php?title=Documentation_Update_Instructions=revision=13215=12785
> 
> OTOH it was a major improvement of the readability.
> 
> Regards
> Frank
> 

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

Re: [GNC-dev] Documentation Build Oddity

[David T. via gnucash-devel]

Geert,

> On Sep 14, 2018, at 3:17 AM, Geert Janssens  
> wrote:
> This was done to be able to separate html output from the other formats.
> 
> pdf, ebub and mobi all output one single file. html outputs a whole series of 
> files. Putting those in their own directory creates one entry point per 
> format 
> in the language directory.
> 
> Granted it could have been "gnucash-guide.html" for even more consistency.

For fullest consistency, I would opt to have each of the formats placed in 
their own folder, named for tehir format:

epub
html
mobi
pdf

(adding "gnucash-guide” is redundant, since the folder hierarchy already 
separates help from guide)

> Geert
> 
> 

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

Re: [GNC-dev] Issues with FOP - PDF generation

[David T. via gnucash-devel]

I saw that option before, but having gone the Fink route in the past, I had 
hoped not to incur the overhead (both computing and psychic) that those tools 
impose.

I bit the bullet and gave Brew a try. It wasn’t difficult at all, and fop now 
works. Thanks for reminding me.

David

> On Sep 14, 2018, at 9:31 AM, Adrien Monteleone 
>  wrote:
> 
> David,
> 
> fop is available via Homebrew for Mac. I don’t use Fink or MacPorts so can’t 
> speak for them.
> 
> Perhaps that route will prove fruitful.
> 
> Regards,
> Adrien

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

[GNC-dev] Documentation Build Oddity

[David T. via gnucash-devel]

Hello,

In trying to deal with compiling the documentation, I have been trying to use 
the newer “make” methods for building the html docs. I am wondering why these 
commands create the output in a new directory within the language 
trees—respectively, “gnucash-guide” and "gnucash-help”. I don’t see the need 
for another layer of folders in this system, and wonder whether the output 
could simply be put in the language folders directly. 

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

[GNC-dev] The Next Hangup

[David T. via gnucash-devel]

OK, so I thought it would be nice to look at the changes I am implementing in 
the documentation in PDF format, since I am rather old school, and like to see 
the changes in a print format.

I went to the wiki, and followed the new directions there to try to compile pdf 
documentation. 

First, I ran ./autogen.sh, and aside from numerous warnings about a non-POSIX 
variable name, everything went well.

Next, I changed to build and ran ../configure, and buried in there is the 
message:

configure: WARNING: fop not found. You will not be able to generate PDF files.

Ah. The wiki didn’t mention anything about this; a search online indicates that 
fop refers to Apache FOP, and I followed directions at 
http://www.working-software.com/node/18 
 to copy the various jar files into 
~/Library/Java/Extensions

Issuing “make pdf” however, yielded:
Making pdf in C
fo 'gnucash-guide.fo' -pdf 'gnucash-guide.pdf'
make[1]: fo: No such file or directory
make[1]: [gnucash-guide.pdf] Error 1 (ignored)

This is repeated for each of the language trees. Digging around on the Apache 
FOP pages led me down some scenic paths, but nothing seemed to shed light on 
the problem.

Suggestions welcome.

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

Re: [GNC-dev] Git Questions With Documentation

[David T. via gnucash-devel]

The typo came about because threw the changes back together quickly before 
dinner

I adopted option 1, and it seems to have worked. Not sure how this is any 
better.

David

> On Sep 13, 2018, at 8:05 PM, Frank H. Ellenberger 
>  wrote:
> 
> Am 14.09.18 um 00:38 schrieb David T.:
>> Updated as requested. My commit message includes the full output of "xmllint 
>> --valid --noout gnucash-guide.xml”
>> 
>> BTW, this sort of experience is yet another example of why I find this 
>> overall process to be inordinately painful. Some docbook guru will probably 
>> know immediately why this fails, but I sure as heck don’t, and having to 
>> muck around with this detracts from actually editing the text to be helpful.
>> 
>> David
> 
> At first there is a typo:
> warning: failed to load external entity
> "/home/frank/git/gnucash-docs/guide/C/ch_txnss.xml"
> 
> guide/C/gnucash-guide.xml:15
> -
> +
> 
> After that fix, I get
> 
> ch_txns.xml:1570: parser error : chunk is not well balanced
> 
> ^
> 
> That means you can not close a tag, which was already opened outside of
> the chunk(file)
> 
> There are several approachs:
> 
> 1.
> ch_basics.xml:
> 
>  The Basics
> :
> 
> 
> 
> 
> 
> 2. like with parts
> gnucash-guide.xml:
> :
> ch_basics.xml:
> 
> 
> 
> 
> 
> 
> 3. test XInclude
> 
> Currently I tend to 2. to keep all
> 
> 
> at one place.
> 
> Regards
> Frank
> 
> 

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

Re: [GNC-dev] Git Questions With Documentation

[David T. via gnucash-devel]

Updated as requested. My commit message includes the full output of "xmllint 
--valid --noout gnucash-guide.xml”

BTW, this sort of experience is yet another example of why I find this overall 
process to be inordinately painful. Some docbook guru will probably know 
immediately why this fails, but I sure as heck don’t, and having to muck around 
with this detracts from actually editing the text to be helpful.

David

> On Sep 13, 2018, at 2:46 PM, Geert Janssens  
> wrote:
> 
> Op donderdag 13 september 2018 14:32:12 CEST schreef D via gnucash-devel:
>> Frank,
>> 
>> It's not in my repo because I couldn't get it to compile. To get it to
>> compile, I had to incorporate the content of each file into ch_basics.xml.
>> 
>> AFAICT, the new files, ch_importing.xml and ch_configuring.xml, are in my
>> repo, attached to my bug-796855 branch. So are ch_accts.xml and
>> ch_txns.xml, which in my branch are not used any more.
>> 
>> If the general preference is to keep ch_accts.xml and ch_txns.xml as
>> separate files, I don't know how to make them work. In that case, would I
>> push these broken efforts to my own repo?
>> 
> David,
> 
> Yes, please do. That way others can help search for the issue.
> 
> Geert
> 
> 

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

Re: [GNC-dev] New Account Hierarchy Setup Assistant Questions

[David T. via gnucash-devel]

t;>>> 
>>>>>>>>>> I have a greater appreciation for the many different perspectives in 
>>>>>>>>>> the community, and thank everyone for their input.
>>>>>>>>>> 
>>>>>>>>>> David
>>>>>>>>>> 
>>>>>>>>>> On September 13, 2018, at 8:10 AM, Adrien Monteleone 
>>>>>>>>>>  wrote:
>>>>>>>>>> 
>>>>>>>>>> David,
>>>>>>>>>> 
>>>>>>>>>> I agree on all points.
>>>>>>>>>> 
>>>>>>>>>> Regards,
>>>>>>>>>> Adrien
>>>>>>>>>> 
>>>>>>>>>>> On Sep 12, 2018, at 10:19 PM, David Cousens 
>>>>>>>>>>>  wrote:
>>>>>>>>>>> 
>>>>>>>>>>> Adrien,
>>>>>>>>>>> 
>>>>>>>>>>> While I agree with the concept David T is proposing to streamline 
>>>>>>>>>>> the process for new users and the thrust of your
>>>>>>>>>>> comments about the new user experience, the new account heirarchy 
>>>>>>>>>>> at least as it is currently implemented, will be used
>>>>>>>>>>> by anyone creating a new set of books, whether they are experienced 
>>>>>>>>>>> Gnucash users, experienced accountants, total
>>>>>>>>>>> newbies or someone transferring from another program.
>>>>>>>>>>> 
>>>>>>>>>>> As a newbie you can get a perfectly usable set of accounts for 
>>>>>>>>>>> exploring Gnucash by simply clicking Next through the
>>>>>>>>>>> assistant then Apply and then saving the file. 
>>>>>>>>>>> 
>>>>>>>>>>> Perhaps this needs to be made clearer to new users as well as 
>>>>>>>>>>> informing them that any choices they make can be changed
>>>>>>>>>>> later (except for the very few cases where this is not possible - I 
>>>>>>>>>>> can't think of any but I personally don't currently
>>>>>>>>>>> use the full capabilty set of GnuCash's features but I used more in 
>>>>>>>>>>> the past). 
>>>>>>>>>>> 
>>>>>>>>>>> If this was done up front, they could then easily skip through.
>>>>>>>>>>> 
>>>>>>>>>>> The suggestion John made of creating a simplified new file option 
>>>>>>>>>>> with defaults based on the locale and an advanced
>>>>>>>>>>> setup option using the NAHS Assistant seems to meet this need as 
>>>>>>>>>>> well.  Even knowing what you want in a CoA requires a
>>>>>>>>>>> fair understanding of your accounting needs as well as the 
>>>>>>>>>>> functionality of GnuCash. Alternatively in other posts I
>>>>>>>>>>> think both Frank and I have suggested a checkbox which by default 
>>>>>>>>>>> disables selecting those options which a new user is
>>>>>>>>>>> going to find confusing and provides default values. 
>>>>>>>>>>> 
>>>>>>>>>>> I would have thought the CoA setup is not too bad. It comes with 
>>>>>>>>>>> the common accounts selected, it does perhaps give the
>>>>>>>>>>> new user a view that there is a lot more to explore. Some new users 
>>>>>>>>>>> will be looking for business functionality and other
>>>>>>>>>>> "advanced " functionality from the get go. There will always be a 
>>>>>>>>>>> few new users who will be confused by having to start
>>>>>>>>>>> the program.
>>>>>>>>>>> 
>>>>>>>>>>> Personally when evaluating software, I jump in without reading 
>>>>>>>>>>> manuals first because I figure if the interface isn't
>

Re: [GNC-dev] New Account Hierarchy Setup Assistant Questions

[David T. via gnucash-devel]

--nofile worked.

> On Sep 13, 2018, at 11:52 AM, John Ralls  wrote:
> 
> 
> 
>> On Sep 13, 2018, at 8:41 AM, David T. via gnucash-devel 
>>  wrote:
>> 
>> Odd. How would GnuCash access that on a different user login?
>> 
>> Just for completeness, I checked in /Library/Preferences as well, but did 
>> not find org.gnucash.Gnucash.plist there.
>> 
> 
> It shouldn’t. Did you try running GnuCash from the command line with --nofile 
> as your test user? Adrien’s testing suggests that there’s a problem with 
> gnc_get_file_to_load().
> 
> Regards,
> John Ralls
> 
> 

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

Re: [GNC-dev] New Account Hierarchy Setup Assistant Questions

[David T. via gnucash-devel]

>>>>>>> use the full capabilty set of GnuCash's features but I used more in 
>>>>>>>>> the past). 
>>>>>>>>> 
>>>>>>>>> If this was done up front, they could then easily skip through.
>>>>>>>>> 
>>>>>>>>> The suggestion John made of creating a simplified new file option 
>>>>>>>>> with defaults based on the locale and an advanced
>>>>>>>>> setup option using the NAHS Assistant seems to meet this need as 
>>>>>>>>> well.  Even knowing what you want in a CoA requires a
>>>>>>>>> fair understanding of your accounting needs as well as the 
>>>>>>>>> functionality of GnuCash. Alternatively in other posts I
>>>>>>>>> think both Frank and I have suggested a checkbox which by default 
>>>>>>>>> disables selecting those options which a new user is
>>>>>>>>> going to find confusing and provides default values. 
>>>>>>>>> 
>>>>>>>>> I would have thought the CoA setup is not too bad. It comes with the 
>>>>>>>>> common accounts selected, it does perhaps give the
>>>>>>>>> new user a view that there is a lot more to explore. Some new users 
>>>>>>>>> will be looking for business functionality and other
>>>>>>>>> "advanced " functionality from the get go. There will always be a few 
>>>>>>>>> new users who will be confused by having to start
>>>>>>>>> the program.
>>>>>>>>> 
>>>>>>>>> Personally when evaluating software, I jump in without reading 
>>>>>>>>> manuals first because I figure if the interface isn't
>>>>>>>>> intuitive to a decent extent, I am not going to want to go too much 
>>>>>>>>> further, unless I really have no other option.
>>>>>>>>> Intuitive for an experienced computer user can however be very 
>>>>>>>>> different for someone with limited experience. My wife
>>>>>>>>> never reads manuals ever, she just asks me. I on the other hand 
>>>>>>>>> consult my 5 year old grand daughter.
>>>>>>>>> 
>>>>>>>>> I share Mechtilde's concern that in making things easier for the new 
>>>>>>>>> user we don't lose functionality for the
>>>>>>>>> experienced user. We should hopefully look for mechanisms for doing 
>>>>>>>>> both.
>>>>>>>>> 
>>>>>>>>> David Cousens
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Wed, 2018-09-12 at 10:33 -0500, Adrien Monteleone wrote:
>>>>>>>>>> As someone who has helped other people get started using GnuCash 
>>>>>>>>>> (and remembering my own first steps) I agree
>>>>>>>>>> completely with these points. Those book preferences are not self 
>>>>>>>>>> explanatory. (perhaps bugs in their own right) A new
>>>>>>>>>> user is left to either trust the defaults and move on, pause and 
>>>>>>>>>> revisit the startup process several times while they
>>>>>>>>>> track down help info and digest it, or give up in frustration. (I’ve 
>>>>>>>>>> seen the latter three times—you may or not be
>>>>>>>>>> surprised how many people do *not* want to read a book before they 
>>>>>>>>>> start using a piece of software, I chose the second
>>>>>>>>>> option personally)
>>>>>>>>>> 
>>>>>>>>>> Unless the startup assistant (wizard, druid, whatever) can be 
>>>>>>>>>> redesigned as an explanatory walk through to choose
>>>>>>>>>> these settings, that part should be removed and the defaults chosen 
>>>>>>>>>> for the user.
>>>>>>>>>> 
>>>>>>>>>> As for trading accounts, I turned them on after the fact for 
>>>>

Re: [GNC-dev] New Account Hierarchy Setup Assistant Questions

[David T. via gnucash-devel]

n without reading manuals 
>>>>>>> first because I figure if the interface isn't
>>>>>>> intuitive to a decent extent, I am not going to want to go too much 
>>>>>>> further, unless I really have no other option.
>>>>>>> Intuitive for an experienced computer user can however be very 
>>>>>>> different for someone with limited experience. My wife
>>>>>>> never reads manuals ever, she just asks me. I on the other hand consult 
>>>>>>> my 5 year old grand daughter.
>>>>>>> 
>>>>>>> I share Mechtilde's concern that in making things easier for the new 
>>>>>>> user we don't lose functionality for the
>>>>>>> experienced user. We should hopefully look for mechanisms for doing 
>>>>>>> both.
>>>>>>> 
>>>>>>> David Cousens
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On Wed, 2018-09-12 at 10:33 -0500, Adrien Monteleone wrote:
>>>>>>>> As someone who has helped other people get started using GnuCash (and 
>>>>>>>> remembering my own first steps) I agree
>>>>>>>> completely with these points. Those book preferences are not self 
>>>>>>>> explanatory. (perhaps bugs in their own right) A new
>>>>>>>> user is left to either trust the defaults and move on, pause and 
>>>>>>>> revisit the startup process several times while they
>>>>>>>> track down help info and digest it, or give up in frustration. (I’ve 
>>>>>>>> seen the latter three times—you may or not be
>>>>>>>> surprised how many people do *not* want to read a book before they 
>>>>>>>> start using a piece of software, I chose the second
>>>>>>>> option personally)
>>>>>>>> 
>>>>>>>> Unless the startup assistant (wizard, druid, whatever) can be 
>>>>>>>> redesigned as an explanatory walk through to choose
>>>>>>>> these settings, that part should be removed and the defaults chosen 
>>>>>>>> for the user.
>>>>>>>> 
>>>>>>>> As for trading accounts, I turned them on after the fact for tracking 
>>>>>>>> commodities as additional currencies. I’ve never
>>>>>>>> bought or sold any since doing that, but I’ve played with turning the 
>>>>>>>> setting on and off to experiment with the
>>>>>>>> setting’s effect on some reports and I’ve never noticed any issues. 
>>>>>>>> (but again, I only have opening balance
>>>>>>>> transactions in each currency) If turning Trading Accounts off after 
>>>>>>>> entering buy/sell transactions is bad news, then
>>>>>>>> I would think the option to do so should be disabled.
>>>>>>>> 
>>>>>>>> Regards,
>>>>>>>> Adrien
>>>>>>>> 
>>>>>>>>> On Sep 12, 2018, at 9:38 AM, David T. via gnucash-devel 
>>>>>>>>>  wrote:
>>>>>>>>> 
>>>>>>>>> Hello,
>>>>>>>>> 
>>>>>>>>> As I begin the process of migrating text from the Help to the Guide 
>>>>>>>>> (cf. Bug 796855), I am working on the Help
>>>>>>>>> information regarding the New Account Hierarchy Setup (NAHS) 
>>>>>>>>> assistant, and I have a couple of questions about the
>>>>>>>>> second screen of the assistant, the “New Book Options” screen. 
>>>>>>>>> 
>>>>>>>>> First off, while I respect the intent to allow users the option to 
>>>>>>>>> set these preferences from the creation of their
>>>>>>>>> file, I wonder whether this is misguided. To wit: all of these 
>>>>>>>>> options are quite technical in nature, and all of
>>>>>>>>> them can be set at a later point by opening the appropriate 
>>>>>>>>> preferences. Adding these options here adds complexity
>>>>>>>>> that can easily be deferred to a later point. While it is true that 
>>>>>>>>> this assistant runs whenever a user chooses
>>>>>>>>> File->New (meaning that an experienced user might wish to add these 
>>>>>>>>> settings from the assistant), I am willing to
>>>>>>>>> hazard a guess that most users will invoke this assistant *only* when 
>>>>>>>>> they first start using GnuCash, and *only*
>>>>>>>>> when their heads are already swimming with the overwhelming 
>>>>>>>>> experience that is GnuCash. Asking a new user to choose
>>>>>>>>> whether to use Trading Accounts or to Use Split Action Field for 
>>>>>>>>> Number is IMHO pointless. They aren’t going to be
>>>>>>>>> able to make an informed decision. 
>>>>>>>>> 
>>>>>>>>> I’ll note that this becomes an obvious issue when I attempt to 
>>>>>>>>> write the help section for the screen. I am
>>>>>>>>> left either with writing a huge explanatory section on the details of 
>>>>>>>>> each of these settings, which detracts from
>>>>>>>>> the flow of the NAHS narrative, or with adding a generic note that 
>>>>>>>>> advises users to accept the defaults and read
>>>>>>>>> about the details in other sections of the Guide.
>>>>>>>>> 
>>>>>>>>> So, for the new user, the only real effect of this screen is to 
>>>>>>>>> introduce confusion and questions. Can it be removed
>>>>>>>>> from the assistant?
>>>>>>>>> 
>>>>>>>>> Related to this screen, my second question has to do with the “Use 
>>>>>>>>> Trading Accounts” setting. Can it be turned off
>>>>>>>>> once it has been enabled in a given GnuCash file?
>>>>>>>>> 
>>>>>>>>> ISTR that this option is a one-way street—i.e., that, once turned on, 
>>>>>>>>> it can not be turned off again. Is this still
>>>>>>>>> the case? If it is still true, then I would strongly suggest that 
>>>>>>>>> this option shouldn’t be placed on the NAHS
>>>>>>>>> Assistant, since a new user won’t be aware of this.
>>>>>>>>> 
>>>>>>>>> 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
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> ___
>>>>>> 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
> 
> ___
> 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] New Account Hierarchy Setup Assistant Questions

[David T. via gnucash-devel]

ftware, I jump in without reading manuals 
>>> first because I figure if the interface isn't
>>> intuitive to a decent extent, I am not going to want to go too much 
>>> further, unless I really have no other option.
>>> Intuitive for an experienced computer user can however be very different 
>>> for someone with limited experience. My wife
>>> never reads manuals ever, she just asks me. I on the other hand consult my 
>>> 5 year old grand daughter.
>>> 
>>> I share Mechtilde's concern that in making things easier for the new user 
>>> we don't lose functionality for the
>>> experienced user. We should hopefully look for mechanisms for doing both.
>>> 
>>> David Cousens
>>> 
>>> 
>>> 
>>> 
>>> On Wed, 2018-09-12 at 10:33 -0500, Adrien Monteleone wrote:
>>>> As someone who has helped other people get started using GnuCash (and 
>>>> remembering my own first steps) I agree
>>>> completely with these points. Those book preferences are not self 
>>>> explanatory. (perhaps bugs in their own right) A new
>>>> user is left to either trust the defaults and move on, pause and revisit 
>>>> the startup process several times while they
>>>> track down help info and digest it, or give up in frustration. (I’ve seen 
>>>> the latter three times—you may or not be
>>>> surprised how many people do *not* want to read a book before they start 
>>>> using a piece of software, I chose the second
>>>> option personally)
>>>> 
>>>> Unless the startup assistant (wizard, druid, whatever) can be redesigned 
>>>> as an explanatory walk through to choose
>>>> these settings, that part should be removed and the defaults chosen for 
>>>> the user.
>>>> 
>>>> As for trading accounts, I turned them on after the fact for tracking 
>>>> commodities as additional currencies. I’ve never
>>>> bought or sold any since doing that, but I’ve played with turning the 
>>>> setting on and off to experiment with the
>>>> setting’s effect on some reports and I’ve never noticed any issues. (but 
>>>> again, I only have opening balance
>>>> transactions in each currency) If turning Trading Accounts off after 
>>>> entering buy/sell transactions is bad news, then
>>>> I would think the option to do so should be disabled.
>>>> 
>>>> Regards,
>>>> Adrien
>>>> 
>>>>> On Sep 12, 2018, at 9:38 AM, David T. via gnucash-devel 
>>>>>  wrote:
>>>>> 
>>>>> Hello,
>>>>> 
>>>>> As I begin the process of migrating text from the Help to the Guide (cf. 
>>>>> Bug 796855), I am working on the Help
>>>>> information regarding the New Account Hierarchy Setup (NAHS) assistant, 
>>>>> and I have a couple of questions about the
>>>>> second screen of the assistant, the “New Book Options” screen. 
>>>>> 
>>>>> First off, while I respect the intent to allow users the option to set 
>>>>> these preferences from the creation of their
>>>>> file, I wonder whether this is misguided. To wit: all of these options 
>>>>> are quite technical in nature, and all of
>>>>> them can be set at a later point by opening the appropriate preferences. 
>>>>> Adding these options here adds complexity
>>>>> that can easily be deferred to a later point. While it is true that this 
>>>>> assistant runs whenever a user chooses
>>>>> File->New (meaning that an experienced user might wish to add these 
>>>>> settings from the assistant), I am willing to
>>>>> hazard a guess that most users will invoke this assistant *only* when 
>>>>> they first start using GnuCash, and *only*
>>>>> when their heads are already swimming with the overwhelming experience 
>>>>> that is GnuCash. Asking a new user to choose
>>>>> whether to use Trading Accounts or to Use Split Action Field for Number 
>>>>> is IMHO pointless. They aren’t going to be
>>>>> able to make an informed decision. 
>>>>> 
>>>>> I’ll note that this becomes an obvious issue when I attempt to 
>>>>> write the help section for the screen. I am
>>>>> left either with writing a huge explanatory section on the details of 
&g

[GNC-dev] Git Questions With Documentation

[David T. via gnucash-devel]

Hello,

I am sending this message as a heads up that I am preparing a PR for bug 
796855, which seeks to pull content from the Help Manual Chapter 3 and put it 
into the Guide in Chapter 2. 

In the course of doing this, a number of other changes were called for, such 
that I needed to add the beginnings of two new proposed chapters to the Guide: 
Importing Data (as suggested in bug 303164), and Configuring GnuCash (which 
ultimately will come from Help Chapter 10). 

Adding these chapters necessitated my editing gnucash-guide.xml to include 
these new chapters, and since I was tinkering with the overall structure of the 
Getting Started section of the Guide, I chose to incorporate the chapters on 
Accounts and Transactions into the Basics chapter, as proposed in bug 687820. 

I tried to retain ch_accts.xml and ch_txns.xml in gnucash-guide.xml and 
simply edit the three files so that they became parts of a single chapter, but 
this resulted in mysterious “Failure to process entity chapter2” errors that I 
was entirely unable to edit away, except by copying the content of those two 
files directly into ch_basics.xml. So much for the “Use separate files and link 
them in docbook” approach.

Anyway, the PR has gotten entirely beyond my git skill set—meaning that, no 
matter what I do next, I will mess it up. My PR will have two new files to add 
to the repo, and ideally should have two files to remove from the repo, and I 
am unsure how to account for either circumstance.

Advice?

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

Re: [GNC-dev] New Account Hierarchy Setup Assistant Questions

[David T. via gnucash-devel]

> On Sep 12, 2018, at 7:03 PM, John Ralls  wrote:
> 
> Most individuals who aren’t familiar with formal accounting should probably 
> be using something other than GnuCash. If all you want to do is keep track of 
> your credit card, demand bank account (“checking account” for us fogies who 
> remember checks), and a couple of mutual funds then GnuCash is swatting flies 
> with a sledgehammer.

I think that’s a little disingenuous; the user base for GnuCash is broad, as 
reflected in the mailing list archives. Perhaps we should put a banner across 
the top of the Home page that reads: “Abandon Hope, All Ye Non-CPAs.”  ;)

> That said, I think the only immutable parameter in setting up a new book is 
> the root account currency, and that can be derived from the locale. How about 
> renaming the NAHSA the "Advanced New Book Assistant" with its own menu item 
> and have File>New just create a bare “Common Accounts” book for the current 
> locale? We could pop up a dialog for opening balances on each of the bank 
> accounts, cash-in-wallet, and the credit card.

Well, I imagine the idea behind the NAHSA was to try and streamline at least 
the creation of basic account hierarchies; shunting this aspect off to this 
ANBA then puts most users into the bidn of having to create all their accounts 
manually. If you take out the “New Book Options” step (and optionally the 
"Choose Currency” step as well) in the existing NAHSA, well, then, you’re 
giving users a means to create all those accounts automatically—without 
burdening them with these Advanced settings. Or, as Graham suggests, have the 
Advanced options be a secondary popup from the main assistant.

I guess in the meantime, I will attempt to write generic help text that will 
point out to the user that they can defer decisions on these settings, and 
cross reference them to (as-yet-unwritten) sections in the new Configuring 
GnuCash chapter.

> 
> Regards,
> John Ralls
> 

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

Re: [GNC-dev] New Account Hierarchy Setup Assistant Questions

[David T. via gnucash-devel]

Hello,

I’d like to start by noting that this assistant is possibly one of the very 
first things a new user will encounter when they start GnuCash for the very 
first time, and it is this user upon which I am most focused.

> On Sep 12, 2018, at 3:31 PM, Frank H. Ellenberger 
>  wrote:
> 
> Am 12.09.2018 um 17:52 schrieb David T. via gnucash-devel:
>> I understand this and agree. I fully expect that these options will be 
>> described within the Guide; my point is that the NAHS assistant presents 
>> options to new users that they are unlikely to comprehend and do not 
>> actually need to decide when they create a new account hierarchy. 
>> Presumably, experienced users will know where to access the settings that 
>> they can change after an initial hierarchy has been created.
> 
> While doing debugging it is often required to create example books and
> it is important to get reminded of all potential book options. So I am
> strictly against removing here something. IMHO every assistant crippling
> options is incomplete and often distracting users.

So, what you’re saying is that ALL the new users of GnuCash have to figure out 
these settings so that YOU are reminded of the multitude of options available 
on creation of a new file. I don’t think that’s how it should go.

> 
> But perhaps you could do some anaytics:
> Which fields are required, suggested, advanced, special*;
> for all-users or business-only?

My original email noted that this ENTIRE screen is advanced information that a 
new user doesn’t need to know in order to create a new book. I know this 
because I can simply click “Next” on the assistant (without touching ANY of the 
settings on ANY of the FOUR sub-screens embedded in this step), and the 
assistant will create a new file perfectly fine. In another message on this 
thread, Adrien noted specific examples in the recent past where these settings 
have led to (real) user frustration. ISTM that deferring decisions about these 
settings won’t hurt a new user trying to get started with GnuCash.

Taking this a little further, I will note that two of these settings *cannot* 
be set in the NAHS assistant: it is an impossibility for a user to set either 
the Customer or Vendor Tax Table options from the NAHS, given that there are no 
tax tables in the file from which to select.

> Then create a suggestion for improving by reordering and grouping. Add
> an intro text per group and review the current tooltips and default values.

I would rather have these settings removed from the assistant altogether. That 
was (and remains) my suggestion. Advanced users can learn to use the settings 
in Preferences and Properties.

> 
> Are settings irreversible after entering data? Theń they need a warning.
> 

Which I have raised elsewhere. The place to raise the alert isn’t in this 
assistant. Adrien’s point regarding allowing users to change settings that will 
mess up their data files raises the bigger question about why there are such 
options in the GnuCash ecosystem in the first place. Perhaps these should be 
considered bugs in need of fixing, rather than requiring extensive 
documentation. 

> * IMHO special options are at least
> in book options: Use Split Action Field for Number. Traditionally
> Transactions are numbered, but some user wish to number splits instead.

Perhaps this is a reflection of the jurisdiction in which you live, but most 
users in the US setting up GnuCash for personal use will NOT be concerned with 
numbering their transactions or their splits. To be honest, given that the 
definition of “split” is rather specific to GnuCash (based on discussions over 
terminology I’ve seen in the past on the lists), I have a difficult time 
believing that a new user is going to know the difference between numbering 
transactions versus numbering (the GnuCash concept of) splits. 

> 
> in Preferences->Accounts: Reverse Balance Accounts: The traditional
> selection is "Credit Accounts", but some users wish a different view.

I don’t understand why you bring this up here; it’s not on the NAHS assistant.

> 
> For this special options the current tooltips do not give enough
> information.
> 
> This changes should then go into the assistent.

I am trying to get the assistant to be more focused on getting a new user 
started with a set of books; adding even more detaiil to it goes the opposite 
direction.

> 
> Regards
> Frank
> 


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

Re: [GNC-dev] New Account Hierarchy Setup Assistant Questions

[David T. via gnucash-devel]

> On Sep 12, 2018, at 11:19 AM, Geert Janssens  
> wrote:
> 
> Op woensdag 12 september 2018 16:38:42 CEST schreef David T. via gnucash-
> devel:
>> Hello,
>> 
>> As I begin the process of migrating text from the Help to the Guide (cf. Bug
>> 796855), I am working on the Help information regarding the New Account
>> Hierarchy Setup (NAHS) assistant, and I have a couple of questions about
>> the second screen of the assistant, the “New Book Options” screen.
>> 
>> First off, while I respect the intent to allow users the option to set these
>> preferences from the creation of their file, I wonder whether this is
>> misguided. To wit: all of these options are quite technical in nature, and
>> all of them can be set at a later point by opening the appropriate
>> preferences. Adding these options here adds complexity that can easily be
>> deferred to a later point. While it is true that this assistant runs
>> whenever a user chooses File->New (meaning that an experienced user might
>> wish to add these settings from the assistant), I am willing to hazard a
>> guess that most users will invoke this assistant *only* when they first
>> start using GnuCash, and *only* when their heads are already swimming with
>> the overwhelming experience that is GnuCash. Asking a new user to choose
>> whether to use Trading Accounts or to Use Split Action Field for Number is
>> IMHO pointless. They aren’t going to be able to make an informed decision.
>> 
>> I’ll note that this becomes an obvious issue when I attempt to write
>> the help section for the screen. I am left either with writing a huge
>> explanatory section on the details of each of these settings, which
>> detracts from the flow of the NAHS narrative, or with adding a generic note
>> that advises users to accept the defaults and read about the details in
>> other sections of the Guide.
> 
> So now the challenge of writing documentation will be shaping the functioning 
> of the application ? ;p
> 
> More seriously, your point is well taken, though I don't know the best answer.

I am sure you understand that my observations are meant as supporting elements 
for my proposal, not edicts from the docs writer.

> 
>> 
>> So, for the new user, the only real effect of this screen is to introduce
>> confusion and questions. Can it be removed from the assistant?
>> 
>> Related to this screen, my second question has to do with the “Use Trading
>> Accounts” setting. Can it be turned off once it has been enabled in a given
>> GnuCash file?
>> 
>> ISTR that this option is a one-way street—i.e., that, once turned on, it can
>> not be turned off again. Is this still the case? If it is still true, then
>> I would strongly suggest that this option shouldn’t be placed on the NAHS
>> Assistant, since a new user won’t be aware of this.
> 
> My memory is failing me. I remember these options got introduced in the new 
> book dialog for a specific reason. Something had to be decided at the start 
> of 
> a new book. But for the life of me I don't remember what that was. Perhaps it 
> was exactly the trading accounts ?

But the question remains: does a new user (who won’t know what this means or 
signifies) need to make this decision at this point? 

Or, to put it another way, if a user accepts the default setting, will they be 
unable to change it at a later point*? 

> 
> As for num-for-action I think you can indeed switch this on an existing book. 
> However I'm not sure a user would want to do this: if the num field had been 
> used for transaction numbers (for example copied from a bank statement) 
> switching the number would suddenly move all of these to the split action 
> field and hide them from the register. This is usually not what the user 
> wants. So again this is an option that's better defined upfront to save the 
> user lots of corrections afterwards.

But the same question holds: does a new user need to make this decision at this 
point? 

Again, if a user accepts the default setting, will they be unable to change it 
at a later point*? 

* Understand that the issue of _changing these settings back and forth_ should 
be discussed in the Guide at the spot where they are discussed in full—that is, 
in the proposed “Configuring GnuCash” chapter. 

David

> 
> Geert
> 
> 

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

Re: [GNC-dev] New Account Hierarchy Setup Assistant Questions

[David T. via gnucash-devel]

Mechtilde,

> On Sep 12, 2018, at 11:21 AM, Mechtilde  wrote:
> 
> Hello David T.
> 
> Am 12.09.18 um 16:38 schrieb David T. via gnucash-devel:
>> Hello,
>> 
>> As I begin the process of migrating text from the Help to the Guide (cf. Bug 
>> 796855), I am working on the Help information regarding the New Account 
>> Hierarchy Setup (NAHS) assistant, and I have a couple of questions about the 
>> second screen of the assistant, the “New Book Options” screen. 
>> 
>> First off, while I respect the intent to allow users the option to set these 
>> preferences from the creation of their file, I wonder whether this is 
>> misguided. To wit: all of these options are quite technical in nature, and 
>> all of them can be set at a later point by opening the appropriate 
>> preferences. Adding these options here adds complexity that can easily be 
>> deferred to a later point. While it is true that this assistant runs 
>> whenever a user chooses File->New (meaning that an experienced user might 
>> wish to add these settings from the assistant), I am willing to hazard a 
>> guess that most users will invoke this assistant *only* when they first 
>> start using GnuCash, and *only* when their heads are already swimming with 
>> the overwhelming experience that is GnuCash. Asking a new user to choose 
>> whether to use Trading Accounts or to Use Split Action Field for Number is 
>> IMHO pointless. They aren’t going to be able to make an informed decision. 
> 
> There are not only people starting with GnuCash for privat use with less
> experience of accounting. There are also people who want to use GnuCAsh
> for Business. They want to have the inforamtion for doing complex
> accounting in GnuCash.

> 
> This Tutorial and Concept is for that business people too.

I understand this and agree. I fully expect that these options will be 
described within the Guide; my point is that the NAHS assistant presents 
options to new users that they are unlikely to comprehend and do not actually 
need to decide when they create a new account hierarchy. Presumably, 
experienced users will know where to access the settings that they can change 
after an initial hierarchy has been created.

> 
>> 
>> I’ll note that this becomes an obvious issue when I attempt to write 
>> the help section for the screen. I am left either with writing a huge 
>> explanatory section on the details of each of these settings, which detracts 
>> from the flow of the NAHS narrative, or with adding a generic note that 
>> advises users to accept the defaults and read about the details in other 
>> sections of the Guide.
>> 
>> So, for the new user, the only real effect of this screen is to introduce 
>> confusion and questions. Can it be removed from the assistant?
>> 
>> Related to this screen, my second question has to do with the “Use Trading 
>> Accounts” setting. Can it be turned off once it has been enabled in a given 
>> GnuCash file?
>> 
>> ISTR that this option is a one-way street—i.e., that, once turned on, it can 
>> not be turned off again. Is this still the case? If it is still true, then I 
>> would strongly suggest that this option shouldn’t be placed on the NAHS 
>> Assistant, since a new user won’t be aware of this.
> 
> I myself got starting with Gnucash to map a complex buaisness accounting
> to GnuCash. That was also the starting point to do the translation to
> German, esp. of the Business part.
> 
> IMO it is neccessary to have MORE information in the Documentation NOT LESS.

We are in total agreement here; my email isn’t about removing information from 
the documentation, but rather how the NAHS is structured. 

Since you have been active in translation of the documentation into German, I 
should alert you that I am process of a significant reorganization of the 
documentation, so as to put more of the analytical content into the Guide. The 
current editorial process is focused on moving most of Chapter 3 of the Help 
into chapter 2 of the Guide, and while I am mostly just moving the text from 
one file to the other, there are editorial changes that are being made on both 
sides to adjust to the new status. I sincerely hope that my edits will be 
clear, and that past translators will be able to migrate the translations 
without too much trouble.

David

> 
> -- 
> Mechtilde Stehmann
> ## Apache OpenOffice
> ## Freie Office Suite für Linux, MacOSX, Windows
> ## Debian Developer
> ## Loook, calender-exchange-provider, libreoffice-canzeley-client
> ## PGP encryption welcome
> ## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F
> 
> ___
> 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] New Account Hierarchy Setup Assistant Questions

[David T. via gnucash-devel]

Hello,

As I begin the process of migrating text from the Help to the Guide (cf. Bug 
796855), I am working on the Help information regarding the New Account 
Hierarchy Setup (NAHS) assistant, and I have a couple of questions about the 
second screen of the assistant, the “New Book Options” screen. 

First off, while I respect the intent to allow users the option to set these 
preferences from the creation of their file, I wonder whether this is 
misguided. To wit: all of these options are quite technical in nature, and all 
of them can be set at a later point by opening the appropriate preferences. 
Adding these options here adds complexity that can easily be deferred to a 
later point. While it is true that this assistant runs whenever a user chooses 
File->New (meaning that an experienced user might wish to add these settings 
from the assistant), I am willing to hazard a guess that most users will invoke 
this assistant *only* when they first start using GnuCash, and *only* when 
their heads are already swimming with the overwhelming experience that is 
GnuCash. Asking a new user to choose whether to use Trading Accounts or to Use 
Split Action Field for Number is IMHO pointless. They aren’t going to be able 
to make an informed decision. 

I’ll note that this becomes an obvious issue when I attempt to write the 
help section for the screen. I am left either with writing a huge explanatory 
section on the details of each of these settings, which detracts from the flow 
of the NAHS narrative, or with adding a generic note that advises users to 
accept the defaults and read about the details in other sections of the 
Guide.

So, for the new user, the only real effect of this screen is to introduce 
confusion and questions. Can it be removed from the assistant?

Related to this screen, my second question has to do with the “Use Trading 
Accounts” setting. Can it be turned off once it has been enabled in a given 
GnuCash file?

ISTR that this option is a one-way street—i.e., that, once turned on, it can 
not be turned off again. Is this still the case? If it is still true, then I 
would strongly suggest that this option shouldn’t be placed on the NAHS 
Assistant, since a new user won’t be aware of this.

David


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

Re: [GNC-dev] Long Term Documentation Directions

[David T. via gnucash-devel]

Adrien,

> On Sep 11, 2018, at 1:09 PM, Adrien Monteleone 
>  wrote:
> 
> 
> 
>> On Sep 11, 2018, at 8:13 AM, David T. via gnucash-devel 
>>  wrote:
>> 
>> Hello,
>> 
>> 
>> I envision that the context help would consist of short _functional_ 
>> descriptions of one or two sentences. I believe that the rate of change in 
>> the functions of the UI elements is exceedingly small. In my decade-plus 
>> time using GnuCash, I haven’t seen many changes to the buttons or screens. 
>> Accounting hasn’t suddenly come up with an entirely new set of functions. 
>> This leads me to the conclusion that functional descriptions of those 
>> buttons and screens won’t need to change either. If the functional aspects 
>> of the interface don’t change, then the context help doesn’t need to change, 
>> either. If the content isn’t changing, then the authorial skill of 
>> developers is beside the point. 
>> 
>> In other words, unless there is a change in function, there is no need to 
>> change the functional description. It seems to me that putting text that 
>> doesn’t change into code is essentially a one-time process. Not necessarily 
>> easy, but once completed, not particularly obtrusive. Putting the functional 
>> description into code has the added benefit, perhaps, of alerting developers 
>> to the fact that if they change a feature, the description (right there in 
>> the code) needs an update as well.
> 
> While the principles might not change, or even the name/label of certain 
> buttons, the UI layout (where those buttons are, the fact that they are 
> buttons instead of menu entries, etc.) will very likely change as the Gnome 
> HIG is more faithfully implemented. But those code changes shouldn’t affect 
> anything generally in the Guide, and should auto update the context help if 
> it is drawn from the code itself. If not, then consider that attempts to 
> corral GnuCash within the confines of the Gnome HIG, will produce such 
> changes you’re thinking won’t happen.
> 

We are in general agreement here. My point was that any context help text, 
being based on the *actual function* of a given widget (and regardless of the 
form or broader context of that widget) is unlikely to change. Geert was 
concerned that embedding help text in code would shield that text from the 
editorial expertise of members of the Documentation Team. I was trying to point 
out that these texts, once written, are unlikely to need rewriting unless the 
actual functions change. 

I’ll note here that you seem to have the documentation model backwards, insofar 
as you suggest that interface changes wouldn’t affect the Guide. I believe that 
such changes would not affect the Help, whereas changes in the UI and the form 
and location of a given widget would definitely be reflected in the Guide, 
since that is where the descriptive explanation of GnuCash and its functions 
will reside. The Help would only consist of context help containing a sentence 
or two about that widget.

David


> Regards,
> Adrien
> ___
> 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] Finding wiki orphans

[David T. via gnucash-devel]

Perhaps

• Bazaar
• BreezyBadgerInstallation
• Main Page

could be deleted by someone with those tights on the wiki?

David T.

> On Sep 11, 2018, at 2:46 AM, Frank H. Ellenberger 
>  wrote:
> 
> Am 11.09.2018 um 06:03 schrieb David Cousens:
>> One other problem with a WIki for a maintenance
>> point of view is thatt a link to a page can be deleted and the page becomes
>> an orphan with no way to logically access it. A search negine will sometimes
>> find orphan pages in a wiki.
> 
> Not really, there is a special page:
> https://wiki.gnucash.org/wiki/Special:LonelyPages
> 
> And if a page has the  magic word __NOINDEX__, no search engine should
> find it.
> 
> HTH
> Frank
> 
> ___
> 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] Long Term Documentation Directions

[David T. via gnucash-devel]

Hello,

> On Sep 11, 2018, at 4:45 AM, Geert Janssens  
> wrote:
> 
> Op dinsdag 11 september 2018 09:15:43 CEST schreef David Cousens:
>> David,
>> 
>> Just some comments on a couple of other points:
>> 
>> Embedding even the context help in the program code is not a really good
>> idea. It means that text cannot be edited /altered easily separately from
>> the program and without rebuilding the program. 
> 
> You raise a good point here. Aside from the building restriction (which we 
> now 
> also have for source message translations), it would probably limit the 
> potential help writing contributors to only those people capable of parsing 
> the source code. In practice there would be few outside of the developers 
> themselves. And those are known not to be the best documentation writers :(
> 

Geert, you note that the developers are not proficient documentors, and I agree 
with you. You also say that you’d prefer the broader documentation team (such 
as it is) to be able to edit this context help.

One major reason for my suggesting that context help be embedded in code is a 
direct response to the current situation, where well-intentioned documentation 
contributors have placed duplicative information in *different places.* 
Deciding when a “small piece of prose” (as you put it, Geert) crosses that 
magical threshold from context help into concept guide is precisely what has 
led this documentation into the mess it’s in. Although it’s perhaps heresy, I 
think that limiting the ability of the Documentation Team to make contributions 
to the Help might not be a bad idea. Push everyone to the Guide, instead.

I envision that the context help would consist of short _functional_ 
descriptions of one or two sentences. I believe that the rate of change in the 
functions of the UI elements is exceedingly small. In my decade-plus time using 
GnuCash, I haven’t seen many changes to the buttons or screens. Accounting 
hasn’t suddenly come up with an entirely new set of functions. This leads me to 
the conclusion that functional descriptions of those buttons and screens won’t 
need to change either. If the functional aspects of the interface don’t change, 
then the context help doesn’t need to change, either. If the content isn’t 
changing, then the authorial skill of developers is beside the point. 

In other words, unless there is a change in function, there is no need to 
change the functional description. It seems to me that putting text that 
doesn’t change into code is essentially a one-time process. Not necessarily 
easy, but once completed, not particularly obtrusive. Putting the functional 
description into code has the added benefit, perhaps, of alerting developers to 
the fact that if they change a feature, the description (right there in the 
code) needs an update as well.

> So I vote for keeping all help consisting of more than a single sentence in a 
> separate document. So a short tooltip or a hint in an empty text entry go 
> into 
> the code (also for practical reasons), but a small piece of prose explaining 
> how a certain dialog window works should go in a document that is more easily 
> edited by documentation writers.
> 
> What we may be able to do is write some scripts that would automatically 
> extract a list of all user interface elements from the source code and 
> compose 
> a skeleton document from this. Then with some clever msgmerge like magic 
> merge 
> existing help strings from a previous version of this document. That would at 
> least make sure the list of interface elements can be kept up to date 
> programmatically so no one should scan the sources manually for changes.
> 

Keeping in mind that the Help is meant to be *contextual*—that is, linked 
directly to the screens and widgets a user encounters in GnuCash—perhaps the 
Help document should be more strictly structured to reflect this. Set it up as 
a table, with a column that provides the link to the interface, a column for 
the (brief) help text, and a column to link to the guide. This sort of 
structure exists already in some places of the Help; converting the entire 
document to this format would make clear to future writers and users that the 
Help is primarily meant for access from the application. People looking for 
more explanation would be directed to the Concept Guide. In an absolute sense, 
there is no real need for chapter headings, screen titles, figures, etc., since 
user access to this document would strictly be from the application itself. You 
could, I guess, go the other direction, and create separate files for each 
individual entry. To me, madness lies down that alley.

> 
>> My understanding is that it
>> can be done from a docbook that just has the links to a section which is
>> displayed in response to a help button being pressed or  something like a
>> Shift-F1 key combination while the focus is on the button/checkbox/etc that
>> you want help on. It could be a separate window from the main 

Re: [GNC-dev] Long Term Documentation Directions

[David T. via gnucash-devel]

OK. In reply to my own message, I have paged through the Help and compared it 
to the Guide. I compiled a mapping framework from Help to the Guide, and found 
that this might not be as huge an undertaking as I initially thought.

Here are my thoughts:

1. Introduction to GnuCash  :   
Delete. The single paragraph enclosed therein is covered elsewhere.
2. Using This Document & Getting Help   :   Delete. 
This information is in the Guide.
3. Getting Started  
:   Merge into Guide 2.3 The Basics. Interface
4. GnuCash Windows & Menus Options Overview :   Merge into 
Guide 2.3 The Basics. Interface as appropriate. Retain Menus and Context Help.
5. Setting Up, Editing & Working with Accounts  :   Merge into 
Guide 3 Accounts as appropriate, except 5.4.1.1 (Online Price Retrieval) into 
Guide 9.6 Investing
6. Common Transaction Operations:   Merge 
into Guide 4 Transactions. I’ll note that the Help is more detailed than the 
Guide in this area
7. Business Features:   
Largely duplicate copy of chapter 13. Business Features.
8. Tools & Assistants   :   
Merge into various chapters based on subject—e.g., investment-oriented 
assistants get put into Guide 9 Investments.
9. Reports And Charts   :   
Delete. Guide 10 Reports covers in more detail
10. Customizing GnuCash :   Add as 
needed to new Customization chapter following Guide chapter 4.
A. GnuCash Tips and tidbits :   
Delete/Move to wiki (currently consists of Finance::Quote data which is, as we 
all know, a fast-moving target)
B. GNU Free Documentation License

As for the Guide, there are a number of bugs outstanding that point to a future 
direction for the structure there, most specifically Bug 687820, so I won’t 
address those here, except to point out that the various appendices included 
there should be moved to the wiki and maintained there.

Cheers,
David

> On Sep 10, 2018, at 11:26 AM, David T. via gnucash-devel 
>  wrote:
> 
> Dear All,
> 
> I reply to this message (even though it lacks the previous discussions for 
> context), as it is the latest in the thread. I will, however, try to take on 
> some of the issues that have gotten raised. I apologize for the length and 
> density of the reply.
> 
> *** My Documentation Manifesto ***
> 1. The Concept Guide should be the primary informational document. 
> 2. The Help should provide specific information on the functions that a given 
> on screen element serves—i.e., Contextual Help.
> 3. The wiki should give technical information and information that is only 
> applicable to specific user situations.
> 

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

Re: [GNC-dev] Long Term Documentation Directions

[David T. via gnucash-devel]

Dear All,

I reply to this message (even though it lacks the previous discussions for 
context), as it is the latest in the thread. I will, however, try to take on 
some of the issues that have gotten raised. I apologize for the length and 
density of the reply.

With regard to translations, I am not informed enough of any of the issues 
involved to offer any insight. I defer to those who can speak more than one 
language using complete sentences (rather than a combination of misconjugated 
verbs, incorrect formality modes, and gestures not intended to be rude in any 
way). ;)

With regard to the idea of using multiple back end XML files, Geert is right 
that I was not talking about removing multiple back end source files (although 
I will note that having data fragmented in the sources seems to lead to 
duplication of content and effort, as different writers conceptualize the 
proper location for a given piece of information in different ways). My goal is 
to unify the narrative help into one sequence and reduce duplication and 
overlap. Bringing all the source XML files into one Frankenstein sequence might 
be a way to see the future pain, but I imagine that any such amalgamation would 
only exist for the editorial process; any final product would in all likelihood 
bear only limited similarity to this documentation monster.

As might be expected from my sending in a generic bombshell, there has been a 
lively discussion touching on a number of different aspects of the 
documentation.

At the core, my proposal has the goal of making clearer the primary purposes of 
the different types of documentation, and working to ensure that information 
gets placed in the proper place, and only the proper place. 

The article at 
https://pronovix.com/blog/overview-context-sensitive-and-embedded-help-formats 

 focuses on web modalities, but the background analysis of user 
assistance-seeking behavior is intriguing.

Currently, there is a lack of clarity in the GnuCash community on the roles of 
the different documentation, and it crops up repeatedly. Questions of 
appropriate content for the wiki, of whether information belongs in the Help or 
the Guide, etc. are all indicative of this underlying problem.

*** My Documentation Manifesto ***
1. The Concept Guide should be the primary informational document. 
2. The Help should provide specific information on the functions that a given 
on screen element serves—i.e., Contextual Help.
3. The wiki should give technical information and information that is only 
applicable to specific user situations.

With these three statements, a number of results follow. 

First, the Guide would contain most of the narrative, explanatory text covering 
how GnuCash works, and how to manage most common accounting situations. Next, 
the Help would be stripped back substantially, with most of the narrative 
content that currently resides in the Help migrated to the Guide. Third, the 
Tutorial aspects of the documentation would reside on the wiki. More on the 
Tutorial issue later.

My goal is to eliminate the situation where we document Online Banking [or 
Reconciliation, or Account Types, or Loans, or Investments, or… you get the 
idea] in every spot in the GnuCash documentation, and, just for fun, have each 
one differ just a little bit from the others, so that the user can’t be sure 
which source is the closest to accurate. 

With regard to the Help, I wonder whether there is some way to use the code 
itself to generate context help programmatically, rather than have it be a 
human-edited, git-managed document. As it stands right now, the Help kind of 
looks like someone started out that way with lists of menus and options, but 
then someone else came along and started writing text to go with those lists of 
menus. And now we have something in between. Having a 
programmatically-generated Context Help system would remove this document from 
the concerns of documenters, and once established, would only need modification 
if the interface were changed. I do not know how such a mechanism would work, 
but I imagine that it would require additional work in code to ensure that the 
proper links are embedded. I recognize that such an endeavor would be 
substantial for an application as complex as GnuCash, but I believe the payoff 
would be major.

Returning to the Tutorial issue: Geert asked me whether it was the style of the 
writing, or the content that bothered me. I think that the style was what first 
bothered me there, but as I considered it further, I felt that there were 
deeper issues embedded. Most fundamentally, I think that as currently written, 
some information about how GnuCash works is written in the *Guide* parts of the 
T, while other aspects are embedded in the *Tutorial* parts of the T 
See, for example, section 3.3 of the Guide, which includes account setup 
information that is largely 

[GNC-dev] Long Term Documentation Directions

[David T. via gnucash-devel]

Hello,

As I have noted in another thread recently, I am finding the process of 
updating the various documentation pieces extremely challenging—due in large 
part to the fragmented nature of this documentation. Different contributors 
have placed information on similar topics in any of a number of official 
locations in the GnuCash documentation realm, making the update process a 
circular nightmare. 

This leads to variation in content, approach, and likelihood that a user is 
going to locate the full information on a given subject.

Rather than tackle each editorial task as if somehow this time it will be 
different, I would like to ask whether there would be support for a complete 
rewrite of the documentation. My idea would be to somehow merge all the content 
from the Guide and the Help into one huge file, and then establish a single 
Grand Unifying Manual that would provide users with a single source for help. 
Contextual help would be stripped back to only naming on screen functions, with 
references back to the GUM in all cases. The wiki would remain primarily for 
specific use cases and temporary issues. The FAQ would also point to the docs 
in most cases. Optionally, I would strip out the “Tutorial” aspect of the 
Tutorial and Concept Guide, as I think a solid Manual would obviate the need 
for this aspect (that, and the fact that most of the Tutorail sections are 
written in a “Hi, how are ya” folksie tone that I find inappropriate in formal 
documentation).

I do not make this suggestion lightly—I know the complexity and difficulty of 
such an endeavor. However, I increasingly find that the content of the Help and 
Guide are so inextricably enmeshed that any attempt to clean up one will have 
extreme impact on the other—and attempting to shepherd these changes through 
piecemeal is cumbersome at best. 

Currently, the Help occupies 230 PDF pages, while the Guide weighs in at 287. 
That’s over 500 pages of information—a good portion of which is duplicated 
across the docs. Any such rewrite would entail a HUGE effort, which is why I 
write this email: there is no way anyone would undertake this without knowing 
in advance whether the community would accept such a change at the outset.

Comments are welcome.

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

Re: [GNC-dev] Documentation--What else?

[David T. via gnucash-devel]

Thanks John for the confirmation on my efforts to realign my repo.

David

> On Sep 7, 2018, at 7:55 PM, John Ralls  wrote:
> 
> David,
> 
> I checked your Github repository and it looks good.
> 
> I agree with Geert, your plan for Online Quotes seems sound.
> 
> I haven’t reviewed the wiki Online Quotes page; if there’s material there 
> about the F::Q API, you may safely remove it because that’s duplicated in the 
> F::Q documentation. Any other technical information should stay or at least 
> be carefully reviewed before removal. 
> 
> Regards,
> John Ralls
> 
>> On Sep 7, 2018, at 1:24 PM, David T. via gnucash-devel 
>>  wrote:
>> 
>> Ha. That means I have to figure out how to get my local repository working 
>> again….
>> 
>> [some time later]
>> 
>> OK, so I googled “force upstream into fork” and found some resources that 
>> seem to have fixed things for me. The commands I issued were:
>> 
>> DHT-Retina:gnucash-docs david$ git fetch upstream
>> DHT-Retina:gnucash-docs david$ git reset --hard upstream/maint
>> HEAD is now at ecd868b Fix xmllint error
>> DHT-Retina:gnucash-docs david$ git push origin maint --force
>> Counting objects: 99, done.
>> Delta compression using up to 8 threads.
>> Compressing objects: 100% (99/99), done.
>> Writing objects: 100% (99/99), 95.66 KiB | 0 bytes/s, done.
>> Total 99 (delta 69), reused 0 (delta 0)
>> remote: Resolving deltas: 100% (69/69), completed with 15 local objects.
>> To https://github.com/sunfish62/gnucash-docs
>> + 4de1289...ecd868b maint -> maint (forced update)
>> 
>> If I understand it correctly, the first command brings in upstream 
>> (github.com/gnucash/gnucash-docs <http://github.com/gnucash/gnucash-docs>), 
>> the second force-resets my local (computer) repo to match upstream/maint, 
>> and the last pushes my (now-updated) local repo to my github fork. Do I have 
>> this right?
>> 
>> This appears to have done the trick; I see Geert’s final xmllint changes to 
>> ch_basics.xml on my local system, and github says that my fork is even with 
>> Gnucash-docs.
>> 
>> Is there another way that I can verify this? After all, I have remarkably 
>> bad luck when it comes to git…
>> 
>> David
>> 
>> 
>>> On Sep 7, 2018, at 12:54 PM, Geert Janssens  
>>> wrote:
>>> 
>>> That reads like a good plan.
>>> 
>>> I'm all for deduplication. I agree with your assessment of what help and 
>>> guide 
>>> should be. And that the guide should be the general documentation with 
>>> troubleshooting explained in the wiki. Troubleshooting tends to change more 
>>> quickly than base documentation.
>>> 
>>> I also think it's a good idea to keep an entry point on Online Quotes on 
>>> the 
>>> FAQ.
>>> 
>>> So a +1 on all accounts.
>>> 
>>> Geert
>>> 
>>> Op vrijdag 7 september 2018 17:47:55 CEST schreef David T. via 
>>> gnucash-devel:
>>>> Hello,
>>>> 
>>>> I am going to raise—once again—the spectre of the conflicting and
>>>> duplicative information in the various documentation packages in relation
>>>> to online quote retrieval.
>>>> 
>>>> As one of the documentarians in the broader community, I episodically
>>>> attempt to make sense of, clean up, and (hopefully) improve the various
>>>> sets of documentation. Currently, I am poking primarily at the wiki, and I
>>>> find myself in a long series of circular tangles of information that render
>>>> a solution daunting (to say the least).
>>>> 
>>>> There are two entries on Online Quotes in the FAQ; these refer to each 
>>>> other
>>>> and to a separate page on the wiki. The separate wiki page is a mess of
>>>> highly technical information that has nothing to do with the FAQ questions,
>>>> and offers no help in that regard (making the references from the FAQ less
>>>> than helpful). Furthermore, both the Guide and the Help have separate,
>>>> essentially complete descriptions of setting up online quotes.
>>>> 
>>>> Any rightful attempt at ensuring that online quoting is properly and
>>>> carefully documented requires that *every* one of these sources be updated
>>>> and coordinated with the others. This turns out to be exceedingly
>>>> challenging, especially given that it’s not entirely clear which source
>>>> should contain which data. To me (admitted

Re: [GNC-dev] Documentation--What else?

[David T. via gnucash-devel]

Ha. That means I have to figure out how to get my local repository working 
again….

[some time later]

OK, so I googled “force upstream into fork” and found some resources that seem 
to have fixed things for me. The commands I issued were:

DHT-Retina:gnucash-docs david$ git fetch upstream
DHT-Retina:gnucash-docs david$ git reset --hard upstream/maint
HEAD is now at ecd868b Fix xmllint error
DHT-Retina:gnucash-docs david$ git push origin maint --force
Counting objects: 99, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (99/99), done.
Writing objects: 100% (99/99), 95.66 KiB | 0 bytes/s, done.
Total 99 (delta 69), reused 0 (delta 0)
remote: Resolving deltas: 100% (69/69), completed with 15 local objects.
To https://github.com/sunfish62/gnucash-docs
 + 4de1289...ecd868b maint -> maint (forced update)

If I understand it correctly, the first command brings in upstream 
(github.com/gnucash/gnucash-docs <http://github.com/gnucash/gnucash-docs>), the 
second force-resets my local (computer) repo to match upstream/maint, and the 
last pushes my (now-updated) local repo to my github fork. Do I have this right?

This appears to have done the trick; I see Geert’s final xmllint changes to 
ch_basics.xml on my local system, and github says that my fork is even with 
Gnucash-docs.

Is there another way that I can verify this? After all, I have remarkably bad 
luck when it comes to git…

David


> On Sep 7, 2018, at 12:54 PM, Geert Janssens  
> wrote:
> 
> That reads like a good plan.
> 
> I'm all for deduplication. I agree with your assessment of what help and 
> guide 
> should be. And that the guide should be the general documentation with 
> troubleshooting explained in the wiki. Troubleshooting tends to change more 
> quickly than base documentation.
> 
> I also think it's a good idea to keep an entry point on Online Quotes on the 
> FAQ.
> 
> So a +1 on all accounts.
> 
> Geert
> 
> Op vrijdag 7 september 2018 17:47:55 CEST schreef David T. via gnucash-devel:
>> Hello,
>> 
>> I am going to raise—once again—the spectre of the conflicting and
>> duplicative information in the various documentation packages in relation
>> to online quote retrieval.
>> 
>> As one of the documentarians in the broader community, I episodically
>> attempt to make sense of, clean up, and (hopefully) improve the various
>> sets of documentation. Currently, I am poking primarily at the wiki, and I
>> find myself in a long series of circular tangles of information that render
>> a solution daunting (to say the least).
>> 
>> There are two entries on Online Quotes in the FAQ; these refer to each other
>> and to a separate page on the wiki. The separate wiki page is a mess of
>> highly technical information that has nothing to do with the FAQ questions,
>> and offers no help in that regard (making the references from the FAQ less
>> than helpful). Furthermore, both the Guide and the Help have separate,
>> essentially complete descriptions of setting up online quotes.
>> 
>> Any rightful attempt at ensuring that online quoting is properly and
>> carefully documented requires that *every* one of these sources be updated
>> and coordinated with the others. This turns out to be exceedingly
>> challenging, especially given that it’s not entirely clear which source
>> should contain which data. To me (admittedly a “Concepts” kind of guy), the
>> fullest description of setup and management should go into the Guide at
>> section 9.6. However, the Help at section 5.4.1.1 includes another
>> essentially full description of setup and management; presumably this entry
>> should focus on the “This button does This action” kind of information
>> (since that is what I understand is supposed to be the primary purpose of
>> the Help). And where, in all this, do the different pieces on the wiki fit
>> in?
>> 
>> Attempting to shepherd any rationalization of these resources through the
>> process is painful and time-consuming.
>> 
>> I will note that the challenge described here repeats itself time and time
>> again, in all manner of subject areas in the documentation, leaving the
>> documentation in a disorganized state.
>> 
>> Here is my proposed action plan:
>> 
>> 1) Edit the Guide to include background, setup and management of online
>> quoting. This section will explain F::Q, its relation to GnuCash,
>> installation, and maintenance. 2) Edit the Help to remove information
>> covered in the Guide, and add references to the Guide. Determining which
>> pieces are context versus background will be difficult, BTW. 3) Replace FAQ
>> questions with references to “Online Quotes” pages and the 

[GNC-dev] Documentation--What else?

[David T. via gnucash-devel]

Hello,

I am going to raise—once again—the spectre of the conflicting and duplicative 
information in the various documentation packages in relation to online quote 
retrieval.

As one of the documentarians in the broader community, I episodically attempt 
to make sense of, clean up, and (hopefully) improve the various sets of 
documentation. Currently, I am poking primarily at the wiki, and I find myself 
in a long series of circular tangles of information that render a solution 
daunting (to say the least).

There are two entries on Online Quotes in the FAQ; these refer to each other 
and to a separate page on the wiki. The separate wiki page is a mess of highly 
technical information that has nothing to do with the FAQ questions, and offers 
no help in that regard (making the references from the FAQ less than helpful). 
Furthermore, both the Guide and the Help have separate, essentially complete 
descriptions of setting up online quotes.

Any rightful attempt at ensuring that online quoting is properly and carefully 
documented requires that *every* one of these sources be updated and 
coordinated with the others. This turns out to be exceedingly challenging, 
especially given that it’s not entirely clear which source should contain which 
data. To me (admittedly a “Concepts” kind of guy), the fullest description of 
setup and management should go into the Guide at section 9.6. However, the Help 
at section 5.4.1.1 includes another essentially full description of setup and 
management; presumably this entry should focus on the “This button does This 
action” kind of information (since that is what I understand is supposed to be 
the primary purpose of the Help). And where, in all this, do the different 
pieces on the wiki fit in?

Attempting to shepherd any rationalization of these resources through the 
process is painful and time-consuming.

I will note that the challenge described here repeats itself time and time 
again, in all manner of subject areas in the documentation, leaving the 
documentation in a disorganized state.

Here is my proposed action plan:

1) Edit the Guide to include background, setup and management of online 
quoting. This section will explain F::Q, its relation to GnuCash, installation, 
and maintenance. 
2) Edit the Help to remove information covered in the Guide, and add references 
to the Guide. Determining which pieces are context versus background will be 
difficult, BTW.
3) Replace FAQ questions with references to “Online Quotes” pages and the 
Guide, and move all detail to those locations.
4) Rewrite “Online Quotes” to be geared first to troubleshooting for the end 
user (rather than whatever it currently is).

Unclear to me, however, is the extent to which GnuCash should document 
Finance::Quote and its functionality. Technically, F::Q is an external project, 
and so GnuCash should point to F::Q for detailed help, rather than write and 
provide it. However, it is clear that there is a disconnect between the help 
provided by F::Q, and the technical skill level of many GnuCash users. I’m not 
sure where to draw the line here.

Because of this, I believe it might be best to keep technical aspects of F::Q 
on our wiki page (at “Online Quotes”), since they can change without GnuCash 
control. Changing the wiki to reflect current F::Q behavior is quicker and 
easier than trying to get those changes into the Help or Guide.

Comments and advice are welcome.

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

Re: [GNC-dev] Wiki FAQ Page

[David T. via gnucash-devel]

Frank,

I will begin with noting that I think that it was not entirely clear in my post 
that I was presenting only the top-level headings for the FAQ in this email; I 
was not prepared to re-align every level in the FAQ at this point. 

> On Sep 4, 2018, at 4:02 PM, Frank H. Ellenberger 
>  wrote:
> 
> Hi David,
> 
> at first thanks for starting with this task.
> 
> Am 04.09.2018 um 16:43 schrieb David T. via gnucash-devel:
>> Now, on a meta-level, I think the primary headings here might be better 
>> arranged as follows:
>> 
>> 1. General Questions
> Perhaps the title should be more specific. Abstract

The existing entry is "General Frequently Asked Questions (FAQ) about GnuCash". 
I was merely cleaning up the heading to make it more reasonable. I have no 
problems with a “General Questions” section. Perhaps others have suggestions 
here.

> About the project, how {this page is organized [missing]}, howw to get
> help (and provide required information, and give something back (from
> feedback to patches).

About the project belongs on the website or on the main page, not as an FAQ 
entry. 

How this page is organized *should* be clear from the main headings, which is 
what I am working on rationalizing. 

I duplicated the first FAQ entry "How to Get Help" at the very top of the FAQ, 
to bring greater prominence to this issue. I additionally left this as the 
first entry in the FAQ. Further, there is an entry on the topic on the main 
wiki page. Fourth, there is a “Getting Help" link on the main web page, which 
links to a separate "Getting Help” page on the wiki 
(https://wiki.gnucash.org/wiki/Getting_Help 
<https://wiki.gnucash.org/wiki/Getting_Help>). Honestly, how many more pointers 
to the help do we need?

Noting my comment above about only presenting at the top level in this first 
pass, I note that there are currently 4 second level sections in “General 
Questions,” (“General”, Contributing, Troubleshooting and Improvements, and 
Mailing List Questions) and that one or more of these sections might remain 
going forward. I will note that many of these issues are already incorporated 
into other pages on the wiki—or should be, IMHO—and that as I work through the 
sections, I am predisposed to relying on those pages, rather than a monolithic 
and overly-dense FAQ page to keep track of it all.

For example, the fourth top level section on the Main page of the wiki is 
entirely dedicated to giving back to the project. It would be my preference to 
see the pages and references on the main page serve as the primary source of 
information on these topics, and a single brief entry on the FAQ that points 
the questoner to those pages.

> 
>>  [move “Accounting Questions” to this section]
> Please do not, I see “Accounting Questions” more or less as "Off topic"
> there are spcefic websites which can answer such questions according the
> local law.

…except that a) general accounting questions are exceedingly common on the 
mailing lists, and b) these questions are already on the wiki. In the past, you 
have strongly advocated for including information on the wiki based on these 
two criteria; why change that now?

> 
> For me there is a logical sequence: Install, configure/customize, use.
>> 2. Installation
>> 3. Using GnuCash [moved ahead of cunfiguring]
> No, before you should configure/customize your installation.

This could go either way—but allow me to share my reasoning behind this 
arrangement. For *most* users, the first hurdle they will encounter after 
installation will NOT be configuring and customizing their brand new accounting 
software package; it’s going to be to run the program and try to figure out how 
to do basic things with said program. Questions about how to reconfigure 
GnuCash (which is what most of the entries under Configuring currently are) 
come *after* a user has been using the program for a while. Indeed, some users 
NEVER attempt to load a different font for their GnuCash.

That being said, there are a large number of these questions that by rights 
should be eliminated as duplicates of information in more official 
documentation locations. The entries for Filenames and Backups are prime 
examples. I don’t believe I would simply remove these questions from the FAQ, 
since they are so perennially-asked. However, I *am* again predisposed to 
streamlining these questions and moving the pertinent information to a separate 
page in the wiki.

> 
>> 4. Configuring and Managing
>>  [Move “Customizing" questions from current section 8 to this section]
> yes
> 
>> 5. Troubleshooting
> Please insert no separate Troubleshooting. It would lead to duplicate
> sections.

Currently, the heading is “Installation Troubleshooting” and contains 
installation questions and a whole lot of other crap that do

[GNC-dev] CSV Transactions exporter issues and a question

[David T. via gnucash-devel]

Hello,

I was just fiddling around with the CSV exporter (trying to clarify something 
for the FAQ) on GC3.1.1 under Mac OS 10.13.6.

A couple of issues:
1) When I got to the screen to select the output filename, there was a file 
picker section, below which is an OK button, and the assistant navigator 
buttons Cancel/Back/Next. For me, the “Next” button never activates, even 
though I enter a valid filename and select a valid folder (see screenshot). It 
turns out that this user must click OK to move forward. This is confusing.
2) In my first fumbling attempt to run through the process, I went back to this 
screen and tried to enter a new file name and GC crashed out. I was not able to 
reproduce the crash subsequently.
3) I attempted to tell the exporter to user Tabs as the delimiter, as I 
expected any of the other options (comma, colon or semi-colon) to appear in my 
output data. Entering “\t” in the Other field, however, did not result in a 
tab-delimited file, but rather a “\t” delimited file. It would be nice either 
to have the tab included as an option, or the “other” option to process escaped 
characters like “\t”

And, now the question (an easy one!): for what version was the Export 
Transactions to CSV option added?

TIA,
David

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

[GNC-dev] Wiki FAQ Page

[David T. via gnucash-devel]

Hello,

I am digging in to the FAQ page with an eye to rationalizing the accumulated 
mess. My hope is to make it easier for uers to find answers to their questions. 

Currently, the structure of the page does not accurately reflect the content of 
the questions. For example, the section “Installation Troubleshooting” covers 
two broad and disparate question areas. 

In addition, numerous questions have been placed haphazardly in sections to 
which they do not belong. For example, questions about theming do not belong 
under Installation (for Mac or Windows), but IMHO under “GnuCash Files and 
managing a GnuCash installation”, which itself would be better named 
“Configuring and Managing”

On a practical level, as I rearrange the FAQ on some pretty substantial levels, 
questions and headings on the page will be changed. 

First issue: I do not see a way to see whether the wiki has any instances of 
links to a specific question. Clicking “What links here” only shows links to 
the overall FAQ page.

Second issue: many links from the mailing lists will no longer work, which may 
cause problems for users searching the ML archives and retrieving the stale 
links. How should this be handled?

Now, on a meta-level, I think the primary headings here might be better 
arranged as follows:

1. General Questions
  [move “Accounting Questions” to this section]
2. Installation
3. Using GnuCash [moved ahead of cunfiguring]
4. Configuring and Managing
  [Move “Customizing" questions from current section 8 to this section]
5. Troubleshooting
6. Exporting and Importing Data
7. Business Features
  [Move entire Developing GnuCash section of questions to the pages established 
for Developers]

I welcome input and feedback.

David


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

Re: [GNC-dev] Bugzilla Structure

[David T. via gnucash-devel]

Thanks, John; I found that about ten minutes after I sent it out! 

I do still think that a bug that crosses documents causes categorization 
issues. Adrien’s suggestion to add a General (I paraphrase) option might be 
useful.

David

> On Aug 27, 2018, at 11:09 AM, John Ralls  wrote:
> 
> 
> 
>> On Aug 27, 2018, at 7:28 AM, David T. via gnucash-devel 
>>  wrote:
>> 
>> Hello,
>> 
>> I was just trying to track down the status of documentation bug 777893, and 
>> was stymied for a bit. 
>> 
>> A bit of history: I raised the bug to induce the addition of information 
>> about the SQL formats. Subsequently, I wrote a section for inclusion in the 
>> Guide, which was submitted 10 days ago as Pull Request #109.
>> 
>> Today, I wanted to go add the PR # to the bug, and clicked my way to the 
>> bugzilla section for the Guide, only to not find the bug in question. 
>> Searching by bug number shows that the bug was entered under Help, rather 
>> than Guide. This situation points out that breaking the bugs out to this 
>> level of granularity can have negative effects: first, it forces a reporter 
>> to decide on the appropriate document for a bug, rather than focus on the 
>> problem in question; second a user looking for these bugs must discern the 
>> specific document to which a given bug was assigned in order to locate said 
>> bug; third, it causes difficulty if a given bug recommends changes to more 
>> than one piece of documentation, as this bug does—which doc does the bug get 
>> assigned to?
>> 
>> While it may have seemed an advance to be able to structure our bugs to 
>> cover specific documents, I wonder at the choice at this point, and ask how 
>> difficult it would be either to change the structure itself, or find a way 
>> to allow users the option of seeing all Doc bugs in an aggregated screen?
> 
> Yeah, don’t select a component when you do the search.
> 
> Regards,
> John Ralls
> 

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

[GNC-dev] Bugzilla Structure

[David T. via gnucash-devel]

Hello,

I was just trying to track down the status of documentation bug 777893, and was 
stymied for a bit. 

A bit of history: I raised the bug to induce the addition of information about 
the SQL formats. Subsequently, I wrote a section for inclusion in the Guide, 
which was submitted 10 days ago as Pull Request #109.

Today, I wanted to go add the PR # to the bug, and clicked my way to the 
bugzilla section for the Guide, only to not find the bug in question. Searching 
by bug number shows that the bug was entered under Help, rather than Guide. 
This situation points out that breaking the bugs out to this level of 
granularity can have negative effects: first, it forces a reporter to decide on 
the appropriate document for a bug, rather than focus on the problem in 
question; second a user looking for these bugs must discern the specific 
document to which a given bug was assigned in order to locate said bug; third, 
it causes difficulty if a given bug recommends changes to more than one piece 
of documentation, as this bug does—which doc does the bug get assigned to?

While it may have seemed an advance to be able to structure our bugs to cover 
specific documents, I wonder at the choice at this point, and ask how difficult 
it would be either to change the structure itself, or find a way to allow users 
the option of seeing all Doc bugs in an aggregated screen?

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

Re: [GNC-dev] Documentation Version Display

[David T. via gnucash-devel]

Adrien,

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

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

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

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

David

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

Re: [GNC-dev] Documentation Version Display

[David T. via gnucash-devel]

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

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

[David T. via gnucash-devel]

Thanks for the hand-holding…

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

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

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

David

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

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

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

[David T. via gnucash-devel]

Geert,

I went ahead and closed the PR. 

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

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

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

Kinks in the hose!

David

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

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

[GNC-dev] Documentation Version Display

[David T. via gnucash-devel]

Hello,

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

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

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

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

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