Kadu Blog

0.11.0 - part four - visual improvements

2012-01-06T02:33:00.000-08:00

During 0.11.0 cycle we have spent some time improving UI of Kadu. Here I'll present a short list of most visible changes.

Toolbar buttons with menus

In 0.10.0 menus for toolbar buttons were implemented in Kadu and it was not very pretty - there was no distinction between normal buttons and menu button.In 0.11.0 we use Qt functionality and there is a small arrow to indicate that menu is available.

Button with menu can have default action (that is executed when button is clicked) or not. First ones have a small arrow next to button, second ones have an arrow directly on button.

Menu button without default action

Menu button with default action

More tabs

Tabs now will shrink when you have a lot of open chats. This allows to show more of them without need to scroll.

Really lot tabs shown at once

Unfortunately, tabs icons will no longer blink. There is Qt bug that caused all tabs to scroll to left when icon was changed - reaching tabs that were far on the right was impossible.

Message notifications

You will no more miss a message - every unread one is now indicated on dock icon, roster, window icon and tab icon. In 0.10.0 only messages for non-open chats were shown. Also placement of icon on roster was improved - it is now shown instead of status icon, non next to it.

New message icons on roster

Add conference window

Creating a conference required a lot of work - one had to Ctrl+select all needed buddies and then right-click and select "Chat..." command. New window will make this easier - you can easily select buddies, name a conference (or not, if it is one-time only) and start it. Lets have a look:

Add conference window

In this window you will no longer lose any selection by accidental click. Filtering by name, group, id makes it very easy to find required buddies. Visible name can be set for a conference - then it will be displayed on top of roster widget.

Summary of 2011

2011-12-29T07:04:00.000-08:00

End of the year is the best time for making summaries of any type, so here is one about Kadu:

Releases

This was really great year for Kadu - 0.9.0, the biggest rewrite/release ever, was finished in March (just look how many bugs and regressions we had to fix on redmine). After that we had a quick 0.9.1 and 0.9.2 bugfix releases, not-so-big 0.10.0 feature release and another one with bugfixes - 0.10.1. This means 5 total releases in one year, after more than 2 years of waiting for 0.9.0. We want to keep this pace and create at least 3 big releases in 2012.

Ports

Kadu on Windows had became official port, so we cannot ignore Windows' bugs anymore. MacOS X support is not bad, someone created port on Haiku, but nobody cares anymore about N900. Linux is still our primary taget.

Changes

In this year 2764 (2161 since 0.9.0) changes were pushed to Kadu source control system by 16 developers. This is pretty amazing for a small IM application.

A lot of these changes are about improving our codebase, so we can add features and fix bugs faster. Rest is about features - like GG10 roster support, new chat notifier, better proxy support, network awareness and so on...

A lot of new translations were added in this year, unfortunately only four are complete enough to be included in official release - Polski, English, Deutsch and Cesky. Uncomplete translations are available for French, Spanish, Italian and Slovak.

New server

We have also moved from our old server (from Chilan and Silvercoders) to new one (from Uni-Lux) and we gained a new domain: kadu.im (it is much shorter and easier to type than old kadu.net).

Future

Future is very bright for us, 1.0 is so close that you can almost touch it, bugs are fixed quicker than new ones are created and no regressions are allowed! 2012 will be the year of Linux on desktops and Kadu everywhere!

Happy New Year everyone!

0.11.0 - part three - conferences

2011-12-23T09:24:00.000-08:00

Conferences on roster

Conference is a way in Gadu-Gadu to talk with many people at once. It is very different from XMPP MUC or IRC chatrooms, as you cannot add new people or remove them. Until 0.11.0 ithe only way to start start a conference was to select all buddies (using Ctrl+mouse click), then right-click of one of buddies and select "Chat" action. It is not convientant all at, escpecially if you chat with the same people all the time.

So we've added possibility to add conference to roster widget. To do that just select all buddies, right click, select "View Chat Properties" menu item and fill in "Visible Name" for given chat. This conference will be then available at top of roster widget. You can also add conference to groups and search for them in roster widget by typing its name.

Implementation

It was implemented by creating MergedProxyModel for Qt that allows to merge two or more models into one. Model for roster widget merges model of all used chats and conferences (unnamed are filtered out) with model of all available buddies. Then other model (named TalkableProxyModel) sorts all items and pass them to widget.

Screenshots

Some screenshots of this new amazing feature:

Conference on roster widget

Expanded conference on roster widget - you can see who takes part in it

Conference data edit window - you can set name and select groups

Beta1

Beta 1 was released a few days ago. Give it a try! It is available at Kadu's Google Code page.

0.11.0 - part two - history

2011-12-13T11:42:00.000-08:00

Better, faster, smaller

In 0.11.0 development cycle Juzef did a great job identifying and resolving performance problems with our history SQL backend. He basically normalized database scheme and voila - history file is now 2 to 3 times smaller than before (with the same information!). That means that loading history into memory is 2 to 3 times faster and processing indexes is also a lot faster. So opening history window is also a lot faster than before!

Asynchronous loading

Messages from history are loaded into chat windows so you can remebmer last conversation with given person. In 0.11.0 this loading is asynchronous - that means you get your window open instantly and you can send and receive messages right away. Old messages are inserted into chat window when they are ready - which can take a second or two for really big histories. In Kadu 0.10.0 you had to wait for that to happen before you could even chat.

Import

History is imported automatically - you don't have to do anything (only wait 30 second at first run of 0.11.0). After import new history is available under ~/.kadu/history1.db file instead of old ~/.kadu/history/history.db.

0.11.0 - part one

2011-12-09T11:45:00.001-08:00

Introduction
This is first post from a series describing new features and improvements of incoming Kadu 0.11.0. As we are aiming for shorter release cycles this list will not be as long as 0.9.0 one.

Proxy configuration
Lets start with the oldest bug in: http://www.kadu.im/redmine/issues/3 Its took whole 8 years to close this one. After last year's rewrite of SMS code to use JavaScript code instead of C++ one this was easy to fix - just use QNetworkAccessManager to set proxy and you are done.

But our proxy configuration was lacking - every account had separate proxy setting and there was no way to easily change proxy for all accounts at once (that would be nice to have for people who often changes networks).

New mechanism was created - there is centralized place for configuring as many proxy setting as one may want. Each account can now choose proxy from the list as well as SMS plugin (or select special Default one). Default proxy can be changed at any time from configuration window or from toolbar button (note: it is not added by default to any toolbar, you need to do it yourself).

Mandatory screenshots

Window for creating proxy configurations

Selecting proxy for an account - you can select Default configuration

Selecting default proxy for whole application from toolbar button

Half a year later...

2011-09-24T12:26:00.000-07:00

Lots of news

Since last blog post a lot of things happened... 0.10.0 was released, we got a new server and moved from mantis to redmine...

0.10.0 release and 0.11.0

0.10.0 is our first release using new release cycle - that means only 5 month after 0.9.0. That is great, because we don't have so many new features to test - we can focus more on stability. That does not mean that nothing changes - Kadu got new plugin code, new build method, better system integration and one new notify plugin. Kadu Team plans to release 0.11.0 sometime about February 2012. 0.11.0 release will be about faster startup times, faster plugin loading and general performance problems fixing. We may be able to fix some of our ugly APIs (status and details APIs).

New server

After releasing 0.9.0 we decided that we need a new server. Old one just wasn't enough to handle all the traffic that comes with releases. We had move from our old server sponsored by 'Chilan' and Silvercoders (both are companies run by former developers of Kadu: Tomasz Chiliński and Adrian Smarzewski) - we are very thankful for all of these years when we could use this hardware. Kadu now uses server provided by Uni-Lux sp. z o.o. where Tomarz Jarzynka is working (he is the father of Kadu).We also got new, shorter domain: kadu.im instead of kadu.net.

0.10.0 progress, part two

2011-05-18T13:41:00.000-07:00

Second month since 0.9.0 release has passed. In our new release cycle that means that we are close to feature freeze (we are just waiting for GaduGadu 10 roster support). This is short list of new features since last blog post:

Plugins cleanup

Unsupported and old plugins were removed:

server_monitor (removed in 0.9.2 release)
parser_extender (merged into core)
all blacklisted plugins (dbus, tlen_protocol, echo)
all sound plugins but phonon_sound, qt_sound and ext_sound
many mediaplayer plugins were merged into mprisplayer_mediaplayer (dont worry, configuration will be imported automatically)

SDK and build changes, autodownload removed

Kadu has now SDK - FindKadu CMake modules for external plugins and own set of C++ headers for installation in /include prefix. Plugins can install its own C++ headers as well.

It means that every plugin can now be build outside of Kadu source tree and without modification of any Kadu source files.

Old .config file was removed. Installing non-standard icons, emoticons and sound themes is not supported anymore from Kadu build system - you have to do it on your own or just copy somewhere and configure Kadu at runtime to use your themes. Plugins are now configured inside new Plugins.cmake file and thanks to SDK additional plugins can be compiled and installed at any moment.

Autodownload is completely removed (I think distribution packagers will be very happy for that) as it is not really needed - everything needed for Kadu compilation is available in source packages and addons should be installed separately.

In-chat notification

New chat-notify plugins provides status-change notifications in chat window:

Myself on buddy list

It is again possible to have Myself buddy on buddy list. Just enable it from Buddies menu and you are done.

Message confirmations for GaduGadu protocol

Ultr has implemented GUI for message confirmations for GaduGadu protocol. Each message in standard Satin style has now icon attached to it: (...) for messages on the way, (v) for delivered messages and (x) for undelivered messages. This allows you to see if your network or GaduGadu servers are working properly.

0.10.0 progress

