[GNC-dev] GnuCash 3.2 Released

[John Ralls]

The GnuCash development team announces GnuCash 3.2, the second release of the 
3.x stable release series.

Changes

Between 3.0 and 3.2, the following bugfixes were accomplished:

• Bug 787401 - Test Report System - Report Definition.
• Bug 794617 - Can't compile with -DWITH_GNUCASH=NO due to 
scm-gnome-utils.
• Bug 795101 - Scroll Bar in Reconcile Window Floats in and covers the 
check boxes.
• Bug 795247 - datepicker broken in Persian. GnuCash passes dates as 
integer y/m/d without using locale-specific formats, so we need to strip out 
'E' and 'O' from the format when scanning dates or determining separators in 
gnc-date. None of '-', 'E', or 'O' are supported by boost (and '-' causes 
errors), so strip them out from formatters in gnc-datetime as well.
• Bug 795253 - Have problems input Chinese.
• Bug 795272 - QIF importer causes application crash if action is 
invalid.
• Bug 795276 - Invalid date on price stops file from being parsed.
• Bug 795362 - Special variable "i" not parsed in function calls. Due 
to balance tests with insane random values.
• Bug 795471 - Impossible to Edit Budget Unless Maximized.
• Bug 795519 - Credit card payment after reconciliation.
• Bug 795666 - Backslash '\' in Description field spoils CSV Import 
without helpful error message.
• Bug 795831 - When read only threshold set, dates are silently 
changed. Display a message box informing the user of the change.
• Bug 795944 - Cannot store change to Business Suppliers data.
• Bug 796079 - Repeatable Crash in Tax Report Options.
• Bug 796081 - Tax Schedule Report - An error occurred while running 
the report.
• Bug 796083 - Reconcile Selection Doesn't Work Anymore.
• Bug 796117 - Connecting 3.1 to an existing mysql db drops all data. 
Provide a backup recovery function that instead of dropping primaries and 
restoring backups merges the primaries and backups. This should handle a 
worst-case safe-save failure where the backup tables don't have a complete set 
of rows for some reason.
• Bug 796256 - Main Window stays hidden when starting after closing 
main window while minimized.
• Bug 796369 - Notes lost or perhaps just not displaying when using 
SQLite backend. This bug caused data loss if you saved your SQLite3 database to 
a different file or database. The problem is that in SQLite3 (though not in 
MySQL or PgSQL) the subquery ((SELECT DISTINCT guid FROM transactions)) (note 
the double parentheses) returns only the first guid in the subquery's results. 
Some transactions are loaded by special queries and those queries are also used 
to retrieve the transaction's slots so they weren't affected.
• Bug 796398 - Restrict accelerator keys to valid date range.
• Bug 796409 - Incorrect Current Value for Stocks. Missed calculating 
the value in the register summary bar.
• Bug 796423 - Cannot Input Chinese, seems does not work with other IME 
too. Toggles not in view with all rows selected weren't being redrawn.
• Bug 796484 - csv import: iostream error. Unfortunately it turns out 
that we can't use filestreams because they can't take path arguments containing 
Unicode on Windows.
• Bug 796527 - invalid currency on scheduled transactions.
• Don't even check for price/exchange rate on template 
transactions, there's no point.
• Check all split commodities are valid, abort transaction 
creation if not.
• If the template transaction's currency isn't used by any of 
the splits set the new transaction's currency to the first-found currency if 
there is one, otherwise to the first-found commodity.
• Bug 796537 - Transaction Report cannot sort by "num".
• Bug 796586 - QIF import incorrectly converts unicode characters from 
UTF8 encoded file.
• Bug 796595 - QIF Import Select Account button to add a new account is 
labled gnc-account-new but should be New.
• Bug 796600 - stock split cash-in-lieu income/asset labels backwards.
• Bug 796614 - Reconciliation report contains incorrect transactions.
• Bug 796638 - configuration not properly saved for CSV transactions 
import form.
The Following fixes and improvemts were not associated with bug reports:

• Transaction report improvements:
• Performance: Do all filtering ops before sorting.
• Move the options summary before the subtotals table.
• New unit tests
• Enable computing averages in subtotal grid.
• Generate the subtotal grid only if the primary sort key 
enables subtotals.
• Fix subtotal grid to support multiple commodities.
• New filters.
• Much cleaning and refactoring of the internals.
• Cache the num-split-action book option to avoid thousands of KVP 
queries 

Re: [GNC-dev] Widget naming and css

[Geert Janssens]

Op zondag 24 juni 2018 22:06:20 CEST schreef Robert Fewell:
> I'm OK with 'gnc-class-' and 'gnc-id-' and can make the changes on master
> over time.
> Could do it on maint but there may be some existing settings that need
> changing to align.
> 
> Bob
> 
Master is fine. Thanks!

Geert

