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

[prl]

On 9/08/11 0:41, John Ralls wrote:
> On Aug 8, 2011, at 12:25 AM, prl wrote:
>
>> On 8/08/11 2:08, John Ralls wrote:
>>> ... Could you file a bug against GConf complaining that it doesn't handle paths with spaces in them?
>>>
>> I've tracked the problem down. ...
> Peter,
>
> Ah, good job.
>
> GConf, like Gnucash, uses http://bugzilla.gnome.org.
>
> As to whether it will be considered a bug: That's hard to say. I don't really know any of the current maintainers.
> It seems that whoever wrote that didn't consider the (admittedly unusual) use case of putting user home directories somewhere other than the system default. It certainly seems to me that any legal path character on the host os should be legal here, too.
>
> Regards,
> John Ralls
>

I've searched the GConf bugs database for invalid_chars, and the bug has 
been reported twice:
https://bugzilla.gnome.org/show_bug.cgi?id=161209
https://bugzilla.gnome.org/show_bug.cgi?id=640716

The initial report was 161209, and it was reported 6 1/2 years ago (Dec 
2004). It seems that there's little prospect of getting it fixed.

I've had a poke around in the GConf source, and I can't see any reason 
for having this invalid_chars check at all, at least not for xml: 
configuration sources. The right place to check whether a string is a 
valid file system path is to ask the file system to do some operation on 
it. It should tell you soon enough! The invalid_chars string itself 
makes no sense, either as a list of invalid characters in a URI (which a 
GConf source address superficially resembles) or as a list of invalid 
Windows filename characters (and anyway, why should Linux and OS X be 
made to suffer for the shortcomings of file names in Windows?).

If such an invalid characters test were to have any place it should 
probably be in the configuration source backend, not in the common GConf 
code anyway.

Regards,
Peter