On 4/5/07, Federico Mena Quintero <[EMAIL PROTECTED]> wrote: > El jue, 29-03-2007 a las 09:52 +0200, Alexander Larsson escribió: > > On Wed, 2007-03-28 at 19:52 -0600, Federico Mena Quintero wrote: > > > > > > [Those functions don't normalize currently; maybe they need to... do you > > > have a reproducible bug?] > > > > NO! They should not normalize! Then you can't open a file that has an > > unnormalized filename. > > You mean > > 1. user types a UTF-8 filename to open it > 2. the app does g_filename_from_utf8() and gets normalized > 3. the file can't be opened because its filename on disk is not normalized > > ? > > But you would have to type the human-readable-filename in the first > place, whereas normally one picks the file from a list (in which case > there is no problem, since we know the filename-on-disk in advance). > > It *is* a problem for Save As (or anything that requires you to type a > possibly-existing filename), since the file dialog (or whatever) needs > to correlate the human-readable-filename with the filenames that are on > disk. I really don't know if GtkFileChooserEntry and the file chooser > in SAVE mode deal with this correctly. > > Denis, could you please test that case and file a bug against the file > chooser if it doesn't work?
The filechooser doesn't use the existing filename if what is typed is canonically equivalent, even if autocompletion gets it right. I had already opened http://bugzilla.gnome.org/show_bug.cgi?id=421736 and http://bugzilla.gnome.org/show_bug.cgi?id=423242 > [Alex is right; the functions shouldn't normalize out of the box, at > least not g_filename_from_utf8(). I don't really see a problem with > g_filename_to_utf8() normalizing for the app's benefit, although this > makes it more likely to uncover bugs with apps that try to round-trip > filenames.] _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
