Qt containers and C++11 range-based loops

Much has been written on teh interwebs about performance of iterations over Qt containers with Q_FOREACH vs. std iterators vs. Java iterators. However there is [very little][1] about how the new C++11 range-based loops work with Qt containers (or maybe I just suck at Googling, but well here I am…). Today I found out that there is a little catch that one has to be very careful about when using range-based loops with Qt containers.

Qt containers are all implicitly shared classes, which means that copying them is very cheap since only shallow copy occurs. When a shared copy is modified (or rather when a non-const method is called) it calls detach() and performs the expensive deep copy. When there are no other copies of the object (i.e. when the reference count is 1) no copying happens when detach() is called. We say that such instance is “not shared”.

To get to the point - the code below performs equally fast in both cases:

QStringList list{ "1", "2", "3", .... };
Q_FOREACH (const QString &v, list) {
   ...
}

for (const QString &v : list) {
  ...
}

However in the following code range-based loop will perform much worse than Q_FOREACH.

class MyClass
{
public:
   ...
   QStringList getList() const { return mList; }
   ...
private:
   QStringList mList;
};

...

Q_FOREACH (const QString &v, myObject.getList()) {
   ...
}

for (const QString &v : myObject.getList()) {
  ...
}

The difference between the first example and this one is that the QStringList in this example is shared, i.e. reference count of it’s data is higher than 1. In this particular case one reference is held by myObject and one reference is held by the copy returned from the getList() method. That means that calling any non-const method on the list will call detach() and perform a deep copy of the list. And that is exactly what is happening in the range-based loop (but not in the Q_FOREACH loop) and that’s why the range-based loop is way slower than Q_FOREACH in this particular case. The example above could be even simpler, but this way it highlights the important fact that returning a copy from a method means that the copy is shared and has negative side-effects when used with range-based loops. Note that if the method would return a const reference to QStringList, everything would be OK (because const …).

The reason for the speed difference is one peculiarity of Qt containers: they have a const overload of begin() which does not call detach(). Q_FOREACH internally makes a const copy of the list, so the const overload of begin() gets called instead of the non-const one.

On the other hand the range-based loop does not take any copy and simply uses the non-const version of begin(). As we explained above, calling non-const methods on shared Qt containers performs a deep copy. Only exception is when the container itself is const because then the const version of begin() is called and the code will behave the same as Q_FOREACH.

Ironically with stdlib containers (std::vector for example) the situation is exactly the opposite. std iterators are not shared classes so making a copy of an std container always performs a deep copy, but calling a non-const method does not trigger any copying. That means that Q_FOREACH, which always takes a copy of the container would be doing a deep copy in such case while range-based loop, which only calls begin() and end() would not be triggering any copying. Although std containers provide cbegin() and cend() methods to get const interators, there’s no need for the range-based loop to use them, since begin() and end() will always perform equally well on std containers.

To prove my point, here is the benchmark code I used. It’s an extended version of an [older benchmark of Qt containers][2].

#include <QStringList>
#include <QObject>
#include <QMetaType>
#include <qtest.h>
#include <cassert>

enum IterationType
{
    Foreach,
    RangeLoop,
    Std,
    StdConst
};

Q_DECLARE_METATYPE(IterationType)

class IterationBenchmark : public QObject
{
    Q_OBJECT
private Q_SLOTS:
    void stringlist_data()
    {
        QTest::addColumn<QStringList>(&quot;list&quot;);
        QTest::addColumn<IterationType>(&quot;iterationType&quot;);
        QTest::addColumn<bool>(&quot;shared&quot;);

        const int size = 10e6;
        QStringList list;
        list.reserve(size);

        for (int i = 0; i < size; ++i) {
            list << QString::number(i);
        }

        QTest::newRow(&quot;Foreach&quot;) << list << Foreach << false;
        QTest::newRow(&quot;Foreach (shared)&quot;) << list << Foreach << true;
        QTest::newRow(&quot;Range loop&quot;) << list << RangeLoop << false;
        QTest::newRow(&quot;Range loop (shared)&quot;) << list << RangeLoop << true;
        QTest::newRow(&quot;Std&quot;) << list << Std << false;
        QTest::newRow(&quot;Std (shared)&quot;) << list << Std << true;
        QTest::newRow(&quot;Std Const&quot;) << list << StdConst << false;
        QTest::newRow(&quot;Std Const (shared)&quot;) << list << StdConst << true;
    }

