Which doc directory

[Robert Fewell]

Hi,

I have two usr/share/doc directories related to Gnucash, they are...

/usr/share/doc/Gnucash with Changelogs... and HACKING,NEWS etc...
/use/share/doc/gnucash with abc.qif, web.qif etc...

I am not sure which is correct but the doc\CMakeLists,txt is pointing to
'doc/gnucash' while the main CMakeLists.txt is using CMAKE_INSTALL_DOCDIR.

Regards,

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

Windows build Unstable Fails

[Robert Fewell]

Hi,

I thought I would build the latest Windows unstable version to prove some
changes I was going to make but it failed as follows...

I ran setup-ming64-ps1 which updated the core system files as usual and
this completed OK. Probably my first mistake, should of kept the system
files at a known working level but I suppose someone building from scratch
would get the latest system files.

Tried to use the jhbuild command which I think updated some AqBanking
parts, and then started the Gnucash build. There were some references to
boost dependencies as I think that was updated and then a failure to find
Swig. Fixed that by applying the SwigPatch to new version of cmake-3.10 and
then it failed on one of the scheme files.

I think I had that sort of error before so I deleted the unstable folder
and started to build it all again but xmlsec fails to build with the
following error...

In file included from
C:/gcdev64/msys2/mingw32/i686-w64-mingw32/include/windows.h:95:0,
 from
C:/gcdev64/msys2/mingw32/include/libxslt/xsltlocale.h:43,
 from
C:/gcdev64/msys2/mingw32/include/libxslt/xsltInternals.h:24,
 from
C:/gcdev64/msys2/mingw32/include/libxslt/security.h:17,
 from
C:/gcdev64/gnucash/unstable/src/xmlsec-xmlsec-1_2_20/include/xmlsec/transforms.h:953,
 from
C:/gcdev64/gnucash/unstable/src/xmlsec-xmlsec-1_2_20/include/xmlsec/keyinfo.h:27,
 from
C:/gcdev64/gnucash/unstable/src/xmlsec-xmlsec-1_2_20/src/openssl/x509.c:33:
C:/gcdev64/gnucash/unstable/src/xmlsec-xmlsec-1_2_20/src/openssl/x509.c:94:66:
error: expected declaration specifiers or '...' before '(' token
 static xmlChar* xmlSecOpenSSLX509NameWrite
(X509_NAME* nm);
  ^
In file included from
C:/gcdev64/msys2/mingw32/i686-w64-mingw32/include/windows.h:95:0,
 from
C:/gcdev64/msys2/mingw32/include/libxslt/xsltlocale.h:43,
 from
C:/gcdev64/msys2/mingw32/include/libxslt/xsltInternals.h:24,
 from
C:/gcdev64/msys2/mingw32/include/libxslt/security.h:17,
 from
C:/gcdev64/gnucash/unstable/src/xmlsec-xmlsec-1_2_20/include/xmlsec/transforms.h:953,
 from
C:/gcdev64/gnucash/unstable/src/xmlsec-xmlsec-1_2_20/include/xmlsec/keyinfo.h:27,
 from
C:/gcdev64/gnucash/unstable/src/xmlsec-xmlsec-1_2_20/src/openssl/x509vfy.c:31:
C:/gcdev64/gnucash/unstable/src/xmlsec-xmlsec-1_2_20/src/openssl/x509vfy.c:100:8:
error: expected identifier or '(' before 'LPCSTR'
 static X509_NAME*   xmlSecOpenSSLX509NameRead
