Cornelius Schumacher wrote:

> Why be content with being a second-class citizen, when you can be first
> class as well?

I don't think having a separate repo, release schedule, license and 
development process makes a third party library a second class citizen. I'm 
also not 100% certain that's what you're saying here.

> I would love to have all the KDE APIs available in Qt in a consistent way.
> Being able to use QtCreator to create a KDE applications in just the same
> simple way as a Qt application (or in KDevelop), having one set of
> documentation covering all API I use, having one build system (of my
> choice), no matter how much of Qt or KDE I use, etc.
> 
> From a developer's point of view writing KDE applications could be much
> more easy, and a big part of that comes from the separation between Qt and
> KDE.

I don't think it comes from separation. I think it comes from kdelibs using 
'data transfer' classes in our APIs and our dependencies which are 
incompatible with Qt. We use KDateTime, KUrl, etc, so any Qt developer 
wishing to use any of our libraries must use those and their dependencies 
too. I think my point on that is clear by now though.

At any rate, thanks for the reply. I'm a bit more clear on what you're 
proposing now, although I can't imagine the details of how it would work, 
and I still don't agree with attempting to put as much of the functional 
libraries in kdelibs into Qt as possible. Platform interfaces yes, of course 
and anything else that makes sense.

Anyway, I'm going to list obstacles on the other thread I guess.

All the best,

Steve.