    void stringlist()
    {
        QFETCH(QStringList, list);
        QFETCH(IterationType, iterationType);
        QFETCH(bool, shared);

        if (!shared) {
            // Force detach
            list.push_back(QString());
            list.pop_back();
        }

        int dummy = 0;
        switch (iterationType) {
        case Foreach:
            QBENCHMARK {
                Q_FOREACH(const QString &amp;v, list) {
                    dummy += v.size();
                }
            }
            break;
        case RangeLoop:
            QBENCHMARK {
                for (const QString &amp;v : list) {
                    dummy += v.size();
                }
            }
            break;
        case Std:
            QBENCHMARK {
                QStringList::iterator iter = list.begin();
                const QStringList::iterator end = list.end();
                for (; iter != end; ++iter) {
                    dummy += (*iter).size();
                }
            }
            break;
        case StdConst:
            QBENCHMARK {
                QStringList::const_iterator = list.cbegin();
                const QStringList::const_iterator = list.cend();
                for (; iter != end; ++iter) {
                    dummy += (*iter).size();
                }
            }
            break;
        }
        assert(dummy);
    }
};

QTEST_MAIN(IterationBenchmark)
#include "iterationbenchmark.moc"
$ moc iterationbenchmark.cpp > iterationbenchmark.moc
$ g++ iterationbenchmark.cpp `pkg-config --cflags --libs Qt5Core` `pkg-config --cflags --libs Qt5Test` --std=c++11 -fPIC -O3 --o iterationbenchmark
$ ./iterationbenchmark
********* Start testing of IterationBenchmark *********
Config: Using QtTest library 5.4.2, Qt 5.4.2 (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 5.1.1 20150422 (Red Hat 5.1.1-1))
PASS   : IterationBenchmark::initTestCase()
PASS   : IterationBenchmark::stringlist(Foreach)
RESULT : IterationBenchmark::stringlist():&quot;Foreach&quot;:
     48 msecs per iteration (total: 96, iterations: 2)
PASS   : IterationBenchmark::stringlist(Foreach (shared))
RESULT : IterationBenchmark::stringlist():&quot;Foreach (shared)&quot;:
     48 msecs per iteration (total: 96, iterations: 2)
PASS   : IterationBenchmark::stringlist(Range loop)
RESULT : IterationBenchmark::stringlist():&quot;Range loop&quot;:
     53.5 msecs per iteration (total: 107, iterations: 2)
PASS   : IterationBenchmark::stringlist(Range loop (shared))
RESULT : IterationBenchmark::stringlist():&quot;Range loop (shared)&quot;:
     177 msecs per iteration (total: 177, iterations: 1)
PASS   : IterationBenchmark::stringlist(Std)
RESULT : IterationBenchmark::stringlist():&quot;Std&quot;:
     51 msecs per iteration (total: 51, iterations: 1)
PASS   : IterationBenchmark::stringlist(Std (shared))
RESULT : IterationBenchmark::stringlist():&quot;Std (shared)&quot;:
     179 msecs per iteration (total: 179, iterations: 1)
PASS   : IterationBenchmark::stringlist(Std Const)
RESULT : IterationBenchmark::stringlist():&quot;Std Const&quot;:
     53 msecs per iteration (total: 53, iterations: 1)
PASS   : IterationBenchmark::stringlist(Std Const (shared))
RESULT : IterationBenchmark::stringlist():&quot;Std Const (shared)&quot;:
     52 msecs per iteration (total: 52, iterations: 1)
PASS   : IterationBenchmark::cleanupTestCase()
Totals: 10 passed, 0 failed, 0 skipped, 0 blacklisted
********* Finished testing of IterationBenchmark *********

Both Q_FOREACH cases are equally fast because as we explained above, Qt always uses the const iterators and no deep copying happens. Range-based loop with non-shared list performs equally well, because even though it calls detach(), there are no copies to detach from and so no deep copy occurs. However range-based loop with a shared list is over 3 times slower, because detach() here will actually perform a deep copy. The same happens with for loop with non-const std iterators, which is basically just expanded version of range-based loops (range-based loops are just a syntactic sugar for for loops with non-const std iterators). For loops with const std iterators perform equally well as Q_FOREACH, because that is what Q_FOREACH does internally.

To sum this up, when using range-based loops with Qt containers:

Make sure the container is const …

// shared, but const, forces call to QStringList::begin() const,
// which does not call detach()
const QStringList list = objectOfClassA.getList();
...
for (const QString &amp;v : list) {
   ...
}