(xmlSecByte *str,
^

Spent some time poking around but my knowledge is lacking. I did try a
newer version of xmlsec but that fails in the same place and I also was
wondering if the i686-w64-mingw32 included header files had changed as they
are all new.

Can any one point me in the right direction and also the build server has
not done a successful run recently.

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

Re: Windows build Unstable Fails

[Robert Fewell]

A follow up, in i686-w64-mingw32/include/wincrypt.h there is a define for
X509_NAME, I temporarily renamed it and was able to build xmlsec and
continue to build GnuCash and create steup.exe for it which installed fine.
I have noticed a couple of issues with the register colours which I will
investigate and add fix to a PR.

Bob

On 4 February 2018 at 22:54, Robert Fewell <14ubo...@gmail.com> wrote:

> Hi,
>
> I thought I would build the latest Windows unstable version to prove some
> changes I was going to make but it failed as follows...
>
> I ran setup-ming64-ps1 which updated the core system files as usual and
> this completed OK. Probably my first mistake, should of kept the system
> files at a known working level but I suppose someone building from scratch
> would get the latest system files.
>
> Tried to use the jhbuild command which I think updated some AqBanking
> parts, and then started the Gnucash build. There were some references to
> boost dependencies as I think that was updated and then a failure to find
> Swig. Fixed that by applying the SwigPatch to new version of cmake-3.10 and
> then it failed on one of the scheme files.
>
> I think I had that sort of error before so I deleted the unstable folder
> and started to build it all again but xmlsec fails to build with the
> following error...
>
> In file included from C:/gcdev64/msys2/mingw32/i686-
> w64-mingw32/include/windows.h:95:0,
>  from C:/gcdev64/msys2/mingw32/
> include/libxslt/xsltlocale.h:43,
>  from C:/gcdev64/msys2/mingw32/
> include/libxslt/xsltInternals.h:24,
>  from C:/gcdev64/msys2/mingw32/
> include/libxslt/security.h:17,
>  from C:/gcdev64/gnucash/unstable/
> src/xmlsec-xmlsec-1_2_20/include/xmlsec/transforms.h:953,
>  from C:/gcdev64/gnucash/unstable/
> src/xmlsec-xmlsec-1_2_20/include/xmlsec/keyinfo.h:27,
>  from C:/gcdev64/gnucash/unstable/
> src/xmlsec-xmlsec-1_2_20/src/openssl/x509.c:33:
> C:/gcdev64/gnucash/unstable/src/xmlsec-xmlsec-1_2_20/src/openssl/x509.c:94:66:
> error: expected declaration specifiers or '...' before '(' token
>  static xmlChar* xmlSecOpenSSLX509NameWrite
> (X509_NAME* nm);
>   ^
> In file included from C:/gcdev64/msys2/mingw32/i686-
> w64-mingw32/include/windows.h:95:0,
>  from C:/gcdev64/msys2/mingw32/
> include/libxslt/xsltlocale.h:43,
>  from C:/gcdev64/msys2/mingw32/
> include/libxslt/xsltInternals.h:24,
>  from C:/gcdev64/msys2/mingw32/
> include/libxslt/security.h:17,
>  from C:/gcdev64/gnucash/unstable/
> src/xmlsec-xmlsec-1_2_20/include/xmlsec/transforms.h:953,
>  from C:/gcdev64/gnucash/unstable/
> src/xmlsec-xmlsec-1_2_20/include/xmlsec/keyinfo.h:27,
>  from C:/gcdev64/gnucash/unstable/
> src/xmlsec-xmlsec-1_2_20/src/openssl/x509vfy.c:31:
> C:/gcdev64/gnucash/unstable/src/xmlsec-xmlsec-1_2_20/src/openssl/x509vfy.c:100:8:
> error: expected identifier or '(' before 'LPCSTR'
>  static X509_NAME*   xmlSecOpenSSLX509NameRead
> (xmlSecByte *str,
> ^
>
> Spent some time poking around but my knowledge is lacking. I did try a
> newer version of xmlsec but that fails in the same place and I also was
> wondering if the i686-w64-mingw32 included header files had changed as they
> are all new.
>
> Can any one point me in the right direction and also the build server has
> not done a successful run recently.
>
> Regards,
>   Bob
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Preference question, issue or not?

[Robert Fewell]

Hi,

While I was working out why setting 'don't use gnucash color themes' was
being reset after every restart of Gnucash, I added a print statement to
gnc_prefs_get_bool which resulted in loads of output related to the
preference 'show-leaf-account-names'. Used the glib backtrace function to
work out what is calling this preference with the following results from
starting Gnucash for a short time and also moving a terminal window over a
register page...

376 calls to gnc_table_get_entry
248 calls to gnc_account_foreach_descendent

to

502 calls to gnc_get_account_name_for_register
to
502 calls to gnc_prefs_get_bool for show-leaf-account-names

My question is whether the register should hold the value and not keep
asking the preference system for it which I assume to mean gsettings
calling what ever back end is being used. It could be cached in some way or
with the fast PC's nowadays it is of no issue. Just asking before I spend
any more time on this.

Regards,

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

Terminal output at start up on Unstable

[Robert Fewell]

Hi,

Just thought I would mention that with the latest build I am seeing the
following in the terminal I start Gnucash from. I see there have been some
scheme changes so assuming it is related.

Unbound variable: gnc:ipmt
gnc:"ipmt" is not a scm procedure
Unbound variable: gnc:ppmt
gnc:"ppmt" is not a scm procedure
Unbound variable: gnc:pmt
gnc:"pmt" is not a scm procedure

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

Windows Build

[Robert Fewell]

Hi all,

Just tried to build the latest unstable for Windows but it fails with this
...

[ 76%] Generating gnucash.appdata.xml
C:/gcdev64/msys2/mingw32/bin/msgfmt.exe: cannot locate ITS rules for
C:/gcdev64/gnucash/unstable/src/gnucash-git/gnucash/gnome/
gnucash.appdata.xml.in
make[2]: *** [gnucash/gnome/CMakeFiles/gnucash-appdata.dir/build.make:61:
gnucash/gnome/gnucash.appdata.xml] Error 1
make[1]: *** [CMakeFiles/Makefile2:7919:
gnucash/gnome/CMakeFiles/gnucash-appdata.dir/all] Error 2
make: *** [Makefile:163: all] Error 2
*** Error during phase build of gnucash-git: ## Error running make
-j 1  *** [15/17]

Poked around but could not get it to work so thought I would see what the
build server logs yield but that has not worked since 25/02/2018 so no help
there.

So I downloaded that build but it fails with a missing
libboost_date_time-mt.dll so if the above is fixed it still might not work.

Regards,

  Bob

PS: Is it possible to clear out some of the old logs, maybe separate
sub-directories for each maint, master, unstable and docs. Also the maint
build is complaining about certificates and gives up.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows Build

[Robert Fewell]

Geert,

I have successfully built a 2.7.5 version locally with these changes...

Added the following to gnome/CMakeLists.txt at line 178 but I think this
may need to go in the jhbuildrc.in file
GETTEXTDATADIR=/mingw32/share/gettext

Added the following to gnucash-mingw64.iss at line 120
Source: "@MINGW_DIR@\bin\libboost_date_time-mt.dll"; DestDir: "{app}\bin";
Components: main

Whilst poking around yesterday I also created copies of
gettext/its/appdata.its/loc as it appeared to me the loc file was doing
file matching but the match pattern was *.appdata.xml and not *.
appdata.xml.in
but this may not be required, need to delete these extra files and try
another rebuild.

Have you run the *setup-ming64-ps1 *file, I did last month and as reported
made some changes which effected the build, namely I think cmake was
updated to 10 which meant the FindSWIG patch would not apply so maybe there
were other changes that affected gettext ?


I will have another go later, need to prepare car for MOT tomorrow.

Regards,
Bob



On 4 March 2018 at 16:40, Geert Janssens  wrote:

> Op zondag 4 maart 2018 16:19:46 CET schreef Robert Fewell:
> > Hi all,
> >
> > Just tried to build the latest unstable for Windows but it fails with
> this
> > ...
> >
> > [ 76%] Generating gnucash.appdata.xml
> > C:/gcdev64/msys2/mingw32/bin/msgfmt.exe: cannot locate ITS rules for
> > C:/gcdev64/gnucash/unstable/src/gnucash-git/gnucash/gnome/
> > gnucash.appdata.xml.in
> > make[2]: *** [gnucash/gnome/CMakeFiles/gnucash-appdata.dir/build.
> make:61:
> > gnucash/gnome/gnucash.appdata.xml] Error 1
> > make[1]: *** [CMakeFiles/Makefile2:7919:
> > gnucash/gnome/CMakeFiles/gnucash-appdata.dir/all] Error 2
> > make: *** [Makefile:163: all] Error 2
> > *** Error during phase build of gnucash-git: ## Error running
> make
> > -j 1  *** [15/17]
> >
> > Poked around but could not get it to work so thought I would see what the
> > build server logs yield but that has not worked since 25/02/2018 so no
> help
> > there.
> >
> This probably means msgfmt is not finding gettext's its rules. On linux
> they
> are in /usr/share/gettext/its and/or /usr/share/gettext-0.19.8/its.
>
> I had to search a bit on the windows build server. Apparently there they
> are
> stored under /mingw32/share/gettext/its which for some reason is not where
> msgfmt is expecting them. We can fix this by setting environment variable
> GETTEXTDATADIR to /mingw32/share/gettext somewhere that it's in the
> environment when gnucash is being built. I don't know offhand how to do
> that
> exactly in jhbuild.
>
>
> > So I downloaded that build but it fails with a missing
> > libboost_date_time-mt.dll so if the above is fixed it still might not
> work.
> >
> Interesting. The build server's build failure is a gettext issue as well.
> It
> fails to compare GETTEXT_VERSION_STRING to 0.19. Or more precisely it seems
> like GETTEXT_VERSION_STRING is not being set.
>
> Did you not get this error in your cmake run locally ?
>
> Geert
>
> > PS: Is it possible to clear out some of the old logs, maybe separate
> > sub-directories for each maint, master, unstable and docs.
>
> That should be something for Derek to look into...
>
> > Also the maint
> > build is complaining about certificates and gives up.
>
> Hmm, looks like our download script isn't happy with the new certificate
> being
> used at aquamaniac.  It appears the download function we use is not smart
> enough to read Alternative DNS names from the certificate... To be
> investigated...
>
> Unless you plan to dig into these yourself, can you file bug reports ?
>
> Thanks
>
>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows Build

[Robert Fewell]

Geert,

Regarding 1, I made local changes when I found it last month but forgot
about it.
Regarding 2, I cheated as mentioned in my posting last month,

in i686-w64-mingw32/include/wincrypt.h there is a define for
X509_NAME, I temporarily renamed it and was able to build xmlsec and
continue to build GnuCash and create steup.exe for it which installed
fine

Regards,
  Bob


On 5 March 2018 at 21:07, Geert Janssens  wrote:

> Op maandag 5 maart 2018 18:41:38 CET schreef Geert Janssens:
> > Op maandag 5 maart 2018 12:10:48 CET schreef Robert Fewell:
> > > Geert,
> > >
> > > I have successfully built a 2.7.5 version locally with these changes...
> > >
> > > Added the following to gnome/CMakeLists.txt at line 178 but I think
> this
> > > may need to go in the jhbuildrc.in file
> > > GETTEXTDATADIR=/mingw32/share/gettext
> >
> > Yes, I figured jhbuildrc.in would be a good candidate. I'm playing with
> > manipulating XDG_DATA_DIRS rather than GETTEXTDATADIR now for the same
> > effect. It should be more useful as there's more in /mingw32/share than
> > gettext data.
> >
> > Also, I have generalized it a bit to work for both 32 as 64 bit builds.
> >
> > > Added the following to gnucash-mingw64.iss at line 120
> > > Source: "@MINGW_DIR@\bin\libboost_date_time-mt.dll"; DestDir:
> "{app}\bin";
> > > Components: main
> >
> > Ok. I didn't understand your first mail correctly. Your fix makes sense
> now.
> > > Whilst poking around yesterday I also created copies of
> > > gettext/its/appdata.its/loc as it appeared to me the loc file was doing
> > > file matching but the match pattern was *.appdata.xml and not *.
> > > appdata.xml.in
> > > but this may not be required, need to delete these extra files and try
> > > another rebuild.
> >
> > This is probably not required. gettext tools will remove any .in
> extension
> > before determining the file type. It's like that on linux as well and it
> > works fine there.
> >
> > > Have you run the *setup-ming64-ps1 *file, I did last month and as
> reported
> > > made some changes which effected the build, namely I think cmake was
> > > updated to 10 which meant the FindSWIG patch would not apply so maybe
> > > there
> > > were other changes that affected gettext ?
> >
> > I didn't run setup-mingw64.ps1 and that was an important clue. Indeed it
> > looks like FindGettext.cmake has been updated to take an optional .exe
> into
> > account.
> >
> > The FindSWIG patch won't apply because it tries to look for a file in
> > cmake-3.9 while the files are now in cmake-3.10. I'm holding off on
> > adjusting the patch because it appears you didn't need it any more.
> >
> > Waiting for the build to finish (once more).
> >
>
> So some final updates:
>
> 1. The FindSWIG patch is still necessary. I have adapted it to work with
> cmake
> 3.10. I don't know how Bob got past that on his local build. Perhaps the
> values were still cached?
>
> 2. I have rerun setup-minw64.ps1 several times to get all non-jhbuild
> managed
> packages up to date. It took several runs because the first run updated
> msys2,
> which had new mingw packages in its package list, but the first run had
> already determined what to update. I believe my local box and the gnucash
> build server are now fully up to date.
>
> With that and my other patches in place...
>
> 2. I can't get a successful build on my local Windows 7 box. It fails to
> build
> xmlsec. I tried wiping it and restarting the build, but it consistently
> fails
> on
> file xmlsec-xmlsec_1_2_20/src/openssl/x509.c:94
> Error: expected declaration specifiers or '...' before '(' token
> static xmlChar* xmlSecOpenSSLX509NameWrite (X509_NAME* nm);
>
> The error points at the the X in X509_NAME. This triggers a whole set of
> other
> warnings which I won't repeat here.
>
> 3. Since I didn't manage to get my Win7 box to build this, I decided to
> try on
> the build server. This has no issues with xmlsec (unless it didn't retry,
> but
> I think it did). It consistently fails however when building gnucash. The
> error log can be seen here:
> https://code.gnucash.org/builds/win32/build-logs/build-
> unstable-2018-03-05-14-46-47.log
>
> Again I tried completely wiping the current build dir, but it still fails.
> So
> again I'm surprised Bob did get past this.
>
> I don't know how to proceed from here (yet) and I don't know when I will
> have
> time to continue this.
>
> If anyone else wants to take a stab at this, please go ahead.
>
> Geert
>
>
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Unstable Imap Editor

[Robert Fewell]

It was mentioned some where it was slow to load so thought I would have a
look.

Dropping the GtkTreeModel has improved that but that has highlighted a
couple of problems so far...

1st, when retrieving 'import-map-bays', the list consists of the number of
tokens squared like this...
 imported 1 transaction which results in 3 tokens and 1 transaction which
results in 2 tokens in the file which then leads to 25 entries in the
treeview.

So for the above the list coming back from
'gnc_account_imap_get_info_bayes' is 25 entries.

2nd, when retrieving 'import-map', the list is empty despite having this
entry...

  Checking Account
  

  import-map
  

  desc
  

  'MY HEALTH
  32282cd8503549af9cf62265df11b3c7

  

  


It seems that in account.cpp line 5642 which is..

if (qof_instance_has_slot (QOF_INSTANCE(acc), category_head))

is returning false despite category_head being 'import-map/desc'

Hopefully I will get it sorted and create a PR for it.

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

Re: Unstable Imap Editor

[Robert Fewell]

Could some one explain the following, trying to fix the 2nd problem as I
thought was the simpler one...
If I try this ...

std::vector path {IMAP_FRAME};
if (category)
path.emplace_back (category);

if (qof_instance_has_path_slot (QOF_INSTANCE (acc), path))

I have a slot but the following does not...

category_head = g_strdup_printf (IMAP_FRAME "/%s", category);

if (qof_instance_has_slot (QOF_INSTANCE(acc), category_head))

These two functions look like this...

bool qof_instance_has_path_slot (QofInstance const * inst,
std::vector const & path)
{
return inst->kvp_data->get_slot (path) != nullptr;
}

gboolean
qof_instance_has_slot (const QofInstance *inst, const char *path)
{
return inst->kvp_data->get_slot({path}) != NULL;
}

Does category_head need to be in a different format ?

Regards,

Bob



On 27 March 2018 at 17:33, Robert Fewell <14ubo...@gmail.com> wrote:

> It was mentioned some where it was slow to load so thought I would have a
> look.
>
> Dropping the GtkTreeModel has improved that but that has highlighted a
> couple of problems so far...
>
> 1st, when retrieving 'import-map-bays', the list consists of the number of
> tokens squared like this...
>  imported 1 transaction which results in 3 tokens and 1 transaction which
> results in 2 tokens in the file which then leads to 25 entries in the
> treeview.
>
> So for the above the list coming back from 'gnc_account_imap_get_info_bayes'
> is 25 entries.
>
> 2nd, when retrieving 'import-map', the list is empty despite having this
> entry...
>
>   Checking Account
>   
> 
>   import-map
>   
> 
>   desc
>   
> 
>   'MY HEALTH
>   32282cd8503549af9cf62265df11b3
> c7
> 
>   
> 
>   
> 
>
> It seems that in account.cpp line 5642 which is..
>
> if (qof_instance_has_slot (QOF_INSTANCE(acc), category_head))
>
> is returning false despite category_head being 'import-map/desc'
>
> Hopefully I will get it sorted and create a PR for it.
>
> Bob
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Feedback about 2.7.8

[Robert Fewell]

I do not think that is the right file to link to, I would of thought this
one was the correct one...
https://github.com/Gnucash/gnucash/blob/unstable/doc/gtk-3.0.css

Bob

On 28 March 2018 at 21:13, Adrien Monteleone 
wrote:

> Christop,
>
> A general guide to CSS(in the context of web pages) is available here:
>
> https://www.w3schools.com/css/
>
> A more specific guide with respect to CSS usage in GTK3 is here:
>
> https://developer.gnome.org/gtk3/stable/chap-css-overview.html
>
>
> Regards,
> Adrien
>
> > On Mar 28, 2018, at 2:20 PM, Christoph R  net> wrote:
> >
> > Hi Geert,
> >
> >> Am 28.03.2018 um 17:24 schrieb Geert Janssens <
> geert.gnuc...@kobaltwit.be>:
> >>
> >> Op woensdag 28 maart 2018 15:46:26 CEST schreef Christoph R:
> >>
> >>> It choked on one of my files, which worked fine with 2.6 and was
> probably
> >>> created with 2.4 or even earlier.  There was an out-of range date in
> the
> >>> price database which I corrected manually. But normal users would have
> been
> >>> lost.
> >> What was the date set to before you corrected it ? And how does it
> display in
> >> gnucash 2.6 if you look at that particular price in the Price editor ?
> >
> > Date was 1301-09-13 00:05:08 +0053
> > and it shows up absolutely correct as 13.9.1301 :-)
> >
> >>
> >>> adding “EXTRA_ARGS=--nofile” to Library/Application\
> >>> Support/Gnucash/gnucashrc does not have any effect any more.
> >>
> >> I never heard of a gnucashrc file. Perhaps that is/was an OS X/Quarz
> specific
> >> extension ? The loading code on OS X has been aligned with Windows and
> Linux
> >> in this development cycle, so perhaps it got lost in that work.
> >
> > Yes it was parsed by the MacOS launcher script, which apparently is gone
> now.
> >
> >>> Changing account or value of a reconciled
> >>> split gives me the correct warning as needed. Yeah! But I can change
> the
> >>> description of a reconciled split without a warning.
> >>
> >> Hmm, a split doesn't have a description, only a memo. Do you mean you
> get no
> >> warning when changing the memo ? Or do you mean you can change the
> transaction
> >> description of a transaction that has reconciled splits ?
> >
> > I get no warning when changing the memo. I get one when changing the
> transaction description.
> >
> >>
> >>> Fonts and icons are different - due to gtk3 - and not
> >>> necessarily to my liking. I had customised .gtkrc-2.0.gnucash a bit
> and of
> >>> course this does not work any more. Unfortunately I did not figure out
> how
> >>> to customise gtk3 on MacOS. Any help would be appreciated
> >>
> >> I have updated the relevant FAQ entry:
> >> https://wiki.gnucash.org/wiki/FAQ#Q:_How_do_I_change_the_
> register_colors.3F
> >
> > Wow, this CSS stuff is cryptic. Can you enlighten me how to set font and
> font size?
> >
> > Cheers,
> > Christoph
> >
> > ___
> > 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

Windows build failed to build new aqbanking 5.7.8

[Robert Fewell]

Was looking to see if the new version of aqbabking 5.7.8 fixes combobox
issue but it fails to build. The new Gwenhywfar 4.20 builds OK and this has
the gtk3 stuff in it.
There were some errors about creating symlinks due to the files already
being there which I suppose one can ignore but later it fails.
Looked at the build server logs and it has the same failure.

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

Re: Windows build failed to build new aqbanking 5.7.8

[Robert Fewell]

Thank you for the patch, that fixed the build but still the same with
aqbanking combo's.
Will see if I can find out what is happening.

Bob

On 30 March 2018 at 14:53, John Ralls  wrote:

> There’s a type error in AQBanking on windows that stops the AQB build and
> I haven’t yet added the patch to the build, though I did report it to
> Martin.
>
> The patch is attached.
>
> Regards,
> John Ralls
>
> > On Mar 30, 2018, at 5:13 AM, Robert Fewell <14ubo...@gmail.com> wrote:
> >
> > Was looking to see if the new version of aqbabking 5.7.8 fixes combobox
> > issue but it fails to build. The new Gwenhywfar 4.20 builds OK and this
> has
> > the gtk3 stuff in it.
> > There were some errors about creating symlinks due to the files already
> > being there which I suppose one can ignore but later it fails.
> > Looked at the build server logs and it has the same failure.
> >
> > 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] import map editor

