Category Archives: planetkde

Answer about “Akonadi for e-mail needs to die” blog

Yesterday morning I read planetkde.org as usual before to hack on kdepim and I saw this blog.

I thought that it was a constructive blog, but not!

(As all your articles on your blog about kdepim. I don’t understand why you are not able to switch to another mailer before.)
Mr “Andreas K. Hüttel” is just an user which was frustrated by a bug about his IMAP server.

I can confirm that KMail is not free bug, Akonadi is not perfect too. We work a lot each days to fix the bugs. You can make the same blog about each application which doesn’t work as you want. You can criticize all these programs and wrote that developers lose their time to work on. I hope that you wrote some blog as it for Kernel Linux, Xorg, LibreOffice etc. for sure they are not perfect too.

KDEPIM team is small but I think that we make a good work. Perhaps you should read kde-commit to see all fixes that we did…

But Mr “Andreas K. Hüttel” I can tell you:

  • Nobody forced you to use KMail ! We are in open-source world, you are not happy by an application you can use another one!
  • I didn’t see a patch from you about KMail to try to fix it. So how can you told us that it was an error to migrate to Akonadi (just because it doesn’t work for you?). Did you study on which technology it’s based ?
  • When you wrote ” What is dead should better remain dead, and not suffer continuous revival efforts while users run away and the brand is damaged.” Who are you to tell us to stop to develop  KMail based on Akonadi ?
  • “Also, I’m a volunteer myself and invest a lot of time and effort into Linux. I’ve been seeing the resulting fallout. It likely scared off other prospective help.” Ok so I will wait to see your work about the fork of kdepim based on qt4. I am sure that you will able to make better than us (poor kdepim team). You know you can port it to qt5 and we will see if you will be able to fix all bugs not just your bugs. I hope that you will able to reproduce all of them.

Now Mr “Andreas K. Hüttel” with a blog as it you will discourage for sure some new user/developer, but also people  which helps us, they will think that they’re wasting their time. It’s unacceptable. 

Mr “Andreas K. Hüttel” you just have NOT ANY respect for all work done by the KDEPIM team, by the doc team, by the i18n team, by all user support guys, by the users which reported bugs.

Mr “Andreas K. Hüttel” if a day you are able to work on a project you will see that it’s not possible to reproduce all bugs because we don’t have all the time, we don’t have the same environment. Fixing a bug take time when we can’t reproduce when it’s a corner case. Some time we don’t have the good technology as a specific server IMAP etc. But perhaps it’s too hard for you to understand it.

Ok Mr “Andreas K. Hüttel” it’s sad that we were not able to fix your bug, but it’s more sad that you think that all kdepim team work is a lost of time.

As I wrote who are you to tell us that it’s a lost of time ?

Do you provide a technical solution ? NO

So for your information we will not stop to develop KMail because you think it’s a lost of time. We will continue, I will continue because I know that a lot of people uses it and they are happy with KMail based on Akonadi. I will continue to “lose my time” each day as I respect users which use KMail, it’s not your case.

I want to thank all people which participate, all guys was participating  to KMail improvement. We make KMail better for sure. Thanks guys. Thanks Doc Team, Thanks I18n Team, Thanks User Team Support, Thanks happy users, Thanks not happy users which understand our work.

To conclude we are in open-source you are not happy you can use another application, all developer is  able to choice on which technology he wants to develop, but it’s really unacceptable as you reduce kdepim team work (and other teams) to a lost of time because you are just a frustrated person.

News about kdepim: Allow to build standalone each applications

Status

I worked harder during 6 days to allow to build each kdepim application as standalone.

I merged some sub-directories in other directory (for example agents in KMail. The agents depend against KMail), I moved some code in kdepim-addons etc.

This morning I added Superbuild support it’s a macro which allows to build each sub-directories as they were separate modules so we can test if build as standalone is not broken => all compiles fine.

Why I did it ?

It will help developers to compile just a module if he wants to debug/hack etc.

We continue to reduce difficulties to work on kdepim

When will I split in separate repositories ?

I decided to do it for 16.12 (it’s not a typo it’s not for 16.08). I prefer to be sure that all is ok before to process to split them.

 

