Saturday, 22 November 2014

Injeqt 0.9.0 released

First official (beta!) version of Injeqt dependency injection library for Qt was released today. I can be downloaded from GitHub releases page.

For last 3 weeks I was working on Kadu and switching some parts of it to use Injeqt for its objects and services wiring. As it turns out, it all works very well already. There is no need to postpone Injeqt release until it gains additional features (and I have big plans for it).

0.9.x series will continue until Kadu 2.0 release with only bugfixes. I don't expect a lot of them (Injeqt has very nice unit tests coverage), but better safe than sorry. Exported API is very minimal and should not be changed (only extended) in a long time.

If you wish to try it - please do it now. I would be happy to see more use cases and real world applications before committing 100% to 1.0 release.

Enjoy!

Thursday, 20 November 2014

Kadu 2.0 progress

Yesterday I finished last big infrastructure item planned for 2.0 (roster simplification). There is one big feature left to do (Unity integration) and a few bugs. As there will not be (probably) version 1.3, all of bugs assigned to it will be moved to 2.0 release.

There is one scary thing to do after Unity integration - creating Windows build. New Kadu is based on Qt5 instead of old Qt4. This means we have to update also QCA and Iris libraries. My experience with releasing 1.0 tells me that this will not be easy at all.

As for now, Injeqt integration is going very well. 0.9.0 release of this library will come this month and 1.0 before Kadu 2.0. First C++ application with Guice-like dependency injection is coming to change the world :)

Tuesday, 4 November 2014

QMetaType in plugins

I've learned that for some uses QMetaType just does not work.

Imagine that you want to read types of parameters of some signal or slot of QObject. You also know that all parameters to this method are pointers to QObject-based types. The best way to do that is to:
  1. register your type with qRegisterMetaType<QObjectDerivedType>
  2. read parameter meta type id with QMetaMethod::parameterType(int)
  3. get QMetaObject of this parameter with QMetaType::metaObjectForType(int)
In most cases it works. But not when QObjectDerivedType lives inside a plugin that is dynamically loaded and unloaded several times during program execution (and this whole sequence is run on each plugin load).

On first load everything works perfectly. On second (or third or next, it is rather random and probably depends on allocation patterns in application) your QMetaObject from point 3 is invalid and using it causes access violation. Why? QMetaType remembers address of QMetaObject for each QObject based class pointer per program execution. On load a new QMetaObject is constructed for each type that lives in plugin. And on unload its memory is freed. In result the stored pointer just must to be invalid.

Maybe I missed something, but I was not able to get it to work properly. My solution is to use custom paramter-QMetaObject mapping instead of relying on QMetaType. It is based on QMetaMethod::parametrTypes() method that returns type name and a map of type-name to QMetaObject pointer that is created on each plugin load and passed around. I'm not very happy with this solution, because it is prone to namespace issues and it does not allow usage of types that are no preregistered in plugin (on the other side, QMetaType has the same problem). Hopefully C++ reflection will become real some day.

But there is one more thing that makes me happy - replacing first solution with second in my dependency framework Injeqt took some time and required non-trivial changes in library. But API and ABI remained the same - there was no need to recompile Kadu 2 to work with new version. It means that my usage of private and public interfaces, pimpls and anonymous namespaces is at least proper. This also closed last bug that blocked 1.0 release. This means I can now prepare beta 0.9 and focus on developing Kadu (also to test if Injeqt is really ready to be released).

Wednesday, 22 October 2014

Qt + CMake + code coverage

Yesterday I was working on getting reports on code coverage for Injeqt library. I've found several tutorials on the internet, but every one of them was missing a detail or two.

So here is what I've come with:

