Re: desktop schemas review [was: Re: GSettings migration status]
hi On Wed, 2010-07-07 at 15:15 -0400, Shaun McCance wrote: 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. I think this is getting ridiculous. As it stands, I made recent modifications to GVariant, adding support for 'bytestring's (which are arrays of bytes 'ay') and 'bytestring arrays'. GVariant * g_settings_new_bytestring (const gchar *); const gchar * g_settings_get_bytestring (GVariant *); There's currently no GSettings convenience API for those, but I could add it if there are requests. I doubt I will ever add an API for GFile. Storing a filename into GSettings isn't done *that* often, and when it is done there are clearly very different ideas about the way it should be done. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: desktop schemas review [was: Re: GSettings migration status]
On Mon, Jul 5, 2010 at 10:06 PM, Russell Shaw rjs...@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). -A. Walton ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: desktop schemas review [was: Re: GSettings migration status]
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 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: desktop schemas review [was: Re: GSettings migration status]
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. The traditional Unix way to deal with such paths is to base them off an environment variable so g_settings_set_relative_file(settings, key, envvar, path); eg g_settings_set_relative_file(settings, mbox, HOME, mbox); Then you have the fun that $HOME/mbox is a perfectly valid actual filename so you need to know what you are looking at, or store files in a smarter way. Apple take this even further with removable media so that it knows about paths on a removable device by the device name and relative path. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: desktop schemas review [was: Re: GSettings migration status]
On Sat, Jul 3, 2010 at 7:37 AM, Christian Persch c...@gnome.org wrote: -- org.gnome.desktop.url-handlers.gschema.xml: This should be a settings list, with a base schema for the enabled, exec and needs-terminal keys; actually the same base schema as the default-applications schemas above. I agree about this being a list, but I am actually thinking about moving the app-lookup into gio itself (currently, it is implemented in gvfs using gconf, via an extension point). If I do that, the schema should live in glib, I think. See https://bugzilla.gnome.org/show_bug.cgi?id=623723 Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: desktop schemas review [was: Re: GSettings migration status]
On Wed, 2010-07-07 at 15:24 +0100, Alan Cox wrote: 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. The traditional Unix way to deal with such paths is to base them off an environment variable so g_settings_set_relative_file(settings, key, envvar, path); eg g_settings_set_relative_file(settings, mbox, HOME, mbox); Then you have the fun that $HOME/mbox is a perfectly valid actual filename so you need to know what you are looking at, or store files in a smarter way. Apple take this even further with removable media so that it knows about paths on a removable device by the device name and relative path. GVfs metadata does something similar based on mount uuids etc. However, doing something like that makes a simple set a pathname setting operation into a possibly blocking (maybe hanging on NFS or suchlike) operation, so it is not something to do lightly or automatically. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's an ungodly Catholic cowboy moving from town to town, helping folk in trouble. She's a chain-smoking wisecracking angel from aristocratic European stock. They fight crime! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: desktop schemas review [was: Re: GSettings migration status]
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 LarssonRed Hat, Inc al...@redhat.comalexander.lars...@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! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: desktop schemas review [was: Re: GSettings migration status]
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 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: desktop schemas review [was: Re: GSettings migration status]
On Wed, 2010-07-07 at 08:04 -0400, A. Walton wrote: On Mon, Jul 5, 2010 at 10:06 PM, Russell Shaw rjs...@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 LarssonRed Hat, Inc al...@redhat.comalexander.lars...@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! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: desktop schemas review [was: Re: GSettings migration status]
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 LarssonRed Hat, Inc al...@redhat.comalexander.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
Re: desktop schemas review [was: Re: GSettings migration status]
On Wed, 2010-07-07 at 10:23 -0400, Matthias Clasen wrote: On Sat, Jul 3, 2010 at 7:37 AM, Christian Persch c...@gnome.org wrote: -- org.gnome.desktop.url-handlers.gschema.xml: This should be a settings list, with a base schema for the enabled, exec and needs-terminal keys; actually the same base schema as the default-applications schemas above. I agree about this being a list, but I am actually thinking about moving the app-lookup into gio itself (currently, it is implemented in gvfs using gconf, via an extension point). If I do that, the schema should live in glib, I think. See https://bugzilla.gnome.org/show_bug.cgi?id=623723 Very much ack. And then we can drop the gvfs part and the extension point. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a shy Catholic Green Beret living undercover at Ringling Bros. Circus. She's a brilliant mute femme fatale from aristocratic European stock. They fight crime! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: desktop schemas review [was: Re: GSettings migration status]
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. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a fiendish albino gentleman spy trapped in a world he never made. She's a blind blonde Hell's Angel from a family of eight older brothers. They fight crime! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: desktop schemas review [was: Re: GSettings migration status]
On Sun, 2010-07-04 at 00:10 +0100, James Sharpe wrote: Might I suggest that you take the opportunity at this point to extend the schema to at least consider support for multiple desktops / monitors. One of the difficulties that I found when looking at this in GSOC a few years back was that there was no way of supporting use of schemas when you had a dynamic number of items that needed the same configuration (e.g. background/screen0, background/screen1 etc), If this functionality is still not available with GSettings shouldn't it be put on the list of things to be addressed for the future? There are two ways of doing this I can see. Using the same schema with multiple paths or making the keys dictionaries. -- Danielle Madeley Software Developer, Collabora Ltd. Melbourne, Australia www.collabora.co.uk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: desktop schemas review [was: Re: GSettings migration status]
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? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
desktop schemas review [was: Re: GSettings migration status]
Hi; I think we should use the opportunity of converting to gsettings to redesign the desktop schemas, not just do a 1:1 translation from gconf. Let me make some remarks about the gsettings desktop schemas as they right now are in gsettings-desktop-schemas module. org.gnome.desktop.background.gschema.xml.in: key name=picture-options enum=org.gnome.desktop.GDesktopBackgroundStyle default'zoom'/default summaryPicture Options/summary descriptionDetermines how the image set by wallpaper_filename is rendered. Possible values are none, wallpaper, centered, scaled, stretched, zoom, spanned./description /key I don't think we need to enumerate all choices in the description here. With gsettings, the valid values are stored in the schema via the enum, so this is unnecessary work for translators, and superflous. Coincidentally, taking a look at all the summary and description strings, it seems to me that once these value enumerations are taken out, not too much remains that justifies the split between two strings. IMHO we should consider dropping summary from gschema and only provide for the one description strings. key name=picture-filename type=s default'@datadir@/pixmaps/backgrounds/gnome/background-default.jpg'/default summaryPicture Filename/summary descriptionFile to use for the background image./description /key 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.) key name=picture-opacity type=i range min=0 max=100/ default100/default summaryPicture Opacity/summary descriptionOpacity with which to draw the background picture./description /key IMHO, should be a d with range min=0.0 max=1.0 instead. Also, I wonder if all the picture-* keys should be inside a child schema here. --- org.gnome.desktop.default-applications.gschema.xml: Looks like this should use a settings list, with a base schema containing exec, needs-term (should be needs-terminal as below) keys, and an extended schema for the browser settings adding the nremote key. key name=exec type=s default'mozilla'/default summaryDefault browser/summary descriptionDefault browser for all URLs./description /key I wonder if we should support as as argv here, instead. Also, whether this should be ay (or aay) since technically, programme names need not be UTF-8. --- org.gnome.desktop.interface.gschema.xml: Looks ok, but maybe the keys could be named more consistently. --- org.gnome.desktop.lockdown.gschema.xml: I wonder if this schema should simply contain a flag setting, instead of several boolean lockdown settings? -- org.gnome.desktop.url-handlers.gschema.xml: This should be a settings list, with a base schema for the enabled, exec and needs-terminal keys; actually the same base schema as the default-applications schemas above. --- org.gnome.system.proxy.gschema.xml: Should use a settings list for the various (http/https/ftp/socks) proxies. Maybe the developers working on GIO proxy support could look at this schema and see if it maps nicely to what their code supports ? key name=host type=s default''/default summaryHTTP proxy host name/summary descriptionThe machine name to proxy HTTP through./description /key key name=port type=i range min=0 max=65535/ default8080/default summaryHTTP proxy port/summary descriptionThe port on the machine defined by /system/proxy/http/host that you proxy through./description /key IMHO this is _one_ setting that belongs together, as a (sq) tuple (string, uint16). - Finally, I'd like to suggest that gsettings-desktop-schemas install a header file containing #define's for each schema ID, schema, path and all the key names. Regards, Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: desktop schemas review [was: Re: GSettings migration status]
Hi, Le samedi 03 juillet 2010, à 13:37 +0200, Christian Persch a écrit : Hi; I think we should use the opportunity of converting to gsettings to redesign the desktop schemas, not just do a 1:1 translation from gconf. Let me make some remarks about the gsettings desktop schemas as they right now are in gsettings-desktop-schemas module. Thanks, it's good that someone takes time to review the schemas! I merely converted them so people couldn't use the excuse we don't have them yet to not port their code to GSettings ;-) On a general note: I think you should feel free to commit most of your proposed changes. org.gnome.desktop.background.gschema.xml.in: key name=picture-options enum=org.gnome.desktop.GDesktopBackgroundStyle default'zoom'/default summaryPicture Options/summary descriptionDetermines how the image set by wallpaper_filename is rendered. Possible values are none, wallpaper, centered, scaled, stretched, zoom, spanned./description /key I don't think we need to enumerate all choices in the description here. With gsettings, the valid values are stored in the schema via the enum, so this is unnecessary work for translators, and superflous. Agree. Coincidentally, taking a look at all the summary and description strings, it seems to me that once these value enumerations are taken out, not too much remains that justifies the split between two strings. IMHO we should consider dropping summary from gschema and only provide for the one description strings. Hrm, I don't know; I can't think of any major objection right now, except that we're used to this way ;-) Ryan, what's your opinion? key name=picture-filename type=s default'@datadir@/pixmaps/backgrounds/gnome/background-default.jpg'/default summaryPicture Filename/summary descriptionFile to use for the background image./description /key 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.) Ryan? key name=picture-opacity type=i range min=0 max=100/ default100/default summaryPicture Opacity/summary descriptionOpacity with which to draw the background picture./description /key IMHO, should be a d with range min=0.0 max=1.0 instead. Works for me. Also, I wonder if all the picture-* keys should be inside a child schema here. They probably should, indeed. --- org.gnome.desktop.default-applications.gschema.xml: Looks like this should use a settings list, with a base schema containing exec, needs-term (should be needs-terminal as below) keys, and an extended schema for the browser settings adding the nremote key. key name=exec type=s default'mozilla'/default summaryDefault browser/summary descriptionDefault browser for all URLs./description /key I wonder if we should support as as argv here, instead. IMHO, the sane thing to do here is to store .desktop filenames instead of what we do right now. Also, whether this should be ay (or aay) since technically, programme names need not be UTF-8. --- org.gnome.desktop.interface.gschema.xml: Looks ok, but maybe the keys could be named more consistently. --- org.gnome.desktop.lockdown.gschema.xml: I wonder if this schema should simply contain a flag setting, instead of several boolean lockdown settings? Does it really make things easier? -- org.gnome.desktop.url-handlers.gschema.xml: This should be a settings list, with a base schema for the enabled, exec and needs-terminal keys; actually the same base schema as the default-applications schemas above. Nod. --- org.gnome.system.proxy.gschema.xml: Should use a settings list for the various (http/https/ftp/socks) proxies. Nod. Maybe the developers working on GIO proxy support could look at this schema and see if it maps nicely to what their code supports ? key name=host type=s default''/default summaryHTTP proxy host name/summary descriptionThe machine name to proxy HTTP through./description /key key name=port type=i range min=0 max=65535/ default8080/default summaryHTTP proxy port/summary descriptionThe port on the machine defined by /system/proxy/http/host that you proxy through./description /key IMHO this is _one_ setting that belongs together, as a (sq) tuple (string, uint16). Works for me. - Finally, I'd like to suggest that gsettings-desktop-schemas install a header file containing #define's for each schema ID, schema, path and all
Re: desktop schemas review [was: Re: GSettings migration status]
Le samedi 03 juillet 2010 à 13:37 +0200, Christian Persch a écrit : Hi; I think we should use the opportunity of converting to gsettings to redesign the desktop schemas, not just do a 1:1 translation from gconf. Let me make some remarks about the gsettings desktop schemas as they right now are in gsettings-desktop-schemas module. I agree with most of your suggestions too. Just two remarks. snip Coincidentally, taking a look at all the summary and description strings, it seems to me that once these value enumerations are taken out, not too much remains that justifies the split between two strings. IMHO we should consider dropping summary from gschema and only provide for the one description strings. In the case of these schemas, I think you're right, but in general the split is really needed. Consider for example this Metacity key, which is only one example among many others: key name=resize-with-right-button type=b defaultfalse/default summaryWhether to resize with the right button/summary description Set this to true to resize with the right button and show a menu with the middle button while holding down the key given in mouse-button-modifier; set it to false to make it work the opposite way around. /description /key If only one string was provided, it would be a pain to find what a key is supposed to do without reading the full description. And that's what makes the settings database more useful than a mere addition of binary values (for example, if we want a « plumbing tool » to tweak advanced settings, we need it to have short and useful summaries). Looks like this should use a settings list, with a base schema containing exec, needs-term (should be needs-terminal as below) keys, and an extended schema for the browser settings adding the nremote key. I've considered this too when reading the file, but in the end I was really not sure we gain anything with a list. GSettingsList is intended for schemas that will be extended at runtime, while here we have a list that is mostly set in stone. Apps only look for a known schema, and will never want to get the list of all registered applications, nor add an application to the list. So I don't think that's worth the complexity it would add Regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: desktop schemas review [was: Re: GSettings migration status]
On Sat, 2010-07-03 at 13:37 +0200, Christian Persch wrote: Finally, I'd like to suggest that gsettings-desktop-schemas install a header file containing #define's for each schema ID, schema, path and all the key names. I tried to discuss this on IRC because I believe it's a good idea. It's nice to have the compiler yell at you because you typed G_DESKTOP_BACKROUND instead of silently allowing org.gnome.desktop.backround. I was even considering one step farther, defining macros like: #define g_desktop_background_settings_new() - g_setting_new(...) That then leads to g_desktop_background_settings_get_style() macros and such. That might be going too far. Opinions? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: desktop schemas review [was: Re: GSettings migration status]
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. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: desktop schemas review [was: Re: GSettings migration status]
Hi; Am Sat, 03 Jul 2010 13:22:16 -0400 schrieb Ryan Lortie de...@desrt.ca: On Sat, 2010-07-03 at 13:37 +0200, Christian Persch wrote: Finally, I'd like to suggest that gsettings-desktop-schemas install a header file containing #define's for each schema ID, schema, path and all the key names. I tried to discuss this on IRC because I believe it's a good idea. It's nice to have the compiler yell at you because you typed G_DESKTOP_BACKROUND instead of silently allowing org.gnome.desktop.backround. Exactly. So let's do this :) I was even considering one step farther, defining macros like: #define g_desktop_background_settings_new() - g_setting_new(...) That then leads to g_desktop_background_settings_get_style() macros and such. That might be going too far. 'Too far' would be anything that makes this into a library instead of just a set of .h files. Anything less goes, as far as I'm concerned. Regards, Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: desktop schemas review [was: Re: GSettings migration status]
On Sat, 2010-07-03 at 13:37 +0200, Christian Persch wrote: Coincidentally, taking a look at all the summary and description strings, it seems to me that once these value enumerations are taken out, not too much remains that justifies the split between two strings. IMHO we should consider dropping summary from gschema and only provide for the one description strings. I'm of a mixed mind on this. On one hand I'm sort of sick of coming up with 3 strings (of slightly increasing verbosity) to describe my GObject properties and the same sort of logic comes into play here. On the other hand, I notice that the typical format for git commit messages is actually extremely helpful. Just because we presently don't have any tools that take advantage of the summary (ie: by showing it somewhere that the full description is not showing) doesn't mean that it's pointless as a concept. One thing I'd like to point to: https://bugzilla.gnome.org/show_bug.cgi?id=620562 The intention is that everything that interacts with the description will do whitespace handling similar to the way Owen described in the bug. As implemented, in intltool for example: description This is a description. Woo. Multiple paragraphs. /description will end up as This is a description.\n\nWoo. Multiple paragraphs. which should end up being shown reasonably well in UIs. ((note the folding of the spaces between Woo. and Multiple)) So as a matter of style, I recommend writing summary and description like so: key summaryThis is a short summary (50 char rule, anyone?)/summary description Even short one-paragraph descriptions should be done like this. Wrap at 72, please. /description /key Since we're discussing style, I'll also mention that I'm a fan of vertical whitespace and that each key should probably have a newline between: ... /key key name='next' type='s' ... and schemas definitely. Maybe even two newlines there. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: desktop schemas review [was: Re: GSettings migration status]
Hi; Am Sat, 03 Jul 2010 17:08:36 +0200 schrieb Milan Bouchet-Valat nalimi...@club.fr: Le samedi 03 juillet 2010 à 13:37 +0200, Christian Persch a écrit : Coincidentally, taking a look at all the summary and description strings, it seems to me that once these value enumerations are taken out, not too much remains that justifies the split between two strings. IMHO we should consider dropping summary from gschema and only provide for the one description strings. In the case of these schemas, I think you're right, but in general the split is really needed. Consider for example this Metacity key, which is only one example among many others: key name=resize-with-right-button type=b defaultfalse/default summaryWhether to resize with the right button/summary description Set this to true to resize with the right button and show a menu with the middle button while holding down the key given in mouse-button-modifier; set it to false to make it work the opposite way around. /description /key If only one string was provided, it would be a pain to find what a key is supposed to do without reading the full description. And that's what makes the settings database more useful than a mere addition of binary values (for example, if we want a « plumbing tool » to tweak advanced settings, we need it to have short and useful summaries). Makes sense. We should at least discourage schema writers from making the description just a reworded summary. Or, let's only have the one description string, and take the first line (paragraph?) of it as the summary, and any extra text as detail that will only be displayed in a tooltip, 'detailed info' area, etc. Like we do for our git commit messages :) Looks like this should use a settings list, with a base schema containing exec, needs-term (should be needs-terminal as below) keys, and an extended schema for the browser settings adding the nremote key. I've considered this too when reading the file, but in the end I was really not sure we gain anything with a list. GSettingsList is intended for schemas that will be extended at runtime, while here we have a list that is mostly set in stone. Apps only look for a known schema, and will never want to get the list of all registered applications, nor add an application to the list. So I don't think that's worth the complexity it would add I don't think it adds complexity, but reduces it. You only need to write the schema once, and then can just reference it and override its values (this is not in gsettings yet, but I think it's going to land soon?). Regards, Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: desktop schemas review [was: Re: GSettings migration status]
On Sat, 2010-07-03 at 19:48 +0200, Christian Persch wrote: Hi; Am Sat, 03 Jul 2010 17:08:36 +0200 schrieb Milan Bouchet-Valat nalimi...@club.fr: Le samedi 03 juillet 2010 à 13:37 +0200, Christian Persch a écrit : Coincidentally, taking a look at all the summary and description strings, it seems to me that once these value enumerations are taken out, not too much remains that justifies the split between two strings. IMHO we should consider dropping summary from gschema and only provide for the one description strings. In the case of these schemas, I think you're right, but in general the split is really needed. Consider for example this Metacity key, which is only one example among many others: key name=resize-with-right-button type=b defaultfalse/default summaryWhether to resize with the right button/summary description Set this to true to resize with the right button and show a menu with the middle button while holding down the key given in mouse-button-modifier; set it to false to make it work the opposite way around. /description /key If only one string was provided, it would be a pain to find what a key is supposed to do without reading the full description. And that's what makes the settings database more useful than a mere addition of binary values (for example, if we want a « plumbing tool » to tweak advanced settings, we need it to have short and useful summaries). Makes sense. We should at least discourage schema writers from making the description just a reworded summary. Or, let's only have the one description string, and take the first line (paragraph?) of it as the summary, and any extra text as detail that will only be displayed in a tooltip, 'detailed info' area, etc. Like we do for our git commit messages :) Isn't that somewhat betraying the idea of XML as a _structured_ representation of data? Philip ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: desktop schemas review [was: Re: GSettings migration status]
Hi; Am Sat, 03 Jul 2010 19:29:13 +0100 schrieb Philip Withnall phi...@tecnocode.co.uk: On Sat, 2010-07-03 at 19:48 +0200, Christian Persch wrote: Am Sat, 03 Jul 2010 17:08:36 +0200 schrieb Milan Bouchet-Valat nalimi...@club.fr: If only one string was provided, it would be a pain to find what a key is supposed to do without reading the full description. And that's what makes the settings database more useful than a mere addition of binary values (for example, if we want a « plumbing tool » to tweak advanced settings, we need it to have short and useful summaries). Makes sense. We should at least discourage schema writers from making the description just a reworded summary. Or, let's only have the one description string, and take the first line (paragraph?) of it as the summary, and any extra text as detail that will only be displayed in a tooltip, 'detailed info' area, etc. Like we do for our git commit messages :) Isn't that somewhat betraying the idea of XML as a _structured_ representation of data? True. So I'd settle for the style Ryan proposes in the other reply, and telling schema writers that it's ok to omit description if it would end up just being a slightly reworded summary. (As is the case in many current gconf schemas.) Regards, Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: desktop schemas review [was: Re: GSettings migration status]
On 3 July 2010 12:58, Vincent Untz vu...@gnome.org wrote: Hi, Le samedi 03 juillet 2010, à 13:37 +0200, Christian Persch a écrit : Hi; I think we should use the opportunity of converting to gsettings to redesign the desktop schemas, not just do a 1:1 translation from gconf. Let me make some remarks about the gsettings desktop schemas as they right now are in gsettings-desktop-schemas module. Thanks, it's good that someone takes time to review the schemas! I merely converted them so people couldn't use the excuse we don't have them yet to not port their code to GSettings ;-) Might I suggest that you take the opportunity at this point to extend the schema to at least consider support for multiple desktops / monitors. One of the difficulties that I found when looking at this in GSOC a few years back was that there was no way of supporting use of schemas when you had a dynamic number of items that needed the same configuration (e.g. background/screen0, background/screen1 etc), If this functionality is still not available with GSettings shouldn't it be put on the list of things to be addressed for the future? James ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