2011-04-16T05:13:00.000-07:00

It is almost full month since 0.9.0 has been released (and one week since 0.9.1). KaduTeam is now busy working on the upcoming 0.10.0 release, which will bring a lot of new shinny features. Here is brief list of what has been already done.

Blinking status icons

Maybe this is not the biggest feature ever, but is is really nice. When Kadu is logging to IM network all status icons (in dock, on buttons and in toolbars) connected with this network are blinking offline <-> your logging status. This is nice indication of what is happening

Better hibernation support

Kadu now knows about your network state (using NTrack library or Qt's QNetworkConfigurationManager on systems where NTrack is not available). When network goes offline Kadu automatically disconnects all accounts and connects them after network is back online. Kadu now properly reconnects after wake up!

Better Gnome3 and Ubuntu support

WhiteEagle has rewritten our kde4_notify plugin into freedesktop_notify (as it never required anything from KDE4) that works better with notification deamon from Gnome3 and Ubuntu (ie. does not put buttons on every notification as Ubuntu deamon does not support buttons).

Suggestions for spellchecker

Our new contributor, Dienet, sent us a set of patches adding suggestions for misspelled words to context menu of chat window. It looks like this:

Sugestie wyrazów

Better XMPP and Gadu-Gadu support

We are working hard with libgadu team to make file transfers in Gadu Gadu possible again. Also work on file transfers and MUC for Jabber/XMPP is on the way (hopefully it will be ready for 0.10.0 release).
Gadu Gadu will also receive contacts list synchronization that is available in Gadu Gadu 10 original client.

History importers

Plugin for importing GG from original Gadu Gadu 6/7 clients is already available: check it on wiki. KaduTeam will cooperate with author of this plugin to add it to default Kadu 0.10.0 package and to extend it to support Gadu Gadu 8 and 10 histories.

Conclusion

Future for Kadu is very bright ;)

Kadu 0.9.0 has been released

2011-03-21T02:06:00.000-07:00

0.9.0 version of Kadu Instant Messenger is available!

Source code:

Packages:

Packages for many Linux distributions are available (or will be soon available) at: Download

Installers:

Mac OS X:

Windows:

After over two and a half years of hard work, we are really proud to announce availability of the new and revolutionary version of Kadu IM 0.9.0.

This version brings many long awaited features, such as support for XMPP network (Jabber, GTalk, Facebook Chat, etc.), possibility of using many accounts from different networks in one instance of the program, completely new history module, and Adium chat styles support. New version is supported on Linux, BSD, Windows and Mac OS X platforms.

Despite significant growth, Kadu does not intend to join the club of overgrown multi-IM's. If you like Kadu for its simplicity and usability, you will find these features in even better shape in the new release. With simple but powerful configuration, Kadu can be either a simple one account client, or a full-featured multi-IM.

Kadu consistently provides free and easy communication across multiple platforms, without any intrusive advertisements and unnecessary additions.

List of most important changes since the 0.6.5 release:

multiple communication protocols, support for Jabber/XMPP (including Facebook, GTalk)
support for multiple accounts in one instance of the program
ease of use with made from scratch menus and dialog boxes
ease of talk with many improvements in the chat window - including copying text representation of emoticons, support for Adium styles and much better toolbars
new emoticon selector displaying items in correct proportions
editable groups of buddies
simplified notifications configuration
added Czech translation
Support for TLS connections and multilogon in Gadu-Gadu
history plugin based on the SQLite database, with brand new interface
new, improved Setup Wizard
new experimental ImageLink plugin for displaying images and youtube videos directly in the chat window
SMS plugin now uses JavaScript to send messages, so changes in the SMS gateways will not require full release of the program, only scripts update
refactorized source code with a much more friendly and readable API allows for quick changes and improvements

Since the release of Kadu 0.9.0 we introduce a new cycle of release:

once a month a small release with amendments (0.9.1, 0.9.2) repairing the most troublesome bugs found after the major release
every 3-4 months a large release (0.10.0, 0.11.0), adding new features and changing API a little bit

No more waiting several years for new Kadu ;)

More information in Release Notes

0.6.6 beta16 is out

2011-02-16T13:04:00.000-08:00

Another great beta is out ;)

Big changes:

encryption is now enabled on Windows
toolbar editing is possible on Windows
libgadu 1.10 is supported, with TLS and multilogon
items in history can be deleted now
search buddy window is now stable and does not crash
added support for typing notifications in XMPP and GaduGadu (requires libgadu 1.10)

Full changelog is here. Downloads are available on our Google Code ans SourceForge pages (links in sidebar).

Multilogon, TLS and libgadu 1.10

2011-02-11T11:31:00.000-08:00

Libgadu 1.10 (not-yet-released) brings us a few extra features that were implemented in Gadu-Gadu protocol for GG10. We have decided to include these in Kadu, but only for people with 1.10.0-pre version of libgadu installed.

TLS

TLS in an encryption protocol used in HTTPS connections. GaduGadu 10 can use it to secure connection between client and server. Each message is decrypted at GG server and then encrypted for the second client (if it also supports TLS connection). This is not ideal solution, but at least it allows for real secure login.

Second level of protection is Kadu's encryption plugin that allows for sending and receiving encrypted messages - this is client-to-client encryption - messages can be decrypted only by receiver (this is supported only by Kadu and EKG messengers).

I hope these two levels of protection are enough for everyone ;)

Multilogon

GaduGadu 10 also supports multilogon. Multiple clients can be logged on one account (before GG10 each login would disconnect other clients). Received messages are sent to each of the client and sent messages are broadcasted between them. Latest git versions of Kadu support this new broadcast message.

Kadu can also notify you about every other connection, both by our notification system and by new special multilogon window. Each session can be disconnected by Kadu both in window and in notifications.

multilogon window shows 2 additional conenctions

multilogon notification shows new connection

Toolbars

2011-01-24T14:37:00.001-08:00

More actions

Kadu has a lot of available actions, added by core, our modules and external modules. Some of these are only available as toolbuttons that can be added to chat window or other windows. So each module added its actions to toolbars by default and the toolbar became cluttered... (mediaplayer module added 5 actions itself!).

To fix that I've disabled the possibility to easily add toolbuttons by API, so no module can do this now ;) I've also added new action, called "More..." that can be added to toolbar. This action just shows a menu with all chat and users actions that are not in toolbar. It is not very pretty, menu is not sorted/categorized in any way, but it works for now. In future versions this will looks better, I promise.

Toolbars synchronization

This was a pain for anyone that wanted to change toolbar layout in chat window. Changes were reverted all the time. The proper solution was to open only one chat window, setup toolbars and close this window. Now toolbar layout is synchronized between all opened chat window and it is stored after every change - so it now works as it should ;)

These changes will be available in beta15, as soon as kadu.net server will be up again.

Invalid password

2010-11-21T04:08:00.000-08:00

Kadu never had good support for Invalid Password message. If you were lucky you would get a notification about that and then you had to find a place to enter your valid password. This has changed recently. When Kadu receives "invalid password" error from server a new notification is displayed (it is nice and transparent):

If you dont remember your password, you can click "Ignore" and Kadu will stop trying to connect. If you know your real password, you can click "Enter new password" button and get this pretty window:

(yes, it is still half-translated).

After clicking "Ok" Kadu will try to connect again. So easy and so nice ;)

Beyond 0.6.6

2010-11-10T11:58:00.001-08:00

As 0.6.6 release of Kadu is getting closer and closer Kadu Team is already thinking about future versions. We do not have as huge plans as after 0.6.5, but still :)

Releases

We want to make releases faster (there is almost a year now from 0.6.6-alpha0 release)!
Ideally we will have new full release every 3 to 4 months (that means 3 to 4 full releases every year, 6 to 8 times more than now)! This will of course make these releases smaller and MUCH easier to maintain. And with less features every release we will have less bugs, so everyone wins :)

Usability and look & feel

Our usability and look & feel improved a lot (transparency!) last two years thanks to our usability team, but there is still very much to do. We have modules window that is ugly. Syntax editors in configuration dialog are not very pretty... We need better widgets for color themes and shortcut editors. A fresh new "Open chat with..." window would be nice too.

I hope at some time we will get QML-based buddies list widget. With animations, transitions and all the fancy stuff everybody loves ;)

Modules/plugins support

We have pretty good modules system. But... Our plugin manager window is not usable at all. We need new one. We need a method for auto-loading of needed modules (based on user's configuration) so users could check "i want this feature" instead of going to modules window and search for module name in plain list. We need per-plugin configuration windows so users do not need to search for options. Moving from Kadu-specific .desc files to standard .desktop would be nice too.

Better protocols support

We do not have full GG10 protocol support. That is sad, as Kadu was created as Gadu-Gadu only application.

0.6.6 is first release with XMPP support, so I'm sure we don't have all features implemented ;)
Kadu does not supports transports or XMPP services now :(

Better code

No much to say here. Code always can be better. I'm trying to improve our code in every place so it is/will be very easy to maintain and modify.

1.0 release?

I hope we will have it before end of the world in 2012 ;)

New delete buddy window

2010-06-12T13:48:00.000-07:00

I know there was no blog posts for some time... I was busy moving to new place and I've got my Starcraft II Beta Key so you know ;) No time for anything else ;)

But SC II Beta is now over and I've got back to work on Kadu. Today I've finished a small feature that allows us to use one window for deleting contacts. It seems silly, but we had two in Kadu 0.6.5: one for deleting contact and one for removing its history. Now every module can add an checkbox to this window, and this is how it looks now:

We need different icons for these two buttons, I know ;)

Story of Screenshot module

2010-02-26T02:30:00.000-08:00

