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

[Shaun McCance <shaunm gnome org>]

On Wed, 2010-07-07 at 20:58 +0200, Alexander Larsson wrote:
> 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.

Isn't g_file_get_path the local path as a byte stream? That's
the equivalent of what people are doing manually right now, I
think.

But if you provide an API with GFile, I suppose people will
expect to be able to hand it all sorts of GFiles, so storing
the URI would be preferable.

Either way, though, the API helps developers avoid storing
a byte string as a UTF-8 string, and we could provide the
zero-effort relative-to-home-directory thing.

(I think a generic relative-to-something-in-an-envar API
is overkill, and it's no longer zero-effort.)

--
Shaun