Re: desktop schemas review [was: Re: GSettings migration status]

[Alexander Larsson <alexl redhat com>]

On Wed, 2010-07-07 at 08:04 -0400, A. Walton wrote:
> On Mon, Jul 5, 2010 at 10:06 PM, Russell Shaw <rjshaw netspace net au> wrote:
> > Alexander Larsson wrote:
> >>
> >> On Sat, 2010-07-03 at 13:25 -0400, Ryan Lortie wrote:
> >>>
> >>> On Sat, 2010-07-03 at 13:37 +0200, Christian Persch wrote:
> >>>>
> >>>> This is a common error. Filenames need to be stored as "ay" and *NOT*
> >>>> "s" (since "s" is UTF-8). (I think this needs some enhancement in
> >>>> glib-compile-schemas to be able to still put a string in <default>.)
> >>>
> >>> I'm not sure I buy into your hardline stance on this one.
> >>>
> >>> I think it's not unreasonable to require that all filenames specified in
> >>> the settings be in a valid encoding (whatever that encoding is) on their
> >>> own filesystem (where "in a valid encoding" means "converts correctly to
> >>> and from unicode").  In that case, utf8 is appropriate here.
> >>
> >> This is not right at all. Anything that does that is broken for two
> >> reasons:
> >>
> >> 1) Technically for unix all filenames are "valid" if they are byte
> >> strings without the characters zero and '/'. If you enforce anything
> >> else on your filenames there *will* be actual files on the system that
> >> you can't store references too. I've fixed soo many bugs from people
> >> thinking filenames are "utf8 strings", they are just not, they are byte
> >> arrays. This sucks, but its reality and we have to handle it.
> >>
> >> 2) Storing a "converted" pathname (for instance from filename encoding
> >> to utf8) is a bad idea, even if it succeeds. First of all, the encoding
> >> is runtime dependent (env vars) so may change over time, secondly
> >> roundtripping to unicode and back does not necessarily get you the same
> >> exact bytes back, so you might not be able to actually open the file.
> >>
> >> I've spent lots of work getting this right in e.g. gvfs, where raw
> >> filenames are G_FILE_ATTRIBUTE_TYPE_BYTE_STRING, but e.g.
> >> standard::display-name is G_FILE_ATTRIBUTE_TYPE_STRING. Please don't
> >> break this. Filenames are not unicode strings, they are byte array
> >> identifiers.
> >
> > Given that users may store file names in arbitrary encodings,
> > what is the best way to determine the encoding for display in
> > a file viewer?
> 
> We have an API for (almost) that, g_filename_display_name(). And
> round-tripping through GFile querying info for the display name
> attribute (standard::display-name) will do the same thing, in case
> that is more convenient for your piece of code (e.g. checking for file
> existence).

These are not quite the same. 

g_filename_display_name() checks the env vars, locale, etc and converts
a local file name to utf8.

standard::display-name is more generic. It will use
g_filename_display_name() for local files, but for other types of files
it may actually do i/o on the backend to figure out the real display
name based on e.g. remote encoding settings, display names in a database
backend, etc.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl redhat com            alexander larsson gmail com 
He's an obese ninja waffle chef fleeing from a secret government programme. 
She's a tortured green-skinned detective with the soul of a mighty warrior. 
They fight crime!