Since no news on this site have been published since nearly three months, I feel like I should give a short update on the development progress of KMobileTools.

But let me first say that I'm a bit unhappy about the current situation. RockMan, who initiated the project and did a very good job with KMobileTools the last years, didn't show up the last two months. Since he doesn't respond to e-mails too, I fear like he won't be a great help the following months. So the situation is that I'm currently refactoring and redesigning KMobileTools alone which is just too much work for one single person. Now if you feel like helping me out, please join #kmobiletools on freenode. There is a lot of interesting work to do which varies in level of difficulty, so I have even work for a kde newbie :-)

Back to the current state of development:
KMobileTools in its state of 0.5-beta3 suffered from several problems, the most important were:
- instability
- clumsy APIs
- inflexibility

To mention just one example: KMobileTools uses so called "engines" which do the actual work and handle the communication between phone and computer (or can be just another abstraction layer as it is the case with gammu). Now not every engine has the same features. For example, the AT engine provided access to the phone's filesystem for some phones.
Now the problem is that if you wanted to implement an engine, you had to implement every possible feature even if your engine could not provide it. Imagine what had happened if the gammu engine wanted to provide additional features: right, we had had to extend the public engine API which would have caused a binary break on every feature addition.

But even if you had flexible APIs, you needed to have a flexible front-end which makes use of your api. For example if you added a feature "ringtone management" to the engine APIs, you would have no counterpart on the gui which triggered the ringtone management functions.

To circumvent this problems, I had to completely replace the core part of KMobileTools by a more flexible approach which makes use of interfaces. Now we define one interface for one phone feature (e.g. address book) and an engine can decide which interfaces it wants to implement. We could even add new interfaces (and thereby features) without breaking binary compatibility.
As counterpart to the interface-driven engines, I introduced so called "services" which can e.g. provide a gui for a feature. The services are also based on interfaces.

So the new approach is based on a key-lock principle where an engine is the key and a service is a lock.
Beside this major change, I did a lot of kde3->kde4 porting and made extensive use of Qt's new model-view architecture.

To be honest, I'm not progressing as well as I wanted to. KMobileTools in its current state needs a bit of work to make it useful again. The most urgent parts which need refactoring are the configuration management and a sms service.

But nevertheless I think you can be curious about the upcoming KMobileTools kde4 version :-)

Matthias Lechner (matlec)