-20

Idea is about building new default IM client, or rewriting Kopete *from* *scratch*.
This would be great move, same or even better, as replacing another KDE3 relic - Konqueror with Dolphin and Rekonq is.

Today Kopete is almost unusable IM client... and the only alternative IM for KDE is MSN-only. There is Kadu - but they broke connection with KDE definetely long time ago.

Why Kopete is almost unusable?
- It is buggy.
- Protocol implementations are **very** old, *out-of-date* and unmaitained (like GG protocol, which has milions of users, but Kopete supports only GG 7 protocol version. Now there is GG 10 protocol version up-to-date and propably soon there will be GG 11. But thats not everything - even using raw GG7 protocol with Kopete causes *much* unsend or unrecived messages without any notice)
- It dont supports video or audio chat, nor file transfers, at least not in usable state.
- It doesnt support most of KDE4 features - akonadi, kaddressbook>4.4, dbus menu, Kross, etc.
- its interface is neither powerful, nor easy-to-use.
- look at Kopete feature request and bug reports, which arent touched for years.


Why Kopete development is hopeless?
- there arent much peoples intrested in developing Kopete.
- code is little hackish, poor documented, without good separation of GUI and protocol (like pidgib/libpurple has) - its very hard to help developing Kopete.
- protocol code is to out-of-date, making it up-to-date will take more work, than rewriting from scratch.
- it uses own protocol support, where it is possible to use libpurple or telepathy as backend, to guarantee up-to-date, bugfree protocol plugins, without much work from client developers. I dont think there are many developers intrested in maintaining something that is already done.
- it isnt using KDE4/Qt4.5 technologies as a backend.


What im proposing?
- build new, KDE default multi-IM client from scratch.
- it should be based on Qt4/KDE4 technologies like Phonon, Solid, Akonadi, Decibel (??)
- it should be good documented and easy to maintain
- it should use one of multi-im libraries (libpurple or Telepathy or Decibel) as a backend, it should be easy to migrate from one of them to another.
- it should completly integrate with KDE4.5. New contact, added either in Kaddressbook or out new IM client, shoud automaticly show in both. File dragged from Dolphin to contact window should automaticly be send to that person. Decoding of video/audio chats should be handled by phonon.
- it should store IM logs and contact data in Akonadi/
- should use Solid for handling cams and other hardware related things.
- It should use Kross scripts as plugins

Sorry for my bad english

I think you are right. Thera was no important development for the last years. In my oppinion office, webbrowsing and communication (mail & chat) are the most important tasks of a desktop system. In case of livemessaging there were at no time good solutions in kde. There open bugs like 74627 which would improve the usability much, but nothing will done. I don't know why there is so less progress in development, but if a new project would motivate developers to develop a modern and good kde4 integrated IM client, than it should be done.

trebor wrote:In my oppinion office, webbrowsing and communication (mail & chat) are the most important tasks of a desktop system.

100% right. KDE will never attract wider segment of common users with modern technologies, beautyful kwin effects, or great audio player, if users cannot be in touch with global network, without any pain.
I love KDE4 but im more and more depressed with KDEPIM & Kopete, and more often thinking about migration.

Instead of developing just support for the new versions of protocols, you are proposing developing everything from scratch with a statement that "there arent much peoples intrested in developing Kopete"?

