I feel sorry to restart blogging after a long time with a rant, but I'm still working on the translation and I also started working as Gentoo dev, so I haven't had time to work on KNetLoad/general KDE apps.
Well time to start the rant, but before I want to say that I really respect Kopete developers, they did a good work, an extremely good one, but I think the way it's managed now it's moving it to the death.
In the past days there were many users who complained about problems with MSN, dued to changes on the MSN server. I don't know the exact details about this, but that's not so important.
I started in those days to use as IM client the other machine, with AdiumX on it. AdiumX is a libgaim-based im client for MacOSX.. I'm still using it now that the MSN problem is fixed. Why that? Because I find AdiumX more useful as an IM client.
Let analyze the problem: coping with proprietary IM servers sometime requires to have to change the way the protocol is implemented to have it working with new changes done to avoid users of unofficial clients to use the service; new features of the IM protocols are released very often; IM clients are something users uses daily, they must be simple and light to use.
The way Kopete is managed now makes this harder and harder to do: the release schedules makes really difficult fix problems like MSN's one, because Kopete can't be released on its own and is up to the downstream mainteiners to fix those problems on the spot. This is not good, this is not good at all as relying on downstream is not something which an be considered a good programming practice.
New features can't be added until a new minor version is released, and this haoppens just one time a year.
Kopete isn't exactly "light", and its UI is, instead, a lot difficult to manage. Just as an example, take the tabbed view of Kopete and the one of Adium.. Adium's can be switched using command-number, there's no way to set this up on Kopete; Adium allows you to select to which medium of a metacontact send the message to when you first write a message, Kopete doesn't. Adium interface takes the minimum space possible on the screen without the need of having a toolbar to connect/disconnect quickly. I think this can go for a looong time.
Unfortunately, the better way to achieve an usable and light interface is via a prototyping development. Adium used to release a new version every week when it started, changing features and UI design. Kopete can't do something like that because very few people will try the CVS versions and is constrained by KDE's release schedules.
So what's the solution? Eh, there's no clean solution. One of the ones which can be done is probably the development of a new IM client for KDE, maybe just using libgaim which seems to support most of the current IM features and many more protocols. This would require very quick releases to find a good design for the UI and a good set of features to implement.
I'd like to do something like that, but as I said I have no time at all... hope someone can just read that and start thinking of doing something to provide a better IM client for KDE users.
Syndicate Blogs
you knew you weren't go off easy, right?
a) Kopete _can_ be released seperately. In fact I'm working on releasing from two seperate branches at the moment. However, it still requires a lot of time because I've only run HEAD/trunk for about the past 6 months, and the move to SVN broke my build infrastructure that I had set up. As an example, I still haven't completely updated KDE from trunk since the move to SVN and that was almost a month ago, and couple that with the fact that i have to have Qt 3.2 and kdelibs 3.2 installed for one branch, and Qt 3.3 and kdelibs 3.3 installed for another, makes this time consuming. Another problem with releasing seperately is having to deal with users who want to use the new version but can't get an RPM or a debian package or whatever. I've also suggested breaking away from the KDE release schedule several times and each time i've been rebutted.
b) define downstream maintainers. Are you refering to the kopete developers themselves? If so, you should realize that we really only have less than 6 people that spend the majority of their time on kopete, and one of those (me) is responsible for like 50% of the code. There are new developers coming on board (my recruitment efforts have had great success!) but it will take some time to get them up to speed.
c) new features can be added. Suggestions for better UI are welcome. email kopete-devel@kde.org with ideas. we might even start releasing snapshots.
d) with regard to point c and the new features: sure, we could release snapshots but there are several problems with this:
- users expect their IM client to work, all the time, no matter what, therefore if something is broken in our snapshot, we hear about it, people quit using kopete, and then we're left with no users.
- the amount of feedback we would get that is useful would be somewhat minimal.
- it takes quite a bit of time (i'd say at least a week, if not two) to actually get a version that's stable enough to use as a snapshot, and even then, we'd have to impose a hard freeze, and i'd have to whack people with sticks to get them to quit committing things, and i don't like doing that.
e) it sounds like you _REALLY_ need to visit bugs.kde.org and file a few wishlists. I know that, for me, my memory sucks, and unless i do something right away or write it down, it won't get done.
yes, there are things that can be improved in Kopete. But we need a _LOT_ more manpower to get massive amounts of improvement, mostly due to the fact that we're not working with open protocols here and it takes people time to decipher, learn, implement and test a new feature.
Those are good news
What you are saying are really good news.
Also, I agree with you with the fact that breaking from KDE releases can help (that was the mainly thing I was thinking of when I wrote the blog entry, and was something I already expressed some time ago).
With "downstream developers" I was referring to packages' maintainers; at least for Gentoo we are used to talk about "upstream" (the original developers) and "downstream" (gentoo maintainers).
Anyway, good to know that you found new forces to help you, I know what it means managing something quite completely by yourself.
But IMHO one of the reasons why there wasn't so much people who asked to work on it before your announcement is because many people are scared of touching somethng in main KDE modules.
About (d), I think that providing "working but not stable" prototypes is something that can help: no need for complete stability with freezes, something which "just works" can be useful to get feedback from users who doesn't mind investingating eventual problems.
Myself.. I used to use konversation from bleeding-edge CVS HEAD before 0.17 release, that was really interesting thing because many things changed day-by-day... but I'm afraid to try do the same thing for kopete, because I don't really know how much can it work using 3.4 stable KDE and HEAD Kopete... if you can tell me that the compatibility is expected, then I'll surely try that and try to contribute with what I can.
About the problem with open protocols... that's why I suggested to take a look with libgaim. I'm not exactly a great fan of 'g' things, but if it can be used in a client which uses OSX's framework, it can probably be adapted with original authors to be used by different projects without too many problems.. that can provide support for many features still missing on Kopete, and at the same time the double contributions can help improve the existing code.
re: good news
About your argument about people being afraid to touch something in a main module: I've found that the place it's located is generally not an issue, but one of the reasons I think people don't get involved is because there is a huge learning curve. You have to know or be willing to learn C++, Qt, KDE, the Kopete APIs, and more often than not, the technical details of a protocol, so the barrier to entry is too high for most people.
About the reply to point (d): One thing that I've noticed, and maybe it's just me being skeptical and having to take a lot of shit from a small minority of users who complain about their IM isn't stable, but users won't accept something that's "working but not stable" and there is no such thing as "just works" for Kopete these days since "just works" for one person means "doesn't work" for another.
you can run Kopete from trunk with KDE 3.4, and it's very easy to do, especially if you've been running Kopete from the KDE 3.4 branch to begin with. it may not be quite as stable, but we tend to not be doing a whole lot of experimental changes w/o using a branch first.
Perhaps the best thing...
Would be to release updates of the libraries behind kopete.
I am not sure how this would work or if would even be possible. But make a quick release of kopete-libs or something similar would be a good solution. A full release of KDE would not be required.
Then the distros could just repackage that part of kopete and distribute it over their normal channels.
except that the libraries behind kopete don't change
you'd actually want to release the plugins by themselves instead. Sure, we could do that, but that's even more of a nightmare than just releasing quick snapshots.
Maybe not a complete solution
Maybe not a complete solution, but this would probably fix a lot of problems. This could fix the problems with protocols for example.
A complete, asynced, release of kopete from the stable branch, and/or from the head branch can also be a good way to allow users to get in touch with something moving to satisfy their needs.
a few corrections
> Adium allows you to select to which medium of a metacontact send the message to when you first write a message, Kopete doesn’t.
Just click on the smaller account icons in the metacontact, and you'll start chat through that account.
> Adium interface takes the minimum space possible on the screen without the need of having a toolbar to connect/disconnect quickly. I think this can go for a looong time.
We care about using minimum space, that's why we've implemented a solution to make it possible to use the contactlist even without scrollbars, which means largest possible space available. See the screenshot: http://img73.echo.cx/img73/6295/kopete0zo.png
Also, connecting/disconnecting is also possible via context menu of systray icon for a particular account or for all accounts.
> Just click on the smaller a
> Just click on the smaller account icons in the metacontact, and you’ll start chat through that account.
I know but is a bit more complex than on adium, especially on little monitors with high resolutions.
Anyway I don't know how it works when you have more than one account of a single type on Kopete, never tried.
> Also, connecting/disconnecting is also possible via context menu of systray icon for a particular account or for all accounts.
That requires you to go in two submenus. And when you're doing something and are disconnected by a lost connection or other reasons, it's annoying... also, kopete complain about the lost connection with a message box instead of trying to reconnect on its own.
> Anyway I don’t know how i
> Anyway I don’t know how it works when you have more than one account of a single type on Kopete, never tried.
Why critisizing if you don't know about it
> That requires you to go in two submenus.
Connecting/Disconnecting operations are rarely used, for me, almost I've never use them, so they would be definetely a waste of space if they were on the main window.
> kopete complain about the lost connection with a message box instead of trying to reconnect on its own.
True, kopete's auto-(re)connect feature is broken for a long time, but no one has motivation to fix it afai can see.
it's not about motivation anymore
At least for me, it's not about motivation anymore, it's about the amount of time i have to spend on Kopete, which isn't much. Testing takes up the majority of the time and it's not like we can automate the testing of certain things easily.