I haven't wrote anything about Kadu code recently, because there was nothing exciting there during last months. Bugfixing and polishing everything (yes, we created best IM ever, but it still has bugs!). This is so boring I've decided I need to learn something new, like Qt's QGraphicsView. Kadu's screenshot module was ideal target for moving to this framework (next one - for 0.8 or 0.9 - will be our buddy list).

1. Old code

To port module required reading old (legacy) code. That was not hard - it was only one big file: screenshot.cpp. As you know I don't like big files and big classes. Fortunately, the code was split into 3 classes: ShotSizeHint (small widget that displays image size in pixels and kB), ScreenShotConfigurationUiHandler (class that handles configuration widgets in configuration window) and Screenshot (class that was doing eveything else).

One thing scared me: for doing one real screenshot this module could take 4 or more (instead of storing first one in QPixmap object).

2. New classes

Big splitting began (remember: one class, one purpose!). Each extracted class deserves its own file. Global variable were moved to classes as static fields, so initialization of module looks like this: screenshot_module.cpp. This is excellent example of small and clean file that is easily understandable.

PixmapGrabber

Some part of old big Screenshot class was commented as code taken from KSnapshot from KDE. And it didn't use a single field from this class. Moving these methods to their own class and making them static was an easy step. This is how it looks now: pixmap-grabber.h.

ScreenShotConfiguration

This class is a small experiment. It is the only class in screenshot module that has access to config_file global variable. Other classes does not have to how configuration variables are stored and how to access them. This removed some duplication (like reading the same value in many places of code).

ScreenShotSaver

This class has only one purpose - save a QPixmap like a screenshot and return path to the file. It chooses path, format, creates needed directories and so on.

ScreenshotActions

This class creates and manages toolbar buttons that you can add to each chat window. It also reacts on menu click by creating new Screenshot objects and delegating all the hard work to them.

Screenshot

This class is as simple as others. It creates ScreenshotTaker widget, waits for screenshot or 'cancel' signal. It can also create widget for cropping image and display it until image is cropped by user. Then it paste result into chat edit window (if not cancelled and contact's max image size is bigger than screenshot size).

ScreenshotTaker

This is possibly the most complicated class. It behaves differently depending on screenshot mode. In full-screen modes it is not even shown, it just takes screenshot by using PixmapGrabber static methods and return them to Screenshot class. In window mode it shows itself and allows to drag an icon to any window, then it takes screenshot of that window. I'm not sure if I did it right, maybe some code should be moved to ScreenshotWidget.

CropImageWidget

The only purpose of this widget is to allow user to select an rectangle of image and crop it. It also displays subwidget with image size (in pixels and kB) and 'Crop' button.

ScreenshotWidget

This widgets wraps around CropImageWidget and adds full-screen behaviors to it.

ScreenshotToolBox

This widgets displays size of image and Crop button.

3. QGraphicsView

Using QGraphicsView allowed me to easily create editable crop rectangle with eight crop handlers.

SelectionFrameItem

This is QGraphicsItem subclass that draws four transparent black rectangles (shadow arount crop rectangle).

HandlerRectItem

This is QGraphicsWidget subclass (it can receive mouse events) that draws small white rectangle with black outline. It can be dragged by mouse - that causes crop rect to change. All these items are controlled by CropImageWidget.

4. Summary

As you can see, I was able to split screenshot module to some small classes that can be described by one or two sentences by general. This is something that makes design good - anybody can look into any of these classes and understand them easily and change them. I would be very happy if all kadu modules would be so easy to understand.

Mockups of Chats History Window

2010-02-08T14:48:00.000-08:00

Hello again,

Today we present to you two alternative mockups of "Chats History Window". For a long time our users were requesting improvements to History Window (in Polish):

Both mockups try to implement those ideas. It is up to you to decide which approach is better. Feel free to comment on those mockups here (in English) or in this forum post (in Polish).

Mockup 1 - 3 panel mockup: link

Mockup 2 - 2 panel mockup: link

We would love to hear your feedback,

Kadu Usability Team

edit:
based on your feedback on our forum we have choosen 3 panel version. It is going to look something like this: link

Releases and stuff

2010-01-19T11:57:00.000-08:00

A lot has happened since last blog entry. More than 380 commits were submitted and about 10 merge requests were merged (most of them from beevvy) ;) - see our number of clones on gitorious - 9 for now. And 0.6.5.4 will be released very soon.

Regular alpha releases give us more control over what was done and what needs to be done in close future. We are using short TODO lists (polish), so testers know what they should expect in next alpha. Thanks to them a lot of critical (crash) issues were resolved: 0.6.6 is now very usable and I've now got a single crash for whole week (but we really need more testers).

We are getting not only fixes, but also new code (this is just alpha, so no core API changes only) like new emoticons selector (beevvy's work):

and improved expandable contacts list (my and White Eagle work :P):

We now have DBUS module by Uzi (very simple for now, but this will change).

Also history got huge improvements: importing from older versions of Kadu is now about 10-50x faster than before (thanks to sqlite transactions support) and does now blocks Kadu anymore (again, transactions and threading - this is first time I've used producer-consumer pattern in real life). Now I'm working on bringing back status and SMS saving.

Still a lot work has left to do: GUI work (many mockups from our Season of Usability are still not implemented), modules porting, bug fixing, logic fixing and so on. After all that is done we will stop doing alpha releases and start doing beta ones - for bug fixing only.

State of the Kadu Usability Project as of 12.2009

2009-12-23T03:21:00.000-08:00

Hello,

This my first post on this blog, so I would like to say "Hello". ;) My name is Piotr Pełzowski, I'm working on Kadu project in my free time - mostly I work on usability and PR. Today I am going to report about current state of usability work done for upcoming version of Kadu Instant Messenger. I will present mockups that had been done by Season of Usability student, Mike Harmala with cooperation with the Kadu Usability Project Contributors.

Adding a New Contact in Kadu IM 0.6.6

Kadu Usability Project aims to make the current Kadu interface more user-friendly and easily accessible for users with different levels of proficiency as well as help the development team with the introduction of new features in the best way possible usability-wise. In short: KaduTeam is serious about building usable universal instant messenger.

As you probably know Kadu IM is an open-source IM client currently supporting only proprietary Gadu-Gadu protocol, Gadu-Gadu is the most popular IM network in Poland. In addition to GG network in next version of Kadu IM the XMPP/Jabber and Tlen networks are going to be officially supported. In fact three days ago Kadu 0.6.6 alpha0 has been released - this is the first development snapshot with XMPP support. As Rafał Malinowski stated:

Alpha0 releases in Kadu are soft-API freeze releases. That means that no one is allowed to make big API changes (small changes are still allowed). (...) Now we will focus on adjusting our GUI to mockups provided by Usability Team and on fixing remaining (less important) API parts - like Pending Messages, File Transfers or Status Changer (...)

So now it is time for GUI changes in Kadu, changes which are required and needed.

Ever since its creation in 2001 Kadu IM has been developed and designed primarily for Polish users of GG protocol. Now we hope to attract international user base with Kadu as a XMPP/Jabber client as well as make life easier for Polish users, many of whom use XMPP/Jabber on a daily basis (according to our user survey, that's the case for ~30% of Kadu users). Along with adding support for multiple protocols, we're planning to support simultaneous connections to more than one communication network, usage of multiple accounts of the same protocol and 'metacontacts'. All these enhancements require big changes, sometimes radical changes, in the interface of Kadu.

IM Networks drop-down list

Those changes are not results of UsabilityTeam whim ;) , our design is based on kadu user survey results (in polish), the survey which has been completed by 5035 participants provided us with vast amounts of useful data. Based on the data acquired from the developers and user survey personas for the Kadu IM has been built by Joanna Pierożek. In 11.2008 the actual work on the design of the multiprotocol user interface has been started. Draft mockups for most of the windows that needed to be introduced or redesigned were ready by the time Mike Harmala joined our team in July 2009 as a Season of Usability student. In the course of his work with us Mike has conducted a heuristic evaluation of the mockups we've previously prepared, based on Nielsen Heuristics, KDE4 Human Interface Guidelines - which we want to comply with - and other resources identifying a lot of issues that needed to be cleared up before the final version of the mockups could start to be implemented. The final contribution Mike has made to Kadu was a set of almost final, both functionally and visually polished mockups for most of the windows that would be introduced into Kadu as soon as it becomes a MultiIM. Those mockups were tweaked/polished a little bit by us and today we will present proposed final design to you.

Let's start with guideline that better explains some of the interactions in the new multiprotocol GUI:

Main mockups in png format:
Click to see big version of each mockup.

Adding a New Contact
Subscription Window (for XMPP-like networks)
Contact Properties
Your Accounts Window- Manage
Your Accounts Window - Add/Create Account
Menu and Context Menu
Merging Contacts (so called "Metacontacts")
Preferences (switching between Simple Mode and Advanced Mode changes ContactsList appearance as described in presentation)
Configuration (First Run) Wizard
Chat window

At this point we've almost finished full specification of all the windows that need to change or need to be introduced into Kadu 0.6.6 to make it a user-friendly multiprotocol Internet Messenger. We know the risks of radical changes to the design our users have enjoyed and gotten used to so far but we hope what we've come up with is good enough to both make our current users stay with Kadu and enjoy its enhanced functionality and improved usability and attract new users who either need a multiprotocol messenger or a user-friendly XMPP/Jabber client.

We still have few windows to design but those mockups should be consider as final GUI proposal for upcoming Kadu 0.6.6 version. We are eager to hear your feedback on our proposal. So if you have any comments feel free to comment!

Get Involved

Do you like our vision of usable multiprotocol messenger? Do you like our 'regionalization' concept visible in "Your Accounts Window - Add/Create Account", "Configuration Wizard" and "Adding a New Contact" window? Or maybe you like our efforts to integrate "branded" XMPP providers into GUI (which will probably lower the entry barriers for newcomers in XMPP world.)?

If additional you are interested or involved somehow in usability please consider joining Kadu Design Feedback mailinglist and became a member of UsabilityTeam. We have still many things to design, improve or fix. ;) Currently UsabilityTeam consists of two active contributors Joanna Pierożek and me. Previously the work on the Usability project has been conducted mostly in Polish. However during the summer we've switched almost entirely to English on the mailing list, in the documents and in the mock-ups we've produced. As far as the Usability project goes, we're ready to accommodate international contribution without making anyone feel intimidated. Hopefully, along with introducing XMPP/Jabber and other protocols useful for people from outside Poland into Kadu, regular contributors from other countries will indeed join our ranks.

