Re: [GNC-dev] WebKitGtk now defaults to Gtk4

[Robert Fewell]

Can I get clarification, is that migrating to Gtk4 or move away from
WebKitGtk ?

I suppose either change would be a major one so that would be version 6.0 I
assume.
I seem to recall there was a question on release cycles but can not find
where, so if 6.0 is that still 08/03/2026 ?

Regards,
Bob

On Fri, 17 Nov 2023 at 17:15, john  wrote:

> WebKitGtk 2.43.1 was just released and one of its changes is that it's
> Gtk4 by default and one must specify a build option, -DGTK4=OFF, to use it
> with Gtk3. I asked on the webkitgtk mailing list if there's a schedule for
> dropping Gtk3 support. Carlos Garcia Campos replied "No, but it will take a
> while I'm afraid. Most of the WebKitGTK based
> applications are still GTK3, I think."
>
> So we don't have a firm deadline yet, but this is a warning that we need
> to get serious about migrating.
>
> 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] Performance regression loading account

[Robert Fewell]

Bug created, https://bugs.gnucash.org/show_bug.cgi?id=798788 with test file.
Regards,
Bob

On Thu, 16 Mar 2023 at 03:38, john  wrote:

> Bob,
>
> Please open a bug report and attach your sample test file.
>
> Regards,
> John Ralls
>
> On Mar 15, 2023, at 4:02 AM, Robert Fewell <14ubo...@gmail.com> wrote:
>
> I wanted to get some numbers on this as my test file seemed OK.
> I used Calc to create a CSV transaction import file with 8402 rows and
> some description columns with 16, 64 and 128 character random strings.
> Used this to import several times to a new empty gnucash xml file and
> added some timing for the account open command in 4.903 and 4.13 with
> results below...
>
> With 4.903
> Description 16 Characters and 16804 unique transactions / descriptions,
> 0.93, second time 0.73
> Description 64 Characters and 16804 unique transactions / descriptions,
> 2.39, second time 1.67
> Description 128 Characters and 16804 unique transactions / descriptions,
> 4.08, second time 2.90
>
> With 4.13
> Description 16 Characters and 16804 unique transactions / descriptions,
> 0.49, second time 0.35
> Description 16 Characters and 16804 unique transactions / descriptions,
> 1.22, second time 0.61
> Description 16 Characters and 16804 unique transactions / descriptions,
> 1.91, second time 0.93
>
> Regards,
> Bob
>
> On Tue, 14 Mar 2023 at 18:54, Maarten Bosmans  wrote:
>
>> Op ma 13 mrt 2023 om 04:44 schreef john :
>> > My first guess is that it's from creating a cache of quickfill entries
>> to populate a drop-down list of possible entries similar to the way the
>> transfer account field has worked for a couple of years.
>>
>> Yes, I've isolated it to the commit "Change the Register description
>> layout cell type", Bob in CC.
>> That branch adds the combobox and quickfill to the description field
>> of the register. In my case those are fairly long (~100 chars) and all
>> unique strings, as they come frome downloaded bank statements and
>> include a timestamp, account holder, actual description, etc. So for
>> my use case having a combo box to easy filling out new items is not
>> that useful anyway. May be we can think of a way to adapt the
>> behaviour to be useful in Bob's case (I suppose manual entry of a
>> short and often reused description text), but not slow down my case?
>>
>> > An obvious optimization is to get a collation key with
>> g_utf8_collate_key for each string and use that for doing the actual
>> sorting/ordered inserting. It's still a char-by-char comparison but it
>> saves having to validate and normalize the strings on every compare.
>> I will have a look into storing the collated string in the QuickFill.
>> That probably doubles the memory usage, but should not be too bad.
>>
>> Maarten
>>
>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Performance regression loading account

[Robert Fewell]

I wanted to get some numbers on this as my test file seemed OK.
I used Calc to create a CSV transaction import file with 8402 rows and some
description columns with 16, 64 and 128 character random strings.
Used this to import several times to a new empty gnucash xml file and added
some timing for the account open command in 4.903 and 4.13 with results
below...

With 4.903
Description 16 Characters and 16804 unique transactions / descriptions,
0.93, second time 0.73
Description 64 Characters and 16804 unique transactions / descriptions,
2.39, second time 1.67
Description 128 Characters and 16804 unique transactions / descriptions,
4.08, second time 2.90

With 4.13
Description 16 Characters and 16804 unique transactions / descriptions,
0.49, second time 0.35
Description 16 Characters and 16804 unique transactions / descriptions,
1.22, second time 0.61
Description 16 Characters and 16804 unique transactions / descriptions,
1.91, second time 0.93

Regards,
Bob

On Tue, 14 Mar 2023 at 18:54, Maarten Bosmans  wrote:

> Op ma 13 mrt 2023 om 04:44 schreef john :
> > My first guess is that it's from creating a cache of quickfill entries
> to populate a drop-down list of possible entries similar to the way the
> transfer account field has worked for a couple of years.
>
> Yes, I've isolated it to the commit "Change the Register description
> layout cell type", Bob in CC.
> That branch adds the combobox and quickfill to the description field
> of the register. In my case those are fairly long (~100 chars) and all
> unique strings, as they come frome downloaded bank statements and
> include a timestamp, account holder, actual description, etc. So for
> my use case having a combo box to easy filling out new items is not
> that useful anyway. May be we can think of a way to adapt the
> behaviour to be useful in Bob's case (I suppose manual entry of a
> short and often reused description text), but not slow down my case?
>
> > An obvious optimization is to get a collation key with
> g_utf8_collate_key for each string and use that for doing the actual
> sorting/ordered inserting. It's still a char-by-char comparison but it
> saves having to validate and normalize the strings on every compare.
> I will have a look into storing the collated string in the QuickFill.
> That probably doubles the memory usage, but should not be too bad.
>
> Maarten
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Performance regression loading account

[Robert Fewell]

Maarten,
I am curious how you created that graph?
Also can you build 4.903?

I am wondering if it is down to the sorting of the list store, by default
gnc_item_list_new has sorting enabled so on every entry the list will be
sorted.
I wonder if it was disabled and in gnc_split_register_load we enabled the
sorting at the end after all entries added it would improve the situation.
I only have 719 transactions for an account in my test file so not sure I
will see the difference.
Regards,
Bob



On Mon, 13 Mar 2023 at 03:44, john  wrote:

>
>
> > On Mar 12, 2023, at 1:28 PM, Maarten Bosmans 
> wrote:
> >
> > Hi all,
> >
> > When testing the 4.902 flatpak, I noticed that loading an account
> > takes several (~4.5) seconds. This account has about 24k transactions
> > and loads in less than half a second on the GnuCash 4.8 from my
> > distribution. Is this a regression because of a code change, or
> > perhaps simply the result of a debug build in the flatpak?
> >
> > From the attached flamegraph you can see that a lot of time is spent
> > in `g_utf8_collate` for the quickfill insert. That function does not
> > appear below `gnc_quickfill_insert` for the 4.8 run. I did a quick
> > search in the git history to see that may be some caller was changed
> > to the `QUICKFILL_ALPHA` sort method, but could not easily find such a
> > thing.
> >
> > Another difference with 4.8 is stat `gnc_table_realize_gui` (which
> > takes 0.85s) does not appear below
> > `gnc_plugin_page_register_create_widget` and that function only takes
> > 0.03s in total. This time seems to be spent in Gtk.
> >
> > I don't think this is a release blocking bug, but GnuCash feels quite
> > sluggish to me, so it would be nice to fix this papercut before 5.0.
> > Any pointers on how to proceed?
>
>
> My first guess is that it's from creating a cache of quickfill entries to
> populate a drop-down list of possible entries similar to the way the
> transfer account field has worked for a couple of years.
>
> An obvious optimization is to get a collation key with g_utf8_collate_key
> for each string and use that for doing the actual sorting/ordered
> inserting. It's still a char-by-char comparison but it saves having to
> validate and normalize the strings on every compare.
>
> Regards,
> John Ralls
>
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[Robert Fewell]

I have installed 4.901 in my Windows 11 VM and all seems to be working OK.
If you are still having trouble, please raise separate bugs so it can be
looked into and not forgotten.

Regards,
Bob

On Mon, 6 Feb 2023 at 04:08, john  wrote:

> Neither of which seem to be in the bug tracker.
>
> Regards,
> John Ralls
>
>
> > On Feb 5, 2023, at 7:54 PM, Glenn Fowler  wrote:
> >
> > Thank you to the team for the continued development!
> >
> > I just installed 4.901 on W10 and just pointing out two bugs still
> persist
> > from 4.900:
> >
> > 1. Tip of the day cannot be suppressed
> > 2. Keyboard shortcut for "Manage Document Link" is still missing
> >
> > Thank you
> >
> > On Sun, Feb 5, 2023 at 2:51 PM John Ralls  jra...@ceridwen.us>> wrote:
> >
> >> The GnuCash development team announces GnuCash 4.901, the second
> unstable
> >> release leading to GnuCash 5.0.
> >>
> >> This is an unstable release for testing purposes. Do not use it with
> >> production data! Make a copy of your book to test this release.
> >>
> >> New Features
> >>
> >>• A new Stock Transaction Assistant to guide you through entering
> >> most investment transactions for stocks, bonds, and mutual funds. You
> can
> >> access it from Actions>Stock Assistant when you have the Accounts page
> ora
> >> Stock or Fund account register open.
> >>• A new Investment Lots report showing a graph of capital gains
> >> and losses in a period by investment lot. Note that if you don't use the
> >> View Lots dialog to manage capital gains and losses this report won't
> have
> >> anything to show you. Use Reports>Assets & Liabilities>Investment Lots
> to
> >> see the report.
> >>• A new tab on the New/Edit Account dialog called More Properties
> >> includes entries to set a high and low limit on an account. That's
> coupled
> >> to a new column that's available on the Accounts Page, Balance Limit. If
> >> you set a high or low limit and the account balance falls above or below
> >> the respective limit an indicator will be shown in the Balance Limit
> column.
> >>• The description field quickfill in the register now displays a
> >> drop-down list of possible completions instead of just one inline
> >> completion.
> >>• File import menu items for the MT940, MT942, and DTAUS formats
> >> is replaced with a single Import from AQBanking that supports importing
> any
> >> file format supported by AQBanking, including the frequently requested
> CAMT.
> >>• The report generated by the Print Invoice button on the Edit
> >> Invoice tab can now be configured as a book option at teh bottom of the
> >> Business tab; this permits selecting a saved configuration of one of the
> >> standard invoice reports. Another option enables a delay, during which a
> >> dialog box will appear enabling the user to select a different report.
> >>
> >> Note: When saving a configuration make sure that the invoice number is
> not
> >> set or you'll get that particular invoice instead of the one that you
> >> pressed the button for.
> >>
> >> Between 4.900 and 4.901, the following bugfixes were accomplished:
> >>
> >> The following fixes will also appear in GnuCash 4.14:
> >>• Bug 797477 - Manual foreign transaction from APAR to another
> >> doesn't trigger price input
> >>• Bug 797725 - Untranslatable string "For Period Covering ~a to
> ~a"
> >>• Bug 798734 - Aging Reports don't handle mixed currency payments
> >> and invoices without Trading Accounts
> >>• Bug 798737 - Minor grammatical error - 'for' missing in 'You
> >> will be asked a conversion rate for each.'
> >>• Bug 798740 - Build fails with gcc 13
> >>• Bug 798747 - Crash in Investment Portfolio report
> >>
> >> The following additional bug fixes are in unstable only:
> >>
> >>• Bug 753307 - Custom Report be selectable as default Report for
> >> Printing
> >> Change the preference in Business->'Report for Printing' to be saved as
> a
> >> book property and allow the selection of any Invoice Report to be used
> as
> >> the default.
> >>
> >>• Bug 794028 - CSV import, default to matching full account name
> >> If the account map doesn't yield a result, try to map the import string
> >> against existing accounts' full names
> >>
> >>• Bug 796955 - Import CSV - Single-line two-currency transactions
> >> can't be imported
> >>• Use a provided price if the transfer account uses a
> >> different commodity from the base account's; apply it as transfer
> amount =
> >> base amount * price.
> >>• Add a transfer amount column option to avoid the
> >> rounding that might arise from having an inexact price.
> >>• Bug 797756 - Currency format setting is ignored
> >>• Bug 798292 - csv Import Transactions Ignores Multi-Splits
> >>• Bug 798475 - GNCAccountSel could have shortcuts
> >>• Bug 798730 - Open report doesn't remember selected accounts
> over
> >> restart
> >>  

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

[Robert Fewell]

For information,
I have updated my windows build machine and successfully built the current
master 4.900 version which resulted in a file size of 150M.
With an existing install of 4.13, I was able to install my 4.900 version
resulting in no errors in the trace file.
I was also able to install the current nightly master version successfully.

Also tried to do the same on my Windows 11 VM, again starting from 4.13 was
able to successfully install my version and also the nightly master version.

Regards,
Bob

On Fri, 13 Jan 2023 at 23:50, David H  wrote:

> Hi again John and Devs,
>
> I've just updated my Ubuntu 22.10 flatpak to the Gnucash 4.900 beta and am
> having the same issues as on Win 10.  Attached are trace files from each OS
> in case it helps.
>
> Regards David H
>
>
> On Thu, 12 Jan 2023 at 08:25, David H  wrote:
>
> > Hi John and devs,
> >
> > Thanks for the update.  I had a number of problems as per the following:-
> >
> > System
> > ---
> >
> > Lenovo laptop, Intel i5, 8 Gb ram, Gnucash 4.13 / Finance Quote 1.54 /
> Win
> > 10 Pro, Version 22H2, OS Build 19044.2486, Win32 strawberry-perl 5.32.1.1
> > #1 Sun Jan 24 12:17:47 2021 i386
> >
> > Process
> > 
> >
> > Installed 4.900 which auto uninstalled 4.13.
> > Started Gnucash 4.900 which displayed the "Tip of The Day" and then the
> > "Welcome to Gnucash" dialogs.
> > Unfortunately Gnucash 4.900 didn't seem to find my xml data file and the
> > Most Recent file list just displays "RecentFile0Action" (Function name?)
> > instead of the usual 2-3 file names.
> > Manually opened the last file used which is just a copy of my usual
> > Gnucash file, it opened fine and re-displayed all the tabs that were
> > previously open.
> > Got the message about the Budget amounts being fixed during the open
> > process.
> > It doesn't seem to be finding my saved report options - the report names
> > are included in the save report config list but no options and the
> Accounts
> > Selected has reverted to all accounts.
> > Get quotes is now not working - the button is simply greyed out.
> > Like Glenn I also can't turn off the Tip of the Day or the Display
> Welcome
> > Dialog Again? and on exiting and restarting Gnucash I repeatedly get
> > prompted to Create a new set of accounts / Import my QIF files / Open the
> > new user tutorial.
> >
> > Also yesterday I happened to update and save Report Options for a saved
> > report configuration  and it seemed Gnucash crashed, repeating the
> process
> > today did NOT result in a crash.
> >
> > Hope this helps and once again thanks to you and the other devs for all
> > your hard work on Gnucash.
> >
> > Regards David H.
> >
> >
> >
> >
> >
> >
> > On Tue, 10 Jan 2023 at 15:03, John Ralls  wrote:
> >
> >> The GnuCash development team announces GnuCash 4.900, the first unstable
> >> release leading to GnuCash 5.0.
> >>
> >> This is an unstable release for testing purposes. Do not use it with
> >> production data! Make a copy of your book to test this release.
> >>
> >> New Features
> >>
> >> A new Stock Transaction Assistant to guide you through entering most
> >> investment transactions for stocks, bonds, and mutual funds. You can
> access
> >> it from Actions>Stock Assistant when you have the Accounts page ora
> Stock
> >> or Fund account register open.
> >> A new Investment Lots report showing a graph of capital gains and
> >> losses in a period by investment lot. Note that if you don't use the
> View
> >> Lots dialog to manage capital gains and losses this report won't have
> >> anything to show you. Use Reports>Assets & Liabilities>Investment Lots
> to
> >> see the report.
> >> A new tab on the New/Edit Account dialog called More Properties
> >> includes entries to set a high and low limit on an account. That's
> coupled
> >> to a new column that's available on the Accounts Page, Balance Limit. If
> >> you set a high or low limit and the account balance falls above or below
> >> the respective limit an indicator will be shown in the Balance Limit
> column.
> >> The description field quickfill in the register now displays a
> >> drop-down list of possible completions instead of just one inline
> >> completion.
> >> File import menu items for the MT940, MT942, and DTAUS formats is
> >> replaced with a single Import from AQBanking that supports importing any
> >> file format supported by AQBanking, including the frequently requested
> CAMT.
> >>
> >> Between 4.13 and 4.900, the following bugfixes were accomplished:
> >> The following fixes will also appear in GnuCash 4.14:
> >>
> >> Bug 798588 - sx scrubbing was using incorrect free function
> >> Bug 798625 - "Last up through report date" changed in 4.12
> >> Bug 798679 - Unicode normalization should be used for comparison but
> >> not stored.
> >> Bug 798702 - Crash in gnc_plugin_page_focus_idle_destroy() closing a
> >> report before it completes.
> >> Bug 798705 - New: UI string mismatch: OK vs. Next
> >>

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

[Robert Fewell]

I am not sure but it looks like the gnucash-4.900.setup.exe is not
complete, the file size is 137M compared to the latest master at 157M and
4.13 is 146M.

I downloaded and installed the gnucash-4.900.setup.exe from code and got
the same startup error that David reported.
Will need to look at the file list error and check what it does when the
list is empty.

Reinstalled 4.13 and all seemed OK again.
Downloaded the latest master gnucash-4.900-2023-01-12-git. and
installed that and Gnucash opened successfully.

David, if you have time try downloading the one I used from the nightlies
at https://code.gnucash.org/builds/win32/master

Regards,
Bob

On Thu, 12 Jan 2023 at 07:50, Frank H. Ellenberger <
frank.h.ellenber...@gmail.com> wrote:

> Hi Fred,
>
> Am 12.01.23 um 07:16 schrieb Fred Tydeman:
> > Since I do not know where it will put that data, nor how to override, I
> > declined.
>
> with the option --user it seems to install in my case below
> /home/frank/.local/share/flatpak/runtime/
>
> 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] Build failure

[Robert Fewell]

Alex,
Just for info I updated my Fedora test VM to 37 and was able to do a clean
build.

Regards,
Bob

On Wed, 23 Nov 2022 at 20:06, Alex Aycinena  wrote:

> Hello,
>
> I was doing a clean build with a new checkout on a Fedora 37 VM and
> received the following (this was after a partial build that resulted in the
> terminal window disappearing, so I couldn't see any messages; then I opened
> a new terminal window and started the build again):
>
> [gnucash-dev@HPFedora37VM gnucash-clean-build]$ ninja-build
> [4/239] Building CXX object
> gnucash/im...-csv-import.dir/gnc-imp-props-tx.cpp.o
> FAILED:
>
> gnucash/import-export/csv-imp/CMakeFiles/gnc-csv-import.dir/gnc-imp-props-tx.cpp.o
>
> /usr/lib64/ccache/c++ -DBOOST_ATOMIC_DYN_LINK -DBOOST_ATOMIC_NO_LIB
> -DBOOST_CHRONO_DYN_LINK -DBOOST_CHRONO_NO_LIB -DBOOST_DATE_TIME_DYN_LINK
> -DBOOST_DATE_TIME_NO_LIB -DBOOST_FILESYSTEM_DYN_LINK
> -DBOOST_FILESYSTEM_NO_LIB -DBOOST_LOCALE_DYN_LINK -DBOOST_LOCALE_NO_LIB
> -DBOOST_PROGRAM_OPTIONS_DYN_LINK -DBOOST_PROGRAM_OPTIONS_NO_LIB
> -DBOOST_REGEX_DYN_LINK -DBOOST_REGEX_NO_LIB -DBOOST_SYSTEM_DYN_LINK
> -DBOOST_SYSTEM_NO_LIB -DBOOST_THREAD_DYN_LINK -DBOOST_THREAD_NO_LIB
> -DG_LOG_DOMAIN=\"gnc.import.csv\" -DHAVE_CONFIG_H -DHAVE_GUILE20
> -D_GNU_SOURCE -Dgnc_csv_import_EXPORTS
> -I/home/gnucash-dev/gitcheckouts/gnucash-clean/borrowed/goffice
>
> -I/home/gnucash-dev/gitcheckouts/gnucash-clean/gnucash/import-export/csv-imp
> -I/home/gnucash-dev/gitcheckouts/gnucash-clean/gnucash/import-export
> -I/home/gnucash-dev/gitcheckouts/gnucash-clean/gnucash/gnome-utils
> -I/home/gnucash-dev/gitcheckouts/gnucash-clean/libgnucash/app-utils
> -I/home/gnucash-dev/gitcheckouts/gnucash-clean/libgnucash/engine
> -I/home/gnucash-dev/gitcheckouts/gnucash-clean-build/common
> -I/home/gnucash-dev/gitcheckouts/gnucash-clean/common
> -I/home/gnucash-dev/gitcheckouts/gnucash-clean/borrowed/libc
> -I/home/gnucash-dev/gitcheckouts/gnucash-clean-build/libgnucash/core-utils
> -I/home/gnucash-dev/gitcheckouts/gnucash-clean/libgnucash/core-utils
>
> -I/home/gnucash-dev/gitcheckouts/gnucash-clean/libgnucash/app-utils/calculation
> -I/home/gnucash-dev/gitcheckouts/gnucash-clean/bindings/guile
> -I/usr/include/guile/2.0
> -I/home/gnucash-dev/gitcheckouts/gnucash-clean/libgnucash/tax
> -I/home/gnucash-dev/gitcheckouts/gnucash-clean/libgnucash/backend/xml
> -isystem /usr/include/glib-2.0 -isystem /usr/lib64/glib-2.0/include
> -isystem /usr/include/sysprof-4 -isystem /usr/include/libxml2 -isystem
> /usr/include/gtk-3.0 -isystem /usr/include/pango-1.0 -isystem
> /usr/include/harfbuzz -isystem /usr/include/freetype2 -isystem
> /usr/include/libpng16 -isystem /usr/include/libmount -isystem
> /usr/include/blkid -isystem /usr/include/fribidi -isystem
> /usr/include/cairo -isystem /usr/include/pixman-1 -isystem
> /usr/include/gdk-pixbuf-2.0 -isystem /usr/include/gio-unix-2.0 -isystem
> /usr/include/cloudproviders -isystem /usr/include/atk-1.0 -isystem
> /usr/include/at-spi2-atk/2.0 -isystem /usr/include/dbus-1.0 -isystem
> /usr/lib64/dbus-1.0/include -isystem /usr/include/at-spi-2.0
> -Wno-error=deprecated-declarations  -Werror -Wall -Wmissing-declarations
> -Wno-unused -Wno-error=parentheses  -g -fPIC -pthread -std=c++17 -MD -MT
>
> gnucash/import-export/csv-imp/CMakeFiles/gnc-csv-import.dir/gnc-imp-props-tx.cpp.o
> -MF
>
> gnucash/import-export/csv-imp/CMakeFiles/gnc-csv-import.dir/gnc-imp-props-tx.cpp.o.d
> -o
>
> gnucash/import-export/csv-imp/CMakeFiles/gnc-csv-import.dir/gnc-imp-props-tx.cpp.o
> -c
>
> /home/gnucash-dev/gitcheckouts/gnucash-clean/gnucash/import-export/csv-imp/gnc-imp-props-tx.cpp
> c++: fatal error: Killed signal terminated program cc1plus
> compilation terminated.
> [6/239] Building CXX object
> gnucash/im...v-import.dir/gnc-imp-props-price.cpp.o
> ninja: build stopped: subcommand failed.
> [gnucash-dev@HPFedora37VM gnucash-clean-build]$
>
> Has anyone else seen this? I believe Geert builds on Fedora. Are you having
> problems? Ayn suggestions?
>
> Thanks,
>
> Alex
> ___
> 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] Co-Owner (v0.3.3)

