Re: Quotation marks: Using “” instead of ""
Le samedi 14 juin 2008 à 01:06 +0100, Bastien Nocera a écrit : > On Fri, 2008-06-13 at 18:01 -0400, Dan Winship wrote: > > Alan Cox wrote: > > > GTK/Glib are not the biggest problem here. You also use C library > > > functions in Gnome applications. Glib/Gtk+ works with the C library in C > > > locale simply because ASCII is a subset of UTF-8. That ceases to work the > > > moment you introduce UTF-8 bytesequences into non utf-8 locales. > > > > Are there actually legitimate reasons for anyone to ever use a non-UTF-8 > > locale these days? > > Other than legacy, and wanting to find bugs in programs? Probably not... Well, you need to discuss that with Chinese / Japanese and some Russian people ;) Non-UTF8 locales are still pretty common there. And I'm also thinking to people who upgraded their system from non-UTF8 locale system and don't want to see their file names become scrambled, because of the locale changes.. -- Frederic Crozat <[EMAIL PROTECTED]> Mandriva ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Quick question about requirements for [possible future] module maintainers
Module proposing procedure[1] requires an e-mail sent to desktop-devel-list, which naturally means subscribing to it, so one can answer any questions raised. The mailing list is quite active and most of discussions are irrelevant to the humble soul here. So I was just wondering, if it is ok to unsubscribe from it now, since discussions about my proposed module[2] have ended? Regards, Toms P.S. I hope this question will not be confused with unwillingness to be part of community or something - i'm keeping myself informed via planets'n'such [1] http://live.gnome.org/ReleasePlanning/ModuleProposing [2] That would be project hamster - http://projecthamster.wordpress.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Future of GNOME: Semantics
Hello Anders, Op zaterdag 14-06-2008 om 19:11 uur [tijdzone +0200], schreef Anders Feder: > Now, the idea is that if we model all of the aforementioned > abstractions (applications, mental models, smart devices etc.) in RDF, > GNOME can take advantage of the same features in a single unified > framework which, incidentally, is also compatible with the Semantic > Web (a very likely 'next step' for the current Web). [...] Thanks for bringing this up. Let me provide a little historical context for you, because ideas much like yours have been discussed as long ago as 2004: http://curtis.hovey.name/2004/01/28/medusa-rdf-and-redland/ http://times.usefulinc.com/2004/06/30-guadec (Unfortunately, the link to Edd's GUADEC 2004 talk seems to be dead now.) Hopefully, the time is more ripe now than it was back then. -- Reinout van Schouwen http://vanschouwen.info/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Quotation marks: Using “” instead of ""
On Sun, 15 Jun 2008 00:32:05 +0100
> gtk_label_new (_("this is a string with "" in it"));
Well firstly it is no longer C. You should be using \2xx\0xx or \xblah
encoding but that is a trivial side item to fix. Assuming you fix that it
obviously compiles and probably comes out ok in a .po file.
In LANG=C you call gtk_label_new with UTF-8 strings. What happens at that
point depends if gtk_label_new ever calls a single C library function
that is locale dependant (eg strcasecmp).
> Now explain how those problems are not caused by this
>
> gtk_label_new (_("this is a string with \"\" in it"));
>
> in the en_GB locale where gettext returns "this is a string with "" in it"
In the en_GB.utf-8 locale (there isn't a meaningful non UTF-8 GB locale)
you get gtk_label_new passing UTF-8 to the C library *but* unlike LANG=C
the library *expects* UTF-8 so will give correct answers for the locale.
Ditto en_US.utf-8.
Perhaps Havoc can definitively state whether than gtk function calls a
locale dependant C function at any point ?
Alan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Quotation marks: Using “” instead of ""
BTW: I realised last night there is another way to tackle this which lets you turn the problem on its head Given smart quotes directly in code are not valid C and that you need to distinguish different quotes so can't do a perl 1 liner turn the problem the other way up Source - with smart quotes String generation Extract with po file tools Rewrite this with a simple script Extracted string is en_US translation Base string has quotes substituted back Compile Remove smart quotes and replace with ordinary ones Compile with gcc (you could extract the translations from the converted file to save having to mend all the translations but that might actually be long term worse) Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Quotation marks: Using “” instead of ""
On Mon, Jun 16, 2008 at 12:24 PM, Alan Cox <[EMAIL PROTECTED]> wrote: > BTW: I realised last night there is another way to tackle this which lets > you turn the problem on its head > > Given smart quotes directly in code are not valid C and that you need to > distinguish different quotes so can't do a perl 1 liner turn the problem > the other way up > > Source - with smart quotes > >String generation >Extract with po file tools >Rewrite this with a simple script >Extracted string is en_US translation >Base string has quotes substituted back > >Compile >Remove smart quotes and replace with ordinary ones >Compile with gcc > > (you could extract the translations from the converted file to > save having to mend all the translations but that might actually be long > term worse) This would result in a thousand .c.in files or a large header .h.in file with all the strings ;) -- Patryk Zawadzki PLD Linux Distribution ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Quotation marks: Using “” instead of ""
> > (you could extract the translations from the converted file to > > save having to mend all the translations but that might actually be long > > term worse) > > This would result in a thousand .c.in files or a large header .h.in > file with all the strings ;) Not really. You just generate a temporary file in the CC=fix-and-gcc script or use a pipeline - conveniently enough the line numbers don't change so you don't need to keep the temporary file around. Anyway - disk is cheap 8) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Quick question about requirements for [possible future] module maintainers
Hi, Le lundi 16 juin 2008, à 09:56 +0100, Toms a écrit : > Module proposing procedure[1] requires an e-mail sent to > desktop-devel-list, which naturally means subscribing to it, so one > can answer any questions raised. > > The mailing list is quite active and most of discussions are > irrelevant to the humble soul here. > So I was just wondering, if it is ok to unsubscribe from it now, since > discussions about my proposed module[2] have ended? We expect discussion to heat up again about proposed modules at the beginning of july (see [1]). You don't have to be subscribed here, but I guess you'd want to be subscribed when this will be discussed again. (Note that you should be on devel-announce-list, which is lower traffic, so you can know what's relevant to you as a maintainer) [1] http://live.gnome.org/TwoPointTwentythree -- 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: Future of GNOME: Semantics
Mikkel, Thanks for your reply. man, 16 06 2008 kl. 00:52 +0200, skrev Mikkel Kamstrup Erlandsen: > To actually understand and use RDF and ontologies "correctly" you need > a lot of experience. There's a whole world of new terminology to > surmount before you can even begin to grasp what people talk about. I > know because I've tried to scale that wall myself (note _tried_ I > often feel that I've somehow failed). Triples and relations are just > scratching the surface of an iceberg. I would opt to use a metaphor that does not make people think of the sinking of Titanic and say that triples are the 'tip of the pyramid': elegantly simple structures with a solid, mathematical foundation. If the lower portion of the pyramid is made available as platform components, application developers would only need to worry about the tip of the pyramid. > Then just starting to include RDF here and there does not come for > free even though there are competent libs out there. It will take a > massive amount of work because most of the Gnome stack is not written > in a way as to take such things into account. I am not as experienced a GNOME developer as you are, but I beg to differ. Data structures equivalent to the triple are used throughout GNOME. Take the GConf database for instance: key (predicate) value (object) pairs organized in directories (subject). Namespace the subject and predicate properly and you have RDF. > Also we do have lots of integration in our stack (we could use more, > granted) and I actually think that it has worked relatively well so > far. And we can certainly get very very far without ever looking at > RDF and I sometimes find myself questioning what it really gives to > put the RDF rubber stamp on our tools. I mean the data models can > always be modelled by RDF no matter how we try to escape it, so in > some way it will always be a ghost in the machine. Is there are real > need to make this explicit? I have not seen any proof of this in the > wild. There's RDF and there's the Semantic Web. It will be an advantage to rely on ontologies already in use on the Semantic Web where possible, so we don't have to map back and forth too much at a later point. It will also be an advantage if developers rely on native RDF storage where applicable so we don't have to implement backends later on. > On a more humanistic note; there is some level of "technology scare" > of RDF amongst some developers. It might not be entirely justified, > and I don't think that it does anyone any good, but that is how it is. > Suddenly high-profiling it in a project where would very much like to > attract new devs might be dangerous. That doesn't mean we can't use it > though. I'n not sure how high-profile it would have to be. Maybe something similar to the Human Interface Guidelines with a few support libraries and services. > In conclusion I would like to make it clear that I don't have anything > against RDF or semantic technologies, I just have this great feeling > that once people get hooked on them every problem starts to look like > a semantic nail :-) That is perhaps not entirely untrue, but on the other hand, I don't think non-semantic nails are inherently better at all. It would have to be determined on a case-by-case basis. But such an evalution can only be made if the semantic alternative does in fact exist - hence these posts. -- Anders Feder <[EMAIL PROTECTED]> ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Quotation marks: Using “” instead of ""
On Sun, 2008-06-15 at 01:24 +0200, Patryk Zawadzki wrote: > On Sat, Jun 14, 2008 at 1:14 PM, Alexander Jones <[EMAIL PROTECTED]> wrote: > > 2008/6/14 Alan Cox <[EMAIL PROTECTED]>: > >> Note; I am all for the US locale using pretty quotes. I'm just strongly > >> opposed to doing it against the specifications and praying it works out. > >> Particularly when its probably a perl one liner to generate en_US.utf-8 > >> locale files. > > Wrong. "Pretty quotes" cannot be distinguished from straight quotes > > without language context. Consider some code that, e.g., generates XML > > output and requires straight quotes. Such a script would break that. > > (We see it already with Wordpress butchering people's pasted code.) > > Not that it has anything to do with GNOME but putting structural > markup (XML code) into translatable strings should seriously be > considered a bug. One mistranslation could easily make the application > unusable. We make extensive use of XML markup in the strings in gnome-doc-utils. While I agree this is less than ideal, it's currently the only way we can do the things we do. If an en_US locale automatically changed all the quotes, gnome-doc-utils would break pretty badly. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Future of GNOME: Semantics
Michael,
Thanks for your reply.
man, 16 06 2008 kl. 11:41 +, skrev
[EMAIL PROTECTED]:
> > Which are these existing applications? Can you give a few examples?
>
> Sorry, I thought I did - Evolution, Conduit, ?Tomboy - in passing.
Why would changing storage backends be a no-go for these applications?
It may be the sentiment of developers if its presented to them just
like that ("here is your new backend, now change"), but I don't see how
it would be structurally impossible or impractical for these
applications to rely on a different store?
> > Also, how is RDF overkill for new applications?
>
> Again, I was saying it would *seem* like overkill to the developers.
Ok. I wonder, then, why it would be perceived as such.
> Take Tomboy as an example. When starting out, had the developer had the
> choice, do you think he would have chosen an RDF store or still have
> used HTML in flat files?
Personally, I would probably have used HTML in flat files with metadata
annotations in the RDF store. I agree that RDF is not intended for
document markup.
> Because you're encoding more information, explicitly. ?For example, much
> of the semantics of an RFC 833 message is implicit its syntax, an RDF
> representation of that would include the semantics explicitly as well.
Isn't an RFC 822 message roughly just a list of key-value pairs?
Wouldn't these pairs map directly into predicate-object pairs in RDF?
> Cool! Are you suggesting Tracker as store? If not, why not? :)
Tracker would be a great candidate for a central RDF store. I don't know
if its developers agree though :)
> I see where you're coming from, but that has the same problem as the
> desktop search engines do at the moment - needing to write a parser for
> every format it needs to understand. Obviously, if Evo used RDF
> and ?Soprano directly then this won't be needed, but the problem with
> that is my whole thesis: RDF is too hard/inconvenient to be used as the
> primary storage model.
That is an interesting thesis because I think it summarize the sentiment
in the past few mails here and I personally still miss any evidence for
its truth.
> A decent helper library to assist implementing a D-Bus RDF interface
> that could be "bolted on", if possible, seems to be like a better way
> forward to my mind. I'd be willing to help implement such a thing, if
> that helps.
That sounds like a good idea to my ears - a generic backend interface of
some kind.
> Having pervasive RDF in the desktop would be awesome, the hard part is
> getting it there. :)
Definitely.
--
Anders Feder <[EMAIL PROTECTED]>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Quotation marks: Using “” instead of ""
On Mon, Jun 16, 2008 at 11:20 AM, Alan Cox <[EMAIL PROTECTED]> wrote: > In LANG=C you call gtk_label_new with UTF-8 strings. What happens at that > point depends if gtk_label_new ever calls a single C library function > that is locale dependant (eg strcasecmp). All of GTK is utf-8 compatible. This is the point we're trying to make. iain ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Quotation marks: Using “” instead of ""
Iain * wrote: > On Mon, Jun 16, 2008 at 11:20 AM, Alan Cox <[EMAIL PROTECTED]> wrote: >> In LANG=C you call gtk_label_new with UTF-8 strings. What happens at that >> point depends if gtk_label_new ever calls a single C library function >> that is locale dependant (eg strcasecmp). > > All of GTK is utf-8 compatible. > This is the point we're trying to make. I"m increasingly mystified by this discussion. Lots of people use non-UTF8 locales - most of the people I know send iso-8859-15 emails and when I send UTF8 emails they end up seeing €¥ or whatever instead of é. I can imagine that lots of Linux users use non-UTF8 locales for their UI. I don't know if there are any stats for this, but a couple of people working with distributions have said so. Alan's made a reasonable argument that we shouldn't be using non-ascii in C source files. It's not standard. He's made a reasonable argument that in the case where a string is untranslated, or the user chooses the C locale, the output string will be the input string, and if the input string is non-ASCII UTF-8, then strange and unexpected things will happen. This is starting to sound to me like change for change's sake. I don't see any decent reason to make the change (other than the "proper" quotes look better, even if they're harder to type), and credible people have pointed out a significant potential for breakage in a change like this. Prudence suggests backing down and letting the subject drop would be the best course of action. If there are UTF8 strings being passed to gettext currently, perhaps that's the problem that needs to be fixed. Cheers, Dave. -- Dave Neary GNOME Foundation member [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Quotation marks: Using “” instead of ""
On Mon, 2008-06-16 at 18:59 +0200, Dave Neary wrote:
> Iain * wrote:
> > On Mon, Jun 16, 2008 at 11:20 AM, Alan Cox <[EMAIL PROTECTED]> wrote:
> >> In LANG=C you call gtk_label_new with UTF-8 strings. What happens at that
> >> point depends if gtk_label_new ever calls a single C library function
> >> that is locale dependant (eg strcasecmp).
> >
> > All of GTK is utf-8 compatible.
> > This is the point we're trying to make.
>
> I"m increasingly mystified by this discussion.
>
> Lots of people use non-UTF8 locales - most of the people I know send
> iso-8859-15 emails and when I send UTF8 emails they end up seeing €¥ or
> whatever instead of é.
The header for the email you just sent has this:
Content-Type: text/plain; charset="utf-8"
Any mail client that tries to interpret your email as ISO-8859-1
is simply broken. Things like web sites and email specify their
character encoding, precisely because not everybody is using the
same one. When you get an email from me, regardless of your
character encoding, the email is to be interpreted as UTF-8.
This, of course, has nothing to do with UTF-8 strings being
passed to GTK+.
> I can imagine that lots of Linux users use
> non-UTF8 locales for their UI. I don't know if there are any stats for
> this, but a couple of people working with distributions have said so.
>
> Alan's made a reasonable argument that we shouldn't be using non-ascii
> in C source files. It's not standard. He's made a reasonable argument
> that in the case where a string is untranslated, or the user chooses the
> C locale, the output string will be the input string, and if the input
> string is non-ASCII UTF-8, then strange and unexpected things will happen.
Input to GTK+ functions is defined to be UTF-8. Always,
regardless of a user's character encoding. That's the
point Iain has been making. When you have this:
gtk_label_new (_("foo"));
The output of the _ function had better be UTF-8, because
that's what GTK+ is going to treat it as. If the input
is non-ASCII, the worst case scenario is that _ returns
the input, because it's untranslated. If that non-ASCII
input is UTF-8, we're golden, because that's what GTK+
wants.
Again, *regardless of the user's locale*, the input to
gtk_label_new is UTF-8. There is *never* any confusion
about what gets passed to gtk_label_new.
I very much doubt any of us are taking these strings
and passing them anywhere they don't belong. They're
being used as simple keys. If we do anything with the
strings, we do it with the translated strings, which
means we have to use UTF-8-capable functions anyway.
All of that means that there are no run-time problems.
The only actual concern is whether compilers will choke
on UTF-8 source files. Alan says that, according to the
standard, a compiler would be perfectly right to choke.
I believe him. I also don't care.
> This is starting to sound to me like change for change's sake. I don't
> see any decent reason to make the change (other than the "proper" quotes
> look better, even if they're harder to type), and credible people have
> pointed out a significant potential for breakage in a change like this.
They don't just look better. They're easier to read.
What's more, they're correct. And if we could get over
this barrier, maybe we could start using proper dashes.
Good typography makes text more legible.
--
Shaun
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Quotation marks: Using “” instead of ""
On Mon, 16 Jun 2008 17:48:31 +0100 "Iain *" <[EMAIL PROTECTED]> wrote: > On Mon, Jun 16, 2008 at 11:20 AM, Alan Cox <[EMAIL PROTECTED]> wrote: > > In LANG=C you call gtk_label_new with UTF-8 strings. What happens at that > > point depends if gtk_label_new ever calls a single C library function > > that is locale dependant (eg strcasecmp). > > All of GTK is utf-8 compatible. > This is the point we're trying to make. UTF-8 compatible is not the same thing as 'can feed utf-8 to the code when in a non UTF-8 locale' Glibc is UTF-8 compatible but it will give you the wrong answers if you feed UTF-8 data to it in a non-utf8 locale. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Quotation marks: Using “” instead of ""
On Mon, Jun 16, 2008 at 7:11 PM, Alan Cox <[EMAIL PROTECTED]> wrote: > On Mon, 16 Jun 2008 17:48:31 +0100 > "Iain *" <[EMAIL PROTECTED]> wrote: > >> On Mon, Jun 16, 2008 at 11:20 AM, Alan Cox <[EMAIL PROTECTED]> wrote: >> > In LANG=C you call gtk_label_new with UTF-8 strings. What happens at that >> > point depends if gtk_label_new ever calls a single C library function >> > that is locale dependant (eg strcasecmp). >> >> All of GTK is utf-8 compatible. >> This is the point we're trying to make. > > UTF-8 compatible is not the same thing as 'can feed utf-8 to the code > when in a non UTF-8 locale' > > Glibc is UTF-8 compatible but it will give you the wrong answers if you > feed UTF-8 data to it in a non-utf8 locale. Alan, seriously. You know exactly what I mean. GTK functions only accept UTF-8 data. They work perfectly when you pass them UTF-8 data no matter what your locale. iain ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Quotation marks: Using “” instead of ""
> All of that means that there are no run-time problems. > The only actual concern is whether compilers will choke > on UTF-8 source files. Alan says that, according to the > standard, a compiler would be perfectly right to choke. > I believe him. I also don't care. I don't think that one is a show stopper because if you can guarantee the rest will not break C provides you with \ escapes so you can paste the string in that way. So the question is the one about feeding utf-8 to glibc functions and internal cleanness of gtk/glib (eg what C library dependancies does it have). Having to use \ escapes for the quotes is a trivial inconvenience. > They don't just look better. They're easier to read. > What's more, they're correct. And if we could get over > this barrier, maybe we could start using proper dashes. > Good typography makes text more legible. Agreed - my concerns are to do it right, not whether it should be done. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Quotation marks: Using “” instead of ""
Am Montag, den 16.06.2008, 18:59 +0200 schrieb Dave Neary: > Iain * wrote: > > On Mon, Jun 16, 2008 at 11:20 AM, Alan Cox <[EMAIL PROTECTED]> wrote: > >> In LANG=C you call gtk_label_new with UTF-8 strings. What happens at that > >> point depends if gtk_label_new ever calls a single C library function > >> that is locale dependant (eg strcasecmp). > > > > All of GTK is utf-8 compatible. > > This is the point we're trying to make. > > I"m increasingly mystified by this discussion. > > Lots of people use non-UTF8 locales - most of the people I know send > iso-8859-15 emails and when I send UTF8 emails they end up seeing €¥ or > whatever instead of é. I can imagine that lots of Linux users use > non-UTF8 locales for their UI. I don't know if there are any stats for > this, but a couple of people working with distributions have said so. > > Alan's made a reasonable argument that we shouldn't be using non-ascii > in C source files. It's not standard. He's made a reasonable argument > that in the case where a string is untranslated, or the user chooses the > C locale, the output string will be the input string, and if the input > string is non-ASCII UTF-8, then strange and unexpected things will happen. > > This is starting to sound to me like change for change's sake. I don't > see any decent reason to make the change (other than the "proper" quotes > look better, even if they're harder to type), and credible people have > pointed out a significant potential for breakage in a change like this. > > Prudence suggests backing down and letting the subject drop would be the > best course of action. If there are UTF8 strings being passed to gettext > currently, perhaps that's the problem that needs to be fixed. Also to consider: It should be trivial to modify intltool to automatically generate en_* message catalogs which use the proper quotation marks. This approach is much more compatible, requires less change and has a much greater chance for success, wide adoption and consistency. Just a little story to support my consistency claim: I once did a program targeting mainly German users, so I decide to use German as message-id language. Well, and I had serious problems to consistently use proper quotation marks: You always have to use those primitive ASCII quotation marks in the C code, and they are more trivial to type. So in the end quotation mark usage was rather random. Also when taking the approach of tool support further it is easy to imagine, to use that code to verify consistent quotation mark usage in message catalogs. So I'd say: Keep the source code ASCII clean - love it or hate it, but C is specified to be ASCII only (despite the fact, that gcc seems to be 8-bit safe). Ciao, Mathias -- Mathias Hasselmann <[EMAIL PROTECTED]> Openismus GmbH: http://www.openismus.com/ Personal Site: http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Quotation marks: Using “” instead of ""
On Mon, 2008-06-16 at 19:51 +0100, Alan Cox wrote: > > All of that means that there are no run-time problems. > > The only actual concern is whether compilers will choke > > on UTF-8 source files. Alan says that, according to the > > standard, a compiler would be perfectly right to choke. > > I believe him. I also don't care. > > I don't think that one is a show stopper because if you can guarantee the > rest will not break C provides you with \ escapes so you can paste the > string in that way. So the question is the one about feeding utf-8 to > glibc functions and internal cleanness of gtk/glib (eg what C library > dependancies does it have). Having to use \ escapes for the quotes is a > trivial inconvenience. Well, as I said, in this case: gtk_label_new(_(some_string)); The output of gettext can (and often will) be UTF-8, so gtk_label_new is going to receive UTF-8 whether some_string is ASCII or not. If it's not UTF-8-safe, we're pretty much screwed already. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Quotation marks: Using “” instead of ""
On Mon, 2008-06-16 at 19:41 +0100, Iain * wrote: > On Mon, Jun 16, 2008 at 7:11 PM, Alan Cox <[EMAIL PROTECTED]> wrote: > > On Mon, 16 Jun 2008 17:48:31 +0100 > > "Iain *" <[EMAIL PROTECTED]> wrote: > > > >> On Mon, Jun 16, 2008 at 11:20 AM, Alan Cox <[EMAIL PROTECTED]> wrote: > >> > In LANG=C you call gtk_label_new with UTF-8 strings. What happens at that > >> > point depends if gtk_label_new ever calls a single C library function > >> > that is locale dependant (eg strcasecmp). > >> > >> All of GTK is utf-8 compatible. > >> This is the point we're trying to make. > > > > UTF-8 compatible is not the same thing as 'can feed utf-8 to the code > > when in a non UTF-8 locale' > > > > Glibc is UTF-8 compatible but it will give you the wrong answers if you > > feed UTF-8 data to it in a non-utf8 locale. > > Alan, seriously. You know exactly what I mean. GTK functions only > accept UTF-8 data. > They work perfectly when you pass them UTF-8 data no matter what your locale. Just to back this up: http://library.gnome.org/devel/gtk/stable/gtk-question-index.html#id2776084 -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Quotation marks: Using “” instead of ""
> Well, as I said, in this case:
>
> gtk_label_new(_(some_string));
>
> The output of gettext can (and often will) be UTF-8,
> so gtk_label_new is going to receive UTF-8 whether
> some_string is ASCII or not. If it's not UTF-8-safe,
> we're pretty much screwed already.
No no no
The output of _("blah") is "blah" for C locale, and "blah" should be
ASCII. You should only receive UTF-8 as the return from _("foo") in a
UTF-8 locale.
It isn't about being "UTF-8 safe" it is about "expecting UTF-8 in this
locale".
Alan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Quotation marks: Using “” instead of ""
> > They work perfectly when you pass them UTF-8 data no matter what your
> > locale.
>
> Just to back this up:
>
> http://library.gnome.org/devel/gtk/stable/gtk-question-index.html#id2776084
Cool - so for anything which doesn't touch the C library directly you can
write _("\xABCD") type stuff for smart quotes and be in spec (except for
the po tools which actually all seem entirely happy with utf-8 msgid).
That makes most of it much easier to do.
Alan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Quotation marks: Using “” instead of ""
On Mon, 2008-06-16 at 20:48 +0100, Alan Cox wrote:
> > Well, as I said, in this case:
> >
> > gtk_label_new(_(some_string));
> >
> > The output of gettext can (and often will) be UTF-8,
> > so gtk_label_new is going to receive UTF-8 whether
> > some_string is ASCII or not. If it's not UTF-8-safe,
> > we're pretty much screwed already.
>
> No no no
>
> The output of _("blah") is "blah" for C locale, and "blah" should be
> ASCII. You should only receive UTF-8 as the return from _("foo") in a
> UTF-8 locale.
>
> It isn't about being "UTF-8 safe" it is about "expecting UTF-8 in this
> locale".
If gettext is returning anything but UTF-8, we have
a lot of bugs in our application code. Because all
of us just pass that stuff off to GTK+, and GTK+
always expects UTF-8, regardless of the locale.
--
Shaun
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Quotation marks: Using “” instead of ""
On Mon, 2008-06-16 at 19:51 +0100, Alan Cox wrote: > > All of that means that there are no run-time problems. > > The only actual concern is whether compilers will choke > > on UTF-8 source files. Alan says that, according to the > > standard, a compiler would be perfectly right to choke. > > I believe him. I also don't care. > > I don't think that one is a show stopper because if you can guarantee the > rest will not break C provides you with \ escapes so you can paste the > string in that way. So the question is the one about feeding utf-8 to > glibc functions and internal cleanness of gtk/glib (eg what C library > dependancies does it have). Having to use \ escapes for the quotes is a > trivial inconvenience. One place that we have seen compilers choke is on Windows ... we used to have literal UTF-8 strings in the GTK+ sources, and on Chinese localized windows, that caused MSVC problems. So we switched to octal escapes. But it should be noted these problems were 4-5 years ago, and the versions of Windows and MSVC may have been much older. - Owen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Quotation marks: Using “” instead of ""
On Mon, 2008-06-16 at 15:18 -0500, Shaun McCance wrote:
> On Mon, 2008-06-16 at 20:48 +0100, Alan Cox wrote:
> > > Well, as I said, in this case:
> > >
> > > gtk_label_new(_(some_string));
> > >
> > > The output of gettext can (and often will) be UTF-8,
> > > so gtk_label_new is going to receive UTF-8 whether
> > > some_string is ASCII or not. If it's not UTF-8-safe,
> > > we're pretty much screwed already.
> >
> > No no no
> >
> > The output of _("blah") is "blah" for C locale, and "blah" should be
> > ASCII. You should only receive UTF-8 as the return from _("foo") in a
> > UTF-8 locale.
> >
> > It isn't about being "UTF-8 safe" it is about "expecting UTF-8 in this
> > locale".
>
> If gettext is returning anything but UTF-8, we have
> a lot of bugs in our application code. Because all
> of us just pass that stuff off to GTK+, and GTK+
> always expects UTF-8, regardless of the locale.
For how this is handled by glib and gtk+, see the man page for
bind_textdomain_codeset.
Not that there is any excuse to use something other than a UTF-8 local
these days.
- Owen
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Future of GNOME: Semantics
2008/6/16 Anders Feder <[EMAIL PROTECTED]>: > Mikkel, > > Thanks for your reply. > > man, 16 06 2008 kl. 00:52 +0200, skrev Mikkel Kamstrup Erlandsen: >> To actually understand and use RDF and ontologies "correctly" you need >> a lot of experience. There's a whole world of new terminology to >> surmount before you can even begin to grasp what people talk about. I >> know because I've tried to scale that wall myself (note _tried_ I >> often feel that I've somehow failed). Triples and relations are just >> scratching the surface of an iceberg. > > I would opt to use a metaphor that does not make people think of the > sinking of Titanic and say that triples are the 'tip of the pyramid': > elegantly simple structures with a solid, mathematical foundation. > > If the lower portion of the pyramid is made available as platform > components, application developers would only need to worry about the > tip of the pyramid. > >> Then just starting to include RDF here and there does not come for >> free even though there are competent libs out there. It will take a >> massive amount of work because most of the Gnome stack is not written >> in a way as to take such things into account. > > I am not as experienced a GNOME developer as you are, but I beg to > differ. Data structures equivalent to the triple are used throughout > GNOME. Take the GConf database for instance: key (predicate) value > (object) pairs organized in directories (subject). > > Namespace the subject and predicate properly and you have RDF. This is the exact point of one of my later paragraphs in my earlier mail. Why do we need to store it in an RDF store? We have a working data model, you can describe it in RDF, but why does it need to be stored in it too. Sounds a bit like rubber stamping for the sake of rubber stamping. I do however like the idea of "grafting it on" discussed in another branch of this thread. Apps should be free to store their data how they like. The argument for storing it in a real triple store is probably that we can launch SPARQL queries at it. To me that is equivalent of requiring everyone to store their data in a sql-database so we can throw SQL at it (except that SPARQL is the new hype (compared to SQL)). There are tonnes of reasons why this is not a good idea, I shall not elaborate on it here (that other people are thinking this too is evident from the fact that no single app I know of expose an SQL interface). >> Also we do have lots of integration in our stack (we could use more, >> granted) and I actually think that it has worked relatively well so >> far. And we can certainly get very very far without ever looking at >> RDF and I sometimes find myself questioning what it really gives to >> put the RDF rubber stamp on our tools. I mean the data models can >> always be modelled by RDF no matter how we try to escape it, so in >> some way it will always be a ghost in the machine. Is there are real >> need to make this explicit? I have not seen any proof of this in the >> wild. > > There's RDF and there's the Semantic Web. It will be an advantage to > rely on ontologies already in use on the Semantic Web where possible, so > we don't have to map back and forth too much at a later point. > > It will also be an advantage if developers rely on native RDF storage > where applicable so we don't have to implement backends later on. > >> On a more humanistic note; there is some level of "technology scare" >> of RDF amongst some developers. It might not be entirely justified, >> and I don't think that it does anyone any good, but that is how it is. >> Suddenly high-profiling it in a project where would very much like to >> attract new devs might be dangerous. That doesn't mean we can't use it >> though. > > I'n not sure how high-profile it would have to be. Maybe something > similar to the Human Interface Guidelines with a few support libraries > and services. > >> In conclusion I would like to make it clear that I don't have anything >> against RDF or semantic technologies, I just have this great feeling >> that once people get hooked on them every problem starts to look like >> a semantic nail :-) > > That is perhaps not entirely untrue, but on the other hand, I don't > think non-semantic nails are inherently better at all. It would have to > be determined on a case-by-case basis. But such an evalution can only be > made if the semantic alternative does in fact exist - hence these posts. To say something constructive I think that a more iterative approach should be taken to this if you seriously intend to pursue this. Make small comprehensible chunks that apps can implement so they don't have to go the whole way in one go. You have a lot of big-picture visions (here and on LGO), these are good to have, but you will also need to go down into the specifics. Define the dbus apis, ways to expose and exhange data. Concrete examples using this. Maybe some small Python examples (or what ever language suits you best) - while Python
Re: Future of GNOME: Semantics
Mikkel, Thanks for your reply. I knew I could count on you for criticism ;) man, 16 06 2008 kl. 22:37 +0200, skrev Mikkel Kamstrup Erlandsen: > This is the exact point of one of my later paragraphs in my earlier > mail. Why do we need to store it in an RDF store? We have a working > data model, you can describe it in RDF, but why does it need to be > stored in it too. Sounds a bit like rubber stamping for the sake of > rubber stamping. Ok, I see what is happening here now. We need to distinguish between 'a database specifically for RDF triples' and 'a SPARQL interface with several storage backends'. What I meant with an RDF store was the latter. Soprano is also an example of this sense. The advantage of a shared SPARQL interface is that we can make complex queries spanning several disparate databases such as "all e-mails from contacts in the group 'Work' in Pidgin". We can't do this without essentially reinventing RDF, and we can't do it with SQL either. > I do however like the idea of "grafting it on" discussed in another > branch of this thread. We're making progress :) > To say something constructive I think that a more iterative approach > should be taken to this if you seriously intend to pursue this. Make > small comprehensible chunks that apps can implement so they don't have > to go the whole way in one go. Sure, that's what I'm suggesting. As I stated in my initial post, it reflected a personal proposal for a way out of the desktop metaphor in the context of the recent posts of similar spirit on the future of GNOME. > You have a lot of big-picture visions (here and on LGO), these are > good to have, but you will also need to go down into the specifics. Mandatory remark: check ;) > Define the dbus apis, ways to expose and exhange data. Concrete > examples using this. Maybe some small Python examples (or what ever > language suits you best) - while Python may not be what Gnome will > (possibly) use in mainstream some working examples are much better at > spurring feedback and more traction than arm waiving. I'm already discussing the specifics with Sebastian Trüg and he sounds very positive about trying to implement what we come up with in Soprano (I didn't have to entice him with Python examples). We've been exploring a few ideas (see e.g. http://live.gnome.org/AndersFeder/SemanticSpace/BusTopology which defines a D-Bus API - the idea itself is now abandoned), but ultimately I can't (and shouldn't) pick the right solution for the whole community. There's a paragraph on the GNOME Love page reading "... make sure to get the opinion of the affected maintainers or the community because the project in question could have become obsolete, invalid or yet implemented with the passing of time." I appreciate the merits of running code, but constructive dialogue among the affected parties really has never hurt software development. > So the bottom line is - you need to do a heck of a lot of heavy > lifting and boring work for things to take off - and that over a very > long period of time. This is my experience from Xesam atleast. Posting > here is good, but don't expect ten people to join your band wagon just > like that :-) Michael Gratton has already proposed a next step for this project and even volunteered to possibly help out with some of it, so I think this path is quite productive. I really don't see what should keep people from joining up if they find the idea worthwhile. Best regards, -- Anders Feder <[EMAIL PROTECTED]> ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Future of GNOME: Semantics
On Mon, Jun 16, 2008 at 11:59:39PM +0200, Anders Feder wrote: > man, 16 06 2008 kl. 22:37 +0200, skrev Mikkel Kamstrup Erlandsen: > > So the bottom line is - you need to do a heck of a lot of heavy > > lifting and boring work for things to take off - and that over a very > > long period of time. This is my experience from Xesam atleast. Posting > > here is good, but don't expect ten people to join your band wagon just > > like that :-) > > Michael Gratton has already proposed a next step for this project and > even volunteered to possibly help out with some of it, so I think this > path is quite productive. I really don't see what should keep people > from joining up if they find the idea worthwhile. People who do stuff don't generally join because of an interesting idea. More when there is something to play with (code, examples). It is not about removing restrictions, but more about getting contributors. e.g. I have lots of stuff I'd like to work on. But don't always feel like it, lack of time, etc (this while I just do scripting stuff). -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
GNOME Showstopper Review
GNOME 2.22.3 Tarballs Due is on June 30 (see [1]), and we have some blocker bugs to fix for our stable branch. This list also includes 2.23 stuff at the end. Kudos to seb128 and cosimoc for their help! Reproduce, test, help out with patches! -andre EVOLUTION & FRIENDS http://bugzilla.gnome.org/show_bug.cgi?id=533122 Subject in message list does not match message preview This is a bug bringing the folder summary out of sync with the mbox file which is hard to fix for an average user. As far as I know, Srini is currently working on a fix. http://bugzilla.gnome.org/show_bug.cgi?id=528902 time zone handling insufficient Evolution has problems with displaying accepted meeting invitations in the correct timezone. A contributed patch is available and hopefully Chen will review this quickly. The patch requires an API extension (not API change). GNOME-PANEL http://bugzilla.gnome.org/show_bug.cgi?id=504600 Crash in handle_cached_dir_changed There has not been a single report coming from GNOME 2.22 so far, so this may not be a blocker anymore. http://bugzilla.gnome.org/show_bug.cgi?id=515948 clock window not shown if e-d-s has not authenticated to google calendar If a google calendar exists in Evolution and one clicks on the time in the clock applet, it hangs because google calendar is not available unless evo authenticates it. Very annoying, no patch available yet. In general, Google calendar support in Evolution is quite buggy and there are several bug reports dealing with issues. GVFS http://bugzilla.gnome.org/show_bug.cgi?id=524485 nautilus does not display samba shares for machines inside an ADS network This is a regression from 2.20.x. A patch is available and one commenter has stated that the patch fixed the issue for him. http://bugzilla.gnome.org/show_bug.cgi?id=529971 Restore from trash appears to do a file copy Restore from trash for local files appears to fallback on copy+delete instead of just moving the relevant files. This is a regression from 2.20 and a visible performance issue. HTTP://CRASH.GNOME.ORG (2.23 issue) Remember this one from 4 months ago? We still need a better http://crash.gnome.org integration; especially getting debug information from the distros so core files can be "decrypted" to stacktraces. I wonder whether Fernando will ever work on writing documentation for the distributions and defining a process. Crash.gnome.org already receives reports nobody looks at because they cannot be decrypted. We will lose even more user feedback if this doesn't get sorted out. GNOME GOALS for 2.23 A list of the few remaining modules that need to be patched to finally get some of our GNOME Goals done. Let's please everybody get this done in the next weeks for 2.23 to clean up our platform and finally drop some ancient dependencies. * http://live.gnome.org/GnomeGoals/PoLinguas : gtk+, atk * http://live.gnome.org/GnomeGoals/PoptGOption : alacarte, gnome-build, GnomePython * http://live.gnome.org/GtkPrintPort : gnome-python-desktop, anjuta, gnome-devel-docs (update), GnomePython * http://live.gnome.org/GioPort : PATCHES: bug-buddy, fusa, gtksourceview, libgweather TODO: alacarte, control-center, ekiga, gedit, gnome-applets, gnome-main-menu, gnome-media, gnome-python-desktop, gnome-utils, pygtk, pygtksourceview, seahorse-plugins, gtk+, sabayon, anjuta, gdl Changes/Fixes since the last review[2]: Fixed issues: 509600, 509620, 511172, 512894; 515777 fixed today. Not a blocker anymore (way less dups and no reports from 2.22): 446097, 446183, 463147, 471133 (for more information on showstopper reviews in general, see [3].) [1] http://live.gnome.org/TwoPointTwentythree [2] http://mail.gnome.org/archives/desktop-devel-list/2008-February/msg00055.html [3] http://live.gnome.org/Bugsquad/ShowstopperReviews -- mailto:[EMAIL PROTECTED] | failed http://www.iomc.de/ | http://blogs.gnome.org/aklapper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Future of GNOME: Semantics
Olav, tir, 17 06 2008 kl. 00:09 +0200, skrev Olav Vitters: > People who do stuff don't generally join because of an interesting idea. Then there is clearly more than one type of "people who do stuff". Best regards, -- Anders Feder <[EMAIL PROTECTED]> ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Future of GNOME: Semantics
Hi Anders,
On Mon, 2008-06-16 at 18:02 +0200, Anders Feder wrote:
> Why would changing storage backends be a no-go for these applications?
> It may be the sentiment of developers if its presented to them just
> like that ("here is your new backend, now change"), but I don't see how
> it would be structurally impossible or impractical for these
> applications to rely on a different store?
You're right, it wouldn't be impossible. Migrating to a new backend is
something that is certainly non-trivial and possibly a whole lot of
work, however. You would need to have a very convincing argument to do
so (and probably contribute a lot of code).
> > Again, I was saying it would *seem* like overkill to the developers.
>
> Ok. I wonder, then, why it would be perceived as such.
I think it is because RDF's model is abstract enough that for the first
time developers, much learning and ground work has to be done to make it
useful.
> Personally, I would probably have used HTML in flat files with metadata
> annotations in the RDF store. I agree that RDF is not intended for
> document markup.
Ahh, this is how Yet Another blog engine I'm writing works. :)
> Isn't an RFC 822 message roughly just a list of key-value pairs?
> Wouldn't these pairs map directly into predicate-object pairs in RDF?
Yes, but then some header field values have additional structure that
should be represented, the ordering of the headers can be important so
you need to track that (maybe using a RDFS Seq) and messages with MIME
bodies should have that represented. As I said, it's just a hunch, I'll
check it out after my exams.
> Tracker would be a great candidate for a central RDF store. I don't know
> if its developers agree though :)
Aww, Jamie didn't think it would be suitable for my blog engine,
either. :) Wasn't the plan to use Tracker for Epiphany's bookmarks and
history? Is the problem that of storing arbitrary RDF?
> That is an interesting thesis because I think it summarize the sentiment
> in the past few mails here and I personally still miss any evidence for
> its truth.
It's about complexity, and people's tendency to try to minimise it.
Using the file system is at least an order of magnitude less complex
than a service for storing your data in terms of implementation, testing
and bugfixing. Using the native model for your data is similarly less
complex than converting it to something else, as is keeping your
metadata and data together vs splitting it up.
So to be successful, something to minimise this complexity is needed -
probably some code (he says, while providing none). How are the KDE guys
doing it? They're using Soprano, but how do apps get data into it, out
of it and keep it sync'ed? What programming interfaces are available for
K developers?
/Mike
--
✌ Michael Gratton. Geeknik since 1976.
✇
Gnome Games 2.23.4
gnome-games 2.23.4 == Gnibbles: - Improved AI search algorithm. Solves AI problems with level 15 (ais523) - Fix problem where worms crash on the starting square of dead worms (ais523) Gnometris: - code clean up (Jason Clinton) - fix compiler warnings (Jason Clinton) Sudoku: - code clean up (Jason Clinton) Translations: - ar: Djihed Afifi - de: Mario Blättermann - ru: Aleksandr Burobin ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Future of GNOME: Semantics
On Tue, Jun 17, 2008 at 12:37:35AM +0200, Anders Feder wrote: > Olav, > > tir, 17 06 2008 kl. 00:09 +0200, skrev Olav Vitters: > > People who do stuff don't generally join because of an interesting idea. > > Then there is clearly more than one type of "people who do stuff". Not sure why you respond like this, especially if you snip the stuff I responded to, which included your remark: | I really don't see what should keep people from joining up if they | find the idea worthwhile. as a reply to: | Posting here is good, but don't expect ten people to join your band | wagon just like that :-) You saw my remark as an attack or something? -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