[Robert Fewell]

I have just imported a CSV file and it works for me with and without
Bayesian matching the entries show up in the editor. The purpose is to
allow you to see and delete current matches to accounts, what you see is
dependant on whether you use Bayesian or not.

With Bayesian, the description column entries are split up into tokens
along with the transaction day which are then used to get the best match on
further imports.
With Non Bayesian, the description column entries are recorded against
there respective accounts and then used to match further imports.
This is where the learning aspect comes in, once you see the entries
hopefully it will make sense.

What I suspect is that you are not setting the accounts on the matcher page
of the assistant. If you leave them as UNBALANCED they do not show up in
the imap editor.

Bob

On 10 April 2018 at 21:55, Stefan Müller 
wrote:

> Hallo all,
> as there isn't anyone in the user mailing list who can answer my question
> may someone here can help me out.
>
> Can anyone explain the purpose of the "import map editor" shown in the
> tools menu?
> All what I can find related to mapping imports is this:
> https://wiki.gnucash.org/wiki/Bayes 
> http://gnucash.1415818.n4.nabble.com/Fixing-confused-bayesia
> n-matching-data-td4685819.html  ble.com/Fixing-confused-bayesian-matching-data-td4685819.html>
> but there is nothing about the editor.
>
> Can anyone explain how to use it is still empty after several csv imports.
>
> Thank you
>
> Stefan
>
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] import map editor