[Robert Fewell]

Ralf,
I have had a look and was able to pull your branch and build it but needed
to replace the de.po file with one from maint but that is besides the point.

I have added a patch file with some changes I have noticed but you will
need to fix / test them.
I am not sure whether you have changed dialog-customer.glade by mistake or
in the middle of a change but there were some changes to coowner.

As for the menus, they are present and the Co-Owner Overview page displays
but I could not create a new Co-Owner due to issues with the glade files.

Regards,
Bob

On Thu, 30 Jun 2022 at 14:03, Ralf Zerres  wrote:

> Rob,
>
> thanks for anwering. And yes, i do have a specific problem.
> It's more a comprehension problem when creating new menu entries.
>
> What i extended
> ===
>
> This is an extact just to explain the involed gui stuff:
>
>
> inside  "gnucash/gnome/gnc-plugin-business.c" i did create new/needed
>  "BusinessActions"
>
>  /* Co-Owner submenu */
>  { "CoOwnerMenuAction", NULL, N_("Co-Owner"), NULL, NULL, NULL },
>
>  {
> "CoOwnerOverviewPageAction", NULL, N_("Co-Owners
> Overview"),NULL,
> N_("Open a Co-Owner overview page"),
> G_CALLBACK (gnc_plugin_business_cmd_coowner_page)
> },
>
> ...
>
> {
> "CoOwnerNewSettlementOpenAction", NULL, N_("New
> _Settlement..."), NULL,
> N_("Open the New Settlement dialog"),
> G_CALLBACK (gnc_plugin_business_cmd_coowner_new_settlement)
> },
>
> As well as the associated callbacks.
>
> UI definitions are in
>
> * gnucash/ui/gnc-plugin-business-ui.xml
>
> that introduce a new menu "CoOwnerMenuAction" with menuitems
> "COOwnerNewCoOwnerOpenAction", etc. They extend the given placeholder
> "AdditionalMenusPlacehoder" inside menu "Business". Fine until here.
>
> The book handling will use "Set" and "Get" functions from
>  "libgnucash/engine/gncCoOwner.c". To make that accessible, funtions in
> "libgnucash/engine/gncOwner.c" are extended to handle the CoOwner
> cases. That means, we now handle a new "owner->type =
> GNC_OWNER_COOWNER".
>
> Bindings have been enhanced
>
> * bindings/business-core.i
> * bindings/python/gnucash_business.py
> * bindings/python/gnucash_core.i
>
> Next i had to extend the "OT" actions to have the needed new callbacks
> for the owner_tree.
>
> * gnucash/gnome/gnc-plugin-page-owner-tree.c
> * gnc-plugin-page-owner-tree-ui.xml
>
> This should make them accessible as "plugin-page"-s, right?
>
> conlusion
> =
>
> All that stuff compiles.
> But i never see any new submenu entry "CoOwner" nor do i get the GUI
> for the Owner-Tree stuff.
> I'm on arch, all the depends like in "util/ci/actions/archlinux-
> test/Dockerfile".
>
> What is needed to make the subsystem use the new Menus?
>
> Greetings
> Ralf
>
> PS: you will find my coowner branch at
> https://github.com/rzerres/gnucash/tree/coowner
>
> Am Donnerstag, dem 30.06.2022 um 08:39 +0100 schrieb Robert Fewell:
> > Ralf,
> > The current minimum Gtk3 version is 3.22.30. All the glade files have
> > been generated with Glade 3.38.2 with the minimum Gtk version set to
> > 3.22.
> >
> > Is there a specific problem you have found that you need help with?
> >
> > Regards,
> > Bob
> >
> > >
>
diff --git a/gnucash/gnome/dialog-coowner.c b/gnucash/gnome/dialog-coowner.c
index 18fb14fc4..7bc509537 100644
--- a/gnucash/gnome/dialog-coowner.c
+++ b/gnucash/gnome/dialog-coowner.c
@@ -596,8 +596,9 @@ gnc_coowner_new_window (GtkWindow *parent,
 
 /* Find the dialog */
 builder = gtk_builder_new();
-gnc_builder_add_from_file (builder, "dialog-coowner.glade", "taxincluded_store");
+gnc_builder_add_from_file (builder, "dialog-coowner.glade", "tax_included_store");
 gnc_builder_add_from_file (builder, "dialog-coowner.glade", "taxtable_store");
+gnc_builder_add_from_file (builder, "dialog-coowner.glade", "terms_store");
 gnc_builder_add_from_file (builder, "dialog-coowner.glade", "coowner_dialog");
 ow->dialog = GTK_WIDGET(gtk_builder_get_object (builder, "coowner_dialog"));
 gtk_window_set_transient_for (GTK_WINDOW(ow->dialog), parent);
@@ -633,17 +634,17 @@ gnc_coowner_new_window (GtkWindow *parent,
 ow->apt_share = edit;
 gtk_widget_show (edit);
 
-hbox = GTK_WIDGET(gtk_builder_get_object (builder, "apt_share_box"

Re: [GNC-dev] Co-Owner (v0.3.3)

[Robert Fewell]

Ralf,
I will have a look tomorrow.

Regards,
Bob

On Thu, 30 Jun 2022 at 14:03, Ralf Zerres  wrote:

> Rob,
>
> thanks for anwering. And yes, i do have a specific problem.
> It's more a comprehension problem when creating new menu entries.
>
> What i extended
> ===
>
> This is an extact just to explain the involed gui stuff:
>
>
> inside  "gnucash/gnome/gnc-plugin-business.c" i did create new/needed
>  "BusinessActions"
>
>  /* Co-Owner submenu */
>  { "CoOwnerMenuAction", NULL, N_("Co-Owner"), NULL, NULL, NULL },
>
>  {
> "CoOwnerOverviewPageAction", NULL, N_("Co-Owners
> Overview"),NULL,
> N_("Open a Co-Owner overview page"),
> G_CALLBACK (gnc_plugin_business_cmd_coowner_page)
> },
>
> ...
>
> {
> "CoOwnerNewSettlementOpenAction", NULL, N_("New
> _Settlement..."), NULL,
> N_("Open the New Settlement dialog"),
> G_CALLBACK (gnc_plugin_business_cmd_coowner_new_settlement)
> },
>
> As well as the associated callbacks.
>
> UI definitions are in
>
> * gnucash/ui/gnc-plugin-business-ui.xml
>
> that introduce a new menu "CoOwnerMenuAction" with menuitems
> "COOwnerNewCoOwnerOpenAction", etc. They extend the given placeholder
> "AdditionalMenusPlacehoder" inside menu "Business". Fine until here.
>
> The book handling will use "Set" and "Get" functions from
>  "libgnucash/engine/gncCoOwner.c". To make that accessible, funtions in
> "libgnucash/engine/gncOwner.c" are extended to handle the CoOwner
> cases. That means, we now handle a new "owner->type =
> GNC_OWNER_COOWNER".
>
> Bindings have been enhanced
>
> * bindings/business-core.i
> * bindings/python/gnucash_business.py
> * bindings/python/gnucash_core.i
>
> Next i had to extend the "OT" actions to have the needed new callbacks
> for the owner_tree.
>
> * gnucash/gnome/gnc-plugin-page-owner-tree.c
> * gnc-plugin-page-owner-tree-ui.xml
>
> This should make them accessible as "plugin-page"-s, right?
>
> conlusion
> =
>
> All that stuff compiles.
> But i never see any new submenu entry "CoOwner" nor do i get the GUI
> for the Owner-Tree stuff.
> I'm on arch, all the depends like in "util/ci/actions/archlinux-
> test/Dockerfile".
>
> What is needed to make the subsystem use the new Menus?
>
> Greetings
> Ralf
>
> PS: you will find my coowner branch at
> https://github.com/rzerres/gnucash/tree/coowner
>
> Am Donnerstag, dem 30.06.2022 um 08:39 +0100 schrieb Robert Fewell:
> > Ralf,
> > The current minimum Gtk3 version is 3.22.30. All the glade files have
> > been generated with Glade 3.38.2 with the minimum Gtk version set to
> > 3.22.
> >
> > Is there a specific problem you have found that you need help with?
> >
> > Regards,
> > Bob
> >
> > >
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] How to start fresh

[Robert Fewell]

Eric,
The only way I can think of is this but make sure you have a backup of your
existing work.

1) Make sure you are saving xml files and under Edit->Preferences->General
compression is not set.
2) Use File->Export->'Export Accounts' to create a new file with the
accounts.
3) Open the new file in Gnucash and create a single dummy customer and save.
4) Open the original file in a text editor and do a search for
'gnc:GncCustomer'.
You should find one line with the customer count, copy this line to the
new file opened in a text editor.
And then you will find a large section of customers, copy the whole
section and replace the dummy customer with it.
5) Open the new file in Gnucash and check under
Business->Customer->'Customer Overview' that you have all your customers.
6) On the Accounts tab, do a Check and Repair which is under 'Actions'

If this is OK, then you could search for 'gnc:GncVendor'

This is not really supported but as the file is empty should be OK.
Do not be tempted to copy other bits as some parts are linked to others in
a complex way.

Regards,
Bob



On Wed, 29 Jun 2022 at 17:50, Eric Hammond  wrote:

> Hi all,
>
> I set up Gnucash as best possible by extracting what I could from my
> crashed Quicken, and many Excel spreadsheets. And 6 months of work.
> I got all the info in, but not working properly.
> I want to start fresh, almost.
> I have created clean CSV files for the AR and AP; and transaction files to
> fill in the bank ledgers.
> What I need is to clean Gnucash of everything Except the account tree,
> vendor and customer database.
> (The exported version of vendor and customer data leaves out everything
> but name and ID.)
>
> Any ideas on how to do this, or how to not need to do this are appreciated.
>
> Thanks,
> Eric
>
> -Original Message-
> From: gnucash-devel 
> On Behalf Of gnucash-devel-requ...@gnucash.org
> Sent: Wednesday, June 29, 2022 9:00 AM
> To: gnucash-devel@gnucash.org
> Subject: gnucash-devel Digest, Vol 231, Issue 11
>
> Send gnucash-devel mailing list submissions to
> gnucash-devel@gnucash.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> or, via email, send a message with subject or body 'help' to
> gnucash-devel-requ...@gnucash.org
>
> You can reach the person managing the list at
> gnucash-devel-ow...@gnucash.org
>
> When replying, please edit your Subject line so it is more specific than
> "Re: Contents of gnucash-devel digest..."
>
>
> Today's Topics:
>
>1. Re:  Dummy lines in dialog-commodity.glade; Unification of
>   "Namespace" and "Type" (Robert Fewell)
>
>
> --
>
> Message: 1
> Date: Tue, 28 Jun 2022 17:23:03 +0100
> From: Robert Fewell <14ubo...@gmail.com>
> To: "Frank H. Ellenberger" 
> Cc: gnucash-devel 
> Subject: Re: [GNC-dev] Dummy lines in dialog-commodity.glade;
> Unification of "Namespace" and "Type"
> Message-ID:
> <
> camy+hksuqhfzmqhbmoxfq-3v6svrh4zyzp11opox448grrg...@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Frank,
> I think those dummy entries can be removed, they were default entries in
> list stores so maybe in the past glade list stores needed them but I do not
> think so now but will check.
>
> As for 'Type', in dialog-commodity.glade it is used twice which could be
> changed to 'N_amespace' and also change existing entry in
> dialog-price.glade to match so accelerator keys do not conflict. The second
> dialog is used when in the account tree and create a 'New Account' with
> 'Account Type' of 'Stock' and presses the 'Select...' button on
> 'Security/currency'.
>
> Regards,
> Bob
>
> On Tue, 28 Jun 2022 at 02:33, Frank H. Ellenberger <
> frank.h.ellenber...@gmail.com> wrote:
>
> > Hi Bob,
> >
> > I just stumbled over at least 2 lines with ' translatable="yes">Dummy
> > '
> > Are they really somewhere displayed to the user or can we drop the
> > translatable flag?
> >
> > Do you remember similar cases, perhaps after looking in a dictionary
> > as described under 'Recycle already existing strings in
> > https://wiki.gnucash.org/wiki/I18N#General_Thoughts?
> >
> > While working on the docs. we found in
> >
> > https://code.gnucash.org/docs/de/gnucash-help/tool-security-edit.html#
> > tool-commodity different labels "Namespace" in the database window and
> > "Type" in this dialog for the same element. IMHO we

Re: [GNC-dev] Co-Owner (v0.3.0)

[Robert Fewell]

Ralf,
The current minimum Gtk3 version is 3.22.30. All the glade files have been
generated with Glade 3.38.2 with the minimum Gtk version set to 3.22.

Is there a specific problem you have found that you need help with?

Regards,
Bob

On Wed, 29 Jun 2022 at 18:32, Ralf Zerres  wrote:

> Hey all,
>
> I'm still active on hacking the coowner branch.
> It's quite a stony path, but I do my best and got into the code
> structure quite well. The active, rebases branch is now called
> `cooowner`. No i do get stuck on two nasty problems. Appreciate your
> advice:
>
> * seems there is the need of a specific GTK environment
>   Which one is needed to use glade and code integration (seems plaind
> 3.x version isn't enough)
>
> * given situation: compiles, but i introduced a regression
>
> 11:23:34 ERROR  gboolean
> qof_choice_add_class(const char*, char*, char*): assertion
> 'qof_object_is_choice(select)' failed
>
>  * debug gnucash
> build path:
> cd ~/build-coowner;
> cmake -D CMAKE_BUILD_TYPE=Debug -D CMAKE_INSTALL_PREFIX=./install -
> G Ninja ..)
>
> no i'm strugglin within gdb. Since the app is multi-threaded, i
> like to simplify the debug session and wonder if it would be possible
> to just run with a singel thread?
>
> * does gnucash have a chat for active development (mattermost, discord,
> et al?)
>
> Ralf
>
> Am Dienstag, dem 14.06.2022 um 11:18 +0200 schrieb Ralf Zerres:
> > Dear list,
> >
> > thanks for all your answers that far. It helped me quite a bit to get
> > into the deeper code structure.
> >
> > For all the interested parties i will summerize the intend and
> > structure of the branch, that is served at github at
> >
> > https://github.com/rzerres/gnucash/tree/wip-coowner
> >
> > The workflow in this repo has been adopted to make use of the github
> > CI. It will check the branch maint and wip-coowner.
> >
> >
> > Status
> > ==
> >
> > Given code does compile ...
> >
> > All needed parts have been implemented.
> > I don't expect to have more structure changes in the near future.
> >
> > This is the foundation for new reports. They will rely and consume
> > properties available in the new coonwer specific entities.
> > A proof of concept report (based on new-owner-reoirt,scm) is
> > included.
> >
> >
> > the backend
> > ===
> >
> > * backend core (libgnucash/engine):
> >   `coowner[P].[h,c] serves functionality a an `gncOwner` child, like
> >   Customer, Employee and Vendor do.
> >   The GncCoOwner stucture has generic parameters (as used in the
> >   other business modules) and CoOnwer specific stuff
> >   (apartment share, apartment unit, distribution_key).
> >   With that in place, it shouldn't be difficult to extend and adopt.
> >   Parameter hadling will need more love.
> >
> > * all involved engine helpers (gncAddress, gncBusiness, gncEntry,
> >   gncIDSearch, gncInvoice, gncJob and gncTaxTable) have been adopted
> >   to handle the new CoOwner type.
> >
> > * backends for sql and xml have been adopted to handle CoOwner
> >
> > * apt-utils are aware of gncCoOwner (business-options and
> >   business-preferences)
> >
> > * gnome-plugins are enhanced to handle the Co-Owner type
> >
> > * basic tests (test-coowner.c and test-business-core.scm) are in
> > place.
> >
> >
> > the frontend
> > 
> >
> > * gnome dialogs have been implemented to address the task you already
> >   know from the other business types.
> >   (gnucash/gnome/dialog-coowner_*)
> >
> >   `dialog-coowner.c provide the CoOwner aware
> >   callbacks, service dialogs have been enhanced
> >   (dialog_invoice, dialog-order, dialog-payment)
> >
> > * gnome business plugins (gnucash/gnome/gnc-plugin-business)
> >   and gnome-utils have been enhanced to support
> >   Co-Owner handling, as well as the helpers
> >   (gncplugin-page-invoice, gnc-plugin-page-owner-tree, search-owner)
> >
> > * I am aware, that the given menu-structure is based on the
> >   legacy gtk menu system (depreciated since gtk v3.10), that uses
> >   an xml file based aproach (gnucash/ui).
> >   It will be another big change to migrate towards the gtk4 provided
> >   GMenu system.
> >
> > * I did adapt the source to have the CoOwner actions.
> >   (gnc-plugin-business-ui.xml)
> >
> > * Glade sources (gnucash/gtkbuilder) have been adopted to make use
> >   of Co-Owner callbacks
> >   (dialog-coowner.glade, dialog-coowner-import-gui.glade,
> >dialog-coowner-report.glade)
> >
> > the reports
> > ===
> >
> > * a new menu `property management` was added. It is used to group all
> > standard reports created to simplify property management tasks.
> >
> > * a proof of concept report (owner-billing.scm) is created.
> >   This need to be adopted to get into the intended shape.
> >
> > * other useful reports may be introduced later on.
> >
> > i18n
> > 
> >
> > * translations for the german language have been included
> >   (po.de)
> >
> >
> >
> > Abstract
> > 
> >
> > In Germany, a co-owners' 

Re: [GNC-dev] Dummy lines in dialog-commodity.glade; Unification of "Namespace" and "Type"

[Robert Fewell]

Frank,
I think those dummy entries can be removed, they were default entries in
list stores so maybe in the past glade list stores needed them but I do not
think so now but will check.

As for 'Type', in dialog-commodity.glade it is used twice which could be
changed to 'N_amespace' and also change existing entry in
dialog-price.glade to match so accelerator keys do not conflict. The second
dialog is used when in the account tree and create a 'New Account' with
'Account Type' of 'Stock' and presses the 'Select...' button on
'Security/currency'.

Regards,
Bob

On Tue, 28 Jun 2022 at 02:33, Frank H. Ellenberger <
frank.h.ellenber...@gmail.com> wrote:

> Hi Bob,
>
> I just stumbled over at least 2 lines with
> ' translatable="yes">Dummy '
> Are they really somewhere displayed to the user or can we drop the
> translatable flag?
>
> Do you remember similar cases, perhaps after looking in a dictionary as
> described under 'Recycle already existing strings in
> https://wiki.gnucash.org/wiki/I18N#General_Thoughts?
>
> While working on the docs. we found in
>
> https://code.gnucash.org/docs/de/gnucash-help/tool-security-edit.html#tool-commodity
> different labels "Namespace" in the database window and "Type" in this
> dialog for the same element. IMHO we should unify this to nammespace. I
> do rurrently not remember, where the second part of the glade file is used.
>
> Regards
> Frank
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

[GNC-dev] Windows build of GnuCash

[Robert Fewell]

Hi,

I needed to setup my build installation again as I corrupted my existing
one and these were my observations.
Using the current setup-ming64.ps1, but I did notice the webkit version was
at 999.4 but on sourceforge there was 999.5 so I changed to using that
version which rebuilt my c:\gcdev64 directory OK.
I think on a previous build I had trouble getting the HTML workshop but as
that was still installed that was OK, wonder if a copy should be on
sourceforge.
I added this to gnucash.modules...

  

  
  
  
  
  
  
  
  
  

  

So I could just build the dependencies and then make copies of the 'build'
and 'inst' directories so I can use the copies to replace the working
directories when it all goes wrong.
It takes a while to build them on my old Windows10 machine.

Jhbuild stopped after building the first package, this was traced to the
following...
The jhbuild manifest files were all empty, to populate them I needed to
move line 325 in modtypes\__init__.py to above line 322.

If you do not want to populate them, then the following is required...
Change utils\packagedb.py line 75 to...
if (self.manifest):
to make the writer.fp.write line conditional.

Maybe add both changes to the jhbuild.patch file.

The only other change that I needed to do was for
gwenhwfar-5.7.4\src\sio\syncio_tls.c
Build failed with undefined MAX_PATH on line 533 so I added this after the
# ifdef OS_WIN32
#ifndef MAX_PATH
# define MAX_PATH 200
#endif

These changes allowed a successful build of the dependencies and after
making copies of the 'build' and 'inst' I was able to build gnucash-git and
gnucash-docs OK.
Created a package and did an install and I think everything is working OK.

Comparing my gnucash\bin directory to the one created from the build
server, I have two files missing...
libxmlsec1-gcrypt.dll
libxmlsec1-gnutls.dll
Maybe down to the build server creating a release and mine is from
gnucash-git maint branch.

The other thing I noticed was the default gtk-3.0.css file is missing, I
added the following to gnucash-ming64.iss
Source: "@INST_DIR@\share\doc\@PACKAGE@\gtk-3.0.css"; DestDir:
"{app}\doc\@PACKAGE@"; Flags: ignoreversion; Components: main

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

Re: [GNC-dev] Intro "Saved Settings"

[Robert Fewell]

I think that must have been a copy and paste error, as John says it does
not apply here.
Regards,
Bob

On Tue, 13 Apr 2021 at 17:50, Frank H. Ellenberger <
frank.h.ellenber...@gmail.com> wrote:

> Hi,
>
> in between it became slightly different:
>
> Am 13.04.21 um 12:29 schrieb Frank H. Ellenberger:
> > I also wonder, if the final instruction
> > "Click on \"Next\" to proceed or \"Cancel\" to Abort the process."
> > should be separated at least in the inrto pages.
> >
> > ~Frank
> >
> > Am 13.04.21 um 12:05 schrieb Frank H. Ellenberger:
> >> Hi,
> >>
> >> I am currently preparing a msgmerge.
> >>
> >> Recently we changed the text about Saved Settings in the intro from
> >> gnucash/gtkbuilder/assistant-csv-trans-import.glade
>
> and gnucash/gtkbuilder/assistant-csv-price-import.glade.
>
> But I wonder, why you inserted it into
> gnucash/import-export/aqb/assistant-ab-initial.glade
> with
>
> https://github.com/Gnucash/gnucash/commit/a26a7c590813391242ad992cb1385e0ae8bbd82b
>
> It is a setup assistant, which calls the aqbanking setup and later links
> between the gnucash account and the aqbanking user
> There is no import with selectable settings.
>
> >> Now I see the old borked text also in
> >> gnucash/import-export/aqb/assistant-ab-initial.glade.
> >>
> >> I could now copy the text over, but I am wondering, if we should
> >> separate it in its own section in both files. Then translators have to
> >> translate the section only once.
> >>
> >> Your opinion?
> >>
> >> Regards
> >> Frank
>
> ~Frank
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Toolbar Style

[Robert Fewell]

Taull,

That setting is no longer valid for gtk3, have a look here...
https://developer.gnome.org/gtk3/stable/GtkSettings.html
look at the properties and find gtk-toolbar-style and you will see that if
set it is ignored.

Regards,
Bob

On Sun, 7 Mar 2021 at 12:52, Taull Boi  wrote:

> Geert,
>
> Thanks for your reply. I haven't programmed with Gtk for a long time but I
> must be missing something: if the calls to set the style and icon size in
> the toolbar were removed, wouldn't the gtk (or user) defaults be used
> anyway? Alternatively, could we use the gtk settings to initialize the
> toolbar?
>
> Thanks
>
> On Sun, Mar 7, 2021 at 4:29 AM Geert Janssens 
> wrote:
>
> > Hi,
> >
> > The configuration option you reference to is a Gtk configuration option.
> > The
> > Gtk project has dropped this option with Gtk3. It now puts responsibility
> > with
> > the projects using Gtk3 to decide which toolbar style to use.
> >
> > So when GnuCash switched to  Gtk3, the possibility to configure this as a
> > user
> > was lost. After a few trials with what should be the best hard-coded
> > style, we
> > ended up with the small icons+text as the best compromise.
> >
> > Regards,
> >
> > Geert
> >
> > Op zaterdag 6 maart 2021 15:25:00 CET schreef Taull Boi:
> > > Hi,
> > >
> > > I am using gnucash 4.4 on Windows. I find that the gnucash toolbar
> style
> > > does not change even though I have correctly configured the toolbar
> style
> > > settings in gtk-3.0/Settings.ini as follows:
> > >
> > > [Settings]
> > > gtk-toolbar-style = GTK_TOOLBAR_TEXT
> > >
> > > This problem appears to have been discussed below:
> > >
> > >
> >
> http://gnucash.1415818.n4.nabble.com/GNC-Toolbar-ignoring-gtk-toolbar-style-
> >
> > setting-in-Ubuntu-18-04-Bionic-tt4699591.html
> > >
> > > I was looking at the gnucash source code and the toolbar style seems to
> > be
> > > hardcoded in the following locations:
> > >
> > > ./gnome/window-reconcile.c:1699:gtk_toolbar_set_style
> > > (GTK_TOOLBAR(widget),
> > > ./gnome-utils/gnc-embedded-window.c:302:gtk_toolbar_set_style
> > > (GTK_TOOLBAR(priv->toolbar),
> > > ./gnome-utils/gnc-main-window.c:3964:gtk_toolbar_set_style
> > > (GTK_TOOLBAR(priv->toolbar),
> > >
> > > I was wondering why this is done.
> > >
> > > Thanks for your time.
> > > ___
> > > 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] GncCombott Widget

[Robert Fewell]

add
> > > context to the possible choices. Something we currently are lacking.
> > >
> > > This can still be done in code, though we need to add sensible
> explaining
> > > tooltips for the options that are using a combobox widget. I don't
> think
> > > we
> > > currently have those.
> > >
> > > Note you can still do smart things like highlight the selected value in
> > > the
> > > big tooltip using markup so more attention is drawn to the currently
> > > selected value (and its possible explanation).
> > >
> > > As an exercise I went through all the comboboxes in the transaction
> > > report's options. From my estimate with a decent description of what
> the
> > > option does, the actual option values are self-explanatory in 99% of
> the
> > > cases. Only in very few situations a per value tooltip can add some
> > > additional information. And even there it's usually only for one of two
> > > values in the whole value list.
> > >
> > > For example, there's the "Primary Key" option. That in itself is a very
> > > technical and unfortunate option name, but that's what we have now. If
> a
> > > general tooltip was added to explain this sets the column to sort on
> > > first,
> > > there's no need for any of the tooltips on the possible values. It's
> > > pretty
> > > clear those are column names.
> > >
> > > Another example: Void Transactions.
> > > If a tooltip explains this option allows to filter transactions based
> on
> > > their voided status, that would already explain all the possible
> values.
> > > One could add a note/warning in that tooltip that if void transactions
> > > are selected, their values will be added to the totals as well. With
> that
> > > everything that's currently presented via the per-value tooltips is
> > > available in the general tooltip and more.
> > >
> > > The same worked for me for each and every of the other options.
> > >
> > > So while you are free to fix this as you see fit, I'm a strong
> proponent
> > > of
> > > revisiting our decision to continue to use per value tooltips.
> > >
> > > Regards,
> > >
> > > Geert
> > >
> > > Op dinsdag 16 februari 2021 12:10:56 CET schreef Robert Fewell:
> > >> Hi,
> > >>
> > >> In bug 798109 it was highlighted that the widget I wrote back in 2012
> > >> does
> > >> not respond to keyboard use well which I think would be relatively
> easy
> > >> to
> > >> fix and maybe a couple of tweaks.
> > >>
> > >> Geert suggested that it could be dropped in favour of a traditional
> > >> GtkComboBox.
> > >>
> > >> The reason I wrote it was to match the GTK2 version at that time which
> > >> allowed you to have tooltips on the popped up menu items as well as
> when
> > >> the item was selected and the popup removed. This can not be done in
> the
> > >> GTK3 version as I can see no way of getting to the used GtkMenu. The
> GTK3
> > >> version only supports a tooltip when there is no popup displayed. This
> > >> tooltip can still be specific to the selected item with the use of a
> > >> 'query-tooltip' call back.
> > >>
> > >> I think the widget is mainly used in dialog options for reports.
> > >>
> > >> I am fine with fixing the widget or replacing it, just asking if
> there is
> > >> a
> > >> preference.
> > >>
> > >> 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
>
>
>
>
> ___
> 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] GncCombott Widget

[Robert Fewell]

Hi,

In bug 798109 it was highlighted that the widget I wrote back in 2012 does
not respond to keyboard use well which I think would be relatively easy to
fix and maybe a couple of tweaks.

Geert suggested that it could be dropped in favour of a traditional
GtkComboBox.

The reason I wrote it was to match the GTK2 version at that time which
allowed you to have tooltips on the popped up menu items as well as when
the item was selected and the popup removed. This can not be done in the
GTK3 version as I can see no way of getting to the used GtkMenu. The GTK3
version only supports a tooltip when there is no popup displayed. This
tooltip can still be specific to the selected item with the use of a
'query-tooltip' call back.

I think the widget is mainly used in dialog options for reports.

I am fine with fixing the widget or replacing it, just asking if there is a
preference.

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

Re: [GNC-dev] Fresh Windows build setup fails

[Robert Fewell]

John,
OK, will try and test a clean install maybe on Sunday. I did actually get
my build working but as usual other things took my time. I still had the
jhbuild package using python2.7, installed that and was able to do a
successful build with a couple of tweaks. I noticed the ICU update and
downgraded ICU, boost and halfbuzz I think to match the webkit version and
cmake and removed pkgconf.
I imagine that as I had been building on windows for a long time I was
always using the old version of jhbuild.

If I recall, I did notice something strange with the mariad database files,
with a new install I do not think there is a plugin directory but will
confirm that.

Regards,
Bob

On Fri, 29 Jan 2021 at 04:33, John Ralls  wrote:

> I finally got back to this this week. There's a simple patch, which I've
> pushed to gnucash-on-windows.git/patches/jhbuild.patch, to get jhbuild to
> lose the leading / from pkgconf's version of pkg-config --list-all. That
> fixes the major problem of nothing being able to find its dependencies with
> pkg-config, and with that fixed everything seems to work normally again.
>
> Except that MSYS2 did a major update recently and bumped the ICU version,
> and that breaks mingw-w64-webkitgtk. I've got a new one building, with luck
> it will be done tomorrow.
>
> Regards,
> John Ralls
>
> > On Dec 27, 2020, at 4:25 PM, John Ralls  wrote:
> >
> > Bob,
> >
> > I poked at this for a few hours today. I found that the only thing that
> needs adjusting is to remove or comment out line 66 ($env:MSYSTEM =
> 'MINGW32') in buildserver/build_package.ps1.
> >
> > I also found an error in jhbuild, this patch fixes it:
> > diff --git a/jhbuild/utils/packagedb.py b/jhbuild/utils/packagedb.py
> > index b938c27c..b9d6d135 100644
> > --- a/jhbuild/utils/packagedb.py
> > +++ b/jhbuild/utils/packagedb.py
> > @@ -76,7 +76,7 @@ class PackageEntry:
> > # write manifest
> > fileutils.mkdir_with_parents(os.path.join(self.dirname,
> 'manifests'))
> > writer = fileutils.SafeWriter(os.path.join(self.dirname,
> 'manifests', self.package))
> > -writer.fp.write('\n'.join(self.manifest).encode('utf-8',
> 'backslashreplace') + b'\n')
> > +writer.fp.write('\n'.join(self._manifest).encode('utf-8',
> 'backslashreplace') + b'\n')
> > writer.commit()
> >
> > def remove(self):
> >
> > And things seem to be building OK now.
> >
> > Regards,
> > John Ralls
> >
> >
> >
> >> On Dec 26, 2020, at 4:01 AM, Robert Fewell <14ubo...@gmail.com> wrote:
> >>
> >> John,
> >> Yes I did amend jhbuildrc.
> >>
> >> Had another poke at it, I ran the setup-mingw64.ps1 file again using
> all defaults to completion.
> >> pkg-config gives said out put.
> >> Down graded cmake to version 3.18.4-1
> >> Installed mingw pkg-config which uninstalled pkgconf.
> >>
> >> Changed to gnucash-on-windows.git and tried jhbuild command
> >> got error importing jhbuild - needed to change path.insert to be of
> form c:\\gcdev64\src\jhbuild.git'
> >>
> >> Changing that then gave the subprocess error
> >> I then made all the changes in mypatch file which seemed to work but I
> then got the following directory structure c\gcdev64\downloads and
> gnucash
> >>
> >> So I changed  jhbuildrc to the following
> >> _basedir = "c:\gcdev64"
> >> _download_dir ="c:\gcdev64\downloads"
> >>
> >> And now OpenSP was downloaded and started to configure and build I
> think and then errored.
> >>
> >> That's as far I can go.
> >>
> >> Regards,
> >> Bob
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Sat, 26 Dec 2020 at 03:38, John Ralls  wrote:
> >>
> >>
> >>> On Dec 24, 2020, at 7:51 AM, Robert Fewell <14ubo...@gmail.com> wrote:
> >>>
> >>> John,
> >>>
> >>> I think this is down to paths / filenames, I can fix all the missing
> dependencies by doing this...
> >>>
> >>>
> >>>c_include_search_paths = None
> >>>for dep_type, value, altdeps in sysdeps:
> >>>print("dep_type: ", dep_type)
> >>>print("value is: ", value)
> >>>dep_met = True
> >>>if dep_type.lower() == 'path':
> >>>if os.path.split(value)[0]:
> >>>

[GNC-dev] Windows build has failed

[Robert Fewell]

Hi,

The Windows nightly build has failed since the libofx upgrade.
Fails at...

C:/gcdev64/gnucash/maint/src/libofx-0.10.0/lib/ofx_preproc.cpp:317:39:
error: invalid conversion from 'const char**' to 'char**'
[-fpermissive]
  317 |   , ,
  |   ^~~
  |   |
  |   const char**

I had a look at the same file in the previous version and on line 310
a change was made...

Old version...
#if defined(__sun) || defined(__NetBSD__)

New version...
#if defined(__WIN32__) || defined(__sun) || defined(__NetBSD__)

I changed that line to the old version and was able to build libofx
and continue to build successfully.

Not sure if that is a valid fix?

Regards,

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

Re: [GNC-dev] Headers in csv tree export; was: [Gnucash/gnucash] Translations update from Weblate (#877)

[Robert Fewell]

Frank,
I have pushed a change that changes the header line to use friendlier
column titles which also uses existing translations.

Regards,
Bob

On Mon, 18 Jan 2021 at 22:46, Frank H. Ellenberger <
frank.h.ellenber...@gmail.com> wrote:

> Hi Bob,
>
> msgid "full_name" can produce false positives when running
> msgfmt -c --check-accelerators="_"
>
> when I looked around, I saw, you used in csv-transaction-export nicer
> headers and I am wondering, if we can unify them also with the header
> used in the register view.
>
> Regards
> Frank
>
>  Weitergeleitete Nachricht 
> Betreff: Re: [Gnucash/gnucash] Translations update from Weblate (#877)
> Datum: Fri, 15 Jan 2021 23:19:10 -0800
> Von: yyyjajp 
> Antwort an: Gnucash/gnucash
> 
> An: Gnucash/gnucash 
> Kopie (CC): Frank H. Ellenberger ,
> Mention 
>
> @fellen ```
> ja.po:20278:#: gnucash/import-export/csv-exp/csv-tree-export.c:155
> ja.po:20279:msgid "full_name"
> ja.po:20280:msgstr "フルネーム"
> ```
> which is not a keyboard accelerator but a column name.
>
> --
> You are receiving this because you were mentioned.
> Reply to this email directly or view it on GitHub:
> https://github.com/Gnucash/gnucash/pull/877#issuecomment-761520857
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Fresh Windows build setup fails

[Robert Fewell]

John,
Yes I did amend jhbuildrc.

Had another poke at it, I ran the setup-mingw64.ps1 file again using all
defaults to completion.
pkg-config gives said out put.
Down graded cmake to version 3.18.4-1
Installed mingw pkg-config which uninstalled pkgconf.

Changed to gnucash-on-windows.git and tried jhbuild command
got error importing jhbuild - needed to change path.insert to be of form
c:\\gcdev64\src\jhbuild.git'

Changing that then gave the subprocess error
I then made all the changes in mypatch file which seemed to work but I then
got the following directory structure c\gcdev64\downloads and gnucash

So I changed  jhbuildrc to the following
_basedir = "c:\gcdev64"
_download_dir ="c:\gcdev64\downloads"

And now OpenSP was downloaded and started to configure and build I think
and then errored.

That's as far I can go.

Regards,
Bob











On Sat, 26 Dec 2020 at 03:38, John Ralls  wrote:

>
>
> > On Dec 24, 2020, at 7:51 AM, Robert Fewell <14ubo...@gmail.com> wrote:
> >
> > John,
> >
> > I think this is down to paths / filenames, I can fix all the missing
> dependencies by doing this...
> >
> >
> > c_include_search_paths = None
> > for dep_type, value, altdeps in sysdeps:
> > print("dep_type: ", dep_type)
> > print("value is: ", value)
> > dep_met = True
> > if dep_type.lower() == 'path':
> > if os.path.split(value)[0]:
> > if not os.path.isfile(value) and not os.access(value,
> os.X_OK):
> > dep_met = False
> > else:
> > pathdirs = set(os.environ.get('PATH',
> '').split(os.pathsep))
> > pathdirs.update(['/sbin', '/usr/sbin'])
> > for path in pathdirs:
> > filename = os.path.join(path, value)
> > filename = filename.replace("/c/", "/")
> > print("path filename is: ", filename)
> > if os.path.isfile(filename) and os.access(filename,
> os.X_OK):
> > break
> > filename = filename + ".exe"
> > print("path filename is: ", filename)
> > if os.path.isfile(filename) and os.access(filename,
> os.X_OK):
> > break
> > else:
> > dep_met = False
> > elif dep_type.lower() == 'c_include':
> > if c_include_search_paths is None:
> > c_include_search_paths =
> get_c_include_search_paths(config)
> > found = False
> > for path in c_include_search_paths:
> > filename = os.path.join(path, value)
> > print("filename is: ", filename)
> > filename = filename.replace("/c/", "/")
> > print("filename is: ", filename)
> > if os.path.isfile(filename):
> > found = True
> > break
> > if not found:
> > dep_met = False
> >
> > Not very portable but may give you an idea for correct fix.
> >
> > Now I get 
> > Traceback (most recent call last):
> >   File "C:/gcdev64/msys2/usr/bin/jhbuild", line 23, in 
> > jhbuild.main.main(sys.argv[1:])
> >   File "c:\gcdev64\src\jhbuild.git/jhbuild/main.py", line 120, in main
> > rc = jhbuild.commands.run(command, config, args, help=lambda:
> print_help(parser))
> >   File "c:\gcdev64\src\jhbuild.git/jhbuild/commands/__init__.py", line
> 188, in run
> > return cmd.execute(config, args, help)
> >   File "c:\gcdev64\src\jhbuild.git/jhbuild/commands/__init__.py", line
> 56, in execute
> > return self.run(config, options, args, help)
> >   File "c:\gcdev64\src\jhbuild.git/jhbuild/commands/base.py", line 262,
> in run
> > build = jhbuild.frontends.get_buildscript(config, module_list,
> module_set=module_set)
> >   File "c:\gcdev64\src\jhbuild.git/jhbuild/frontends/__init__.py", line
> 27, in get_buildscript
> > return BuildScript(config, module_list, module_set=module_set)
> >   File "c:\gcdev64\src\jhbuild.git/jhbuild/frontends/terminal.py", line
> 111, in __init__
> > buildscript.BuildScript.__init__(self, config, module_list,
> module_set=module_set)
> >   File "c:\gcdev64\src\jhbuild.git/jhbuild/frontends/buildscript.py",
> line 78, in __init__
>

Re: [GNC-dev] Fresh Windows build setup fails

[Robert Fewell]

John,

I think this is down to paths / filenames, I can fix all the missing
dependencies by doing this...


c_include_search_paths = None
for dep_type, value, altdeps in sysdeps:
print("dep_type: ", dep_type)
print("value is: ", value)
dep_met = True
if dep_type.lower() == 'path':
if os.path.split(value)[0]:
if not os.path.isfile(value) and not os.access(value,
os.X_OK):
dep_met = False
else:
pathdirs = set(os.environ.get('PATH', '').split(os.pathsep))
pathdirs.update(['/sbin', '/usr/sbin'])
for path in pathdirs:
filename = os.path.join(path, value)
filename = filename.replace("/c/", "/")
print("path filename is: ", filename)
if os.path.isfile(filename) and os.access(filename,
os.X_OK):
break
filename = filename + ".exe"
print("path filename is: ", filename)
if os.path.isfile(filename) and os.access(filename,
os.X_OK):
break
else:
dep_met = False
elif dep_type.lower() == 'c_include':
if c_include_search_paths is None:
c_include_search_paths = get_c_include_search_paths(config)
found = False
for path in c_include_search_paths:
filename = os.path.join(path, value)
print("filename is: ", filename)
filename = filename.replace("/c/", "/")
print("filename is: ", filename)
if os.path.isfile(filename):
found = True
break
if not found:
dep_met = False

Not very portable but may give you an idea for correct fix.

Now I get 
Traceback (most recent call last):
  File "C:/gcdev64/msys2/usr/bin/jhbuild", line 23, in 
jhbuild.main.main(sys.argv[1:])
  File "c:\gcdev64\src\jhbuild.git/jhbuild/main.py", line 120, in main
rc = jhbuild.commands.run(command, config, args, help=lambda:
print_help(parser))
  File "c:\gcdev64\src\jhbuild.git/jhbuild/commands/__init__.py", line 188,
in run
return cmd.execute(config, args, help)
  File "c:\gcdev64\src\jhbuild.git/jhbuild/commands/__init__.py", line 56,
in execute
return self.run(config, options, args, help)
  File "c:\gcdev64\src\jhbuild.git/jhbuild/commands/base.py", line 262, in
run
build = jhbuild.frontends.get_buildscript(config, module_list,
module_set=module_set)
  File "c:\gcdev64\src\jhbuild.git/jhbuild/frontends/__init__.py", line 27,
in get_buildscript
return BuildScript(config, module_list, module_set=module_set)
  File "c:\gcdev64\src\jhbuild.git/jhbuild/frontends/terminal.py", line
111, in __init__
buildscript.BuildScript.__init__(self, config, module_list,
module_set=module_set)
  File "c:\gcdev64\src\jhbuild.git/jhbuild/frontends/buildscript.py", line
78, in __init__
subprocess.call(chrt_args + ['true'], stdout=devnull, stderr=devnull)
== 0):
AttributeError: module 'jhbuild.utils.subprocess_win32' has no attribute
'call'

Regards,
Bob



On Thu, 24 Dec 2020 at 10:07, Sumit Bhardwaj  wrote:

> I was trying around the same time as Robert on a fresh Windows machine and
> it failed as well. With the same message.
>
> -Sumit
>
> -Original Message-
> From: gnucash-devel  outlook@gnucash.org> On Behalf Of Robert Fewell
> Sent: Thursday, December 24, 2020 02:02
> To: John Ralls 
> Cc: gnucash-devel 
> Subject: Re: [GNC-dev] Fresh Windows build setup fails
>
> John,
>
> Every thing above from 'My last attempt...' was done from the MINGW64
> terminal prompt.
>
> Regards,
> Bob
>
> On Thu, 24 Dec 2020 at 01:31, John Ralls  wrote:
>
> >
> >
> > > On Dec 23, 2020, at 6:50 AM, Robert Fewell <14ubo...@gmail.com> wrote:
> > >
> > > Hi,
> > >
> > > My Windows 10 hard drive failed which I thought would not be a big
> > > deal
> > as
> > > I only use it to build and test the windows build. After installing
> > Windows
> > > 10 and updating I grabbed the setup-mingw64.ps1 file and proceeded
> > > to recreate my build system.
> > >
> > > Unfortunately that did not work, tried the 32bit and 64bit versions
> > > which both failed. The first problem was that pkg-config --list-all
> > > would list all the packages with a starting forward slash with
> > > problems also in jhbuild.
> > >
> > > So tried another tact, I had an old backup from March wh

Re: [GNC-dev] Fresh Windows build setup fails

[Robert Fewell]

John,

Every thing above from 'My last attempt...' was done from the MINGW64
terminal prompt.

Regards,
Bob

On Thu, 24 Dec 2020 at 01:31, John Ralls  wrote:

>
>
> > On Dec 23, 2020, at 6:50 AM, Robert Fewell <14ubo...@gmail.com> wrote:
> >
> > Hi,
> >
> > My Windows 10 hard drive failed which I thought would not be a big deal
> as
> > I only use it to build and test the windows build. After installing
> Windows
> > 10 and updating I grabbed the setup-mingw64.ps1 file and proceeded to
> > recreate my build system.
> >
> > Unfortunately that did not work, tried the 32bit and 64bit versions which
> > both failed. The first problem was that pkg-config --list-all would list
> > all the packages with a starting forward slash with problems also in
> > jhbuild.
> >
> > So tried another tact, I had an old backup from March which I restored
> and
> > then proceeded to update but that resulted in pacman listing loads of
> > missing packages in the 'virtual world'
> >
> > My last attempt was to do the script manually, all OK till line 241 where
> > it installed mingw64/cmake and pkg-config. Once these were installed
> > pkg-config --list-all would list with forward slash's. To overcome this I
> > uninstalled them and installed msys versions and proceeded to the end of
> > script.
> >
> > I have not checked the whether the boost version is correct for the
> webkit
> > version as to start with I just wanted a valid dependency.
> >
> > Changed to the gnucash-on-windows.git directory to start the build but
> that
> > failed as follows...
> >
> > Failed to 'import jhbuild' on line 15
> >   to fix I changed line 12 to sys.path.insert(0,
> > 'c:/gcdev64/src/jhbuild.git')
> >
> > Next was subprocess_win32 has no check_output
> >  so added a line check_output = real_subprocess.check_output to
> > subprocess_win32.py
> >
> > Which resulted in a string has no split method in systeminstall.py
> >  so changed shell_split = string.split to shell_split = str.split
> >
> > I am not sure these changes are correct as I know nothing about python
> but
> > I can now run...
> >
> > $ TARGET=gnucash-maint jhbuild -f jhbuildrc build
> > Required packages:
> >  System installed packages which are too old:
> >(none)
> >  No matching system package installed:
> >make
> >gcrypt
> >pkg-config
> >gmp
> >git
> >boost
> >cmake
> >ninja
> >
> > The strange thing is that all these are installed as...
> > cmake --version gives 3.18.4, ninja --version gives 1.10.2
> >
> > So the question is, has anybody recently done a fresh build setup install
> > and it worked or know how to fix.
>
> Bob,
>
> Are you trying to run MSYS2 commands from a CMD or Powershell window
> instead of from an MinGW32/64 one?
>
> Regards,
> John Ralls
>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

[GNC-dev] Fresh Windows build setup fails

[Robert Fewell]

Hi,

My Windows 10 hard drive failed which I thought would not be a big deal as
I only use it to build and test the windows build. After installing Windows
10 and updating I grabbed the setup-mingw64.ps1 file and proceeded to
recreate my build system.

Unfortunately that did not work, tried the 32bit and 64bit versions which
both failed. The first problem was that pkg-config --list-all would list
all the packages with a starting forward slash with problems also in
jhbuild.

So tried another tact, I had an old backup from March which I restored and
then proceeded to update but that resulted in pacman listing loads of
missing packages in the 'virtual world'

My last attempt was to do the script manually, all OK till line 241 where
it installed mingw64/cmake and pkg-config. Once these were installed
pkg-config --list-all would list with forward slash's. To overcome this I
uninstalled them and installed msys versions and proceeded to the end of
script.

I have not checked the whether the boost version is correct for the webkit
version as to start with I just wanted a valid dependency.

Changed to the gnucash-on-windows.git directory to start the build but that
failed as follows...

Failed to 'import jhbuild' on line 15
   to fix I changed line 12 to sys.path.insert(0,
'c:/gcdev64/src/jhbuild.git')

Next was subprocess_win32 has no check_output
  so added a line check_output = real_subprocess.check_output to
subprocess_win32.py

Which resulted in a string has no split method in systeminstall.py
  so changed shell_split = string.split to shell_split = str.split

I am not sure these changes are correct as I know nothing about python but
I can now run...

$ TARGET=gnucash-maint jhbuild -f jhbuildrc build
Required packages:
  System installed packages which are too old:
(none)
  No matching system package installed:
make
gcrypt
pkg-config
gmp
git
boost
cmake
ninja

The strange thing is that all these are installed as...
cmake --version gives 3.18.4, ninja --version gives 1.10.2

So the question is, has anybody recently done a fresh build setup install
and it worked or know how to fix.

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

Re: [GNC-dev] Budgets: Sort accounts by code

[Robert Fewell]

Kevin,
The current version is 4.2, soon to be 4.3 and in that version there is
already an option to show the code column and description with either being
sorted.
Also on the toolbar is 'All Periods' and with an account selected will
populate all cells for that account with a value.
You do not say what OS you are using but maybe you should think about
upgrading?

Regards,
Bob

On Thu, 10 Dec 2020 at 02:41, Kevin Buckley 
wrote:

> Was replicating budget details from an industry body flyer recently
> and, having replicated the accounts and sub accounts within a
> GnuCash book, then relaised that, whilst I was able to sort the
> accounts into the order the appeared in the external budget, within
> the accounts tree, the option for sorting accounts in the budget dialog
> only allows for reversing the alphabetical sorting.
>
> One can get round this by prepending digits to the names of the
> accounts, but I was wondering if any consideration of the possiblity
> of having the account list in the budget dialog sorted by the account
> code?
>
> More than happy to take a look at implementing something, assuming
> that it's never been discounted as completely un-doable in previous
> discussions, hence asking about "prior work".
>
> I am still using a 2.6.20-ish GnuCash.
>
> Kevin
>
> PS
>
> I also thought that way back now, there was a way to fiil all
> of the coulmns to the right of any given cell wih the current
> one, but I couldn't see how to achieve that either.
>
> Probably just getting too old!
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] New branch mistake

[Robert Fewell]

Thank you.
Bob

On Sat, 28 Nov 2020 at 19:10, Geert Janssens 
wrote:

> Bob,
>
>
>
> The command to execute would be
>
> git push origin :bug309943
>
> (I have done so for you already)
>
>
>
> This will push the "empty" branch to bug309943, effectively removing it.
>
>
>
> The git devs use odd logic from time to time...
>
>
>
> Regards,
>
>
>
> Geert
>
>
>
> Op zaterdag 28 november 2020 12:38:54 CET schreef Robert Fewell:
>
> > Hi Guys,
>
> >
>
> > I think I got my bug_branch and branch the wrong way round and created a
>
> > new branch on code/github of bug309943.
>
> >
>
> > Could someone remove / advise on command to do this on code.
>
> >
>
> > 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

[GNC-dev] New branch mistake

[Robert Fewell]

Hi Guys,

I think I got my bug_branch and branch the wrong way round and created a
new branch on code/github of bug309943.

Could someone remove / advise on command to do this on code.

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

Re: [GNC-dev] Fwd: gnucash maint: Multiple changes pushed

[Robert Fewell]

Frank,

That is a new one on me, the changes I made have no reference to that file
as far as I can see. From googling it looks like a theme css file so I
think mabe a coincidence, maybe your theme was updated recently?

Regards,
Bob

On Fri, 23 Oct 2020 at 19:36, Frank H. Ellenberger <
frank.h.ellenber...@gmail.com> wrote:

> Sorry, I forgot to CC.
>
>
>  Weitergeleitete Nachricht 
> Betreff: gnucash maint: Multiple changes pushed
> Datum: Fri, 23 Oct 2020 20:17:31 +0200
> Von: Frank H. Ellenberger 
> An: Robert Fewell <14ubo...@gmail.com>
>
> Hi Bob,
>
> after your changes I watch on the console:
>
> (gnucash:31326): Gtk-WARNING **: 20:06:18.800: Theme parsing error:
> gtk.css:16:33: Failed to import: Error opening file
> /home/frank/.config/gtk-3.0/window_decorations.css: No such file or
> directory
>
> I never knew about gtk-3.0/window_decorations.css before.
>
> Regards
> frank
>
> > commit 3c5066feb4a6a58c263c3ae83a16739fedf28266
> > Author: Robert Fewell <14uBobIT at gmail.com>
> > Date:   Thu Oct 22 14:30:46 2020 +0100
> >
> > Change source files option-util.* for spaces and tabs
> :
> ___
> 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] Glade file version

[Robert Fewell]

While looking at a glade file for a bug fix, I noticed that the version
required parameter was at 3.10 and the file generated was with glade
version 3.22.2

As the required gtk+ version for Gnucash is greater than 3.22.30, I would
like to change the version required to 3.22 and as I have glade 3.36.0 they
will be generated by that. This may involve changing deprecated widgets and
also glade file layout changes.

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

Re: [GNC-dev] "2" version of source code

[Robert Fewell]

The slowness I think is that the treeview travesses the model working out
what paths are valid before loading. I had started to get round that by
only loading part of the transaction list. So locally I have a test account
with 1 transactions and have two Glist's, a full one with 1 entries
and a view list which the custom model uses and which is currently set to
150 entries. I am able to move about successfully by keyboard, loading and
removing entries from the view list as needed but moving by mouse needs
work but I have an idea on that.

Selectable columns were already implemented, currently the normal registers
have a fixed set of columns but the general ledger has some default and
elective ones but this is easily changed.

If the transaction could only have one line then that would make the model
and view simpler like not having two cell renderers in one column and
setting the visibility of them by type of row.

I will try and get the mouse scrolling to work and then there are changes
to the model I want to make which can include going to a transaction with
one line only. As this is all self contained in separate source files
hopefully there will be no problem if I push my changes when ready but some
changes may still require work.

This still may not come to anything but maybe show what is possible, the
wrong way to do it or something to build on.

Regards,
Bob


On Sat, 1 Aug 2020 at 12:10, Geert Janssens 
wrote:

> Op dinsdag 14 juli 2020 17:49:34 CEST schreef Robert Fewell:
>
> > Also if I remember right there was a lot of, "it is not the same as
>
> > the existing" which slightly put me off any further progress.
>
>
>
> I admit partial blame to this and apologize for it. In the years since I
> have changed my mind on this and I would be more ok with certain layout
> improvements. Just as an example I would now even dare to propose to drop
> the double line mode in favour of user selectable visible columns (some
> columns may be made mandatory though).
>
>
>
> But as mentioned in other messages, I don't know if it's the right time to
> work on this. The primary concern remains the slowness of GtkTreeView (or
> is that really GtkTreeModel) with large data sets.
>
>
>
> Regards,
>
>
>
> Geert
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

[GNC-dev] Example CSS file missing from Windows install

[Robert Fewell]

Hi,
Not sure if this is deliberate or not but the example CSS file is missing
from the Windows install.
I fixed this locally by adding a line to gnucash-mingw64.iss at line 107 as
follows...

Source: "@INST_DIR@\share\doc\@PACKAGE@\gtk-3.0.css"; DestDir:
"{app}\doc\@PACKAGE@"; Components: main

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

Re: [GNC-dev] "2" version of source code

[Robert Fewell]

Jean,
I have been relooking at this and wil give it another go. When I first made
the changes, all seemed to be OK but with large transaction lists it was
slow. Also if I remember right there was a lot of, it is not the same as
the existing which slightly put me off any further progress.
I have recently created a new tree view / model based on the original
register rewrite to see if I had made an error with my changes but it also
is slow with large transaction lists, slightly quicker than my effort but I
think that was down to only having one transaction row.
I did implement only retrieving part of the transaction list at a time but
this needs to be changed along with the vertical scrollbars which I may
have an idea about.

If you can wait, I will try and spend more time on it soon. Multi selection
still might be tricky, what do you want that for?

Regards,
Bob

On Tue, 14 Jul 2020 at 16:11, Jean Laroche  wrote:

> Hi Devs,
> Last night I was looking at what it would take to allow selecting
> multiple transactions in the split register, and realize (if I'm not
> mistaken) that the split register is not based on a tree view (in which
> case it would be easy to allow multi-select, but possibly tricky to do
> the right thing after that).
> On the other hand, there are versions of the .c source files with a "2",
> which I believe were a rework of the basic GC UI elements, and one of
> them is the split register. The version 2 of it is apparently based on a
> tree view and I remember somebody mentioning that the refactoring was
> intended to allow multi-select (among other things I'm sure).
>
> Question:
> - What's the status of the "2" versions? This was worked on more than 10
> years ago, if I remember correctly. No update since?
> - How far was it from completion? Would it be a huge effort to look at
> the code and make it functional? I know it can be enabled with a special
> flag when we launch gnucash, what I don't know is what's missing before
> the "2" versions can be adopted...
>
> Jean
> ___
> 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] GnuCash 3.906 Released

[Robert Fewell]

Adrian, maybe for a start one could just try and see if you can paste those
unicodes or some other into the notes/memo fields, that is how I started
and when it worked I thought about using them.

Regards,
Bob

On Thu, 25 Jun 2020 at 02:10, Adrien Monteleone <
adrien.montele...@lusfiber.net> wrote:

> I’d be happy to play with the CSS, but I don’t see a way to target that
> cell. All I get are the sheet and the entry cell.
>
> Regards,
> Adrien
>
> > On Jun 24, 2020 w26d176, at 8:05 PM, John Ralls 
> wrote:
> >
> > Font handling in Gtk on MacOS is weird: Pango only calculates the layout
> for computing box sizes. The actual glyph selection and layout is handled
> by Cairo, and I don't think it knows how to use CoreText's font
> substitution. WebKitGtk complicates matters by requiring the FreeType2
> Pango backend as well and that does its own font substitution. Regardless,
> pango is finding the emojis so the test passes. Cairo isn't putting a
> missing glyph glyph there like I'd expect. I haven't yet figured out why
> not.
> >
> > I can think of two avenues to try: Simply forcing have_glyphs to false
> on MacOS would display the regular letters. Not as pretty but it's sure to
> work. A bit more difficult and in need of testing would be to use CSS to
> set the font family for the Association cell to Apple Color Emojis on MacOS.
> >
> > Regards,
> > John Ralls
>
>
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[Robert Fewell]

I think for now we should disable it for MacOS until a solution presents
itself, maybe I will get a Macbook so I can test this.
John, is this right...
void
gnc_assoc_cell_set_use_glyphs (AssocCell *cell)
{
#ifdef MAC_INTEGRATION
cell->use_glyths = FALSE;
#else
gboolean use_glyphs = TRUE;
gchar *test_text;
GtkWidget *label;
PangoLayout *test_layout;
gint count;

g_return_if_fail (cell != NULL);

label = gtk_label_new (NULL);
test_text = g_strconcat (GLYPH_LINK, ",", GLYPH_PAPERCLIP, NULL);
test_layout = gtk_widget_create_pango_layout (GTK_WIDGET (label),
test_text);

pango_layout_set_text (test_layout, test_text, strlen (test_text));

count = pango_layout_get_unknown_glyphs_count (test_layout);

if (count != 0)
use_glyphs = FALSE;

g_object_unref (test_layout);
g_free (test_text);

cell->use_glyphs = use_glyphs;
#endif
}


On Thu, 25 Jun 2020 at 02:10, Adrien Monteleone <
adrien.montele...@lusfiber.net> wrote:

> I’d be happy to play with the CSS, but I don’t see a way to target that
> cell. All I get are the sheet and the entry cell.
>
> Regards,
> Adrien
>
> > On Jun 24, 2020 w26d176, at 8:05 PM, John Ralls 
> wrote:
> >
> > Font handling in Gtk on MacOS is weird: Pango only calculates the layout
> for computing box sizes. The actual glyph selection and layout is handled
> by Cairo, and I don't think it knows how to use CoreText's font
> substitution. WebKitGtk complicates matters by requiring the FreeType2
> Pango backend as well and that does its own font substitution. Regardless,
> pango is finding the emojis so the test passes. Cairo isn't putting a
> missing glyph glyph there like I'd expect. I haven't yet figured out why
> not.
> >
> > I can think of two avenues to try: Simply forcing have_glyphs to false
> on MacOS would display the regular letters. Not as pretty but it's sure to
> work. A bit more difficult and in need of testing would be to use CSS to
> set the font family for the Association cell to Apple Color Emojis on MacOS.
> >
> > Regards,
> > John Ralls
>
>
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[Robert Fewell]

I tested this on a couple of Linux boxes and also on Windows and had no
trouble so maybe it is a Mac issue. Unfortunately I do not presently have
one so I do not know, maybe John might have an idea, the only ideas I have
is to set different code points for a paperclip and links for Mac's,
disable it for Macs or maybe change the test.

Adrien do you have likely candidates for those?

On Wed, 24 Jun 2020 at 16:28, Adrien Monteleone <
adrien.montele...@lusfiber.net> wrote:

> Those glyphs only show up for me in Character Viewer as ‘Apple Color
> Emoji’. (thus not part of any regular typeface) Not sure how to get that
> included in GnuCash if it isn’t there by default. Certainly, I don’t want
> to change my default font to all emojis.
>
> But that doesn’t explain the lack of fall back ‘f’ and ‘w’.
>
> I had a custom CSS file for colors and font sizes, so I pulled that and
> still the fall backs are not there.
>
> Regards,
> Adrien
>
> > On Jun 24, 2020 w26d176, at 7:38 AM, Robert Fewell <14ubo...@gmail.com>
> wrote:
> >
> > Adrien,
> > That is a bot surprising, there is a test for the glyphs in the font and
> if not present should default to 'f' and 'w', code points are..
> > #define GLYPH_PAPERCLIP "\360\237\223\216" // Codepoint U+1F4CE
> > #define GLYPH_LINK  "\360\237\224\227" // Codepoint U+1F517
> >
> >
> > 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] GnuCash 3.906 Released

