On Mon, 2005-01-03 at 23:50 +0000, Tor Lillqvist wrote:
> BTW, for the case-preserving but case-insensitive Win32 file system,
> would it be a good idea to implement GtkFilePath as a pair of strings,
> one containing the g_utf8_casefolded path, the other the path in the
> original/desired case? (And thus not having to casefold over and over
> again when comparing, sorting, etc.)
>
> Or are there hard-to-change assumptions that GtkFilePath actually is
> char* all over the place? (If so, hmm, one could even have the pair of
> strings not as a struct, but concatenated as a single string with some
> illegal character as separator?)
Any assumptions about the internal structure of GtkFilePath are supposed
to be entirely within the macros. Nothing outside a particular
filesystem
should be converting filepaths to strings.
(Bug: a couple of places in gtkfilesystemdefault do that instead of
calling gtk_file_path_compare())
There is the assumption in some of the generic code that strcmp() on
the strings will give a consistent (but not user meaningful) ordering.
(gtk_file_path_compare(), gtk_file_paths_sort())
For win32, using paths that are:
<casefolded name>\0<non-casefolded name>
is certainly a possible solution to the problem. They should compare
and order correctly (*) and also be possible to retrieve the appropriate
display name from. (Does g_utf8_casefold() really use the right rules?
Does windows expose casefolding with the rules it uses for comparison
of filenames?)
The only real downside is excess storage.
Regards,
Owen
(*) Note that order correctly here doesn't mean user visible ordering,
just order consistently.
Attachment:
signature.asc
Description: This is a digitally signed message part