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.