why kdelibs?

[Marco Martin]

On Saturday 30 October 2010, Cornelius Schumacher wrote:
> On Thursday 28 October 2010 John Layt wrote:
> > Big questions.  Anyone with big answers? :-)
> 
> Here is a big answer:
> 
> Let's merge Qt and the KDE development platform. Let's put all KDE
> libraries, support libraries, platform modules into Qt, remove the
> redundancies in Qt, and polish it into one nice consistent set of APIs,
> providing both, the wonderful KDE integration, consistency and
> convenience, as well as the simplicity and portability of the Qt platform.

I like this target :)
And yes, it's not going to happen but must *still* remain the target.

> 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?
> 
> 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?

so, as being well pointed out not al things would really make sense to be 
"merged"
there are big categories in this, something like
 * KUrl (and many similar examples): why the hell we still have a class like 
that?
that one is the poster child of poor communication and problems in the 
contribution processes we had with Qt. Features in classes like KUrl would 
just need to go down in QUrl (or whatever) instead

* Then there is what we really have more compared to Qt, being KIO, Akonadi, 
an actually useful calendar system (that is partly in the domain of the 
previous point perhaps :))
those things make sense to be developed and provided by us, -but-...
In part for actual technical problems (too much interdependence)
In (great) part for misunderstanding and we not able to get the word out:
all those extra, really useful features are avoided like pest by many Qt 
developers, and most important by the main Qt user: its owner, Nokia.

> Sure, this would be a massive effort, and require huge changes, it would
> probably mean Qt 5 and KDE 5, it would take quite some time, it would need
> further changes to the Qt governance model, it would mean investments from
> Qt Development Frameworks, it would mean a long transition phase for
> applications to adapt. But wouldn't it be worth this effort? What's the
> future of the KDE development platform long-term, independent of Qt?

I would like to put the accent here on the part "it would need further changes 
to the Qt governance model"
and "it would mean investments from Qt Development Frameworks"
we really need to be recognized as a viable module of Qt.
Something that is worth investing into
Something that is worth supporting on their platforms (*cough* MeeGo *cough*) 

> There are probably a hundred times as many Qt developers out there than KDE
> developers, and if Nokia is only half-way successful with their plans for
> Qt, this ratio will continue to change rapidly in favor of Qt. By merging
> the platforms we could turn all these Qt developers into KDE developers.
> We could benefit from and contribute to the success of Qt without
> restrictions. We would reach way more users. We could much more easily
> acquire contributors.

What it's risking of happen is also another thing: as the developer base of Qt 
enlarges, the KDE portion will be felt more and more negligible, and that 
would be the biggest threat to KDE, not coming from Windows, not from GNOME, 
but from the Qt community itself.
It's both acknowledging that we are thrustworty as a platform they rely upon
and that we are no more an hobby project: I know that's true since well, last 
14 years, but there *is* still that conception alive around.

> Over the last couple of years, KDE development has constantly shifted from
> library development to application development. Our struggles with even
> just doing the basic maintenance of the libraries show that. But we have a
> lot of shiny apps, people are excited about being part of our
> subcommunities centered around applications. There are still brave souls
> taking care of kdelibs, but it's really hard to keep up there.
> 
> On the other hand Qt has broadened a lot, and recently with the ambition to
> provide a full API for MeeGo this has accelerated. That's a bit similar to
> what KDE did quite some time ago. There is more and more redundancy and
> overlap between Qt and KDE libraires, and we still don't really have a good
> answer to that. A merge would be an answer, a big answer.

The big things that would need to happen i think are a merge of the most core 
classes that are just a fix upon the Qt version (again, KUrl, Kicon...)
And the pltform should be somewhat acknowledged as an (official) Qt module, 
just like meegotouch or qtmobility, is (this particular period makes a such 
thing less crazy since this is happening with other nokia-but-not-
QtDevelopment Framework stuff)
the challenge is how making it being accepted by not being something by Nokia 
and even worse sin, being by a "community" and not by a defined company.

> Am I crazy? Or could this be exciting? What do you think?

yes, of course you are, and that's why we love you :p

Cheers,
Marco Martin