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

[Josh Williams]

On 8/6/07, Etan Reisner <pidgin at unreliablesource.net> wrote:
> What sort of changes?

tim (terminal instant messenger):
I want to remove the windowing system. Instead, I want the buddy list
and each chat window to be separate processes (and commands). This
will give better support for terminals that don't support the window
borders in finch and will enable the user to choose whatever windowing
or screen system he wishes (e.g., screen or separate terminals).

This more simple approach is more unix-like in that you can use each
command as a building block (e.g., sending the incoming messages to a
file or program, or, if you don't care about what they have to say,
the bit bucket.. tehehe).

I'm also considering whether the buddy list should be the connection
manager or if that should be a daemon.

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?)

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.

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.)

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