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

[prl]

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"


Regards,
Peter