… or make sure the container is not shared.

// shared and non-const
QStringList list = objectOfClassA.getList();
// call to non-const method causes detach() and deep copy,
// 'list' is now non-shared
list.append(QLatin1String(&quot;some more data&quot;));
...
// calls non-const begin(), but detach() of non-shared
// containers does not perform deep copy
for (const QString &amp;v : list) {
   ...
}

Note that this just moves the slow deep-copying outside of the loop, but the deep copy still occurs. The point is that you need to be careful not to create a new copy of the ‘list’ after it has been detached on line 5, but before passing it to the loop on line 9. Failing to do so would make the list shared again and the loop would trigger yet another deep copy.

I was very excited when range-based loops were added in C++0x and I’ve been using them in some new C++11 code I wrote since then. But in Qt-based code I’ll be reverting back to the much safer Q_FOREACH. While it is possible to have range-based loops as fast as Q_FOREACH as we’ve shown above, one has to be really careful and constantly think about whether the container is non-shared or at least const and use Q_FOREACH if not. For that reason using Q_FOREACH everywhere is much safer for now.

I know that this is not any ground-breaking revelation and many of you probably even know of it, but I hope that it will still be useful for people who are not aware of the implementation details of Q_FOREACH and range-based loops, or just like me did not realize the importance of difference between shared and non-shared container instance.

[1] http://blog.qt.io/blog/2011/05/26/cpp0x-in-qt/ [2] https://blog.qt.io/blog/2009/01/23/iterating-efficiently/

Plasma 5.3 for Fedora

Fedora logoPlasma 5.3, new feature release of KDE workspace, has been released on Tuesday and you can get it now on Fedora.

Plasma 5.3 brings new features, improvements and almost 400 bug fixes for basically all of its components ranging from power management to various applets.

For users of Fedora 20 and Fedora 21 the traditional COPR repository has been updated. If you already use it just do yum update. If you want to switch to Plasma 5 from KDE 4 just follow the instructions on the main page.

Fedora 22, which is currently in beta, already has the 5.3 update in updates-testing and we are continuously polishing the update. For all KDE users updating to Fedora 22, when it's released in May, it will also mean final bye bye to KDE 4 and switch to Plasma 5. Fedora 22 repositories also features the latest release of KDE Telepathy, which finally brings IM integration into Plasma 5.

If you want to try out Plasma 5.3 on Fedora but don't want to install it on your computer yet there's, as always, a live ISO available for you based on Fedora 22 beta. And this time I did include a working installer (for real!), so when you change your mind just click "Install" ;-)

We welcome any feedback and testing from users, feel free to report any bugs to bugzilla.redhat.com, talk to us on #fedora-kde IRC channel on Freenode or join our mailing list.

What happened in Toulouse?

... a KDE PIM sprint happened in Toulouse! And what happened during that sprint? Well, read this wholly incomplete report!

Let's start with the most important part: we decided what to do next! On the last PIM sprint in Munich in November when Christian and Aaron introduced their new concept for next version of Akonadi, we decided to refocus all our efforts on working on that which meant switching to maintenance mode of KDE PIM for a very long time and then coming back with a big boom. In Toulouse we discussed this plan again and decided that it will be much better for the project and for the users as well if we continue active development of KDE PIM instead of focusing exclusively on the "next big thing" and take the one-step-at-the-time approach. So what does that mean?

We will aim towards releasing KF5-based KDE PIM in August as part of KDE Applications 15.08. After that we will be working on fixing bugs, improving the current code and adding new features like normally, while at the same time preparing the code base for migration to Akonadi 2 (currently we call it Akonadi Next but I think eventually it will become "2"). I will probably write a separate technical blog post on what those "preparations" mean. In the meantime Christian will be working from the other side on Akonadi 2 and eventually both projects should meet "in the middle", where we simply swap the Akonadi 1 backend with the Akonadi 2 backend and ship next version. So instead of one "big boom" release where we would switch to Qt 5 and Akonadi 2 at the same time we do it step-by-step, causing as little disruption to user experience as possible and allowing for active development of the project. In other words WIN-WIN-WIN situation for users, devs and the KDE PIM project.

I'm currently running the entire KDE PIM from git master (so KF5-based) and I must say that everything works very well so far. There are some regression against the KDE 4 version but nothing we couldn't handle. If you like to use bleeding-edge versions of PIM feel free to update and help us finding (and fixing) regressions (just be careful not to bleed to death ;-)).

