[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: why kdelibs?
From:       Cornelius Schumacher <schumacher () kde ! org>
Date:       2010-10-31 10:21:01
Message-ID: 201010311219.21215.schumacher () kde ! org
[Download RAW message or body]

On Saturday 30 October 2010 Stephen Kelly wrote:
> Answering Cornelius and Alexander here.
> 
> Cornelius Schumacher wrote:
> > I know what you think ("madness", "no", "KDE 5", "impossible",
> > "governance", "binary compatibility", "Nokia", "impossible", ...), but if
> > you put that aside for a while and think big, wouldn't that be a
> > wonderful answer to all the struggles we have with kdelibs?
> 
> I don't think so.
> 
> There will always be a place for third party Qt-based libraries. That is
> what kdelibs should be.

I agree that there will always be a place for third-party Qt-based libraries. 
Maybe KDE will create some of these third-party libraries, but this shouldn't 
be the goal, but a last resort for situations, which can't be solved directly 
in Qt.

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

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.

> The kde platform should sit on top of those
> libraries. The kde platform will not become completely irrelevant because
> of integration points like action shortcuts, about dialogs, menu
> structures etc. It should be possible to use the libraries without the
> menu structures and about dialogs though.

The platform should be encapsulated by APIs (ideally generic APIs), so that an 
application developer doesn't have to care about on which platform to run, and 
still get good integration and platform specific features, when available. (I 
would argue that the platform is below the libraries, not on top, because it 
hides the platform to some degree).

And of course the KDE platform won't become irrelevant, not at all, as it 
provides integration and richness to the desktop experience, which isn't 
available, if you go with a platform-independent implementation spanning the 
full stack. But again, the less the developer has to care about the platform, 
the better.

> 1) Would KJob make sense to have in Qt directly? Probably. kdeui/itemviews?
> Parts of it, yes. And parts of it are going in to Qt.

Yes. We could make this process much smoother, if we would explicitly target 
these classes to go into Qt, instead of containing them in our own walled 
garden.

> 2) What about KMime, KIMAP, Kross etc? Those are all domain specific
> libraries. Why should they be in Qt instead of third party libraries?

Because it's easier for a developer. Of course there will always be domain 
specific parts, which are not suitable for Qt. But the boundaries are not very 
sharp. Qt now contains much more domain specific parts than it used to, and 
with the more modular concept of Qt, it can be managed better. So in some 
cases over time these domain specific libraries will become parts of Qt. A 
mail-parsing library? I'm sure many Qt developers could make use of that. Why 
not include it in the platform, instead of everybody having to find some and 
make a choice, and be incompatible with others who did another choice?

> 3) What about KDED, KLauncher, kdeinit, ksycoca? Those are all platformy
> kde specific things. They make sense if you are creating a large suite of
> integrated applications, which use the same libraries, which publish
> mimetype based capabilities of the applications for certain tasks. Most Qt
> developers don't make a large suite of hundreds of applications. They make
> just one. They make the only one which is suited to the task it was
> written for, so they don't need ksycoca.

True. That's why this stuff belongs to the platform, but it should be 
available for developers. Many developers make only one application, but many 
make more than one as well. So some platform integration is attractive. When 
you create two applications doing HTTP communication, wouldn't it be nice, if 
they would transparently share passwords, cookies, cache, just by making use 
of the platform, without the developer having to care much about that?

> I heard there used to be a rule that API only gets into Qt if 80% of their
> customers would use it. I don't know if that has changed, but it might help
> answer the questions of 'Does this particular functional library in
> kde{pim,}libs belong in Qt?'

Qt is more modular, then it used to be, and as Qt has the declared goal to be 
the API for MeeGo, the scope is expanded rapidly. This won't be covered by an 
80% rule anymore.

But again, the boundaries are fuzzy, and if we design for being able to be 
included in Qt instead of our walled garden, we can accommodate this 
fuzziness, and flexibly create the best experience for developers.

> If you're talking about putting code into Qt to make is possible to use Qt
> APIs like QDateTime in our applications (and most importantly in our APIs),
> and have it JustWork with our platform like it does with KDateTime today,
> I'd say +1000. That needs to happen.

Absolutely.

> When the categories 1 and 2 are separate and below the platform, rather
> than on top of it, it doesn't matter whether they are in Qt or are a third
> party addon, such as my proposal for kdelibs. The separation of platform
> and libs is a prerequisite either way.

I agree about the separation, but I would argue, that it matters how the addon 
is done. If it's separate, and done differently, it raises the barrier for 
developers to use it in addition to the APIs, they get with Qt.

> > We all love Qt, without it KDE wouldn't exist. We also love the KDE
> > development platform, it provides all that what Qt doesn't have or didn't
> > have at some point in time. But is there still a real reason to keep them
> > separate? Wouldn't it be much more elegant, if you wouldn't have to
> > decide, if to use some KDE classes or write a "qt-only" application, if
> > you would get all the wonders of KDE from Qt in one consistent way?
> 
> Which wonders? The libraries or the platform?

I mean the functionality. Take kioslaves as an example. Right now you have to 
decide to use almost the full KDE platform, if you want to make use of them. 
You can use the Qt equivalent, but then the functionality is limited. So, if 
the full functionality of kioslaves would be available via an API in Qt, it 
would be much more easy to use, and if the API is done in a way, that it 
benefits from the features of the platform, so that you get more or richer 
functionality on a more powerful platform, then both wonders are available in 
one.

That doesn't mean that Qt has to ship all possible kioslaves, but an 
application, which uses the Qt API to access kioslaves should be able to make 
use of all of them, if the platform, where the application runs, provides 
them.

> The fact is that kdelibs as it currently is is incompatible with Qt
> applications, and therefore many parts of it do not belong in Qt. It is in
> a walled garden. You can use use none of it, or you can use all of it, or
> you can fork the parts you want to use into your own build and integration
> system. That is why it is hard to use and hard to sell.

Yes. A lot of development in Qt has replicated parts of KDE, and KDE has 
continued on its incompatible paths. These really is a wall between them 
sometimes. That's one of the main reasons why I think it would be good to 
think about merging the development platforms. It would tear down these walls.

> > We would reach way more users. We could much more easily
> > acquire contributors.
> 
> Wouldn't this be true if kdelibs was 'a set of Qt-based libraries which can
> be used in Qt-based applications'?

Only, if they would transparently integrate with how Qt developers work. 
Downloading a separate library, learning a separate build system, reading 
documentation in a different way, etc. are all barriers for adoption. The most 
elegant way to overcome them, seems to me to just become part of the primary 
platform.

> After that we can start listing obstacles :)

I'm looking forward to that. Once we know them, we can work on removing them, 
and that's fun :-)

> http://techbase.kde.org/Projects/KDELibsModifications

I think this is a good proposal. It is one step which needs to be done, and it 
would be one step in direction of a merge of Qt and KDE. We would need two 
more steps to actually arrive at the goal, that would be to make the libs 
compatible and integrated with the Qt development framework, and the actual 
merge.

-- 
Cornelius Schumacher <schumacher@kde.org>

[prev in list] [next in list] [prev in thread] [next in thread]