How I can to build KMail (or others kdepim apps) as standalone in master kdepim git ?

It’s very easy, clone kdepim git master source:

git clone kde:kdepim.git

cd kdepim/kmail

mkdir build && cd build && cmake -DCMAKE_INSTALL_PREFIX=<path> ../ && make install

 

Status QtWebEngine in KDEPIM

As QtWebKit will be remove from official Qt package I decided some months ago to evaluate QtWebEngine.

For sure QtWebEngine < 5.6 was too limited. But I started to use it. I evaluated QtWebEngine 5.5 but some features were missing (as possibility to block request or use custom scheme url).

I started to focus on Akregator as it still used khtml, I migrated it to QtWebKit and after that to QtWebEngine. (For 16.04 there is a experimental option to activate compilation).

When I proved that it was possible to use in kdepim I started to port kmail. It was not easy as we use specific QtWebKit methods as QtWebElement which are sync method. In QtWebEngine we need to use async method.

So I started to create test application and autotests to validate my changes.

(For example I wanted to make sure that scamdetection works in QtWebEngine as it worked in QtWebKit).

Status in master

Akregator/Kontact/kmail can use QtWebEngine.

I created a new lib to replace composereditor-ng, named composereditorwebengine to make it possible to use QtWebEngine in Blogilo too. I finished it this morning.

I reimplemented AccessKey + AdBlock + ScamDetection support against QtWebEngine.

Future

I will continue to fix, implement features. Not all is finished (but I use by default KMail QtWebEngine so I can see bugs and fix them).

QtWebEngine in kdepim

As QWebKit is deprecated now (it’s not in official 5.6 package, but we still able to build by hand for 5.6 as distro will do) I investigated how to replace it by QWebEngine.

For sure QWebEngine  < Qt5.6 was not enough to replace it in akregator or others kdepim component.

For example QUrl custom scheme was not supported until 5.6.

So I decided to start porting kdepim against QtWebEngine. Some parts were easy as “about page” in kontact, others were harder as akregator support or others parts were not started yet (as remove QtWebKit in kmail for example).

This big problem is that QtWebEngine uses async method when QtWebKit used sync method.

So it was necessary to rewrite a lot of part of code (still in progress).

But my big success is Akregator which works fine with QtWebEngine.

In kdepim/messagelib/kdepimlibs I added an option for activate it. But it will not activate by default for 16.04 as it’s still not perfect yet.

I will continue this work until 16.08.

There is still a lot of work as:

  • reimplement adblock support (in progress)
  • reimplement accesskey
  • rewrite mail viewer to support it
  • rewrite blogilo lib based on QtWebEngine.

But it’s good and fun to do it 🙂

KDEPIM/KMail is NOT dead

This week I received several mails about kmail/kontact user which read the blog “The year of Kube” and asked me if “KMail is dead now?”. Or “KMail will be replace by Kube in the future?”

I answered that KMail and KDEPIM are still alive and they still continue to be maintain. We prepare actually the next release 16.04 with a lot of changes as:

  • all library are split for helping new developer to use them.
  • we created a system of plugins for kmail/kaddressbook/korganizer and we moved a lot of codes in theses new plugins (so we reduced code complexity in base application).
  • Akregator was refreshed (bugs fixing, move to qtwebkit rendering html, clean up UI)
  • New kmail quote support (modernize quote support as others mail applications)
  • Bug fixing and bug fixing.

So for sure kdepim/kmail is not dead.

 

What is Kube ?

Kube is a new project which started from scratch by the KolabSystem team, based on new backend named AkonadiNext which was renamed as Sink (developed by the KolabSystem team), and it uses QML as technology.

For the moment Kube is just a new email client.

They want to reimplement a new mail client and perhaps other pim components in the future.

They use some codes from kdepim (for example some part of code from the library messageviewer to rendering html).

We decided some months ago to split kdepim libraries to help external applications to use them (We knew that Kube wanted to use some part of codes). We didn’t want to see a fork of kdepim library.

 

What is KMail/Kontact/KDEPIM ?

It’s a suite of PIM application based on Akonadi technology