> On 24 June 2018 at 18:43, Geert Janssens  wrote:
> > Op zondag 24 juni 2018 18:12:19 CEST schreef John Ralls:
> > > Bob,
> > > 
> > > Thanks, much clearer.
> > > 
> > > Using the prefix gnc-style and gnc-name does clarify the intent, so
> > 
> > that’s
> > 
> > > good.  My only concern from a grepping standpoint is that it mimics the
> > > format for Scheme functions imported from C, but as long as we don’t
> > > have
> > > any functions named gnc_style_foo and gnc_name_foo that’s probably OK.
> > > 
> > > Regards,
> > > John Ralls
> > 
> > Yes I'm fine with the concept too. On the other hand I like to think a bit
> > more about the best prefixes to choose as they should be relevant for
> > years to
> > come.
> > 
> > The primary reason to enumerate the style contexts and widget names used
> > is to
> > be able to write css rule based on them. Ideally/eventually this should
> > even
> > be possible for people understanding css but don't know the gtk internals
> > very
> > well. The reason I formulate it this way is that I think the prefixes
> > should
> > make most sense for css writers and are less important for code writers.
> > 
> > So how will widget names and style contexts be used in css ?
> > A style context maps to a css class. So the class is the core concept to
> > stress and as such I would propose to use "gnc-class" as prefix for style
> > contexts.
> > A widget name maps to a css ID. In this case "ID" is the core concept to
> > stress and hence to create  some consistency for our purpose I would
> > propose
> > to prefix them with "gnc-id".
> > 
> > What do you think ?
> > 
> > Regards,
> > 
> > Geert
> > 
> > > > On Jun 24, 2018, at 4:10 AM, Robert Fewell <14ubo...@gmail.com> wrote:
> > > > 
> > > > Sorry it was not clear, so I will try again.
> > > > 
> > > > When I was doing the GTK3 migration I added some context styles to
> > 
> > various
> > 
> > > > widgets but I now believe some of them should be widget names like the
> > > > following... GncBusinessPage should really be a widget name and then
> > 
> > with
> > 
> > > > associated styles.
> > > > 
> > > > So as an example I changed GncBusinessPage from a style context to a
> > > > widget name of 'gnc-name-business-page' and associated style contexts
> > 
> > to
> > 
> > > > start with 'gnc-style-' along with some other changes I can now grep
> > > > them...
> > > > 
> > > > grep -nHIirF 'gnc-style-'
> > > > gnucash/gnome/gnc-plugin-page-owner-tree.c:658:style_label =
> > > > 
> > > > "gnc-style-unknown"; gnucash/gnome/gnc-plugin-page-owner-tree.c:663:
> > > >   style_label = "gnc-style-customer";
> > > > 
> > > > gnucash/gnome/gnc-plugin-page-owner-tree.c:668:style_label =
> > > > "gnc-style-job"; gnucash/gnome/gnc-plugin-page-owner-tree.c:673:
> > > > 
> > > > style_label = "gnc-style-vendor";
> > > > gnucash/gnome/gnc-plugin-page-owner-tree.c:678:style_label =
> > > > 
> > > > "gnc-style-employee"; gnucash/gtkbuilder/dialog-vendor.glade:559:
> > > >  
> > > > 
> > > > gnucash/gtkbuilder/dialog-vendor.glade:796:   > > > 
> > > > name="gnc-style-vendor"/> gnucash/gtkbuilder/dialog-vendor.glade:830:
> > > >  
> > > > 
> > > > grep -nHIirF 'gnc-name-'
> > > > gnucash/gnome/gnc-plugin-page-owner-tree.c:626:gtk_widget_set_name
> > > > (GTK_WIDGET(priv->widget), "gnc-name-business-page");
> > > > gnucash/gnome/window-reconcile.c:1817:gtk_widget_set_name
> > > > (debits_box, "gnc-name-reconcile-window-debits");
> > > > gnucash/gnome/window-reconcile.c:1822:gtk_widget_set_name
> > > > (credits_box, "gnc-name-reconcile-window-credits");
> > > > gnucash/gnome/window-reconcile.c:1855:gtk_widget_set_name
> > > > (frame, "gnc-name-reconcile-window-totals");
> > > > gnucash/gtkbuilder/dialog-vendor.glade:30: > > > name="name">gnc-name-vendor-dialog
> > > > 
> > > > With the grep command it easily shows me what widgets have been named
> > > > along with style contexts and so I can easily apply CSS to them and
> > > > possibly reuse the style contexts else ware in the code..
> > > > 
> > > > So the question was how to name them consistently, I have used the
> > > > prefixes of 'gnc-name-' and 'gnc-style-' and find them easily for
> > > > possible manipulation / publication in the future.
> > > > 
> > > > Hope this is clearer.
> > > > 
> > > > Regards,
> > > > Bob
> > > > 
> > > > On 23 June 2018 at 16:59, John Ralls  > 
> > > wrote:
> > > > > On Jun 23, 2018, at 4:18 AM, Robert Fewell <14ubo...@gmail.com
> > > > > > wrote:
> > > > > 
> > > > > I have been thinking about naming some widgets and changing some of
> > 
> > t

Re: [GNC-dev] Slow user interface in 3.x gnucash: Online transaction import painfully slow - with workaround

[John Ralls]

> On Jun 24, 2018, at 11:48 AM, Christian Stimming  
> wrote:
> 
> Dear developers,
> 
> as I'm still in the process of migrating my everyday work from 2.6.x gnucash 
> to 3.x gnucash, I enountered some places where the user interface is still 
> quite slow in current 3.x gnucash compared to the old one. I've fixed on such 
> issue in the last days, but other remain.
> 
> One such place that seems painfully slow is the online transaction import 
> (using aqbanking with a German HBCI bank account). After the connection log 
> window closes, it took literally minutes until the transaction-matching 
> window 
> appeared. During this step, the imported transactions should be matched 
> against potentially existing ones with the identical online_id, and suggested 
> matches for all the non-matching ones are being calculated. (After editing 
> normally there, clicking "Ok" was additionally very slow, but let's focus on 
> the first step.)
> 
> By looking into this with valgrind/callgrind, it turns out that the register 
> windows keep getting refreshed a lot, i.e. gtk_widget_draw is called several 
> ten thousands times during this phase. This is quite weird. Of course the UI 
> shouldn't get updated during the calculation step, and only after this is 
> finished the UI update should be activated again.
> 
> Here's the workaround: I closed all account register windows, and select the 
> online actions by selecting my online account in the account tree widget as 
> selected item. When calling the online transaction download now, there is no 
> large delay anymore! (i.e. the behaviour is practically identical to 2.6 
> gnucash)
> 
> This seems quite weird to me. It seems there is no gnc_suspend_gui_refresh / 
> gnc_resume_gui_refresh pair for this first step before the matcher window 
> opens, so maybe this needs to be inserted in the correct place. However, in 
> 2.6 gnucash this was missing, too, and it didn't seem to be a problem.
> 
> Also, on clicking "Ok" there is such a suspend/resume pair (in import-main-
> matcher.c lines 160ff), unchanged from 2.6 to now, but in my first tests when 
> the register windows are open, this step has just as well a minute-long delay 
> similar to the first step.
> 
> Anyone an idea on what might be missing? Thanks for pointers. 
> 
> Unfortunately I didn't find an easy method to reproduce this without online 
> account. Maybe some of the file imports show this as well, but so far I 
> didn't 
> encounter it except with the online account.