Strange point of view. Why do you think people would be more interested in developing a complete new application? (the code is not that hackish and undocumented at all - when I needed to make something with it, it was a 5 minute task to see what's what)

As for pidgin/purple separation, it isn't that clean as you might think. Using purple from another project is rather painful because in many places it sorta depends on pidgin's structures.

As for "Akonadization" it is being worked on, and since KMail (and other PIM apps) in 4.4 doesn't work with the addressbook, you can't really blame Kopete for that.

With all that said, Kopete has a long way to go to become perfect, but dismissing it as 'unusable' is far out.

ivan wrote:Instead of developing just support for the new versions of protocols, you are proposing developing everything from scratch with a statement that "there arent much peoples intrested in developing Kopete"?

Isnt that better, than developing new protocol plugins, which in two years will be once again terribly out-of-date?

Strange point of view. Why do you think people would be more interested in developing a complete new application?

There are similar IM applications, for less popular than KDE enviromens, which have more people working on their. So maybe its Kopete codebase fault, that so less people want to contribute for it. Besides that, here complete new application means only GUI. Protocols should be handled by backends like libpurple or telepathy.

(the code is not that hackish and undocumented at all - when I needed to make something with it, it was a 5 minute task to see what's what)

Maybe it isnt, im not good programmer, without any experience in GUI in particular, so my judgement may be wrong. But still there isnt much development about Kopete.

As for pidgin/purple separation, it isn't that clean as you might think.

OK< libpurple uses much glib, etc. It is not easy to code completly new C app that implements it. But what about implementing libpurple by dbus? Even if im wrong, isnt easier to make libpurple integration, than implement dozen of closed protocols and maintaining them all the time?

With all that said, Kopete has a long way to go to become perfect, but dismissing it as 'unusable' is far out.

When i try to download contact list from server Kopete crashes. I cant send or recive messages, or even see statuses of half of my contact lists. Chatting with other half is troublesome, becouse 1/3 of sended messages by my or to me, are missing, without any warning that message were not delivered. Server-side avatars dont work for me. I only see small parts of status messages that other people have. Sending or reciving files dont work at least for me. Audio and video calls also dont work, at least for me.... et cetera et cetera...
are you saying that this are only minor bugs, and Kopete is perfectly usable for me ?

I agree the Kopete has a little to be wished for on the UI side (one of my pet peeves is logging in through the "status" button), and that there are a few bugs here and there, I don't think that another one from scratch is the solution.

Say, have you seen KMess?

(will let this idea stew a little more before validating/invalidating it)

This was supposed to be what decibel was for, but it is the only "pillar" of KDE 4 that never seemed to get off the ground.

Moult wrote:
I agree the Kopete has a little to be wished for on the UI side (one of my pet peeves is logging in through the "status" button)

I also login by Status button ;)

Say, have you seen KMess?

(will let this idea stew a little more before validating/invalidating it)

Yeah, of course. I wrote "and the only alternative IM for KDE is MSN-only". KMess looks great for me, but im not using this protocol.
Protocols what i use are: Gadu-Gadu in the first place (more than 20,000,000 users in Poland. For most of them this is the only IM they use), Jabber/GTalk, Skype, Facebook.

TheBlackCat: Yeah, you are right. Im changing topic a little

Dinth wrote:
Isnt that better, than developing new protocol plugins, which in two years will be once again terribly out-of-date?

If you develop new plugins now, they will be obsolete in two years and that's not depending on whether the client is written from scratch or not.

Dinth wrote:
There are similar IM applications, for less popular than KDE enviromens, which have more people working on their. So maybe its
Kopete codebase fault, that so less people want to contribute

Trust me on this one, it isn't I've been /fortunate/ enough to work on one of those /more popular/ IMs and with every step of the way I was wishing we forked Kopete instead of /that one/.

Dinth wrote:
for it. Besides that, here complete new application means only GUI. Protocols should be handled by backends like libpurple or telepathy.

Telepathy is coming to Kopete, and via that it will be able to use libpurple without the need to taint the code with purple.

Dinth wrote:
OK&lt; libpurple uses much glib, etc. It is not easy to code completly new C app that implements it. But what about

It is not about that, it is like separating Kopete into classes that deal with UI and classes that don't, and call the later a library. Currently purple looks a lot like that - when you want to use purple, you need to emulate some internals of the pidgin itself in your code...

Dinth wrote:
are you saying that this are only minor bugs, and Kopete is perfectly usable for me ?

I don't really like when people try to misinterpret my words.

1. I didn't say it is perfectly usable for you (I didn't say it was perfectly usable for me neither, although it is)

2. The reason you can't use it due to constant crashes, doesn't make Kopete unusable in general, but rather unusable for you specifically. Personally, I haven't had Kopete crash on me since KDE SC 4.o.

ivan wrote:
If you develop new plugins now, they will be obsolete in two years and that's not depending on whether the client is written from scratch or not.

You arent right. When new IM client supporting telepathy or libpurple, would be develped now, KDE developers (and users) would have guarantee that protocol plugins will not be obsolete in two years.

Telepathy is coming to Kopete, and via that it will be able to use libpurple without the need to taint the code with purple.

Yeah, ive already done much testing on Kopete telepathy plugin. But as ive seen, it is only protocol plugin. There will be many problems with it, like two different contacts lists (Kopete and telepathys own). Also is Kopete core really able to handle protocol plugins, which are wrappers for another protocol plugins (telepathy), which can be also wrappers for another protocol plugins? Theoretically, Kopete will only use only one protocol plugin, but really there will be for example 5 connected protocols. How Kopete will handle metacontacts ? How Kopete will handle setting different statuses on [Kopete telepathy plugin]->[telepathy haze protocol]->[libpurple gadu gadu protocol] and [Kopete telepathy plugin]->[telepathy jabber protocol]?

New IM should be build around Telepathy (or libpurple or ressurected Decibel).

