"Cornelius's grand plan" - Merging KDElibs into Qt

[John Layt]

On Sunday 31 October 2010 11:33:22 Mark Kretschmann wrote:
> Hey all,
> 
> after reading the whole thread that started with Chani's mail ("why
> kdelibs?"), I think the noise level has become a bit too much there.
> Cornelius had proposed this rather daring idea:
> 
> http://lists.kde.org/?l=kde-core-devel&m=128842761708404&w=2
> 
> 
> It's a very controversial idea. However, I think it is so refreshing
> that it deserves some more thought. Personally, I think the idea is
> great, if we can overcome some of the obvious road blocks. I would
> love to read some honest and direct thoughts from you guys.
> 
> 
> What do you think about it?

Wow.  I know I asked for big answers, but... Wow. :-)

I can't help but see the massive obstacles and massive objections to the idea, 
especially given my experience with printing, but I can also see the huge 
benefits if we were to pull even a part of it off.

Our biggest problem, and possibly biggest advantage, is Nokia having bet the 
company on MeeGo and needing it to succeed big time next year, which includes 
growing an app marketplace to rival the iStore and the Android marketplace.  I 
seriously don't see Nokia wanting to break their platform yet again anytime in 
the medium-term future and alienate all their app devs, they just can't afford 
to, the vultures of doom are already circling.  Yet we have a huge base of 
apps ready and waiting to help them in the market, the promise of which we can 
leverage to try win improvements in both support for our platform in their 
libs, and in the governance model to get them to trust us with real 
maintainership of parts of Qt.

I think Stephen, Michael, Torsten and Aaron have hit the path forward about 
right.  We should start work now (well, after next weeks freeze :-) to find 
out what we actually have in kdelibs, why we have it, and how it all links 
together.  Literally, a class-by-class documenting and justification of why 
it's there.  Work on improving our understanding of our own code-base, find 
out what it is that makes our api better than Qt in places, find out what Qt 
now does better than us, find some quick wins we can push upstream now, come 
up with a model that allows for different levels of K-ness.  It will take time 
and effort, but it's worth it regardless of the whole Qt idea.

Yet at the same time we need to start reaching out to Nokia, finding out what 
they think, getting a realistic feel for what they are willing to accept, and 
using that to judge what we are willing to attempt.  We also need to start 
pushing code at them for Qt4, and in volume, showing that we can help them in 
the areas they want to spend the least resources on, that if they invest in 
the community relations, governance model, and merge reviewers they will 
benefit.  Bluntly, they need to see there is something in it for them, and we 
need to prove to the new bosses who don't know us that we are worth trusting.

If at the end of the day we only gain a few small improvements in Qt and we 
can't find a model that works for both parties, that's fine, we've at least 
improved our own code-base in the process and we can move forward with a 
better idea where we are heading.  But if we don't try, we won't know.

Personally, I think we will end up with Qt supporting KDE as a platform on top 
of Unix / Windows / Mac with KDE holding maintainership for those platform 
backends, we'll merge some of the deep core stuff like l10n (not i18n) to make 
everything play nice together, and some of the nice fluffy stuff, but we will 
still offer a kdelibs with things like KJob and KIO and Nepomuk as add-ons 
that can integrate nicely in a Qt-only application, but provide their best 
features when running on the KDE platform.  We need to keep something back 
that is uniquely KDE, something that attracts people to the community, a 
reason to be KDE, a definition of what it means to be KDE, otherwise we're 
just Qt++.

Now obviously not everyone is happy with the Qt contributors agreement, and 
that's fine, only those who want to have to contribute, and we as a community 
will have to negotiate a model that accommodates the community as a whole.  
There will be red lines that can't be crossed, but we have negotiated trickier 
waters in the past.  Much depends on how the governance model works out, but 
the process of working through kdelibs is likely to take a year by which time 
we should know if the model is open enough for us.

For me personally, the licensing around my locale and calendar code is not an 
issue, my personal ethos is I want everyone everywhere to get properly 
localized software and properly interchanging data, this is a case for Open 
Standards not Open Source.  I'm willing to have that part of my code used 
under any license by anybody to reach this end.  I want to get the calendars 
and algorithms properly defined in the iCalendar and Unicode CLDR standards 
for everyone to use, yes even Microsoft.  Similar goes for some of my work on 
KHolidays, eventually I want a new open standard for holiday files hosted 
somewhere like freedesktop.org or even as an rfc.  Other code will be case-by-
case, but Trolltech and Nokia have been incredibly generous to us over the 
years and I have few problems with personally giving a little back, especially 
if the money they make gets pushed back into developing more Free code for me 
to use.

I know others won't agree, and I respect that, we need strong voices to help 
keep us from becoming over-pragmatic or from falling into deep holes we didn't 
notice were there while staring up at the blue sky.  That's why freely talking 
about it here matters so much.

OK, enough with all the airy-fairy pie-in-the-sky waffle, how about something 
concrete, like fixing l10n?

Why don't Qt apps use the KDE locale settings when running under KDE?  Why 
don't KDE apps use the correct locale settings when running under other 
platforms?  Why don't Qt apps use half the locale settings available when 
running under any platform?  Wouldn't it be pointless for both sides to fix 
the problem separately when they both will have to write the same code?

(Just to be clear, I'm not including translation in this, it really seems 
unlikely Qt would switch to gettext, and we wouldn't want to give up our 
superior facilities).

We have two problems with KLocale.  One is we we are isolated, we don't play 
nice when running under other platforms, and other apps can't play nice when 
running under our platform.

The other is KLocale is monolithic with circular references, it's really 3 
different things, a container for locale settings, a formatter/parser, and a 
translator.  We need to spilt it up.

So, imagine this.  QLocale becomes the container for the locale settings.  Qt 
adds a KDE backend to QLocale to allow it to read our locale settings and have 
them used in all Qt apps running under KDE.  We start using QLocale to obtain 
the right settings on non-KDE platforms so we fit in over there.  We work 
together to bring the QLocale api up to standard.  QDateTime and QString 
become our formatters/parsers (once their broken calendar and timezone 
handling is fixed), using our locale settings in their formatting routines 
when running under KDE.  All other Qt classes suddenly start using the KDE 
settings too.  We provide a separate Ki18n library that we can advertise as a 
superior solution, one that others can use if they like, but one of the 
pillars of the KDE dev platform, what distinguishes a true KDE app from a Qt-
app that uses some of that nice KDE stuff.

Ideally we'd reach the position where we only need QLocale/QDateTime/QString 
for most uses, removing one of the big dependency problems Qt apps have with 
using our libraries.  We may still need our own versions available from our 
own KGlobal, possibly sub-classed from a virtual 
QLocale/QDateTime/QCalendarSystem, for some of our unique features that Qt 
doesn't want, but I'm sure there's a way to make that work.

We'd also need to start setting the users envvars on login to the KDE settings 
so Gnome apps play nice, but that's a separate issue to be worked out (or it 
could be how Qt reads our settings, who knows yet).

There's a few different ways to do all this, some of which would require 
breaking BC (e.g. if we need a base QLocale and QDateTime to be virtual), but 
the great thing is a lot of this could be achieved in KDE4/Qt4 if Qt was to 
buy in. I'm already working on a lot of what's needed to get there, I'd love 
for it to be with Qt (yes, I'm an optimist, even after printing...), but we 
will win either way.

Whew, that's a bit long, and I really need to get on with preparing for this 
weekends Marble sprint, and finishing all that code before the hard freeze :-)

John.