Christian,

I suspect this is https://bugzilla.gnome.org/show_bug.cgi?id=792986 that 
Mechtilde reported several months ago. She wasn't able to provide any 
additional data and none of the rest of us have the requisite bank account to 
be able to reproduce the issue.

There are two prime suspects here: One is that the redraw code is different 
between Gtk3 and Gtk2 with the former being significantly slower and possibly 
incompatible with gnc_suspend_gui_refresh; the other that the change of the 
register redraw code from libgnomecanvas to directly to a cairo surface, being 
lower-level code is inefficient.

Regards,
John Ralls

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

Re: [GNC-dev] Widget naming and css

[Robert Fewell]

I'm OK with 'gnc-class-' and 'gnc-id-' and can make the changes on master
over time.
Could do it on maint but there may be some existing settings that need
changing to align.

Bob

On 24 June 2018 at 18:43, Geert Janssens  wrote:

> Op zondag 24 juni 2018 18:12:19 CEST schreef John Ralls:
> > Bob,
> >
> > Thanks, much clearer.
> >
> > Using the prefix gnc-style and gnc-name does clarify the intent, so
> that’s
> > good.  My only concern from a grepping standpoint is that it mimics the
> > format for Scheme functions imported from C, but as long as we don’t have
> > any functions named gnc_style_foo and gnc_name_foo that’s probably OK.
> >
> > Regards,
> > John Ralls
> >
> Yes I'm fine with the concept too. On the other hand I like to think a bit
> more about the best prefixes to choose as they should be relevant for
> years to
> come.
>
> The primary reason to enumerate the style contexts and widget names used
> is to
> be able to write css rule based on them. Ideally/eventually this should
> even
> be possible for people understanding css but don't know the gtk internals
> very
> well. The reason I formulate it this way is that I think the prefixes
> should
> make most sense for css writers and are less important for code writers.
>
> So how will widget names and style contexts be used in css ?
> A style context maps to a css class. So the class is the core concept to
> stress and as such I would propose to use "gnc-class" as prefix for style
> contexts.
> A widget name maps to a css ID. In this case "ID" is the core concept to
> stress and hence to create  some consistency for our purpose I would
> propose
> to prefix them with "gnc-id".
>
> What do you think ?
>
> Regards,
>
> Geert
>
> > > On Jun 24, 2018, at 4:10 AM, Robert Fewell <14ubo...@gmail.com> wrote:
> > >
> > > Sorry it was not clear, so I will try again.
> > >
> > > When I was doing the GTK3 migration I added some context styles to
> various
> > > widgets but I now believe some of them should be widget names like the
> > > following... GncBusinessPage should really be a widget name and then
> with
> > > associated styles.
> > >
> > > So as an example I changed GncBusinessPage from a style context to a
> > > widget name of 'gnc-name-business-page' and associated style contexts
> to
> > > start with 'gnc-style-' along with some other changes I can now grep
> > > them...
> > >
> > > grep -nHIirF 'gnc-style-'
> > > gnucash/gnome/gnc-plugin-page-owner-tree.c:658:style_label =
> > > "gnc-style-unknown"; gnucash/gnome/gnc-plugin-page-owner-tree.c:663:
>
> > >   style_label = "gnc-style-customer";
> > > gnucash/gnome/gnc-plugin-page-owner-tree.c:668:style_label =
> > > "gnc-style-job"; gnucash/gnome/gnc-plugin-page-owner-tree.c:673:
>
> > > style_label = "gnc-style-vendor";
> > > gnucash/gnome/gnc-plugin-page-owner-tree.c:678:style_label =
> > > "gnc-style-employee"; gnucash/gtkbuilder/dialog-vendor.glade:559:
>
> > >  
> > > gnucash/gtkbuilder/dialog-vendor.glade:796:   > > name="gnc-style-vendor"/> gnucash/gtkbuilder/dialog-vendor.glade:830:
>
> > >  
> > >
> > > grep -nHIirF 'gnc-name-'
> > > gnucash/gnome/gnc-plugin-page-owner-tree.c:626:gtk_widget_set_name
> > > (GTK_WIDGET(priv->widget), "gnc-name-business-page");
> > > gnucash/gnome/window-reconcile.c:1817:gtk_widget_set_name
> > > (debits_box, "gnc-name-reconcile-window-debits");
> > > gnucash/gnome/window-reconcile.c:1822:gtk_widget_set_name
> > > (credits_box, "gnc-name-reconcile-window-credits");
> > > gnucash/gnome/window-reconcile.c:1855:gtk_widget_set_name
> > > (frame, "gnc-name-reconcile-window-totals");
> > > gnucash/gtkbuilder/dialog-vendor.glade:30: > > name="name">gnc-name-vendor-dialog
> > >
> > > With the grep command it easily shows me what widgets have been named
> > > along with style contexts and so I can easily apply CSS to them and
> > > possibly reuse the style contexts else ware in the code..
> > >
> > > So the question was how to name them consistently, I have used the
> > > prefixes of 'gnc-name-' and 'gnc-style-' and find them easily for
> > > possible manipulation / publication in the future.
> > >
> > > Hope this is clearer.
> > >
> > > Regards,
> > > Bob
> > >
> > > On 23 June 2018 at 16:59, John Ralls  > wrote:
> > > > On Jun 23, 2018, at 4:18 AM, Robert Fewell <14ubo...@gmail.com
> > > > > wrote:
> > > >
> > > > I have been thinking about naming some widgets and changing some of
> the
> > > > entries I added with css style classes and wondered if there has
> been a
> > > > convention decided.
> > > >
> > > > What I would like to see is a couple of unique prefixes so that one
> > > > could
> > > > do a grep on the top level directory and obtain all such entries and
> > > > maybe
> > > > manipulate into some sort of list that could be published some ware.
> > > >
> > > > Doing a quick content search shows 'gnc-style-'