[Robert Fewell]

Stefen,

Yes to your first question, you should always try to do the matching on
that page, that's the way it learns for subsequent imports.
Bayesian / Non Bayesian is dependant on the preference setting you have
under 'online banking' and it uses those settings also.
'Online id' is used in OFX and QIF imports.

The import editor does not show reconciliation, it just shows you what
mappings you have and allows you to delete them.

Re-Documentation, when someone gets round to writing some, all volunteers
welcome.

Columns should be saved and they do on my setup, if not for you raise a
bug, https://wiki.gnucash.org/wiki/Bugzilla

I can understand why the trailing line number is not saved as you do not
know how big your CSV is, the leading line to skip is when you have headers
which I assume would always be the same.

Bob


On 11 April 2018 at 14:29, Stefan Mueller 
wrote:

> Hallo Robert,
> you mean to do the reconciliation in *Import Dialog *> *Match
> Transactions*as shown here.
> <https://cvs.gnucash.org/docs/de/gnucash-guide/figures/basics_import_general1.png>
>
> I've jsut tested it. Now, there are entries in the *Import Map Editor*
> but only in the *Bayesian* list. What about *Non-Bayesian* and *Online ID*,
> how are they get filled?
> I added a transaction manually and reconciled it but nothing shows up in  
> *Import
> Map Editor* but I reckon that is not covered by it, isn't it.
>
> In addition is there any posbility to influnce the *Bayesian matching *as
> it can be done in the settings for online banking import
> <https://cvs.gnucash.org/docs/de/gnucash-guide/basics-prefs1.html#basics-onlinebank2>.
>
>
> Will be there any documentation soon?
> During my research I find a very good but lonley piece of documentation
> about the import process, 2.7. Daten importieren
> <https://cvs.gnucash.org/docs/de/gnucash-guide/basics-import1.html>, on
> what all my statements mainly base on. Will it find a way in the official
> documentation?
>
> The is properly off-topic and has to go in a separated email but during
> the import process I nocticed that in  *Import Dialog *> *Transaction *
> *Information*
>
>    1. Column selction
>2. Trailing line to Skip number
>
> not saved, when saving settings.
>
> thx
> stefan
>
>
> 2018-04-11 11:57 GMT+02:00 Robert Fewell <14ubo...@gmail.com>:
>
>> I have just imported a CSV file and it works for me with and without
>> Bayesian matching the entries show up in the editor. The purpose is to
>> allow you to see and delete current matches to accounts, what you see is
>> dependant on whether you use Bayesian or not.
>>
>> With Bayesian, the description column entries are split up into tokens
>> along with the transaction day which are then used to get the best match on
>> further imports.
>> With Non Bayesian, the description column entries are recorded against
>> there respective accounts and then used to match further imports.
>> This is where the learning aspect comes in, once you see the entries
>> hopefully it will make sense.
>>
>> What I suspect is that you are not setting the accounts on the matcher
>> page of the assistant. If you leave them as UNBALANCED they do not show up
>> in the imap editor.
>>
>> Bob
>>
>> On 10 April 2018 at 21:55, Stefan Müller 
>> wrote:
>>
>>> Hallo all,
>>> as there isn't anyone in the user mailing list who can answer my
>>> question may someone here can help me out.
>>>
>>> Can anyone explain the purpose of the "import map editor" shown in the
>>> tools menu?
>>> All what I can find related to mapping imports is this:
>>> https://wiki.gnucash.org/wiki/Bayes <https://wiki.gnucash.org/wiki/Bayes
>>> >
>>> http://gnucash.1415818.n4.nabble.com/Fixing-confused-bayesia
>>> n-matching-data-td4685819.html <http://gnucash.1415818.n4.nab
>>> ble.com/Fixing-confused-bayesian-matching-data-td4685819.html>
>>> but there is nothing about the editor.
>>>
>>> Can anyone explain how to use it is still empty after several csv
>>> imports.
>>>
>>> Thank you
>>>
>>> Stefan
>>>
>>> ___
>>> 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] Bug 795101 - Scroll Bar in Reconcile Window Floats in and covers the check boxes

