On Sat, Oct 30, 2010 at 7:01 PM, Albert Astals Cid wrote: >> On Sat, Oct 30, 2010 at 4:32 PM, Cornelius Schumacher < >> schumacher@kde.org > 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. I remeber that, and indeed printing is a sore point. What did go wrong exactly? What do you think would be needed to make some progress in upstreaming/collaborating with Qt? In the spirit of brainstorming, here is my brain dump: I think part of the problem is complete independent solutions have been set up for Qt, disregarding existing KDE technologies. This has brought out things like QPrinter or QMultimedia. But in case part of kdelibs goes to a Qt module that does not mean current maintainer can find a new hobby - they should stay in charge. For something useful to come out of kdelibs modularization/reorganization, we do not even have to move it to Qt domain; there are third party modules already, all we have to do is find the parts of kdelibs that can only depend on Qt or common open source libraries. We are in a puzzling situation, imho, where Qt has been relicensed in a way many of us hoped, an open governance model has been announced, but it does not seem to affect KDE that much. I think testing waters with some solid and simple parts of kdelibs could be useful -- for it to work, I suppose a first step could be having non-nokia people involved in patch review and acceptance, which I gather was part of the plan. > > 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. Sure, Qt has to open up some more. Shouldn't we try prodding them some more before giving up on the process at all? Hell, we have friends working there, we have to find a way to help them help us! :) > > Albert > -- Luciano Montanaro Anyone who is capable of getting themselves made President should on no account be allowed to do the job. -- Douglas Adams