[GNC-dev] gsettings not working bug 797222 Resetting the "change reconciled split" warning doesn't take effect until GnuCash is restarted

Chris Good goodchris96 at gmail.com
Sun May 24 00:12:27 EDT 2020


-----Original Message-----
From: John Ralls <jralls at ceridwen.us> 
Sent: Wednesday, 20 May 2020 1:34 PM
To: Chris Good <goodchris96 at gmail.com>
Cc: gnucash-devel <gnucash-devel at gnucash.org>
Subject: Re: [GNC-dev] gsettings not working bug 797222 Resetting the
"change reconciled split" warning doesn't take effect until GnuCash is
restarted


> On May 19, 2020, at 6:44 PM, Chris Good <goodchris96 at gmail.com> wrote:
> 
> Hi gurus,
> 
> 1. src/gnucash/libgnucash/app-utils/gnc-gsettings.c
> gnc_gsettings_load_backend() contains:
> 	    /* The gsettings backend only works in an installed environment.
> 	     * When called from the source environment (for testing
> purposes)
> 	     * simply return.
> 	     */
> 	    if (g_strcmp0 (g_getenv ("GNC_UNINSTALLED"), "1") == 0)
> 	        return;
> 
> I don't think that is true anymore as there is no GNC_UNINSTALLED in 
> the environment file and the schemas seem to be compiled to  
> build/share/glib-2.0/schemas/gschemas.compiled
> 
> This code was added in
> https://github.com/Gnucash/gnucash/commit/31c7396e15715d6e178b8fe727f6
> 1dabe2
> 6eca53#diff-83a994aa1576a20801bf5ec6475d5a90
> 	gjanssens committed on Dec 3, 2013
> 	The preferences backend can't work from the source environment 
> because
> 	it's schemas won't be compiled. This situation is only relevant for 
> testing,
> 	which is done from the source (or build) tree.
> 	Note that a few preferences are needed by the xml backend. If no 
> preferences
> 	backend is loaded, some sane defaults will be used instead. Again 
> this should
> 	only matter for testing, in which case the real preferences are not 
> relevant
> 	anyway.
> 
> Should the above code be removed?
> 
> 2. I've debugged (Linux) and found there doesn't seem to be any bug in 
> the GnuCash code and that there is some sort of disconnect between 
> writing a gsettings (dconf) setting and reading it. I've put in debug 
> statements right after writing a setting, which reads it again, and it 
> gets an old value.
> 
> I found there is a g_settings_sync() that is supposed to wait until 
> all writes (which need a D-Bus session bus) have occurred.
> Putting that in has not helped. I found on the internet several pages 
> saying
> g_settings_sync() is not needed if there is a gtk main loop and as I 
> have seen that during debugging, I guess it is not needed...
> 
> I have compiled glib with optimization off so I can debug (the problem 
> still
> exists) but I really have no idea of what it is supposed to do. I can 
> see
> g_settings_get_int() reading something like a hash table and getting 
> the wrong value. It doesn't seem to executing anything I can identify 
> as dconf???
> 
> Any suggestions please?

Chris,

No, it should not be removed. As the commit summary indicates it's necessary
for running tests.

GNC_UNINSTALLED, along with its companion GNC_BUILDDIR, is set in
common/cmake-modules/GncAddSchemeTargets.cmake,
common/cmake-modules/GncAddTest.cmake, bindings/python/tests/runTests.py and
several Scheme files for running tests. It's also needed for running reports
without first installing, for which you can say
  GNC_UNINSTALLED=1 GNC_BUILDDIR=`pwd` bin/gnucash from a prompt in the main
builddir.

Since bug 797222 is about a preference not taking effect until after a
program restart you'll obviously need functional GSettings to debug it. It
*is* possible that the bug is in GSettings, but in most cases preference
changes take effect immediately so it seems unlikely to me that that's the
case.

Regards,
John Ralls

Hi John,

Thanks for the info. Unfortunately, I often forget about the tests when I
hear 'testing'.
It makes sense to disable the settings environment to ensure the settings
are in the default state while testing, and also do not alter the live user
settings.
Is there some other problem with using settings from the build directory, as
AFAIK, the settings schema is compiled by the build, so I don't understand
the statement "The preferences backend can't work from the source
environment because it's schemas won't be compiled." It seems to work fine
under Linux from the build, except for the bug mentioned above.
Is it because in the CI testing, the built schemas are not available?

I agree it is unlikely that this bug is because of a problem with GSettings.
The problem also occurs with other warnings (eg trying to unreconcile a
reconciled split) and also happens in Linux and Windows.

Unfortunately, I'm out of ideas and will have to give up on this bug.

Regards,
Chris Good




More information about the gnucash-devel mailing list