On Thu, 2009-02-26 at 08:18 +1100, Kevin Ryde wrote: > Quentin Sculo <squentin free fr> writes: > > > > FileChooserDialog > > If the docs are to be believed gtk_file_chooser_get_filename() returns > bytes, though it's marked as a gchar* return. Eg. foo.pl below in a > latin1 locale, click on browse then click on the y-dieresis file gives > > Malformed UTF-8 character (overflow at 0x1806ade8, byte 0x00, after start byte 0xff) in subroutine entry at /usr/lib/perl/5.10/Data/Dumper.pm line 190. > > And a printf in the XS shows gtk_file_chooser_get_filename() returned a > bare '\xFF' byte. > > But if you then press return in the entry box with that same file, it > comes out of gtk_file_chooser_get_filename() as actual utf8, where I > might have expected latin1. (This is with gtk 2.12.11 and glib 2.18.4 > at least.) So I'm more confused than ever ... It's been a long time since I looked into this, it seems to work better than I thought. I modified your test script to test a few more functions. It seems the biggest problem is that all functions return strings with the utf8 flag on when it should always be off. But the folder/filename returned can be used to open a file/folder (checked with -e $filename). I haven't tested the functions that use a uri, they can probably be used to work around these encoding bugs. I can't understand why I didn't think of using them when I first met this bug :) set_current_folder : doesn't work set_filename : works get_filename : works get_filenames : works get_current_folder : works get_preview_filename : doesn't work note that I modified the test script to create the test file in a test folder that also has a utf8-invalid name. Also I changed the invalid character from \xff to \xf3, because with \xff I get crashes when selecting the test file in the test folder. \xff is probably pretty rare. Hm, doing some more tests I got a few crashes with \xf3 too, so it's not only with \xff. I can provide more details about the crashes if you can't reproduce it. > > impossible to use Gtk2::Gdk::Pixbuf->new_from_file with these files, > > Is it gperl_filename_from_sv() which is to blame? Or the return from > the chooser? > > For gdk_pixbuf_new_from_file() it does look like it'd be much better off > passing a raw byte string straight through, since the first thing that > func does is simply fopen(). > > (As opposed to currently where gperl_filename_from_sv() does an > "upgrade" with SvPVutf8() then immediately downgrade again with > g_filename_from_utf8().) I don't know XS, but yes, I think that is the problem. Quentin
Attachment:
foo2.pl
Description: Perl program