Gnucash 2.6: problem opening file

[Geert Janssens]

On Saturday 18 January 2014 09:18:25 John Ralls wrote:
> On Jan 18, 2014, at 1:26 AM, Geert Janssens <janssens-geert at telenet.be> wrote:
> > 
> > More in general it was something I read on the glib website some
> > time ago that made me believe that what Mike did was indeed
> > necessary for some locales. And at the time it made me believe we
> > had some more work ahead of us to find all situations where we were
> > using strings passed in from the operating system and treat them in
> > the same way.
> > 
> > I have just read that page [1] again and it looks like I
> > misunderstood. We should apparently only convert file system
> > strings if we want to show them to the user. So it looks like
> > John's fix is sufficient.
> 
> No, we shouldn't convert file system strings at all, at least in that
> direction. GLib takes care of that for us. The manual page you're
> referring to is talking about reading file names from a Unix OS,
> almost all modern versions of which do indeed store filenames in
> UTF8. Windows uses UTF16 for encoding filenames and the system code
> page for displaying them to the user. GLib knows this and does the
> conversion before calling fopen().
> 
> The only time we'd need to convert a file system string would be to
> pass it back to a native Windows function, and in that case we'd
> normally convert *from* UTF8 to UTF16 for almost everything; we'd
> only convert it to the locale codepage to display it in a non-MSYS
> command window.
> 
> For those curious about why I know this, I rewrote the Gramps
> localization code for the new Gtk3 version a year ago. Gramps uses
> Gtk only for the GUI, relying on Python for everything else, and
> Python doesn't do any transcoding automatically. I got to learn more
> than I ever wanted to know about Windows codepages.
> 
> Regards,
> John Ralls

Thanks for the clarification. I'm glad glib handles it for us and I misread the page once more :)

But this means if we intend to drop glib at some point, we will have to make sure the 
replacement code/framework handles this properly as well...

These are the type of platform dependent differences I'd happily rely on a good platform 
abstraction framework (which glib certainly is to some extent).

Geert