Kontact regroups some application as:

  • KMail: kde mail reader
  • KAddressBook: Address Book application
  • KOrganizer: organizer application
  • Akregator: Rss reader
  • SieveEditor: an sieve editor script
  • Kontact: an application which embedded kmail/kaddressbook/korganizer/knotes/akregator
  • PimSettingExporter: an application which import/export settings.
  • and other little programs.

KMail is the official KDE mail reader from long time.

 

Why we don’t switch to Kube and we didn’t kill kdepim/kmail ?

Because in Akademy 2015 we didn’t decide to do it. We decided to migrate step by step (on several years) to next backend but not start from scratch a new application. (It’s always critical to migrate to new technology so we take time).

We can’t migrate kdepim application directly without to be sure that new backend is ok and it works fine.

We can’t migrate to Sink if there is not a migrate application for existing data.

We can’t migrate to new backend if we are not sure that all resources are reimplemented (vcard resource, caldav resource etc.)

KMail/KDEPim is used from age. So we will not switch/break all in a release. We have a lot of users which will not understand if we trash all.

 

Future of KDEPIM?

We will continue to improve each components.

We will continue to read bugs reports and answer to user about them.

We will continue to add new features when they are useful.

We will continue to clean up code, clean up GUI.

We will continue to make KMail and other KDEPIM free bugs, and stable.

We will continue to rewrite kdepim application to allow in the future to move to “Sink” if possible.

 

To conclude

KMail/KDEPIM applications will be still in kde for future release.

Kube will not replace KMail in KDEPIM.

Kube will continue to be improved as an opensource project as other opensource project.

News about Akregator

As you know I decided to fix and improve Akregator for the next release (16.04 in april).

So this week I continued to improve QtWebKit support.

I readded:

  • Adblock support (We can add configure it in akregator config dialog)
  • Save image to disk
  • Adblock specific element in page.

I created a new Grantlee theme. The old theme dated before kde4…

During this work to create new theme I implemented “actions”. The actions is useful when we use a combined view. We can’t change status of article (for example it’s impossible to mark as read/important/unread, it’s static).