[Robert Fewell]

The kludge is not practical as there are some hidden columns at 0px as the
layout is shared between invoices and bills and one would not know on save
which columns should really be at 0px or changed to 1px.

I think the only real option is to not allow dragging columns to zero, not
really sure why it is at least this would also allow you to drag the column
width back should it be required.

Bob


On Wed, 24 Jun 2020 at 16:36, D. via gnucash-devel <
gnucash-devel@gnucash.org> wrote:

> 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
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[Robert Fewell]

It may be possible to save the column widths as 1px when the columns are
dragged on screen to zero px.

Regards,
Bob

On Wed, 24 Jun 2020 at 15:54, Adrien Monteleone <
adrien.montele...@lusfiber.net> wrote:

> Bob,
>
> Thanks, that was the ticket.
>
> I very carefully set them to 1px (column dividers still visible as a now
> thicker line) which is rather tricky.
>
> The layout was retained.
>
> Apparently, the columns that were getting reset on me had been reduced to
> zero.
>
> So I guess this is working as intended (or allowed by code restraints) but
> I can’t say it is intuitive and I suspect something in the wiki and
> documentation (if not already there, my apologies if it is) would be in
> order.
>
> Regards,
> Adrien
>
> > On Jun 24, 2020 w26d176, at 9:46 AM, Adrien Monteleone <
> adrien.montele...@lusfiber.net> wrote:
> >
> > Funny enough, they were 1 or 2px.
> >
> > In my re-test after using the reset option, I made sure to be careful to
> bring them to zero. Those widths weren’t retained at all.
> >
> > I’ll try again to carefully set them all to very small and see what
> happens.
> >
> > Regards,
> >
> >
> >> On Jun 24, 2020 w26d176, at 9:44 AM, Robert Fewell <14ubo...@gmail.com>
> wrote:
> >>
> >> I think that is the problem, reduce those columns but make sure the
> columns are at least one pixel. I do not think they can be zero.
> >>
> >> 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] GnuCash 3.906 Released

