Re: [GNC-dev] [GNC] ANNOUNCE: GnuCash Windows Bundle 4.11-1 Released

[D via gnucash-devel]

Frank,

The announcements are sent both to -users and -devel. Since the guidance of the 
list is to reply all, a user reply-all will go to both lists. 

Just like your reply did. 

David T. 

On Jul 14, 2022, 11:36, at 11:36, "Frank H. Ellenberger" 
 wrote:
>Hello Allan,
>
>as this is a user question it should have been sent to gnucash-users
>only.
>
>Yes, the fix did not happen in GnuCash itself, but its bundled
>dependencies:
>https://github.com/Gnucash/gnucash-on-windows/commit/03f7f35342d717c1a137e82ad4d8f4973fa4f934
>
>Regards
>Frank
>
>Am 14.07.22 um 07:31 schrieb Alan A Holmes:
>> I've just installed this latest update, as I do all updates, after
>return
>> from holiday. Though the setup.exe is definitely a different size to
>V4.11,
>> Help->About gives me exactly the same version number and build date.
>Is that
>> what I would expect?
>> 
>> 
>> Alan A Holmes
>___
>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: Menu Treev

[D via gnucash-devel]

My apologies to everyone. It seems my pocket has something to say on this 
topic. I only wish I knew what it was. Obviously it was very important, since 
it got said several times. 

David T.

On Jun 14, 2022, 12:26, at 12:26, D via gnucash-devel 
 wrote:
>Hhvbblb v hhubhggvgghbvgmb
>
>On Jun 14, 2022, 07:50, at 07:50, Ralf Zerres 
>wrote:
>>Dear developers,
>>
>>with all that work in place for Co-Owner support, i still can't make
>it
>>to see the UI Menu-Entries.
>>
>>It must be something simple and stupid, but i don't get the clue.
>>All UI actions have been defined, all xml-files adopted. 
>>
>>I'm aware, that the business entries are added in a dynamic fashion. I
>>cross checked 
>>
>>* gnucash/ui/gnc-plugin-page-owner-tree-ui.xml and  
>>* gnucash/ui/gnc-plugin-business-ui.xml
>>* gnucash/gnome/gnc-plugin-business.c
>>
>>What am i missing?
>>
>>
>>
>>___
>>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: Menu Treev

[D via gnucash-devel]

Hhvbblb v hhubhggvgghbvgmb

On Jun 14, 2022, 07:50, at 07:50, Ralf Zerres  wrote:
>Dear developers,
>
>with all that work in place for Co-Owner support, i still can't make it
>to see the UI Menu-Entries.
>
>It must be something simple and stupid, but i don't get the clue.
>All UI actions have been defined, all xml-files adopted. 
>
>I'm aware, that the business entries are added in a dynamic fashion. I
>cross checked 
>
>* gnucash/ui/gnc-plugin-page-owner-tree-ui.xml and  
>* gnucash/ui/gnc-plugin-business-ui.xml
>* gnucash/gnome/gnc-plugin-business.c
>
>What am i missing?
>
>
>
>___
>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: Menu Treevb

[D via gnucash-devel]

Hhvbblb v hhubhggvgghbvgmb

On Jun 14, 2022, 07:50, at 07:50, Ralf Zerres  wrote:
>Dear developers,
>
>with all that work in place for Co-Owner support, i still can't make it
>to see the UI Menu-Entries.
>
>It must be something simple and stupid, but i don't get the clue.
>All UI actions have been defined, all xml-files adopted. 
>
>I'm aware, that the business entries are added in a dynamic fashion. I
>cross checked 
>
>* gnucash/ui/gnc-plugin-page-owner-tree-ui.xml and  
>* gnucash/ui/gnc-plugin-business-ui.xml
>* gnucash/gnome/gnc-plugin-business.c
>
>What am i missing?
>
>
>
>___
>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: Menu Treevb

[D via gnucash-devel]

Hhvbblb v hhubhggvgghbvgmb

On Jun 14, 2022, 07:50, at 07:50, Ralf Zerres  wrote:
>Dear developers,
>
>with all that work in place for Co-Owner support, i still can't make it
>to see the UI Menu-Entries.
>
>It must be something simple and stupid, but i don't get the clue.
>All UI actions have been defined, all xml-files adopted. 
>
>I'm aware, that the business entries are added in a dynamic fashion. I
>cross checked 
>
>* gnucash/ui/gnc-plugin-page-owner-tree-ui.xml and  
>* gnucash/ui/gnc-plugin-business-ui.xml
>* gnucash/gnome/gnc-plugin-business.c
>
>What am i missing?
>
>
>
>___
>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: Menu Treevb

[D via gnucash-devel]

Hhvbblb v hhubhggvgghbvgmb

On Jun 14, 2022, 07:50, at 07:50, Ralf Zerres  wrote:
>Dear developers,
>
>with all that work in place for Co-Owner support, i still can't make it
>to see the UI Menu-Entries.
>
>It must be something simple and stupid, but i don't get the clue.
>All UI actions have been defined, all xml-files adopted. 
>
>I'm aware, that the business entries are added in a dynamic fashion. I
>cross checked 
>
>* gnucash/ui/gnc-plugin-page-owner-tree-ui.xml and  
>* gnucash/ui/gnc-plugin-business-ui.xml
>* gnucash/gnome/gnc-plugin-business.c
>
>What am i missing?
>
>
>
>___
>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 of prices in CSV files

[D. via gnucash-devel]

All you need is a csv file with four columns: 

Stock (i.e., ticker), Namespace (from Gnucash) , Date, Price

Follow the Importer prompts. 

I imagine you could figure out how to map your bank's file based on this. 




 Original Message 
From: Thomas 
Sent: Sun Jan 16 16:19:38 EST 2022
To: gnucash-devel@gnucash.org
Subject: [GNC-dev] Import of prices in CSV files

Hello,

I would like to use a custom (bank-provided) CSV-file containing the 
prices for some of my securities to fill the price database.
Unfortunately, I couldn't find a good source of information to do that 
with GnuCash itself (yet). If there's a proper way to do so, I'd be 
grateful for any advice.
If that is not possible out-of-the-box, I had a first draft for using 
the 'piecash' module for doing so (which seems not to handle the source 
definition of the price properly, and reports 'invalid' though).

What I am looking for is either a recommended approach for this or maybe 
hints on how to make sure that I don't break anything with it and keep 
my book and overall data intact.

Thanks a lot in advance!

Best regards,
Thomas
___
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] Small changes to comment text, mostly in gnucash/import-export/import-main-matcher.h

[D. via gnucash-devel]

Kevin, 

The preferred way to submit changes is through git PRs, not with patch files 
attached to emails to the lists. You'll get better results using that method. 

David T.


 Original Message 
From: Kevin Buckley 
Sent: Sun Dec 05 01:35:12 EST 2021
To: "Frank H. Ellenberger" 
Cc: gnucash-devel 
Subject: Re: [GNC-dev] Small changes to comment text, mostly in 
gnucash/import-export/import-main-matcher.h

On Wed, 1 Dec 2021 at 22:40, Frank H. Ellenberger
 wrote:
>
> Hi Kevin,
>
> don't forget to CC the list.
>
> Am 01.12.21 um 03:22 schrieb Kevin Buckley:
> > On Sat, 27 Nov 2021 at 23:36, Frank H. Ellenberger
> >  wrote:
> >>
> >> Hi Kevin,
> >>
> >> The comments containing "@param" are doxygen sources. How looks the reesult
> >> https://code.gnucash.org/docs/MAINT/import-main-matcher_8h.html and links?
> >>
> >> Regards
> >> Frank
> >
> > Yes the "a the" is visible there too.
> >
> > If I navigate through to, say,
> >
> > https://code.gnucash.org/docs/MAINT/group__Import__Export.html#gad26d36e9e962bb4ba174d697f59f25fb
> >
> > which is the doc for this fucntion
> >
> > gnc_gen_trans_list_empty()
> >
> > I see
> >
> > gboolean gnc_gen_trans_list_empty ( GNCImportMainMatcher *  info)
> >
> > Checks whether there are no transactions to match.
> >
> > Parameters
> > info A pointer to a the GNCImportMainMatcher structure.
> >
> > so the "a the" is in there too.
> >
> > FWIW, I have noticed a few other typos and spelling corrections in
> > the comments, so maybe I should clone the repo and submit a PR
> > with them all in?
>
> Yes, that would be the best approach.
> See also https://wiki.gnucash.org/wiki/Doxygen
>
> Regards
> Frank

Find a patch from a `git diff -p -stat` 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

[GNC-dev] Fwd: Re: [GNC] Flatpak/Flatseal Gnucash fails to launch

[D. via gnucash-devel]

Forwarding back to the list. 


 Original Message 
From: "Frank H. Ellenberger" 
Sent: Sat Nov 27 18:37:00 EST 2021
To: "D." 
Subject: Re: [GNC] Flatpak/Flatseal Gnucash fails to launch

Hi David

Am 27.11.21 um 23:53 schrieb D.:
>  if I used flatpak, I'd try to help you, instead of suggesting you go the 
> Google route. 

You are right, I should have mentioned that I cannot reproduce it under
Opensuse Tumbleweed (Linux 5.15.2-1-default #1 SMP x86_64) and
Flatpak 1.12.2.

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

Re: [GNC-dev] Chartsjs javascript not loaded in html reports since 4.6

[D. via gnucash-devel]

Someone reported similar troubles a while back. Take a look at 
https://lists.gnucash.org/pipermail/gnucash-user/2021-July/097219.html

I believe there was a simple fix. 


 Original Message 
From: Antonios Hadjigeorgalis 
Sent: Sat Nov 27 15:54:50 EST 2021
To: gnucash-devel@gnucash.org
Subject: [GNC-dev] Chartsjs javascript not loaded in html reports since 4.6

When I build 4.7, or 4.8a the html reports with javascript chartjs do not
show the charts.
When I export the report to html, I see the chartjs library is missing.



Where in 4.6 I see



the javascript location appears to be sourced from guile function
gnc-path-find-localized-html-file  in file
share/guile/site/2.2/gnucash/report/html-chart.scm

I can find this function defined in both 4.6 and the later builds in file
bindings/guile/swig-core-utils-guile.c.

Based on my current understanding of the code base, that's as far as I got
in looking for what is causing this error.  Are there any particular parts
of the documentation that would help me understand how this is happening?
I'd love to fix it if it could.  Any help would be appreciated.


Antonios Hadjigeorgalis
LinkedIn.com 
@AntoniosHadji

___
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] Omit zero balance figures Vs Show zero balances

[D. via gnucash-devel]

As I stated previously, the developers want want no entry to reflect the 
default. In this case, the default preference is to display zero balance 
accounts. Your alternative requires a value for the default (Display zero 
balance accounts is checked for the default), whereas the existing setting does 
not require a value for the default (Display zero balance accounts does not 
require a value for the default).

You can argue with the decision behind this, but I don't think you'll get very 
far. It's been part of the Gnucash fabric for a long time. 


 Original Message 
From: flywire 
Sent: Wed Nov 24 17:15:47 EST 2021
To: gnucash-devel 
Subject: Re: [GNC-dev] Omit zero balance figures Vs Show zero balances

Probably clearer to demonstrate same default functionality with different
user interface:
* Default is Off with On to Omit - double negative ??
* Alternative default is On with Off to Omit - consistent and logical on a
*Display* tab ??

[image: OmitVsDisplay.png]




___
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] Omit zero balance figures Vs Show zero balances

[D. via gnucash-devel]

Because: a) the default behavior in the reports is to display zero balance 
accounts,  and b) the Gnucash developers want omitted preferences to cause the 
default behavior. 




 Original Message 
From: flywire 
Sent: Mon Nov 22 20:29:52 EST 2021
To: gnucash-devel 
Subject: [GNC-dev] Omit zero balance figures Vs Show zero balances

Display options are selected to display something except for Omit zero
balance figures. Why is it any different to Include accounts with zero
total balances ie select to display?
___
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] old online Quotes

[D. via gnucash-devel]

Daily prices for a long period of time can increase the size of a file pretty 
significantly. I don't recall what my own results were when I pruned my price 
db and replaced it with monthly numbers, but I do remember a dip in size. 
Whether that size affects anything in regular use is another thing altogether. 


 Original Message 
From: Chris Good 
Sent: Sun Oct 31 16:32:06 EDT 2021
To: gnucash-devel@gnucash.org
Subject: Re: [GNC-dev] old online Quotes

Hi Snehal,

Possibly adding daily prices for 7 years would have an unwanted effect on the 
size of the database or the performance…
Perhaps monthly may be all that is required, or only add those prices to a 
one-off database?

Regards,
Chris Good

> Message: 3
> Date: Sat, 30 Oct 2021 23:07:51 -0400
> From: "D." 
> To: John Ralls 
> Cc: Snehal Bhavsar ,gnucash-devel@gnucash.org
> Subject: Re: [GNC-dev] old online Quotes
> Message-ID: <2b063c73-b360-44ec-8332-9357c33cd...@yahoo.com>
> Content-Type: text/plain; charset=UTF-8
> 
> There are a few external projects that do this as well, although they are at 
> this point rather dated, and may not work in the current environment. There 
> is something on the wiki about these. 
> 
> 
>  Original Message 
> From: John Ralls 
> Sent: Sat Oct 30 16:10:56 EDT 2021
> To: Snehal Bhavsar 
> Cc: gnucash-devel@gnucash.org
> Subject: Re: [GNC-dev] old online Quotes
> 
> 
> 
>> On Oct 30, 2021, at 12:18 PM, Snehal Bhavsar  wrote:
>> 
>> hi All,
>> 
>> I have been using GnuCash for the last 7 years... and started using Online
>> Fund get Quotes from the last 1-2 years...
>> 
>> Get Quotes  gets the latest file.. is there a way to get old quotes.
>> 
>> I would like to bring all the daily fund prices for all my funds for the
>> last 7 years for use in a report..
> 
> Not directly. You can get historical prices from yahoo or alpha vantage as a 
> CSV and then import it into GnuCash with File>Import>Import Prices From a CSV 
> File.
> 
> 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] old online Quotes

[D. via gnucash-devel]

There are a few external projects that do this as well, although they are at 
this point rather dated, and may not work in the current environment. There is 
something on the wiki about these. 


 Original Message 
From: John Ralls 
Sent: Sat Oct 30 16:10:56 EDT 2021
To: Snehal Bhavsar 
Cc: gnucash-devel@gnucash.org
Subject: Re: [GNC-dev] old online Quotes