[GNC-dev] Slow user interface in 3.x gnucash: Online transaction import painfully slow - with workaround

[Christian Stimming]

Dear developers,

as I'm still in the process of migrating my everyday work from 2.6.x gnucash 
to 3.x gnucash, I enountered some places where the user interface is still 
quite slow in current 3.x gnucash compared to the old one. I've fixed on such 
issue in the last days, but other remain.

One such place that seems painfully slow is the online transaction import 
(using aqbanking with a German HBCI bank account). After the connection log 
window closes, it took literally minutes until the transaction-matching window 
appeared. During this step, the imported transactions should be matched 
against potentially existing ones with the identical online_id, and suggested 
matches for all the non-matching ones are being calculated. (After editing 
normally there, clicking "Ok" was additionally very slow, but let's focus on 
the first step.)

By looking into this with valgrind/callgrind, it turns out that the register 
windows keep getting refreshed a lot, i.e. gtk_widget_draw is called several 
ten thousands times during this phase. This is quite weird. Of course the UI 
shouldn't get updated during the calculation step, and only after this is 
finished the UI update should be activated again.

Here's the workaround: I closed all account register windows, and select the 
online actions by selecting my online account in the account tree widget as 
selected item. When calling the online transaction download now, there is no 
large delay anymore! (i.e. the behaviour is practically identical to 2.6 
gnucash)

This seems quite weird to me. It seems there is no gnc_suspend_gui_refresh / 
gnc_resume_gui_refresh pair for this first step before the matcher window 
opens, so maybe this needs to be inserted in the correct place. However, in 
2.6 gnucash this was missing, too, and it didn't seem to be a problem.

Also, on clicking "Ok" there is such a suspend/resume pair (in import-main-
matcher.c lines 160ff), unchanged from 2.6 to now, but in my first tests when 
the register windows are open, this step has just as well a minute-long delay 
similar to the first step.

Anyone an idea on what might be missing? Thanks for pointers. 

Unfortunately I didn't find an easy method to reproduce this without online 
account. Maybe some of the file imports show this as well, but so far I didn't 
encounter it except with the online account.

Regards,

Christian

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

Re: [GNC-dev] Widget naming and css

[Geert Janssens]

Op zondag 24 juni 2018 18:12:19 CEST schreef John Ralls:
> Bob,
> 
> Thanks, much clearer.
> 
> Using the prefix gnc-style and gnc-name does clarify the intent, so that’s
> good.  My only concern from a grepping standpoint is that it mimics the
> format for Scheme functions imported from C, but as long as we don’t have
> any functions named gnc_style_foo and gnc_name_foo that’s probably OK.
> 
> Regards,
> John Ralls
> 
Yes I'm fine with the concept too. On the other hand I like to think a bit 
more about the best prefixes to choose as they should be relevant for years to  
come.

The primary reason to enumerate the style contexts and widget names used is to 
be able to write css rule based on them. Ideally/eventually this should even 
be possible for people understanding css but don't know the gtk internals very 
well. The reason I formulate it this way is that I think the prefixes should 
make most sense for css writers and are less important for code writers.

So how will widget names and style contexts be used in css ?
A style context maps to a css class. So the class is the core concept to 
stress and as such I would propose to use "gnc-class" as prefix for style 
contexts.
A widget name maps to a css ID. In this case "ID" is the core concept to 
stress and hence to create  some consistency for our purpose I would propose 
to prefix them with "gnc-id".

What do you think ?

Regards,

Geert

