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
(L)GPLv3
hi Everyone, I recently received an email from a company in our ecosystem asking me to relicense a smallish piece of code from GPLv3 to (L)GPLv2. I'm not really interested in inciting a flamewar on the topic or anything, but I'm wondering how people feel, in general about the licensing direction of the GNOME project. 1) Go freedom-warrior GPLv3 style and make the world a better place (potentially at the cost of our own relevance). 2) Be pragmatic GPLv2 style and make the world a better place (potentially at the cost of reduced end-user freedoms). One thing in particular I want to mention is that I asked about this topic a couple of years ago in relation to Gtk and was told at that time that we can't reasonably relicense Gtk 2.0 since the licence could almost be considered as being part of the API/ABI contract. We have 3.0 upon us now, so I guess we should make a choice one way or another. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: (L)GPLv3
Le lundi 05 juillet 2010, à 10:48 -0400, Ryan Lortie a écrit : hi Everyone, I recently received an email from a company in our ecosystem asking me to relicense a smallish piece of code from GPLv3 to (L)GPLv2. I'm not really interested in inciting a flamewar on the topic or anything, but I'm wondering how people feel, in general about the licensing direction of the GNOME project. 1) Go freedom-warrior GPLv3 style and make the world a better place (potentially at the cost of our own relevance). 2) Be pragmatic GPLv2 style and make the world a better place (potentially at the cost of reduced end-user freedoms). One thing in particular I want to mention is that I asked about this topic a couple of years ago in relation to Gtk and was told at that time that we can't reasonably relicense Gtk 2.0 since the licence could almost be considered as being part of the API/ABI contract. We have 3.0 upon us now, so I guess we should make a choice one way or another. The current (unwritten, afaik) policy is (L)GPLv2+. It's worth thinking really hard before moving to LGPLv3 (at least; not sure about GPLv3): LGPLv3 is incompatible with GPLv2, according to the FSF; that's a major issue, and, IMHO, this doesn't go well with our philosophy of having our platform LGPL. (see http://gplv3.fsf.org/dd3-faq for the compatibility matrix) Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Converting libraries and plugins to use gtk3
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On 11/06/10 14:28, Alexander Larsson wrote: Any library that links to gtk+, gdk or gdk-pixbuf, that switches to gtk3 will need to have the new version be separate from and parallel installable with the old version. If this is not done then distributions can not ship applications still using gtk2 linking to the older version of the library, as this change is binary incompatible (and since you can't mix gtk2 and gtk3 in the same app). I'm sorry but may I ask for interpretation of the following text? I interpret that separate packages (as well as Gentoo developers responsible for GNOME packages) that it applies at package-level. However evolution-data-server developer(s)[1] thinks otherwise and believe it is sufficient if the only libraries linking to gtk+-3.0 (like libedataserverui-3.0.so) need the bumping and rest of packages bundled do not. It creates making a package harder, especially in source based distribution as it requires splitting package by hand and to resolve incompatibles between versions. Additionally one file (/usr/lib64/evolution-data-server-1.2/extensions/libecalbackendweather.so) have 2.x version (1.2) while linking to libgtk+-x11-3.0.so.0. Could anyone clarify (and reopen if appropriate) bug 623462[1]? Regards [1] https://bugzilla.gnome.org/show_bug.cgi?id=623463 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAwAGBQJMMg2IAAoJEJIdee2Vr4aP0CUP/0aP5KRVAjHH15Oh83M1A1vY BDWgvx2WjaWPXD5pth5s45yQmYq29YfBPSypMj8GGJ57y0Rz5kFLZtaA31Gli11s bOswBeoUS1cDIpLhACg95xhtAt7afFVt/F7BQ8xp2og6hP3p7KPUcgSvmRZY1B3y IBc0xX/7PMuvHCrM2zdjFwQcszoR1tkTMQqqTeF2RA+aVLry7f1y7VasnyzrqtvM rpt5aQxX5/fzlFO4VQeTa6qNYCajMAFyzjiknM6K1GL8B8CIoJ0h0JzhxfUH3q+V gCFRa17SKeuRoNZKMk+8ink4vg8KID+Ouckya7gNQH6Y6PZw3h+DBio6YbY3cpR5 fIMS4QIQkEK7fpFO75T9duPdPvykjVVkLI+4omBIdcRgugifs0g6gczE3Ai4lqCY gNr+IXau7MIclAA6Q1jJu5DEsGfEsx5p95BGWwNaFYP7oH/OorVQB5g2W0fL+8cP StaOiknxQ1OthaTdq5C/Cc7jtNIYdA/C+hfYI/oMnfsCFKtgLMsB2lEvHL9F005p wfEIS2Xgc5zsrvVIkFLh4IrQ1GjePfitqJfC4jsaWnJmFKp0ba2kb/wEUfruoqLa N3MyEPKunOXeWZzpKH5b8iQ5P2xJWQNrap+a25gl+9p4ySDUvtwrmobc7b4ZfmwR CSaJWKL63x2t2NpaGrG8 =0f0Q -END PGP SIGNATURE- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: (L)GPLv3
On Mon, 2010-07-05 at 17:18 +0200, Vincent Untz wrote: Le lundi 05 juillet 2010, à 10:48 -0400, Ryan Lortie a écrit : hi Everyone, I recently received an email from a company in our ecosystem asking me to relicense a smallish piece of code from GPLv3 to (L)GPLv2. I'm not really interested in inciting a flamewar on the topic or anything, but I'm wondering how people feel, in general about the licensing direction of the GNOME project. 1) Go freedom-warrior GPLv3 style and make the world a better place (potentially at the cost of our own relevance). 2) Be pragmatic GPLv2 style and make the world a better place (potentially at the cost of reduced end-user freedoms). One thing in particular I want to mention is that I asked about this topic a couple of years ago in relation to Gtk and was told at that time that we can't reasonably relicense Gtk 2.0 since the licence could almost be considered as being part of the API/ABI contract. We have 3.0 upon us now, so I guess we should make a choice one way or another. The current (unwritten, afaik) policy is (L)GPLv2+. It's worth thinking really hard before moving to LGPLv3 (at least; not sure about GPLv3): LGPLv3 is incompatible with GPLv2, according to the FSF; that's a major issue, and, IMHO, this doesn't go well with our philosophy of having our platform LGPL. (see http://gplv3.fsf.org/dd3-faq for the compatibility matrix) Maybe it's a good idea to discuss this issue in detail with Bradley M. Kuhn at GUADEC who will give a talk about GNU licenses v3 http://guadec.org/index.php/guadec/2010/paper/view/127 Cheers, -- Juanjo Marin ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: (L)GPLv3
hi Vincent, On Mon, 2010-07-05 at 17:18 +0200, Vincent Untz wrote: It's worth thinking really hard before moving to LGPLv3 (at least; not sure about GPLv3): LGPLv3 is incompatible with GPLv2, according to the FSF; that's a major issue, and, IMHO, this doesn't go well with our philosophy of having our platform LGPL. Just a note: the LGPLv3 is incompatible with GPLv2 not because of the LGPLv3 but because of the GPLv2 (which is incompatible with almost everything). I'm not sure this should be counted as a point against LGPLv3, in general. 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]
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
