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

[Shaun McCance <shaunm gnome org>]

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.

On top of that, there was a conversation a long while
back about the pain of migrating GConf settings when
your home directory changes locations. (Think of an
NFS setup where there are multiple mount points under
/home for separate NFS servers, and sysadmin moves you
to a different server.)

A possible solution is to store paths under your home
directory as relative paths, and when reading, assume
any relative paths are relative to your home directory.
Doing this with each individual application would be
tiresome and error-prone, but it would be easy with
a convenience API like this.

--
Shaun