> > On Jun 24, 2018, at 4:10 AM, Robert Fewell <14ubo...@gmail.com> wrote:
> > 
> > Sorry it was not clear, so I will try again.
> > 
> > When I was doing the GTK3 migration I added some context styles to various
> > widgets but I now believe some of them should be widget names like the
> > following... GncBusinessPage should really be a widget name and then with
> > associated styles.
> > 
> > So as an example I changed GncBusinessPage from a style context to a
> > widget name of 'gnc-name-business-page' and associated style contexts to
> > start with 'gnc-style-' along with some other changes I can now grep
> > them...
> > 
> > grep -nHIirF 'gnc-style-'
> > gnucash/gnome/gnc-plugin-page-owner-tree.c:658:style_label =
> > "gnc-style-unknown"; gnucash/gnome/gnc-plugin-page-owner-tree.c:663: 
> >   style_label = "gnc-style-customer";
> > gnucash/gnome/gnc-plugin-page-owner-tree.c:668:style_label =
> > "gnc-style-job"; gnucash/gnome/gnc-plugin-page-owner-tree.c:673:   
> > style_label = "gnc-style-vendor";
> > gnucash/gnome/gnc-plugin-page-owner-tree.c:678:style_label =
> > "gnc-style-employee"; gnucash/gtkbuilder/dialog-vendor.glade:559:
> >  
> > gnucash/gtkbuilder/dialog-vendor.glade:796:   > name="gnc-style-vendor"/> gnucash/gtkbuilder/dialog-vendor.glade:830:
> >  
> > 
> > grep -nHIirF 'gnc-name-'
> > gnucash/gnome/gnc-plugin-page-owner-tree.c:626:gtk_widget_set_name
> > (GTK_WIDGET(priv->widget), "gnc-name-business-page");
> > gnucash/gnome/window-reconcile.c:1817:gtk_widget_set_name
> > (debits_box, "gnc-name-reconcile-window-debits");
> > gnucash/gnome/window-reconcile.c:1822:gtk_widget_set_name
> > (credits_box, "gnc-name-reconcile-window-credits");
> > gnucash/gnome/window-reconcile.c:1855:gtk_widget_set_name
> > (frame, "gnc-name-reconcile-window-totals");
> > gnucash/gtkbuilder/dialog-vendor.glade:30: > name="name">gnc-name-vendor-dialog
> > 
> > With the grep command it easily shows me what widgets have been named
> > along with style contexts and so I can easily apply CSS to them and
> > possibly reuse the style contexts else ware in the code..
> > 
> > So the question was how to name them consistently, I have used the
> > prefixes of 'gnc-name-' and 'gnc-style-' and find them easily for
> > possible manipulation / publication in the future.
> > 
> > Hope this is clearer.
> > 
> > Regards,
> > Bob
> > 
> > On 23 June 2018 at 16:59, John Ralls mailto:jra...@ceridwen.fremont.ca.us>> wrote:
> > > On Jun 23, 2018, at 4:18 AM, Robert Fewell <14ubo...@gmail.com
> > > > wrote:
> > > 
> > > I have been thinking about naming some widgets and changing some of the
> > > entries I added with css style classes and wondered if there has been a
> > > convention decided.
> > > 
> > > What I would like to see is a couple of unique prefixes so that one
> > > could
> > > do a grep on the top level directory and obtain all such entries and
> > > maybe
> > > manipulate into some sort of list that could be published some ware.
> > > 
> > > Doing a quick content search shows 'gnc-style-' and 'gnc-name-' would
> > > work
> > > but open to suggestions.
> > > 
> > > This would allow those users inclined to customise the appearance more
> > > easily.
> > > I would probably do this on master over time.
> > 
> > Bob,
> > 
> > I’m not sure I understand what you’re suggesting. Perhaps you could
> > suggest a concrete example?
> > 
> > Regards,
> > John Ralls
> 
> _

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

[John Ralls]

Chris,

OK, I think that’s a good choice.

As a general design principle I’d like to see the reports use QofQuery as much 
as possible--and extend QofQuery as necessary--because that makes it easier to 
reimplement as database queries.

Regards,
John Ralls


> On Jun 24, 2018, at 2:50 AM, Christopher Lam  
> wrote:
> 
> I think I'll forego a noclosing_balance upgrade in C.
> 
> According to https://bugzilla.gnome.org/show_bug.cgi?id=570042 
>  the "Closing Entries" 
> transactions did not always receive a special KVP-based flag until the commit 
> onhttps://github.com/Gnucash/gnucash/commit/4b2800145 
>  on datafiles generated 
> from 27-11-2008 and later.
> So, to find and exclude these closing entries, we can use the following 
> strategies:
> xaccTransGetIsClosingTxn, will query the KVP flag
> Run a QofQuery and add xaccQueryAddClosingTransMatch (also queries the KVP 
> flag)
> Free-text search "Closing Entries" to seek these old closing entries
> So a P&L report will necessarily need to do both filtering for KVP and 
> free-text search.
> 
> The multicolumn report will be different enough from the old balance-sheet 
> and income-statement that I think I should spin it off into a different 
> report altogether, and the others will be sunsetted. Hopefully this new 
> report will be broadly acceptable because the old reports have a *lot* of 
> supporting unintelligible old code, especially to handle closing-entries as 
> above.
> 
> C
> 
> On 24/06/18 00:51, Christopher Lam wrote:
>> Hi John, the split->noclosing_balance is updated in 
>> xaccAccountRecomputeBalance. Will continue copypasta coding until it works!
>> 
>> On Sat, 23 Jun 2018, 23:56 John Ralls > > wrote:
>> 
>> 
>> > On Jun 22, 2018, at 9:42 PM, Christopher Lam > > > wrote:
>> > 
>> > Hi All
>> > 
>> > I'm working through balance-sheet.scm and overhauling this report.
>> > 
>> > At the same time, I can see that balance-sheet.scm and 
>> > income-statement.scm can be merged together.
>> > 
>> > After all
>> > 
>> > * balance sheet = asset/liability/equity balance at date X,
>> > * income statement = difference in income/expense balances at date X and Y
>> > 
>> > The issue I have is that the balance sheet can call 
>> > xaccAccountGetBalanceAsOfDate(acc,date) directly to nicely retrieve the 
>> > balance, whereas income statement cannot directly call it because it also 
>> > includes closing transactions.
>> > 
>> > My proposal is to augment xaccAccountGetBalanceAsOfDate to accept a 3rd 
>> > boolean argument i.e. 
>> > xaccAccountGetBalanceAsOfDate(acc,date,ignoreclosing) which will 
>> > selectively produce the balance, ignore closing transactions.
>> > 
>> > This is partly done in the last commit of 
>> > https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances
>> >  
>> > 
>> >  - it will augment API everywhere, and also modify Account.cpp, especially 
>> > xaccAccountRecomputeBalance which will call 
>> > xaccTransGetIsClosingTxn(xaccSplitGetParent(split)) for each split in the 
>> > account to determine closing status and cache the balances for each split. 
>> > See draft on 
>> > https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances
>> >  
>> > 
>> >  - this currently fails because I'm not good at C.
>> > 
>> > *My query is whether it will be too expensive to call 
>> > xaccTransGetIsClosingTxn for each split in Account.cpp to produce the 
>> > split->noclosing_balance, which will be crucial to calculate income 
>> > between two dates.*
>> > 
>> > *Currently this 'closing-txn' filter is done in income-statement.scm via a 
>> > "Closing Entries" string/regex filter and xaccTransGetIsClosingTxn calls, 
>> > which IMHO is not ideal either.
>> > *
>> > 
>> > Any help welcome!
>> > 
>> > P.S. if this last commit is removed, the 
>> > https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances
>> >  
>> > 
>> >  branch contains work-so-far for updated balance-sheet. Screenshot 
>> > https://screenshots.firefox.com/eelmGQrGCtcP6bqC/null 
>> >  - see the 
>> > multilevel subtotals were previously horizonal, are now vertical; 
>> > original-currency amounts, and multiple-date balance sheets.
>> > 
>> > _
>> 
>> Chris,
>> 
>> Only profiling will tell how much of a performance hit this creates.
>> 
>> I don’t see where in your commit you’re computing the split’s no-closing 
>> balance. Perhaps that’s why it doesn’t work?
>> 
>> Regards,
>> Joh

