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 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. I managed to persuade gconfd to run independent of Gnucash and capture its output. The relevant log message was:
> 
> (process:2203): GConf-WARNING **: Failed to load source "xml:readwrite:/Volumes/Cambyses User/Users/prl/.gconf": Couldn't resolve address for configuration source: Bad address `xml:readwrite:/Volumes/Cambyses User/Users/prl/.gconf': ` ' is an invalid character in a configuration storage address
> 
> The error is generated when the call of gconf_address_valid() in gconf_get_backend() (gconf-backend.c) fails. gconf_address_valid() (gconf-backend.c) has the following set of invalid characters:
> 
>    static const char invalid_chars[] =
>    #ifndef G_OS_WIN32
>      /* Space is common in user names (and thus home directories) on Windows */
>      " "
>    #endif
>      "\t\r\n\"$&<>,+=#!()'|{}[]?~`;%\\";
> 
> So it appears that not allowing spaces in paths except in Windows is a deliberate decision.
> 
> Where do I report this as a bug, and is it likely to be regarded as one?
> 
> I've also discovered along the way that the only valid form of quoting a configuration source in the gconf path file is as:
>    "xml:readwrite:/some/path/without/spaces/unless/you/run/Windows"
> The quoting is only useful if you want the configuration source to have leading whitespace or # symbols. It's not an error not to have a matching closing quote.
> The rules for includes are different, and there only the file name may have quotes:
>    include "/some/path"

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