Kadu 0.6.6 alpha0

2009-12-21T01:13:00.000-08:00

Kadu 0.6.6 alpha0 was released.

Warning: This version will eat your children. Do not use if you are not sure what you are doing. Configuration file format was changed (configuration file too), history format was changed. Reverting back to older versions is be possible, but with loss of all new history and configuration changes. If you can, use new Kadu from new user or with CONFIG_DIR set to kadu_alpha. We will not provide any official packages for this version.

Alpha0 releases in Kadu are soft-API freeze releases. That means that no one is allowed to make big API changes (small changes are still allowed). Stability in general is very good, history works, chats works, file transfers - we don't really know yet ;)

Now we will focus on adjusting our GUI to mockups provided by Usability Team and on fixing remaining (less important) API parts - like Pending Messages, File Transfers or Status Chagner. Many modules needs to be adjusted to new API too.

And of course: stability, stability and stability ;)

ChangeLog available at gitorious.
Source package available at kadu.net (2MB).

Good lock!

Storage Layer

2009-12-02T15:19:00.000-08:00

Code I've started writing almost year ago (new configuration API) have grown to whole new layer of code. Now it is called Kadu Storage API and this is the first thing that will get documentation (by Doxygen) for new release.

This API has some really nice features:

Details

Some classes, like Contact or Chat, have data that depends on some plugins (like XMPP/Jabber contact data, or Gadu-Gadu contact data, or IRC chatroom data, or ...). We want to give user view to this data even if plugin is not loaded/unavailable for some reason. So as much data as possible were extracted to generic classes like Contact, Chat, or Account (see how much extra data Gadu-Gadu needs for Account).This data can be loaded from Storage at any moment and be displayed to user and manipulated.
But that data cannot be used to do anything useful: you can't talk with someone on XMPP account if Jabber plugin is not loaded (but you can view this chat history). So when the plugin is loaded every object that depends on it loads extra data by using specific Details class. This class uses the same StoragePoint as main class so it can load extra data from the same configuration node. After extra data is loaded, the object can be used (to connect to server, make some chat and so on).

Shared classes

Shared classes bring some Java-like API to Kadu. It is just a trick to hide that given class is really a pointer. Just a good usage of QExplicitlySharedDataPointer and QSharedData. But with lazy-loading and StorableObject support ;)

Generic managers

Kadu has now two generic (template-based) managers: Manager and SimpleManager. The first one has built-in support for classes that use Details (like DetailsHolder subclasses) - it only exposes object without Details loaded when code explicitly asks for that. Just look for ChatManager implementation to see how little code is now needed to implement manager that fully supports loading/storing and many more features using these generics:

chat-manager.h
chat-manager.cpp

Simple constructors and intuitive behavior of StorableObject

StorableObject class (and all subclasses) has now only one constructor (instead of 4). Passing parent objects, node names and so on in constructors was replaced with nice virtual functions.

This class has now State field. It can has three values: StateLoaded, StateNotLoaded, StateNew. Code of load method is executed only if the state is StateNotLoaded. By default object is treated as "new" (so no need to load, but only default data is available). To make object "not loaded" (so it will be eventually "loaded") you need to set up its StoragePoint using setStorage method.

All that simple changes give more natural and intuitive feel of how this object behave. It also allows us to remove some code, because these new default are what we need in most of our code.

What is next?

After Doxygen documentation for Storage is written, I'll focus myself on little higher layers: Buddy Storage, Chat Storage, anything Storage to make sure everything is nice and clean ;)

API unification

2009-11-10T13:34:00.000-08:00

I am working on last bits of new Kadu API. Works that needs to be done can be summarized in 3 points:

move all important classes to base/shared/details model
extract as much as possible from base/shared/details model to common base classes
remove Buddy::contact(Account) method (or remove unnecessary uses of it)

Base/Shared/Details model

This is the improved structure of our main classes (Buddy, Contact, Identity, Avatar...). Base class (named simply Contact) is responsible to give access to object data. Every copy of such object contains pointer to the same Shared class (like ContactShared) contains data, can read and store it (it is always UuidStorableObject). Thanks to that we don't need to worry about working on copy of object instead of original one (the only class that knows about Shared class is the Base class).

Details classes allowed us to switch from IS-A to HAS-A relation (now GaduContact does not inherits Contact, just GaduContactDetails inherits ContactDetails and ContactShared object contains one of ContactDetails objects). This allows us to load all accounts/buddies and contacts at once and only populate details fields when protocol module is loaded. So situation where some object exists only in configuration and not in running program is not possible now. You can read history of such contact now ;)

A lot of code for these classes is duplicated: it needs extraction to template classes, and it will be done after Contact is ported to this new model.

BTW: I've renamed Contact to Buddy and ContactAccountData to Contact, so the names do make sense now ;) It was very problematically but I think that it was worth the effort.

Removing Buddy::contact(Account) method

This method assumes that a Buddy can have only one Contact for one Account. We don't like this assumption (someone can have a friend with 10 Jabber accounts, so why limit connections to only one?). After this function is removed (or its usage reduced as much as possible) this will be possible. We also need to remove functions with Account/Buddy pairs and replace that with Contact. It will also make moving Contacts between Buddies simpler (and merging and splitting Buddies too).

0.6.6 alpha0 - soft API freeze (or I will not mess so much anymore)

These are the last three things I want to do before soft API freeze. Be prepared to testing first alpha release ;)

Power of proxy models

2009-10-11T13:02:00.000-07:00

Our Usability Team created mockup of new "Add Buddy" window. It contains combobox for selecting group new contact will belong to. It looks like that:

- Select group -
Group 1
Group 2
Group 3
Create new group...

We have model for groups, but using it for that combobox would only show 3 groups, without additional items at top and at bottom. So I had to use proxy model.

Proxy models are models that you can stack (many of them) on another model (like our group model) to filter them, sort them or process data in any way. For "Add buddy" window there are 2 proxy models on top on group model:

QSortFilterProxyModel
ActionsProxyModel

First proxy model sorts groups by name, the second one adds items at top and at bottom of the list (it even make it italics). Code for stacking proxy models looks like this:


GroupsModel *groupComboModel =
new GroupsModel(GroupCombo);
  QSortFilterProxyModel *sortModel =
new QSortFilterProxyModel(GroupCombo);
  sortModel->setSourceModel(groupComboModel);
ActionsProxyModel *groupsProxyModel =
new ActionsProxyModel(groupsModelBeforeActions,
  groupsModelAfterActions, GroupCombo);
  groupsProxyModel->setSourceModel(sortModel);
GroupCombo->setModel(groupsProxyModel);

The most important part is that you can reuse these proxy models everywhere you want and you don't have to manually update this combobox when new groups are created ;) Models do everything for you.

How not to use signals and slots

2009-09-22T14:06:00.000-07:00

I wanted sound module to work for brand-new git/master Kadu with Phonon backend. So I've looked at code of sound and phonon_sound modules and I've discovered a big misuse of signal-slot mechanism.

Please look at sound.h file from 0.6.5 branch. The interesting part is signals: from SoundManager class:


signals:
  void openDeviceImpl(SoundDeviceType type,
       int sample_rate, int channels,
       SoundDevice* device);
  void closeDeviceImpl(SoundDevice device);
  void playSampleImpl(SoundDevice device,
       const int16_t* data, int length,
       bool *result);
  void recordSampleImpl(SoundDevice device,
       int16_t* data, int length, bool *result);

How this works? A module such as phonon_module creates new object that connects to these signals. Then a signal is emited and a slot is executed. Everything works, but this creates a lot of problems:

many object can conencts to these slots so sound may be played many times by different backend
so we need to ensure that only one backend is loaded, this requires additional code in module-managing classes
object can just ignore some signals and do not implement slots and/or connect them
results are returned using pointers in last parameters of these signals

This kind of problem requires another solution, that is still very simple and nice to implement:

create abstract class, like SoundPlayer, that has methods like SoundDevice *openDevice() and so on
create object SoundPlayer *Player in SoundManager
use this object instead of emitting signals
make SoundPlayer parent class of backend classes instead of connecting signals

Thats all today ;)

New history window

2009-09-14T13:18:00.000-07:00

Juzef has been working on new history window (and SQL history backend) for some time. So I've finally give it a try and after some tweaks I will show you effects of his work (this window still needs lot of work from our UI team, but it works as it should):

On the left side there is list of all chats (single ones and conferences - future modules like irc_protocol would be able to add new types of chats). You can use edit box above this tree view to filter chats by name, contacts, contacts' ids and whatever you want.

On the right side you have list of dates. You can select any one of them and you will get list of messages from that date. Above that is edit box for searching words (it will filter chats and dates lists too) and for selecting date range (it will filter chats list also).

