转自： http://linux.chinaunix.net/bbs/thread-1173485-1-1.html

下面是一个重要的答案

让我们合并Qt和KDE的 开发 平台。让我们把所有的KDE库，支持库，平台 模块 合并进Qt，删除与Qt冗余的部分，将它优化成一套完美的、一致的APIs，让它提供绚丽的KDE集成，不仅便利而且一致，同时兼顾Qt平台的简单和可 移植 性。

我知道你可能会想 （“疯子”，“不”，“KDE 5”， “不可能”，“管理”，“二进制的兼容性”，“Nokia", "不可能”，。。。）， 但是你把这些放在一边深深的想一下，难道这不是一个对我们在KDE库上所有奋斗付出的一个精妙回答吗？

我们都深爱Qt，没有它KDE就不会存在。我们也都深爱KDE开发平台，它给我们提供了Qt没有的或当时Qt不具有的所有。 但这还是让它们继续分离的原因吗？如果不是必须得这样，如果你要用一些KDE的类或只是写仅用Qt的 程序 ， 如果你想在Qt中利用所有KDE的亮点而且是以一致的方式，难道没有比现在更好，更优美的方式了吗？

当然了，这将是一个很大的工作量，同时需要巨大的改动，它将可能意味着Qt 5 和 KDE 5，它将需要花一些时间，它还需要Qt的管理模式做进一步的改动。它将意味着对Qt开发框架的投资，它同时也意味应用程序将有一个长的适应、过渡期。难道它不值得这些努力吗？究竟KDE开发平台长远的未来是什么，一直独立于Qt之外吗？

外面Qt的开发者可能比KDE开发者多百倍，而且哪怕Nokia在Qt上的计划只成功了一半，Qt都可以得到持续、快速的改善。通过合并平台，我们可以将所有的Qt的开发者转变为KDE的开发者。我们能无限制的从所Qt的成功中受益，同时也有助于Qt的成功。 我们将接触到更多的用户，我们也将更容易的获得贡献者。

在过去的几年中，KDE开发不断地从库的开发转变到应用程序的开发上来。仅仅做一些基础的库维护都使得我们很费力可以证明这点。但是我们有很多优秀的应用程序，人们很乐意成为我们这些以应用程序为中心的分协会中的一部分。仍然是只有一些勇者在维护着KDE库，但是真的是很难维持着这种情况。

另一方面来说，Qt也扩展了很多，最近因为要为MeeGo提供完整API的抱负更是加速地朝这种趋势发展。有点类似于KDE以前所做的那样。结果是Qt和KDE库中重叠的、冗余的部分越来越多，对此问题我们仍没有一个好的答案。 合并就是一个答案，一个重要的答案。

如前所说，为了让这能够实现，我们有大量的困难要克服。但是让我们就假定片刻，假定我们把这些困难都克服了，这将是KDE历史上多么一件重要的事情啊！

我疯了吗？或者说这听起来是不是很精彩？你觉得呢？

-- 
Cornelius Schumacher < schumacher@kde.org >

原文：
Here is a big answer:

Let's merge Qt and the KDE development platform. Let's put all KDE libraries, 
support libraries, platform  module s 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?

We all love Qt, without it KDE wouldn't exist. We also love the KDE 
development platform, it provides all that what Qt doesn't have or didn't have 
at some point in time. But is there still a real reason to keep them separate? 
Wouldn't it be much more elegant, if you wouldn't have to decide, if to use 
some KDE classes or write a "qt-only" application, if you would get all the 
wonders of KDE from Qt in one consistent way?

Sure, this would be a massive effort, and require huge changes, it would 
probably mean Qt 5 and KDE 5, it would take quite some time, it would need 
further changes to the Qt governance model, it would mean investments from Qt 
Development Frameworks, it would mean a long transition phase for applications 
to adapt. But wouldn't it be worth this effort? What's the future of the KDE 
development platform long-term, independent of Qt?

There are probably a hundred times as many Qt developers out there than KDE 
developers, and if Nokia is only half-way successful with their plans for Qt, 
this ratio will continue to change rapidly in favor of Qt. By merging the 
platforms we could turn all these Qt developers into KDE developers. We could 
benefit from and contribute to the success of Qt without restrictions. We 
would reach way more users. We could much more easily acquire contributors.

Over the last couple of years, KDE development has constantly shifted from 
library development to application development. Our struggles with even just 
doing the basic maintenance of the libraries show that. But we have a lot of 
shiny apps, people are excited about being part of our subcommunities centered 
around applications. There are still brave souls taking care of kdelibs, but 
it's really hard to keep up there.

On the other hand Qt has broadened a lot, and recently with the ambition to 
provide a full API for MeeGo this has accelerated. That's a bit similar to 
what KDE did quite some time ago. There is more and more redundancy and 
overlap between Qt and KDE libraires, and we still don't really have a good 
answer to that. A merge would be an answer, a big answer.

As said, there are tons of obstacles to overcome to make this happen, but 
let's just assume for a moment that we would be able to remove these 
obstacles, wouldn't it be a great thing for KDE for the long term?

Am I crazy? Or could this be exciting? What do you think?

-- 
Cornelius Schumacher < schumacher@kde.org >

从另一个角度来看，这可能是一种创新。但过程会比较麻烦。