Now we can change status or delete article directly. It’s very useful. (see screenshot below akregator-newactions

Others changes:

  • Add action on tabbar (close all tab/close specific tab etc.)
  • Add radio button for view type (so now we know which type of view we use)
  • Clean up searchbar, we have filter actions directly in lineedit. akregator-searchline

Future:

I will try to close a lot of bug before next release.

I hope that you will be happy with new version.

 

Akregator

Once upon a time a program named Akregator.

It was born in 2004.

But it didn’t evolute during 6-7 years. It was a bad thing for an kdepim application.

Long time ago I worked on akregator2 (a akregator based on akonadi) but it was never released and there is no future for it.

So for the next release (16.04) I decided to work on. (It needs some love)

The first problem was that it used khtml as primary render web engine, it’s a very obsolete engine. (Ok if you installed kdewebkitpart it was able to use qtwebkit, but it’s not all the time).

So I decide to port to QtWebKit directy.

First impression: it’s speed ! (and there is less crash).

Second step I moved all generated html code (which display info about rss) to grantlee, so now it’s more easy to refresh html code.

Next step is to clean up code, and add new features (I have some ideas, and bugs.kde.org has some idea too)

So I hope to finish all the clean up for 16.04.

I hope that you will happy to use it and you will report bug about it.

Split kdepim and kdepim-addons

Last week after some months I finally split lib from kdepim.

Why?

The main reason is that I wanted to make life easy for new developers.

Until now when we wanted to develop an extension for kmail/kaddressbook or other kdepim application it was necessary to build all kdepim.

Now we can create plugins outside of kdepim or in new kdepim-addons repository (Which was created last week too).

Another reason is that these libraries can be used by kontact-quick and by applications as Zanshin (which duplicated libkdepim).

When?

I didn’t do for 15.12 but for 16.04. So I have time to fix all problems.

Where?

All split packages are in kde/pim repository

kdepim-addons

I created this repository for putting all kdepim plugins.

So we can found here:

– messageviewer plugins => header style plugins and messageviewer plugins (create todo etc.)

– pimcommon plugins => customtools plugins as shorturl and translator plugin

– kmail plugins => antispam/antivirus plugins

– kaddressbook plugins => merge contact/search duplicate contacts etc.

So now you can develop more plugins without compile all kdepim.

I will continue to convert features as plugins so we can reduce kdepim code base. And it’s more easy to disable a broken code when it’s a plugin.

Future:

I want to create plugins for korganizer too (I will add plugin support).

I would like to create plugin which uses some different language as c++ but I need to investigate how to create it 🙂

KDEPIM 5.0

KDEPIM 5.0 is the port of kdepim to kf5/qt5.

The porting was started in may 2014. It was a long way because kdepim is not just kmail. It’s based on Akonadi server and all libraries from kdepimlibs.

The first step was to make Akonadi worked against Qt5.

The second step was porting kdepimlibs to make it work with akonadi server and KF5.

The last step was porting kdepim to kdepimlibs.

But we are able to obtain a stable version for 15.08 !

What contains kdepim 5.0 ?

It contains all original applications:

  • KMail
  • KAddressBook
  • KOrganizer
  • Kontact
  • KAlarm
  • Blogilo
  • AccountWizard
  • KNotes
  • grantleeeditor*
  • importwizard

What applications were removed?

KNodes was not ported to KDE4 pure and there is not a maintainer for it. So it was a big work for me if I wanted to port to pure KDE4 and porting after that to kf5

KTimeTracker was not maintains during some years and it was not really a pim application.

KDEPIM-Mobile: it was removed too because it depends against QtQuick1.0 it was not tested in 4.14 so in KF5 it was completly broken. So if some guy wants in the future to have it, it will be necessary to rewrite all.

KMailCVT: it was merged in the application importwizard.

What is news in kdepim 5.0?

  • First at all we ported to Qt5/KF5 🙂
  • New composer for KMail which has search/replace component integrated in composer directly.
  • contactprintthemeeditor allows to create some grantlee theme for kaddressbook
  • KAddressBook allows to send vcard file directly
  • Now we can manage IMAP folder which can be show in KOrganizer/KAddressBook.
  • Now we can share url on social network (as Facebook/Twitter etc.)
  • Add support for texttospeech based on Qt5TextToSpeech (which is not release yet).
  • Pimsettingexport has a console program now. (so we can backup from a script directly)
  • I merge all setting for email completion in an unique dialog.
  • SieveEditor has bookmark support.
  • a lot of others features that I don’t remember 🙂
  • KContacts has full vcard4 support.
  • Dan made a big work on Akonadi. He speeded up it a lot. It’s very fast now.

Future:

The future is in progress 🙂 KF5.1 is in development.

We have some new feature:

  • Sieveeditor has debug script support implemented based on “sieve-test” application.
  • KAddreebook has complement gravatar support
  • KAddressbook can display image based on an url
  • A lot of optimization was done
  • Some obsolete features were removed during Akademy coding session

KDEPIM report (week 26)

My focus was KAddressBook last week.

KAddressBook:

It’s not a complicated application, so I didn’t find a lot of bugs. But indeed as I maintain it I already fixed critical bugs.

Some fixes:

  • I improved gravatar support.
  • I added “Server Side Subscription” action. Before that it was necessary to go to kmail or go to resource settings and click on “ServerSide subscription” button. I was not userfriendly.
  • I continued to clean up code and I use new qt5 connect api.
  • I fixed a lot of bugs (as layout bugs etc.)

Other works in KDEPIM:

  • I fixed LDAP support which was broken when we ported it to QUrl now we can use it. It’s great 🙂
  • I fixed translation in korganizer.
  • AkonadiSearch dbus interface name was changed. So we couldn’t have email indexing information. Fixed.
  • I fixed Imap Resource interface too.
  • A lot of bugs were fixed in korganizer/kmail/sieveeditor etc.

Future:

Next week I will focus on KNotes and Kleopatra.

Other info:

Dan merged his work about replacing text protocol by a binary protocol for Akonadi. I confirm it’s faster.

He worked a lot to improve speed. Now kmail is very speed 🙂

I hope that he will add more speed patch 🙂

Sergio continued to add some optimizations in kdepimlibs/kdepim/akonadi. !!!