1. Update compiler and linker flags in CMakeLists.txt file of your tests:
set (CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wall -W -g
    -fprofile-arcs -ftest-coverage -O0")
set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -W  -g
    -fprofile-arcs -ftest-coverage -O0")
set (CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS}
    -fprofile-arcs -ftest-coverage -O0")
2. Link each test with gcov library:
target_link_libraries (test-target-name gcov)
3. Add new target for extracting coverage data:
add_custom_target (coverage
    COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/coverage.sh
    WORKING_DIRECTORY ${CMAKE_BINARY_DIR})
4. Insert coverage.sh script into directory of CMakeLists.txt:
#!/bin/bash

lcov --capture --directory . --output-file coverage.info
lcov --directory . --output-file coverage.info \
    --remove coverage.info "/usr/*" "*.moc" "test/*"
genhtml coverage.info
First lcov invocation will capture all data from previously executed tests. Second will remove useless data like coverage of generated moc files or of standard library headers and tests themselves.

5. Run tests and coverage:
make test
make coverage
6. Enjoy nice HTML coverage report.

Injeqt got 90,4% of lines coverage on first try! I hope to make it even better today.

Saturday, 11 October 2014

Recovery

On Monday, just before leaving for Qt Developer Day, I was polishing my presentation on Injeqt. Of course HDD decided to crash at the very moment before exporting final version to PDF and moving it to pendrive.

Fortunately I was able to quickly recreate what I've lost and even order new drive (this time SSD) before leaving and now I'm slowly getting all my stuff installed and set up for further development. Kadu and Injeqt progress is delayed just a few days.

After that is done I hope to move all bugs for 1.0 from forum to redmine and start working on them a little bit before returning to writing tests for Injeqt. Stay tuned!

Thursday, 2 October 2014

Injeqt on Qt Developer Days

Next week I'll be attending Qt Developer Days in Berlin.

I'm giving lighting talk about Injeqt - a dependency injection framework for Qt that you will fall in love with! I hope a lot of people will show up ;)

Tuesday, 30 September 2014

Merged Proxy Model is now LGPL

I was really ashamed today as I've found that Blogger was sending information about comments on the blog to my kindle e-mail... But also I've found that some people are interested in Merged Proxy Model described on this blog (but only as LGPL).

I've asked all developers that have their input in this nice solution and there it is:
available as LGPL2.1+ Enjoy!

Fixes from blog comments not yet included.

On versioning

Kadu 1.0 was released just a few days ago. It was a 14 years long journey to get here from beginning. From one side it feels like great accomplishment - version 1.0 marks application as mature and finished. From another - it is just a release like many before - I can honestly say that Kadu was ready for that number years ago and could now be much higher version.

But that is just a number - not of a very big importance as Chrome 37 and Firefox 32 shows us for a some time. For that reason I've decided to change Kadu versioning to be more Chrome and Firefox-like. Next feature version will be number 2 (bugfix will be 1.1) and will contain just a few minor features and be a big port to Qt5 (already 98% of that is done). It is possible it will be done before end of a year. 14 years from 0.1 to 1.0 and then 4 months from 1.0 to 2.0 - nice speedup :) Version 3.0 will some as soon as we replace Iris with another, more developer-friendly, XMPP/Jabber library (that will also include some minor features and maybe some major).

From yet another side - I'm very happy that I've postponed 1.0 so much since 1.0-alpha1. It took almost year to fix all bugs reported since (not all were very important). When alpha5 was released - almost no bugs were reported. I was so sure of that version that whole beta cycle was skipped and rc1 was released just after. It took five months and 11 rc versions to fix what people reported in rc series. But maybe just nobody wanted to test alpha versions? Who knows...

I hope that next releases will come more often and with smaller set of changes. Release early, release often.

Sunday, 17 August 2014

Lots of updates

Release candidates for Kadu 1.0 are now released weekly. With each I hope that it is the last one, but new bugs (not very critical, but still annoying) are reported. There is hope that final 1.0 will be released this month. I need to cleanup our wiki page and write release notes. That won't be long document, as only one or two major features were implemented. Most of the work was focused on fixing bugs and improving stability.

There is also progress on future release (2.0). Port to Qt5 is completed and first feature was implemented today - content of input box in chat widget is now persisted and can not be lost by accident. Kadu 2.0 will use my new injeqt library for managing dependencies between classes (I'll write about it more in couple of weekd). Its first version is very simple and will be finished in couple of months. It is very probably that Kadu 2.0 will be released in 2014.

Wednesday, 9 July 2014

Still fixing bugs...

I'm so happy ;)

After releasing semi-rc2 for Windows a few new bug were reported by our users. Progress is really good as bugs are removed, external plugins are ported. Even 64bit version for Windows is on the way.

Also a bit of work on Kadu 2.0 is being done so stay tuned ;)

Monday, 23 June 2014

Good news, everyone

Good news, everyone. Thanks to Tomek from libgadu and pidgin, I was finally able to build Kadu 1.0-rc2 for Windows. It lacks several plugins (all external ones, spellchecker and otr), but it works almost flawlessly.

You can find packages at my project at OpenSUSE Build Service. It is RPM that can be unpacked with 7zip It contains only one file - Windows installer. I will put installer on Kadu download pages when I resolve problems with spellchecker and otr plugins. Then I will start work on external plugins (probably some small maintenance will be needed).

Thursday, 12 June 2014

1.0-rc2

Kadu 1.0 is very very close to be released. Since last release candidate only a few bugs were found (and only one was serious) and all of them were fixed.

Now I'll focus again on making it work on Windows using OpenSuse Build Service. I won't promise anything, but I'll try to make it happen.

I'm also working on next release on Kadu - 1.1 or just 2 - that will be based on Qt5 instaed of Qt4. I still don't know what features will be introduced - first months of work are always dedicated to internals. I want Kadu 1.1/2 to use at least very simple dependency injection. That is why I'm also starting work on new dependency-injection library dedicated to Qt. Stay tuned ;) It will be amazing ;)

Tuesday, 13 May 2014

1.0 and 1.1 status update

Good news. Or bad news. Depends on point of view. No bugs were reported for 1.0-rc1 after release. It can mean that there are no more bugs or that no one is testing. In either way - if that stays as it is for the next 3 weeks - I'm gonna release 1.0 unchanged from rc1. Probably without Windows port.

Now about 1.1 (or maybe just Kadu 2 if we switch to Firefox/Chrome-like versioning). Beevvy did amazing job porting 90% of the Kadu to Qt5. I've ported remaining 9.9%. Last 0.1% will have to be abandoned. This probably caused some regressions that we are not aware of (and a few that I've found already). I'm going to fix that in following weeks and release 1.1-alpha1 as soon as possible. That will make 1.1 release a Qt5-port-only one.