> On Oct 30, 2021, at 12:18 PM, Snehal Bhavsar  wrote:
> 
> hi All,
> 
> I have been using GnuCash for the last 7 years... and started using Online
> Fund get Quotes from the last 1-2 years...
> 
> Get Quotes  gets the latest file.. is there a way to get old quotes.
> 
> I would like to bring all the daily fund prices for all my funds for the
> last 7 years for use in a report..

Not directly. You can get historical prices from yahoo or alpha vantage as a 
CSV and then import it into GnuCash with File>Import>Import Prices From a CSV 
File.

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] How do I get the "sign" (or side) of the transaction from the account or transaction element in xml?

[D. via gnucash-devel]

I'm not sure I follow your issue, but I'll note that the list of types of 
accounts in GnuCash is outlined in the Help docs in Chapter 5 at 
https://code.gnucash.org/docs/C/gnucash-help/acct-types.html

There are 13 types listed there. 


 Original Message 
From: Arman Schwarz 
Sent: Sun Jul 11 08:03:51 EDT 2021
To: Geert Janssens 
Cc: gnucash-devel@gnucash.org
Subject: Re: [GNC-dev] How do I get the "sign" (or side) of the transaction 
from the account or transaction element in xml?

Ok I'll take a look myself, thanks for pointing me in the right direction.

On Sun, 11 Jul 2021, 9:50 pm Geert Janssens, 
wrote:

> Op zondag 11 juli 2021 13:38:43 CEST schreef Arman Schwarz:
> > Thanks Geert,
> >
> > I'm aware of the need to think in terms of debit/credit signs, but my
> > question was how I could know whether a positive value in the split
> element
> > in the XML will increase or decrease the "balance" that the user sees in
> > gnucash.
> >
> > This depends on the side of the accounting equation the account is on,
> e.g.
> > positive split values increase the balance of an asset account, but
> > decrease the balance of an income account. Rather than manually
> maintaining
> > a mapping of account types and whether the sign is positive or negative,
> I
> > was hoping there'd be something in the XML or perhaps in those bindings
> you
> > mentioned that would do this for me.
> >
>
> I don't think this is stored in the xml file as the net representation in
> the
> gui is a combination of account type and the user preference. The former
> is
> hard-coded, the latter can be changed by the user. I don't know if we can
> access either information via the python bindings. I don't use them myself.
>
> 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] Removing "unused" code

[D. via gnucash-devel]

I thought the eguile report was included in the distribution already. 


 Original Message 
From: Christopher Lam 
Sent: Sat Jun 12 07:57:35 EDT 2021
To: Mike Alexander 
Cc: Gnucash Devel 
Subject: Re: [GNC-dev] Removing "unused" code

This particular commit aimed to simplify and reduce old code. It can be
reverted.
Would you consider submitting them into the repository?

On Fri, 11 Jun 2021 at 06:12, Mike Alexander  wrote:

> I would like to request that we avoid removing code that is thought to
> be unused, but which may in fact be used, just for the sake of cleaning
> things up.  I use a couple of reports that are not part of the standard
> GnuCash distribution and every now and then they stop working because
> something they depend on is gone.  Since some of these are reports I
> didn't write it's often a nuisance to fix them.
>
> In particular I like the EGuile budget report written by Benoit
> Blancard, et al.  It stopped working after commit 4e38b68 which removed
> a number of parameters from gnc:html-acct-table including account-name
> which this report uses.  Assuming something is unused everywhere just
> because no built-in report uses it is not a safe assumption.
>
> Rather than try to figure out what to use instead and how to fix it I
> just reverted that change, but this may cause me trouble later if
> something else is done that depends on this change.
>
> I understand that cleaning up code and removing dead code are good
> things to do, but I think this is going too far.
>
> Mike
>
___
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] Nice Job All!

[D. via gnucash-devel]

I'll jump in to say that:

1) xml is still considered the primary storage format, and
2) the xml format is by default gzipped, which will render a cat illegible. You 
can turn off compression in GnuCash, or you can gunzip the file and cat the 
results. 

HTH,
David



 Original Message 
From: Scott Morgan 
Sent: Thu Jan 07 19:30:14 EST 2021
To: John Ralls 
Cc: gnucash-devel@gnucash.org
Subject: Re: [GNC-dev] Nice Job All!

Ok, thanks for the clarification.   If SQL is the main model format where
is the best place to look for docs on the SQL schema ?   I don't even seem
to be able to get see the XML correctly, I will log this as a bug (perhaps
the older 3.11 version [on an old mac 10.10.5])  ie;

cat 2020-01-07.gnucash.xml.gnucash


4???p?~???'??M??f??

I'm digging in the bug list, but is this known to anyone?

On Thu, Jan 7, 2021 at 5:17 PM John Ralls  wrote:

>
>
> > On Jan 7, 2021, at 1:40 PM, Scott Morgan  wrote:
> >
> > Hey All,
> >
> >  I just wanted to thank you all for working hard to bring gnucash into
> the
> > world.  I am curious about your XML formats, are you using XSD schema
> files
> > or DTD files.
> >  #2 is there a good way to transfer the XML files to a SQL db and vice
> > versa with gnucash?
> >  #3) As an avid developer (Java / https://github.com/adligo) I have
> become
> > sick of XML and JSON and I am looking for collaborators to develop a new
> > binary data format that is mostly text.  What I really mean is that I am
> > looking to build a pluggable parsing strategy that avoids s-expressions
> and
> > allows csv file data inside of trees called;
> > Classification Markup Notation
> >  Let me know if any of you are interested in this idea and would like to
> > collaborate.
> >
>
> Scott,
>
> Neither DTD nor XML:Schema nor relax, we don't use parser validation. All
> of the XML semantics are hard-coded in the SAX handlers. There are some
> DTDs and a relax schema in libgnucash/doc/xml, but they're for
> documentation only.
>
> The only way at present to convert between XML and SQL is File>Save As
> from an open book. We have it on the long-term todo list to write a more
> direct conversion but it hasn't even been started.
>
> Regards,
> John Ralls
>
>

-- 
Regards,
Scott Morgan
President & CEO
Adligo Inc
http://www.adligo.com
https://www.linkedin.com/in/scott-morgan-21739415
A+ Better Business Bureau Rating

https://github.com/adligo

By Appointment Only:
1-866-968-1893 Ex 101
sc...@adligo.com
skype:adligo1?call
Send Me Files Securely:
*https://www.sendthisfile.com/f.jsp?id=ewOnyeFQM18IDRf7MMIdolfI
*
___
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

[D. via gnucash-devel]

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" 
Sent: Mon Sep 28 09:20:21 EDT 2020
To: Christopher Lam 
Cc: gnucash-devel 
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

Re: [GNC-dev] [GNC] Experimental Balance Sheet report

[D via gnucash-devel]

Ok. Thanks. I'll leave it lie then. Never mind. 

On Sep 16, 2020, 19:47, at 19:47, Christopher Lam  
wrote:
>Hi David, responses inline. I'm sure you know it's my work, and I am
>(for
>now) happy to defend its state. TBH I do not need this report myself,
>but
>figure out it fills a gap. I also think devel is more appropriate.
>
>In my view it won't come out of experimental anytime soon because of
>https://bugs.gnucash.org/show_bug.cgi?id=797786 -- figuring out price
>from
>stock/foreign-currency into target currency is *HARD*. TL;DR: in some
>price-sources (avg-bal/wt-avg) current balance sheet will tally only
>txns
>UPTO report-date and calculate price from it; in multicolumn report
>there
>are multiple report-dates therefore this strategy would be far too
>slow.
>I'm running out of steam to make pricing behave identically to the old
>balance-sheet.
>
>On Wed, 16 Sep 2020 at 16:42, David T. via gnucash-user <
>gnucash-u...@gnucash.org> wrote:
>
>> 1. When initially run, I receive an empty report. This is similar to
>the
>> initial result of the basic Transaction report, except in the latter
>> case, users are given a note that links them to the report options.
>It
>> would seem to me that at the least, this report should do the same. A
>> better solution in both cases would be to have initial parameters
>that
>> return some kind of data--however unrelated to the user's end
>> goal--rather than an empty page. It seems to me that users are better
>at
>> changing something they see that is wrong, rather than trying to
>conjure
>> it up out of thin air. (the famous quote from US Supreme Court
>Justice
>> Potter Stewart regarding obscenity comes to mind here: "I know it
>when I
>> see it. This is not it."). In the Balance Sheet, changing the Period
>> Duration setting from its default "None" to anything else (I'd
>suggest
>> "Year") yields data from which a user can build. (I have no
>suggestions
>> for the Transaction Report.)
>>
>
>This would be worthy of an individual bug report .
>
>
>> 2. The report defaults to including all accounts, including hidden
>and
>> placeholder accounts. While there is an option on the Accounts tab to
>> display hidden accounts, I think the decision to include hidden
>accounts
>> in the report by default is confusing, given that the Account tab
>> doesn't display hidden accounts by default. I think it makes more
>sense
>> for the report either to default to omitting hidden accounts, or to
>> default to displaying hidden accounts in the options dialog. I see
>that
>> the standard Balance Sheet report also includes hidden accounts by
>> default, although this is masked because the standard report limits
>the
>> accounts to 3 levels (the Experimental report defaults to All
>levels). I
>> will note that there is an option on the Display tab to omit zero
>> balance accounts, which may have been seen as a way to skip hidden
>> accounts. However, while it may not be prudent or common practice to
>> hide accounts that have balances, there is nothing in the program to
>> prevent this, which means that hiding zero balance accounts is not
>the
>> same as including hidden accounts. I'll note that if I Clear All and
>> then click Select All on the Accounts tab, the report properly omits
>all
>> hidden accounts, which it should also do by default. I suggest that
>both
>> reports should default to omitting Hidden accounts on opening, and
>that
>> the default level setting should be the same for both.
>>
>
>Also worthy of a bug report. The rationale IMV is that hidden accounts
>can
>carry balances and if they are skipped during report generation, they
>will
>cause undue mismatch between children balances and total parent
>balances.
>
>
>>
>> 3. The report propagates balances all the way up the account
>hierarchy,
>> which makes sense for accounts denominated in a currency. However,
>with
>> accounts denominated in commodities (such as Stock or Mutual Fund
>> accounts), it makes less sense, and in fact renders the report
>extremely
>> difficult to follow, especially with accounts with many different
>> commodities. Seeing a full listing of all 150 different commodities
>(and
>> various subsets thereof) repeated for
>>
>> Assets,
>> Assets:Investments,
>> Assets:Investments:Taxed,
>> Assets:Investments:Taxed:Self, and
>> Assets:Investments:Taxable:Self:Brokerage A
>>
>> gets old and confusing very quickly. It would be better to propagate
>> totals for the book currency  only, and leave the tallying of stock
>and
>> mutual fund holdings to the Advanced Portfolio report. I will note
>that
>> initially, I was going to ask why some entries in the report were
>listed
>> as hyperlinks, while others were not. After some puzzling, I figured
>out
>> that the non-linked entries were summarizations of holdings further
>down
>> the hierarchy. Removing the numerous duplications of commodity
>> summmarizations would at least make it a little clearer what is going
>on
>> in this regard. I will further note 

Re: [GNC-dev] "Mortgage Repayment Druid"

[D. via gnucash-devel]

Way back when, computer folks referred to system assistants (such as the new 
accounts assistant, or the mortgage setup assistant) as "druids." There was 
some obscure reasoning for this. Gnucash originally referred to its assistants 
as druids, but abandoned them for normal English terminology a long time ago. 

No doubt these ancient enhancement requests have languished for as long as they 
have because working out the details in setting up a mortgage repayment 
schedule are highly complex, and the return is so minimal. Variations in 
calculating interest alone pretty much guarantee that predicted values will 
diverge from the actuality, which force the user to modify those transactions 
anyway. I personally abandoned using scheduled transactions for loans for this 
reason. 

David T. 


 Original Message 
From: Dean Jagels 
Sent: Wed Sep 16 10:25:47 EDT 2020
To: gnucash-devel@gnucash.org
Subject: [GNC-dev] "Mortgage Repayment Druid"

There are a couple of old enhancement requests that refer to a "Mortgage 
Repayment Druid."  Is/was this a wizard of sorts?  Does it still exist?  
The House Mortgate How-To in the doc's makes no mention of such a thing.

Thanks,
Dean


___
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] Meaning of "RFE"

[D. via gnucash-devel]

Of the 535 bugs listed as enhancements, 35 include the "RFE" designation; the 
remaining are identified by the severity designation "enhancement." Thus, I 
wouldn't necessarily rely on that term to locate all the RFEs that have been 
submitted over the years. Better to search for bugs with a severity of 
"enhancement."

@Frank: it is duplicating effort in bugzilla to suggest that enhancements 
should include "RFE" in their descriptions, given that bugzilla includes 
enhancement as a severity level. Moreover, adding a note to the wiki that 
implies that adding this is common practice, when it overwhelmingly isn't, is 
rather presumptuous on your part. Why not encourage users to apply the feature 
that bugzilla already provides? 

David


 Original Message 
From: Dean Jagels 
Sent: Mon Sep 07 16:31:54 EDT 2020
To: gnucash-devel@gnucash.org
Subject: Re: [GNC-dev] Meaning of "RFE"

Frank, thanks for the link to the Enhancement Requests page.  I hadn't 
seen that one yet.  And there I see the RFE prefix!

Cheers,
Dean

P.S.  Thanks also to D.


On 9/7/20 3:19 PM, Frank H. Ellenberger wrote:
> Hi Dean,
>
> I try to answer more general for your current task.
>
> Did you read https://wiki.gnucash.org/wiki/Bugzilla,
> https://wiki.gnucash.org/wiki/Enhancement_requests, and
> https://wiki.gnucash.org/wiki/Bugzilla_Administration?
>
> In some cases also
> https://bugzilla.readthedocs.io/en/5.0/using/index.html is useful.
>
> Regards
> Frank
>
> Am 07.09.20 um 02:50 schrieb Dean Jagels:
>> In Bugzilla, I see quite a few summaries prefixed "RFE".  What does this
>> stand for?  Is there a glossary for other prefixes?
>>
>> Thanks,
>> Dean

___
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] Meaning of "RFE"

[D. via gnucash-devel]

Request For Enhancement. 



 Original Message 
From: Dean Jagels 
Sent: Sun Sep 06 20:50:53 EDT 2020
To: gnucash-devel@gnucash.org
Subject: [GNC-dev] Meaning of "RFE"

