On Thu, 2009-02-26 at 08:18 +1100, Kevin Ryde wrote:
Quentin Sculo <squentin free fr> writes:FileChooserDialogIf 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