GnuCash 2.2.0 under Windows (problems)

[Mike or Penny Novack]

"Thanks a lot for the report! I do not know whether we can do a lot 
about that though."

I'm a senior analyst, not just a programmer. Sometimes the "solution" to 
a problem doesn't involve the code. I appreciate that it might not be 
practical to fix the code, but that doesn't mean "do nothing" in a 
situation like this.

We have a GnuCash release for Windows, and we have discovered that it 
won't work (completely properly) for all Windows users. What do we do 
about that if we can't fix the code? A number of possibilities:
1) We place a release note warning for Windows users along the lines  
"will not work  if your  Windows account name contains ......."
    I  for one would have seen that (certainly AFTER encountering the 
problem). But since few end users read the documentation.
2) A "first time only" routine that examines the name of the data 
directory (the user account name) and if an "illegal character" is 
encountered, pops up a message explaining the problem and suggesting 
that if the person wants to use GnuCash with everything working properly 
they create another Windows account to do that in.
3) We alert the "user help" list so that when puzzled Windows users come 
in with inquiries about "not working" they get an explanation (I've 
already done that). Being unfamiliar with GnuCash and the data 
structures it uses, this took me some time to figure out (first had to 
notice missing .gconf directory). I did figure it out in the end, but 
you can't expect even a knowlegable end user to do this for themselves!

<ampersand> is a legal character in Windows directory names. This 
problem would not affect my evaluation report with regard to our own 
organization using GnuCash but I will be doing two evaluation reports, 
one for "us" (MA Chapter of The American Chestnut Foundation) and one 
for "the OpenCD" group.

I am not as sure, BTW, that there wouldn't be some way around this. Note 
that not all of the GnuCash code has difficulty coping with the "&". For 
example, no problem being able to find the set of books I created (that 
path has the "&" in it too -- did not prevent a correct path being 
placed in .gtk-bookmarks). Instead of my jumping into the code, may I 
ask a question? Is the problem (precise specification)

"...if any of those characters appears in a gconf configuration source 
address, then that is declared as invalid..."
Did that mean "in the name of the directory in which the directory 
.gconf will be placed" or "in the name of any directory in the path to 
the directory in which .gconf will be placed"? The former should not be 
the same insurmountable problem as the latter. I must admit to being a 
little surprised to discover that the configuration directories (and the 
file .gtk-bookmarks) were simply dropped separately into the top level 
of the user data directory as up to now all open source for Windows apps 
I have tried have created an "application data directory" for stuff like 
that -- good practice since it prevents any chance of a name conflict 
with a directory or file already in the user's data directory (now only 
the name for the app data directory itself need be unique).

Michael

>that is correct.  Spaces are not the problem on Windows, but the
>ampersand.  In
>
>http://svn.gnome.org/viewcvs/gconf/trunk/gconf/gconf-backend.c?revision=2371&view=markup
>
>you will find that the string invalid_chars is defined as "\t\r\n\"$&<>,
>+=#!()'|{}[]?~`;%\\" and if any of those characters appears in a gconf
>configuration source address, then that is declared as invalid.  In the
>end you do not have any writable gconf source and are tied to the
>default values.
>
>For a bug, see
>
>http://bugzilla.gnome.org/show_bug.cgi?id=161209
>
>Thanks a lot for the report!  I do not know whether we can do a lot
>about that though.
>
>-- andi5
>
>
>  
>


-- 
There is no possibility of social justice on a dead planet except the equality of the grave.