What needs to be done:
* usability (this window does not have any)
* highlighting of found words (needs backport from 0.6.5.3)

New channels

2009-09-07T14:35:00.001-07:00

Three new channels for KaduTeam-world communication were open today:

identi.ca
twitter (mirror of identi.ca microblog)
blip.pl (only polish)

I hope you will enjoy reading our microblogs ;)

New history feature

2009-09-05T11:22:00.000-07:00

Yesterday I've added a feature known from Skype - user can display messages from yesterday/last 7 days/last 30 days in chat window. I needed only one hour to implement it, thanks to Juzef's SQL history and improving Kadu API ;)

Screenshot:

I know, the icon is the same as "Show history" one. I'll ask our art team to make a new one :)

Another git repository

2009-09-02T13:45:00.001-07:00

White Eagle has set up a new git repository for Kadu: on gitorious.org. It is way better that the one I've set: it has all our SVN tags, branches and externals (libiris). He has spent a lot of time to do that ;)

So now repositorium on Github is just a mirror of master branch and other git branches (not including old svn-ones). Feel free to ask for access to any of them.

Avatars

2009-08-26T17:32:00.000-07:00

Kadu now supports avatars on contacts list and chat window with Adium styles (now only for GaduGadu accounts). Implementation was done by me, Juzef and White Eagle (team work ;) ). Thanks to Qt model-view framework and to Kadu protocols' service framework this was very easy to do. Now we only need to optimize it a bit (don't ask server every time for avatar data) and to use original aspect-ratio of images.

Below is screenshot with contacts from my list that have avatars and two contacts without one, so you can see the temporary default-avatar image too.

And the chat window:

Next feature that will be implemented by me is choosed by community on our forum - support for "Show messages from today/last day/last week" in chat window (similar to what is in Skype 4).

Contacts tree view

2009-08-19T14:19:00.000-07:00

With one of last revision Kadu got a new feature - tree view for contacts. Now you can expand (with right-arrow button) any contact to see all connection to it (like Gadu-Gadu and Jabber ones). In near future double-clicking on any item will open chat window using choosen protocol and account, and every item will have its own context menu... Now just a simple screenshot:

My number is shown (btw: if you want to talk to me, use Private Messages on our forum or comments on this blog).

If someone has a screenshot with contact that has more than one subcontact - please send it to me.

Edit: screenshot from White Eagle

Another manager

2009-08-13T15:45:00.000-07:00

GaduGadu protocol supports delivery acknowledges - you can be sure that message was received. Kadu implemented it in two ways (you can choose one in Configuration):
* ignore it
* block chat window until ack is received

The first one sucks, because message could be lost in deep network and you will never know, second one sucks, because you sometimes have to wait for more than 5 second until you could write another message.

On 2007 mishaaq wrote a patch that would display a status icon next to each message. So you have information about delivery and chat window is not blocked. This patch was not applied (don't remember why) and is not available now (url is invalid now). This functionality is so much needed - I decided to write simple version of it from scratch.

As usual for me I started with looking again at the whole messages code and I've found that we need to make MessagesManager, remove PendingMessagesManager (or change it into MessagesManager), make Message a StorableObject and QSharedData and then everything will work great and look great and will be very hackable ;)

In near future 50% of Kadu classes will be managers. I hope it is a right way - it still looks so.

Back in Poznań

2009-08-05T15:09:00.000-07:00

I'm now back from my two weeks of sailing on Mazury's lakes. My thesis is almost-approved by my mentor and amount of my free time will be greater than zero in next week. Be prepared for next big changes for Kadu 0.6.6 ;)

Git repository

2009-07-04T04:05:00.001-07:00

Kadu has now an unofficial (read only) Git repository: git://github.com/vogel/kadu.git (http://github.com/vogel/kadu/). For write access please create an account on Github and ask me on our forum then. It is connected with our SVN by my local repo created by git-svn, so I hope I'll be able to synchronize these two.

I am curious how it will works and how the Kadu Team will like it. From the tutorial on github it seems like git is superior to SVN in every possible case. The future will show the truth ;)

Changing status for multiple accounts

2009-06-29T13:30:00.000-07:00

We now supports multiple accounts. Each account can have its own status and description. We need a way to allow user to change these easily. Our usability team created two modes for kadu: advanced and simple one. In advanced mode each account will have its own status button and status menu, each identity will have own button and menu (accounts can be joined in identities like Work and Private).

Development team has to put these ideas into code. In Kadu 0.6.5 each status change goes through StatusChangerManager singleton, that stores current user-set status and computes real status (modules can change what user set). StatusButton and StatusMenu uses this singleton.

The new code will be a little more complicated. StatusContainer interface (empty class) is introduced. It contains methods to set status, get current status and signal statusChanged. This interface will be implemented by two classes: Account (already done) and Identity (this class does not exists yet). Singleton StatusContainerManager will be created, as well as StatusContainerAwareObject class. Each StatusMenu object will get an StatusContainer object as contructor parameter, the samy apply for StatusButton. New widget, StatusButtons, is an StatusContainerAwareObject so it can adjust itself to new accounts/identities. It is just a horizontal box that contains multiple StatusButton widgets.

I thinks that this architecture will cover all needed functionality. Any other ideas?

Status updates

2009-06-23T14:54:00.000-07:00

Kadu is now slowly progressing to 0.6.6:

I'm moving files and classes around, so as few files as possible will remaing in kadu-core directory;
after this is done, I'll finish Your accounts window and start to enhance ContactsListWidget to support visualizing of metacontacts
our Season of Usability mentor and student connected (at least) with us, so we will have more GUI mockups to code;
I've switched locally to git (with git-svn as gateway to our official repository). I hope we will be able to move official repo to git after team members' exams, so everyone would be able to work on own branch(es), and I hope that this will also speed up our development a bit.

Password protection

2009-06-10T14:14:00.000-07:00

I did not have much time to work on Kadu last time (thesis work), but I would like to present a small feature I've just implemented. Now you can use "Your accounts" window to uncheck "Remember password" field. When you'll try to login to this account a nice window will appear to get the password from you:

You don't need to worry again about someone stealing your identity ;)

New Accounts window

2009-05-19T13:08:00.000-07:00

Our Usability team worked hard for bringing some nice windows for users. The first one I've implemented (almost) is "Your accounts" (White Eagle is working on "Add buddy" window now).

Maybe some screenshots now:

This is the window in "New account mode" (the only one already implemented). It lacks edit/delete functions, but anyone really needs them?

Lets select "Gadu-Gadu" from protocols combobox. What do you get?

You can enter things like "Account name", "Gadu-Gadu number" and "Password". Below is something called "Account description" - not yet implemented too. If you don't have an Gadu-Gadu account go select "I don't have a Gadu-Gadu number" and you'll get this window:

You need to provide e-mail address and a password (two times). And the "captcha" has to be solved (it is Gadu-Gadu's thing, not our invention). Click "Register" and with some luck you'll be granted with new account!

Next click "Add this account" and you'll get this:

Voila.

Implementing this window required some strange code:

CreateAccountWidget was added, each ProtocolFactory now has to provide function that create one of these window (like GaduAccountCreateWidget, that is visible above),
Creating FirstEmpty model class that adds an item before any other items in a model (like "Select a network to add" in example above); I think there is a better way to do that, but I haven't found one.

We (with the whole Kadu Usability Team) hopes that our users will love these windows. If you have any suggestions please put them in comments or on Kadu forum (we have special subforum for English users).

Broken server

2009-04-29T05:56:00.000-07:00

Out server is broken now ;( It means no access to our web page, Wiki, Forum, Mantis, even SVN... What is worse: we cannot reach admins of the machine... Maybe it is time to think about mirroring on SourceForge or on Google Code? And to move development from SVN to git?

And of course this had to happen when we got Season of Usability slot... Sigh.

Update: server is online again! It was only broken net connection, so no backup restore needed ;)

Season of Usability

2009-04-27T02:36:00.000-07:00

I have a good news from our Usability Team:

Kadu accepted as a Season of Usability project

Season of Usability is a series of sponsored student projects to encourage students of usability, user-interface design, and interaction design to get involved with Free/Libre/Open-Source Software (FLOSS) projects. Inspired by Google's Summer of Code, OpenUsability offers sponsored student projects. The Season of Usability 2009, sponsored by Google and Canonical, will be supporting 10 students to work on 10 open source projects during the June 1 - August 31 2009 season.

Kadu has been accepted as one of the projects. If you want to apply and work on our Usability Project) find out the details at the Season of Usability 2009 website.

Joanna "akai" Pierożek

Status updates

2009-04-19T14:40:00.000-07:00

Code a lot more stable that before ;) Almost everyday-usable (if you do not count modules...)
Gadu descriptions now properly decoded
Work on "Your accounts" window was started - it will allow users to configure their accounts (add, edit, delete). Mockups are available at our wiki page.
New class added: ContactSet (based on QSet). It will replace ContactList in many places.
Managers are now lazy-loading.
ConfigurationManager class added - it stores list of classes, that wants to save themselves before aplication exits (like AccountManager)
Many signals in ContactManager added - to allow watching for contact data changes
ChatWidgetManager will be added, replacing old ChatManager (that was renamed recently to ChatManagerOld [sic]).

0.6.6 in middle of the way

2009-04-01T11:06:00.000-07:00

Kadu 0.6.6 is now half done. I've decided to stop adding new features and reorganizing/rewriting code and to focus on stabilization and functionality that was lost in the development process after 0.6.5 (excluding modules, only core counts). So everyone is encouraged to get the last SVN snapshot and test it. I would like to have a stable version in a week or two, before the next part of API will go under review (the less important part).