[Robert Fewell]

I think that is the problem, reduce those columns but make sure the columns
are at least one pixel. I do not think they can be zero.

Bob

On Wed, 24 Jun 2020 at 15:41, Adrien Monteleone <
adrien.montele...@lusfiber.net> wrote:

> Thanks I’ll check for that glyph.
>
> Concerning the layout, I used that option then opened other bills from a
> Vendor Report, as well as the same bill.
>
> I just changed them again and used the menu entry again, and this time did
> a Find.
>
> Now (check my reply to Geert) only ’Taxable?’ and ‘Billable?’ come back to
> default sizes. (and stay that way regardless of how I pull up that or other
> bills)
>
> Regards,
> Adrien
>
> > On Jun 24, 2020 w26d176, at 7:38 AM, Robert Fewell <14ubo...@gmail.com>
> wrote:
> >
> > Adrien,
> > That is a bot surprising, there is a test for the glyphs in the font and
> if not present should default to 'f' and 'w', code points are..
> > #define GLYPH_PAPERCLIP "\360\237\223\216" // Codepoint U+1F4CE
> > #define GLYPH_LINK  "\360\237\224\227" // Codepoint U+1F517
> >
> > Regarding the second point,
> > Once you set the columns for the vendor bill, I presume you then used
> the menu option "Windows->Use as Default for Vendor Documents" which should
> save the layout.
> > Closed the Bill, did a find for a bill and hopefully the layout is the
> same.
> >
> > Note the 'Windows' option will probably move to 'View' for 4.0
> >
> > Regards,
> > Bob
> >
> >
> > On Wed, 24 Jun 2020 at 08:43, Adrien Monteleone <
> adrien.montele...@lusfiber.net> wrote:
> > Is there a trick to this?
> >
> > I just set a layout on a Vendor bill, then clicked the menu entry.
> >
> > I closed the bill and opened a different one from the same vendor. The
> layout was not the one I saved.
> >
> > I then re-opened the original bill and it too did not return with the
> saved layout.
> >
> > 3.906 on MacOS 10.15.5
> >
> > Regards,
> > Adrien
> >
> > p.s. - better to keep the announcement thread title or change it per
> issue? (not sure of the protocol on this for testing releases)
> >
> > > Add option to save Layout for Business items
> > > Add two menu items under windows, one to save an existing layout for
> Invoices, Bills and Vouchers to their respective default layouts so the
> user set column widths will be used. The second menu item will reset the
> column widths to defaults and remove the default layout. Open Business
> items will also save their column widths to the page section so these can
> temporarily have different widths.
>
>
> ___
> 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] GnuCash 3.906 Released

[Robert Fewell]

Adrien,
That is a bot surprising, there is a test for the glyphs in the font and if
not present should default to 'f' and 'w', code points are..
#define GLYPH_PAPERCLIP "\360\237\223\216" // Codepoint U+1F4CE
#define GLYPH_LINK  "\360\237\224\227" // Codepoint U+1F517

Regarding the second point,
Once you set the columns for the vendor bill, I presume you then used the
menu option "Windows->Use as Default for Vendor Documents" which should
save the layout.
Closed the Bill, did a find for a bill and hopefully the layout is the same.

Note the 'Windows' option will probably move to 'View' for 4.0

