A Qt replacement for KGlobal::ref and deref

[Stephen Kelly]

Dawit A wrote:

> On Wed, Feb 9, 2011 at 3:29 PM, Stephen Kelly <steveire at gmail.com> wrote:
>> Christoph Feck wrote:
>>
>>> On Wednesday 09 February 2011 21:01:09 Stephen Kelly wrote:
>>>> KJob would be a Qt only library
>>>
>>> ? KJob is not a library, but a class in kdecore.
>>
>> I should have been more clear I guess. When I wrote kjob there I meant a
>> library for asynchronous job execution containing kjob, kcompositejob and
>> perhaps the rest of the contents of kdecore/jobs
> 
> ahh... unless your intent is to provide your own implementation of
> KIO, "asynchronous job execution" involves more than just
> kdecore/jobs. You have to suck in almost all of the classes in
> kdelibs/kio/kio, which of course depends on libkdecore.

I'm afraid I don't know kio to that kind of detail. Could that stuff also be 
in a kjob library? 

I'm more talking about kimap. Of kde stuff, That uses kjob and kmime.

kde-devel at bishop:~/dev/src/KDE/kdepimlibs/kmime{master}$ grep -h include * | 
egrep -i "<(k|K)" | sort | uniq
#include <kascii.h>
#include <kcalendarsystem.h>
#include <kcharsets.h>
#include <kcodecs.h>
#include <kdatetime.h>
#include <KDebug>
#  include <kdebug.h>
#include <kdebug.h>
#include <kdebug.h> // for kFatal()
#include <kdefakes.h> // for strcasestr
#include <kdemacros.h>
#include <KGlobal>
#include <kglobal.h>
#include <klocale.h>
#include <kpimutils/supertrait.h>
kde-devel at bishop:~/dev/src/KDE/kdepimlibs/kmime{master}$ cd ../kimap/
kde-devel at bishop:~/dev/src/KDE/kdepimlibs/kimap{master}$ grep -h include * | 
egrep -i "<(k|K)" | sort | uniq
#include <kcodecs.h>
#include <KDebug>
#include <KDE/KDebug>
#include <KDE/KGlobal>
#include <KDE/KJob>
#include <KDE/KLocale>
#include <kdemacros.h>
     * #include <kio/ksslui.h>
#include <ktcpsocket.h>


Even though this is quite few dependencies on KDE stuff, it could even be 
less. kimap only uses KGlobal for K_GLOBAL_STATIC. Qt provides the same 
functionality, though not as public API (currently) so that's one down 
potentially.

kimap could depend only on Qt, KJob, KMime, and KLocale with some re-
arrangement of the existing kdelibs. That would make it far more accessible 
to Qt developers. The only Qt developer I'm aware of to use kimap actually 
forked it to pretty much as I described above (he also took out the KLocale 
dependency). When people have to fork stuff because it's not modular enough 
it means we can do better.