"Cornelius's grand plan" - Merging KDElibs into Qt
johnlayt at googlemail.com
Mon Nov 1 21:25:45 GMT 2010
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:
> 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
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
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
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 :-)
More information about the kde-core-devel