I don't want to make mistake similar to when 0.6.0 was ported to Qt4 as 0.6.5 with so many additional changes it took a few months too long. I also hope that 1.1 will be ported to Windows.

Lets get to work!

Sunday, 6 April 2014

Kadu 1.0 for Windows

I've spent last few weeks trying to build Kadu 1.0 for Windows. I've failed. Many times.

Some time ago Bartek wrote set of bat files that helps building our project on Windows. Unfortunately they were a little bit out of date, so I worked a bit and updated what I could. After some time every dependency was compiling/downloading properly. Then come time for Kadu. It turns out that our C++11 usage was well over MSVC 2012 capabilities. Even well over MSVC 2013. After some adjustments (mostly removing noexcept keyword and brace-initializations here and there) MSVC started dumping internal compiler errors. WTF?

I'm a calm man, but that made me angry (remember, it took several days to get here). So I decided to switch to MINGW with GCC. And I've failed again. It seems I just don't get it*. After few more days of failing a decision was made to get back to MSVC and work around these compiler errors. A few more days and I had Kadu compiled properly with all required dependencies. So I ran it. It crashed. Debugger shown me nothing interesting - just a normal function that is executing a lot and that never crashed for me under Linux. Just for fun I've commented crashing line and got another one. And another. And one more.

So I've finally gave up. There is only one hope - that Bartek will have time and will to work on this.

* Currently I work for a company that does Windows software. I can compile it, debug it, add files, create projects and so on. So why I can't do this for Kadu? I don't know...

Wednesday, 12 March 2014

Status update

Hello.

It was long time since I've written anything here. So for just a quick update on what is going on:

  1. I've finally fixed English version of our web page. It was really unprofessionally looking with big error instead of screenshot on Home page and with bunch of chaotic characters on Download page.
  2. Since last post 2 alpha releases were made with one major fix of long-standing bug - some messages were not displayed at all and some were displayed twice.
  3. I use inverse of control more and more and it is working very well for code quality - it is now more testable than before.
  4. I also try to extract generic code where possible (like in sorted_unique_vector class) - it also improves code quality and makes is more testable.
  5. As a result of previous points, tests are added. Now we have only a dozen of them, but last year we had only one ;)
Lets go back to work!

Wednesday, 29 January 2014

Kadu 1.0-alpha3

Yesterday (28.01.2014) I was finally able to release 3rd alpha of Kadu 1.0. This took really long time for an alpha. A lot of code was commited (more than 300 individual commits), and even some unit tests were added!

There are several reasons that make this release a very good one in my opinion. It moves Kadu forward much more that alpha should:

  1. C++11 is used more and more, std::unique_ptr and move semantics are my best friends now - passing ownership of pointers is now easy and does not require special comments or documentation.
  2. Value semantics is used where it makes sense (less pointer passing, more immutability).
  3. In some places pointers were replaces with references, that removes burden of checking them for nullness.
  4. Preparation for Qt5 migration by Beevvy were merged, so hopefully full transition in 1.1 will be less painful.
  5. OSGi-like services are used more and more (see plugin subdirectory).
  6. Real and useful unit tests were added for new plugins code - not as much as I would like, but this is still a big progress form what we had before.
  7. Automoc is used more, so changing build files is easier.
  8. scan-build was executed and showed almost no bugs in Kadu core and plugins (most of them is fixed now)
But there are some things that I'm worried about:
  1. With service based code Core class becomes more and more messy, need for dependency injection library raises with every new service added (I plan to work on this just after Qt5 port).
  2. main.cpp code is still not cleaned up.
  3. Services does not seem to be split properly, some unneeded dependencies and extensive responsibilities can be seen in some places. On the other side, there are now many services for just plugin handling. I'm thinking that maybe a wrapper service is needed to present a one-point entry API for outside code?
  4. I noticed that with unit-tests around I tend to take less care of my code with a thought that 'every bug will be found by tests' - this is very bad and I need to fight with this new habit and go back to executing methods line-by-line in my head.
  5. I'm not sure if unit tests are very good (they have found some bugs), but I hope that will growing experience they will also became better.
Anyway, Kadu is in general getting better and better and still have a great future.