Re: [GNC-dev] Widget naming and css

[John Ralls]

Bob,

Thanks, much clearer.

Using the prefix gnc-style and gnc-name does clarify the intent, so that’s 
good.  My only concern from a grepping standpoint is that it mimics the format 
for Scheme functions imported from C, but as long as we don’t have any 
functions named gnc_style_foo and gnc_name_foo that’s probably OK.

Regards,
John Ralls



> On Jun 24, 2018, at 4:10 AM, Robert Fewell <14ubo...@gmail.com> wrote:
> 
> Sorry it was not clear, so I will try again.
> 
> When I was doing the GTK3 migration I added some context styles to various 
> widgets but I now believe some of them should be widget names like the 
> following...
> GncBusinessPage should really be a widget name and then with associated 
> styles.
> 
> So as an example I changed GncBusinessPage from a style context to a widget 
> name of 'gnc-name-business-page' and associated style contexts to start with 
> 'gnc-style-' along with some other changes I can now grep them...
> 
> grep -nHIirF 'gnc-style-'
> gnucash/gnome/gnc-plugin-page-owner-tree.c:658:style_label = 
> "gnc-style-unknown";
> gnucash/gnome/gnc-plugin-page-owner-tree.c:663:style_label = 
> "gnc-style-customer";
> gnucash/gnome/gnc-plugin-page-owner-tree.c:668:style_label = 
> "gnc-style-job";
> gnucash/gnome/gnc-plugin-page-owner-tree.c:673:style_label = 
> "gnc-style-vendor";
> gnucash/gnome/gnc-plugin-page-owner-tree.c:678:style_label = 
> "gnc-style-employee";
> gnucash/gtkbuilder/dialog-vendor.glade:559:   name="gnc-style-vendor"/>
> gnucash/gtkbuilder/dialog-vendor.glade:796:   name="gnc-style-vendor"/>
> gnucash/gtkbuilder/dialog-vendor.glade:830:   name="gnc-style-vendor"/>
> 
> grep -nHIirF 'gnc-name-'
> gnucash/gnome/gnc-plugin-page-owner-tree.c:626:gtk_widget_set_name 
> (GTK_WIDGET(priv->widget), "gnc-name-business-page");
> gnucash/gnome/window-reconcile.c:1817:gtk_widget_set_name 
> (debits_box, "gnc-name-reconcile-window-debits");
> gnucash/gnome/window-reconcile.c:1822:gtk_widget_set_name 
> (credits_box, "gnc-name-reconcile-window-credits");
> gnucash/gnome/window-reconcile.c:1855:gtk_widget_set_name (frame, 
> "gnc-name-reconcile-window-totals");
> gnucash/gtkbuilder/dialog-vendor.glade:30: name="name">gnc-name-vendor-dialog
> 
> With the grep command it easily shows me what widgets have been named along 
> with style contexts and so I can easily apply CSS to them and possibly reuse 
> the style contexts else ware in the code..
> 
> So the question was how to name them consistently, I have used the prefixes 
> of 'gnc-name-' and 'gnc-style-' and find them easily for possible 
> manipulation / publication in the future.
> 
> Hope this is clearer.
> 
> Regards,
> Bob
> 
> 
> On 23 June 2018 at 16:59, John Ralls  > wrote:
> 
> 
> > On Jun 23, 2018, at 4:18 AM, Robert Fewell <14ubo...@gmail.com 
> > > wrote:
> > 
> > I have been thinking about naming some widgets and changing some of the
> > entries I added with css style classes and wondered if there has been a
> > convention decided.
> > 
> > What I would like to see is a couple of unique prefixes so that one could
> > do a grep on the top level directory and obtain all such entries and maybe
> > manipulate into some sort of list that could be published some ware.
> > 
> > Doing a quick content search shows 'gnc-style-' and 'gnc-name-' would work
> > but open to suggestions.
> > 
> > This would allow those users inclined to customise the appearance more
> > easily.
> > I would probably do this on master over time.
> 
> Bob,
> 
> I’m not sure I understand what you’re suggesting. Perhaps you could suggest a 
> concrete example?
> 
> Regards,
> John Ralls
> 
> 

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

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

[Christopher Lam]

Seeking beta testers. This will not be in v3.2.

https://github.com/christopherlam/gnucash/tree/maint-balsheet-pnl

Or, anyone with a relatively recent maint can copy the file directly 
into the build's standard-reports folder: 
https://raw.githubusercontent.com/christopherlam/gnucash/maint-balsheet-pnl/gnucash/report/standard-reports/balsheet-pnl.scm


