Version: 0.8.0 (using KDE 3.2.0 RC1, Gentoo) Compiler: gcc version 3.2.3 20030422 (Gentoo Linux 1.4 3.2.3-r3, propolice) OS: Linux (i686) release 2.4.20-gentoo-r8 Und Windows (with ICQlite I think) I added a contact to my contactlist and renamed it to "Hääschen". This looked good both in ICQlite and Miranda. But if I go online with Kopete, the user is displayed as "Hääschen"; looks much like an UTF problem. I'll attach a screenshot.
Created attachment 4409 [details] screenshot
*** This bug has been marked as a duplicate of 67727 ***
Matt, are you sure? That other bug talks about problems with umlauts in the messages, causing invalid XML. Here I've got problems already in the contact list. I haven't followed the Kopete development very closeley the last few weeks but this is the BRANCH from a few days ago and setting the encoding manually (as suggested) doesn't work. If the problem is the encoding guessing, maybe you can "steal" some code from Miranda which does it right :)
Also I can't understand why all bugs on this are marked as RESOLVED, when the problem clearly remains (although fix is reportedly underway).
yup, this is a general bug to cover all the various encoding issues, which we can't really fix due to something in QT (IIRC).
I doubt this is a Qt problem as his contact is also saved as H<C3><83><C2><A4><C3><83><C2><A4>schen in the contactlist.xml. I have renamed him manually and it seems like Kopete likes him now. I'll check what ICQlite and Miranda thinks about that contact when I boot to Windows next time (which might take some days as I have to switch harddisks). I'll reopen this bug as it should be possible to take the needed code from Miranda; if you think I'm totally nuts, feel free to close it again :) But I think there should be some bug tracking this. (Maybe this won't be fixed before the Oscar rewrite, but who knows.)
> I'll reopen this bug as it should be possible to take the needed code from > Miranda; if you think I'm totally nuts, feel free to close it again :) You _are_ completely nuts ;) We cannot and won't use any Miranda code as Miranda doesn't use QT and thus no QString (same applies to every other gpl source written in C and/or using char arrays). Furthermore this problem can be solved as soon as I've added the gui to set an encoding per-account because all strings coming from the server itself (i.e. not from a contact) will be converted to a QString honoring this setting (it'll also be the fallback option for instant messages but that's another topic). I'll keep this open until I've added the combobox (IIRC I have added the config option and support for it in the string freeze, so no new combo was allowed back then). > (Maybe this won't be fixed before the Oscar rewrite, but who knows.) In this case I can make an exception as the code is already there. I prefer to fix things in our refactoring work though (it's NOT a rewrite, it's just a new class hierarchy and we have to cutnpaste code into it, there won't be new code for the protocol handling itself)
With taking it from Miranda I meant adapting the logic they use; I don't even know under what License they publish their code so if stuff would be taken from them, a clean-room implementation might be necessary anyway. But you definitely know the Kopete/Oscar code better than me, so I shut up :)
It's all the same problem, we need to do string decoding when data reaches OscarContact or as soon as we know which contact the data will reach. *** This bug has been marked as a duplicate of 79574 ***