Can't update preferences and can't get rid of Welcome dialog in Gnucash 2.4.7 (OS X 2.6.8)

[John Ralls]

On Aug 11, 2011, at 12:23 AM, prl wrote:

> On 11/08/11 15:06, John Ralls wrote:
>> On Aug 10, 2011, at 8:47 PM, prl wrote:
>> 
>>> On 11/08/11 13:09, John Ralls wrote:
>>>> ...
>>>> Wouldn't it be simpler for me to just patch GConf to remove the character check?
>>>> 
>>>> Regards,
>>>> John Ralls
>>> Yes, but I wasn't sure that was a direction you wanted to go.
>> 
>> Peter,
>> 
>> I prefer to get upstream fixed, but I also don't wait. There are a few Gnome project maintainers with their heads up their asses, but Maraas moved instantly to the top of the list once you pointed out 161209.
>> 
>> Even with gtk-quartz, which should be generally sympathetic to getting OSX bugs fixed there's resistance, so I have separate branches in git for my modifications and 16 corresponding patches in the gtk-osx repo for tarballs.
> 
> Thanks, John. I'd appreciate a fix. In the meantime, I've got my own :-)
> 
> The original design looks a bit misguided. There are actually two separate tests for this set of invalid characters. One is in gconf-backend.c, and is the cause of my original problem. The other is in gconf.c.
> 
> The test in gconf.c is in principle more sensible, because it tests for invalid characters in GConf key names. Since key names that are portable across different (eventually) backends, having some rules about their structure seems sensible, and the code escapes illegal characters in key names before they're used as file names.
> 
> Unfortunately, though, even in this case where the intention is reasonable, the implementation fails, because it allows '*' and ':' to appear unescaped in key names, and they're both illegal in Windows long file names.
> 
> My preference would be for there to be no test for invalid chars in the configuration source address in gconf-backend.c, and just allow it to be tested in the backend (which is likely to be a backend-depended test anyway). In the case of backends/xml-backend.c, any failure of the file system's path syntax will cause the g_stat() and g_mkdir() in resolve_address() to fail, and so the error is flagged by the proper arbiter of file system path syntax, the file system implementation.
> 
> I do hate trying to read i386 assembly code, though, especially when it's the product of the gcc optimiser, so not having to re-create this patch would be very nice.

Peter,

The patch is incorporated in the new Gnucash-2.4.7-2 dmgs. Please try it out.

Regards,
John Ralls