Adds new balsheet and new income-statement. I still have further ideas 
in the pipeline, just wish to check accuracy of amounts produced. Not 
all options have been implemented. Testing closing amounts through KVP 
wasn't an issue after all; the closing entries are first sought, cached, 
then analyzed as required. For posterity C could also produce noclosing 
balances for easier future reports, but I think this works well so far.


C

On 24/06/18 17:50, Christopher Lam wrote:


I think I'll forego a noclosing_balance upgrade in C.

According to https://bugzilla.gnome.org/show_bug.cgi?id=570042 the 
"Closing Entries" transactions did not always receive a special 
KVP-based flag until the commit on 
https://github.com/Gnucash/gnucash/commit/4b2800145 on datafiles 
generated from 27-11-2008 and later.


So, to find and exclude these closing entries, we can use the 
following strategies:


 1. xaccTransGetIsClosingTxn, will query the KVP flag
 2. Run a QofQuery and add xaccQueryAddClosingTransMatch (also queries
the KVP flag)
 3. Free-text search "Closing Entries" to seek these old closing entries

So a P&L report will necessarily need to do both filtering for KVP and 
free-text search.


The multicolumn report will be different enough from the old 
balance-sheet and income-statement that I think I should spin it off 
into a different report altogether, and the others will be sunsetted. 
Hopefully this new report will be broadly acceptable because the old 
reports have a *lot* of supporting unintelligible old code, especially 
to handle closing-entries as above.


C

On 24/06/18 00:51, Christopher Lam wrote:
Hi John, the split->noclosing_balance is updated in 
xaccAccountRecomputeBalance. Will continue copypasta coding until it 
works!


On Sat, 23 Jun 2018, 23:56 John Ralls > wrote:




> On Jun 22, 2018, at 9:42 PM, Christopher Lam
mailto:christopher@gmail.com>> wrote:
>
> Hi All
>
> I'm working through balance-sheet.scm and overhauling this report.
>
> At the same time, I can see that balance-sheet.scm and
income-statement.scm can be merged together.
>
> After all
>
> * balance sheet = asset/liability/equity balance at date X,
> * income statement = difference in income/expense balances at
date X and Y
>
> The issue I have is that the balance sheet can call
xaccAccountGetBalanceAsOfDate(acc,date) directly to nicely
retrieve the balance, whereas income statement cannot directly
call it because it also includes closing transactions.
>
> My proposal is to augment xaccAccountGetBalanceAsOfDate to
accept a 3rd boolean argument i.e.
xaccAccountGetBalanceAsOfDate(acc,date,ignoreclosing) which will
selectively produce the balance, ignore closing transactions.
>
> This is partly done in the last commit of

https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances
- it will augment API everywhere, and also modify Account.cpp,
especially xaccAccountRecomputeBalance which will call
xaccTransGetIsClosingTxn(xaccSplitGetParent(split)) for each
split in the account to determine closing status and cache the
balances for each split. See draft on

https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances
- this currently fails because I'm not good at C.
>
> *My query is whether it will be too expensive to call
xaccTransGetIsClosingTxn for each split in Account.cpp to produce
the split->noclosing_balance, which will be crucial to calculate
income between two dates.*
>
> *Currently this 'closing-txn' filter is done in
income-statement.scm via a "Closing Entries" string/regex filter
and xaccTransGetIsClosingTxn calls, which IMHO is not ideal either.
> *
>
> Any help welcome!
>
> P.S. if this last commit is removed, the

https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances
branch contains work-so-far for updated balance-sheet. Screenshot
https://screenshots.firefox.com/eelmGQrGCtcP6bqC/null - see the
multilevel subtotals were previously horizonal, are now vertical;
original-currency amounts, and multiple-date balance sheets.
>
> _

Chris,

Only profiling will tell how much of a performance hit this creates.

I don’t see where in your commit you’re computing the split’s
no-closing balance. Perhaps that’s why it doesn’t work?

Regards,
John Ralls

Re: [GNC-dev] Widget naming and css

[Robert Fewell]

Sorry it was not clear, so I will try again.

When I was doing the GTK3 migration I added some context styles to various
widgets but I now believe some of them should be widget names like the
following...
GncBusinessPage should really be a widget name and then with associated
styles.

So as an example I changed GncBusinessPage from a style context to a widget
name of 'gnc-name-business-page' and associated style contexts to start
with 'gnc-style-' along with some other changes I can now grep them...

grep -nHIirF 'gnc-style-'
gnucash/gnome/gnc-plugin-page-owner-tree.c:658:style_label =
"gnc-style-unknown";
gnucash/gnome/gnc-plugin-page-owner-tree.c:663:style_label =
"gnc-style-customer";
gnucash/gnome/gnc-plugin-page-owner-tree.c:668:style_label =
"gnc-style-job";
gnucash/gnome/gnc-plugin-page-owner-tree.c:673:style_label =
"gnc-style-vendor";
gnucash/gnome/gnc-plugin-page-owner-tree.c:678:style_label =
"gnc-style-employee";
gnucash/gtkbuilder/dialog-vendor.glade:559:  
gnucash/gtkbuilder/dialog-vendor.glade:796:  
gnucash/gtkbuilder/dialog-vendor.glade:830:  

grep -nHIirF 'gnc-name-'
gnucash/gnome/gnc-plugin-page-owner-tree.c:626:gtk_widget_set_name
(GTK_WIDGET(priv->widget), "gnc-name-business-page");
gnucash/gnome/window-reconcile.c:1817:gtk_widget_set_name
(debits_box, "gnc-name-reconcile-window-debits");
gnucash/gnome/window-reconcile.c:1822:gtk_widget_set_name
(credits_box, "gnc-name-reconcile-window-credits");
gnucash/gnome/window-reconcile.c:1855:gtk_widget_set_name
(frame, "gnc-name-reconcile-window-totals");
gnucash/gtkbuilder/dialog-vendor.glade:30:gnc-name-vendor-dialog