We've done a summary of changes (done so far) on our forum. Here it is translated:

Gadu protocol moved to gadu_protocol module;
kadu-core directory splitted, files moved to subdirectories;
splitted big classes (Kadu -> KaduWindow, Core, KaduWindowActions, StatusMenu, StatusButton);
notify and window_notify modules moved to core;
static objects reimplemented as singletons (e.g. AccountsManager::instance());
a lot of new API to support multiple protocols: Account, Contact, AccountsManager, ContactsManager, ProtocolFactory, ContactAccountDat and many more;
UserListElement/UserListElements replaced by Contact/ContactList and probably ContactSet in nearest future;
services extracted from Protocol class, every implementor can just implement a subset of them - like Chat of FileTransfer;
Qt3Support removed, contacts list is MVC now;
Chat concept introduced (chat with one contact, GG conferences, IRC chatroom, XMPP chatroom - everything is a Chat), contacts list will be transfered into chat list in fututre;
simpler classes to support configuration storing (StorableObject, UuidStorableObject);
Adium chat styles support (with possibility to add more styles engines);
better X11 integration (by ultra);
idle module for supporting autoaway and similar modules (no more /proc reading);
better, splited menu (3 submenus);
extended group management (adding, removing, changing name and so on);
tlen and jabber modules added (Juzef, uzi);
a lot more.

And it's just half of the things that needs to be done...

Proof-read by Stiep

Notifications

2009-03-23T03:15:00.000-07:00

For the last few days I've been splitting the big Kadu god-class. It has so much code, that it's enough to make five other classes (Core, KaduWindow, KaduWindowActions, StatusMenu, StatusButton) and I think I could split it even more! Core (with Core::instance()) manages starting/stopping the application and setting/getting the current status. KaduWindow only implements gui of the main window... It is now closer to one-class one-purpose principle.

The next task is to move notify and notify_window code from modules to core. There are many places in kadu_core that could use notify capabilities and I don't see any reason to forbid that (and it will allow us to remove the MessageBox class).

I think our notify system is quite powerful, it supports many back-ends (like showing windows, playing sound, showing hints...) and it allows placing actions inside notifications. The only thing it is lacking is showing a value, e.g. a progress bar for file transfers. If we add it, it could be possible to integrate our notify system with KDE or GNOME notifications.

A little bit about our system: it consists of two base classes, i.e. Notification (for a messages being displayed to the user) and Notifier (for backends), and the NotificationManager class (for managing the two former).

Notification

If you want to create a message for the user, you should use the Notification class (or one of its descenders). Each notification has a name (e.g.: "newChat", "incomingFile", "connectionError") that identifies an event (notifications are configurable by name). Other properties are: title (used in WindowNotifier), text (content displayed to user, e.g. "New message from XYZ"), details (less important data, e.g. content of message sent to us), list of contacts and of course an icon.

Many notifications depend on the currently used account (e.g. "connectionError"). For those notifications the AccountNotification class should be used. Of course you could extend any of these classes to add new information, but not every notifier will be aware of them.

The Notification class has a concept of 'callbacks' - it's a list of actions that a user can perform (e.g.: 'accept' and 'ignore' on the 'incomingFile' notification). The only way to create a notification with a callback is to create a new class with slots for each action and call addCallback(tr("Action description"), SLOT(...)). You can also call setDefaultCallback(int timeout, SLOT(...)) so the user won't have to decide by herself or himself. If you would want to receive only the default callbacks 'accepted' and 'discard' (e.g. generated by left and right-clicking on hint), then just overwrite the callbackAccept and callbackDiscard virtual methods.

Also, notifications can live for some time. Every notifier can 'acquire' notification, so it won't be deleted until every 'acquirement' is canceled with 'release'. Sound notifiers do not 'acquire', but window and hint do. As long as the Notification is alive, it can be changed, but as I can see now, no signal is emitted. I consider it a flaw (look how the hints module appends new messages to hint...).

The last thing to know about notifications is that they need to be registered (so users can edit settings for each of them individually). It is done by NotificationManager::registerEvent and you can unregister it (for example if your module gets unloaded) by NotificationManager::unregisterEvent.

Notifiers

For implementing a new notifier, you should create descendant from the Notifier class with an overridden method notify(Notification *) (and register it with NotificationManager::registerNotifier). If your notifier will support callbacks, re-implement CallbackCapacity callbackCapacity() too (and return CallbackSupported there). You will also need to use notification->acquire() if it will display/update the notification content/icon anywhere. Of course after the notification has hidden use notification->release() to free memory.

If notifier can be configured, you should also re-implement NotifierConfigurationWidget *createConfigurationWidget(QWidget *) - it should return a new instance of the new class descending from NotifierConfigurationWidget. The most important function to re-implement is switchToEvent(const QString &). It should save the state of the currently edited event and display the state of the new one - given its method arguments.

In the end, saveNotifyConfiguration should store all changes made by the user in the configuration file.

Proof-read by Stiep

GSOC updates

2009-03-18T16:02:00.000-07:00

Google rejected us ;(
How sad. So we will have to do some of our projects without their support.
Maybe next year... When we will have XMPP support and Kadu will be more recognizable in the world ;)

Status updates

2009-03-18T03:10:00.000-07:00

No big changes recently in Kadu code (lack of time as usuall), but there are some things I would like to share:

we've got new developer - Juzef (http://juzef.idl.pl/) got full read-write access to Kadu svn repository, congratulations ;)
we've applied for Google Summer Of Code 2009 (our submission is still not verified), there is list of our ideas: http://www.kadu.net/w/GSOC2009 - of course anyone can start working on it, even if Google does not want us ;(
big Kadu class will be splited into KaduWindow, Core, CoreActions and maybe some others; mixing GUI logic with main class of Kadu is not a good idea (something like God Object antipattern)
Chat concept appeared, it will allows to have Gadu-Gadu conferences on contact list and not only that ;)

Signals, slots and ignoring OOP principies

2009-03-11T02:43:00.000-07:00

Refactoring of gadu_protocol module is now in cleanup mode. There are still some missing things, like DCC not supporting NAT connections, DCC configuration is not moved to Account settings page and so on...

I had some thoughts that I've got while I did the refactoring: about signals and slots overuse in gadu_protocol code. This Qt extension of C++ is supposed to help programmers with connecting events that happens on one object with actions that another object should perform when an event is triggered. The overuse occurs when the connection is always one-to-one and we know that no another object ever will try to connect to these slots or signals. Just like in gadu_protocol - classes like GaduProtocol, GaduProtocolSocketNotifiers, DccManager, DccSocketNotifiers were communicating with each other using this, but I think it is not the optimal solution. It needs connecting these objects (this is a lot of code to write!) and signals-slots invoking is really very slow (I know it is not a concern because of small frequency of these calls in protocol classes, but I still does not like this solution).

I've got into conclusion that these classes are really an one big class that is just split for convenience. So I've removed signal-slots where it was possible and made these classes each ones friends. They can now access private members of each other ;) In the result, it is easier now to understand how this whole group works together. We did not lost any of flexibility, because there was not any either (you cannot just extend a closed communication protocol like this).

This is not very good solution from view of OOP (no accessors, just friend classes), but it is the best one for my simple mind ;)

Sending files

2009-03-02T15:06:00.000-08:00

Kadu trunk can now send and receive files. Dcc6 and Dcc7 are supported. NAT to NAT Dcc7 connections will not work (libgadu issue). I've not checked Dcc6 callback connections (public-ip to NAT). If anyone has Gadu Gadu 6.x and is behind NAT - please contact with me on Kadu forum, so we can test this too.

What is left? Notify-based questions (accept file/reject file) and merging new file transfers with old ones (like sending rest of the same file in another session).

Receiving files

2009-02-28T05:32:00.000-08:00

Gadu protocol can now receive files (again) - in Dcc6 mode ;) It now uses FileTransferService to do that. Now it needs support for incoming transfers from Gadu Gadu 7 and newer and support for outcoming transfers; file_transfer modue will get all functionality of old dcc module (like asking for accepting incoming connection) and everybody will be happy now.

I've also found (and fixed) some fundamental mistakes in whole SocketNotifiers code. I hope now file transfers will be more reliable (eg: will work 100% of the time).

New (alternative) configuration API

2009-02-23T14:27:00.001-08:00

When I was updating Contacts API, then Accounts API and some more Kadu APIs ;) I've realized that current configuration API needs too much code to use. You basically have to use QXml to do anything more complicated that write one simple value (config_file.writeEntry() is not always good enough).

