On Wed, 2010-07-07 at 15:15 -0400, Shaun McCance wrote: > 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.
Sure... > 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. Exactly. > 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. yeah -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc al...@redhat.com alexander.lars...@gmail.com He's a fiendish umbrella-wielding librarian with a passion for fast cars. She's a ditzy communist widow with her own daytime radio talk show. They fight crime! _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list