Another discussion we had is closely related to the 15.08 release. KDE PIM is a very huge code base, but the active development team is very small. Even with the incredible Laurent Montel on our side it's still not enough to keep actively maintaining all of the KDE PIM (yes, it's THAT huge ;-)). So we had to make a tough decision: some parts of KDE PIM have to die, at least until a new maintainer steps up, and some will move to extragear and will live their own lives there. What we release as part of KDE Applications 15.08 I call KDE PIM Core and it consists of the core PIM applications: KMail, KOrganizer, KAddressbook, Kleopatra, KNotes and Kontact. If your favorite PIM app is not in the list you can volunteer as a maintainer and help us make it part of the core again. We believe that in this case quality is more important than quantity and this is the trade-off that will allow us to make the next release of PIM the best one to date ;-).

Still related to the release is also reorganization of our repos, as we have some more splitting and indeed some merging ahead of us but we'll post an announcement once everything is discussed and agreed upon.

Thanks to Christian's hard work most of the changes that Kolab did in their fork of KDE PIM has been upstreamed during the sprint. There are some very nice optimizations and performance improvements for Akonadi included (among other things), so indeed the next release will be a really shiny one and there's a lot to look forward to.

Vishesh brought up the topic of our bug count situation. We all realize the sad state of our PIM bugs and we talked a bit about re-organizing and cleaning up our bug tracker. The clean up part has already begun as Laurent with Vishesh have mass-closed over 850 old KMail 1 bugs during the sprint to make it at least a little easier to get through the rest. Regarding the re-organization I still have to send a mail about it but a short summary would be that we want to remove bugzilla components and close bugs for the apps we decided to discontinue and maybe do a few more clean up rounds for the existing bugs.

I'm sure I've forgotten something because much more happened during the sprint but let's just say I'm leaving some topics for others to blog about ;-).

Huge thank you to Franck Arrecot and Kevin Ottens for taking care of us and securing the venue for the sprint! All in all it was a great sprint and I'm happy to say that we are back on track to dominate the world of PIM.

The only disappointment of the entire sprint was my failure to acquire a French beer. I managed to try Belgian, Spanish, Mexican and Argentinian beer but they did not serve any French beer anywhere. Either there's no such thing or it must be really bad...:-)

KDE PIM Sprint in Toulouse We had a great dinner with the local KDE people on Saturday. Also a prove that Laurent is a real person :-D

Fedora RPM: Automatic "Provides" for CMake projects packages

If you ever did any RPM packaging (not just on Fedora) you probably noticed that some SPEC files don't use package names in BuildRequires fields but instead they refer to pkg-config module names, like this:

Name:           qt5-qtbase
Version:        5.4.1
Release:        1%{?dist}
...
BuildRequires:  pkgconfig(dbus-1)
BuildRequires:  pkgconfig(fontconfig)
BuildRequires:  pkgconfig(gl)
BuildRequires:  pkgconfig(glib-2.0)
BuildRequires:  pkgconfig(gtk+-2.0)
...

This is achieved by the respective packages simply having these aliases as their Provides (for example dbus-devel package Provides: pkgconfig(dbus-1)). The Provides are extracted automatically by an RPM script when the package is being built which gave me an idea...what if we could do the same for CMake modules?

And so I've written a simple script for RPM which extracts CMake package name and version from the package config files installed to /usr/lib/cmake. Simply put it means that kf5-kcoreaddons-devel will have

Provides:       cmake(KF5CoreAddons) = 5.8.0

and qt5-qtdeclarative-devel will have

Provides:       cmake(Qt5Qml) = 5.4.1
Provides:       cmake(Qt5Quick) = 5.4.1
Provides:       cmake(Qt5QuickTest) = 5.4.1
Provides:       cmake(Qt5QuickWidgets) = 5.4.1

...and all this happens automatically :-)

So, if you are packaging a CMake-based projects for Fedora you don't have to wonder which package provides the needed dependencies but you can just use the name from find_package() in BuildRequires and be done with it.

Name:           plasma-workspace
Version:        5.2.1
Release:        6%{?dist}
Summary:        Plasma workspace, applications and applets
...
BuildRequires:  cmake(Qt5Widgets) cmake(Qt5Quick) cmake(Qt5QuickWidgets) cmake(Qt5Concurrent) cmake(Qt5Test) cmake(Qt5Script) cmake(Qt5Network) cmake(Qt5WebKitWidgets)
BuildRequires:  cmake(Phonon4Qt5)
BuildRequires:  cmake(KF5Plasma) cmake(KF5DocTools) cmake(KF5Runner) ...
...