With the grep command it easily shows me what widgets have been named along
with style contexts and so I can easily apply CSS to them and possibly
reuse the style contexts else ware in the code..

So the question was how to name them consistently, I have used the prefixes
of 'gnc-name-' and 'gnc-style-' and find them easily for possible
manipulation / publication in the future.

Hope this is clearer.

Regards,
Bob


On 23 June 2018 at 16:59, John Ralls  wrote:

>
>
> > On Jun 23, 2018, at 4:18 AM, Robert Fewell <14ubo...@gmail.com> wrote:
> >
> > I have been thinking about naming some widgets and changing some of the
> > entries I added with css style classes and wondered if there has been a
> > convention decided.
> >
> > What I would like to see is a couple of unique prefixes so that one could
> > do a grep on the top level directory and obtain all such entries and
> maybe
> > manipulate into some sort of list that could be published some ware.
> >
> > Doing a quick content search shows 'gnc-style-' and 'gnc-name-' would
> work
> > but open to suggestions.
> >
> > This would allow those users inclined to customise the appearance more
> > easily.
> > I would probably do this on master over time.
>
> Bob,
>
> I’m not sure I understand what you’re suggesting. Perhaps you could
> suggest a concrete example?
>
> Regards,
> John Ralls
>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[Christopher Lam]

I think I'll forego a noclosing_balance upgrade in C.

According to https://bugzilla.gnome.org/show_bug.cgi?id=570042 the 
"Closing Entries" transactions did not always receive a special 
KVP-based flag until the commit on 
https://github.com/Gnucash/gnucash/commit/4b2800145 on datafiles 
generated from 27-11-2008 and later.


So, to find and exclude these closing entries, we can use the following 
strategies:


1. xaccTransGetIsClosingTxn, will query the KVP flag
2. Run a QofQuery and add xaccQueryAddClosingTransMatch (also queries
   the KVP flag)
3. Free-text search "Closing Entries" to seek these old closing entries

So a P&L report will necessarily need to do both filtering for KVP and 
free-text search.


The multicolumn report will be different enough from the old 
balance-sheet and income-statement that I think I should spin it off 
into a different report altogether, and the others will be sunsetted. 
Hopefully this new report will be broadly acceptable because the old 
reports have a *lot* of supporting unintelligible old code, especially 
to handle closing-entries as above.


C

On 24/06/18 00:51, Christopher Lam wrote:
Hi John, the split->noclosing_balance is updated in 
xaccAccountRecomputeBalance. Will continue copypasta coding until it 
works!


On Sat, 23 Jun 2018, 23:56 John Ralls > wrote:




> On Jun 22, 2018, at 9:42 PM, Christopher Lam
mailto:christopher@gmail.com>> wrote:
>
> Hi All
>
> I'm working through balance-sheet.scm and overhauling this report.
>
> At the same time, I can see that balance-sheet.scm and
income-statement.scm can be merged together.
>
> After all
>
> * balance sheet = asset/liability/equity balance at date X,
> * income statement = difference in income/expense balances at
date X and Y
>
> The issue I have is that the balance sheet can call
xaccAccountGetBalanceAsOfDate(acc,date) directly to nicely
retrieve the balance, whereas income statement cannot directly
call it because it also includes closing transactions.
>
> My proposal is to augment xaccAccountGetBalanceAsOfDate to
accept a 3rd boolean argument i.e.
xaccAccountGetBalanceAsOfDate(acc,date,ignoreclosing) which will
selectively produce the balance, ignore closing transactions.
>
> This is partly done in the last commit of

https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances
- it will augment API everywhere, and also modify Account.cpp,
especially xaccAccountRecomputeBalance which will call
xaccTransGetIsClosingTxn(xaccSplitGetParent(split)) for each split
in the account to determine closing status and cache the balances
for each split. See draft on

https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances
- this currently fails because I'm not good at C.
>
> *My query is whether it will be too expensive to call
xaccTransGetIsClosingTxn for each split in Account.cpp to produce
the split->noclosing_balance, which will be crucial to calculate
income between two dates.*
>
> *Currently this 'closing-txn' filter is done in
income-statement.scm via a "Closing Entries" string/regex filter
and xaccTransGetIsClosingTxn calls, which IMHO is not ideal either.
> *
>
> Any help welcome!
>
> P.S. if this last commit is removed, the

https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances
branch contains work-so-far for updated balance-sheet. Screenshot
https://screenshots.firefox.com/eelmGQrGCtcP6bqC/null - see the
multilevel subtotals were previously horizonal, are now vertical;
original-currency amounts, and multiple-date balance sheets.
>
> _

Chris,

Only profiling will tell how much of a performance hit this creates.

I don’t see where in your commit you’re computing the split’s
no-closing balance. Perhaps that’s why it doesn’t work?

Regards,
John Ralls



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

[GNC-dev] Transaction / Split Action List

[Robert Fewell]

Thank you for the feedback, I am going to leave it for now and finish some
other things along with the odd bug for now.
Bob
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Minor coding style discussion: C++ and comments

[Colin Law]

On 23 June 2018 at 23:49, John Ralls  wrote:
> ...
> For the record, I don’t care as long as all comments in a file use the same 
> style and a single commit is used to convert the comments in a particular 
> file and that commit has no other changes.

I cannot see the point in wasting time changing the format in existing
code. When it comes to understanding existing code, the comment format
will make no difference to any developer sufficiently experienced to
understand code as complex as gnucash.  In addition there is always
the slight possibility of accidentally changing code so possibly
introducing bugs.  Surely there are more important things to do.

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