why kdelibs?

Chani chanika at gmail.com
Sun Oct 31 21:10:04 GMT 2010

On October 30, 2010 19:44:29 Parker Coates wrote:
> On Sat, Oct 30, 2010 at 13:01, Albert Astals Cid wrote:
> >> On Sat, Oct 30, 2010 at 4:32 PM, 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 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 know we keep coming to the same place, but no, it would not be a
> > wonderful answer, it would be a disaster like it was for KPrinter.
> > 
> > Just for those that have short memories let me explain what happened.
> > 
> > We killed our printing stack because we were "promised" that QPrinter
> > would be maintained and better than KPrinter was. And years later,
> > QPrinter is unmaintained and provides less features KPrinter delivered
> > much more years ago.
> > 
> > So please come back to the real world were Nokia doesn't have infinite
> > manpower and where the only thing Nokia wants to do is sell cell phones.
> I think Qt's semi-adoption of Phonon is another very (probably even
> more) relevant example. At the time everyone (myself included) thought
> it was a really great move. KDE produced code would see a wider
> audience and Qt would take on some of the maintenance load. Win-win,
> right?
> But it turns out that Qt's needs didn't fully match KDE's so the KDE
> version had "go on without" the Qt version. Nowadays, Qt's Phonon is
> nothing more than a mild inconvenience for KDE, as every few weeks
> someone shows up with KDE/Phonon build conflicts.

I notice something both of those have in common: qt was supposed to take on 

so perhaps it could work better if the things that are their own libraries 
stay under kde maintainership, but in some way that can be more easily 
marketed as qt addons, and the things we would fully upstream would only be 
the ones that enhance an existing properly-maintained feature or are otherwise 
very unlikely to be neglected.

also, nokia does seem interested in getting community maintainership of qt 
things, so upstreaming won't necessarily mean giving up control...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20101031/e0c07750/attachment.sig>

More information about the kde-core-devel mailing list