Another advantage is that this makes it easier to automate dependencies extraction from CMakeLists because we will no longer have to bother with mapping the CMake names to package names (for reference I have wrote a script to mass-update dependencies of all our KDE Frameworks 5 packages in Fedora).

We have pushed the script into Fedora's cmake package (currently in rawhide and (soon) in F22 but eventually I'd like to have it in F20 and F21 too) so all packages that will be rebuilt after this will get the automatic Provides.

In the long-term we would like to try to get the script to upstream RPM so that other distributions can use this too. For now the script is available in cmake package distgit.

Plasma 5.2 arrives to Fedora

It's here! Plasma 5.2 has been released just yesterday and you don't have to wait a single minute longer to update your beloved Fedora boxes :-)

I won't go into detail here about all the new awesome things that are waiting for you in Plasma 5.2, but I totally recommend that you go and read Plasma 5.2: The Quintessential Breakdown by Ken Vermette while you are waiting for your package manager to wade through the update. You can also read the official Plasma 5.2 release announcement, it has fancy animated screenshots ;).

And there's other news related to Plasma 5.2 and Fedora: Fedora rawhide has bee updated to Plasma 5.2 too. This means that KDE SIG will ship Plasma 5 in Fedora 22! Of course we will still maintain the Copr repository for our Fedora 20 and Fedora 21 users.

So, how to get Plasma 5.2 on Fedora?

On rawhide, just do dnf update. On Fedora 20 and Fedora 21, if you are already running Plasma 5.1.2 from dvratil/plasma-5 Copr, then all you need to do is to run dnf update. If you are running Plasma 5.1.95 (aka Plasma 5.2 beta) from dvratil/plasma-5-beta Copr, then it's time to switch back to stable:

dnf copr disable dvratil/plasma-5-beta
dnf copr enable dvratil/plasma-5
dnf update

If you are still running KDE 4 and you want to update to Plasma 5.2, just follow the instructions on dvratil/plasma-5 Copr page.

And if you don't feel like installing Plasma 5 on your production box right away and would like to just try it out, there's a live ISO for you. This time I did not forget to add Anaconda, so once you decide that Plasma 5 is good enough for you, you can just install it right from the ISO ;-)

EDIT: I might have included Anaconda, but did not add grub2 to the ISO, so the installer would fail anyway. This has been fixed and updated images are available now on the same link. If you are planning to install from the live ISO, please download the updated images (29-Jan-2015 00:42)

 

Oh, and if anyone is around in Brno next week for DevConf, let us know and we can informally meet for ceremonious consumption of beer to celebrate the Plasma release ;)

Plasma 5.2 Beta available for Fedora testers

On Tuesday KDE has released first beta of the upcoming Plasma 5.2. Plasma 5.2 is adding many new features and improvements and we would welcome testers to help find and fix bugs before the final release.

Fedora 21 with Plasma 5.2 beta Fedora users are welcome to try out Plasma 5.2 beta, either by running Fedora Plasma 5.2 beta live ISO, or by installing packages from plasma-5-beta Copr (see Installation Instructions on the Copr page)

Check out the release announcement to see what new features and improvements are waiting for you in Plasma 5.2. Final release will be in two weeks on January 27, after that we will update the plasma-5 Copr to get the update to all our users :-)

KDE Frameworks 5.3 and KDE Plasma 5.1 for Fedora are ready!

Fedora KDE SIG is happy to announce that latest version of KDE Frameworks 5 have just reached stable repositories of Fedora and  brand new version of KDE Plasma 5 is now available in the our Plasma 5 COPR.

KDE Frameworks 5.3.0

The third release of KDE Frameworks brings mostly bugfixes. KDE Frameworks 5 is a collection of libraries and software frameworks created by the KDE community. It's an effort to rework KDE 4 libraries into a set of individual and independent, cross platform modules that will be readily available to all Qt-based applications.

KDE Frameworks 5 are available in official Fedora repositories for Fedora 20 and the upcoming Fedora 21.

KDE Plasma 5.1

Fedora 20 running KDE Plasma 5KDE Plasma 5 is the next generation of KDE workspace based on Qt 5 and KDE Frameworks. It's latest version brings many bug fixes, performance improvements but also many new features! Dark color theme for the Breeze style, more widgets, improved Task switcher, reworked tray icons and much more. You can read about all the new things in Plasma 5.1 in the official release announcement.

