Version: 0.8.0 (using KDE KDE 3.2.0) Installed from: Compiled From Sources Compiler: gcc 3.2.1 OS: Linux Well, I'm a long time user of gaim and have switched over to kopete. First, congratulations on some really great work - I really like the KNotify flexibility. One feature I really liked in gaimthough, was the fact that the emoticons were auto-selected based on the protocol - made it really simple to tell which protocol the message was coming from, while eliminating emoticon inconsistencies between protocols. Also, not to mention the fact it's nice to know that the other person is seeing the same smileys you are. Could this be done? Thanks.
This is already on our TODO list. > Also, not to mention the fact it's nice to know that the other person is > seeing the same smileys you are. That can't be guaranteed for protocols that don't send custom emoticons (like MSN now does). Or for people using clients which have emoticon support different to that of the official client...
*** Bug 68010 has been marked as a duplicate of this bug. ***
We have already discussed that by the past, and this will probably not been implemented. 1) We want to try to be as consistant as possible between protocols. (having the same emoticons is a first thing) 2) each client may have different emoticons as there are no standard for that. You can't assume everyone uses MSN Messenger to connect to MSN. (and even, their pictures are copyrighted, so it's not possible to have the same)
As I said earlier in the bug report, this is on the TODO list (well, half of this wish at least). I intend to implement it eventually if no-one else does. Your reason 1 ignores the fact that different protocols are different. Just like we send crypto messages in JEP format over Jabber, or treat specially messages starting with 'AutoMessage: ' for MSN, or only handle '/me' for IRC, we should display emoticons that a particular protocol (or its default client) supports (and no others) when using that protocol, or at least provide the option to do so. Your reason 2 is partly valid - we can't necessarily emulate exactly the emoticons that other clients use for copyright reasons. But we can have the option to support only emoticons which are common for the protocol, or show the user which protocol certain emoticons are common on (Trillian Pro does something like this). I don't think this is a WONTFIX.
*** Bug 111596 has been marked as a duplicate of this bug. ***
*** Bug 112150 has been marked as a duplicate of this bug. ***
*** This bug has been confirmed by popular vote. ***
well, i share the same opinion! as former gaim-user i'm _really_ missing protocol emoticons. when i receive a message containing smilies i also want to get the same smilie as my chat-partner intended to send. to make a unified smilie-theme for a multi-protocol client makes no sense, at my point of view! and the support of such a protocol-dependent smilie-set does not necessary affect the actual common one. if you look at gaim (what would be a good idea to understand us, former gaim-user!) you'll see that this makes no problem! ;)
Is there any news about this feature ?
I was just about to write a feature request about this. It's not useful at all to send an emoticon if the other person will see a different one. What's worse, it could cause a misundestanding of what you're trying to express! Is it not the main goal of a program like Kopete, to help people communicate? Please dedicate some time to this... Thanks for listening!
*** Bug 128511 has been marked as a duplicate of this bug. ***
Recently my Bug 128511 (http://bugs.kde.org/show_bug.cgi?id=128511) has been marked as a duplicate, but I think is a different whilst than this one. Here you are talking about having different emoticons depending on the protocol that is a good thing. But I was playing around some time ago with making my own emoticons theme, and that was so easy that my imagination flew. My idea was let the user configure the emoticons theme _per buddy_. Although this feature could be used to solve this problem about the emoticons and the protocols, I was thinking in other use. Imagine you have all your friends using AIM. But you have _pictures_ of each of them with gestures that mimic the smiles. So you could configure Kopete with a different theme per buddy and really see your friends smiling when they send a ;-) or whatever. With another turn of the screw a small problem could be solved. When _you_ write emoticons you also would like to see your own face. So one more improvement let you specify the theme for your own user and see yourself smiling on the screen. I hope this clarify my whilst... Best regards
*** Bug 56751 has been marked as a duplicate of this bug. ***
I also would like a similar feature. One that uses a different emoticon theme per protocol. I don't care about all the fancy stuff though, just that the emoticons the conversation uses, are the ones I selected for the protocol.
I'm rejecting this with the standardisation across protocols argument, and since it would cause configuration bloat.
You're completely wrong. People need Kopete as a communication tool, and not being able to send and receive the same symbols (emoticons) across the network they share with others (i.e. MSN, Yahoo, ICQ, etc.) is in clear detriment of the value of Kopete as a communication tool itself. I'm so sorry for this!!
I also don't like the "standardization" reasoning - there are protocols that have official clients and official emoticon sets, and when I'm for example using the Gadu-Gadu protocol, I expect to see the same what my interlocutor sees (or what they would see if they used the official client; if they use a different one and/or choose a nonofficial emoticon set, I don't really care). For me, the ideal solution would be to configure a global/default emoticon set and (optional) emoticon sets for each protocol (they would override the default one). If no emoticon set is chosen for a protocol, the default one would be used.
Configuration "bloat".... It kills me when I see terms used so much that they lose all meaning. Just because you don't want to spend a couple minutes thinking of a way to implement this does not mean that there isn't a clean way to implement the feature. I would think that many people only use Kopete with one protocol, and for those who do use it with multiple protocols there isn't a problem presenting them with a very clean interface similar to the one that is used now. Allow users to choose a default emoticon set in the same way that it is done now. Then, just add a button or tab that would only be accessed for deviations from the default. A user could then choose to only change the emoticon set with one protocol or all of them depending on preference and use. I imagine that for stability and consistency reasons it would be best to use some kind of default emoticon set anyway. So, an exception list is both practical and clean from a configuration standpoint. Oh, and the standardization across protocols... I realize that development time and effort being expended here isn't free. So, it does make sense that the program itself have a certain amount of consistency, but with the protocols themselves behaving in so many different ways and having inherent differences in capability, I don't entirely understand that argument. In fact, it doesn't make much sense in an area where even one protocol behaves in a distinct manner from the rest. I see emoticons being such an area of concern.
Reopening. Standardization across protocols is not a valid argument for closing this bug.
Dear user, unfortunately Kopete is no longer maintained. Please migrate to another solution, e.g. for Jabber a possibility is Kaidan, for Matrix a candidate is NeoChat.