Contacts, Accounts, File Transfers are complicated structures that needs simple API to save/restore (some kind of serialization). This API is now provided by StorableObject class (I think I'll rename it to Persistent or PersistentObject in API-review time). Class that need to be stored (persistent) must inherit from StorableObject. It only requires reimplementation of one method: virtual StoragePoint * createStoragePoint() const, where StoragePoint class contains pointer to XmlConfigFile and QDomElement that is root node for storing this object's configuration.

For example, ContactData class implements it as:

StoragePoint *parent = ContactManager::instance()->storage();
if (!parent)
 return 0;

QDomElement contactNode = parent->storage()->getUuidNode(parent->point(),
 "Contact", Uuid.toString());
return new StoragePoint(parent->storage(), contactNode);

So we get new node under main ContactManager configuration tagged with the contact's Uuid. The storage() method is inherited and implemented in StorableObject class - it calls createStoragePoint when needed.

Implementation of createStoragePoint in ContactManager:

QDomElement contactsNewNode = xml_config_file->getNode("ContactsNew");
return new StoragePoint(xml_config_file, contactsNewNode);

It creates ContactsNew node under root node of main configuration file.

StorableObject supports external setting of StoragePoint - see setStorage() method.

When we have all of that nice stuff, we can store object. For example, FileTransfer storage looks like that:

void FileTransfer::storeConfiguration()
{
 if (!isValidStorage())
   return;

 storeValue("Account", CurrentAccount->uuid().toString());
 storeValue("Peer", Peer.uuid().toString());
 storeValue("LocalFileName", LocalFileName);
 storeValue("RemoteFileName", RemoteFileName);
 storeValue("TransferType", TypeSend == TransferType ? "Send" : "Receive");
 storeValue("FileSize", (qulonglong)FileSize);
 storeValue("TransferredSize", (qulonglong)TransferredSize);
}

Condition !isValidStorage() check if storage point exist, if not, it creates it (with all the needed hierarchy). It if fails, it returns false - we cannot do anything here about it. After that we store all values needed to recreate object in future. storeValue() method of StorableObject class writes data to subnodes of StoragePoint of this object (BTW: this method is not completed yet, it does not store objects Uuid, and I think that should be done be StorableObject or StorableObjectWithUuid class).

Loading object is possible when setStorage() method was called from somewhere (object does not know anything about its StoragePoint before loading). Then we could do:

void FileTransfer::loadConfiguration()
{
 if (!isValidStorage())
   return;

 CurrentAccount = AccountManager::instance()->byUuid(QUuid(loadValue<QString>("Account")));
 Peer = ContactManager::instance()->byUuid(QUuid(loadValue<QString>("Peer")));
 LocalFileName = loadValue<QString>("LocalFileName");
 RemoteFileName = loadValue<QString>("RemoteFileName");
 TransferType = ("Send" == loadValue<QString>("TransferType")) ? TypeSend : TypeReceive;
 FileSize = loadValue<qulonglong>("FileSize");
 TransferredSize = loadValue<qulonglong>("TransferredSize");
}

Everyting is as simple as possible.

And who sets the StoragePoint? FileTransferManager:

StoragePoint *fileTransferStoragePoint =
 new StoragePoint(configurationStorage, fileTransferElement);
FileTransfer *fileTransfer =
 FileTransfer::loadFromStorage(fileTransferStoragePoint);

The static method loadFromStorage does some magic to determine which Account this FileTransfer belongs to. Then it creates empty FileTransfer for this Account and calls something like this (for Gadu):

GaduFileTransfer *gft = new GaduFileTransfer(Protocol->account());
gft->setStorage(fileTransferStoragePoint);
gft->loadConfiguration();

Done.

Dcc Porting

2009-02-20T15:19:00.000-08:00

I'm in hell now. I've got working ChatService, ChatImagerService, PersonalInfoService, ContactListService and almost-working SerachService... But the FileTransferService need so much porting of DCC module, that I'm starting to cry... The worst part is that I've rewritten it before.

The good news is that White Eagle is writing Adium chat styles support for Kadu ;)

ULEs removed

2009-02-12T15:01:00.000-08:00

I've finally managed to remove last uses of UserListElement, UserListElements, UserGroup, UserList in Kadu (not including modules, but it is work for post-alpha releases).

Uzi is working on new ContactDataWindow (for editing contacts). After that we can restore contact management functionality - it is hard to use IM without that :(

I'll work on removing UserStatus and renaming Status to Presence. After that - rest of Gadu-Gadu protocol refactorisations (FileTransferService, VoiceService, SearchService...).

Protocol services

2009-02-12T02:53:00.000-08:00

Some more thoughts about refactorisation of Protocol and GaduProtocol classes. When I was extracting contact list export-import functionality from GaduProtocol, I've got an excellent idea about how-to-split the whole big class into smaller ones. It is very simple and widelly used in other projects (so why did't I thought about it before?).

We will have services: ContactListService, ChatService, FileTransferService, VoiceService and many others. Each of these will be an abstract class (call it an interface). Protocol class will implement methods like ChatService * chatService() - it will return 0 (no service implementation) by default. GaduProtocol for example will return GaduChatService object created in GaduProtocol's contructor.

Advantages? Smaller classes, possibility to query protocols for capabilities (if chatService() == 0 we cannot chat by this protocol, fileTransferService() == 0 - we cannot send/receive files).

Sometimes a function can became a class...

2009-02-10T11:48:00.000-08:00

...and it happens after the function became too big (or complicated). Like account-management functions for GaduProtocol (registerAccount, unregisterAccount, remindPassword, changePassword). Each of these functions used getToken function and a Mode field of GaduProtocol object, so the getToken could choose right function to call after its work was done (it works asynchronically). And each of these has own slot!

Why I don't like this solution? Without true reason it adds a new state field to GaduProtocol class - Mode (Register, Unregister, RemindPassword, ChangePassword). It makes GaduProtocol do things that are not really involved with normal IM communication - account management. It uses copy-and-pasted code, becouse these methods are nearly identical.

So I've decided to promote each of this funtion to a class of its own. With, of course, one base class: GaduServerConnector (ok, the name suck, it will be changed when I found a better one). This class does most of the work: it connects to server, fetches token (captcha) image, asks user for token value (using external object for that, so method of asking can be changed) and calls abstract method performAction(tokenId, tokenValue). Classes like GaduServerRegisterAccount (this name sucks too) only implement performAction method (and should call finished(bool), so GaduServerConnector can emit a signal for higher level code).

For example (there is only one right now) GaduServerRegisterAccount implements performAction using gg_register3 libgadu function. It wraps the connection in GaduPubdirSocketNotifiers and connects to its signal: done(bool, gg_http *). So after registration if over, it receives that signal and sets its Uin field. The caller can then read GaduServerConnector::Result field (so it knows if it was successfully) and the GaduPubdirSocketNotifiers::Uin (so it knows id of the newly registered account). Voila.

It makes GaduProtocol smaller and the flow of Register/Unregister/RemindPassword/ChangePassword a lot simples (I hope so...).

BTW: it still don't work, it segfaults every time. But it is just a technical problem, not design one.

UPDATE: I've fixed the crash. Registration does not work because (as I think) we are no longer compatible with GG protocol. I'll fix that later.

Is there somebody who wants to promote last 3 functions to objects?

UPDATE 2: I've found error with registration - it was just sending 2x password instead of password and e-mail ;)

Time for GaduProtocol

2009-02-03T02:03:00.000-08:00

Unfortunately it is impossible to do full ULE to ContactList transition without making some changes in Gadu-Gadu protocol implementation. Code responsible for exporting/importing list of contacts depends on old classes. So I had a look into gadu_protocol module and...

And I started refactoring it a bit. I know I've done it about year ago, but now I see that it was not well done: files and classes are too large. Some method also. Yesterday three classes were moved to their own files. Next step require removing all references to old UserStatus (and GaduUserStatus classes) and replacing it with the brand-new Status class.

But what was wrong with UserStatus? It does tasks that only Protocol class should have: it has slots, signals (for informing it was changed). Both protocol classes and Kadu main class conencted to it. The code flow:

Kadu: protocol->writeableStatus().setStatus(newStatus)
Status: emit goOnline("description")
Protocol: slot iWantGoOnline("description")
Protocol: communication with server
Protocol: CurrentStatus->setStatus(newStatus)
CurrentStatus emit goOnline("description")
Kadu: wentOnline("description")

Many unnecessary slots/signals. The right way to do it:

Kadu: protocol->setStatus(newStatus)
Protocol: communication with server
Protocol: emit statusChanged(newStatus)

We need the statusChanged signal, because the status setting can be asynchronous.

So the Status class is now very lightweight and does just what it should do - stores 2 pieces of data. Protocol and Kadu classes lost lot of signals and slots. And logic is much simpler ;)

After I sort out the Status class I'll look if splitting GaduProtocol into smaller classes (like GaduConnection) makes sense - I just like small classes ;)

New developer

2009-01-29T01:59:00.000-08:00

Yesterday Uzi got a SVN account. Now he is an official Kadu developer ;)

He is working with Juzef on making Jabber/XMPP and Tlen protocols first-class citizens in Kadu - expect impressive results in next few months ;)

How much does it need to change to make sure everything remains as before (or the ContactsListWidget story)

2009-01-26T04:04:00.000-08:00

Old widget used to display list of contacts in main window and in chat widget (used with conferences) was named UserBox. This class survived the transition to Qt4 only because Q3Support module. In 0.6.6 we want to remove dependency on Q3Support, and to add more functionality there (like support for meta-contacts, avatars, trees).

So we've started to writing it from scratch (almost).

The first thing to do: extract usefull classes from userbox.h/userbox.cpp to its own files.

Result:

AbstractToolTip
ToolTipClassManager
ContactsListWidgetMenuManager

The last one was part of UserBox class, but I think it is better to have it separated.

Second thing to do: write new widget.

Result:

ContactsListWidget based on QListView - part of Qt4 Model/View framework.
ContactsModel to feed data from ContactsManager to the new widget
ContactsModelProxy to sort and filter contacts beetwen ContactsModel and ContactsListWidgets
ContactsListWidgetDelegate to paint contacts with icons description

I can say that this whole Model/View thing totally kicks ass. Most of the work is done by Qt: we don't have to care about sorting (with its performance when many contacts change status in one time) - we only provide compare function and signals triggered when something changes on ContactsManager.

Also the refreshing code in old UserBox was not very easy to follow - there was methods like refresh(), refreshLater(), refreshAll(), refreshAllLater() and complicated structures that allowed to avoid refreshing list if not neccessary. I'm glad we could remove all that code and just belive that Qt will do it better than us ;)