In Bugzilla, I see quite a few summaries prefixed "RFE".  What does this 
stand for?  Is there a glossary for other prefixes?

Thanks,
Dean


___
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] Dev's features of choice?

[D. via gnucash-devel]

Jean,

I think you raise a valid point. There does seem to be a tendency in the 
community to assume that a certain amount of inconvenience is to be expected. 
The reasons vary, but the underlying tendency remains.

David T. 


 Original Message 
From: jean laroche 
Sent: Sun Jul 26 17:49:47 EDT 2020
To: "Frank H. Ellenberger" 
Cc: GnuCash Developer 
Subject: Re: [GNC-dev] Dev's features of choice?



On 7/26/2020 1:54 PM, Frank H. Ellenberger wrote:
> Hi Jean,
>
> Am 26.07.20 um 19:57 schrieb jean laroche:
>> I'm curious about something:
>> If you're a GC dev, contributing code to the project, what's the
>> feature(s) you'd like to see added to GC?
>> I'm only contributing a bit, but I'll offer my 3 top wishes:
>> - Undo/(redo)
>> - Multi-transaction (bulk) editing
>> - Multi-account (bulk) editing
> All three are violations of strict accounting rules. We often talk about
> "In the times of ink and paper", not graphite (pencils). Some
> governments require the immutabiity of once written records.
I see a disconnect here. Some of us (John in particular) insist that GC 
is not a system for professionals, only for personal finance.
Yet, I always hear about accounting rules, and the way it should be done 
by the book. If GC is really for the personal user, I don't understand 
how we can survive without undo/redo, and multi-select. *every* piece of 
software out there has these types of features, and they're invaluable.
J.
___
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] error message with finance::quote gnc-path-check + problems with retrieving quotes for 2 symbols.

[D. via gnucash-devel]

Exactly! 


 Original Message 
From: Derek Atkins 
Sent: Wed Jun 24 16:54:26 EDT 2020
To: "D." 
Cc: "Frank H. Ellenberger" , Dawid Wrobel via 
gnucash-devel 
Subject: Re: [GNC-dev] [GNC] error message with finance::quote gnc-path-check + 
problems with retrieving quotes for 2 symbols.

Also if you are in the outback without connectivity to read the wiki you
are definitely not going to have the connectivity to grab quotes!  LOL.
-derek

On Wed, June 24, 2020 3:54 pm, D. via gnucash-devel wrote:
> Further : the user case for a user to be actually unable to access the
> internet to consult the wiki is I think rather extreme. Inconvenient,
> perhaps; maddeningly slow, even. But actually unavailable?
>
> Personally, I'm not sure how many transactions I would generate in the
> "outback," anyway. I'd just wait until I had some connectivity to do my
> online accounting. Besides my laptops never have that much battery life to
> them.
>
>
>  Original Message 
> From: "Frank H. Ellenberger" 
> Sent: Wed Jun 24 12:18:19 EDT 2020
> To: "D." 
> Cc: gnucash-devel 
> Subject: Re: [GNC-dev] [GNC] error message with finance::quote
> gnc-path-check + problems with retrieving quotes for 2 symbols.
>
> David,
>
> Am 24.06.20 um 14:01 schrieb D.:
>> Yet another documentation appendix that would be more appropriately
>> placed on the wiki...
>
> you are still walking in the wrong direction!
>
> If you are in the outback the wiki is not available or the access is
> very expensive, but the docs are installed on
> * Windows and Macos always,
> * Linux details depend on the distribution and your choice. Usually if
> you install gnucash, you get the recommendation to install gnucash-docs,
> too.
>
> Frank
>
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>


-- 
   Derek Atkins 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant


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

Re: [GNC-dev] [GNC] error message with finance::quote gnc-path-check + problems with retrieving quotes for 2 symbols.

[D. via gnucash-devel]

Further : the user case for a user to be actually unable to access the internet 
to consult the wiki is I think rather extreme. Inconvenient, perhaps; 
maddeningly slow, even. But actually unavailable? 

Personally, I'm not sure how many transactions I would generate in the 
"outback," anyway. I'd just wait until I had some connectivity to do my online 
accounting. Besides my laptops never have that much battery life to them. 


 Original Message 
From: "Frank H. Ellenberger" 
Sent: Wed Jun 24 12:18:19 EDT 2020
To: "D." 
Cc: gnucash-devel 
Subject: Re: [GNC-dev] [GNC] error message with finance::quote gnc-path-check + 
problems with retrieving quotes for 2 symbols.

David,

Am 24.06.20 um 14:01 schrieb D.:
> Yet another documentation appendix that would be more appropriately placed on 
> the wiki...

you are still walking in the wrong direction!

If you are in the outback the wiki is not available or the access is
very expensive, but the docs are installed on
* Windows and Macos always,
* Linux details depend on the distribution and your choice. Usually if
you install gnucash, you get the recommendation to install gnucash-docs,
too.

Frank

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

Re: [GNC-dev] [GNC] error message with finance::quote gnc-path-check + problems with retrieving quotes for 2 symbols.

[D. via gnucash-devel]

Whatever. 


 Original Message 
From: "Frank H. Ellenberger" 
Sent: Wed Jun 24 12:18:19 EDT 2020
To: "D." 
Cc: gnucash-devel 
Subject: Re: [GNC-dev] [GNC] error message with finance::quote gnc-path-check + 
problems with retrieving quotes for 2 symbols.

David,

Am 24.06.20 um 14:01 schrieb D.:
> Yet another documentation appendix that would be more appropriately placed on 
> the wiki...

you are still walking in the wrong direction!

If you are in the outback the wiki is not available or the access is
very expensive, but the docs are installed on
* Windows and Macos always,
* Linux details depend on the distribution and your choice. Usually if
you install gnucash, you get the recommendation to install gnucash-docs,
too.

Frank

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

Re: [GNC-dev] [GNC] GnuCash 3.906 Released

[D. via gnucash-devel]

Seems like this feature needs a few more kinks worked out. At the least, saving 
zero width column settings should be allowed. A kludge might be to 
programmatically reset a zero width column to 1px on save. I doubt most users 
would notice or object to the difference on screen. 


 Original Message 
From: Adrien Monteleone 
Sent: Wed Jun 24 11:01:31 EDT 2020
To: gnucash-devel 
Subject: Re: [GNC-dev] [GNC] GnuCash 3.906 Released

I guess that is what I managed to do. I'm interpreting ‘0px’ to mean the 
dividers merge/overlap so you only see a single-width divider. That it seems 
doesn’t get saved, but it is easier to accomplish dexterity-wise without having 
to carefully hit a fine-tuned target. (I’m using a touch pad, not sure if this 
is easier or harder with a mouse)

Regards,
Adrien

> On Jun 24, 2020 w26d176, at 9:56 AM, Robert Fewell <14ubo...@gmail.com> wrote:
> 
> It may be possible to save the column widths as 1px when the columns are 
> dragged on screen to zero px.
> 
> Regards,
> Bob
> 


___
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] error message with finance::quote gnc-path-check + problems with retrieving quotes for 2 symbols.

[D. via gnucash-devel]

Yet another documentation appendix that would be more appropriately placed on 
the wiki...


 Original Message 
From: "Frank H. Ellenberger" 
Sent: Wed Jun 24 05:25:57 EDT 2020
To: "uhopfer@gmail" 
Cc: gnucash-devel 
Subject: Re: [GNC-dev] [GNC] error message with finance::quote gnc-path-check + 
problems with retrieving quotes for 2 symbols.



Am 24.06.20 um 01:51 schrieb John Ralls:
> The 3 TIAA-CREF symbols are QCGLRX, QCSCIX, QCSCRX. TIAA-CREF does not return 
> any quote for these.
> 

Because TIAA-CREF uses it's own numbers from colum bogus:
https://code.gnucash.org/docs/C/gnucash-help/fq-spec-tiaa.html

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] Feedback on GnuCash 3.903

[D via gnucash-devel]

Michael,

The idea of default column widths makes sense, but the idea that a user's 
previously set preferences will no longer apply seems a little backward. 

I am curious to know more about the thought process that arrived at this 
solution. I'd have thought that storing per account column settings wouldn't 
cause too much storage problem, and I would imagine the register opening 
process could look, in order, for an account-specific column record by guid, 
and, upon failure, the default for that account type in question. I wouldn't 
imagine that such a process would be onerous even for the largest of gnucash 
books. But, I am no programmer. 

David

On Jun 5, 2020, 11:18, at 11:18, "Fross, Michael"  wrote:
>Hello David T.,
>
>I understand the point.  But I also struggle with having a lot of
>security
>accounts and I'm always having to go tweak them.  If I could set it
>once
>and it would apply to them all, I applaud the decision.  I think it
>boils
>down to how the account types are defined.
>
>Michael
>
>On Fri, Jun 5, 2020 at 9:05 AM D via gnucash-devel <
>gnucash-devel@gnucash.org> wrote:
>
>> Bob,
>>
>> I still don't understand fully. Are you saying that if I set my
>column
>> widths differently for Stock A and Stock B, and then close both and
>reopen
>> them both, that they will open with a set of arbitrarily-defined
>default
>> widths for that account type, rather than the account-specific
>settings I'd
>> chosen previously?
>>
>> If that is so, I'd say that the decision that "was made" was a bad
>one.
>>
>> To take one example, my mortgage and my credit card are both
>liability
>> accounts. The balances in the two accounts are going to be
>significantly
>> different, however, and I'd prefer to have different widths for the
>balance
>> column. It sounds like I'd be out of luck in this new regime, yes?
>>
>> I'm not clear what benefit this provides on the back end. Could you
>> explain these reasons more clearly?
>>
>> Thanks,
>> David T.
>>
>> On Jun 5, 2020, 06:41, at 06:41, Robert Fewell <14ubo...@gmail.com>
>wrote:
>> >David,
>> >
>> >It was decided that instead of every time you open a register and
>then
>> >change that layout to your liking we could just save the widths to
>be
>> >used
>> >as defaults for the 6 register layouts. As most registers of type
>will
>> >have
>> >similar widths set, the first one loaded will be used to set the
>> >default
>> >widths for that type which you can obviously change and save for
>future
>> >opening of that type of register. To accommodate situations like you
>> >have
>> >described, register widths of all open registers when Gnucash is
>closed
>> >will also be saved and used when restoring. Should any of them be
>> >closed
>> >and reopened then they will base the widths on the saved default for
>> >that
>> >register type.
>> >Hope that answers your question.
>> >
>> >On Fri, 5 Jun 2020 at 11:12, David H  wrote:
>> >
>> >> Rob,
>> >>
>> >> Please clarify this.  I have 2 savings accounts and 4 credit card
>> >accounts
>> >> that I have open all the time and over the years I've gone to the
>> >trouble
>> >> of setting these up just the way I like them.  Of course flicking
>> >through
>> >> the register tabs the columns aren't all in the same places as I'm
>> >using
>> >> accounts with different nesting levels in each so the Transfer
>column
>> >> widths vary even within each account type.  Are you saying that
>these
>> >would
>> >> be treated as 2 register types and you are going to blow away all
>my
>> >good
>> >> work and just randomly choose one of the open settings as the
>default
>> >when
>> >> you remove old configurations?
>> >>
>> >> Thanks David H.
>> >>
>> >>
>> >> On Fri, 5 Jun 2020 at 19:05, Robert Fewell <14ubo...@gmail.com>
>> >wrote:
>> >>
>> >>> Mark,
>> >>> Yes the saving of column widths has changed, in version 4.0 they
>are
>> >saved
>> >>> per register type so you only have to set the defaults once per
>type
>> >>> instead of every single register opened, there are menu options
>> >under
>> >>> 'Windows' that allow you to save new register widths or clear
>them.
>> >Open
>> >>> regis

Re: [GNC-dev] Feedback on GnuCash 3.903

[D via gnucash-devel]

Bob,

I still don't understand fully. Are you saying that if I set my column widths 
differently for Stock A and Stock B, and then close both and reopen them both, 
that they will open with a set of arbitrarily-defined default widths for that 
account type, rather than the account-specific settings I'd chosen previously?

If that is so, I'd say that the decision that "was made" was a bad one. 

To take one example, my mortgage and my credit card are both liability 
accounts. The balances in the two accounts are going to be significantly 
different, however, and I'd prefer to have different widths for the balance 
column. It sounds like I'd be out of luck in this new regime, yes?

I'm not clear what benefit this provides on the back end. Could you explain 
these reasons more clearly?

Thanks,
David T. 