It is not about that, it is like separating Kopete into classes that deal with UI and classes that don't, and call the later a library. Currently purple looks a lot like that - when you want to use purple, you need to emulate some internals of the pidgin itself in your code...

Ok, now i understand But if this applies also for making communication with libpurple using DBUS ?

I don't really like when people try to misinterpret my words.

1. I didn't say it is perfectly usable for you (I didn't say it was perfectly usable for me neither, although it is)

Sorry, i was trying to be little ironic.

2. The reason you can't use it due to constant crashes, doesn't make Kopete unusable in general, but rather unusable for you specifically. Personally, I haven't had Kopete crash on me since KDE SC 4.o.

At least for me, and for more than 20M other GG users which maybe would migrate to KDE, but dont do this, because KDE is lacking instant messaging for them.

And Gadu Gadu isnt only protocol in Kopete, which werent touched in _years_...

Please name at least three things in which Kopete is really good at?
Also look and konqueror-rekonq example, how developing from scratch new application was good for KDE. Konqueror would be slowly fixed, optimized, repaired for years, and in this time KDE would not have native good-working, fast and reliable webbrowser... Same applies to Kopete in my opinion

Whereas Ivan's developer input is highly valuable, I have approved the idea for greater community exposure.

Don't get me wrong, I'm not saying you're wrong, I'm just saying that some of your arguments are

Dinth wrote:
You arent right. When new IM client supporting telepathy or libpurple, would be develped now, KDE developers (and users) would have guarantee that protocol plugins will not be obsolete in two years.

...

... really there will be for example 5 connected protocols. How Kopete will handle metacontacts ? ...

This is exactly my point - you don't need to redevelop everything just so that you can support telepathy/...

I have no idea about how Kopete devs will do that - maybe the telepathy plugin will (when it becomes stable) replace all the other ones.

Dinth wrote:
Ok, now i understand But if this applies also for making communication with libpurple using DBUS ?

DBus interface should not have these problems, but I have no idea whether it has other issues - haven't tested it

Dinth wrote:
Sorry, i was trying to be little ironic.

I know, and I respect (and like) irony, but it is not really useful in a constructive argument

Dinth wrote:
At least for me, and for more than 20M other GG users which maybe would migrate to KDE, but

Again, I'm not saying you don't have a point there - there certainly are things that don't work (fortunately for me, I'm not using them at all) - but things that don't work don't always request rewriting a program from scratch.

Dinth wrote:
Please name at least three things in which Kopete is really good at?

1. UI (for some reason I really like it)
2. XMPP (it works perfectly for me - file transfer included)
3. Nice D-Bus interface (thanks to which I have a contact list on my panel)

Well, the above is all I need from an IM program.

Dinth wrote:
Also look and konqueror-rekonq example, how developing from scratch new application was good for KDE. Konqueror would be slowly fixed, optimized, repaired for years, and in this time KDE would not have native good-working, fast and reliable webbrowser... Same applies to Kopete in my opinion

Maybe it would, maybe not. Some ppl prefer Rekonq, some Konq.

The thing that is certain is that a lot of ppl would complain that the 'new kopete' doesn't have all the features the old one did.

@Moult
Heh, I haven't got a faintest clue this wasn't already approved

@OP
See the following:
http://community.kde.org/Real-Time_Comm ... laboration
http://grundleborg.wordpress.com/category/telepathy/

NO. Don't re-write the entire application because one protocol doesn't work well!

1. Kopete's meta-contact handling and user interface are EXCELLENT. I can't STAND not being able to group contacts together in Empathy.
2. Telepathy doesn't handle file-transfers very well, or in my experience at all. It could be added, but the same could be said of webcam support in XMMP and MSN in Kopete, especially since Kopete already has lots of code in it to support webcams.
3. The possibility of porting Kopete to Akonadi and Telepathy is there without the extra effort of re-writing completely unrelated, and in fact very well-implemented elements of Kopete. Take the Contact List layout editor: I understand it's lifted directly from Amarok and is the best implementation I've seen to date.

All the problems this claims to solve can be solved without the extra time and effort in a completely new IM client. Yes, all one of them, which is basically one, buggy protocol implementation.

Madman wrote:NO. Don't re-write the entire application because one protocol doesn't work well!

Maybe kde doesn't need a new IM-client. But in fact, there is a very little development progress in the kopete trunk. It becomes clear if you look at kopetes roadmap or at the featurewishlist on KDE Bug Tracking System.
I'm no coder, so I don't want criticising too much. But the question how the development of an important and basic app could be (re)animated must be legal.