libim/tm/kim (was Use case for per-protocol icons)

Casey Harkins caseyharkins at
Tue Aug 7 00:47:11 EDT 2007

Josh Williams wrote:
> libim (library instant messenger):
> Experimental virtual protocols, such as terminals and a global,
> non-standard libim-to-libim file transfer method. (Can you imagine how
> wickedly cool it would be to have ssh and telnet terminal contacts in
> your buddy list?)

You could likely do this with protocol plugins for libpurple without 
having to fork.

> kim (kde instant messenger):
> In contrast to tim, kim will have only one main window for the buddy
> list and chats (unless the user chooses otherwise). Both the chat and
> the buddy list can be expanded or collapsed as the user wishes in
> order to save screen space.

As has been mentioned previously, a KDE libpurple client would certainly 
be welcomed.

> Unlike Pidgin, however, I would like to write kim to allow the user to
> choose which backend he uses, so it would not matter whether he
> prefers libim or libpurple. While libim would have more toys,
> libpurple would probably be more stable and secure (unless the libim
> project gains momentum). (Note that I do not wish to limit the user to
> _only_ the libim and libpurple backends; there will be a standard
> plugin API to allow the user to choose backends.)

You might want to look at There is a SoC 
project implementing a telepathy connection manager using libpurple and 
a prpl plugin for libpurple to use telepathy connection managers. If you 
did write a libim, you could make it a telepathy connection manager and 
base your clients on telepathy and get the pluggable backends for free.

> Again, if you would like to help in this project, feel free to send me
> an e-mail.

Good luck with your project. I hope you take the advise of many on this 
list and avoid forking libpurple if possible. Or, look into telepathy if 
that is closer to your needs.


More information about the Devel mailing list