Tuesday, 31 March 2015

End of Facebook Chat support

This is sad announcement. Kadu 3 will have its Facebook Chat support removed. There will be no longer possibility to add or use Facebook accounts and existing accounts will stop working. It is not Kadu fault. Facebook is closing its XMPP gates on 1.05.2015 [1] and their own protocol is not accessible for third party applications.

[1] https://developers.facebook.com/docs/chat

Tuesday, 3 March 2015

Moved to Gitlab

As you may know, Gitorious is merging with Gitlab. That means Kadu repository was also moved there: https://gitlab.com/kadu/kadu. Github repository will be kept as mirror.

Saturday, 7 February 2015

Kadu nightly for Windows

If you are interested in testing Kadu we have great news for you: since today nightly Windows builds of 2.0 and 3.0 are available under http://download.kadu.im/nightly/. Enjoy!

Thursday, 5 February 2015

New development model

Since Kadu 1.0 I'm working with new development model. It was first described in On versioning post. Its basic idea is very simple: release often, underpromise and overdeliver. Thanks to this 1.0 series had already 5 bugfix releases (last one, 1.5, was released just two weeks ago), 2.0 is almost released and work on 3.0 is underway.

Work on 2.0 was started very quickly around 1.0 release (to be completely honest, most of Qt5 port work was done by beevvy a long time ago). I didn't made big plans for it - just finish Qt5 port and add a few small features (and, of course, fix as much bugs as possible). And now it is almost release ready (rc2 will be available this weekend) and work on Kadu 3.0 is already progressing very nicely (this time with 100% support of file transfers in Gadu Gadu).

This is possible thanks to change of my own mentality (underpromise instead of overpromise) and to much improved source code quality - it is easier to make changes than 10 to 5 years ago. Also openSUSE Build Service is a great help - working Windows installer can be available just a hour after any commit.

So, get ready for 2.0 and for 3.0 testing!

Saturday, 24 January 2015

Injeqt 1.0.0

There is not much to say. I'm working with Injeqt (Qt dependency injection library) for some time now, preparing to release Kadu 2.0, and I've not encountered any problems at all. It is great to have only one feature and have full tests coverage for it. So here it is, 1.0.0 release!

I really enjoy using this small library, but I've also learned that I wish it have some more features:


I would like to use main Kadu injector in plugins code in a normal way. I would like to have a class with following header file and setters invoked by injector:

class ChatNotifier : public Notifier
private slots:
  INJEQT_SETTER void setChatWidgetRepository(
    ChatWidgetRepository *chatWidgetRepository);
  INJEQT_SETTER void setFormattedStringFactory(
    FormattedStringFactory *formattedStringFactory);

auto plugin_injector = injeqt::injector(
  plugin_modules, main_injector);
auto notifier = plugin_injector.get<ChatNotifier>();

Currently it is not possible - list of classes supported by injector is immutable and set on injector creation. And class ChatNotifier need to be added later, as it is in dynamically loaded plugin. So this code must be used:

class ChatNotifier : public Notifier
  void setChatWidgetRepository(
    ChatWidgetRepository *chatWidgetRepository);
  void setFormattedStringFactory(
    FormattedStringFactory *formattedStringFactory);

auto notifier = new ChatNotifier{this};

Subinjectors will solve this problem. Injectors will be able to have a parent injector and known all of its objects so it will be able to use them in an easy way.

As this is the feature that I miss most, it will be included in Injeqt 1.1 that will be released just before Kadu 3.0 (hopefully in about 3 or 4 months).


Injeqt should have an option to recognize matching signals and slots in objects that it creates and connect them automatically. I'm not 100% about the semantics of it (should it create objects just to connect to them even if application does not use them yet or should it wait for application to ask for an object to create it and connect). This is much more complicated to implement than subinjectors, so it is postponed to some next release.

Wednesday, 7 January 2015

QtSingleApplication replacement for Qt5

Kadu uses QtSingleApplication to ensure that only one instance can run on one profile at a time.

Unfortunately this solution is not compatible with Qt 5, so I've decided to update it a bit. My solution is available at gitorious. It uses code from Nokia solution, so I hope I got the licencing and copyright right (it is LGPL - one of the licences from Nokia's original files).

It has different interface from original one - 3 lambdas are accepted as constructor parameters. One for running first instance, one for running second and one for accepting messages. Not very Qt-ish but possibly less error prone.