(*** This bug was imported into bugs.kde.org ***) Package: kopete Version: 0.4 (using KDE 3.0.1 ) Severity: wishlist Installed from: SuSE Compiler: gcc version 2.95.3 20010315 (SuSE) OS: Linux (i686) release 2.4.18-4GB OS/Compiler notes: Russian ICQ messages are usually encoded in CP-1251. Kopete ICQ plugin sends them in KOI-8r and it seems like there is no recoding facilities there so i cant talk to people using other ICQ clients. some recoding options needed. (Submitted via bugs.kde.org) (Called from KBugReport dialog)
Re-assigning to ICQ plugin
you mean you want to select a certain encoding for a user on your contactlist and outgoing messages get recoded to that encoding?
*** Bug 47298 has been marked as a duplicate of this bug. ***
well, at least in the way it is done in SIM, which, AFAIK, is the prototype for the icq-plugin. there is a sort of the default-encoding for me, and i can select particular encodings for particular users from my contact list. BTW: as far as i have tried it in kopete 0.5 came with KDE 3.1 - at least some of my friends read my russian OK, but i dont know how it depends on their clients and protocols they use -- i just have not reached all of them yet, i'll try to figure it out ASAP.
well, my recent tests show, that all my friends (at least using ICQ clients with protocol version 6 and newer) read my russian OK, so you may close this issue at least for Russian. (who knows if it works well for other languages)
Encodings should get honored now, selecting a special encoding for outgoing messages will get added after kopete 0.6 is out (see roadmap on our homepage). *** This bug has been marked as a duplicate of 52013 ***
Set of LANG=ru_RU.CP1251 before running kopete 0.7.2 (QT 3.1.2, KDE 3.1.4) helps to write/receive messages in CP1251, however CP1251 lang environment is not available on all Linux distros by default.
Subject: Re: icq plugin does not recode russian messages On Sunday 05 October 2003 21:23, you wrote: > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. > > http://bugs.kde.org/show_bug.cgi?id=43701 > > > > > ------- Additional Comments From oleg@tiscali.no 2003-10-05 19:23 > ------- Set of LANG=ru_RU.CP1251 before running kopete 0.7.2 (QT 3.1.2, > KDE 3.1.4) helps to write/receive messages in CP1251, however CP1251 > lang environment is not available on all Linux distros by default. > ___________ > www.plod.nm.ru -
Please reopen this whishlist-bug. until now i didn't report because i thought that there is going to be encoding selection. but as i downloaded and compiled Kopete0.8beta1, i noticed it's still missing :( ICQ users in Israel have the exact same problem. Some windows ICQ clients use ISO-8859-8 while other clients (kopete, sim, etc) use UTF-8. if i run kopete with ISO-8859-8 locales, then i can't see UTF8. To resolve this problem i think you should add encoding selection for each user that will be stored together with the contact information. in the chat window - please add a configurable combobox to set encoding. if you think it's ugly (and you're probably right) then set it to be hidden by default. but please add it. I think the combobox shouldn't display all available encodings, it should display only the ones supported by the system.
It's already there, but it's not in the chat window. It's in the properties dialog. However, Kopete's OSCAR protocol will do the right thing and send Unicode if ASCII can't fit, if the other side said it understands Unicode. If it doesn't, Kopete will send using the user encoding. In other words, Kopete might know better than you. If the other side isn't receiving correctly, maybe they were not configured correctly. I might add that I've never had a problem with Unicode being displayed wrong in Kopete (Latin 1 being displayed wrong I have). Since you're not in the CC list nor in the Voters list, I'm assuming it'll take a long time for you to read this, so I'm closing the bug again meanwhile. If you still have problems, please tell us what you typed and what the other side received (and what client they were using).
The problem still exists. it seems that i can see hebrew text sent to me by windows ICQ but when i send text they can't see it. the encoding option in the ICQ contact information seems to have no effect, lacale variables have no effect either. (still using kopete 0.8beta1) i also tested other clients like sim,Licq, and the problem doesn't exist with these clients. in sim's chat window there's an encoding button but i didn't even have to use it for communicating with windows ICQ clients. it autodetected and worked with the correct encoding. I was able to send and recieve hebrew text. I still think that encoding button (like the one in sim) is a good idea (even if autodetection would have worked) as this bug makes Kopete unusable for hebrew users. look what happens after i set to some hebrew encoding and try to send: ------------------------------------- kopete: [void ICQUserInfo::slotSaveClicked()] setting encoding to MIB:85(ISO-8859-8-I Hebrew, logically ordered) kopete: [void OscarSocket::sendIM(const QString&, OscarContact*, bool)] SEND (CLI_SENDMSG), msg='ממצב ?' to 'xxxxxxxxx' kopete: [void OscarSocket::sendIM(const QString&, OscarContact*, bool)] Outgoing message encoded as 'UTF-16BE' ------------------------------------- i set it to "ISO-8859-8-I Hebrew, logically ordered" but "Outgoing message encoded as 'UTF-16BE'" ??? and then i set it back to automatic: ------------------------------------- kopete: [void ICQUserInfo::slotSaveClicked()] setting encoding to MIB:0(Automatic) kopete: [void OscarSocket::sendIM(const QString&, OscarContact*, bool)] SEND (CLI_SENDMSG), msg='מה ?' to 'xxxxxxxxx' kopete: [void OscarSocket::sendIM(const QString&, OscarContact*, bool)] Outgoing message encoded as 'UTF-16BE' ------------------------------------- still, the other side could not read my hebrew text. BTW: i don't uderstand where did 'UTF-16BE' setting come from. my system uses only UTF-8. should i open a new bug?
> BTW: i don't uderstand where did 'UTF-16BE' setting come from. my system > uses only UTF-8. If the other side understands UTF16 I send out UTF16 regardless of the setting as that can encode anything you want. You forgot to mention the client used on the other side, in case it's not official ICQ or micq I suspect the bug to be on the other side (there are clients that claim UTF support although they don't have any). > should i open a new bug? NO!
the log i gave before i was chating with a sim user who doesn't use UTF-8. Here is a full session log with ICQ pro 2003b for Win: http://t2.technion.ac.il/~shlomil/kopete_problem.log in this session, after reading the log, it looks like Kopete detects the right encoding but the other user recieved only "aaaaaaa" or "???????" strings. > You forgot to mention the client used on the other side, in case it's not > official ICQ or micq I suspect the bug to be on the other side (there are > clients that claim UTF support although they don't have any). And that's exactly why a set-encoding feature is needed. right now i can see it exists but i wish it wasn't hidden in the ICQ contact information. This should be added to the chat-window toolbar, even if hidden option as default IMO.
>Here is a full session log with ICQ pro 2003b for Win: That can't be ICQ 2003, sorry to say. Every current Mirabilis client sends UTF and this client does NOT. > And that's exactly why a set-encoding feature is needed. No, it's only used if the other side does not support UTF. > right now i can see it exists but i wish it wasn't hidden in the ICQ contact > information. This should be added to the chat-window toolbar, even if hidden > option as default IMO. That's impossible with the current chatwindow, maybe later.
Actually this conversation does not make any sense because your logs are not the same. One time you're chatting with a client that supports UTF and one time you're chatting with some crappy/outdated client. Please don't change clients while testing something. In case you want really verbose logs about the other sides caps you might uncomment #define OSCAR_CAP_DEBUG 1 in oscardebug.h. That might reveal problems about the other side supporting UTF or not. Actually I think Thiago is right. If the other side announces UTF support and still things don't get displayed properly then the other side is having problems displaying UTF strings on screen and Kopete can't do anything about that. Again: I am NOT going to work around broken clients, the code is already complex enough to make string parsing a mess, just make your friends use a decent client, there are enough working ones out there.
Subject: Re: icq plugin does not recode russian messages The workaround for what you call "old broken" clients is simplier, that forcing all my friends to switch to new "correct" clients. for example for Russians: most Russian ICQ users use Windows, and thus the default text encoding for them is "CP-1251" (if not UTF-8, which is rare) so is for most Russian Linux Users, since they talk to other Russian users, who use Windows. so there are two obvoius and simple solutions: 1. Make default Russain encoding when "autodetecting" in ICQ as CP-1251. and/or 2. Make a "default Encoding" option for the owner's ICQ profiles, like in LICQ. -- this "defaults" encoding, if specified, will be used by default, for chatting with any other party, unless otherwise specified in that partie's contact properties. i dont know details about ICQ protocols -- maybe a newer version supports UTF-8, then, if the other party supports it, and that clients can agree themselves about it themselves, it should be used, otherwise -- the specified or the "default" encoding. This will simplify life of beginner KDE users Hello Stefan Gehn
I believe you've just described Kopete's current behaviour, except there is no "default encoding" configuration.
Exactly, as usual people just don't get what I repeat all the time :( OSCAR uses UTF if both sides announce UTF-support, otherwise the encoding-selection OR a fallback encoding (which is hardcoded right now due to lack of time) gets used. If something does not work it's either caused by QTextCodec not working properly or the other side announcing UTF support although it does not understand UTF (btw, UTF in here means UTF16-BE).
Subject: Re: icq plugin does not recode russian messages > ------- Additional Comments From thiagom@mail.com 2003-11-20 00:31 > I believe you've just described Kopete's current behaviour, > except there is no "default encoding" configuration. what about adding it? it will be simplier for user to select this one, when first trying kopete, rather than re-setting the same for all of ~150 of his pre-existing users that he found before
> what about adding it? After 3.2, it's too late to add new strings.
Although I can specify the contact's preferred encoding in the contact info, I'd still like to be able to change the encoding explicitly in the chat window -- for the chat duration. The other party may happen to use a broken client temporarily, or something like this...
i tried it once more, and the result is the same. even more -- my russian friends with Miranda (protocol v8) were reading me with ???? and i was reading their messages as some Japaneese symbols. after i changed their encodings (in their contact properties) to CP-1251 -- they read my russian messages fine -- and i read their messages as if they came in wrong encoding (CP1251 sysmbols displayed as ISO-8859-1) with SIM i never had such problems. besides -- most of my friends have russian nick which are displayed "in wrong encoding" in kopete, and fine in SIM and other popular linux and windows clients.
I tryied the Kopete wich comes with kde-3.3.1 and the result is the same. even more bizare -- they read my russian text fine, but i can not read their's (even setting the default encoding for contacts seems not to help) will this problem ever be fixed? take a look on how it works in SIM or LICQ. a proposal: maybe there should be a contact-wide option like "default encoding"? AFAIK -- there are several ICQ protocols, some of which use UNICODE, some not. then, this option could be valid for case when non-UNICODE transfer is used. for example -- for Russian users the best option would be to choose "CP-1251" -- every windows client uses it, and most unix users have to use it for ICQ too. besides -- all russian nicknames are otherwise shown in wrong encoding as well.
there are several other bugs that are similar to your problem, and it won't be fixed until i can find time to fix it.
I had a look at the sources. The file kopete/protocols/oscar/oscarsocket/oscarsocket.icq.cpp has some comments like "//TODO: encoding" But the functions in that file only send data, so problem probably isn't there. The second interesting place is in the file kopete/kopete/chatwindow/chatview.cpp (line 197). I have a crazy idea: what if the encoding of the chat window is set incorrectly? I am not a great programmer, so this is just a guess.
Sorry for my last post - it was intended for another bug. Shame on me
Kopete is great client for KDE. But this bug forces me to switch back to SIM, because there is no such problem. When I use LANG=ua_UK.CP1251 kopete or LANG=ru_RU.CP1251 kopete to start Kopete - I get correct encoding for ICQ contacts. Otherwise - ukrainian/russian contacts are displayed with wrong KOI8 or another default system encoding. But. This setting doesn't affect default encoding for message receiving. And I always get messages from my friends in some ISO encoding instead of my CP1251. I think, (as Gleb Litvjak said, even if he had mistaken (?) ), that bug can be in message displaying, not receiving. May be messages is really received in UTF-8 (or -16) encodings, but then displayed in wrong system encoding? or even some "default" ISO encoding? What do you think about this? Also, contact's "encoding" setting doesn't affect anything..
CVS commit by mattr: Merge the oscar_rewrite branch into HEAD. There are a ton of changes here and while i'm not going to go over them one by one, here's a brief overview of some of the things that have changed. - Delayed contact creation. Contacts aren't created on the kopete list until we get a confirmation back from the server that they were added correctly. - Timestamps of received offline messages are correct now (#45751) - Hopefully, many many encoding problems with message receiving are fixed (#88033, #97116, #43701) - Contacts that require authorization are now marked by a red 'X' over their icon. - Asking for and getting contact list authorization should be much more user friendly. - All the reported crashes (except for two dealing with ICQ RTF) are fixed - Contact list handling in general should be more robust. All in all, there are just a ton of changes and hopefully, your AIM and ICQ experience within kopete should become more enjoyable. BUG: 92115 BUG: 97411 BUG: 86471 BUG: 88062 BUG: 89505 BUG: 89982 BUG: 90353 BUG: 87714 BUG: 88033 BUG: 97116 BUG: 45751 BUG: 43701 BUG: 86502 BUG: 93631 BUG: 95702 BUG: 84688 BUG: 92888 M +4 -6 Makefile.am 1.32 M +46 -13 TODO 1.12 M +299 -609 oscaraccount.cpp 1.161 M +61 -131 oscaraccount.h 1.73 M +121 -663 oscarcontact.cpp 1.166 M +83 -196 oscarcontact.h 1.89 M +57 -0 oscarmyselfcontact.cpp 1.2 M +59 -0 oscarmyselfcontact.h 1.2 M +2 -2 aim/Makefile.am 1.10 M +91 -179 aim/aimaccount.cpp 1.50 M +43 -54 aim/aimaccount.h 1.20 M +158 -248 aim/aimcontact.cpp 1.65 M +64 -74 aim/aimcontact.h 1.24 M +23 -34 aim/aimprotocol.cpp 1.29 M +56 -57 aim/aimprotocol.h 1.11 M +67 -64 aim/aimuserinfo.cpp 1.18 M +0 -1 aim/aimuserinfo.h 1.10 M +1 -1 aim/kopete_aim.desktop 1.33 M +1 -1 aim/ui/Makefile.am 1.4 M +2 -4 aim/ui/aimaddcontactpage.cpp 1.10 M +8 -14 aim/ui/aimaddcontactpage.h 1.4 M +13 -4 aim/ui/aimeditaccountui.ui 1.31 M +40 -35 aim/ui/aimeditaccountwidget.cpp 1.23 M +21 -17 aim/ui/aimeditaccountwidget.h 1.9 M +4 -7 icq/Makefile.am 1.12 M +201 -228 icq/icqaccount.cpp 1.58 M +70 -54 icq/icqaccount.h 1.24 M +218 -279 icq/icqcontact.cpp 1.67 M +86 -130 icq/icqcontact.h 1.30 M +226 -0 icq/icqpresence.cpp 1.2 M +176 -0 icq/icqpresence.h 1.2 M +72 -372 icq/icqprotocol.cpp 1.63 M +62 -73 icq/icqprotocol.h 1.17 M +1 -1 icq/kopete_icq.desktop 1.36 M +0 -2 icq/ui/.cvsignore 1.4 M +7 -4 icq/ui/Makefile.am 1.5 M +85 -344 icq/ui/icqadd.ui 1.12 M +38 -262 icq/ui/icqaddcontactpage.cpp 1.21 M +26 -35 icq/ui/icqaddcontactpage.h 1.8 M +69 -0 icq/ui/icqauthreplydialog.cpp 1.2 M +45 -0 icq/ui/icqauthreplydialog.h 1.2 M +202 -0 icq/ui/icqauthreplyui.ui 1.2 M +136 -141 icq/ui/icqeditaccountui.ui 1.47 M +33 -472 icq/ui/icqeditaccountwidget.cpp 1.43 M +19 -42 icq/ui/icqeditaccountwidget.h 1.18 M +481 -0 icq/ui/icqgeneralinfo.ui 1.2 M +68 -0 icq/ui/icqotherinfowidget.ui 1.2 M +442 -0 icq/ui/icqsearchbase.ui 1.2 M +141 -0 icq/ui/icqsearchdialog.cpp 1.2 M +60 -0 icq/ui/icqsearchdialog.h 1.2 M +138 -0 icq/ui/icquserinfowidget.cpp 1.2 M +55 -0 icq/ui/icquserinfowidget.h 1.2 M +219 -0 icq/ui/icqworkinfowidget.ui 1.2 M +2 -0 liboscar/.cvsignore 1.2 M +12 -0 liboscar/DESIGN 1.2 M +194 -0 liboscar/HACKING 1.2 M +28 -0 liboscar/Makefile.am 1.2 M +77 -0 liboscar/TODO 1.2 M +382 -0 liboscar/aimlogintask.cpp 1.2 M +82 -0 liboscar/aimlogintask.h 1.2 M +91 -0 liboscar/blmlimitstask.cpp 1.2 M +43 -0 liboscar/blmlimitstask.h 1.2 M +474 -0 liboscar/buffer.cpp 1.2 M +248 -0 liboscar/buffer.h 1.2 M +270 -0 liboscar/bytestream.cpp 1.2 M +78 -0 liboscar/bytestream.h 1.2 M +206 -0 liboscar/changevisibilitytask.cpp 1.2 M +58 -0 liboscar/changevisibilitytask.h 1.2 M +675 -0 liboscar/client.cpp 1.2 M +368 -0 liboscar/client.h 1.2 M +115 -0 liboscar/clientreadytask.cpp 1.2 M +44 -0 liboscar/clientreadytask.h 1.2 M +270 -0 liboscar/closeconnectiontask.cpp 1.2 M +67 -0 liboscar/closeconnectiontask.h 1.2 M +207 -0 liboscar/connection.cpp 1.2 M +154 -0 liboscar/connection.h 1.2 M +62 -0 liboscar/connector.cpp 1.2 M +59 -0 liboscar/connector.h 1.2 M +245 -0 liboscar/coreprotocol.cpp 1.2 M +109 -0 liboscar/coreprotocol.h 1.2 M +66 -0 liboscar/errortask.cpp 1.2 M +39 -0 liboscar/errortask.h 1.2 M +72 -0 liboscar/flapprotocol.cpp 1.2 M +46 -0 liboscar/flapprotocol.h 1.2 M +134 -0 liboscar/icbmparamstask.cpp 1.2 M +55 -0 liboscar/icbmparamstask.h 1.2 M +113 -0 liboscar/icqlogintask.cpp 1.2 M +47 -0 liboscar/icqlogintask.h 1.2 M +151 -0 liboscar/icqtask.cpp 1.2 M +63 -0 liboscar/icqtask.h 1.2 M +213 -0 liboscar/icquserinfo.cpp 1.2 M +195 -0 liboscar/icquserinfo.h 1.2 M +224 -0 liboscar/icquserinfotask.cpp 1.2 M +75 -0 liboscar/icquserinfotask.h 1.2 M +100 -0 liboscar/inputprotocolbase.cpp 1.2 M +72 -0 liboscar/inputprotocolbase.h 1.2 M +86 -0 liboscar/locationrightstask.cpp 1.2 M +57 -0 liboscar/locationrightstask.h 1.2 M +219 -0 liboscar/logintask.cpp 1.2 M +144 -0 liboscar/logintask.h 1.2 M +392 -0 liboscar/md5.c 1.2 M +93 -0 liboscar/md5.h 1.2 M +236 -0 liboscar/messagereceivertask.cpp 1.2 M +102 -0 liboscar/messagereceivertask.h 1.2 M +159 -0 liboscar/offlinemessagestask.cpp 1.2 M +54 -0 liboscar/offlinemessagestask.h 1.2 M +97 -0 liboscar/onlinenotifiertask.cpp 1.2 M +60 -0 liboscar/onlinenotifiertask.h 1.2 M +138 -0 liboscar/oscarbytestream.cpp 1.2 M +72 -0 liboscar/oscarbytestream.h 1.2 M +425 -0 liboscar/oscarclientstream.cpp 1.2 M +165 -0 liboscar/oscarclientstream.h 1.2 M +108 -0 liboscar/oscarconnector.cpp 1.2 M +69 -0 liboscar/oscarconnector.h 1.2 M +349 -0 liboscar/oscartypeclasses.cpp 1.2 M +210 -0 liboscar/oscartypeclasses.h 1.2 M +252 -0 liboscar/oscartypes.h 1.2 M +252 -0 liboscar/oscarutils.cpp 1.2 M +75 -0 liboscar/oscarutils.h 1.2 M +86 -0 liboscar/ownuserinfotask.cpp 1.2 M +53 -0 liboscar/ownuserinfotask.h 1.2 M +72 -0 liboscar/prmparamstask.cpp 1.2 M +42 -0 liboscar/prmparamstask.h 1.2 M +116 -0 liboscar/profiletask.cpp 1.2 M +56 -0 liboscar/profiletask.h 1.2 M +228 -0 liboscar/rateclass.cpp 1.2 M +126 -0 liboscar/rateclass.h 1.2 M +157 -0 liboscar/rateclassmanager.cpp 1.2 M +76 -0 liboscar/rateclassmanager.h 1.2 M +172 -0 liboscar/rateinfotask.cpp 1.2 M +64 -0 liboscar/rateinfotask.h 1.2 M +2427 -0 liboscar/rtf.cc 1.2 M +864 -0 liboscar/rtf.ll 1.2 M +207 -0 liboscar/rtf2html.h 1.2 M +139 -0 liboscar/safedelete.cpp 1.2 M +79 -0 liboscar/safedelete.h 1.2 M +94 -0 liboscar/senddcinfotask.cpp 1.2 M +41 -0 liboscar/senddcinfotask.h 1.2 M +57 -0 liboscar/sendidletimetask.cpp 1.2 M +46 -0 liboscar/sendidletimetask.h 1.2 M +203 -0 liboscar/sendmessagetask.cpp 1.2 M +47 -0 liboscar/sendmessagetask.h 1.2 M +166 -0 liboscar/serverversionstask.cpp 1.2 M +57 -0 liboscar/serverversionstask.h 1.2 M +123 -0 liboscar/servicesetuptask.cpp 1.2 M +69 -0 liboscar/servicesetuptask.h 1.2 M +102 -0 liboscar/snacprotocol.cpp 1.2 M +46 -0 liboscar/snacprotocol.h 1.2 M +50 -0 liboscar/ssiactivatetask.cpp 1.2 M +38 -0 liboscar/ssiactivatetask.h 1.2 M +196 -0 liboscar/ssiauthtask.cpp 1.2 M +60 -0 liboscar/ssiauthtask.h 1.2 M +157 -0 liboscar/ssilisttask.cpp 1.2 M +109 -0 liboscar/ssilisttask.h 1.2 M +429 -0 liboscar/ssimanager.cpp 1.2 M +131 -0 liboscar/ssimanager.h 1.2 M +448 -0 liboscar/ssimodifytask.cpp 1.2 M +127 -0 liboscar/ssimodifytask.h 1.2 M +99 -0 liboscar/ssiparamstask.cpp 1.2 M +43 -0 liboscar/ssiparamstask.h 1.2 M +31 -0 liboscar/stream.cpp 1.2 M +75 -0 liboscar/stream.h 1.2 M +286 -0 liboscar/task.cpp 1.2 M +114 -0 liboscar/task.h 1.2 M +367 -0 liboscar/transfer.cpp 1.2 M +169 -0 liboscar/transfer.h 1.2 M +354 -0 liboscar/userdetails.cpp 1.2 M +85 -0 liboscar/userdetails.h 1.2 M +153 -0 liboscar/userinfotask.cpp 1.2 M +69 -0 liboscar/userinfotask.h 1.2 M +173 -0 liboscar/usersearchtask.cpp 1.2 M +61 -0 liboscar/usersearchtask.h 1.2 M +93 -0 liboscar/warningtask.cpp 1.2 M +59 -0 liboscar/warningtask.h 1.2 M +7 -0 liboscar/tests/.cvsignore 1.2 M +19 -0 liboscar/tests/Makefile.am 1.2 M +49 -0 liboscar/tests/clientstream_test.cpp 1.2 M +49 -0 liboscar/tests/clientstream_test.h 1.2 M +56 -0 liboscar/tests/logintest.cpp 1.2 M +53 -0 liboscar/tests/logintest.h 1.2 M +73 -0 liboscar/tests/ssigrouptest.cpp 1.2 M +54 -0 liboscar/tests/ssigrouptest.h 1.2 M +111 -0 liboscar/tests/ssitest.cpp 1.2 M +34 -0 liboscar/tests/ssitest.h 1.2 M +67 -0 liboscar/tests/userinfotest.cpp 1.2 M +53 -0 liboscar/tests/userinfotest.h 1.2 R Doxyfile 1.3 R README.login 1.1 R icq/icqsendsmsdialog.cpp 1.1 R icq/icqsendsmsdialog.h 1.1 R icq/icquserinfo.cpp 1.21 R icq/icquserinfo.h 1.11 R oscarsocket/.cvsignore 1.1 R oscarsocket/Makefile.am 1.25 R oscarsocket/aim.cpp 1.9 R oscarsocket/aim.h 1.8 R oscarsocket/buffer.cpp 1.44 R oscarsocket/buffer.h 1.31 R oscarsocket/md5.c 1.1 R oscarsocket/md5.h 1.1 R oscarsocket/oncomingsocket.cpp 1.23 R oscarsocket/oncomingsocket.h 1.11 R oscarsocket/oscar_fam01.cpp 1.3 R oscarsocket/oscar_fam04.cpp 1.10 R oscarsocket/oscar_fam19.cpp 1.10 R oscarsocket/oscarcaps.cpp 1.5 R oscarsocket/oscarcaps.h 1.4 R oscarsocket/oscarconnection.cpp 1.32 R oscarsocket/oscarconnection.h 1.24 R oscarsocket/oscardebug.h 1.5 R oscarsocket/oscardirectconnection.cpp 1.24 R oscarsocket/oscardirectconnection.h 1.10 R oscarsocket/oscarfilesendconnection.cpp 1.14 R oscarsocket/oscarfilesendconnection.h 1.8 R oscarsocket/oscarmessage.cpp 1.6 R oscarsocket/oscarmessage.h 1.1 R oscarsocket/oscarsocket.aim.cpp 1.33 R oscarsocket/oscarsocket.cpp 1.213 R oscarsocket/oscarsocket.h 1.126 R oscarsocket/oscarsocket.icq.cpp 1.73 R oscarsocket/oscarsocket.icq.h 1.14 R oscarsocket/oscartypes.h 1.9 R oscarsocket/rateclass.cpp 1.5 R oscarsocket/rateclass.h 1.3 R oscarsocket/rtf.cc 1.5 R oscarsocket/rtf.ll 1.5 R oscarsocket/rtf2html.h 1.2 R oscarsocket/ssidata.cpp 1.22 R oscarsocket/ssidata.h 1.16
Hi! Are these changes included in beta2? I have KDE 3.4 beta2 installed and the problem is still there. Moreover, I cannot select a custom encoding for my ICQ contacts anymore, using the "Properties" page. I really hope this will be fixed, because I honestly prefer Kopete over SIM, but forced to use the latter because of this bug. Thanks
I examine Kopete 0.10 from KDE 3.4.0. For ICQ protocol bug is still exists. Do you apply patch for KDE_3_4_BRANCH or in version 0.10.0 that can be download from kopete.kde.org? Or how I can build Kopete for stable usage with this patch?
the new code is in version 0.10. Please open a new bug with exact details if you're still having problems with this in 0.10. I need the following details: 1. the name and version of the sending client 2. the name and version of the receiving client 3. the locale setting of the receiving client 4. the locale setting of the sending client 5. a debug log of a single aim or icq session where you get sent messages that aren't displayed correctly. having items 1, 2, and 5 are the most important. I simply can't fix the bug w/o having that information.
I have no idea on what clients are those which my friends use, Also, i have no notion about internals of ICQ protocol, and what formats of messages are. I can only say, that the linux clients i usually use (licq, sim) handle this situation fine. From what i can see: my friend use VARIOUS clients from Windows. (from ICQ98 till ICQ2003 including MIRANDA, ICQlite and icq2go.) I can read their messages fine if i set encoding to cp1251 manually for every person in my contact-list manually. in other programs this issue is solved easilly: both SIM and LICQ allow to set so called "default" encoding for each IM account. As far as i know, some newer versions of ICQ protocols (clients) use unicode for messages transfer, and i suggest the following solution for the problem: If a remote client is UNICODE-compatible, use unicode, otherwise, for older clienst/protocols, if a special encoding is set for a specific person in contact-list, use that, otherwise, use an encoding set as "default" in the account setup, otherwise, use locale-default one. please note, i suggested the above solution 2 years ago (as soon as i tried one of the first public versions of Kopete) !!! Utill that issue is fixed, at least in russian LUGs and forums you will always see messages like "kopete is buggy with encodings, that is why i use SIM/LICQ/GAIM/ etc" On Thursday 31 March 2005 18:17, Matt Rogers wrote: > 1. the name and version of the sending client > 2. the name and version of the receiving client > 3. the locale setting of the receiving client > 4. the locale setting of the sending client > 5. a debug log of a single aim or icq session where you get sent > messages that aren't displayed correctly. > > having items 1, 2, and 5 are the most important. I simply can't fix the > bug w/o having that information.
seems to be working fine with 0.12 release the "default encoding" option seems to work fine, it didnot work for me in the version that came with SuSE 10.1 by default. (0.11.something -- it had the default encoding option, but it was grayed) after 4 years since this issue was described, it seems to be resolved, HURAY (!)