I've been playing with Jon Cruz's updates to the profile_path and mkdir stuff. Short story: it works. Long story: g_file_test isn't utf sane. *bang head*
So, the test for the directory fails, but making it works just fine.
Kees Cook wrote:
I've been playing with Jon Cruz's updates to the profile_path and mkdir stuff. Short story: it works. Long story: g_file_test isn't utf sane. *bang head*
So, the test for the directory fails, but making it works just fine.
Soo....
Sounds like time for Inkscape::IO::fileTest()
:-)
*sigh* I find it *very* annoying that the GTK+ API uses different encodings all over but doesn't even mark which is used or needed where. I realize that probably comes from them changing things after the fact and then only testing on English (or Western) systems.
On Sun, Jan 30, 2005 at 11:20:03AM -0800, Jon A. Cruz wrote:
Sounds like time for Inkscape::IO::fileTest()
Yup. That's what I've added. (Well, I called it file_test, but yeah). It's not checked in yet, I want to solve the current "~/.gnome" crash under Linux.
On Sun, Jan 30, 2005 at 11:44:16AM -0800, Kees Cook wrote:
Yup. That's what I've added. (Well, I called it file_test, but yeah). It's not checked in yet, I want to solve the current "~/.gnome" crash under Linux.
Okay, the crash is fixed, Inkscape::IO::file_test is in CVS now. My "Mr Umlaut" user under windows works fine now.
Bulia: you had a note near one of the g_file_test calls that said "FIXME: make this work under win95 too". I'm not sure what was failing, but can you test it with the next win32 build snapshot?
I think we might close a mess of bugs with this fix.
Jon A. Cruz esordì:
*sigh* I find it *very* annoying that the GTK+ API uses different encodings all over but doesn't even mark which is used or needed where. I realize that probably comes from them changing things after the fact and then only testing on English (or Western) systems.
GTK+ and GLib use exclusively UTF8. The exception in the file-related function are due to the fact that there is no sane way to use any enconding different from the one the filesystem expect, expecially on unix systems... :)
You should use the g_filename_to_utf8() and g_filename_from_utf8() utility function to convert enconding between the internal rapresentation (UTF8) and the filesystem rapresentation (usually locale dependent).
I agree this should be written in big fonts at the top of the file-related utilities in GLib... :(
Emanuele Aina wrote:
You should use the g_filename_to_utf8() and g_filename_from_utf8() utility function to convert enconding between the internal rapresentation (UTF8) and the filesystem rapresentation (usually locale dependent).
But on Windows there's an additionall complication.
The 'filename' encoding glib gives us is mainly only useful for names in the 8-bit CP_ACP encoding. Anything else (including UTF-8 if glib uses that for 'filename' on XP) will fail when passed to any standard io calls. In these cases one would need to convert to UTF-16 and then call a different file routine. And in order to get a single binary that works both on Windows 95/98/ME and on Windows NT/2K/XP that needs to be checked at runtime.
Oh, and another slight problem is that often it's hard to get systems setup where the three glib encodings are different and to feed them proper test cases, so not all the routines do all the right things. They're working on it, but there are some issues still.
Jon A. Cruz wrote:
... And in order to get a single binary that works both on Windows 95/98/ME and on Windows NT/2K/XP that needs to be checked at runtime.
For that unicows might help (see http://libunicows.sourceforge.net/), or perhaps even the UTF-8 API used by Foobar2000 (see http://www.foobar2000.org/, it's in the SDK). These might be a bit extreme if filenames are the only problem, but it could provide a relatively easy solution to this particular (sub)problem.
Jasper van de Gronde wrote:
Jon A. Cruz wrote:
... And in order to get a single binary that works both on Windows 95/98/ME and on Windows NT/2K/XP that needs to be checked at runtime.
For that unicows might help (see http://libunicows.sourceforge.net/), or perhaps even the UTF-8 API used by Foobar2000 (see http://www.foobar2000.org/, it's in the SDK). These might be a bit extreme if filenames are the only problem, but it could provide a relatively easy solution to this particular (sub)problem.
Generally doesn't quite fit all of our needs, as among other things we'd have to switch more code to Win32 API stuff directly (i.e. OpenFile instead of stdio's fopen, etc.
Thankfully, we don't use that much of the Win32 API, so things are fairly manageable. Oh, and I've been doing this kind of trick for years before Microsoft released MSLU and unicows, so it's fairly shaken out.
Great! Good work. That's one of the Must-Fix bugs put into the grave (plus probably a whole host of other utf-related bugs I'm guessing.)
Bryce
On Sun, 30 Jan 2005, Kees Cook wrote:
I've been playing with Jon Cruz's updates to the profile_path and mkdir stuff. Short story: it works. Long story: g_file_test isn't utf sane. *bang head*
So, the test for the directory fails, but making it works just fine.
participants (5)
-
Bryce Harrington -
Emanuele Aina -
Jasper van de Gronde -
Jon A. Cruz -
Kees Cook