Re: normalizing filenames and strings



On 4/5/07, Federico Mena Quintero <federico ximian com> 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.]


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]