For each ContactsListWidget in Kadu there is exactly one ContactsListWidgetDelegate object that paints items on list. In Kadu 0.6.6 for each item on each UserBox there was one KaduListBoxPixmap. So I hope our memory ussage is a little bit lower that before (I'll do some measurements after we have 0.6.6 out). Painting code is almost the same - the only difference is description handling. Qt4 provides QTextDocument that we now use for that - Kadu 0.6.5 had custom (and long) code to compute description height and to paint it wrapped. It is another thing that Qt is doing for us now.

But it is not done yet:

sorting does not works as good as it should (random contacts are not-sorted)
filtering not yet implemented
support for only one column (maybe it will be possible to have more columns, i don't know yet)
drag&drop not yet implemented
background images not yet implemented

So if you have some time, please go to Kadu forum and ask how you can help ;)

Aware objects

2009-01-20T02:24:00.000-08:00

"Aware objects" were created because of my laziness. In Kadu exists lot of objects that should change their behaviour/look when the configuration changes. The change invokes ConfigurationWindow::updateConfig() which (before introduction of ConfigurationAwareObject class) emited a signal.

Each object that wanted to be informed about it had to connect to this signal. It needed a lot of code: slot implementation, connection in constructor, disconnection in destructor. To free myself from writing this I've created ConfigurationAwareObject class. It has very simple interface:

class KADUAPI ConfigurationAwareObject
{
  static QList<ConfigurationAwareObject *> objects;

  static void registerObject(ConfigurationAwareObject *object);
  static void unregisterObject(ConfigurationAwareObject *object);

public:
  static void notifyAll();

  ConfigurationAwareObject();
  virtual ~ConfigurationAwareObject();

  virtual void configurationUpdated() = 0;

};

The objects field contains list of all objects of this class. Its gets updated each time the ConfigurationAwareObject contructor or destructor is called.

Static method notifyAll (called from ConfigurationWindow::updateConfig()) iterates over all objects and calls configurationUpdated on them.

So if you need to create a class that reacts to changes in configuration just make it inherit from ConfigurationAwareObject and reimplement virtual method configurationUpdated(). No need to connect/disconnect signals and slots.

In 0.6.6 AccountsAwareObject class was added with 2 abstract virtual methods: accountRegistered(Account *) and accountUnregistered(Account *) and two normal methods: triggerAllAccountsRegistered and triggerAllAccountsUnregistered (these two just call virtual methods with all currently active account).

So if you want information about accounts changes - make a class inherit from AccountsAwareObject and reimplement virtual methods. Also add call to triggerAllAccountsRegistered in constructor and triggerAllAccountsUnregistered in destructor - so it will be aware of accounts that existed before the object was created.

You could ask why triggerAllAccountsRegistered and triggerAllAccountsUnregistered are not called in AccountsAwareObject's constructor/destructor. It is because AccountsAwareObject's constructor will be called before your class constructor, and call accountRegistered(Account *) on object that can be not ready for this.

I hope that in near future we will create more aware objects in Kadu and remove many unnecessary signal/slots connections.

Tlen & Jabber support

2009-01-19T02:39:00.000-08:00

First screenshots of Tlen contacts in Kadu (Jabber is supported too, but we don't yet have icons for that):

http://www.kadu.net/forum/viewtopic.php?p=88749#p88749

Thanks for Juzef and uzi for the hard work!

Status and description

2009-01-08T16:36:00.000-08:00

I had a GPU failure on my laptop, so I was unable to do any work for Kadu for 2 weeks. Now as the ULE to Contact porting is in progress, I'll present how status/description changes are done in Kadu internals.

The problem

Changing status seems to be an easy task - create an object with enum (Online, Busy, Invisible, Offline) and QString fields, modify values and pass it to protocol-handler object. But at some time people started writing plugins that were modifying statuses in many ways:

amarok module - could add information about currently played song to description (before or after user-supplied one)
filedesc module - was reading lines from file, one by one, and setting it as user description
autoway - change status to offline/invisible/busy after some time of inactivity, description could also be modified as in amarok
...

User could load and use any status-changing modules at one time.

This is how amarok module worked:

when amarok started to play song, current user status was stored
user description was changed by adding song information
when song stopped, old (stored) status was restored

And autoaway:

when user was inactive for given period of time, current user status was stored
user description and status was changed
when user activated, user status was restored

If you have some experience with multithreaded programming, you'll see the possible problem right away. If user used amarok and autoaway modules and the steps were executed in following order:

(amarok) 1 - amarok stores "user status"
(amarok) 2 - amarok changes status to "amarok status"
(autoaway) 1 - autoaway stores "amarok status"
(autoaway) 2 - autoaway changes status to "autoaway status"
(amarok) 3 - amarok restores "user status
(autoaway) 3 - autoaway restores "amarok status"

The status of user will not be set to "user status" - so the behavior is plain wrong.

The resolution

To resolve this problem I've created two classes: StatusChanger and StatusChangerManager. These two operates on old UserStatus class (that will be replaced by new, much simpler, Status - but this is another story).

StatusChanger is abstract class with method virtual void changeStatus(UserStatus &status). This method can do anything with status - append, prepend something to description, replace some tags with any content, even change the status to Offline (which means logout from Gadu Gadu network).

StatusChangerManager allows for registration and unregistration of StatusChangers. StatusChangers are joined in chain, ordered by their priorities. The first StatusChanger in chain is always UserStatusChanger, which is controlled by user. When user changes status the UserStatusChanger::userStatusSet(UserStatus) is invoked, which emits signal statusChanged. This signal is received by StatusChangerManager, and every StatusChanger's changeStatus is invoked:

UserStatus status;
for (int i = 0; i < statusChangers.count(); i++)
 statusChangers.at(i)->changeStatus(status);

After that statusChanged(Userstatus) signal of StatusChangerManager is invoked, and resulting status is sent to server.

Every StatusChanger can emit statusChanged slot and trigger status rebuild in chain.

Resolved

Now amarok module is replaced by mediaplayer (much more general module). All status-changing modules uses new classes. There is no problem like before, because all modules provides only 'operations' that changes copy of user status (so it is always remembered). After removing or changing one of 'operations' status is rebuild starting from the one that user set.

SplitStatusChanger

Kadu has class SplitStatusChanger (in status_changer.cpp). It allows for setting statuses with description of any length for Gadu Gadu. If it is too long for protocol to handle it - it is splited in number of parts. Each part is displayed for specified period of time.

If you want to test it - please find place in code suitable for inserting it in chain, also remove the description limit from status dialog (look in misc.cpp).

Crappy-code to Good-code transition

2008-12-23T11:17:00.000-08:00

The current Kadu code is crappy in many places. Like the contact-management part. This is realized by some classes that really weren't written after deep consideration:

* UserListElement
* UserListElements
* UserGroup
* UserList
* ULEPrivate

UserListElement is really a wrapper on ULEPrivate (using QExplicitlySharedDataPointer allows us to have many copies of UserListElement object that points to the same data).

UserListElements is a list of UserListElement. UserGroup is a set of UserListElements. Why there are two classes - nobody knows (it is really old code...).

UserList is a global list of all known contacts.

ULEPrivate stores all data for one contact.

Problem is how it stores the data - in three big hashes (one of them is really a hash of hashes...). Unfortunately - almost no comments. Also, the main hashes key's are protocol names (with one used - Gadu) - subhashes have keys as names of properties.

For Kadu 0.7.0 we need more elegant design. I started to rewrite contact-management and the results seems to be very good (at least a lot better). Now there are more classes (but with better names and one-class-one-task approach).

Each contact is now stored in Contact class (UserListElement was a cryptic name). Like in previous version data is hidden with QExplicitlySharedDataPointer and stored in ContactData class. ContactData contains QMap that maps accounts into ContactAccountData object (as in Kadu you can have multiple accounts, you also can be connectect with each of your contacts on each of your accounts). There will be something like ContactModuleData - each module (plugin) will be allowed to add new data to each contact.

Also ContactData contains (or will contain...) fields for data that is not specific per account - first/last name and so on.

Classes UserListElements/UserGroup will be merged as ContactList (QList with few additional methods). Class UserList will be replaced ContactManager.

Now code is in mixed-state: half of it used old classes, half uses new. There are conversion methods that allows to move data from one type to another, so code does not have to be ported at once.

Three people are doing the transition: uzi18, Juzef (they are from jabber-module team, so it is really important to them to make Kadu more multiprotocol) and me. And the work is progressing very, very fast ;)

About me and about Kadu

2008-12-20T06:23:00.000-08:00

Kadu is a Polish open-source IM client. Currently (version 0.6.5) it supports only proprietary Gadu-Gadu protocol, but in next version the Jabber XMPP will be also supported. We (the Kadu Team) are planning to make the best IM on the world ;)

And we have the power to really do it - Kadu in Poland is most popular Linux Gadu-Gadu client, and many of our users will use it instead of Psi when it gains XMPP support. We will have QGraphicsView-based contact list, Phonon-based multimedia support. We have chat dialog with full HTML and CSS support (thanks to WebKit), Kadu is the most configurable IM client out here - and the configuration dialog is really very convienant. We have our own usability team that work on upcoming 0.6.6 and 0.7 user interface.

We have support for plugins (called modules) and a lot of users that write their own modules - it is one of the reason Kadu is so popular (imagine kadupanel module that turns the window into hideable panel just like Kicker in KDE 3.5, or screenshot module that allows sending images of part of the screen directly in chat).

Some words about myself: my name is Rafał Malinowski, I'm a programmer from Poland and I'm working on Kadu project. I'm also working for Cognifide Poland, where I'm writing ASP.NET internet pages (like Setanta).

I'm going to write more about Kadu in this blog, to promote it and to improve my english and general writing skills ;)

I hope you will enjoy reading this blog.