Regards,
Bob


On Wed, 24 Jun 2020 at 08:43, Adrien Monteleone <
adrien.montele...@lusfiber.net> wrote:

> Is there a trick to this?
>
> I just set a layout on a Vendor bill, then clicked the menu entry.
>
> I closed the bill and opened a different one from the same vendor. The
> layout was not the one I saved.
>
> I then re-opened the original bill and it too did not return with the
> saved layout.
>
> 3.906 on MacOS 10.15.5
>
> Regards,
> Adrien
>
> p.s. - better to keep the announcement thread title or change it per
> issue? (not sure of the protocol on this for testing releases)
>
> > Add option to save Layout for Business items
> > Add two menu items under windows, one to save an existing layout for
> Invoices, Bills and Vouchers to their respective default layouts so the
> user set column widths will be used. The second menu item will reset the
> column widths to defaults and remove the default layout. Open Business
> items will also save their column widths to the page section so these can
> temporarily have different widths.
>
>
> ___
> 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] Can I edit the github release notice

[Robert Fewell]

Thank you for doing this.

Regards,
Bob

On Tue, 16 Jun 2020 at 00:12, Frank H. Ellenberger <
frank.h.ellenber...@gmail.com> wrote:

> Updated on www.gnucash.org and github.
> Frank
>
> Am 16.06.20 um 00:22 schrieb Robert Fewell:
> > John,
> > That's better than my change so please use yours.
> >
> > Thankyou,
> > Bob
> >
> > On Mon, 15 Jun 2020 at 21:10, John Ralls  wrote:
> >
> >> Bob,
> >>
> >> How about "A new Transaction Association dialog, available from the
> Update
> >> Association for Transaction menu item that has replaced the two
> association
> >> items in 3.x, allows setting, changing, and deleting associations."
> >>
> >> Regards,
> >> John Ralls
> >>
> >>> On Jun 15, 2020, at 12:15 PM, Robert Fewell <14ubo...@gmail.com>
> wrote:
> >>>
> >>> Thank you John,
> >>> Can you change the 6th bullet point that reads...
> >>>
> >>> A new Transaction Association dialog, available from the new Update
> >> Transaction Association item in the register context menu, provides the
> >> ability to have multiple associations for a single transaction.
> >> Associations may now be easily removed.
> >>>
> >>> and change it to...
> >>>
> >>> A new Transaction Association dialog, available from the new Update
> >> Transaction Association item in the register context menu with the
> addition
> >> that Associations can now be easily removed.
> >>>
> >>> Sorry if my push on Saturday caused more work for you.
> >>>
> >>> Regards,
> >>> Bob
> >>>
> >>> On Mon, 15 Jun 2020 at 18:29, John Ralls  wrote:
> >>>
> >>>
> >>>> On Jun 15, 2020, at 6:43 AM, Derek Atkins  wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> Robert Fewell <14ubo...@gmail.com> writes:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> Just noticed that the release says you can have multiple transaction
> >>>>> associations, the 6th bullet point but it is still only one per
> >> transaction.
> >>>>
> >>>> You probably should not edit anything directly in github, or it will
> >>>> probably get lost on the next push from code.
> >>>
> >>> Release notices are different from git-controlled files, though. Those
> >> are only editable via Github.
> >>>
> >>> Note though that the Github release notices, release news on
> >> https://www.gnucash.org/news.phtml, and the emailed release
> announcement
> >> all use the same text and that it starts with the www.gnucash.org news
> >> item. Those are in the gnucash-htdocs repo.
> >>>
> >>> I'll fix all of it up if you like, just tell me what line you want
> >> changed.
> >>>
> >>> 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] qof_book_is_readonly error in trace file

[Robert Fewell]

John,
No, just tried with 3.905 and I get the 4 errors.
With gdb the first is from
gnc-main-window.c:1514
gnc-plugin-aqbanking.c:348
gnc-plugin-basic-commands.c:366
gnc-plugin-business.c:1044

Regards,
Bob




On Mon, 15 Jun 2020 at 20:55, John Ralls  wrote:

>
>
> > On Jun 14, 2020, at 8:11 AM, John Ralls  wrote:
> >
> >
> >
> >> On Jun 14, 2020, at 5:16 AM, Robert Fewell <14ubo...@gmail.com> wrote:
> >>
> >> Hi,
> >>
> >> If you start gnucash with the --nofile option and then proceed to use
> the
> >> New Account Hierarchy Assistant, when you do the save you get the
> following
> >> error in the trace file 4 times...
> >>
> >> ERROR  gboolean qof_book_is_readonly(const QofBook*):
> assertion
> >> 'book != NULL' failed
> >>
> >> This I assume is because there is no book for use in
> qof_book_is_readonly,
> >> qofbook.c line 579 but that does not appear to have changed so I am
> unsure
> >> of a fix.
> >
> > I stopped it creating a session and therefore a book when you pass
> --nofile or when it can't find the file/database you asked to open so that
> it wouldn't then ask if you wanted to save the book when you opened
> something new. Looks like I missed at least one path that assumes there's
> always a book, I'll track that down after I finish the release.
>
> Hmm, can't get it to replicate now. Is this what you fixed yesterday
> morning?
>
> Regards,
> John Ralls
>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Can I edit the github release notice

[Robert Fewell]

John,
That's better than my change so please use yours.

Thankyou,
Bob

On Mon, 15 Jun 2020 at 21:10, John Ralls  wrote:

> Bob,
>
> How about "A new Transaction Association dialog, available from the Update
> Association for Transaction menu item that has replaced the two association
> items in 3.x, allows setting, changing, and deleting associations."
>
> Regards,
> John Ralls
>
> > On Jun 15, 2020, at 12:15 PM, Robert Fewell <14ubo...@gmail.com> wrote:
> >
> > Thank you John,
> > Can you change the 6th bullet point that reads...
> >
> > A new Transaction Association dialog, available from the new Update
> Transaction Association item in the register context menu, provides the
> ability to have multiple associations for a single transaction.
> Associations may now be easily removed.
> >
> > and change it to...
> >
> > A new Transaction Association dialog, available from the new Update
> Transaction Association item in the register context menu with the addition
> that Associations can now be easily removed.
> >
> > Sorry if my push on Saturday caused more work for you.
> >
> > Regards,
> > Bob
> >
> > On Mon, 15 Jun 2020 at 18:29, John Ralls  wrote:
> >
> >
> > > On Jun 15, 2020, at 6:43 AM, Derek Atkins  wrote:
> > >
> > > Hi,
> > >
> > > Robert Fewell <14ubo...@gmail.com> writes:
> > >
> > >> Hi,
> > >>
> > >> Just noticed that the release says you can have multiple transaction
> > >> associations, the 6th bullet point but it is still only one per
> transaction.
> > >
> > > You probably should not edit anything directly in github, or it will
> > > probably get lost on the next push from code.
> >
> > Release notices are different from git-controlled files, though. Those
> are only editable via Github.
> >
> > Note though that the Github release notices, release news on
> https://www.gnucash.org/news.phtml, and the emailed release announcement
> all use the same text and that it starts with the www.gnucash.org news
> item. Those are in the gnucash-htdocs repo.
> >
> > I'll fix all of it up if you like, just tell me what line you want
> changed.
> >
> > Regards,
> > John Ralls
> >
>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Can I edit the github release notice

[Robert Fewell]

Thank you John,
Can you change the 6th bullet point that reads...

A new *Transaction Association* dialog, available from the new *Update
Transaction Association* item in the register context menu, provides the
ability to have multiple associations for a single transaction.
Associations may now be easily removed.

and change it to...

A new *Transaction Association* dialog, available from the new *Update
Transaction Association* item in the register context menu with the
addition that Associations can now be easily removed.

Sorry if my push on Saturday caused more work for you.

Regards,
Bob

On Mon, 15 Jun 2020 at 18:29, John Ralls  wrote:

>
>
> > On Jun 15, 2020, at 6:43 AM, Derek Atkins  wrote:
> >
> > Hi,
> >
> > Robert Fewell <14ubo...@gmail.com> writes:
> >
> >> Hi,
> >>
> >> Just noticed that the release says you can have multiple transaction
> >> associations, the 6th bullet point but it is still only one per
> transaction.
> >
> > You probably should not edit anything directly in github, or it will
> > probably get lost on the next push from code.
>
> Release notices are different from git-controlled files, though. Those are
> only editable via Github.
>
> Note though that the Github release notices, release news on
> https://www.gnucash.org/news.phtml, and the emailed release announcement
> all use the same text and that it starts with the www.gnucash.org news
> item. Those are in the gnucash-htdocs repo.
>
> I'll fix all of it up if you like, just tell me what line you want changed.
>
> Regards,
> John Ralls
>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

[GNC-dev] Can I edit the github release notice

[Robert Fewell]

Hi,

Just noticed that the release says you can have multiple transaction
associations, the 6th bullet point but it is still only one per transaction.

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

[GNC-dev] qof_book_is_readonly error in trace file

[Robert Fewell]

Hi,

If you start gnucash with the --nofile option and then proceed to use the
New Account Hierarchy Assistant, when you do the save you get the following
error in the trace file 4 times...

ERROR  gboolean qof_book_is_readonly(const QofBook*): assertion
'book != NULL' failed

This I assume is because there is no book for use in qof_book_is_readonly,
qofbook.c line 579 but that does not appear to have changed so I am unsure
of a fix.

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

Re: [GNC-dev] Feedback on GnuCash 3.903

[Robert Fewell]

David,
Thanks for trying and the feedback, will try and answer your points...
1) The program default widths have not changed and are based on example
strings in code. So for the account / transfer column it is based on
"Expenses:Automobile:Gasoline" plus some space for the button. I added
those accounts to my test book and it fitted exactly.
2) Same thing here but it is based on a number, "999,999.000". I did fix
the double clicking on the header but you need the highlighted line to be
on the transaction as opposed to the splits. Not sure I understand the
second point.
3) Do not know why that is, you should be able to adjust the column widths
and they will be remembered as before, this aspect has not been touched.
The scheduled transactions template
 is based on the REG_TYPE_GROUP_JOURNAL group so go to 'Tools->General
Journal' and setup the desired widths from there. Will see if I can add the
menu options to the template window.


On Sun, 7 Jun 2020 at 00:29, David H  wrote:

> Hi Robert/Geert,
>
> Thanks for that.  I only use Gnucash for my personal expenses so it looks
> like I'm only using the first register group.  I've installed 3.903 and am
> happy that my use case apart from scheduled transactions is generally
> unaffected so will leave installed and continue using and if anything pops
> out of the woodwork I'll post something here if that's the way to go.
>
> For your info my setup is Win 10 Pro and I'm running gnucash on a 27"
> monitor at 1920 x 1080 res and I always run it full screen.  Dual monitor
> with laptop screen as secondary display.
>
> A few minor things I did notice are as follows :-
>
> 1. Reverting to default on a register seems to shrink the Transfer column
> down a lot further than I expected and really truncates the column.
> 2. When I review scheduled Created Transactions and revert to default it
> also cuts off the left side of the "Tot Funds In" and "Tot Funds Out"
> columns (see pic attached).  Also if I close without saving after reverting
> to default when Gnucash restarts and recreates the txn's it doesn't pick up
> the new default it seems to remain on the reverted view with the truncated
> columns.  This is also after I go to another account register with good
> columns and click on use as default for this group so it's like it's become
> orphaned from the defaults.
> 3. My list of scheduled txns seems to have shrunk the Name column.  Also
> in all of the template transactions the account column has shrunk right
> down and the Windows menu when you're in the template editor doesn't
> include the new register default entries which leads me to thinks this is
> possibly an unintended consequence and since I've got a lot of these I'm
> probably have to go and re-adjust each one :-(
> 4. If I go in and change the widths of some columns and then scroll up a
> couple of pages of txns and decide "meh this isn't looking so good" I just
> close the register and re-open it to get the defaults back so that's good.
>
> Thanks David.
>
>
>
>
> On Sat, 6 Jun 2020 at 18:34, Robert Fewell <14ubo...@gmail.com> wrote:
>
>> David,
>> There are 6 different layouts that all registers are based on as
>> described below...
>>
>> REG_TYPE_GROUP_CURRENCY;
>> BANK_REGISTER:
>> CASH_REGISTER:
>> ASSET_REGISTER:
>> CREDIT_REGISTER:
>> LIABILITY_REGISTER:
>> INCOME_REGISTER:
>> EXPENSE_REGISTER:
>> EQUITY_REGISTER:
>> TRADING_REGISTER:
>>
>> REG_TYPE_GROUP_APAR;
>> PAYABLE_REGISTER:
>> RECEIVABLE_REGISTER:
>>
>> REG_TYPE_GROUP_JOURNAL;
>> INCOME_LEDGER:
>> GENERAL_JOURNAL:
>> SEARCH_LEDGER:
>>
>> REG_TYPE_GROUP_STOCK;
>> STOCK_REGISTER:
>> CURRENCY_REGISTER:
>>
>> REG_TYPE_GROUP_PORTFOLIO;
>> PORTFOLIO_LEDGER:
>>
>> Opening sub accounts uses the Portfolio layout.
>>
>> On Sat, 6 Jun 2020 at 00:31, David H  wrote:
>>
>>> Geert,
>>>
>>> Thanks for your explanation but I still don't understand what the 6
>>> different register types you refer to are - can you point me to where
>>> these
>>> are described?
>>>
>>> My reason for having different column widths is as previously posted ...
>>>
>>> "... 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 Transf

Re: [GNC-dev] Feedback on GnuCash 3.903

[Robert Fewell]

David,
There are 6 different layouts that all registers are based on as described
below...

REG_TYPE_GROUP_CURRENCY;
BANK_REGISTER:
CASH_REGISTER:
ASSET_REGISTER:
CREDIT_REGISTER:
LIABILITY_REGISTER:
INCOME_REGISTER:
EXPENSE_REGISTER:
EQUITY_REGISTER:
TRADING_REGISTER:

REG_TYPE_GROUP_APAR;
PAYABLE_REGISTER:
RECEIVABLE_REGISTER:

REG_TYPE_GROUP_JOURNAL;
INCOME_LEDGER:
GENERAL_JOURNAL:
SEARCH_LEDGER:

REG_TYPE_GROUP_STOCK;
STOCK_REGISTER:
CURRENCY_REGISTER:

REG_TYPE_GROUP_PORTFOLIO;
PORTFOLIO_LEDGER:

Opening sub accounts uses the Portfolio layout.

On Sat, 6 Jun 2020 at 00:31, David H  wrote:

> Geert,
>
> Thanks for your explanation but I still don't understand what the 6
> different register types you refer to are - can you point me to where these
> are described?
>
> My reason for having different column widths is as previously posted ...
>
> "... 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?  "
>
> Why do I like things just the way they are ?  Well it generally depends on
> the level of nesting in my EXPENSES category - some of them are nested to 6
> levels deep so the TRANSFER column is wider in a couple of these registers
> and the DESCRIPTION column narrower than others.
>
> It's like re-opening Gnucash and having the same tabs open I guess, if I
> close a register tab and re-open it, it looks exactly the same as when I
> left it :-)
>
> I must confess that I did see this unfolding a little while ago on this
> mailing list but it didn't sink in that you would be blowing all my
> existing settings away altogether. I thought that this was only to set up a
> default for a register that hadn't yet been opened/didn't already have
> settings...  My understanding of DEFAULT is that it's only a starting point
> and I assumed that my existing settings would remain unchanged even if they
> were different within the same register type.
>
> However I appreciate that you can't please everyone and that things have to
> move on so I'm going to download this version, backup my existing settings,
> install on one of my Windows pc's and see what it messes with and if it
> really is going to upset my apple cart :-)
>
> Happy to provide feedback as to whether I see it as an issue after I see it
> in practice...
>
> It might also be beneficial to explain what's happening on the wider user
> list before it goes live, I don't think I've seen any mention of this
> change there.  I know you said you are responding to complaints re setting
> register column widths but you know what they say "the noisy wheel gets the
> most oil" and it appears the silent majority are content with things as is.
>
> Getting rid of that hidden automatic expansion on the description column
> will probably also alleviate some of the complaints.
>
> Thanks David H.
>
>
>
> On Sat, 6 Jun 2020 at 06:46, Geert Janssens 
> wrote:
>
> > Op vrijdag 5 juni 2020 20:45:07 CEST schreef 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.
> > >
> > Note default columns widths are not set automatically. GnuCash can't know
> > if you just tweaked
> > a column temporarily for whatever reason or you want this to be the
> > default for a given register
> > type. So to set defaults the user has to select the appropriate command
> in
> > the Windows menu.
> >
> > As there are no account level presets any more, how can GnuCash know
> which
> > preferences to
> > apply if you have different preferences for different accounts in the
> same
> > register type group ?
> > At best we can read them once and convert them to preferences for an open
> > tab (which is not
> > the same as preferences for a given account). Once you close the tab the
> > tab preferences are
> > gone with it.
> >
> > As for motivations to drop account level presets, read on.
> >
> > > 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, 

Re: [GNC-dev] Feedback on GnuCash 3.903

[Robert Fewell]

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 *transfer* columns,
>> too
>> > > > narrow to fit the text they contain. Again, I had to restore my
>> backup
>> > > gcm
>> > > > file to restore all my custom set

Re: [GNC-dev] Feedback on GnuCash 3.903

[Robert Fewell]

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 *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 <
> > christopher@gmail.com
> > > >
> > > 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
> > > >>> + 

[GNC-dev] 'g_signal_handler_disconnect: assertion' on master

[Robert Fewell]

Hi,

I built master in a different VM and ran Gnucash from there that happened
to have and open Invoice and when I closed it I got the following...

* 11:52:31 ERROR  g_signal_handler_disconnect: assertion
'G_TYPE_CHECK_INSTANCE (instance)' failed

I tracked this down to a difference in the way the sheet is closed between
registers and invoices. The gnc-date-cell-destroy is being called before
the gnc-item_edit_destroying for invoices and so when the item_edit tries
to do the signal disconnect on the popup_item it no longer exists.

It can be fixed by moving gtk_widget_destroy(widget);, line 617 in
dialog-invoice.c to above the gnc_entry_ledger_destroy (iw->ledger);

Just not sure if this causes a different problem, all seems to work but as
I do not use invoices would like a second opinion.

Regards,

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

Re: [GNC-dev] view_selection_function in the main_matcher, why was it added?

[Robert Fewell]

Jean,
I think that is used in rubber banding the list so only valid entries are
selected.
Regards,
Bob

On Sun, 17 May 2020 at 02:57, jeanl  wrote:

> The view_selection_function in the main_matcher was added at
> caeea74b5003788a79fd684e50244dac44f11e93
> I'm trying to understand why that was needed. Here's the commit message,
> but
> I'm not sure what the problem was it was trying to solve.
> The issue currently is that because of this function, transactions under
> the
> cursor are or are not highlighted in the matching windows, depending on the
> action that's selected. This is very confusing as you can move the cursor
> up, and you don't see any difference in the display until you hit a
> transaction that can be highlighted (based on what
> view_selection_function()
> returns).
> Jean
>
>
> Author: David Cousens 
> Commit: David Cousens 
>
> Add view_selection_function
>
> view_selection_function added to only allow adding a row to the
> selection if GNCImport_Add is set for the transaction.
> Explicit selection clearing
>
> try explicitly clearing the row in the add, update and clear toggle
> callbacks - before refresh row and add debugging info which showed that the
> selection is called after exiting the above callbacks and as the
> view_selection_function has no knowledge that the add checkbox has just
> been
> toggled it allows the row to be selected. Requires a flag to be set in the
> add_toggle_cb which prevents selection in the view_selection_function and
> is
> cleared there.
> Fix row being selected after A(dd)toggled
>
> When the A is toggled on from U+R or R the row is automatically
> selected
> and if the row is toggled back to U+R or R selected, it cannot be
> unselected. Add a global add-toggled flag set in the
> gnc_gen_trans_add-toggled_cb and used in the treeview  multiple selection
> function to prevent a row being selected immediately after the A has been
> toggled.
> Fix to Multiple selection to ensure the match dialog comes up on double
> click on a  reconciled or update row and implement a
> view_selection_function
> so that only rows flagged for addition can be added to a selection
>
>
> Fixes requested by Bob-IT
>
> removed global add_toggled variable and added it to _main_matcher_info
> structure. modified gnc_gen_trans_add_toggled_cb and
> view_selection_function
> to use the _main_matcher_info member.
>
>
>
> --
> 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] Windows master build fails to run

[Robert Fewell]

Oh well, that was not it but maybe related...
stack trace...

(gdb) bt
#0  0x74a9e2d3 in KERNELBASE!DebugBreak () from
C:\WINDOWS\System32\KernelBase.dll
#1  0x64c31919 in libglib-2.0-0!g_abort () from c:\Program Files
(x86)\gnucash\bin\libglib-2.0-0.dll
#2  0x64bfd504 in libglib-2.0-0!g_mem_profile () from c:\Program Files
(x86)\gnucash\bin\libglib-2.0-0.dll
#3  0x64bfe280 in libglib-2.0-0!g_logv () from c:\Program Files
(x86)\gnucash\bin\libglib-2.0-0.dll
#4  0x64bfe487 in libglib-2.0-0!g_log () from c:\Program Files
(x86)\gnucash\bin\libglib-2.0-0.dll
#5  0x0264ad12 in qof_log_check (domain=0x0, level=(QOF_LOG_WARNING |
unknown: 2))
at
C:/gcdev64/gnucash/master/src/gnucash-git/libgnucash/engine/qoflog.cpp:327
#6  0x0264a707 in log4glib_handler (log_domain=0x0, log_level=18,
message=0xf5d9d78 "Could not spawn perl: Failed to execute child
process (Bad file descriptor)",
user_data=0x9e78ec0) at
C:/gcdev64/gnucash/master/src/gnucash-git/libgnucash/engine/qoflog.cpp:169
#7  0x64bfe254 in libglib-2.0-0!g_logv () from c:\Program Files
(x86)\gnucash\bin\libglib-2.0-0.dll
#8  0x64bfe487 in libglib-2.0-0!g_log () from c:\Program Files
(x86)\gnucash\bin\libglib-2.0-0.dll
#9  0x63f83150 in gnc_spawn_process_async (argl=0xe646770, search_path=1)
at
C:/gcdev64/gnucash/master/src/gnucash-git/bindings/guile/glib-guile.c:268
#10 0x63fc6790 in _wrap_gnc_spawn_process_async (s_0=0x13524438, s_1=0x404)
at bindings/guile/swig-engine.c:41019
#11 0x6e819a9d in vm_regular_engine (thread=0x10fd1f00, vp=0x1136df78,
registers=0x105f690, resume=0)
at
C:/gcdev64/gnucash/master/src/guile-2.2.4.68-65d98/libguile/vm-engine.c:786

