Version: 0.10.2 (using KDE KDE 3.4.0) Installed from: SuSE RPMs OS: Linux When sending messages to ICQ 2001b (and possibly other ICQ clients) on Windows (swedish), kopete adds <br> in the message instead of a row break. This result in ICQ showing <br> instead of a line break. Loaded modules: connection status contact notes cryptography (but not used in this messages) history netmeeting statistics suse smppd-en How to reproduce: Send a message to an Windows ICQ client containing a line break (newline).
It also sends > and < instead of > and <.
Linebreak works for me in svn trunk and miranda/licq on the other side. BTW, isn't that a duplicate of Bug 102880?
*** Bug 106637 has been marked as a duplicate of this bug. ***
Just a bit more on this problem: The following characters are getting translated on outgoing ICQ messages: Two consecutive spaces (" ") ==> " " Ampersand ("&") ==> "&" Less-than ("<") ==> "<" Greater-than (">") ==> ">" Newline ==> "<br />" Is there a simple way for users to patch this immediately?
*** Bug 107049 has been marked as a duplicate of this bug. ***
*** Bug 107763 has been marked as a duplicate of this bug. ***
When sending messages between two Kopete 0.10.2 the problem also appears. Sending tags results in escaped HTML code on the receiver side, sending already escaped code results in the sended text. But the biggest problem (which makes my chat partners angry ;-) ) is when I simply send normal text with newlines etc. they are send as HTML tags...
Fixed for KDE 3.4.2 (Kopete 0.10.3)
Can you provide a patch, or a list of files that we can retrieve from CVS in order to patch 0.10.2 prior to the KDE 3.4.2 release?
Strike my last comment. I downloaded the latest Kopete 0.10.3 from SVN using the instructions for Stable Checkout from SVN. I then replaced the kopete/ directory in the sources for kdenetwork-3.4.1 with this new version of Kopete, and rebuilt. Kopete 0.10.3 is now running nicely on my KDE 3.4.1 desktop. The HTML tag/entity issue seems to be resolved. The as-you-type spell checking seems a bit weird. It is enabled, then it gets disabled after typing the first word.
that is due to the way it is designed. the highlighting is turned off if you misspell too many words. Once the ratio of mispelled words to correctly spelled words goes down, the highlighting reappears. Kopete from SVN trunk has better indications regarding the status of the spell checking
still not fixed in svn version
*** Bug 109103 has been marked as a duplicate of this bug. ***
Sorry, i was beleiving i was using the svn version, but iwas using the release. the svn version works fine.