On Jun 5, 2020, 06:41, at 06:41, Robert Fewell <14ubo...@gmail.com> wrote:
>David,
>
>It was decided that instead of every time you open a register and then
>change that layout to your liking we could just save the widths to be
>used
>as defaults for the 6 register layouts. As most registers of type will
>have
>similar widths set, the first one loaded will be used to set the
>default
>widths for that type which you can obviously change and save for future
>opening of that type of register. To accommodate situations like you
>have
>described, register widths of all open registers when Gnucash is closed
>will also be saved and used when restoring. Should any of them be
>closed
>and reopened then they will base the widths on the saved default for
>that
>register type.
>Hope that answers your question.
>
>On Fri, 5 Jun 2020 at 11:12, David H  wrote:
>
>> Rob,
>>
>> Please clarify this.  I have 2 savings accounts and 4 credit card
>accounts
>> that I have open all the time and over the years I've gone to the
>trouble
>> of setting these up just the way I like them.  Of course flicking
>through
>> the register tabs the columns aren't all in the same places as I'm
>using
>> accounts with different nesting levels in each so the Transfer column
>> widths vary even within each account type.  Are you saying that these
>would
>> be treated as 2 register types and you are going to blow away all my
>good
>> work and just randomly choose one of the open settings as the default
>when
>> you remove old configurations?
>>
>> Thanks David H.
>>
>>
>> On Fri, 5 Jun 2020 at 19:05, Robert Fewell <14ubo...@gmail.com>
>wrote:
>>
>>> Mark,
>>> Yes the saving of column widths has changed, in version 4.0 they are
>saved
>>> per register type so you only have to set the defaults once per type
>>> instead of every single register opened, there are menu options
>under
>>> 'Windows' that allow you to save new register widths or clear them.
>Open
>>> registers also save their widths and therefore can have temporarily
>>> changed
>>> widths.
>>>
>>> What should happen is when a register is opened with a saved
>configuration
>>> and no default has been saved for that type, that configuration will
>be
>>> used as the default. Once there is a default for the register type,
>all
>>> old
>>> configurations will be removed. Did this not happen?
>>>
>>> On Fri, 5 Jun 2020 at 04:58, Christopher Lam
>
>>> wrote:
>>>
>>> > The balance sheet date option does not transfer because old
>balance
>>> sheet
>>> > uses "Balance Sheet Date" whereas upgraded one uses "End Date". I
>am not
>>> > sure it is practical to set up a compatibility pathway -- new
>balance
>>> sheet
>>> > can report multiple dates.
>>> >
>>> > On Fri, 5 Jun 2020, 7:27 am mark sattolo, 
>wrote:
>>> >
>>> > > Yes, that makes sense. I did some more digging around, and not
>all my
>>> > > custom column widths were changed, just those for any of the
>accounts
>>> > that
>>> > > I actually opened while using version 3.903. Which happened to
>be
>>> quite a
>>> > > few as I was testing various transactions, etc.
>>> > >
>>> > >
>>> > > *Mark Sattolo*
>>> > > *mh.sa...@gmail.com *
>>> > >
>>> > >
>>> > >
>>> > > On Thu, Jun 4, 2020 at 7:15 PM D.  wrote:
>>> > >
>>> > > > Mark,
>>> > > >
>>> > > > If that's true, I imagine it's a mistake. At least I hope so!
>I
>>> trust
>>> > the
>>> > > > devs will fix it, since I'd be pretty upset to have to reset
>column
>>> > > widths
>>> > > > on all my accounts...
>>> > > >
>>> > > > David
>>> > > >
>>> > > >
>>> > > >  Original Message 
>>> > > > From: mark sattolo 
>>> > > > Sent: Thu Jun 04 19:07:27 EDT 2020
>>> > > > To: gnucash-devel 
>>> > > > Subject: Re: [GNC-dev] Feedback on GnuCash 3.903
>>> > > >
>>> > > > Also fyi, I just noticed that version 3.903 overwrote all the
>custom
>>> > > column
>>> > > > width settings in my gcm file and changed all of them to a new
>>> default
>>> > > set
>>> > > > of widths, I presume the new defaults for Gnucash 4. These new
>>> default
>>> > > > widths give a very wide *description* column and every other
>column
>>> is
>>> > > very
>>> > > > narrow and especially for the *date*, *num* and 

Re: [GNC-dev] Feedback on GnuCash 3.903

[D. via gnucash-devel]

Mark, 

If that's true, I imagine it's a mistake. At least I hope so! I trust the devs 
will fix it, since I'd be pretty upset to have to reset column widths on all my 
accounts...

David


 Original Message 
From: mark sattolo 
Sent: Thu Jun 04 19:07:27 EDT 2020
To: gnucash-devel 
Subject: Re: [GNC-dev] Feedback on GnuCash 3.903

Also fyi, I just noticed that version 3.903 overwrote all the custom column
width settings in my gcm file and changed all of them to a new default set
of widths, I presume the new defaults for Gnucash 4. These new default
widths give a very wide *description* column and every other column is very
narrow and especially for the *date*, *num* and *transfer* columns, too
narrow to fit the text they contain. Again, I had to restore my backup gcm
file to restore all my custom settings.

So I guess since this will eventually be released as Gnucash version 4.xxx,
we are to expect breaking changes from the current version? And users will
be warned that they will be losing custom settings for column widths, saved
reports, etc when they switch over?


cheers,

*Mark Sattolo*
*mh.sa...@gmail.com *



On Thu, Jun 4, 2020 at 11:45 AM Christopher Lam 
wrote:

> Good luck. I've just verified that the old (3.x) balance-sheet date
> defaults to "end-of-accounting-period", so, the first few lines shouldn't
> be added.
>
> On Thu, 4 Jun 2020 at 15:41, mark sattolo  wrote:
>
>>
>> Thanks. I'll give it a try. I'll just update the source in my git folder
>> for tag 3.903 and rebuild if I can't figure out how to modify the flatpak.
>>
>> *Mark Sattolo*
>> *mh.sa...@gmail.com *
>> *(613) 447-5385*
>>
>>
>> On Thu, Jun 4, 2020 at 11:36 AM Christopher Lam <
>> christopher@gmail.com> wrote:
>>
>>> Hi Mark
>>>
>>> The reports for balance-sheet and income-statement were replaced with
>>> the multicolumn ones. See the release notes. This was described in devel a
>>> few weeks/months ago.
>>>
>>> Try the following patch which will reduce the discrepancy in the default
>>> options between old and new. You may be able to modify the patch from
>>> within the flatpak (but I'm not sure).
>>>
>>> modified   gnucash/report/reports/standard/balsheet-pnl.scm
>>> @@ -176,6 +176,9 @@ also show overall period profit & loss."))
>>>  (gnc:options-add-date-interval!
>>>   options gnc:pagename-general optname-startdate optname-enddate "c")
>>>
>>> +(gnc:option-set-default-value
>>> + (gnc:lookup-option options gnc:pagename-general optname-enddate)
>>> 'today)
>>> +
>>>  (add-option
>>>   (gnc:make-multichoice-callback-option
>>>gnc:pagename-general optname-period
>>> @@ -1107,6 +1110,22 @@ also show overall period profit & loss."))
>>> retained-earnings-fn
>>>   #:negate-amounts? #t)
>>>
>>> +(add-to-table multicol-table-right (_ "Liability and Equity")
>>> +  (append liability-accounts
>>> +  equity-accounts
>>> +  (if common-currency
>>> +  (list (vector (_ "Unrealized Gains")
>>> +unrealized-gain-fn))
>>> +  '())
>>> +  (if (null? income-expense)
>>> +  '()
>>> +  (list (vector (_ "Retained Earnings")
>>> +retained-earnings-fn
>>> +  #:negate-amounts? #t
>>> +  #:show-title? #f
>>> +  #:show-accounts? #f
>>> +  #:show-total? #t)
>>> +
>>>  (if (and common-currency show-rates?)
>>>  (add-to-table multicol-table-right (_ "Exchange Rates")
>>>asset-liability
>>>
>>> On Thu, 4 Jun 2020 at 15:18, mark sattolo  wrote:
>>>
 I am on Linux Mint 19.3 Cinnamon. I started using Gnc 3.903 yesterday
 morning. This is a version I built from git using tag '3.903' on June
 2. It
 built without any problems, so I assumed it was good, but now it occurs
 to
 me that all these problems may just be due to a problem with my build.
 But
 I thought i would report now anyway just in case there are general
 issues
 with this version. I was actually going to try a flatpak build of 3.903,
 but I couldn't tell from any of the build names in Gnucash flatpak repo
  which one is for version
 3.903.

 Anyway, everything seemed fine with 3.903 until I opened one of my saved
 reports. The appearance of the report was essentially unrecognizable. I
 only ever use my saved reports and their appearance hasn't changed for
 years, for any other Gnucash version (release or maint) until 3.903. So
 I
 went in to the report *options* to see if I could restore the layout to
 what i was 

Re: [GNC-dev] About 3.9 and reconciliation balances

[D. via gnucash-devel]

Christopher, 

Those are all very good points. I do think that the goals are laudable, and I 
think Dale's call for further analysis is a good approach. The question of what 
reconciliation is supposed to be, and what it's supposed to do (beyond the most 
rudimentary textbook descriptions) are not yet clearly defined in theoretical 
or practical ways, and they should be. 

The original developer model, I believe, was that reconciliation was a one 
time, forward moving progression that never deviates. You get a statement from 
your bank, check off those entries in your books that match, and if they 
balance, you are done until the next month, when you repeat the process with 
the next batch, etc. The need for a date of reconciliation is secondary in this 
model. 

Unfortunately, real life doesn't always match that, and when a fat finger 
problem arises, it becomes exceedingly difficult to track down the source. I've 
been known to revert more than a year's transactions and reconcile them all 
over again in some situations. So, a mechanism that would allow me to isolate 
that variation would be fabulous. 

But, I am also one who will reconcile an account for a year or more in one 
pass, simply because it's an account with one or two monthly transactions. So, 
that is a complication...

I will also add in here that the developers have muddied the waters on this 
whole situation with the decision to de-reconcile transactions when the user 
edits it later-- even if the changes are not related to an account's balances. 
In addition to the challenges these changes may cause to your reconcile model, 
they go straight to the question of what reconciliation means in the GnuCash 
realm. If reconciliation is an established regular process to compare against a 
statement always, then allowing an edit to change this status needs 
reevaluation. But if status is always malleable by later actions, then your 
model is doomed to failure, since you can't rely on the date of reconciliation 
to remain set to the actual statement date. 

The aqbanking issue (that imported transactions get the current date in 
reconciliation date) requires further consideration as well. 

Looking this over, it seems to me that your goals could only be achieved by 
adding a statement date data element to each transaction, which would tie that 
transaction to a specific statement. This field would have much more limited 
purpose and modification avenues. It would also help with generation of 
reconciliation reports. The existing reconciliation date field would then be 
freer to be considered a last-edited date, which might have benefits in other 
ways-- for example, one might be able to identify a transaction in a 
reconciliation set that has a significantly different last edited date. Or a 
user could be notified in the popup when they change the value of a reconciled 
split that they should revisit the mm-dd- reconciliation to be sure that 
their books are still accurate. 

David T.




 Original Message 
From: Christopher Lam 
Sent: Sat Apr 11 03:41:01 GMT+05:30 2020
Cc: gnucash-devel 
Subject: Re: [GNC-dev] About 3.9 and reconciliation balances

The "purpose" for the "fix" was to allow future features:

1. allow manual reconciliation of an account, using past reconciled_date
and relevant past ending_balance. If my "fix" were applied, it would serve
*me* very well:
(a) If an account, properly reconciled, had an errant split hiding
somewhere caused by fat-finger, I could reconcile from any past bank
statement, verify the balance is correct (or not) and narrow down to the
exact period that contains the errant split.
(b) This was also useful to fix cases where a past split was unreconciled
and needed to be rereconciled -- you could reconcile latest statement and
change the field 'n' to 'y' but its reconciled date would *not* be accurate
anymore because it'd be the latest statement; I meant to reset the split
reconciled_date to be the statement_date.

2. a natural extension of allowing past reconciliation is to store the list
of statement_date and ending_balance somewhere in the account metadata and
retrieve the list in reconcile_window. Hence
https://github.com/Gnucash/gnucash/pull/667 is born.
https://user-images.githubusercontent.com/1975870/77246245-5a1e2d80-6c1d-11ea-8fc3-b2ec34fdb5f9.png
is possible. In my testing, rereconciling past statements is nicely
upgraded.

3. a benefit of maintaining old reconciled_data is that we can now compare
an account's reconciled balances at periodic dates against the stored list,
and loudly report if a balance discrepancy is found. See
https://user-images.githubusercontent.com/1975870/78035104-2c8d5e80-7358-11ea-95bc-feba7f9f2bba.png
-- note the first two lines show reconciliation and account balances match;
the third section show unequal balances and show the relevant splits which
contain an extra one.

So, (1) and (2) are not possible -- rereconciling past statement cannot
currently take 

Re: [GNC-dev] About 3.9 and reconciliation balances

[D. via gnucash-devel]

Christopher, 

I understand your frustration at trying to help and getting a negative 
response. In trying to fix one problem, you have unwittingly waded into a 
bigger one. 

Your message raises a couple of points. First, this rollback need not be 
forever. It could wait until such time as the reconcile date issues can be more 
effectively addressed-- for example, by creating an interface to allow users to 
view or correct them. Your own advice to use the reconciliation report to track 
down the errors might point a way toward such a solution. 

Second, your changes have made a set of books that were completely functional 
in earlier versions no longer functional-- all without any changes to the 
underlying data. I have significant problems with that, and I can't believe 
that you would even suggest arbitrarily changing data in a user's books without 
considering ways to allow the user to make those fixes consciously, themselves. 

I've mentioned that you've done this before with the reports; I suggest you 
reconsider your approach to development of Gnucash tools. Screwing up 
reconciliation and then looking for a slap dash post hoc fix is not the way to 
win over users. 

David T.


 Original Message 
From: Christopher Lam 
Sent: Thu Apr 09 12:55:18 GMT+05:30 2020
Cc: gnucash-devel 
Subject: Re: [GNC-dev] About 3.9 and reconciliation balances

Regarding reverting:

It is too difficult to create a UI to modify reconciled dates. Options to
fix this are:

1. roll back this change and tolerate the invalid data. This means any
progress on that matter is hindered forever.

2. allow this change depending on a user-selectable book property "Use
strict reconcile date balances".
Pros: This means the book can be read/written by any recent version. See
"Use split action for num" as a similar example.
Cons: The toggled property can be a confusing option for new users.

3. allow this change depending on a non-user-selectable book feature "Use
strict reconcile date balances".
Pros: This feature can be set by a menu item. It triggers one-time
verification of all reconciled dates, instructing users to
correct/re-reconcile previous reconciled-dates, and sets the book feature
if all dates seem correct.
Cons: This means the book can only be read by 3.10 onwards.

On Thu, 9 Apr 2020, 11:29 am Christopher Lam, 
wrote:

> Thank you David.
>
> Further work for tighter safeguards is planned in
> https://github.com/Gnucash/gnucash/pull/685 -- no scrubbing is currently
> on the table but a warning during reconciliation if future splits are
> detected.
>
> On Thu, 9 Apr 2020, 9:59 am David Cousens, 
> wrote:
>
>> I am now happy that there is no problem with the starting balance
>> calculation
>> in 3.9  and the problem was caused by a previously undetected finger
>> problem
>> on my part  and withdraw my previous qualms about retaining it for the
>> future.
>>
>> I still think it is excessive to restrict the reconciliation date entry in
>> any way but agree that a warning should be displayed if either a statment
>> date in advance of "today" is entered, perhaps with the option for the
>> user
>> to confirm that they either want to retain the advance date or reenter it
>> in
>> a popup dialog.
>>
>> Also agree with a warning if any reconciled transactions with reconcile
>> dates  in advance of today are detected in the file. I am less sure about
>> assigning them to an arbitrary past date however.
>>
>> If a procedure for correcting them is developed it might be helpful if it
>> could display data for transactiions with reconciled splits which have the
>> advance date. The information that I found most useful to determine when I
>> made the error were the transaction date posted and the transaction date
>> entered into GnuCash and the reconciliation date and the account name or
>> at
>> least the account guid to confirm that all the affected splits are to a
>> single account. This was particularlyuseful to me because i append an "_R"
>> to statement pdf files I have reconciled and the file modified time allows
>> me to determine the date I did a recociliation. In future I will append
>> "_Rmmdd" so i don't have to look up the modified times for the files
>> as
>> well.
>>
>> Bug797668 is now marked as resolved
>>
>>
>>
>> -
>> 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
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] About 3.9 and reconciliation balances

[D. via gnucash-devel]

Christopher, 

I have to admit to some trepidation at having something as significant to my 
books as reconciliation suddenly changed based on data elements that aren't 
visible in the GUI. Are you sure the solution is better than the problem? 

I'm also concerned at the fact that (as with some other reports you've changed 
in the past) you are changing GnuCash behaviors without considering their 
effects on end users, and then waiting for the outcry from users to enact 
fixes. That is poor planning on your part, and has significant effect on the 
user base. 

Perhaps you should revert this change for the time being, until such time as 
you figure out a solution that works for the user base. For example, give the 
user an interface that allows them to see and fix the kinds of errors you've 
already identified. 

As for your proposed safeguards, option 2 should better be implemented by 
giving the user a listing of spurious reconciled txns, and giving them some 
interface to set a proper date (or a better one) on a group or individual 
basis, rather than arbitrarily creating a date that will cause the user to 
question the quality of their data sometime down the road.  

David T.


 Original Message 
From: Christopher Lam 
Sent: Tue Apr 07 13:00:55 GMT+05:30 2020
To: gnucash-devel 
Subject: [GNC-dev] About 3.9 and reconciliation balances

Release 3.9 comes with a new method for calculating reconciliation starting
balances.

Previously, the account reconciled balance was considered the starting
balance. This includes any splits previously reconciled with an invalid
(e.g. future) reconciliation statement date.

From 3.9 onwards, the starting balance is calculated by adding all account
splits whose *previous *reconciled date the *current* reconciliation date.
This means any past reconciliation with an invalid (ie future) reconciled
date would be ignored. The benefit is to allow re-reconciliation of a past
statement.

So, anyone with difficulties reconciling an account with 3.9 onwards should
check the account Reconciliation Report, Start Date = today, End Date =
31/12/ to seek these splits. To fix it manually, you can unreconcile
them and re-reconcile with any past date or today. Or modify the XML/SQL to
fix these dates.

To prevent future issues there are several safeguards being planned for
3.10:

1. any reconciliation must have a statement date of TODAY + 1MONTH. This
allows some leeway for users who wish to reconcile in advance, yet
disallows reconciliation too far ahead.

2. a datafile with splits with reconciled_date in the future *may *be
repaired; e.g. if reconciled_date > 1 month from today, then it is
evidently an error and can be changed to an arbitrary old date eg 1/1/1970.
This will allow them to be counted when calculating modern reconciled
balances.

I think 1 is acceptable. Any particular votes for 2?
___
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] alphavantage time out fix not obvious

[D via gnucash-devel]

Legitimate questions deserve legitimate answers.

On December 2, 2019, at 10:14 PM, David Carlson  
wrote:

Please do not feed the animals


On Mon, Dec 2, 2019 at 6:30 AM D via gnucash-devel  
wrote:

This was discussed in the groups--for finance::quote 
(https://sourceforge.net/p/finance-quote/mailman/message/36277551/) I believe 
there may have been a couple of cross posted messages here, though.

This is not a bug for Gnucash, so probably shouldn't file one against Gnucash. 
I don't know whether the fixes were integrated into F::Q or not.

David

On December 2, 2019, at 1:17 PM, Wm via gnucash-devel 
 wrote:

I can't find a bug and fix in the list for the alphavantage time out 
problem.

It was certainly discussed here.

Do I have to make a bug for it or hand roll again?

-- 
Wm

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



-- 

David Carlson

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

Re: [GNC-dev] alphavantage time out fix not obvious

[D via gnucash-devel]

This was discussed in the groups--for finance::quote 
(https://sourceforge.net/p/finance-quote/mailman/message/36277551/) I believe 
there may have been a couple of cross posted messages here, though.

This is not a bug for Gnucash, so probably shouldn't file one against Gnucash. 
I don't know whether the fixes were integrated into F::Q or not.

David

On December 2, 2019, at 1:17 PM, Wm via gnucash-devel 
 wrote:

I can't find a bug and fix in the list for the alphavantage time out 
problem.

It was certainly discussed here.

Do I have to make a bug for it or hand roll again?

-- 
Wm

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

Re: [GNC-dev] Mouse usage in Gnucash

[D via gnucash-devel]

On October 12, 2019, at 3:45 AM, John Ralls  wrote:

>
>> On Oct 10, 2019, at 10:26 PM, David Cousens  wrote:
>> 
>> Do we by any chance have some sort of standard description of mouse usage in
>> GNuCash on the various OS. 
>> 
>> I am updating documentation. Docbooks has tags for description of mouse
>> operations.  With configurable mouses for LH or RH operation terms like Left
>> Click and Right Click start to become ambiguous. DocBooks has tags for
>> . In a review of some recent changes Frank suggested using
>> Button1, Button2 and Button 3 rather than Left, Middle and Right to avoid
>> the LH/RH mouse conundrum.  I haven't been able to find anything in the
>> documentation re input devices but I could have missed it
>> 
>> Two of my mice have 6 buttons and two scroll wheels (basic config is a 2
>> button + central scroll/button) and  another only has 2 buttons and a single
>> scroll wheel/button. Linux Mint can configure that for LH operation,
>> emulation of a centre button by pressing both buttons together, scrolling
>> reversal and double click timeout and I presume most OSs will have something
>> similar. Then we go to Macs and we have single buttons and magic mice to
>> contend with.  Then there are tablets and touchpads and gestures.  GTK3
>> seems to support a wide range
>> https://developer.gnome.org/gtk3/stable/chap-input-handling.html and does
>> interpret the scroll wheel appropriately on my mice but the wheel button
>> inserts "another" each time it is pressed while editing a transaction in a
>> register - not too useful.
>> 
>> It is clearly far too onerous to describe all possible mice/input
>> variations.
>> 
>> My own preference would to perhaps settle on a fairly common 2 button RH
>> basic mouse and keyboard configuration and describe operations in terms of
>> that. Perhaps then offer in a wiki section some translations from this
>> configuration to other configurations like track pads that could be
>> populated by users. I think Left (Centre) Right  for a RH mouse is likely to
>> be far less confusing to translate than a "Button1 Button2, Button3  where
>> it is totally ambiguous whether the mouse is LH RH or upside down.
>> 
>David,
>The middle-button behavior on Linux is an X-Windows thing: The right button 
>begins a selection, the left button completes the selection, and the middle 
>button pastes the selection. I don't know if Wayland has that behavior as 
>well. Gtk has a GdkSelection class to try to provide it on other Ones but it 
>was implemented only partly on Windows and not at all on MacOS. It's been 
>deprecated for some time.
>If you don't like "left click" or "click button 1", how about "primary click" 
>and "secondary click"? You could even say "primary click/tap" to include the 
>touchpad users.
>I don't think that it's particularly useful for our documentation to try to 
>teach users the basics of using their computers, and explaining everything at 
>that level quickly gets tiresome for the majority of users who know how to 
>click a button, select some text, or open a context menu.
>Regards,
>John Ralls
>___
>gnucash-devel mailing list
>gnucash-devel@gnucash.org
>https://lists.gnucash.org/mailman/listinfo/gnucash-devel

+1 to John's comments.

I think it best to focus on the task, rather than the specific mechanics.

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

Re: [GNC-dev] Find Transfers feature

[D via gnucash-devel]

Rob,

Welcome to Gnucash!

When you "label" your transfer Education:Books, in Gnucash you are putting it 
into a separate *account* named that. This is the fundamental difference 
between Quicken and Gnucash: Gnucash is a full double entry software package 
which uses accounts in place of categories. Reading up on this will help you 
greatly--the Gnucash Guide has some explanations, and there is more online.

So, to locate all those transactions*, just open** the Education:Books account. 
They will all be there. 

David

* Of course, there is a search option, but it's provably not needed here.
** There are several ways to accomplish this. One is to double click the 
account in the chart of accounts. Another is to click the Jump button while a 
transaction to this account is highlighted.

On July 16, 2019, at 6:29 AM, Rob Koch  wrote:

I'm new to GnuCash and moving over from Quicken. Some things requires a
learning curve and this might be one of those. Is there a find Transfers
functionality somewhere? For example, we'd have a transaction with Transfer
labeled as "Education:Books", however not sure how we can Find transactions
by keyword "Education".

Thanks!
___
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] Release Schedule

[D via gnucash-devel]

On May 28, 2019, at 8:06 PM, Derek Atkins  wrote:

>D via gnucash-devel  writes:
>> A custom report, as Christopher says, is a scm file. In order for it
>> to run, you will have made an entry in config.user to explicitly load
>> your file.
>Actually, a custom .scm file could also be installed into the
>standard-reports folder and will be automatically loaded.  But it is
>still a custom report and will need to be updated when the API changes.

Well, yes, of course, but anyone who does this should be pretty clear about 
their file being a custom report, since it will have to be re-copied at every 
upgrade. The standard advice to most users is to leave the program tree intact, 
and use the config.user method.


>> David
>-derek
>-- 
>   Derek Atkins 617-623-3745
>   de...@ihtfp.com www.ihtfp.com
>   Computer and Internet Security Consultant
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Release Schedule

[D via gnucash-devel]

Derek,

On May 28, 2019, at 8:05 PM, Derek Atkins  wrote:

>Wm via gnucash-devel  writes:

 

>> for example, what if someone is depending on a perceived fault in the
>> current reporting system? <-- I don't know if I am doing this but I
>> might be.
>THIS could be an issue.  One person's bug is another person's feature.
>So yes, it is certainly possible that someone is depending upon the
>current behavior and might be put out if that behavior changes. 

In fact, this already HAS happened with recent changes to transaction.scm. 
Changes to the settings regarding inclusion of transaction detail got changed, 
forcing me to go through every saved report that I had that used the 
transaction report as its basis (by the way, there are numerous other standard 
reports that behind the scenes are based on the transaction report). It was 
quite a surprise, and there was no warning or guidance given ahead of time.

I ultimately was able to work out the problem and its solution, but it was 
quite frustrating at the time.

David

>-derek
>-- 
>   Derek Atkins 617-623-3745
>   de...@ihtfp.com www.ihtfp.com
>   Computer and Internet Security Consultant
>___
>gnucash-devel mailing list
>gnucash-devel@gnucash.org
>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] Release Schedule

[D via gnucash-devel]

Wm, 

To amplify, saved-reports-x.x contains saved options settings for standard 
reports, and not actual custom reports..

A custom report, as Christopher says, is a scm file. In order for it to run, 
you will have made an entry in config.user to explicitly load your file.

David

On May 26, 2019, at 4:24 AM, Christopher Lam  wrote:

Basically anyone who runs a custom .scm file.
Many function names are being deprecated; they are not used in main code
anymore but custom .scm files may call them, and will error out after
removing these functions.

On Sat, 25 May 2019 at 21:40, Wm via gnucash-devel <
gnucash-devel@gnucash.org> wrote:

> On 24/05/2019 04:07, Christopher Lam wrote:
> > Hi John
> > My plans for 4.0 will be
> > - remove *all* deprecated exported functions and deprecated code paths
> > - enable book-accounting-period preference
> >
> > I'd urge anyone with custom reports will observe the console or
> tracefile,
> > and watch for any scheme deprecation warnings while running latest
> versions
> > of GnuCash -- old functions are due a major cleanup. If there are, please
> > let us know via devel or bugzilla (and attach custom report).
>
> How are you defining a custom report, Chris?
>
> Do you mean anything anyone has in saved-reports-2.8 or similar?
>
> If so that is definitely non-trivial.
>
> --
> Wm
>
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Unable to compile Docs

[D via gnucash-devel]

I thought that those tools were only need to create the pdf and mobi versions.

On May 8, 2019, at 5:43 PM, John Ralls  wrote:



> On May 7, 2019, at 9:25 PM, Stephen M. Butler  wrote:
> 
> How do I go about getting the Fontbox jar(s) referenced  below. 
> Apparently I can't compile the docs without this.
> 

Does
 sudo apt-get install libfontbox-java
not work?

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] Dormant Bugzilla Accounts

[D via gnucash-devel]

Yeah. As I mentioned at the time, my primary concern was to make the wiki 
reflect the status quo. It's all good.

David

On March 17, 2019, at 2:58 AM, Wm via gnucash-devel  
wrote:

On 05/02/2019 15:55, Derek Atkins wrote:
> All accounts that touched any GnuCash bug were migrated over.  The ONLY
> user data migrated were email address and full name.  The user account
> passwords were NOT migrated because password data is not accessible (which
> is a GOOD THING).  So all those accounts are, technically, in a dormant
> state.  If those users would like to access them then they will need to
> perform a password reset on the account.
> 
> Removing accounts is... challenging.  The database requires them to remain
> in order to maintain proper history.
> 
> Is there a problem with keeping the accounts around?

I'm OK with Derek's answer, David T.  Are you?

-- 
Wm

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

Re: [GNC-dev] tb, gnc or me? my trial balance is wrong and I think it is gnc not me

[D via gnucash-devel]

Ok. I'll preface my comments with the note that every time I try to understand 
how the trial balance report works, someone on the list points out how 
misguided my understanding is

That being said, I don't understand how a trial balance of completed 
transactional history could change value based on a change in price history 
settings. The euros I bought last week might be worth more this week, but I'd 
expect the report to be based on what was real, versus the imaginary value 
those euros have gained or lost since then.

David T.

On February 10, 2019, at 2:40 AM, David Carlson  
wrote:

Following up on my last email, in version 2.6.17 the Trial Balance report does 
default to nearest in time as the default valuation procedure.   I don't know 
what happens in 3.4.


David Carlson


On Sat, Feb 9, 2019 at 9:05 AM David Carlson  
wrote:

Now if there is an exchange rate entry for 12-19 and 12-16 but not for 12-18 or 
12-17-2017 and the report is using nearest in time, that could cause what you 
are seeing.




On Sat, Feb 9, 2019 at 7:04 AM D via gnucash-devel  
wrote:

That sounds to me like it's using a different exchange rate from one day to 
another, and I'd agree with your assessment in that case. I would have thought 
that the exchange rate in the transaction would be used.

Mind you, I can't wrap my head around the subtleties that seem to apply on this 
report.

David

On February 9, 2019, at 5:56 PM, Wm via gnucash-devel 
 wrote:

On 09/02/2019 07:00, Wm via gnucash-devel wrote:
> Background: My gnc TB has been wrong for years.  This hasn't been a 
> problem for me because I can do my own TB in sql and satisfy myself all 
> is relatively well with my accounts.  Over the last week or so I decided 
> to try again and I think the gnc TB report is b0rked.

OK, have a think about this.

Having deleted the tx previously mentioned.

If I run a TB report to 2017-12-17 it balances.

If I run a TB report to 2017-12-18 it is out by .01

Problem?  There are no tx on 2017-12-18

The ordinary use of a TB is to help find accounting errors.  If the 
report introduces errors I say it is not fit to be used.

https://bugs.gnucash.org/show_bug.cgi?id=797097

-- 
Wm

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

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

Re: [GNC-dev] tb, gnc or me? my trial balance is wrong and I think it is gnc not me

[D via gnucash-devel]

That sounds to me like it's using a different exchange rate from one day to 
another, and I'd agree with your assessment in that case. I would have thought 
that the exchange rate in the transaction would be used.

Mind you, I can't wrap my head around the subtleties that seem to apply on this 
report.

David

On February 9, 2019, at 5:56 PM, Wm via gnucash-devel 
 wrote:

On 09/02/2019 07:00, Wm via gnucash-devel wrote:
> Background: My gnc TB has been wrong for years.  This hasn't been a 
> problem for me because I can do my own TB in sql and satisfy myself all 
> is relatively well with my accounts.  Over the last week or so I decided 
> to try again and I think the gnc TB report is b0rked.

OK, have a think about this.

Having deleted the tx previously mentioned.

If I run a TB report to 2017-12-17 it balances.

If I run a TB report to 2017-12-18 it is out by .01

Problem?  There are no tx on 2017-12-18

The ordinary use of a TB is to help find accounting errors.  If the 
report introduces errors I say it is not fit to be used.

https://bugs.gnucash.org/show_bug.cgi?id=797097

-- 
Wm

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

Re: [GNC-dev] Dormant Bugzilla Accounts

[D via gnucash-devel]

No. There's no problem. I just want the wiki page to reflect what actual 
practice is. I wasn't thinking that the accounts would be removed.

David

On February 5, 2019, at 9:25 PM, Derek Atkins  wrote:

Hi,

All accounts that touched any GnuCash bug were migrated over.  The ONLY
user data migrated were email address and full name.  The user account
passwords were NOT migrated because password data is not accessible (which
is a GOOD THING).  So all those accounts are, technically, in a dormant
state.  If those users would like to access them then they will need to
perform a password reset on the account.

Removing accounts is... challenging.  The database requires them to remain
in order to maintain proper history.

Is there a problem with keeping the accounts around?

-derek

On Tue, February 5, 2019 10:45 am, David T. via gnucash-devel wrote:
> 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
>


-- 
   Derek Atkins 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant

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

Re: [GNC-dev] gnucash.org logins

[D via gnucash-devel]

Well, yes. Like they were! But, now that they're not...

On February 3, 2019, at 8:38 PM, Derek Atkins  wrote:

David,

On Sun, February 3, 2019 1:51 am, David T. via gnucash-devel wrote:
> 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?

They are completely separate systems using completely separate databases,
so I have no idea how you could merry their user databases.  Theoretically
they could be running on completely separate hardware, too.

-derek

> David T.


-- 
   Derek Atkins 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant

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

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

[D via gnucash-devel]

Alex,

Thanks for the clarification. My example was unfortunate; my actual experience 
was with income accounts--precisely for dividend income accounts, for the 
reason you indicated. Still greyed out.

David

On January 22, 2019, at 3:57 AM, Alex Aycinena  wrote:

David,


-- Forwarded message --
From: "David T." 
To: gnucash-devel 
Cc: 
Bcc: 
Date: Mon, 21 Jan 2019 19:11:59 +0530
Subject: [GNC-dev] Tax Report Options: Payer Name Source Option
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.

I checked with both 3.4 and 2.6.21 and it seems to work correctly.


The feature is not intended to work with all TXF Categories (for example, 
expenses:Charity).


It is intended for things like Interest and Dividends where you may have, say 
dividends, credited to a sub-account of the brokerage (e.g., the security 
sub-account, say, IBM) but Schedule B wants the total dividends shown by the 
parent not the payer (e.g., the broker, say, Morgan Stanley who sends you your 
1099-DIV). This allows the report to collect these all together for you. (For 
it to work properly, all the sub-accounts need to be directly under the parent, 
as is pointed out in the documentation, I believe).


Check under Income with Dividends to see if it not greyed out.


Regards,


Alex


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

[D via gnucash-devel]

Nope. I get this error every time, even after running GC3.4 numerous times. 

Since I've given up on retrieving stock quotes anyhow, and I've given up on 
looking at what my portfolio is doing lately (ignorance may not be bliss, but 
it cuts down on the stress), I guess I'll just let this one slide.

David

On January 13, 2019, at 7:36 AM, John Ralls  wrote:

Huh. Oh well.

Anyway, I just tried it (with both Gnucash.app and Finance Quote Update.app in 
/Applications) and it worked fine after I got past all of the noise about it 
not being signed and being downloaded from the internet and all. MacOS 10.14.3 
Beta. I renamed my development folder to make sure that it wasn’t finding 
gnc-fq-update there somehow.

I wonder if the problem is that you hadn’t run GnuCash yet and Gatekeeper is 
blocking access until it’s checked it out.

Regards,
John Ralls


> On Jan 12, 2019, at 11:29 AM, David T.  wrote:
> 
> 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] Reports -- Cleanup

[D via gnucash-devel]

If the reports are getting some attention now, I'll note that there are a 
number of minor bugs in Bugzilla regarding reports that could use attention. I 
put in 773168, 773169, 773198, 773199, and 773200, which are all pretty 
superficial, IMHO, and might be despatched by someone with any skill set all (I 
am unfortunately not that person).

David

On January 10, 2019, at 7:33 AM, Christopher Lam  
wrote:

Thanks for the interest in reports.

I'd like to take opportunity to explain current state of code.

Examples of duplication:
- html-barchart, html-linechart, html-scatter, html-pie have a lot of
duplicated code; there's a pending work for merging the charting
infrastructure into a universal one, and also upgrading from jqplot to
chartjs (responsive and animated). this is not frozen yet.

Pending work
- transaction.scm may receive a CSV export function. see last commit at
https://github.com/christopherlam/gnucash/commits/maint-export-csv/gnucash/report/standard-reports/transaction.scm
for anyone wishing to experiment.
- multicolumn balsheet is still pending and requires cleanup

Future work
- if reconciliation report gets a lot of attention and refinements it may
be spun off into a separate file like income-gst-statement.scm.
- a header for reconciliation report is not difficult, but the
determination of 'starting and ending balance' for the header is
*difficult* - I'd like to mimic the formal reconciliation tool but I'm not
sure how it calculates the balances.
- organising removal of unused old code

On Thu, 10 Jan 2019 at 05:53, David Cousens 
wrote:

> Steve,
>
> I would like to add to Adrien's concerns. The reports are for more than an
> accountant or a bookkeeper. Many people using GnuCash are managing personal
> finances, investments, not for profits, small businesses etc and while they
> may need the basic standard accounting reports (balance sheet, income
> statement, transaction, cash flow etc.), they also need to have reports
> which give them information which is more related to managing those
> activities and sometimes they also need to dig deeper into the information.
>
> We need to remember that the options that are there have grown out of user
> requests for reports outside the basic reports and/or the need for more or
> different information.
>
> An additional concern is perhaps that many users have produced customized
> reports based on the standardized reports. I don't know to what extent
> these
> are standalone, but if changes in the underlying report affect the derived
> reports then we will hear screams and gnashing of teeth from the user base.
>
> GnuCash is also widely used in many jurisdictions and reporting
> requirements
> and standards and practice can vary in more than just language and date
> formats. Fortunately there is a strong international push for financial
> reporting standards (IFRS) led by the IASB. The FASB in the US is moving
> the
> GAAP towards agreement/compliance with the IFRS, and is a major participant
> in the IASB, but has not yet adopted the IFRS as the basis of its internal
> standards. Many European countries and others adopt the IFRS standards with
> local variation on top to meet legislative requirements in corporate law,
> consumer legislation etc as well as local practices.
>
> https://www.ifrs.org/use-around-the-world/use-of-ifrs-standards-by-jurisdiction/#analysis
> has a comlete breakdown of the current position.
>
> 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
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Unwritten Wiki Conventions

[D via gnucash-devel]

Frank,

On December 24, 2018, at 12:19 AM, "Frank H. Ellenberger" 
 wrote:

>David,
>thanks for your question. Because it affects unwritten historical
>conventions, I cc the list.
>https://code.gnucash.org/wiki/Wiki_Conventions
>Am 23.12.18 um 08:04 schrieb David T.:
>> Frank,
>> I just decided to look into this change to the wiki you made a couple of 
>> weeks ago. 
>> It appears that you renamed the "PAS 76" page to "GB/PAS_76"
>> I can't see why you did this. Is there more than one "PAS 76" that might 
>> confuse gnucash users?
>Probably not users, but wiki maintainers:
>Its original name was Pas_76 and several times, I opened it with the
>intention "Strange name, can we delete it?".
>So I changed it to uppercase letters to denote, it is the abbreviation
>of a regulation (form, law, ...). Further I prefixed it with GB because
>it only concerns users in GB.

Rather than add another code to an obscure code, I think you should have gone 
the opposite direction, and named this page something like "Compliance with UK 
Tax Authorities". This is especially relevant, since the page appears to 
approach the topic in this manner, and the only link to it is the FAQ question 
about tax compliance for the UK.

Would you please do that, since I am as yet unsure of wiki conventions in this 
regard? Then no one will have to wonder what "PAS 76" is. (of course, you could 
always have added an entry to the glossary-- oh, never mind, I just did)

>> That would, in my opinion, have been the only reason to make this change. 
>> Given that the only link to this page was the one from the FAQ, this change 
>> seems really fussy. 
>> And is it wise to use a forward slash in a wiki page name? That just seems 
>> destined for trouble. 
>The slash divides a prefix from the intrinsic page name. This way you
>can have a main page with subpages. A technical good example of this
>technic was the draft of the guide with a template, common index, ...
>In general in more encyclopedic wikis its use is disregarded (you need
>several tools for both, coding and documenting. Which should become the
>main page?)

I guess I wasn't clear; using a slash seems problematic in a wiki page title 
since the forward slash is used in URLs. Won't that confuse browsers?

David

>There is one exception in our wiki:
>Language and region specific pages got prefixed with the language code
>(De, Es, Pt ...) or region code (GB, NO ...). Ideally they should also
>have a respective category tag.
>The reason is historical: When we imported the first enlish and german
>pages from linixwiki.de, nobody of us knew about mediawikis language
>extensions.
>When Derek and I have some spare time, we will move languages in
>specific domains.
>> David
>HTH
>Frank
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] [GNC] Accounts do not appear in budget

[D via gnucash-devel]

Another option would be for someone (other than myself, because I never have 
used, liked or understood the budgets module) to write some documentation for 
the budgets.

A third option, even less likely, is for someone who cares to go in and try and 
make sense of the budget features, and rewrite the functionality in a way that 
people can understand and use. I say less likely because this area has been 
deficient for a long time without any interest in improving it developing 
anywhere.

A fourth option, more radical but based on the reality of number three, is to 
remove this module altogether, since it is neither being fixed nor improved. 
Keeping it around suggests to new users that it has any support behind it, 
which is not the case.I

David

On December 5, 2018, at 2:58 PM, Adrien Monteleone 
 wrote:

Another case of something recently being an issue all of a sudden...

Perhaps changing the default to include *all* accounts is in order.

Certainly I can see the use case of someone setting up GnuCash for the first 
time and one of the 1st items in their workflow being to create a budget before 
they enter any transactions. I would say that is more likely than someone using 
GnuCash for an entire year before diving into the budget module, which is the 
apparent assumption based on how it works.

Regards,
Adrien

> On Dec 5, 2018, at 3:24 AM, Adrien Monteleone 
>  wrote:
> 
> Do you have any transactions in those accounts yet?
> 
> If not, they won’t show up by default.
> 
> You can change this setting in View > Filter By... > Other > Show unused 
> accounts.
> 
> Regards,
> Adrien
> 
>> On Dec 4, 2018, at 3:32 PM, Sadhna True  wrote:
>> 
>> I am a new Gnucash user, and I am using the software to manage personal 
>> finances. I have previously used QuickBooks to do bookkeeping for a small 
>> company.
>> 
>> In Gnucash, I created my accounts. When I create a new budget, a new tab 
>> opens, but none of the accounts I created appear in the budget. What am I 
>> doing wrong?
>> ___
>> 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
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Wiki page removal

[D via gnucash-devel]

Ok. So, I'll ask someone to move "MacOSX/Quartz" to "MacOS/Quartz" then.

David

On December 4, 2018, at 12:35 AM, Geert Janssens  
wrote:

Op maandag 3 december 2018 18:18:03 CET schreef D via gnucash-devel:
> It would seem that you all have the mistaken belief that I have powers that
> have not been granted to me --specifically, I do not have any option to
> move a wiki page, thus I cannot 'preserve the talk pages' in any way,
> shape, or form.

Well, I wasn't sure of this, hence my suggestion. But as you don't have these 
rights, you can ask someone with rights to move or rename the page for you. It 
will be even less work for you :)

> 
> BTW, I'm not sure why it's suddenly a priority to change MacOSInstallation
> to MacOS_Installation. After all, everyone was plenty happy to stay with
> the outmoded MacOSXInstallation until I decided to do something about it.
> 
It was not a priority. But as we were changing the page title anyway it's 
nicer to have a more human readable one. I for sure am more comfortable with 
reading
"MacOS Installation" than "MacOSInstallation".

Wiki will accept both,  but it won't use the former unchanged in url's as 
spaces are known to be tricky. So wiki will always replace spaces with 
underscores when generating a url. That's what Frank was pointing out.

Regards,

Geert


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

Re: [GNC-dev] Wiki page removal

[D via gnucash-devel]

It would seem that you all have the mistaken belief that I have powers that 
have not been granted to me --specifically, I do not have any option to move a 
wiki page, thus I cannot 'preserve the talk pages' in any way, shape, or form.

BTW, I'm not sure why it's suddenly a priority to change MacOSInstallation to 
MacOS_Installation. After all, everyone was plenty happy to stay with the 
outmoded MacOSXInstallation until I decided to do something about it.

David

On December 3, 2018, at 10:34 PM, "Frank H. Ellenberger" 
 wrote:

While moving a page
* by default a redirect will be created and
* the talk page will move, too.

BTW, I have redone it and named it "MacOS Installation" which is better
readable. While Wiki links know to handle blanks and other nonASCII
chars, in other references you have to map them:
Space to underline, ...

~Frank

Am 03.12.18 um 14:41 schrieb Derek Atkins:
> I think the better option is to edit the page and leave it as a forward
> reference to the new page.  That way it wont brak existing links.
> 
> -derek
> 
> On Mon, December 3, 2018 7:26 am, Geert Janssens wrote:
>> I think the manual method is indeed available to you. I don't know if the
>> option to move a page is visible for you under the "More" menu. That's
>> both a
>> shorthand way of doing it which deals a bit better with page history and
>> related talk pages.
>>
>> Geert
>>
>> Op maandag 3 december 2018 13:06:36 CET schreef David T.:
>>> 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
>>
> 
> 

___
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] Gtk and themes

[D via gnucash-devel]

While it is true that many users on Gnucash lists bemoan the latest theme 
selections, I agree with Geert, John, and the blogger that the tendency is away 
from such individualization. I am reminded of the wonders of dot matrix 
printers way back when; there was an ecstatic enthusiasm for all the new font 
possibilities, and for a while, every document was a riot of different fonts. 
Eventually, most people decided to stick with just a few fonts and get on with 
life...

As for the article, I was more intrigued by the comment early on that designing 
user interfaces with css is more for the developer set than the user base. It 
seems like we haven't gotten that memo, despite the strong evidence of its 
accuracy. Expecting users to write css to change the appearance is doomed to 
failure.

David

On October 19, 2018, at 8:09 PM, cicko  wrote:

Geert Janssens-4 wrote
>> Well, I'm fairly confident that it is exactly the opposite. Just looking
>> at
>> trends in mobile apps tells me that clearly the users want to customize
>> the
>> apps to their preferences, mostly visual, rather than to have "more,
>> better
>> app" (whatever that means).
> 
> Interestingly I'm not aware of visual styling customizations in any of the 
> mobile apps I use. They all seem to use the system's theme(s). I don't
> find 
> options anywhere related to, hmm, I'd like a different font for this menu
> item 
> or hide the label for that button, and oh, can the spacing between these
> two 
> fields be reduced a bit ?

Right. But choosing a different theme is a kind of visual customization, no?
Not to mention the icon packs, custom emojis, and what not. That, of course,
depends on the apps you use but I'm talking about a huge deal where I read
"visually pleasing" and "easy customization" in the description and move on.


Geert Janssens-4 wrote
> The point I wanted to make by posting this article is really this:

I think I get your point and actually agree with it, along with the point
the guy was making in that article. But I'm a developer and I've noticed
that my view is quite different to that of an average user.

My point, on the other hand, would be - the users want customizations and
that won't change anytime soon. And you can confirm that simply by
considering the amount of questions on this list referring to fonts,
spacing, colors, sizes, icons, etc. 
Unfortunately.



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

Re: [GNC-dev] Documentation Build Oddity

[D via gnucash-devel]

Ok, ok. You win.

I surrender.

On September 14, 2018, at 11:57 AM, John Ralls  wrote:




On Sep 14, 2018, at 8:34 AM, Geert Janssens  wrote:


Op vrijdag 14 september 2018 17:13:44 CEST schreef John Ralls:

On Sep 14, 2018, at 7:38 AM, David T. via gnucash-devel  wrote:

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.

But in the case of HTML there’s a good reason for the inconsistency. You’re
heading into hobgoblin territory.

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

Sure you do, it’s just indirect via GitHub.com.


While true I doubt this is what Frank was referring to. As I understood he was 
referring to the directory structure where the nightly documentation builds 
are uploaded. And to make this upload easier the built docs are structured the 
way they are.

And yes, this may be slightly confusing after a first build. However I believe 
adding directories for pdf, epub and mobi will not do much to improve the 
documentation process. It would mean you have to navigate one level deeper 
each time to find the relevant derived files. As someone sensitive to rsi, I'm 
not looking forward to that.
I do think it keeps the main directory more tidy by grouping all html files in 
a subdirectory as it is now.


It was David T., not Frank, but no matter.


That repository is echoed to http://www.gnucash.org/docs/v3/. Since there’s no 
index.html except in http://www.gnucash.org/docs/v3/*/gnucash-guide/ one may 
browse the directory listings except those. As you say, it’s the same as the 
build results to simplify copying from the build directory to 
gnucash-htdocs-docs, but that’s scripted and user access to the docs is 
generally via http://www.gnucash.org/docs.phtml so the actual layout of either 
the build directory or the website docs folder could change without much 
impact... but frankly I don’t see any reason to change them.


Regards,

John Ralls


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

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

[D via gnucash-devel]

On September 14, 2018, at 1:59 AM, "Frank H. Ellenberger" 
 wrote:

>
>Am 14.09.18 um 03:55 schrieb 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. 
>which page?

https://wiki.gnucash.org/wiki/Documentation_Update_Instructions#Prepare_The_Build_Directory


>> 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;
>Such dependencies are usually in a specific README.dependencies or
>direct in the README[.md] file.
>> 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
>Strange, I had only to install a package xmlgraphics-fop, but Macos
>might behave different.
>Result of 'which fop' returns a usable path like "/usr/bin/fop"?I

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

>Hope this helps a few steps further.
>Frank

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

[D via gnucash-devel]

Hello,

Having raised yet another ruckus on the lists regarding documentation, I will 
back off altogether, and work to write documentation on the assistant as it is, 
taking care to balance the needs of the different user groups.

My only final comment is to note that it is unfortunate that this assistant is 
what all users see when they click File->New. Perhaps the idea of adding 
buttons on the first screen for Business and Personal setup (along with a 
modification in sequencing for the latter option) could be implemented with 
minor developer effort?

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

Re: [GNC-dev] Git Questions With Documentation

[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

On September 13, 2018, at 2:28 AM, "Frank H. Ellenberger" 
 wrote:

David,

Am 13.09.2018 um 02:46 schrieb David T. via gnucash-devel:
> 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.

In such a case you can push it in your fork and we can view it. It seems
you removed it, while Tried to reviw it.

I suspect, you forgot 'git add' for importing.xml or whatever chapter2
now should contain.

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

[D via gnucash-devel]

David,

On September 13, 2018, at 1:31 AM, David Cousens  
wrote:

>
>> 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.
>David,
>You would have to declare new entities for the files you wished to include in 
>ch-basics within ch-basics put &name> statements in ch-basics 

What I did was leave the entity definitions for ch_accts.xml and ch_txns.xml in 
gnucash-guide.xml, relabel them as chapter2a and chapter2b. I added entity 
statements for ch_importing.xml and ch_configuring.xml as chapter3 and 
chapter4. I added the new entities in the main compiling section of 
gnucash-guide.xml around line 497 or so.


>then remove the  and  tags and contents at the chapter level 
>in each of

Did this as well (actually, I changed the chapter tags till sect1, and added 
one to each successive sect, which is pretty much the same thing). Spent an 
hour trying to locate any errors in tagging that might have resulted in the 
parsing error, decided to try the monolithic file approach. When I pasted the 
sections into one file, xmllint stopped throwing errors (meaning that the 
tagging was actually correct).

>those files as well as removing the @entity statements and any !Entity 
>definitions for the chapters you removed from
>gnucash-guide.xml. After removing the chapter and associated tags the included 
>files will also have to fit into the
>defined structure for a chapter as defined by 
>https://tdg.docbook.org/tdg/5.0/chapter.html. That error usually indicates
>a formatting problem with the tags in an included entity. Preceding error 
>messages usually definine exactly where. The
>altered files would of course have to be shifted from the Help directory to 
>the guide directory and references in the
>gnucash-help.xml removed
>For your info I recently made changes to the import matcher code( Bug796778 to 
>enable multiple selection of transactions
>and assignement of a single destination account to them). I was looking for 
>the appropriate place to document them in
>the transactions section of the help manual and discovered that the importing 
>had not been documented so I had nowhere
>to put the changes into. 
>I started to prepare a change to the Help manual -Transactions chapter 6 
>covering importing from OFX/QFX, CSV, and QIF 
>including the changes to the import matcher, which is nearly complete and 
>fitted in before the stub that is there for
>online actions. As yet I haven't raised a documentation bug about that
>If you haven't started writing the importing section, I could feed what I have 
>done so far to you for incorporation as

I am open to any modality on this. My fork of the documentation on github has a 
stub file for importing in the Guide. It currently has the text from Help on 
importing qif files, but will ideally include all the other pieces as well.

David T.

>you like. If the transactions chapter is going into the guide, it may be 
>better to wait until you have shifted it and
>then insert it into the new Guide at an appropriate place rather than pull it 
>into the current master.If I do that I
>think you would have to rebase to the current master to include my changes 
>before committing your own chnages.
>John ralls may be able to advise us as to the best strategy.
>David Cousens 
>> 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
>___
>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

[D via gnucash-devel]

Frank,

You raise significant points about the effect that this might have on 
translations.

How would it be if these changes occurred in the course of a piecemeal 
approach? In other words, if I or someone else were to essentially remove the 
text from one document, put it in the other, and add new text at the first, 
would that be better?

David

On September 9, 2018, at 6:21 AM, "Frank H. Ellenberger" 
 wrote:

Hi,

Am 08.09.2018 um 17:48 schrieb John Ralls:
>> On Sep 8, 2018, at 7:57 AM, David T. via gnucash-devel 
>>  wrote:
>>
>> 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.
> 
> I’ve no objection in principle.  Thorough preparation for such a rewrite 
> would also include a review of the mailing list archives and the wiki.

-: I18N: We will loose the current translations and probably frustrate
the last translators and loose their readers.

?: Usability: Will F1 or pressing the Help button still deliver the
right content? I know it is aslo now not always th case.

Historical note: we had a GUM in version 1 and I assume there were
reasons to break it in two parts.

> We should resolve the source-format question (Docbook/Asciidoc/Docx/Markdown) 
> before beginning actual writing.
> 
> It’s a pretty massive project, I think you’ll need to recruit a team.

You might also consider to choose a more recent license. But that would
mean, you must not copy

> Regards,
> John Ralls


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

Re: [GNC-dev] Documentation Version Display

[D via gnucash-devel]

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

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

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

[D via gnucash-devel]

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

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

David,


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


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


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


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


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


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


Regards,

John Ralls



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


Hmm.

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

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

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

David

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



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

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

Geert Janssens  writes:

[snip]

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

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

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

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

-derek


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

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


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

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

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



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

Re: [GNC-dev] Main WIki Page edit

[D via gnucash-devel]

Frank,

Thank you for implementing the changes.

WRT removing the references to the glossaries, it *was* my intention to remove 
them, for a few reasons. First, the glossaries are sections of either the Guide 
or of the wiki. Thus, like the FAQ and the Using Gnucash links, it doesn't 
merit top level mention. 

As I considered it further, it seemed to me that a glossary isn't really 
something that someone seeks out for itself; they will only seek it when they 
don't understand a term they find elsewhere. Thus, my suggestion that these 
terms, when used, should receive proper linking in the source. Moreover, given 
that the Guide is separately released and published, I felt that mention of the 
Guide Glossary in the wiki was truly superfluous--akin to making note that the 
Guide includes screenshots. Therefore, mention of the Guide Glossary was out.

As to the Wiki Glossary, I rather liked Adrien's suggestion that such mention 
might go with developer info later on the page. Since I wasn't focused on those 
other sections, I set aside that change, and then I later decided that inline 
citations would be the better solution. Thus, no more mention of that glossary 
from my corner.

On the subject of the different sources for information:
It may be advisable to put a note about differences between the documents. 
However, any discussion about the information on the wiki versus the 
documentation needs to be couched in terms that explain the differences 
clearly, fully, unambiguously, and without bias. IOW, the wiki might be more 
recent, but that information is more likely subject to change, since it may not 
be fully accurate. The Help and Guide have been edited for accuracy.

David

On August 20, 2018, at 10:38 AM, "Frank H. Ellenberger" 
 wrote:

Hi David,

I have applied it, but have 2 questions:
Was it intended to remove the reference to the glossary completely?
Should we somehow note, that in doubt the wiki might be more recent than
the official docs?

Regards
Frank

Am 20.08.2018 um 15:57 schrieb David T. via gnucash-devel:
> OK. I have looked over this issue with an eye to clarifying the text, and I 
> believe that the User Documentation section should be simplified. As 
> currently written, as you all have noted, the User Documentation section 
> includes different layers of content, presented at the same tier of coverage. 
> Thus, the Help and Tutorial are presented alongside two wiki pages and two 
> glossaries. That’s inconsistent. 
> 
> So, first up is to level things off. That means eliminating the separate 
> headings for the Glossaries, the FAQ and Using Gnucash, and changing the main 
> section to refer to the wiki at the same level as the Help and Tutorial. In 
> the interest of helping people in dire need, I choose to retain the 
> references to the FAQ and Using GnuCash pages, but as a descriptive list 
> under the wiki in general (I will note that I also changed the Getting Help 
> page to parallel this approach). As suggested, mention of the Glossaries 
> isn’t particularly appropriate here, so I remove it altogether. [FWIW, I 
> think the proper approach would be to make sure that all uses of special 
> terminology in the wiki and the documentation receive reference to their 
> glossary definitions, ideally as tool tips—but that solution is beyond my 
> ability]
> 
> I also don’t like “User Documentation” since we aren’t documenting users, so 
> I prefer “Documentation for Users”, which requires the following heading to 
> be changed to “Documentation for Developers”
> 
> Here is my final suggestion for the section in question:
> 
> === Documentation for Users ===
> GnuCash offers two major pieces of documentation: 
> * [http://www.gnucash.org/viewdoc.phtml?doc=help The Help Manual] - a quick 
> reference manual for specific tasks, and
> * [http://www.gnucash.org/viewdoc.phtml?doc=guide The Tutorial and Concepts 
> Guide] - an in-depth guide to the concepts. It is highly recommended to read 
> at least the first chapters of the guide.
> The [http://www.gnucash.org/docs.phtml Documentation page on the gnucash.org 
> ''website''] also contains these documents in
> * '''other languages:''' de, it, ja, pt; 
> * '''other formats:''' ''PDF'', ''ePub'' or ''mobi''; as well as
> * '''other releases:''' nightly (unstable),  previous and earlier stable 
> releases.
> The GnuCash wiki includes extensive information regarding all aspects of 
> GnuCash, contributed by the developers and users of GnuCash. Information in 
> the wiki covers a broad variety of topics, and includes detailed technical 
> information, as well as information that applies to specific use cases. Of 
> particular interest on the wiki are: 
> * The [[FAQ|GnuCash FAQ]], which contains a collection of frequently asked 
> questions about GnuCash, including administration, accounting, and glossary 
> questions, and
> * [[Using GnuCash]], which collects real life experiences using GnuCash. You 
> may find (user) solutions here that 

Re: [GNC-dev] Main WIki Page edit

[D via gnucash-devel]

The glossary entry has historically been included separately on this page. When 
I last suggested changes for the page, it didn't occur to me to remove that 
separate section and incorporate references to them (there are two glossaries: 
one in the Guide, and the one on the wiki, each with slightly didn't vintage) 
in other locations.

Incorporating these references into other sections makes sense to me. It 
simplifies the main page structure a little, and reflects the fact that the 
glossaries are part of the Guide and wiki, respectively.

I'll look into a rewrite, and send it in for adjustment in the next few days.

David T.

On August 18, 2018, at 7:15 AM, Adrien Monteleone 
 wrote:

In combination with making the T glossary sentence a part the Official 
documentation paragraph, I think the second sentence should be moved down to 
the Developer Documentation paragraph.

Also, the following line needs a number correction:

"The Documentation page on the gnucash.org website also contains ~~this~~ 
_these_ documents in”

I’d do either myself, but I see the main page is above my pay grade. (I’m sure 
for very good reason)

Regards,
Adrien

> On Aug 18, 2018, at 8:53 AM, John Ralls  wrote:
> 
> 
> 
>> On Aug 17, 2018, at 11:45 PM, David T. via gnucash-devel 
>>  wrote:
>> 
>> 
>> 
>>> On Aug 17, 2018, at 11:29 AM, Frank H. Ellenberger 
>>>  wrote:
>>> 
>>> Am 16.08.2018 um 20:37 schrieb David T. via gnucash-devel:
 Hello,
 
 I was reviewing the Wiki today to try to figure out where a page on the 
 SQL formats might get attached, and I noticed a change to the Glossary 
 section that makes for awkward English.
 
 As currently entered, the section reads:
 
 Above GnuCash Tutorial and Concepts Guide includes a comprehensive 
 Glossary: 
 [https://www.gnucash.org/docs/v2.6/C/gnucash-guide/gnc-gloss.html 
 Released] or [https://code.gnucash.org/docs/C/gnucash-guide/gnc-gloss.html 
 Maintainer] version.
 
 However, it used to say:
 
 The GnuCash Tutorial and Concepts Guide includes a comprehensive Glossary: 
 [https://www.gnucash.org/docs/v2.6/C/gnucash-guide/gnc-gloss.html 
 Released] or [https://code.gnucash.org/docs/C/gnucash-guide/gnc-gloss.html 
 Maintainer] version.
 
 I would like to ask that someone with edit permissions on the wiki home 
 page to please change the word “Above” back to “The” to make the section 
 read more idiomatically.
 
 David T.
>>> 
>>> IMHO it is also bad style to have:
>>> The Tutorial and Concepts Guide - an in-depth guide to the concepts.
>>> :
>>> The GnuCash Tutorial and Concepts Guide includes a comprehensive
>>> Glossary: Released or Maintainer version.
>>> 
>> 
>> We differ in our opinion here. I stand by my recommendation.
> 
> And you’re both right, it needs a more thorough rewrite to flow better. Since 
> the glossary isn’t a stand-alone document it shouldn’t have its own level-two 
> header. An additional sentence in the T paragraph under Official 
> Documentation would be better. On the other hand the wiki needs more 
> prominence, there’s a whole lot more information there than just the FAQ and 
> technical glossary.
> 
> 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] Wiki Home page

[D via gnucash-devel]

Adrien, John, Frank, and others,

Thank you all for your considered input and forbearance. In looking over the 
wiki-related threads I've generated in the last couple of days, I can clearly 
see both my petulance and pettiness on them, and I apologize.

Obviously, encouraging people to get involved is most important, and whether 
the verb used to describe this is "developing" or "improving" is not so 
important.

I apologize again for cluttering the list.

David T.

On August 18, 2018, at 7:03 AM, John Ralls  wrote:

The other application project I’m involved with, Gramps (a genealogical project 
manager) uses a wiki with restricted editing for its manual.

No, no one has ever suggested switching to a CMS for www.gnucash.org 
. I don’t think that there would be any payoff for the 
effort and it would stop us using git to manage revisions.

Regards,
John Ralls

> On Aug 18, 2018, at 4:57 AM, Adrien Monteleone 
>  wrote:
> 
> From a cursory look at other FOSS projects:
> 
> LibreOffice has an “Improve It” menu on their site, with an entry labeled 
> “Docs Team”. They utilize a wiki and printable WYSIWYG produced using LO 
> itself. (probably the lowest entry barriers of any project save for Mozilla)
> 
> GIMP has a “Participate” menu and then a link for “add Documentation” (but 
> that took me to the docs, not how to contribute. I had to go to their generic 
> developers page to find anything on contributing to the docs) It appears they 
> currently use DocBook XML/git but are looking to move to something else using 
> markdown.
> 
> Inkscape has “Contribute” “Learn” “Community” “Develop” menu entries on their 
> site. Strangely, how to help with documentation seems a bit hidden, but 
> apparently, that’s because it seems to be all via their website CMS. Details 
> info might be hidden behind their documentation mailing list they direct 
> everyone to, but I don’t see any page on what is involved in the doc process 
> itself.
> 
> Thunderbird & Firefox have a “Get Involved” link and then a simple 
> “Documentation” heading and a “Contributing to Documentation” subsection. 
> They utilize a wiki apparently exclusively. (with official help forums for 
> users instead of a mailing list which employs ’sticky’ articles people can 
> write - something I think GnuCash could benefit greatly from, especially just 
> for users.)
> 
> Gnome - has a “Get Involved” link, then a simple “Documentation” heading with 
> “Contribute to the documentation team” link. They seem to use Mallard, an XML 
> editor and Git.
> 
> Arch - yes, that Arch, uses a wiki. (integrated help is of course in the form 
> of man pages as part of their regular build system)
> 
> So perhaps taking a cue from that, a simple “Contributing to Documentation”, 
> “Help with Documentation” or a simple “Documentation” heading/link is just 
> fine. It did seem that those projects that used more complicated tools than 
> wiki/CMS hid their actual process behind several links or I had to go to the 
> developer section to find anything. I’m not suggesting GnuCash should bury 
> info however.
> 
> I see on the website, GnuCash has a simple “Writing Documentation” link and 
> the page looks pretty direct and straightforward. The Wiki page is certainly 
> more involved, but I don’t think the title “Improving” here is misleading. 
> The only thing I see missing on either page is any hint that the wiki or the 
> website are also documentation projects, or how to get involved with them, 
> and at least the former has a lower entry barrier. (Has there been any 
> discussion of moving to a CMS for the website?)
> 
> Just some thoughts...
> 
> Regards,
> Adrien
> 
> 
> 
>> On Aug 18, 2018, at 1:42 AM, David T. via gnucash-devel 
>>  wrote:
>> 
>> Frank,
>> 
>> You imply that the use of Eclipse somehow renders the documentation process 
>> simple enough for a user to identify a typo and get it fixed. I flat out 
>> disagree, and I think that using disingenuous language on the wiki home page 
>> is not going to change the reality: implementing a change in the 
>> documentation is a Process.
>> 
>> I still think the heading should be reverted to “Developing the 
>> Documentation”, and I am copying gnucash-devel as you requested.
>> 
>> David
>> 
>> 
>>> On Aug 17, 2018, at 11:23 AM, Frank H. Ellenberger 
>>>  wrote:
>>> 
>>> Hi David,
>>> 
>>> Am 16.08.2018 um 20:52 schrieb David T.:
 Frank,
 
 As you will see on gnucash-devel, I had reason to examine the wiki home 
 page today, and noticed some of the changes you have implemented there 
 over the last year or so. I wanted to discuss off list with you one of 
 those changes.
 
 You changed “Developing the Documentation” to “Improving the 
 Documentation” with the note that “developing sounds so high-flown”. I 
 think you’re wrong here, and I’d like you to change that back to 
 “Developing.” 
 
 Here’s why I think that:
 
 IF improving 

Re: [GNC-dev] [GNC] GnuCash 3.2 Released

[D via gnucash-devel]

On July 11, 2018, at 4:04 PM, Wm via gnucash-devel  
wrote:

>On 11/07/2018 03:49, John Ralls wrote:
>> 
>> 
>>> On Jul 10, 2018, at 6:45 PM, Wm  wrote:
>>> Aside: is there a reason why version changes aren't on (or easily found 
>>> from) the front page  of gnucash.org? they used to be there.
>> 
>> David T. thought that it made the front page too busy and moved it to 
>> https://www.gnucash.org/news.phtml ;.
>Hmmn.  Does anyone else think that news and release notes aren't quite 
>the same?  That there has been a release, possibly with notes, is indeed 
>news.  I'm sorta thinking the release notes should be close to the 
>download, especially for a version change, rather than tucked away under 
>some Bugzilla stuff that the vast majority of users don't care about.

When I made the proposal, and subsequently implemented the changes based on 
input through Bugzilla, I was struck by the overwhelming nature of the laundry 
list approach to news announcements on the start page. 

To me, the start page is Gnucash's opportunity to make an impression on *new* 
users. Such users are unlikely to be interested in knowing all the broken 
things that have now been fixed; they are primarily looking to find out what 
Gnucash does, and how to get it and use it. Your comment is the first to note 
the change, which suggests that it hasn't deterred other users.

Frankly, I don't understand your distinction between release notes and 
"Bugzilla stuff." However, if there's a way to improve the communication of 
changes to users that balances the different information needs, then I am all 
for it. What do you propose?

David T.


>I can't find the release notes on sourceforge.net (which is, I think, 
>were most people get their GnuCash from) either.
>Ho hum.  A thread nearby suggests someone else didn't have the 2.x to 
>3.x changes made clear to him.
>-- 
>Wm
>___
>gnucash-devel mailing list
>gnucash-devel@gnucash.org
>https://lists.gnucash.org/mailman/listinfo/gnucash-devel
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Register text selection

[D via gnucash-devel]

Rather than change the message (which is still a good idea), I think we should 
in this case fix the messenger--in other words, stop highlighting off screen 
data elements and stop allowing users to change things they cannot see.

David T.

On May 22, 2018, at 5:39 AM, David Carlson  wrote:

A long time ago I filed a bug report 
 about needing to have an 
easy way to navigate to those edited but not committed transactions that 
trigger the warnings when closing the file or clicking on Save.  I vote to 
escalate that bug.


David C


On Mon, May 21, 2018 at 12:44 PM, David T. via gnucash-devel 
 wrote:



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

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

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

David T.




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


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

Re: trial balance - how to find mismatch question

[D via gnucash-devel]

Geert,

I think having nearest in time use future dates relative to the report date is 
not useful. Mind you, matching a broker statement for value (as opposed to 
holdings) is perhaps equally not useful.

I guess I could see a point to a nearest in time using later dates (for 
example, when the date history is sparse, and the only earlier date is much 
earlier). But perhaps your suggestion of a separate setting would solve the 
dilemma.

David

On March 3, 2018, at 11:00 PM, Geert Janssens  
wrote:

Op zaterdag 3 maart 2018 16:35:27 CET schreef David Carlson:
> On January 30, 2015 I reported
> https://bugzilla.gnome.org/show_bug.cgi?id=743753 pointing out this
> behavior in Gnucash suggesting that the nearest in time criterion should
> not select future dates.  That bug report applied to release 2.6.5 and as
> of today it still has a status of "New"  If this criterion with it's
> current behavior is the desired behavior, I assert that there should be
> another criterion "last price on or before" so users can make their GnuCash
> year end reports match their brokers statements without fudging prices in
> their data files.
I think having the extra option would be useful and less confusing than having 
"Nearest in time" only look backwards.

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

Mac Help works. Since when?

[D via gnucash-devel]

Hello,

Another wiki thing, probably for John. The FAQ includes a Mac question about 
how to get help to work, but I know that it currently (2.6.19) works out of the 
box, and has for a few versions now. I hesitate to delete the question 
outright, though, because people are known to use older versions all the time. 
So, the question is, for which release was the help system fixed on the Mac? I 
will change the FAQ to identify the version, once I know this.

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

Access to code.gnucash.org

[D via gnucash-devel]

Hello,

I am editing the various wiki pages that address using git (mostly, "Git" and 
"Git for Newbies"), and I noted that on the Git page, it talks about connecting 
to code.gnucash.org. The newbie page, however talks solely about connecting 
through github. My question is this: aside from the core developers, is anyone 
supposed to work directly with code.gnucash.org? Should it even be mentioned on 
the Git instruction pages, or should that be put into some other page? My sense 
is that non-committing (noncommittal?) contributors are only going to use 
github. Am I wrong in this assumption?

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

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

[D via gnucash-devel]

Certainly. I've just used what my mail program puts in.

On December 1, 2017, at 8:31 PM, Geert Janssens  
wrote:

Oh, David,

Completely unrelated to this discussion... Can you use gnucash-
de...@gnucash.org in the future as mail address for the list rather than 
gnucash-de...@lists.gnucash.org ?

While both work the one without "list" in the domain is the one the list 
manager itself promotes. When I do a reply-all on mails sent to gnucash-
de...@lists.gnucash.org, my mailer automatically adds both addresses which 
would make the list receive my message twice. I usually try to catch this 
before I send the mails, but as with my previous mail I do miss it from time 
to time...

Thanks!

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

Fwd: [Bug 692961] Update Chapter 6.3 in Tutorial

[D via gnucash-devel]

Frank,

I don't understand why you are updating a documentation bug that was closed in 
2015. Can you explain?

David

 Original Message 
 Subject: [Bug 692961] Update Chapter 6.3 in Tutorial
 From: GnuCash 
 Sent: Thursday, October 5, 2017, 1:12 AM
 To: sunfis...@yahoo.com
 CC: 

Frank H. Ellenberger changed bug 692961 
WhatRemovedAddedAttachment #264169 is obsolete   1 

Comment # 17 on bug 692961 from Frank H. Ellenberger Comment on attachment 
264169 [details] [review] Patch for this bug 692961 Patch 310037 obsoletes 
264169 

You are receiving this mail because: You reported the bug. 
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel