why kdelibs?

[Luciano Montanaro]

On Sat, Oct 30, 2010 at 7:01 PM, Albert Astals Cid <aacid at kde.org> wrote:
>> On Sat, Oct 30, 2010 at 4:32 PM, Cornelius Schumacher <
>> schumacher at 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