To install KDE Plasma 5 on Fedora, just add the Plasma 5 COPR repository to yum, and simply run yum install plasma-5.

Live ISO

Do you want to give Plasma 5 a try, but don't want to install it yet? Easy! We have prepared a live ISO image based on Fedora 20 for you! You can get it from here: http://pub.dvratil.cz/plasma/iso/5.1/ (use Torrent for faster download).

Do you need help? Come talk to us: either on #fedora-kde IRC channel on Freenode, or join our mailing list kde@lists.fedoraproject.org.

Fedora 20 running KDE Plasma 5

I'm going to Akademy 2014 in Brno!

What am I going to do there? I will give a short talk on Saturday at 11:35 about what we have achieved in Akonadi in the past year and I'll be attending the KDE PIM BoF on Tuesday morning - you are all invited of course to join us in discussions about the future of KDE PIM! Possibly I'll also go to KTp BoF (purely for nostalgic reasons) and Solid BoF (did someone mention KScreen?).

I tried to list some talks I want to attend, but as I was browsing the program I realized I want to attend all of them. Seriously! So many interesting talks and so many things to learn this year! Any progress on the self-duplicating technology, so I could attend two talks at the same time? :-)

I'm really excited about this year Akademy. For us in Brno the Akademy has already begun in a sense with all the planing and preparations, but the real Akademy starts when everyone is here. I'm really looking forward to meet with all my friends from KDE again!

By the way, if you arrive on Friday (or earlier), stop by at the brand new Red Hat office for the pre-registration event. Food, drinks and fun are guaranteed!

I'm going to Akademy 2014

See you all in couple days! *hug*

Hacking my way through Randa

Hello! This is me, reporting from Randa KDE meetings!

I decided to go to Randa to work with the KDE Mutlimedia team on getting Date in the Digital Clock appletPhonon GStreamer 1.0 port out and to discuss future directions of Phonon. As you could figure out from Harald's blog, my mission was successful (mostly). All the original porting work was done by Rohan Garg, Torrie Fisher and Harald Sitter, so big thanks to them! Here in Randa I was mostly fixing existing Phonon GStreamer bugs and polishing the 1.0 port to make it ready for release (had to undust my glib skills :P). An just three days ago, we pushed out first public beta. That night we also fixed a bug that made videos in Gwenview have a blue tint, but the fix is not in the beta release.

Even though it was not part of the plans for Randa, I spend all Wednesday trying to fix some issues in Plasma 5 that were too annoying for me to just continue ignoring them - so in Plasma 5.0.2 the labels in Kickoff will finally be properly centered and in Plasma 5.1 the date will return to the Digital Clock applet. I also submitted patches to add keyboard layout changer and CapsLock-on warning to the new screen locker.

Screenlocker with keyboard layout switcher and caps lock warningI tried to avoid working on KDE PIM here, but got bribed by chocolate into fixing a specific bug related to contacts and events tags, which I started working on, but haven't finished yet.

And now it's time to leave. If it was up to me, I could just stay in this beautiful place all year... :-)

Many thanks to Mario and the team for organizing the Randa meetings, many thanks to sponsors who made this possible financially and finally huge round of applause to the kitchen team for preparing such delicious meals :-)

See you all in Brno in couple weeks!

I'm going to Akademy!

No Gmail integration in 4.14 after all :(

Hi folks,

I'm sorry to bring bad news, but after trying to fight some last minute bugs in the new Gmail resource today, I realized that pushing the resource into KDE Applications 4.14 was too hurried, and so I decided not to ship it in KDE Applications 4.14. I know many of you are really excited about the Gmail integration, but there are far too many issues that cannot be solved this late in 4.14 cycle. And since this will probably be the last 4.x release, shipping something that does not perform as expected and cannot be fixed properly would only be disappointing and discouraging to users. In my original post I explained that I was working on the Gmail integration to provide user experience as close as possible to native Gmail web interface so that people are not tempted to switch away from KMail to Gmail. But with the current state of the resource, the effect would be exactly the opposite. And if the resource cannot fulfil it's purpose, then there's no point in offering it to users.

Instead I will focus on implementing the new native Gmail API and merging together the existing Google resources to create a single groupware solution that will provide integration will all Google's PIM services - contacts, calendars, tasks and emails.