You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(27) |
Jul
(25) |
Aug
(21) |
Sep
(136) |
Oct
(123) |
Nov
(87) |
Dec
(110) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(87) |
Feb
(88) |
Mar
(81) |
Apr
(255) |
May
(73) |
Jun
(96) |
Jul
(131) |
Aug
(94) |
Sep
(148) |
Oct
(171) |
Nov
(166) |
Dec
(172) |
| 2004 |
Jan
(251) |
Feb
(140) |
Mar
(213) |
Apr
(298) |
May
(182) |
Jun
(185) |
Jul
(159) |
Aug
(376) |
Sep
(334) |
Oct
(256) |
Nov
(217) |
Dec
(189) |
| 2005 |
Jan
(186) |
Feb
(151) |
Mar
(199) |
Apr
(115) |
May
(203) |
Jun
(228) |
Jul
(116) |
Aug
(189) |
Sep
(136) |
Oct
(198) |
Nov
(249) |
Dec
(339) |
| 2006 |
Jan
(167) |
Feb
(185) |
Mar
(95) |
Apr
(133) |
May
(86) |
Jun
(156) |
Jul
(149) |
Aug
(170) |
Sep
(208) |
Oct
(151) |
Nov
(270) |
Dec
(148) |
| 2007 |
Jan
(240) |
Feb
(127) |
Mar
(150) |
Apr
(40) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Sean E. <sea...@gm...> - 2007-02-03 21:33:55
|
On 2/3/07, Richard Laager <rl...@wi...> wrote: > I don't believe I ever heard back on this... Anyone have any opinions > before I try to tackle this? DO IT! Make INVALID_PASSWORD bring you to the modify account dialog. -s. |
|
From: Richard L. <rl...@wi...> - 2007-02-03 21:27:27
|
On Tue, 2007-01-16 at 11:50 -0500, Mark Doliner wrote: > On Tue, 16 Jan 2007 08:44:55 -0600, Richard Laager wrote > > When I startup Gaim and it connects my accounts, I'm seeing a dialog > > that says, "Could not add the buddy 1 for an unknown reason. The most > > common reason for this is that you have the maximum number of allowed > > buddies in your buddy list." > >=20 > > This happens for my ICQ account. I haven't added anyone to my blist > > recently. Any idea why I might be seeing this error, or how to track=20 > > it down? > It's related to buddy icons and family_feedbag.c. I'm not sure of the ex= act > cause. If I could reproduce it I could probably fix it. We've got bug reports of users hitting this as well: http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1642009&group_= id=3D235&atid=3D100235 http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1641580&group_= id=3D235&atid=3D100235 Is there anything I can do to help solve this? Richard |
|
From: Richard L. <rl...@wi...> - 2007-02-03 21:23:36
|
On Tue, 2006-11-07 at 00:01 -0600, Richard Laager wrote: > On Wed, 2006-10-25 at 12:36 -0400, Luke Schierer wrote: > > On Wed, Oct 25, 2006 at 11:30:23AM -0500, Richard Laager wrote: > > > Do we still want to be bringing up dialogs when you sign on from anot= her > > > location? It seems like showing that as a connection error in the bud= dy > > > list (which we do) is sufficient. Otherwise we have duplication. >=20 > > I would say the blist is sufficient. >=20 > I found a minute to look into this. Apparently, we display the error > dialog when wants_to_die is TRUE. I think it's proper to show an error > message when the connection has some other sort of fatal error, I just > don't want a bunch of dialogs if I sign in elsewhere. >=20 > The easiest way I can think of to change this would be to make > wants_to_die and enum, where 0 is still FALSE, 1 is still TRUE, but 2 is > AIGNED_ON_ELSEWHERE. I'd have to make sure we're not actually comparing t= o > TRUE directly, but otherwise this shouldn't break anything. It feels a > little weird. I guess the alternative is to add a parameter to > gaim_connection_error() or another field in GaimConnection. >=20 > A bigger change would be to introduce behavior where the account > wouldn't be disabled, but wouldn't be reconnected either. This actually > seems ideal in this situation. That way, I don't have to re-enable all > my accounts. >=20 > Taking it further, if I was signed in at location A, then signed in at > location B, then went back to location A and changed my status, we could > have Gaim reconnect the accounts at that time. >=20 > Thoughts? I don't believe I ever heard back on this... Anyone have any opinions before I try to tackle this? Richard |
|
From: Mark D. <ma...@ki...> - 2007-02-03 19:22:42
|
On Sat, 03 Feb 2007 12:56:17 +0000, Chris Stafford wrote > I'm more interested in the changing the reply-to issue, since I noticed > yesterday that our company mailing list script does just that, and still > can't decide if that's the right approach. Oh I think there's much more concensus that munging the reply-to header is bad. I'm pretty sure we won't be doing that. Well, except for the Gaim-commits mailing list, where we set reply-to to gaim-devel because Gaim-commits can only be posted to by our sourceforge accounts. -Mark |
|
From: Chris S. <gai...@no...> - 2007-02-03 12:56:36
|
Luke Schierer wrote: > On Fri, Feb 02, 2007 at 04:19:39PM -0500, Ethan Blanton wrote: > >> Mark Doliner spake unto us the following wisdom: >> >>> Sorry, I wrote the thing in like 15 minutes. So far 16 people prefer the full >>> header, 14 people prefer no header and 1 person prefers the short header. >>> >> I don't see how this is up for a vote. There is an obvious and >> technically correct solution to this, which is to elide such headers >> on all mailing lists, and allow those who want them to insert them. >> The URL that Sean posted explains this clearly. >> >> Ethan >> >> > > In that its a common practice, even if a less than correct. In that the > argument you and Sean posted is wrong in at least one respect. > > There are any number of people who could and would contribute useful and > even correct patches to gaim, but who could be turned off by our holding > to this practice, even though correct. While yes this ignorance, > willful or otherwise, is less than ideal, it is also beyond our ability > to cure, at least to cure in every case. > > Some of us are more concerned with finding the most pragmatic solution > than with the technically most correct one. The poll would help > determine this. > > While I tend to be persuaded by the arguments that you and Sean have > found and advanced, I really don't care. I'm just as capable as using > procmail to remove the tags as it is possible to use procmail to add > them, if they did bother me, which they mostly don't. > > If it looks like we will turn off more people from helping with gaim > than our correctness would attract, then some of us would seriously > consider putting up with the minor incorrectness. > > luke > With tags I can do a sort visually and very quickly, which will actually be based on the time I have available at that second rather than the way I felt when I wrote the rules (I only ever write email rules out of spite). I can even use the tags in webmail interfaces with no rules at all, which is pretty damn useful given the amount of time I spend in internet cafes. If you've got the access and inclination to use a rules-based system, write a rule to dump the tags. Simple. I'm more interested in the changing the reply-to issue, since I noticed yesterday that our company mailing list script does just that, and still can't decide if that's the right approach. chris |
|
From: Luke S. <lsc...@us...> - 2007-02-03 12:29:23
|
On Fri, Feb 02, 2007 at 04:19:39PM -0500, Ethan Blanton wrote: > Mark Doliner spake unto us the following wisdom: > > Sorry, I wrote the thing in like 15 minutes. So far 16 people prefer the full > > header, 14 people prefer no header and 1 person prefers the short header. > > I don't see how this is up for a vote. There is an obvious and > technically correct solution to this, which is to elide such headers > on all mailing lists, and allow those who want them to insert them. > The URL that Sean posted explains this clearly. > > Ethan > In that its a common practice, even if a less than correct. In that the argument you and Sean posted is wrong in at least one respect. There are any number of people who could and would contribute useful and even correct patches to gaim, but who could be turned off by our holding to this practice, even though correct. While yes this ignorance, willful or otherwise, is less than ideal, it is also beyond our ability to cure, at least to cure in every case. Some of us are more concerned with finding the most pragmatic solution than with the technically most correct one. The poll would help determine this. While I tend to be persuaded by the arguments that you and Sean have found and advanced, I really don't care. I'm just as capable as using procmail to remove the tags as it is possible to use procmail to add them, if they did bother me, which they mostly don't. If it looks like we will turn off more people from helping with gaim than our correctness would attract, then some of us would seriously consider putting up with the minor incorrectness. luke |
|
From: Ethan B. <ebl...@cs...> - 2007-02-02 21:19:42
|
Mark Doliner spake unto us the following wisdom: > Sorry, I wrote the thing in like 15 minutes. So far 16 people prefer the= full > header, 14 people prefer no header and 1 person prefers the short header. I don't see how this is up for a vote. There is an obvious and technically correct solution to this, which is to elide such headers on all mailing lists, and allow those who want them to insert them. The URL that Sean posted explains this clearly. Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 |
|
From: Mark D. <ma...@ki...> - 2007-02-02 21:06:15
|
On Fri, 2 Feb 2007 13:48:17 -0500, Luke Schierer wrote > On Fri, Feb 02, 2007 at 12:24:30PM -0500, Mark Doliner wrote: > > Hi! We're debating whether we should keep the short little [gaim-commits] > > header thing at the beginning of the subject line in emails sent through this > > mailing list. > > > > Could every single person on this list please go to > > http://kingant.net/gaimpoll/ > > and vote for your preference? Thanks! > > > > -Mark > > > > You aren't showing running results!! > > luke Sorry, I wrote the thing in like 15 minutes. So far 16 people prefer the full header, 14 people prefer no header and 1 person prefers the short header. -Mark |
|
From: Sean E. <sea...@gm...> - 2007-02-02 20:13:56
|
On 2/2/07, Sean Egan <sea...@gm...> wrote: > Becaues democracy only works with informed voters: > http://www.andrew.cmu.edu/user/qralston/writing/tagging-harmful/ That might make totally no sense to the people on this list, which brings up: http://www.unicom.com/pw/reply-to-harmful.html :) If you don't know what this is about, you can ignore it ;) -s. |
|
From: Sean E. <sea...@gm...> - 2007-02-02 20:12:22
|
Becaues democracy only works with informed voters: http://www.andrew.cmu.edu/user/qralston/writing/tagging-harmful/ |
|
From: Luke S. <lsc...@us...> - 2007-02-02 16:59:27
|
On Fri, Feb 02, 2007 at 11:43:40AM -0500, Mark Doliner wrote: > On Fri, 2 Feb 2007 10:31:17 -0500, Luke Schierer wrote > > I am not debating the potential usefullness of Network Manager > > integration. > > > > However, someone needs to be maintaining it. It is decidedly buggy. > > A quick glance at our tracker reveils bugs 1650380, 1649500, > > 1648433, 1641894 and 1603919. I know there are also bugs relating > > to it in the debian and ubuntu trackers. It has also caused non- > > trivial numbers of bug reports in #gaim. Some of these are just > > annoyances of varying severity, others are crashes. > > > > If no one wants to take & fix these bugs, we ought to seriously consider > > pulling or disabling the nm code until such a time as someone wants > > to take care of it. > > > > luke > > Can we have it disabled by default and add a "(buggy)" note to ./configure --help? > > -Mark > That's fine, it will effectively stop innocent unsuspecting users from hitting its bugs. :-) luke |
|
From: Mark D. <ma...@ki...> - 2007-02-02 16:43:28
|
On Fri, 2 Feb 2007 10:31:17 -0500, Luke Schierer wrote > I am not debating the potential usefullness of Network Manager > integration. > > However, someone needs to be maintaining it. It is decidedly buggy. > A quick glance at our tracker reveils bugs 1650380, 1649500, > 1648433, 1641894 and 1603919. I know there are also bugs relating > to it in the debian and ubuntu trackers. It has also caused non- > trivial numbers of bug reports in #gaim. Some of these are just > annoyances of varying severity, others are crashes. > > If no one wants to take & fix these bugs, we ought to seriously consider > pulling or disabling the nm code until such a time as someone wants > to take care of it. > > luke Can we have it disabled by default and add a "(buggy)" note to ./configure --help? -Mark |
|
From: Luke S. <lsc...@us...> - 2007-02-02 15:32:46
|
I am not debating the potential usefullness of Network Manager integration. However, someone needs to be maintaining it. It is decidedly buggy. A quick glance at our tracker reveils bugs 1650380, 1649500, 1648433, 1641894 and 1603919. I know there are also bugs relating to it in the debian and ubuntu trackers. It has also caused non-trivial numbers of bug reports in #gaim. Some of these are just annoyances of varying severity, others are crashes. If no one wants to take & fix these bugs, we ought to seriously consider pulling or disabling the nm code until such a time as someone wants to take care of it. luke |
|
From: Daniel A. <dan...@gm...> - 2007-02-01 13:41:19
|
On 2/1/07, Luke Schierer <lsc...@us...> wrote: > This user cannot get guifications to load with beta6, can anyone help > him? > > luke > > ----- Forwarded message from Tom George <tho...@no...> ----- > Here is the log when I open the plugin window: > It syas guifications and perl cannot be found, but they are both there with the correct name. > plugins: probing C:\Program Files\Gaim\plugins\guifications.dll > plugins: C:\Program Files\Gaim\plugins\guifications.dll is not loadable: The specified module could not be found. The GTK+ 2.10.7 runtime that is distributed with 2.0.0beta6 is not compatible with guifications. Check this out: http://gaim.guifications.org/trac/ticket/306#comment:5 -D |
|
From: Luke S. <lsc...@us...> - 2007-02-01 12:42:30
|
This user cannot get guifications to load with beta6, can anyone help him? luke ----- Forwarded message from Tom George <tho...@no...> ----- Date: Thu, 1 Feb 2007 11:34:55 +0100 From: Tom George <tho...@no...> To: Luke Schierer <lsc...@us...> Subject: RE: beta 6 and gnufications beta 6 Here is the log when I open the plugin window: It syas guifications and perl cannot be found, but they are both there wi= th the correct name. I include guifications.dll for good measure plugins: probing C:\Program Files\Gaim\plugins\autoaccept.dll plugins: probing C:\Program Files\Gaim\plugins\autoreply.dll plugins: probing C:\Program Files\Gaim\plugins\buddynote.dll plugins: probing C:\Program Files\Gaim\plugins\convcolors.dll plugins: probing C:\Program Files\Gaim\plugins\extplacement.dll plugins: probing C:\Program Files\Gaim\plugins\gaimrc.dll plugins: probing C:\Program Files\Gaim\plugins\guifications.dll plugins: C:\Program Files\Gaim\plugins\guifications.dll is not loadable: = The specified module could not be found. plugins: probing C:\Program Files\Gaim\plugins\history.dll plugins: probing C:\Program Files\Gaim\plugins\iconaway.dll plugins: probing C:\Program Files\Gaim\plugins\idle.dll plugins: probing C:\Program Files\Gaim\plugins\libaim.dll plugins: probing C:\Program Files\Gaim\plugins\libgg.dll plugins: probing C:\Program Files\Gaim\plugins\libicq.dll plugins: probing C:\Program Files\Gaim\plugins\libirc.dll plugins: probing C:\Program Files\Gaim\plugins\libjabber.dll plugins: probing C:\Program Files\Gaim\plugins\libmsn.dll plugins: probing C:\Program Files\Gaim\plugins\libnovell.dll plugins: probing C:\Program Files\Gaim\plugins\libqq.dll plugins: probing C:\Program Files\Gaim\plugins\libsametime.dll plugins: probing C:\Program Files\Gaim\plugins\libsilc.dll plugins: probing C:\Program Files\Gaim\plugins\libsimple.dll plugins: probing C:\Program Files\Gaim\plugins\libyahoo.dll plugins: probing C:\Program Files\Gaim\plugins\log_reader.dll plugins: probing C:\Program Files\Gaim\plugins\markerline.dll plugins: probing C:\Program Files\Gaim\plugins\newline.dll plugins: probing C:\Program Files\Gaim\plugins\notify.dll plugins: probing C:\Program Files\Gaim\plugins\offlinemsg.dll plugins: probing C:\Program Files\Gaim\plugins\perl.dll plugins: C:\Program Files\Gaim\plugins\perl.dll is not loadable: The spec= ified module could not be found.=20 TommyG (=E5=AF=8C)=20 -----Original Message----- From: Luke Schierer [mailto:lsc...@us...]=20 Sent: Wednesday, 31 January, 2007 10:42 PM To: George, Tom (CTF:6258) Subject: Re: beta 6 and gnufications beta 6 On Wed, Jan 31, 2007 at 09:30:25PM +0100, Tom George wrote: > Its not there at all. By the way it=E2=80=99s the win32 implementation >=20 >=20 > TommyG (=E5=AF=8C) Then you will need to use the debug window. Turn it on and then restart = gaim. It should open right from the start. I suggest you do this with n= o accounts enabled, to reduce the output. Scroll up in the output, till it is probing the plugins, and find where i= t probes guifications. If it is not in the list, then it seems likely that guifications is not i= nstalled to the right location. luke >=20 >=20 > -----Original Message----- > From: Luke Schierer [mailto:lsc...@us...] > Sent: Wednesday, 31 January, 2007 9:02 PM > To: George, Tom (CTF:6258) > Subject: Re: beta 6 and gnufications beta 6 >=20 > On Wed, Jan 31, 2007 at 08:34:14PM +0100, Tom George wrote: > > I installed and then reinstalled both version. some how I cannot get = gnufications to appear in the plugin list. the DLL is in the right place = .... > > =20 > > but nothing... > > =20 > > Any idea? > > =20 > > Thomas GEORGE (=E5=AF=8C) >=20 > In the plugins list, is it telling you anything about why it cannot loa= d? It should be there, but grayed out. >=20 > luke >=20 ----- End forwarded message ----- |
|
From: Richard L. <rl...@wi...> - 2007-01-31 20:21:04
|
On Wed, 2007-01-17 at 08:54 -0500, Luke Schierer wrote: > Below is a bug report issued early this morning. It suggests that > config files and cached data be moved to conform to some freedesktop.org > idea. Presumably this is an attempt to clean up the mess of dot files > in ~/ I figured I'd bring this up here so that the idea gets noticed. >=20 > Naturally we'd have to detect and move the old config stuff if present. I don't like this. It makes it harder to synchronize ~/.gaim between computers (which is more of an issue for Gaim than many other applications). It also doesn't map well to our win32 port. Richard |
|
From: dolphinling <dol...@my...> - 2007-01-31 19:44:02
|
I recently upgraded from 1.5 to 2.0b6 and still have the preference set to show the number of new messages received in the window title of any inactive window. I've noticed though that sometimes this number is shown and sometimes it isn't. I narrowed it down to when someone starts typing again, the number goes away (but when they send the message, it comes back and is updated appropriately). I'd put this in the sourceforge bug tracker, but it's down at the moment. -- dolphinling <http://dolphinling.net/> |
|
From: Luke S. <lsc...@us...> - 2007-01-30 15:28:19
|
I am not sure what is going on here, so I am passing it on to our devel list in hopes that someone there can help you. On Tue, Jan 30, 2007 at 01:45:04AM -0800, Cristina Dumitrache wrote: > Dear Sir, > I understood from the help of gaim, that you could > help me! > I have a problem! I've changed the password from my > yahoo account, and now I have problem with messenger > through swissjabber.ch! > I can open the window but at yahoo.swissjabber.ch > write unauthorised,error 502 unavailable srvice,sender > (in waiting)! > I hope you we'll be not very upset of me for my mail! > > Best regard, > Cristina Dumitrache > > > > > > ____________________________________________________________________________________ > Now that's room service! Choose from over 150,000 hotels > in 45,000 destinations on Yahoo! Travel to find your fit. > http://farechase.yahoo.com/promo-generic-14795097 > |
|
From: Fredrik T. <fr...@do...> - 2007-01-30 11:19:54
|
On Tue, 2007-01-09 at 01:06 +0100, Fredrik Tolf wrote: > On Fri, 2007-01-05 at 13:25 -0500, Nathan Walp wrote: > > Fredrik Tolf wrote: > > <snip> > > > While I'm at it with chat rooms, though: I also have a slight cosmetic > > > problem where the room list window displays the listing as still being > > > generated, even though I call gaim_roomlist_set_in_progress(..., FALSE). > > > Could it be related to that I call it while still being in the > > > roomlist_get_list callback? (I already have the list in memory, so > > > there's no need for me to do I/O to generate the room list.) > > > > I just made a commit that should fix this. Let me know if it doesn't. > > I don't run Gaim from SVN (or is it CVS?), so I'll take your word for it > for now, and get back if it doesn't work when Gentoo pushes the next > release on me. I just thought I'd report back on this. I got beta6 through Gentoo's portage, and it works now. Thanks! Fredrik Tolf |
|
From: Ethan B. <ebl...@cs...> - 2007-01-29 20:06:50
|
James Lockie spake unto us the following wisdom:
> # Try and decode message
> try:
> msg =3D message.decode('utf8')
> except:
> self.log("DecodeError: Could not decode utf8 '%s', trying ISO=
8$
>=20
> try:
> msg =3D message.decode('iso-8859-1')
Note that ISO-8859-1, specifically, should never fail to deocode, as
it uses all 256 codepoints. This is not true of all encodings
(particularly multibyte encodings).
Glad to hear it works for you.
Ethan
--=20
The laws that forbid the carrying of arms are laws [that have no remedy
for evils]. They disarm only those who are neither inclined nor
determined to commit crimes.
-- Cesare Beccaria, "On Crimes and Punishments", 1764
|
|
From: James L. <bjl...@lo...> - 2007-01-29 06:07:01
|
Ethan Blanton wrote:
> James Lockie spake unto us the following wisdom:
> =20
>> Ethan Blanton wrote:
>> =20
>>> It most certainly can. B, j, r, and k are represented by their ASCII
>>> values, and =F6 can be represented in several ways; this email contai=
ns
>>> =F6 in UTF-8 as U+00F6, which UTF-8 represents as 0xc3 0xb6.
>>> =20
>> Ah, the string is probably something other than UTF8.
>> I get it thanks.
>>
>> I think I did this right :-)
>> '426c656564696e6720576f726473206279204d6f62696c65' =3D 'Bleeding Words=
by=20
>> Mobile'
>> =20
>
> Yes, this string is all ASCII -- I assume it works.
>
> =20
>> '69742773206f6820736f20717569657420627920426af6726b' =3D 'it's oh so q=
uiet
>> =20
> ^^ =F6 in ISO-8859-{1,15=
}
> =20
>> by Bj=F6rk'
>> =20
>
> So, if Amarok isn't telling you what encoding these strings are (and I
> suspect it is, when it can tell itself, but some annotations, such as
> id3v1, do not have encoding tags), your best bet is probably to simply
> try whatever encoding you expect to be most common, and fall back on
> replacement of the invalid characters if that doesn't work. Something
> like:
>
> if (g_utf8_validate passes)
> use the string as is
> else if (g_convert from ISO-8859-1 works)
> use the conversion
> else
> gaim_utf8_salvage it
>
> We use this sort of tactic in several places in Gaim, where strings
> come in that are of some unknown encoding.
>
> Ethan
Thank you so much.
I did
# Try and decode message
try:
msg =3D message.decode('utf8')
except:
self.log("DecodeError: Could not decode utf8 '%s', trying ISO=
8$
try:
msg =3D message.decode('iso-8859-1')
except:
self.log("DecodeError: Could not decode '%s'" % message)
return
which is what you suggested and it works now.
|
|
From: Ethan B. <ebl...@cs...> - 2007-01-28 22:03:45
|
James Lockie spake unto us the following wisdom:
> Ethan Blanton wrote:
> > It most certainly can. B, j, r, and k are represented by their ASCII
> > values, and =F6 can be represented in several ways; this email contains
> > =F6 in UTF-8 as U+00F6, which UTF-8 represents as 0xc3 0xb6.
>
> Ah, the string is probably something other than UTF8.
> I get it thanks.
>=20
> I think I did this right :-)
> '426c656564696e6720576f726473206279204d6f62696c65' =3D 'Bleeding Words by=
=20
> Mobile'
Yes, this string is all ASCII -- I assume it works.
> '69742773206f6820736f20717569657420627920426af6726b' =3D 'it's oh so quiet
^^ =F6 in ISO-8859-{1,15}
> by Bj=F6rk'
So, if Amarok isn't telling you what encoding these strings are (and I
suspect it is, when it can tell itself, but some annotations, such as
id3v1, do not have encoding tags), your best bet is probably to simply
try whatever encoding you expect to be most common, and fall back on
replacement of the invalid characters if that doesn't work. Something
like:
if (g_utf8_validate passes)
use the string as is
else if (g_convert from ISO-8859-1 works)
use the conversion
else
gaim_utf8_salvage it
We use this sort of tactic in several places in Gaim, where strings
come in that are of some unknown encoding.
Ethan
--=20
The laws that forbid the carrying of arms are laws [that have no remedy
for evils]. They disarm only those who are neither inclined nor
determined to commit crimes.
-- Cesare Beccaria, "On Crimes and Punishments", 1764
|
|
From: James L. <bjl...@lo...> - 2007-01-28 19:12:27
|
Ethan Blanton wrote:
> James Lockie spake unto us the following wisdom:
> =20
>> James Lockie wrote:
>> =20
>>> Sean Egan wrote:
>>> =20
>>>> I'm sure Amarok provides a mechanism for knowing the
>>>> encoding of the strings it gives you
>>>> =20
>>> I have asked on the Amarok maiing list what string format Amarok is=20
>>> returning. :-)
>>> =20
>>> =20
>> I took out the decode and it works for strings without special=20
>> characters but I get this error for "Bj=F6rk":
>> message.append(signature=3Dintrospect_sig, *args)
>> UnicodeError: String parameters to be sent over D-Bus must be valid UT=
F-8
>>
>> My guess is Amarok is NOT sending utf8 but decode works for some of th=
e=20
>> strings but utf8 for other strings. :-(
>> I'll figure it out. :-)
>> =20
>
> I'm guessing Amarok is not sending UTF-8 for *any* of its strings, but
> those strings which happen to contain only characters in the ASCII
> range are validating as UTF-8. (ASCII strings are valid UTF-8, and
> will display correctly.) Any strings which contain extended ISO-Latin
> characters (e.g., =F6) are probably in some locale-specific charset
> (most likely ISO-8859-1 or ISO-8859-15) and are thus failing
> validation.
>
> Try taking a byte dump of the string you're trying to use, and see if
> it doesn't say {0x42, 0x6a, 0xf6, 0x72, 0x6b}. This is the
> representation of "Bj=F6rk" in ISO-8859-{1,15}.
>
> =20
>> I was told "Bj=F6rk" can be represented by utf8 but that doesn't seem =
to=20
>> be the case.
>> =20
>
> It most certainly can. B, j, r, and k are represented by their ASCII
> values, and =F6 can be represented in several ways; this email contains
> =F6 in UTF-8 as U+00F6, which UTF-8 represents as 0xc3 0xb6.
Ah, the string is probably something other than UTF8.
I get it thanks.
I think I did this right :-)
'426c656564696e6720576f726473206279204d6f62696c65' =3D 'Bleeding Words by=
=20
Mobile'
'69742773206f6820736f20717569657420627920426af6726b' =3D 'it's oh so quie=
t=20
by Bj=F6rk'
|
|
From: Ethan B. <ebl...@cs...> - 2007-01-28 17:22:48
|
James Lockie spake unto us the following wisdom:
> James Lockie wrote:
> > Sean Egan wrote:
> >> I'm sure Amarok provides a mechanism for knowing the
> >> encoding of the strings it gives you
> >
> > I have asked on the Amarok maiing list what string format Amarok is=20
> > returning. :-)
> > =20
> I took out the decode and it works for strings without special=20
> characters but I get this error for "Bj=F6rk":
> message.append(signature=3Dintrospect_sig, *args)
> UnicodeError: String parameters to be sent over D-Bus must be valid UTF-8
>=20
> My guess is Amarok is NOT sending utf8 but decode works for some of the=
=20
> strings but utf8 for other strings. :-(
> I'll figure it out. :-)
I'm guessing Amarok is not sending UTF-8 for *any* of its strings, but
those strings which happen to contain only characters in the ASCII
range are validating as UTF-8. (ASCII strings are valid UTF-8, and
will display correctly.) Any strings which contain extended ISO-Latin
characters (e.g., =F6) are probably in some locale-specific charset
(most likely ISO-8859-1 or ISO-8859-15) and are thus failing
validation.
Try taking a byte dump of the string you're trying to use, and see if
it doesn't say {0x42, 0x6a, 0xf6, 0x72, 0x6b}. This is the
representation of "Bj=F6rk" in ISO-8859-{1,15}.
> I was told "Bj=F6rk" can be represented by utf8 but that doesn't seem to=
=20
> be the case.
It most certainly can. B, j, r, and k are represented by their ASCII
values, and =F6 can be represented in several ways; this email contains
=F6 in UTF-8 as U+00F6, which UTF-8 represents as 0xc3 0xb6.
Ethan
--=20
The laws that forbid the carrying of arms are laws [that have no remedy
for evils]. They disarm only those who are neither inclined nor
determined to commit crimes.
-- Cesare Beccaria, "On Crimes and Punishments", 1764
|
|
From: James L. <bjl...@lo...> - 2007-01-28 17:05:19
|
James Lockie wrote:
> Thanks.
>
>
> Sean Egan wrote:
> =20
>> I'm sure Amarok provides a mechanism for knowing the
>> encoding of the strings it gives you
>> =20
>
> I have asked on the Amarok maiing list what string format Amarok is=20
> returning. :-)
> =20
I took out the decode and it works for strings without special=20
characters but I get this error for "Bj=F6rk":
message.append(signature=3Dintrospect_sig, *args)
UnicodeError: String parameters to be sent over D-Bus must be valid UTF-8
My guess is Amarok is NOT sending utf8 but decode works for some of the=20
strings but utf8 for other strings. :-(
I'll figure it out. :-)
I was told "Bj=F6rk" can be represented by utf8 but that doesn't seem to=20
be the case.
>
>
> Bartosz Oler wrote:
> =20
>> On 01/28/2007 06:26 AM, James Lockie wrote:
>>
>> [...]
>> =20
>> =20
>>> I am trying to modify the AmarokGaim plugin so that it works with
>>> non-utf8 strings like "Bj=F6rk".
>>>
>>> It calls "message =3D message.decode('utf8')" where message might be =
the
>>> string "Bj=F6rk".
>>> =20
>>> =20
>> [...]
>>
>> The decode() method converts a string into a Unicode string (which is =
just
>> an internal representation and not the thing which you can pass anywhe=
re
>> further). The argument specifies *current* encoding of the string. Thu=
s if
>> you know it's not utf-8 then you should not be giving utf-8 as the arg=
ument.
>> =20
> Mmm.
> I didn't write the original code and I don't know python, gaim or Amaro=
k=20
> so I am trying to figure it out.
> The original code passes utf8 to to decode and it works for strings wit=
h=20
> non-special characters but fails on things like "Bj=F6rk".
>
> I can print out "Bj=F6rk" to the console so the internal representation=
by=20
> python can handle special characters.
> =20
|