On Fri, 15 May 2020 at 11:42, Robert Fewell <14ubo...@gmail.com> wrote:

> Chris,
>
> I get this when I uninstalled Strawberry Perl, I think it is down to
> glib-guile.c line 65
> static QofLogModule UNUSED_VAR log_module = GNC_MOD_GUILE;
>
> Just removed UNUSED_VAR and trying a build to prove.
>
> Regards,
> Bob
>
> On Fri, 15 May 2020 at 05:18, Chris Good  wrote:
>
>> Hi John,
>>
>>
>>
>> Trying to test your fix for
>> https://bugs.gnucash.org/show_bug.cgi?id=797052
>>
>> Using
>>
>> https://code.gnucash.org/builds/win32/master/gnucash-3.902-2020-05-14-git-3.
>> 902-120-g09a8bee5c+.setup.exe
>> <https://code.gnucash.org/builds/win32/master/gnucash-3.902-2020-05-14-git-3.902-120-g09a8bee5c+.setup.exe>
>>
>>
>>
>> No perl installed.
>>
>> Gets "Unspecified fatal error encountered, aborting"
>>
>> which BTW is difficult to see as it is hidden behind Tips Of The Day.
>>
>>
>>
>> Only thing obvious to me in trace (attached) is
>>
>> * 13:49:37 MESSG  Could not locate optional module
>> gnucash/python interface v.0
>>
>>
>>
>> Regards,
>>
>> Chris Good
>>
>>
>>
>> ___
>> 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] Windows master build fails to run

[Robert Fewell]

Chris,

I get this when I uninstalled Strawberry Perl, I think it is down to
glib-guile.c line 65
static QofLogModule UNUSED_VAR log_module = GNC_MOD_GUILE;

Just removed UNUSED_VAR and trying a build to prove.

Regards,
Bob

On Fri, 15 May 2020 at 05:18, Chris Good  wrote:

> Hi John,
>
>
>
> Trying to test your fix for
> https://bugs.gnucash.org/show_bug.cgi?id=797052
>
> Using
>
> https://code.gnucash.org/builds/win32/master/gnucash-3.902-2020-05-14-git-3.
> 902-120-g09a8bee5c+.setup.exe
> 
>
>
>
> No perl installed.
>
> Gets "Unspecified fatal error encountered, aborting"
>
> which BTW is difficult to see as it is hidden behind Tips Of The Day.
>
>
>
> Only thing obvious to me in trace (attached) is
>
> * 13:49:37 MESSG  Could not locate optional module
> gnucash/python interface v.0
>
>
>
> Regards,
>
> Chris Good
>
>
>
> ___
> 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] Windows build fails to run

[Robert Fewell]

John,
Thank you, log file back to how it was.

Regards,
Bob

On Tue, 12 May 2020 at 22:49, John Ralls  wrote:

> I'd screwed up a couple of things, now fixed and pushed.
>
> Regards,
> John Ralls
>
>
> > On May 12, 2020, at 9:22 AM, John Ralls  wrote:
> >
> > Bob,
> >
> > I found that late yesterday afternoon. It seems to be from my change
> changing the mapping of log level by log domain from GHashTable to nested
> C++ std::vectors. If I don't get it sorted shortly I'll revert that change.
> >
> > Regards,
> > John Ralls
> >
> >
> >> On May 12, 2020, at 4:28 AM, Robert Fewell <14ubo...@gmail.com> wrote:
> >>
> >> John,
> >>
> >> So the logging is different now, updated master on my Linux VM and with
> nothing else changed in that environment which has been building with -ggdb.
> >> Built OK but when I ran it I ended up with an unresponsive Gnucash,
> ended up by force quitting. Looked at the trace file which was 1.6GB.
> >> Looking at it, it looks like it is every single INFO, DEBUG message
> possible.
> >>
> >> Previously, to get more trace information I would start gnucash with
> --debug and then control the module detail I wanted with a log.conf file.
> >>
> >> Do I need to do something different now, always use a log.conf with
> every entry set to info and then set individual modules to debug when
> required.
> >> I have not tried this yet but will later to see how much is logged.
> >>
> >> Regards,
> >> Bob
> >>
> >>
> >> On Mon, 11 May 2020 at 17:28, John Ralls  wrote:
> >>
> >>
> >>> On May 11, 2020, at 4:45 AM, Robert Fewell <14ubo...@gmail.com> wrote:
> >>>
> >>> #6  0x0244ae57 in qof_log_check (domain=0x0, level=(QOF_LOG_WARNING |
> unknown: 2))
> >>>at
> C:/gcdev64/gnucash/master/src/gnucash-git/libgnucash/engine/qoflog.cpp:308
> >>
> >> That's what I suspected. I made qof_log_check do a
> g_return_value_if_fail on domain=NULL and it caused crashes in some tests
> that didn't have G_LOG_DOMAIN set.
> >>
> >>> Have you noticed that the Windows trace file has DEBUG entries as
> default?
> >>>
> >>
> >> Yeah, that's on purpose because for most users getting a stack trace is
> too hard. Having GnuCash always run with --debug gets as much info on
> crashes as possible. What I'm not sure about is how G_DEBUG is getting set.
> Unless something got changed in GLib recently that's what turns on
> g_abort() from a CRITICAL log message.
> >>
> >> So I'll rework qof_log_check to log a WARNING about a NULL domain and
> use a substitute one (maybe "gnc.unknown") for the log message.
> >>
> >> 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] Windows build fails to run

[Robert Fewell]

John,

So the logging is different now, updated master on my Linux VM and with
nothing else changed in that environment which has been building with -ggdb.
Built OK but when I ran it I ended up with an unresponsive Gnucash, ended
up by force quitting. Looked at the trace file which was 1.6GB.
Looking at it, it looks like it is every single INFO, DEBUG message
possible.

Previously, to get more trace information I would start gnucash with
--debug and then control the module detail I wanted with a log.conf file.

Do I need to do something different now, always use a log.conf with every
entry set to info and then set individual modules to debug when required.
I have not tried this yet but will later to see how much is logged.

Regards,
Bob


On Mon, 11 May 2020 at 17:28, John Ralls  wrote:

>
>
> > On May 11, 2020, at 4:45 AM, Robert Fewell <14ubo...@gmail.com> wrote:
> >
> > #6  0x0244ae57 in qof_log_check (domain=0x0, level=(QOF_LOG_WARNING |
> unknown: 2))
> > at
> C:/gcdev64/gnucash/master/src/gnucash-git/libgnucash/engine/qoflog.cpp:308
>
> That's what I suspected. I made qof_log_check do a g_return_value_if_fail
> on domain=NULL and it caused crashes in some tests that didn't have
> G_LOG_DOMAIN set.
>
> > Have you noticed that the Windows trace file has DEBUG entries as
> default?
> >
>
> Yeah, that's on purpose because for most users getting a stack trace is
> too hard. Having GnuCash always run with --debug gets as much info on
> crashes as possible. What I'm not sure about is how G_DEBUG is getting set.
> Unless something got changed in GLib recently that's what turns on
> g_abort() from a CRITICAL log message.
>
> So I'll rework qof_log_check to log a WARNING about a NULL domain and use
> a substitute one (maybe "gnc.unknown") for the log message.
>
> Regards,
> John Ralls
>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Windows build fails to run

[Robert Fewell]

andler_data=0x1136a510)
at
C:/gcdev64/gnucash/master/src/guile-2.2.4.68-65d98/libguile/continuations.c:360
#28 0x6e7914c4 in scm_c_with_continuation_barrier (func=0x6e7b01e0
, data=0xe3fba0)
at
C:/gcdev64/gnucash/master/src/guile-2.2.4.68-65d98/libguile/continuations.c:456
#29 0x6e809675 in with_guile (base=0xe3fb4c, data=0xe3fb74)
at
C:/gcdev64/gnucash/master/src/guile-2.2.4.68-65d98/libguile/threads.c:661
#30 0x70bcdcbc in GC_call_with_stack_base (fn=fn@entry=0x6e809630
, arg=arg@entry=0xe3fb74)
at C:/gcdev64/gnucash/master/src/bdwgc/misc.c:1935
#31 0x6e80a060 in scm_i_with_guile (dynamic_state=,
data=0xe3fba0, func=0x6e7b01e0 )
at
C:/gcdev64/gnucash/master/src/guile-2.2.4.68-65d98/libguile/threads.c:704
#32 scm_with_guile (func=func@entry=0x6e7b01e0 ,
data=data@entry=0xe3fba0)
at
C:/gcdev64/gnucash/master/src/guile-2.2.4.68-65d98/libguile/threads.c:710
#33 0x6e7b0417 in scm_boot_guile (argc=1, argv=0x83f5770,
main_func=0x1c34ba, closure=0x0)
at
C:/gcdev64/gnucash/master/src/guile-2.2.4.68-65d98/libguile/init.c:324
#34 0x001c3d6c in ?? ()
#35 0x001c1396 in ?? ()
#36 0x75eb6359 in KERNEL32!BaseThreadInitThunk () from
C:\WINDOWS\System32\kernel32.dll
#37 0x776c7c24 in ntdll!RtlGetAppContainerNamedObjectPath () from
C:\WINDOWS\SYSTEM32\ntdll.dll
#38 0x776c7bf4 in ntdll!RtlGetAppContainerNamedObjectPath () from
C:\WINDOWS\SYSTEM32\ntdll.dll
#39 0x in ?? ()
(gdb)

Regards,
Bob

On Sun, 10 May 2020 at 18:30, John Ralls  wrote:

>
>
> > On May 10, 2020, at 9:30 AM, John Ralls  wrote:
> >
> >
> >
> >> On May 10, 2020, at 7:44 AM, Robert Fewell <14ubo...@gmail.com> wrote:
> >>
> >> Hi,
> >> Just trying a change but my build failed to run, tried the nightlies and
> >> the Windows build 3.902 gf23e3b266 fails to run also but the one before
> >> does f1ff78965
> >> All it says "Unspecified fatal error encountered, aborting"
> >
> > Bob,
> >
> > Today's master nightly, gf23e3b266, starts up fine for me. Can you get a
> stack trace?
> >
>
> Another thought, check the trace file for "assertion failed (domain &&
> level && modules)"
>
> Regards,
> John Ralls
>
>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

[GNC-dev] Windows build fails to run

[Robert Fewell]

Hi,
Just trying a change but my build failed to run, tried the nightlies and
the Windows build 3.902 gf23e3b266 fails to run also but the one before
does f1ff78965
All it says "Unspecified fatal error encountered, aborting"

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

Re: [GNC-dev] Master problem when entering account in register

[Robert Fewell]

Chris,

I can not reproduce your exact problem but I have ended up with a blank
drop down.
Jean Laroche made some changes in this area, may be related, see commit...

Merge Jean Laroche's 'fix_autocompletion_master' into master,
f74d7c52da378b126a1a0faffaddfb802b44dd8c

Regards,

Bob

On Fri, 24 Apr 2020 at 06:46, Chris Good  wrote:

> Hi,
>
>
>
> I'm seeing what looks like a problem in GnuCash built from source pulled
> from git master with latest commit:
>
> 5th Apr 2020 No gnucash/gettext scm module anymore, the translation defs
> are
> in core-utils a392190adf877b552c25936c493c4d63a4a83e8f.
>
>
>
> Say I have a transaction with 2 splits:
>
> Assets:Current Assets:Bank1
>
> Expenses:Groceries Joint
>
>
>
> I click on the transaction Description, then click into the Account field
> for the Expenses split.
>
> It shows "Expenses: Groceries Joint" with nothing selected and insertion
> cursor at the front.
>
> I highlight the full field using Shift End.
>
> Type ex and the field shows (nothing highlighted):
>
> rage CommSec CG:AMP CGex
>
> and nothing in the now open selection list.
>
> This is a combination of my Asset account Assets:Investments:Brokerage
> CommSec CG:AMP CG
>
> and the ex I typed.
>
>
>
> This is running client Ubuntu 18.04 in VirtualBox on host Windows 10.
>
>
>
> This seems like text selection
>  Bug 797052 - Autofill
> Selection is Corrupted After Clicking Description.
>
>
>
> This is not happening with my maint built from source in the same VM.
>
>
>
> Can anyone else duplicate this problem?
>
>
>
> Regards,
>
> Chris Good
>
>
>
> ___
> 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] Windows master build

[Robert Fewell]

Guys,
Tried to do a build on my Windows 10 setup after doing some updates to OS
and build system and it failed for these reasons...

CMakeLists.txt , line 927 and 928 could not find the dll's specified
Changing find_library to find_file worked, this maybe due to cmake being
updated to 3.17.0

Also it failed on inno setup, gnucash_mingw64.iss, line 135, libffi-6.dll
is now libffi-7.dll

Not sure if the build server does a msys/mingw update on a regular basis,
thought I would point out what happened to me.

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

Re: [GNC-dev] Gnucash on master fails to start

[Robert Fewell]

Just noticed fix from Chris, ignore this...

Bob

On Wed, 1 Apr 2020 at 16:52, Robert Fewell <14ubo...@gmail.com> wrote:

