Re: desktop schemas review [was: Re: GSettings migration status]
- From: Alexander Larsson <alexl redhat com>
- To: Shaun McCance <shaunm gnome org>
- Cc: Christian Persch <chpe gnome org>, GNOME, Desktop Development List <desktop-devel-list gnome org>
- Subject: Re: desktop schemas review [was: Re: GSettings migration status]
- Date: Wed, 07 Jul 2010 20:58:23 +0200
On Wed, 2010-07-07 at 10:01 -0400, Shaun McCance wrote:
> On Mon, 2010-07-05 at 10:43 +0200, 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.
> Perhaps we should add some convenience API to GSettings.
> GFile * g_settings_get_file (GSettings *settings,
> const gchar *key);
> gboolean g_settings_set_file (GSettings *settings,
> const gchar *key,
> GFile *file);
> If this API insisted on the type being "ay", it would
> encourage developers to do the right thing.
Well, the serialization form of a GFile is a uri, and uris are ascii
strings. So, in this case "ay" is not needed. However, that doesn't mean
an API like this is not useful.
Alexander Larsson Red Hat, Inc
alexl redhat com alexander larsson gmail com
He's a deeply religious one-eyed cyborg who knows the secret of the alien
invasion. She's an elegant cigar-chomping Valkyrie fleeing from a Satanic
cult. They fight crime!
] [Thread Prev