[Robert Fewell]

Would like some thoughts on possible fix...

There seems to be three options but I may of missed something, move the
toggle reconcile column, make it wider or add a dummy spacer column.

The first may not be liked..
The last seems a bit over kill.
So making the column wider seems the best / easiest.

In reconcile-view.c you have the line below which sets the column title...

gnc_search_param_set_title ((GNCSearchParam *) param, _("Reconciled:R")
+ 11);

All I need to do is add a couple of spaces either side of the 'R' which I
assume I can not do as it would affect the translation string

gnc_search_param_set_title ((GNCSearchParam *) param, _("Reconciled:
R  ") + 11);

But can I add this after above line, it works on my setup, is this OK.

// to allow space for the vertical scrollbar showing, add a couple of
spaces
gnc_search_param_set_title ((GNCSearchParam *) param,
  g_strconcat ("  ", ((GNCSearchParam *) param)->title, "  ",
NULL));

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

[GNC-dev] New invoice date opened shows 01/01/1970, possibly other places

[Robert Fewell]

Not sure about this but I have tracked this down as follows...

in dialog-invoice.c we start with this in the dialog

iw->opened_date = gnc_date_edit_new (gnc_time (NULL), FALSE, FALSE);

looking at the time64 number this starts of correct, i.e. today's value.

At some point this function gets called 'gnc_invoice_update_window' and on
line 1766 we have

time = gncInvoiceGetDateOpened (invoice);

and time is 9223372036854775807 which is INT64_MAX which is what is
returned for null invoice

following that we have...

if (!time)
{
gnc_date_edit_set_time (GNC_DATE_EDIT (iw->opened_date),  gnc_time
(NULL));
}
else
{
 gnc_date_edit_set_time (GNC_DATE_EDIT (iw->opened_date), time);
}

So, should that be 'if(time == INT64_MAX)', is this the invalid date value
now ?
and I noticed when I searched for gnc_date_edit_new, some used
gnc_time(NULL) while others used time(NULL)
what's preferred, should they be changed ?

Regards,

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

Re: [GNC-dev] Bye-bye Unstable

[Robert Fewell]

Just trying to get myself straight for going forward.
maint is now for bug fixes on version 3.0
master is for new stuff that would go into 4.0 but may be backported to 3.x
if appropriate

Is master version 3.99, it appears to be 3.0 still and does show the build
warning ?

Bob

On 15 April 2018 at 01:02, John Ralls  wrote:

> Fellow Developers,
>
> As long promised (threatened?) I've just merged unstable into maint and
> deleted unstable. In general you can just pull as usual and your branch
> will be updated.
>
> If you have unpushed commits in a local unstable branch, rebase that
> branch onto maint after pulling maint.
>
> If you have unpushed commits in a local maint branch:
>   If you want to port them to 3.x,
> git branch saved-maint
>  git fetch
>  git reset --hard origin/maint
>
>  Because of the directory structure changes you won't be able to
> cherry-pick or merge your saved-maint commits. Your best bet is to make
> patches with git format-patch and then edit the paths.
>
> 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] Help with making changes on Windows maint

[Robert Fewell]

Hi,
I have successfully built maint and needed to test some changes for some
bug fixes on Windows. So for the first couple of bugs I made the changes to
files in the following path...
c:\gcdev64\gnucash\maint\src\gnucash-git\gnucash\...

Went to my msys32 shell, used the usual jhbuild command which ran
successfully and was able to run gnucash from the maint directory via a cmd
file, some icons were missing but not relevant for my tests.

Now the problem...
Wanted to change file
c:\gcdev64\gnucash\maint\src\gnucash-git\gnucash\gnome-utils\gnc-main-window.c/h

There is a function in there gnc_main_window_popup_menu_cb which was
declared static but I wanted to expose it so I could call it from
gnc-plugin-page-register.c
Removed the static, added function to .h file and started the rebuild which
all looked fine until it failed with...

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/gnucash/import-export/qif-imp/qif-import.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/gnucash/import-export/qif-imp/qif-import.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 ((load-extension "libgnc-gnome" "scm_init_sw_gnome_module"))
() ...]
In unknown file:
   ?: 1 [load-extension "libgnc-gnome" "scm_init_sw_gnome_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: "libgnc-gnome",
message: "The specified module could not be found."
make[2]: ***
[gnucash/import-export/qif-imp/CMakeFiles/scm-qif-import-2.dir/build.make:63:
lib/gnucash/scm/ccache/2.0/gnucash/import-export/qif-import.go] Error 1
make[1]: *** [CMakeFiles/Makefile2:9685:
gnucash/import-export/qif-imp/CMakeFiles/scm-qif-import-2.dir/all] Error 2
make: *** [Makefile:163: all] Error 2

Next I deleted maint/build/gnucash-git but that made no difference.
Added a duplicate of that function with a different name but that made no
difference.

Why do my changes cause this scheme error?
Do I need to remove more files before the rebuild ?

Regards,

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

Re: [GNC-dev] Help with making changes on Windows maint

[Robert Fewell]

John,

I did that at the beginning of the week. As I said at the top of my first
message, I had a successful build, made some changes to prove a bug fix,
rebuilt and that was OK. It is only when I tried to make changes to
gnc-main-window.c/h that I get the error message. If I change them back, it
will work again.
Maybe I need to delete more files and not just the build/gnucash-git
directory.

Bob

On 20 April 2018 at 03:23, John Ralls  wrote:

>
>
> On Apr 19, 2018, at 9:16 AM, Robert Fewell <14ubo...@gmail.com> wrote:
>
> Hi,
> I have successfully built maint and needed to test some changes for some
> bug fixes on Windows. So for the first couple of bugs I made the changes to
> files in the following path...
> c:\gcdev64\gnucash\maint\src\gnucash-git\gnucash\...
>
> Went to my msys32 shell, used the usual jhbuild command which ran
> successfully and was able to run gnucash from the maint directory via a cmd
> file, some icons were missing but not relevant for my tests.
>
> Now the problem...
> Wanted to change file
> c:\gcdev64\gnucash\maint\src\gnucash-git\gnucash\gnome-
> utils\gnc-main-window.c/h
>
> There is a function in there gnc_main_window_popup_menu_cb which was
> declared static but I wanted to expose it so I could call it from
> gnc-plugin-page-register.c
> Removed the static, added function to .h file and started the rebuild which
> all looked fine until it failed with...
>
> 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/gnucash/import-
> export/qif-imp/qif-import.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/gnucash/import-
> export/qif-imp/qif-import.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 # 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 ((load-extension "libgnc-gnome" "scm_init_sw_gnome_module"))
> () ...]
> In unknown file:
>   ?: 1 [load-extension "libgnc-gnome" "scm_init_sw_gnome_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:100:6 (thrown-k . args)>:
> ice-9/boot-9.scm:109:20: In procedure dynamic-link: file: "libgnc-gnome",
> message: "The specified module could not be found."
> make[2]: ***
> [gnucash/import-export/qif-imp/CMakeFiles/scm-qif-import-
> 2.dir/build.make:63:
> lib/gnucash/scm/ccache/2.0/gnucash/import-export/qif-import.go] Error 1
> make[1]: *** [CMakeFiles/Makefile2:9685:
> gnucash/import-export/qif-imp/CMakeFiles/scm-qif-import-2.dir/all] Error 2
> make: *** [Makefile:163: all] Error 2
>
> Next I deleted maint/build/gnucash-git but that made no difference.
> Added a duplicate of that function with a different name but that made no
> difference.
>
> Why do my changes cause this scheme error?
> Do I need to remove more files before the rebuild ?
>
>
> Bob,
>
> This is probably due to https://github.com/Alexpux/
> MINGW-packages/issues/3609. The workaround for now is to set ignorepkg in
> paceman.conf, see https://wiki.gnucash.org/wiki/Building_on_Windows
>
> To recover you need to revert the upgrades of ICU, Boost, and harfbuzz.
> The previous versions will be in /var/cache/pacman/pkg; you want the
> next-to-latest of each. Open an msys shell (doesn’t matter which), do e.g.
>   ls /var/cache/pacman/pkg/*boost*
>   pacman -U /var/cache/pacman/pkg/
> for each one.
>
> Regards,
> John Ralls
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Help with making changes on Windows maint

[Robert Fewell]

Deleting the maint/inst/lib/gnucash directory did not fix it but what did
was when you get the jhbuild menu after it fails, copying all the
maint/build/bin files to maint/inst/bin and then I selected option 1 to
rebuild.

Had some time and with the changes made to gnc-main-window.c/h, at the
failure all I needed to do was copy
maint/build/bin/libgncmod-gnome-utils.dll to the maint/inst/bin directory
and continue with the rebuild and all was OK.

Not sure why at build time it is looking in the inst directory ?

Bob

On 20 April 2018 at 14:53, John Ralls  wrote:

> Bob,
>
> Sorry, I misunderstood. Try rm -rf c:\gcdev64\gnucash\maint\inst\
> lib\gnucash\*.
>
> Regards,
> John Ralls
>
>
> On Apr 20, 2018, at 6:31 AM, Robert Fewell <14ubo...@gmail.com> wrote:
>
> John,
>
> I did that at the beginning of the week. As I said at the top of my first
> message, I had a successful build, made some changes to prove a bug fix,
> rebuilt and that was OK. It is only when I tried to make changes to
> gnc-main-window.c/h that I get the error message. If I change them back, it
> will work again.
> Maybe I need to delete more files and not just the build/gnucash-git
> directory.
>
> Bob
>
> On 20 April 2018 at 03:23, John Ralls  wrote:
>
>>
>>
>> On Apr 19, 2018, at 9:16 AM, Robert Fewell <14ubo...@gmail.com> wrote:
>>
>> Hi,
>> I have successfully built maint and needed to test some changes for some
>> bug fixes on Windows. So for the first couple of bugs I made the changes
>> to
>> files in the following path...
>> c:\gcdev64\gnucash\maint\src\gnucash-git\gnucash\...
>>
>> Went to my msys32 shell, used the usual jhbuild command which ran
>> successfully and was able to run gnucash from the maint directory via a
>> cmd
>> file, some icons were missing but not relevant for my tests.
>>
>> Now the problem...
>> Wanted to change file
>> c:\gcdev64\gnucash\maint\src\gnucash-git\gnucash\gnome-utils
>> \gnc-main-window.c/h
>>
>> There is a function in there gnc_main_window_popup_menu_cb which was
>> declared static but I wanted to expose it so I could call it from
>> gnc-plugin-page-register.c
>> Removed the static, added function to .h file and started the rebuild
>> which
>> all looked fine until it failed with...
>>
>> 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/gnucash/import-exp
>> ort/qif-imp/qif-import.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/gnucash/import-exp
>> ort/qif-imp/qif-import.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 #> 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 ((load-extension "libgnc-gnome" "scm_init_sw_gnome_module"))
>> () ...]
>> In unknown file:
>>   ?: 1 [load-extension "libgnc-gnome" "scm_init_sw_gnome_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:100:6 (thrown-k . args)>:
>> ice-9/boot-9.scm:109:20: In procedure dynamic-link: file: "libgnc-gnome",
>> message: "The specified module could not be found."
>> make[2]: ***
>> [gnucash/import-export/qif-imp/CMakeFiles/scm-qif-import-2.
>> dir/build.make:63:
>> lib/gnucash/scm/ccache/2.0/gnucash/import-export/qif-import.go] Error 1
>> make[1]: *** [CMakeFiles/Makefile2:9685:
>> gnucash/import-export/qif-imp/CMakeFiles/scm-qif-import-2.dir/all] Error
>> 2
>> make: *** [Makefile:163: all] Error 2
>>
>> Next I deleted

[GNC-dev] Bug 795653 - Windows File Open/Save Dialog

[Robert Fewell]

Had a poke at this as I was certain that it was working in the 2.7.x series.

It can be fixed by downgrading the following packages with pcman -U to...

pacman -U
/var/cache/pacman/pkg/mingw-w64-i686-glib2-2.54.3-1-any.pkg.tar.xz
pacman -U
/var/cache/pacman/pkg/mingw-w64-i686-pango-1.40.11-1-any.pkg.tar.xz
pacman -U
/var/cache/pacman/pkg/mingw-w64-i686-gtk3-3.22.28-1-any.pkg.tar.xz

I did try doing a system upgrade with pacman -Syu but with those packages I
still had to down grade to the above packages to fix the file chooser
dialogue.

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

Re: [GNC-dev] Bug 795653 - Windows File Open/Save Dialog

[Robert Fewell]

John,

I think I downgraded gtk and ran gnucash from the install directory with no
change. Did glib and when starting gnucash complained about pango.
I did not rebuild gnucash after just doing gtk, I can check on that
tomorrow if you would like.

Bob

On 10 May 2018 at 17:41, John Ralls  wrote:

>
>
> > On May 10, 2018, at 9:34 AM, Robert Fewell <14ubo...@gmail.com> wrote:
> >
> > Had a poke at this as I was certain that it was working in the 2.7.x
> series.
> >
> > It can be fixed by downgrading the following packages with pcman -U to...
> >
> > pacman -U
> > /var/cache/pacman/pkg/mingw-w64-i686-glib2-2.54.3-1-any.pkg.tar.xz
> > pacman -U
> > /var/cache/pacman/pkg/mingw-w64-i686-pango-1.40.11-1-any.pkg.tar.xz
> > pacman -U
> > /var/cache/pacman/pkg/mingw-w64-i686-gtk3-3.22.28-1-any.pkg.tar.xz
> >
> > I did try doing a system upgrade with pacman -Syu but with those
> packages I
> > still had to down grade to the above packages to fix the file chooser
> > dialogue.
>
> Ah, thanks, that was next on my list. Surely one need downgrade only gtk.
> Did pacman refuse to do that if you didn't also downgrade the other two?
>
> Regards,
> John Ralls
>
>
___
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

[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

Re: [GNC-dev] Windows Build

[Robert Fewell]

Thank you, that makes it clearer now.
Bob

On 17 May 2018 at 18:22, John Ralls  wrote:

>
>
> > On May 17, 2018, at 9:49 AM, Geert Janssens 
> 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] 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] 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  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] 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

[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] Transaction / Split Action List

[Robert Fewell]

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

Re: [GNC-dev] Widget naming and css

[Robert Fewell]

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

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

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

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

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

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

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

Hope this is clearer.

Regards,
Bob


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

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

Re: [GNC-dev] 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
> > >

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

[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 (&temp);

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 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 (&temp);
> >
> >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

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

[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

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

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

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

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

[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

[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

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

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

[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

[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

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

[GNC-dev] Bugzilla - Resolved Bugs

[Robert Fewell]

Hi,

What is the correct way to mark bugs fixed.
Should I be marking them as RESOLVED/FIXED if I think I have fixed the
reported bug with appropriate text asking for the reporter to test and
reopen if not fixed.
or
leave it as NEEDINFO with some text asking for the reporter to test and
update the bug accordingly. Obviously this could mean waiting for the next
release if they do not want to try a windows nightly / flatpack.

Regards,
  Bob
___
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

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

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

[Robert Fewell]

Frank,
So it looks like get rid of trailing colon/space and right align text for
normal dialogues.

For RTL, GTK already swaps the label and control along with the alignment
which I have observed on the 'View Invoice page'.

The preference dialogue may need to be treated differently, not sure yet
and there is also no indents for RTL, will need to be looked at separately
along with some other RTL stuff I have been thinking about.

For removing the trailing colon, 35 out of 66 glade files and maybe some
source files would need to be changed which is probably too many changes
for maint in one hit all be it in a few commits.
Then on top of that, changing from GTK boxes to grids and the alignment
changes, I am just not sure what to do on maint and what to do on master?

Regards,
Bob

On Mon, 4 Nov 2019 at 16:05, Frank H. Ellenberger <
frank.h.ellenber...@gmail.com> wrote:

> Hi Bob,
>
> Am 04.11.19 um 12:01 schrieb Robert Fewell:
> :
> > 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 ?
>
> The benefit of the right alignment: It is easily comprehensible which
> label belongs to which control element. This would be harder, if you
> have one long and many short labels and align them left.
>
> Their exception is the existence of options, which depend on a
> previous option, i.e. in Edit->Preferences>Scheduled Transactions
> "Notify before transactions are created" is only vailable, if
> "Auto-create new transactions" is enabled. I am wondering, if there is
> a smarter solution.
>
> Another question: How will the elements behave for RTL writing?
>
> > Regards,
> > Bob
> :
> >> https://developer.gnome.org/hig/stable/visual-layout.html.en
>
> Regards
> Frank
>
___
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] 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

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

[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] 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] 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] 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 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] Windows build fails to run

[Robert Fewell]

90ed0
, pre_unwind_handler_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

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]

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

[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] 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
> > > >>> + 

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

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

[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

[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

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

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

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

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]

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]

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]

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]

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

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

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

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