> Hi,
>
> Rebased one of my branches on master and it now fails to run with this on
> the terminal...
>
> Backtrace:
>4 (apply-smob/1 #)
> In ice-9/boot-9.scm:
>2312:4  3 (save-module-excursion #)
> In ice-9/eval-string.scm:
>  38:6  2 (read-and-eval # #:lang _)
> In gnucash/price-quotes.scm:
>524:17  1 (gnc:price-quotes-install-sources)
>  42:0  0 (gnc:fq-check-sources)
>
> gnucash/price-quotes.scm:42:0: In procedure gnc:fq-check-sources:
> In procedure module-lookup: Unbound variable: gnc-spawn-process-async
>
> Thought it was my branch, so checked out master, builds OK but fails to
> start as above.
> Was there a change needed for master, I see there were some changes to
> price-quotes.scm in maint ?
>
>
> Regards,
> Bob
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

[GNC-dev] Gnucash on master fails to start

[Robert Fewell]

Hi,

Rebased one of my branches on master and it now fails to run with this on
the terminal...

Backtrace:
   4 (apply-smob/1 #)
In ice-9/boot-9.scm:
   2312:4  3 (save-module-excursion #)
In ice-9/eval-string.scm:
 38:6  2 (read-and-eval # #:lang _)
In gnucash/price-quotes.scm:
   524:17  1 (gnc:price-quotes-install-sources)
 42:0  0 (gnc:fq-check-sources)

gnucash/price-quotes.scm:42:0: In procedure gnc:fq-check-sources:
In procedure module-lookup: Unbound variable: gnc-spawn-process-async

Thought it was my branch, so checked out master, builds OK but fails to
start as above.
Was there a change needed for master, I see there were some changes to
price-quotes.scm in maint ?


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

Re: [GNC-dev] Ideas for account type-ahead modification

[Robert Fewell]

Jean,
That patch was for register2 which is stalled, it has no bearing on the
current version.

Bob

On Tue, 10 Mar 2020 at 16:53, Frank H. Ellenberger <
frank.h.ellenber...@gmail.com> wrote:

> Jean,
>
> Am 10.03.20 um 17:41 schrieb Jean Laroche:
> > Frank,
> > I tried reviving this patch, but git patch failed. I recreated the patch
> > manually (which wasn't very hard given that it contains few changes) but
> > I don't see any effect (not breakpoint is hit). So I'm wondering whether
> > this patch is still useful.
>
> I believe, Bob will faster understand, what is happening there.
>
> ~Frank
>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] [GNC] Reports have got broken with commit f66b7ed

[Robert Fewell]

I have pushed my fix to maint so if you build again it should now work.
Regards,
Bob

On Sat, 15 Feb 2020 at 15:15, Robert Fewell <14ubo...@gmail.com> wrote:

> Hi, I know what the report problem is, just doing some testing, will
> hopefully push later or tomorrow.
>
> Regards,
> Bob
>
> On Fri, 14 Feb 2020 at 22:59, John Ralls  wrote:
>
>>
>>
>> > On Feb 14, 2020, at 10:33 AM, Peter Zimmerer  wrote:
>> >
>> > Hi John,
>> >
>> > thanks for your prompt response.
>> >
>> > Am 14.02.20 um 18:34 schrieb John Ralls:
>> >>
>> >>> On Feb 14, 2020, at 7:00 AM, Peter Zimmerer  wrote:
>> >>>
>> >>> Hi all,
>> >>>
>> >>> if I build gnucash from commit f66b7ed (or a newer commit in maint)
>> any
>> >>> report from the "Reports" menu will show up with an empty page.
>> >>> If I keep the report open and close gnucash the report will be
>> displayed
>> >>> correctly after restart of gnucash.
>> >>> If I open a new report or a report from the "Saved Report
>> >>> Configurations" an empty page will show up again.
>> >>>
>> >>> A build from the previous commit 58ddb47 does not show this
>> issue/behavior.
>> >>>
>> >>> Can anybody confirm this behavior?
>> >> It worked OK for me on Arch Linux with a fresh maint build just now.
>> On what platform are you testing?
>> >
>> > I am on Debian 10.3 with Gnome desktop amd I am testing the newest
>> > version of Aqbanking and Gwenhyfar with Gnucash.
>> > I have just tried it with the most recent commit b23d244 from maint on
>> > Github and could reproduce the issue.
>> >
>> >>
>> >> BTW, questions about builds from git are better directed to
>> gnucash-devel than to here.
>> >
>> > Thanks for the info. I will use gnucash-devel now.
>>
>> OK, I updated my Debian 10 VM and see the problem there. On a hunch I did
>> a system update on Arch and now see the same problem.
>>
>> Bob Fewell, this is about your "Follow up to previous commit 94cb965/Bug
>> 797570" aka PR 644. In addition to the report not generating I get the
>> following on the terminal when I open an SX editor window:
>> sys:1: Warning: ../../../gobject/gsignal.c:2523: signal 'page_changed' is
>> invalid for instance '0x55a669b844d0' of type 'GncEmbeddedWindow'
>>
>> Regards,
>> John Ralls
>>
>>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] [GNC] Reports have got broken with commit f66b7ed

[Robert Fewell]

Hi, I know what the report problem is, just doing some testing, will
hopefully push later or tomorrow.

Regards,
Bob

On Fri, 14 Feb 2020 at 22:59, John Ralls  wrote:

>
>
> > On Feb 14, 2020, at 10:33 AM, Peter Zimmerer  wrote:
> >
> > Hi John,
> >
> > thanks for your prompt response.
> >
> > Am 14.02.20 um 18:34 schrieb John Ralls:
> >>
> >>> On Feb 14, 2020, at 7:00 AM, Peter Zimmerer  wrote:
> >>>
> >>> Hi all,
> >>>
> >>> if I build gnucash from commit f66b7ed (or a newer commit in maint) any
> >>> report from the "Reports" menu will show up with an empty page.
> >>> If I keep the report open and close gnucash the report will be
> displayed
> >>> correctly after restart of gnucash.
> >>> If I open a new report or a report from the "Saved Report
> >>> Configurations" an empty page will show up again.
> >>>
> >>> A build from the previous commit 58ddb47 does not show this
> issue/behavior.
> >>>
> >>> Can anybody confirm this behavior?
> >> It worked OK for me on Arch Linux with a fresh maint build just now. On
> what platform are you testing?
> >
> > I am on Debian 10.3 with Gnome desktop amd I am testing the newest
> > version of Aqbanking and Gwenhyfar with Gnucash.
> > I have just tried it with the most recent commit b23d244 from maint on
> > Github and could reproduce the issue.
> >
> >>
> >> BTW, questions about builds from git are better directed to
> gnucash-devel than to here.
> >
> > Thanks for the info. I will use gnucash-devel now.
>
> OK, I updated my Debian 10 VM and see the problem there. On a hunch I did
> a system update on Arch and now see the same problem.
>
> Bob Fewell, this is about your "Follow up to previous commit 94cb965/Bug
> 797570" aka PR 644. In addition to the report not generating I get the
> following on the terminal when I open an SX editor window:
> sys:1: Warning: ../../../gobject/gsignal.c:2523: signal 'page_changed' is
> invalid for instance '0x55a669b844d0' of type 'GncEmbeddedWindow'
>
> Regards,
> John Ralls
>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Comments in the state file

[Robert Fewell]

If I remember, it was added due to a comment about not being able to
identify the section to delete easily if the widths got mucked up as the
group is based on the guid of the register which I think it is still nice
to have

On Fri, 20 Dec 2019 at 19:02, John Ralls  wrote:

>
>
> > On Dec 20, 2019, at 5:50 AM, Robert Fewell <14ubo...@gmail.com> wrote:
> >
> > Hi,
> > Need some advise on this problem I found when trying to fix a budget
> state
> > file issue...
> > Currently the register full name is being added as a comment to the
> > register sections of the state file based on the group, so we have...
> >
> > #Register state for "Assets:Current Assets:Savings Account"
> > [Register 5ca76dbe6668a75daeffd33b1229fa0e]
> > date_width=111
> > ...
> > Unfortunately, when the state file is loaded it strips out all the
> comments
> > and it is only the registers that have been open in the current session
> > that get there comments added back on save.
> > There is a key file flag that can be set, G_KEY_FILE_KEEP_COMMENTS but
> this
> > has the disadvantage of ending up with the comment being added on every
> > close so you end up with multiple comments like ...
> >
> > #Register state for "Assets:Current Assets:Savings Account"
> >
> > #Register state for "Assets:Current Assets:Savings Account"
> > [Register 5ca76dbe6668a75daeffd33b1229fa0e]
> > date_width=111
> > ...
> > This does not happen if the comment is for a key, so if the date_width
> was
> > used you get...
> >
> > [Register 5ca76dbe6668a75daeffd33b1229fa0e]
> > #Register state for "Assets:Current Assets:Savings Account"
> > date_width=111
> > ...
> > So my first idea was to make the changes for above on maint and then in
> > master make the key file flag change but this would not work, if some one
> > from a version less than 3.8 upgraded to 4.0, there key file would still
> > have group comments and they would start multiplying on each save. I did
> > try removing the group comment but that does not work with the new key
> file
> > flag,
> >
> > The only other thing I can think of is add a dummy key and put the
> register
> > full name in that which what I had done originally. The reason for asking
> > is I want to add a similar comment for the budget as it is only
> > identifiable by the guid and was looking at the lack of saving of the
> > invoice sheet layout hoping to get that sorted on master.
>
> What purpose is served by having the account name in the file at all?
>
> If it's really necessary then I think the dummy key is indeed the way to
> go: If you have a keep-comment at the key level then it would have to be on
> every key or would need logic to always move it to the first key at every
> write.
>
> Regards,
> John Ralls
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

[GNC-dev] Comments in the state file

[Robert Fewell]

Hi,
Need some advise on this problem I found when trying to fix a budget state
file issue...
Currently the register full name is being added as a comment to the
register sections of the state file based on the group, so we have...

#Register state for "Assets:Current Assets:Savings Account"
[Register 5ca76dbe6668a75daeffd33b1229fa0e]
date_width=111
...
Unfortunately, when the state file is loaded it strips out all the comments
and it is only the registers that have been open in the current session
that get there comments added back on save.
There is a key file flag that can be set, G_KEY_FILE_KEEP_COMMENTS but this
has the disadvantage of ending up with the comment being added on every
close so you end up with multiple comments like ...

#Register state for "Assets:Current Assets:Savings Account"

#Register state for "Assets:Current Assets:Savings Account"
[Register 5ca76dbe6668a75daeffd33b1229fa0e]
date_width=111
...
This does not happen if the comment is for a key, so if the date_width was
used you get...

[Register 5ca76dbe6668a75daeffd33b1229fa0e]
#Register state for "Assets:Current Assets:Savings Account"
date_width=111
...
So my first idea was to make the changes for above on maint and then in
master make the key file flag change but this would not work, if some one
from a version less than 3.8 upgraded to 4.0, there key file would still
have group comments and they would start multiplying on each save. I did
try removing the group comment but that does not work with the new key file
flag,

The only other thing I can think of is add a dummy key and put the register
full name in that which what I had done originally. The reason for asking
is I want to add a similar comment for the budget as it is only
identifiable by the guid and was looking at the lack of saving of the
invoice sheet layout hoping to get that sorted on master.

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

Re: [GNC-dev] Translators: Re: To colon or not to colon

[Robert Fewell]

Frank,
Yes the trailing space is a mistake so was going to get rid of that any
way, possibly it was added for alignment.

So, the only other question as part of this is whether the labels should be
left aligned or right and again there is a mix of the two in various
dialogs.
The page you linked to says they should be right aligned so there is the
minimum space between the label and control but I quite like it being left.

As part of the changes to use grids, I will probably need to set this so I
just want it to be consistent and only change it once.

Any thoughts, left or right aligned ?

Regards,
Bob

On Sun, 3 Nov 2019 at 23:08, Frank H. Ellenberger <
frank.h.ellenber...@gmail.com> wrote:

> Hi Bob,
>
> Am Do., 31. Okt. 2019 um 12:11 Uhr schrieb Robert Fewell <
> 14ubo...@gmail.com>:
> >
> > Hi,
> > I have PR563 which I want to progress and it has a couple of commits that
> > either add a missing colon or remove a trailing space from a label with a
> > colon next to a entry widget. These will require translation changes so I
> > was wondering if there is a consensus of whether these sort of labels
> > should or should not have a trailing colon.
>
> IMHO a trailing space should be seen as an input error and be fixed
> immediately.
>
> In the times of command line interfaces, the colon was common to show,
> the program is waiting for input.
> This was also inherited in the first simple GUI's.
> But as of today, there are other properties like text style to
> distinguish input field labels from content, see i.e.
> https://developer.gnome.org/hig/stable/visual-layout.html.en. So we
> should remove them.
>
> But because we usually add mnemonics, they will still in most cases
> still be different from the base words. OTOH if we are consistent, we
> should still reduce the number of translatable strings.
>
> If nobody *protests now*, we should remove them immediately.
>
> > Looking at other places, the job dialogue doesn't, the invoice page
> > doesn't, the transfer dialogue does, the schedule dialogue also does and
> > also the print dialogue mostly.
> >
> > I would imagine if this was consistently done it may reduce the number of
> > translations a bit.
> >
> > Regards,
> > Bob
>
> Regards
> Frank
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

[GNC-dev] To colon or not to colon

[Robert Fewell]

Hi,
I have PR563 which I want to progress and it has a couple of commits that
either add a missing colon or remove a trailing space from a label with a
colon next to a entry widget. These will require translation changes so I
was wondering if there is a consensus of whether these sort of labels
should or should not have a trailing colon.

Looking at other places, the job dialogue doesn't, the invoice page
doesn't, the transfer dialogue does, the schedule dialogue also does and
also the print dialogue mostly.

I would imagine if this was consistently done it may reduce the number of
translations a bit.

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

[GNC-dev] Tax Tables

[Robert Fewell]

Hi,

I got distracted with these warning in my trace file as I like to build/run
with an empty one so I know any errors are down to me, these are from an
XML file with one open invoice when saving...

* 11:58:50  WARN  [taxtable_reset_refcount()] Fixing refcount on
taxtable 2dca815fad04436cbb5497517803cc79 (2 -> 1)
* 11:58:56 ERROR  xmlNode* time64_to_dom_tree(const char*,
time64): assertion 'time != INT64_MAX' failed
* 11:58:56 ERROR  xmlNode* time64_to_dom_tree(const char*,
time64): assertion 'time != INT64_MAX' failed
* 11:58:56 ERROR  xmlNode* time64_to_dom_tree(const char*,
time64): assertion 'time != INT64_MAX' failed
* 11:58:56 ERROR  xmlNode* time64_to_dom_tree(const char*,
time64): assertion 'time != INT64_MAX' failed
* 11:58:56 ERROR  xmlNode* time64_to_dom_tree(const char*,
time64): assertion 'time != INT64_MAX' failed

taking the time64 errors first, I was going to propose changing
maybe_add_time64 in gnc-invoice-xml-v2.cpp as follows...

if (time)
to
   if (time && time != INT64_MAX)
xmlAddChild (ptr, time64_to_dom_tree (tag, time));

any one see a problem with that ?

Now the first warning, this is due to the blank ledger entry in the open
invoice having the tax table cell filled in with the default one for that
customer and when one quits Gnucash the file save happens before the gui is
destroyed so the refcount will always be wrong by the number of open
invoices.
I did think about decreasing the refcount for the table in the blank entry
but that causes another issue with the value going below 0 unless it could
be increased before the ledger is destroyed.

Can any one else see a way of fixing this, maybe just change it to an info
message ?

On a similar note, if you save the file as a sqlite3 one, the refcount will
increase on every save / open by the number of open invoices which is down
to new entries with the default tax table being added to the 'entries
table' which also do not have an invoice value.

No clue on this one.

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

Re: [GNC-dev] Windows nightly not building

[Robert Fewell]

Thank you John.

Bob

On Wed, 31 Jul 2019 at 16:29, John Ralls  wrote:

>
> > On Jul 31, 2019, at 2:16 AM, Robert Fewell <14ubo...@gmail.com> wrote:
> >
> > Hi,
> > The last Windows nightly built was on the 24/07/2019, could someone have
> a
> > look and fix.
>
> There was a hung Guile task from the 25th. I killed it, ran make clean in
> the build-dir, and fired off another build.
>
> Regards,
> John Ralls
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

[GNC-dev] Windows nightly not building

[Robert Fewell]

Hi,
The last Windows nightly built was on the 24/07/2019, could someone have a
look and fix.

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

[GNC-dev] Git Push

[Robert Fewell]

Hi,
I pushed my branch bug797278 to code and I do not think code updated
github, I received this message...

Enter passphrase for key '/root/.ssh/gnucash-key':
Enumerating objects: 46, done.
Counting objects: 100% (46/46), done.
Compressing objects: 100% (32/32), done.
Writing objects: 100% (32/32), 5.64 KiB | 1.88 MiB/s, done.
Total 32 (delta 28), reused 0 (delta 0)
remote: *** Mirror changes to origin (usually github)...
remote: ssh: Could not resolve hostname github.com: Name or service not
known
remote: fatal: Could not read from remote repository.
remote:
remote: Please make sure you have the correct access rights
remote: and the repository exists.
To code.gnucash.org:gnucash
   03d9bf902..b50ed4755  bug797278 -> maint

I have done a git fetch --all and then git log code/maint and can see my
commits in the log so is it just a matter of waiting for another push to
get code to send my commits to github ?

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

Re: [GNC-dev] Buttons in GnuCash for now and in the future

[Robert Fewell]

As I stated in the bug I would prefer no icons or very selective ones but
applied consistently across all dialogues in one go.
When I migrated all the dialogues I made a conscious decision to remove all
icons on all buttons to have a consistent look.
You can make the button translatable in the glade file and I forgot ticking
the box for the Aq banking glade changes.
I can easily check all glade files for the missing setting if required.

Regards,
Bob

On Fri, 24 May 2019 at 05:29, John Ralls  wrote:

>
>
> > On May 23, 2019, at 7:21 PM, Frank H. Ellenberger <
> frank.h.ellenber...@gmail.com> wrote:
> >
> > Bob, I think we should put the discussion from
> > https://bugs.gnucash.org/show_bug.cgi?id=797232 -
> > dialog-ab.glade was written for gtk 2.16
> > on the list.
> >
> > Glade did not tell me, stock items, which I used in some recent
> > commits, are deprecated since version 3.10. [gtk_button_new_from_stock
> > () in 1]
> > They included:
> > 1. a label with mnemonic,
> > 2. for which the translation was already done in the gtk domain,
> > 3.unique icons were associated.
> >
> > The questions now:
> > 1. Does anybody know the background of this decision? I thought it was
> > very useful to have standard icons associated with standard actions,
> > also for handicapped people like me, while I do test runs with foreign
> > translations.
> >
> > 2. What is there some general replacement strategy or does it get
> > simply dropped?
> >
> > 3. Do we want to
> > a) drop the icons from the buttons as you did recently or
> > b) should we use gtk_button_new_from_icon_name () [1] with names
> > according [3] so they get choosen from [4]
> > c) in the long term look to replace GTK?
>
>
> Frank,
>
> The stock items were deprecated to improve theming, particularly with CSS
> theming. The discussion about it begins at
> https://mail.gnome.org/archives/gtk-devel-list/2013-July/msg0.html.
>
> How to create the button depends on what you want to show. IIUC the Gnome
> design team thinks that buttons should either have icons or labels but not
> both. If you want both you must create it with
> gtk_button_new_from_icon_name(), set the label with gtk_button_set_label(),
> and set the "always-show-image" property to TRUE.
>
> I don't know how to ensure that labels are translated in gtk.mo instead of
> gnucash.mo other than to search gtk.pot for msgids. For gtk3 the stock-item
> strings will continue to be translated, and some of them will probably live
> on in future versions.
>
> We decided some time ago that we don't want to keep Gtk for the long term,
> but there's other work with a higher priority so nothing has been done
> about it.
>
> Regards,
> John Ralls
>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Release Schedule

[Robert Fewell]

I'm OK with the first option but suggest instead of December with all the
diversions for Christmas it be the end of January.
Has it been decided on a minimum Gtk version for master, there are probably
some conditional version statements that can be removed and some CSS that I
want to change/rename.

Regards,
   Bob

On Fri, 24 May 2019 at 12:37, Christopher Lam 
wrote:

> Oh and also:
>
> I'll wish to transition *all* html-acct-table based reports to force them
> to do subtotals properly.
>
> There are currently 9 different combinations for subtotals while displaying
> accounts, depending on the Display settings "parent account balances" and
> "parent account subtotals"; the 'canonically-tabbed' option should be
> deprecated; and either parent account include children-account subtotals,
> or parent subtotals displayed after their children group. i.e. 9
> combinations reduced to 2 options.
>
> I'll hope this can be achieved for 4.0.
>
>
> On Fri, 24 May 2019 at 03: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).
> >
> > On Thu, 23 May 2019 at 19:12, John Ralls  wrote:
> >
> >> Back in the run-up to releasing GnuCash 3.0 when we adopted the
> two-digit
> >> release numbering we also said that we wanted to accelerate the major
> >> release tempo to 2-3 years instead of the 4 years that had gone between
> the
> >> previous several major releases.
> >>
> >> Well, it's two years later. We've added almost 1500 commits, but they've
> >> all been to the maint branch. There are a few low-effort changes on the
> >> table that would fit better into a new stable series, including more
> report
> >> system updates from Chris Lam and the report menu rearrangement Geert
> >> surfaced last week.
> >>
> >> The first alternative is to finish those up, merge them onto master, and
> >> release 4.0 in December as we optimistically planned 2 years ago. Along
> >> with that change we'd bump the C++ standard requirement to 14 so that we
> >> can use initializer lists correctly. That will require GCC 5.0 or Clang
> >> 3.4, which would raise the baseline distros to Ubuntu 16.04, Debian 9,
> Mint
> >> 18, and Fedora 25. RHEL/Centos users would need to install devtoolset-7
> or
> >> devtoolset-8. OpenSuSE users would need to install one of the GCC
> upgrade
> >> packages. MacOS minimum would bump to 10.10 (Yosemite). MSYS2's
> toolchain
> >> is consistently bleeding-edge so Windows builds wouldn't be affected.
> >>
> >> The second alternative is to revert to the 4-year major release tempo,
> >> continuing the current 3.x stable series until the end of 2021 and
> hoping
> >> that we've made sufficient progress on the major goals by then.
> >>
> >> The third alternative is to not have a fixed major release schedule at
> >> all and instead to wait until the goals set out in
> >> https://wiki.gnucash.org/wiki/Release_Schedule#Goals_for_4.0 are
> >> completed.
> >>
> >> Geert and I, having discussed this on IRC, are inclined toward the first
> >> alternative because it allows us to update the minimum versions of
> several
> >> dependencies.
> >>
> >> Regards,
> >> John Ralls
> >>
> >> ___
> >> gnucash-devel mailing list
> >> gnucash-devel@gnucash.org
> >> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> >>
> >
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Windows build

[Robert Fewell]

Derek,
Thanks for that and regarding the sorting I never noticed that, just tried
it and will save the book mark in that order.
Bob

On Mon, 13 May 2019 at 11:51, Derek Atkins  wrote:

> HI,
>
> On Mon, May 13, 2019 6:33 am, Robert Fewell wrote:
> > Hi guys, looks like the windows build has been created in fro the last
> few
> > days, the last one being 10/05/2019 and looking at the logs it is failing
> > with a permission error. Could some one have a look and give it a kick.
>
> If John or Geert don't get to this I will see if I can later this week.
>
> > Some thing I have noticed is the exe has increased in size again on the
> > 28/04/2018, from 174M to 182M for the last successful build.
>
> Perhaps there was a new language added?  Either that or some other
> dependencies increased in size.  I haven't been following along closely
> enough.
>
> > Also could the log files be pruned and may be some of the daily builds
> not
> > sure how many.
>
> I usually prune them every ~6 months or so..  You do know you can sort by
> most-recent first, right?
>
> > Regards,
> >
> >   Bob
>
> -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

[GNC-dev] Windows build

[Robert Fewell]

Hi guys, looks like the windows build has been created in fro the last few
days, the last one being 10/05/2019 and looking at the logs it is failing
with a permission error. Could some one have a look and give it a kick.

Some thing I have noticed is the exe has increased in size again on the
28/04/2018, from 174M to 182M for the last successful build.

Also could the log files be pruned and may be some of the daily builds not
sure how many.

Regards,

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

[GNC-dev] Windows build

[Robert Fewell]

Hi,
Does the Windows build server run the tests, I was going to add a unc file
path uri to test-gnc-uri-utils.c
Can I run them locally, if yes how ?

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

Re: [GNC-dev] Windows build server

[Robert Fewell]

Thank you John, could you do one more but just with -Q, sorry I should of
tested the command before I asked, looks like -e restricts the list to only
ones explicitly installed.

Regards,
   Bob

On Tue, 26 Mar 2019 at 21:37, John Ralls 
wrote:

> Here you go. mingw64-config.txt is with q, mingw64-config-ext.txt without
> it.
>
> Regards,
> John Ralls
>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Windows build server

[Robert Fewell]

I am still having trouble and I think it is down to my build system being
to up to date and maybe incompatible library versions, looking at a the
files from a nightly build, they seem to be older so I am wondering if that
is my problem.

Is it possible that some one with console access run the following command
that lists all the installed packages to a text file.

pacman -Qqe > pkglist.txt

I can then use this to install the same versions, it may be worth while
adding it to the build script for future reference.

Regards,
   Bob

On Sun, 24 Mar 2019 at 17:49, John Ralls 
wrote:

> Bob,
>
> When it can't find libtest-core-guile.so itself it says "the specified
> *file* could not be found" (my emphasis); "the specified module could not
> be found" means that the linker couldn't find one of the dependencies of
> libtest-core-guile.so. That includes the whole Gtk stack, libgncmod-engine,
> libgnc-core-utils, several Boost libraries, libguile, libgc, and libintl.
>
> Did you remember to start a jhbuild shell to set up the build environment?
>   cd /c/gcdev64/src/gnucash-on-windows.git
>   TARGET=gnucash-maint jhbuild -f jhbuildrc shell
>   cd $PREFIX/../build/gnucash-git
>
> It sometimes helps to uninstall; if you've cleared the build directory so
> install_manifest.txt is gone it's usually sufficient to
>  rm -r $PREFIX/lib/gnucash
>  rm $PREFIX/lib/libgnc*
>
> Regards,
> John Ralls
>
>
> > On Mar 24, 2019, at 9:30 AM, Robert Fewell <14ubo...@gmail.com> wrote:
> >
> > Thanks John,
> >
> > Yesterday I did manage to build and then install a working version but
> found my changes for 'transaction associations' needed some work, change
> the source file and tried to rebuild and now it wont.
> > I do not know why it wont but it so frustrating
> > Cleared my build and install directory and now getting...
> >
> > [ 30%] Generating
> ../../lib/gnucash/scm/ccache/2.0/gnucash/unittest-support.go
> > Backtrace:
> > In ice-9/eval.scm:
> >  432: 19 [eval # #]
> > In C:/gcdev64/gnucash/maint/inst/bin/guild:
> >   72: 18 [main ("C:/gcdev64/gnucash/maint/inst/bin/guild" "compile" "-o"
> ...)]
> > In srfi/srfi-1.scm:
> >  616: 17 [for-each # (file)> #]
> > In scripts/compile.scm:
> >  190: 16 [#
> "C:/gcdev64/gnucash/maint/src/gnucash-git/common/test-core/unittest-support.scm"]
> > In system/base/target.scm:
> >   59: 15 [with-target "i686-w64-mingw32" ...]
> > In system/base/compile.scm:
> >  152: 14 [compile-file
> "C:/gcdev64/gnucash/maint/src/gnucash-git/common/test-core/unittest-support.scm"
> ...]
> >   43: 13 [call-once # ()>]
> > In ice-9/boot-9.scm:
> >  174: 12 [with-throw-handler #t ...]
> > In system/base/compile.scm:
> >   59: 11 [#]
> >  155: 10 [#
> #]
> >  218: 9 [read-and-compile # #:from ...]
> >  234: 8 [lp (#) # 2d40f50> ...]
> >  182: 7 [lp (#) (eval-when # #)
> ...]
> > In ice-9/boot-9.scm:
> > 2412: 6 [save-module-excursion # language/scheme/compile-tree-il.scm:29:3 ()>]
> > In language/scheme/compile-tree-il.scm:
> >   31: 5 [# ()>]
> > In ice-9/psyntax.scm:
> > 1107: 4 [expand-top-sequence ((eval-when # #)) () ((top)) ...]
> >  990: 3 [scan ((eval-when # #)) () ((top)) ...]
> >  279: 2 [scan (#) () (#) ...]
> > In unknown file:
> >?: 1 [load-extension "libtest-core-guile"
> "scm_init_unittest_support_module"]
> > In ice-9/boot-9.scm:
> >  109: 0 [# args)> misc-error ...]
> >
> > ice-9/boot-9.scm:109:20: In procedure # ice-9/boot-9.scm:100:6 (thrown-k . args)>:
> > ice-9/boot-9.scm:109:20: In procedure dynamic-link: file:
> "libtest-core-guile", message: "The specified module could not be found."
> > make[2]: ***
> [common/test-core/CMakeFiles/scm-test-core.dir/build.make:62:
> lib/gnucash/scm/ccache/2.0/gnucash/unittest-support.go] Error 1
> > make[1]: *** [CMakeFiles/Makefile2:2182:
> common/test-core/CMakeFiles/scm-test-core.dir/all] Error 2
> > make: *** [Makefile:163: all] Error 2
> > *** Error during phase build of gnucash-git: ## Error running
> make -j 1  *** [13/14]
> >
> > Is it looking for the libtest-core-guile.dll, that is there and looked
> at it and has  "scm_init_unittest_support_module" is there. Tried copying
> to the inst/bin folder but that did not help.
> >
> > Regards,
> >Bob
> >
> >
> >
> >
> >
> > On Sat, 23 Mar 2019 at 02:59, John Ralls 
> wrote:
> >
> >
> > > On Mar 22, 2019, at 2:12 PM, Robert Fewell 

Re: [GNC-dev] Windows build server

[Robert Fewell]

Thanks John,

Yesterday I did manage to build and then install a working version but
found my changes for 'transaction associations' needed some work, change
the source file and tried to rebuild and now it wont.
I do not know why it wont but it so frustrating
Cleared my build and install directory and now getting...

[ 30%] Generating
../../lib/gnucash/scm/ccache/2.0/gnucash/unittest-support.go
Backtrace:
In ice-9/eval.scm:
 432: 19 [eval # #]
In C:/gcdev64/gnucash/maint/inst/bin/guild:
  72: 18 [main ("C:/gcdev64/gnucash/maint/inst/bin/guild" "compile" "-o"
...)]
In srfi/srfi-1.scm:
 616: 17 [for-each # #]
In scripts/compile.scm:
 190: 16 [#
"C:/gcdev64/gnucash/maint/src/gnucash-git/common/test-core/unittest-support.scm"]
In system/base/target.scm:
  59: 15 [with-target "i686-w64-mingw32" ...]
In system/base/compile.scm:
 152: 14 [compile-file
"C:/gcdev64/gnucash/maint/src/gnucash-git/common/test-core/unittest-support.scm"
...]
  43: 13 [call-once #]
In ice-9/boot-9.scm:
 174: 12 [with-throw-handler #t ...]
In system/base/compile.scm:
  59: 11 [#]
 155: 10 [#
#]
 218: 9 [read-and-compile # #:from ...]
 234: 8 [lp (#) #
...]
 182: 7 [lp (#) (eval-when # #) ...]
In ice-9/boot-9.scm:
2412: 6 [save-module-excursion #]
In language/scheme/compile-tree-il.scm:
  31: 5 [#]
In ice-9/psyntax.scm:
1107: 4 [expand-top-sequence ((eval-when # #)) () ((top)) ...]
 990: 3 [scan ((eval-when # #)) () ((top)) ...]
 279: 2 [scan (#) () (#) ...]
In unknown file:
   ?: 1 [load-extension "libtest-core-guile"
"scm_init_unittest_support_module"]
In ice-9/boot-9.scm:
 109: 0 [#
misc-error ...]

ice-9/boot-9.scm:109:20: In procedure #:
ice-9/boot-9.scm:109:20: In procedure dynamic-link: file:
"libtest-core-guile", message: "The specified module could not be found."
make[2]: *** [common/test-core/CMakeFiles/scm-test-core.dir/build.make:62:
lib/gnucash/scm/ccache/2.0/gnucash/unittest-support.go] Error 1
make[1]: *** [CMakeFiles/Makefile2:2182:
common/test-core/CMakeFiles/scm-test-core.dir/all] Error 2
make: *** [Makefile:163: all] Error 2
*** Error during phase build of gnucash-git: ## Error running make
-j 1  *** [13/14]

Is it looking for the libtest-core-guile.dll, that is there and looked at
it and has  "scm_init_unittest_support_module" is there. Tried copying to
the inst/bin folder but that did not help.

Regards,
   Bob





On Sat, 23 Mar 2019 at 02:59, John Ralls 
wrote:

>
>
> > On Mar 22, 2019, at 2:12 PM, Robert Fewell <14ubo...@gmail.com> wrote:
> >
> > Hi,
> >
> > Just wondering if any body has setup a windows build environment
> recently,
> > I mistakenly ran setup-mingw64.ps1 which updated my setup, a good 100
> plus
> > packages were updated and now I can not run a build from scratch, builds
> I
> > think 4 package dependencies and fails on xmlsec. Will investigate
> further
> > tomorrow or maybe try and not build aqbanking as I think it a dependency
> of
> > that.
> >
> > Does the build server update its environment or is just the dependencies
> ?
>
> Bob,
>
> It updates everything except the dozen or so dependencies that are built
> from source in gnucash.modules.
>
> Xmlsec has build products committed in the repo so just building creates a
> change that git can see. The result is that when jhbuild tries to see if
> the tree has updates it fails with "unable to switch a dirty tree". Just
> pick "2 - ignore error and continue to configure".
>
> Regards,
> John Ralls
>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

[GNC-dev] Windows build server

[Robert Fewell]

Hi,

Just wondering if any body has setup a windows build environment recently,
I mistakenly ran setup-mingw64.ps1 which updated my setup, a good 100 plus
packages were updated and now I can not run a build from scratch, builds I
think 4 package dependencies and fails on xmlsec. Will investigate further
tomorrow or maybe try and not build aqbanking as I think it a dependency of
that.

Does the build server update its environment or is just the dependencies ?

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

[GNC-dev] Bugs Web site

[Robert Fewell]

Hi,

Just a couple of observations, there seems to be a missing icon/image to
the left of 'New' in the banner. Also I seem to recall a page that had
stat's on it like number of bugs against release levels, bug types, open or
closed which I can not find. Any body know where it is and how to get there
?

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

[GNC-dev] Convert Imap to Flat

[Robert Fewell]

Hi,
I was poking around with the CSV importer and I noticed the following, this
may also be an issue with other importers on first use after creating a new
file...
With a new empty xml file, I used a one line transaction csv file with
appropriate settings and the 'Account' set to 'Assets:Current
Assets:Checking Account' and observed the following when I got to the match
page...

With the 'Checking Account' register open it would partly show the imported
transactions, (this can be fixed by suspending GUI changes which I was
going to propose in a PR) and the register would reload seven times.
This reloading is caused by the triggering of the
'imap_convert_bayes_to_flat' function and as it is a new file you would not
expect it to do any thing but it does. Adding a few print statements I get
the following...

matchmap_find_destination
imap_convert_bayes_to_flat
 convert_imap_account_bayes_to_flat 'Assets'
  gnc_split_register_load called for account 'Assets:Current
Assets:Checking Account' with list of 1
 convert_imap_account_bayes_to_flat 'Current Assets'
  gnc_split_register_load called for account 'Assets:Current
Assets:Checking Account' with list of 1
 convert_imap_account_bayes_to_flat 'Checking Account'
  gnc_split_register_load called for account 'Assets:Current
Assets:Checking Account' with list of 1
 convert_imap_account_bayes_to_flat 'Liabilities'
  gnc_split_register_load called for account 'Assets:Current
Assets:Checking Account' with list of 1
 convert_imap_account_bayes_to_flat 'Income'
  gnc_split_register_load called for account 'Assets:Current
Assets:Checking Account' with list of 1
 convert_imap_account_bayes_to_flat 'Expenses'
  gnc_split_register_load called for account 'Assets:Current
Assets:Checking Account' with list of 1
 convert_imap_account_bayes_to_flat 'Equity'
  gnc_split_register_load called for account 'Assets:Current
Assets:Checking Account' with list of 1

As you can see, seven accounts get updated forcing the register reload
seven times, (not sure why those other accounts force a reload either), and
this gets even worse if this first import is 100 transactions which would
equate to 700 reloads. I have not worked out why all these accounts are
updated or why after the first pass the converted flag is not set/noticed
there by eliminating the convert for the rest of the transactions, it only
seems to be noticed on subsequent imports.

You also get this behaviour if you start the 'Import Map Dialogue' which
may be the source of a report about that dialogue freezing but that needs
more investigating.

Any idea why these accounts are updated and why it runs on every import
transaction row ?

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

Re: [GNC-dev] Windows Build not working

[Robert Fewell]

OK, I have found the register date problem which is down to commit Make
selection caching uniform across gnucash-sheet functions.
<https://github.com/Gnucash/gnucash/commit/bfa6cd52e829cb50d8ad401528b7ca7daae0b26f>
more specificity if I comment out the addition of lines 402 and 403 the
date cursor navigation by using the arrow keys works.

Regards,
Bob


On Sat, 15 Sep 2018 at 23:56, John Ralls  wrote:

>
>
> > On Sep 15, 2018, at 9:47 AM, Robert Fewell <14ubo...@gmail.com> wrote:
> >
> > Hi,
> > Came across this today when trying to find a build with a working
> register
> > date edit to see if I can find which commit broke it.
> > For information in a register, click in the date field which removes the
> > selection but you can not move the cursor with the arrow keys.
> >
> > Looking at the nightlies...
> > 3.2-191, register date works
> > 3.2-258, register date does not work
> > 3.2-263 register date still does not work and obviously starts
> > 3.2-265 installs but will not start along with all later ones.
> >
> > I may have time tomorrow to investigate, not sure at the moment.
> >
> > Also is it possible to give more room for the file name on the website
> for
> > the directory, see image.
>
> Only Derek can change the display of the builds listing.
>
> I think I know what's wrong with the installers after Monday, but I blew
> up my Windows build environment and it's taking a while to rebuild it. I
> should have a fix for that by tomorrow.
>
> Regards,
> John Ralls
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Bug 796725

[Robert Fewell]

So really in the FIND dialogue the Date find option only needs two or three
possibilities

"is before or on" using gnc_dmy2time64_end() to change entry date to
23:59:59
"is on" with the QofDateMatch set to QOF_DATE_MATCH_DAY ( this changes the
compared dates with 'time64CanonicalDayTime' )
 "is on or after" using gnc_dmy2time64() to change entry date to 00:00:00

Regards,
Bob

On 14 August 2018 at 16:02, John Ralls  wrote:

>
>
> > On Aug 14, 2018, at 6:55 AM, Robert Fewell <14ubo...@gmail.com> wrote:
> >
> > I have been looking at this one and know what is wrong but not sure if my
> > fix is valid.
> >
> > It is to do with searching for transactions by posted date and returning
> > the wrong number of transactions for the required filter option.
> >
> > When the date entered in the GtkEntry, gnc_date_edit_get_date returns the
> > time64 but at 12:00:00 am for that day.
> >
> > Looking at the transaction posted date in my Xml file they are at
> > '2018-01-01 10:59:00 +'
> >
> > I can fix this in search-date.c by changing the two occurrences of
> > gnc_date_edit_get_date to some thing like this...
> >
> >time64 temp = gnc_date_edit_get_date (GNC_DATE_EDIT
> (priv->entry));
> >struct tm * temp_tm = gnc_localtime ();
> >
> >fi->tt = gnc_dmy2time64_neutral (temp_tm->tm_mday, temp_tm->tm_mon
> > + 1, temp_tm->tm_year + 1900);
> >gnc_tm_free (temp_tm);
> >
> > but this would affect all date searches in transactions, invoices and
> bills.
> >
> > Should all dates be at this neutral time so it does not matter ?
>
> Bob,
>
> I think all search dates should be “open” intervals, meaning that if you
> search from 1 - 31 January, the result set should include transactions on
> both 1 January and 31 January as well as everything in between. The best
> way to accomplish this is to use gnc_dmy2time64() for the beginning of the
> search and gnc_dmy2time64_end() for the end of the search: The former
> returns 00:00:00 on the day and the latter to 23:59:59.
>
> Transaction *posted* dates created with 2.6.12 or so and later are set to
> 10:59:00 UTC using gnc_dmy2time64_neutral() unless the user is in one of
> the “edge” timezones, -12, +13, or +14, in which cases the time is offset
> to keep the time in the same local day. Other dates, e.g. date_entered and
> date_reconciled, are set to the actual time that the action occurred,
> usually using gnc_time().
>
> Regards,
> John Ralls
>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

[GNC-dev] Bug 796725

[Robert Fewell]

I have been looking at this one and know what is wrong but not sure if my
fix is valid.

It is to do with searching for transactions by posted date and returning
the wrong number of transactions for the required filter option.

When the date entered in the GtkEntry, gnc_date_edit_get_date returns the
time64 but at 12:00:00 am for that day.

Looking at the transaction posted date in my Xml file they are at
'2018-01-01 10:59:00 +'

I can fix this in search-date.c by changing the two occurrences of
gnc_date_edit_get_date to some thing like this...

time64 temp = gnc_date_edit_get_date (GNC_DATE_EDIT (priv->entry));
struct tm * temp_tm = gnc_localtime ();

fi->tt = gnc_dmy2time64_neutral (temp_tm->tm_mday, temp_tm->tm_mon
+ 1, temp_tm->tm_year + 1900);
gnc_tm_free (temp_tm);

but this would affect all date searches in transactions, invoices and bills.

Should all dates be at this neutral time so it does not matter ?

Regards,

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

Re: [GNC-dev] Bug 796778 Feature Request Multiple Selection in Import- matcher

[Robert Fewell]

David,
I may be missing some thing but you should be able to select lines by
control, shift or by individual.
I think what you are after can be shown in the reconcile view, multiple
lines can be selected and then right moused to a menu.

Anyway, enjoy your holiday...

Bob

On 12 August 2018 at 11:47, David Cousens  wrote:

> Bob,
>
> From what I've read in the GtkTreeView documentation, the rubber-banding
> mode only seems to support selection by dragging the mouse so one is only
> able to select consecutive rows, not a group of single non-contiguous rows.
> I could of course be wrong on that.  It obviously sets the
> GTK_SELECTION_MULTIPLE mode of a GtkTreeSelection along with the drag
> detection. I find the Gtk documentation extremely terse and unhelpful in
> some areas. I did find a reference to the row-activated signal being
> emitted
> when"when a non-editable row is selected and one of the keys: Space,
> Shift+Space, Return or Enter is pressed." which would permit non-mouse row
> activation to initiate the selection of a transfer account
>
> I also found a Python gtk discussion to the effect that GtkTreeView's
> slection capabilities were limited pretty well to the drag over to select
> and from that found a hint on how to do Ctrl click event detection using
> the
> GdkEventButton using the event-> state and also how to detect the right
> click event.  When I included that in the import-main-matcher.c the
> row-activated signal stopped working. I am assuming here that the python
> GTK
> implementation is an exact parallel of the C++ implementation. I would
> expect it to be pretty similar and possibly just the C++ code in Python
> wrappers.
>
> I may have to setup a dummy program implementing  a TreeView and just play
> with how things work with rubber banding and multiple selection until I
> understand it better and the interaction between the rubber-banding and
> multiple selection mode. Usually the best way of understanding incomplete
> or
> unclear documentation.
>
> I'm away for a few days on holidays so I'll try and tackle it then if my
> wife lets me get an opportunity. Otherwise it will be when I return.
>
> Cheers
>
> David
>
>
>
> -
> David Cousens
> --
> Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Bug 796778 Feature Request Multiple Selection in Import- matcher

[Robert Fewell]

David,
Why do you not as a start change the tree view selection from single to
multiple, you will see that in the dialog-import.glade file, that way you
can select multiple lines.
You will need to alter the selection call back as you need different
functions that use a list of selected rows.

Bob

On 12 August 2018 at 08:22, David Cousens  wrote:

> Hi,
>
> I raised the above bug as a feature request then I decided to try and
> tackle
> it myself. My concept was to have a popup menu activated by a right click
> in
> the matcher window area from which the user could enable and disable
> multiple selection of transactions in the window and elect to assign a
> transfer account to a selection of multiple rows. My reason for doing this
> is I often have within an imported set of transactions, sets of multiple
> transactions which have the same transfer account and processing an import
> would be speeded up if these could be selected as a group and the the
> transfer account selected and applied to the group.
>
> I now have a lot of the basic code in place to process a selection and to
> create and view a popup menu, activate and disable multiple selection and
> process a group of selected rows, partially tested but I have struck a
> problem in that the GtkTreeView does not implement Ctrl-click selection in
> the API and i am going to have to provide that myself.
>
> As far as I can see from the code in import-main-matcher.c GnuCash does not
> seem to implement anything other than a mouse double click to select a
> single row which is processed by the callback initiated by the TreeView
> "row-activated" event. I.e. there is no selection by pressing "Enter" while
> the focus is on a given row.
>
> My plan is to detect Ctrl-Left click (implemented) and use that to add rows
> to the selection and then initiate the processing of the selection using
> the
> right click (implemented) popup menu. To do this, I have to detect a
> GDK_BUTTON_PRESS event and then use the event->state to determine whether
> Ctrl is pressed simultaneously (implemented) or whether the third mouse
> button has been clicked (implemented) . This however appears to short
> circuit the "row-activated" event detection by the GtkTreeView as it
> detects
> the sequence:
> GDK_BUTTON_PRESS
> GDK_BUTTON_RELEASE
> GDK_BUTTON_PRESS
> GDK_BUTTON_RELEASE if it occurs within 0.25 s
> so I am going to have to provide my own double click detection within the
> callback I use to process the initial button press.
>
> My question is is this. Is what I have outlined above likely to interfere
> with any non mouse based selection of transactions for applying a transfer
> account and does the approach seem reasonable? I can't see that occurring
> in
> the code for the main matcher, but I am a relative novice in using Gdk and
> Gtk so I could be easily missing something. E.g. Up, Down keys to shift the
> row focus and Enter to select for example.
>
> David Cousens.
>
>
>
> -
> David Cousens
> --
> Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[Robert Fewell]

Just wondering the following...

Are the imported transactions related to the open registers ?
If you created a new register with a blank transaction, do you see the same
delay, just thinking less to draw ?
Not sure if you have open aqbanking windows/dialogs open that are covering
the register, if you have space can they be moved so there is nothing
covering the main Gnucash window, does this make a differnce.
If you do have windows/dialogs covering, what type are they, proper windows
or dialogs with transient parents, might make a difference.

Bob

On 24 June 2018 at 22:00, John Ralls  wrote:

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

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

[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

[GNC-dev] Transaction / Split Action List

[Robert Fewell]

There have been some enquiries about customising this list so I thought I
would propose a possible solution that I may work.
At the moment the static lists are based on register type in
split-register.c and it looks to me there are two possible options.

1, Dynamicaly add to these lists based on past entries, probably there
would be an overhead do so.
2, Allow the lists to be customised in some sort of config file.

I think 2, is the better option and in the source it mentions about using a
config file so I was thinking along those lines to basicly do...

Create a new user key file probably in .config/gnucash called
user-config.gcm

On gnucash load, test for the file and if not present create it with the
default list content of split-register.c, I assume this would populate the
file with the translated entries.

A section name would then have list keys for the entries, something like...

[Action List]
cash_register=Increase;Decrease;Buy;Sell
asset_register=Buy;Sell;Fee

Change gnc_split_register_config_action to read the key file content to
populate the appropriate list.

A missing register key would get a list of one entry with "Empty".

This would allow the users, once the file is created to add or remove
entries as required.

Any thoughts, wrong approach ?

This would probably be a master project.

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

[GNC-dev] Widget naming and css

[Robert Fewell]

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.

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

Re: [GNC-dev] Register text selection

[Robert Fewell]

Sorry I did not explain the third option very well, have a transaction
between say "Checking Account" and "Cash in Wallet" with both registers
open.
Position the cursor on a transaction somewhere in the "Checking Account",
go back to the "Cash in Wallet" and edit a transaction between the two and
commit it.
If you go back to the "Checking Account" you will find the text highlighted
where the cursor was.

I had a look at the "Edit Account Dialog" and the "Edit Customer Dialog",
both do not preselect the first entry when opened and the cursor is at the
beginning of that entry. When you tab to the next entry it is preselected
but with the cursor hidden. If you type a letter, the cursor becomes
visible as usual or if you left arrow it shows at the start or right arrow
it shows at the end of the text.

I think I will close my PR and start again if required after you have made
your changes.

Bob

On 21 May 2018 at 14:14, Geert Janssens <geert.gnuc...@kobaltwit.be> 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.
> >
> > If you navigate by keyboard, the next field text is preselected and the
> > cursor set to the end of text.
> > If you navigate by mouse, the text is not selected and the cursor is the
> > mouse position.
> > If you update a transaction in one register and have the other
> > corresponding register open, the text where the cursor is will get
> > selected. (I think this is an easy fix).
> >
> > I am just wondering if we should be doing this preselected text at all ?
> >
> As far as I can tell the first two (text navigation hightlights the full
> text,
> mouse navigation sets the text cursor) are at least common behavior, if
> not
> default. Find any dialog with more than one text field and try what
> happens if
> you tab from one field to the next or click in random fields. I would find
> it
> disturbing if the register would behave differently.
>
> I don't understand exactly what you mean with the third behavior.
>
> > Some might say it is a good indication of where the focus is, only with
> > keyboard navigation, but one could simply add something like this to your
> > css file which would also work for mouse navigation...
> >
> > cursor entry {
> >   background-color: pink;
> > }
> >
> > So just asking the question.
>
> It's not just a matter of visual indication. It's also about ergonomics.
> Text
> and mouse navigation have different dynamics and this is reflected in the
> way
> text is selected or not when entering a text field.
>
> For your information I plan to work in this area of the code soon to fix
> input
> methods. I intend to drop all code related to text manipulation from the
> sheet
> and make the gtk entry responsible for it instead. Perhaps it's best you
> hold
> off other changes related to text entry until that's done to avoid doing
> double work.
>
> Geert
>
>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

[GNC-dev] Register text selection

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

If you navigate by keyboard, the next field text is preselected and the
cursor set to the end of text.
If you navigate by mouse, the text is not selected and the cursor is the
mouse position.
If you update a transaction in one register and have the other
corresponding register open, the text where the cursor is will get
selected. (I think this is an easy fix).

I am just wondering if we should be doing this preselected text at all ?

Some might say it is a good indication of where the focus is, only with
keyboard navigation, but one could simply add something like this to your
css file which would also work for mouse navigation...

cursor entry {
  background-color: pink;
}

So just asking the question.

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

Re: [GNC-dev] Windows Build

[Robert Fewell]

Thank you, that makes it clearer now.
Bob

On 17 May 2018 at 18:22, John Ralls <jra...@ceridwen.us> wrote:

>
>
> > On May 17, 2018, at 9:49 AM, Geert Janssens <geert.gnuc...@kobaltwit.be>
> wrote:
> >
> > Op donderdag 17 mei 2018 18:11:49 CEST schreef Robert Fewell:
> >> Trying to answer my own question...
> >>
> >> I assume the file size difference is because the nightly have debug
> >> information built in.
> >>
> > Indeed.
> >
> >> I know the last bit is the commit it is based on, can not see why they
> >> start with 'g' but can find 5f5ad968f but not d2ef5fd0f
> >>
> > The 'g' comes by default from git's "describe" command and refers to
> (g)it
> > commit.
> >
> > Perhaps d2ef5fd0f is not found because John started the build from a
> commit
> > that never got pushed ? Can't find it either in my git repo.
> >
>
> It exists only in the reflog on the machine that built the tarballs: I
> re-made the tarballs (that's why they're 3.1-1) after making an
> inconsequential change to CMakeLists.txt, to wit:
> --- a/CMakeLists.txt
> +++ b/CMakeLists.txt
> @@ -14,11 +14,11 @@ ENABLE_TESTING()
>  SET (GNUCASH_MAJOR_VERSION 3)
>  SET (GNUCASH_MINOR_VERSION 1)
>  SET (VERSION "${GNUCASH_MAJOR_VERSION}.${GNUCASH_MINOR_VERSION}")
> -SET (GNUCASH_LATEST_STABLE_SERIES 3.1)
> +SET (GNUCASH_LATEST_STABLE_SERIES 3.x)
>
>  SET (PACKAGE gnucash)
>  SET (PACKAGE_NAME GnuCash)
> -SET (PACKAGE_VERSION 3.0)
> +SET (PACKAGE_VERSION 3.1)
>  SET (PACKAGE_BUGREPORT gnucash-devel@gnucash.org)
>  SET (PACKAGE_TARNAME ${PACKAGE})
>  SET (PACKAGE_STRING "${PACKAGE_NAME} ${PACKAGE_VERSION}")
>
> Neither variable is actually used for anything, so a better change would
> probably be to simply remove them.
>
> The difference between 3.1-2 and 3.1-3 is that the latter is built with
> the latest release of libofx (0.9.13 instead of 0.9.10) to see if it fixes
> Chris Good's OFX import problem (https://bugzilla.gnome.org/
> show_bug.cgi?id=795347). It appears instead to have caused other
> problems. The "official" current release on Windows is 3.1-2.
>
> Regards,
> John Ralls
>
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

[GNC-dev] Windows Build

[Robert Fewell]

Trying to answer my own question...

I assume the file size difference is because the nightly have debug
information built in.

I know the last bit is the commit it is based on, can not see why they
start with 'g' but can find 5f5ad968f but not d2ef5fd0f

Regards,

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

[GNC-dev] Windows Builds

[Robert Fewell]

I was looking at Bug 796083 and after some testing on Linux realised that
my reconcile sort fix may of fixed this.

Booted into Windows 10 and downloaded the nightly build
gnucash-3.1-2018-05-16-git-3.1-59-g5f5ad968f+.setup.exe and indeed it was
fixed. Just to make sure I also downloaded the latest release
build gnucash-3.1-3.setup.exe but noticed that the sort order of the
reconcile dialog was different, no default sort.

The nightly shows in the about box version Build ID: git 3.1-59-g5f5ad968f+
(2018-05-15) and is 97Meg
The release shows in the about box version Build ID: 3.0-118-gd2ef5fd0f+
(2018-04-28) and is 91Meg

Any ideas why ?

I was going to ask the reporter to try a later version, I think I will
specify the nightly, don't want another bug saying there is no default sort
order !!

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