原文:http://dot.kde.org/1154654739/
翻译:yuanjiayj, yunfan
引自:http://www.myswear.net/forum/viewthread.php?tid=6409&extra=page%3D1
KDevelop是领先的自由集成开发环境。这个项目当前的工作是在KDevelop3.4中添加一些新特性并开发新的版本KDevelop4。为了更多地了解这个KDE中的最重要的项目之一的KDevelop,KDE Dot新闻采访了三位作者,重点是他们当前的工作和未来的计划。
请介绍一下自己以及自己在KDevelop中的角色。
Matt:大家好,我是Matt Rogers,我是KDevelop的首席维护者。
Adam:大家好,我是Adam Treat,我在KDevelop的很多方面都做了工作。如在3.x系列中,我在C++语言部分,代码完善,分离阅读头文件/源文件以及shell和库的各方面都做了工作。在KDevelop4,我已经在做C++/Java语言部分,背景分析,代码模型,文档查看,代码查看,shell程序,将库融入kdevplatform以及GUI的各个方面。
Alex:我叫Alexander Dymo。我从2002年起为KDevelop工作并成为一个维护者,还从3.1版开始我发布了KDevelop 3.x系列的协调器。我已在KDevelop的很多部分作了工作,我也是文档插件的作者。我也是最初将“平台”这个词加入KDevelop的人,这使得将KDevAssistant 和 Kuanta运行在相同代码基础如KDevelop上成为可能。
目前我在帮助Matt做些维护工作并在KDevelop4用户界面部门做点事。我也是Ruby语言插件的发起人。
KDevelop3.4中将会出现哪些新东西,什么时候它能发布?
Matt:将会加入基于Qt 4项目的支持,还有一些对C++代码补全系统的好的改进。代码补全将快速,稳定,支持更多语言特性。我们不知道发布的确切时间,因为我们想让它更稳定一点,另外翻译者还需要一点时间做翻译工作。
Adam:我现在集中精力在KDevelop4上工作,但我知道Andreas Pakulat, Vladimir Prus, Alexander Dymo, Dave Nolden和其它人都在为Qt4/KDE4开发支持,调试程序,代码补全,UI改进和各类的bug的解决做工作。
Alex:就像Matt和Adam说的,KDevelop3.4将几乎在所有方面都有改进。
为什么需要KDevelop4?
Matt:因为KDevelop 3.x不能运行在KDE4上。KDevelop 4是KDevelop的生命循环中真正的下一个进化。KDevelop 3.x 的代码基础已经使用了很长一段时间了,现在是时候将我们从KDevelop 3.x 系列开发过程中所学到的东西进行整理,并将它们升华为KDevelop4了。
Adam:如Matt所说,我们需要将代码转向Qt4/KDE4平台。那是第一位的。但是,我觉得这也给我们一个难得的机会来真正或多或少地改进KDevelop。KDevelop3.x对于KDevelop2.x,那是自我进化了一大步,但一些特性和插件就显得陈旧了。这样虽然造就了强大的开发环境,但是其中杂乱的特性始终无法很好地整合在一起。
而KDevelop4,我想使得整个开发环境基于核心就可以工作得很出色:KDE/Qt的开发。这要求有分健壮而稳定的语言部份以使得代码补全连续而可用。这是Roberto Raggi的新的C++分析程序,这基于Qt3到Qt4的移植工具,它将很好地为我们工作。 Jakob Petsovitz 正忙于创建基于Raggi的kdevelop-pg工具的新的对Java和C#的语言分析程序。Alexander Dymo也立足kdevelop-pg工具做Ruby分析器。这些将组成KDevelop4的强大语言部分。我等不及想看到Java语言部分与奇趣的新Qt Java绑定的协同工作了。
Alex:我们必须搞出点酷的东西。KDevelop4是一个出色的机会破而后立。
KDevelop 4 当前的状态怎么样?
Matt:它现在还不太成熟。基础的东西已能运行。您可以打开一个文件,作些编辑工作,使用KDE 4终端,还有一些其它的东西,但现在它对正常的开发工作帮助不大。
Adam:它现在以编译,链接,和还可以做些特定的“工作”。它很不成熟,但您可以从中看到大量的改变了。新的文档查看和代码查看部分已初步具备。新的配置框架和与KCM结合的对话已完成。再加入一些更多的改进和Matt将CMakelib植入后,它就基本成形了。
Alex:它就像我刚加入这个团队时它的样子。那是KDevelop3.0 alpha2版,当时它拥有了基本的特性却总是崩溃。当然我是开玩笑的的,但我喜欢它在初期给我的感觉。
是否KDevelop3中的很多内容将在KDevelop4中改变?
Matt:是的。我不能说我们在KDevelop4中的工作是重写,因为我们不能简单地抹去一切重新开始,但我们是在KDevelop的结构上作深层次的改变,这种改变将对那些想开发一个像IDE般程序和想要单独构建某些东西的开发者更有用。我们也在仔细检查,做大量的代码清理,加强等工作。
Adam:用一个字来说,是。KDevelop平台库正经历巨大的重构和API清理。新的类已经引入,可以使得C++/Java/C#语言部分的整合更简单。我现在的工作是合并库和shell程序以及重写API。新的配置框架和工程文件也引入了大的改变。
Alex:是的,改变很大,但我们的结构背后的想法还是一的。我想KDevelop3于KDevelop2的改变更彻底。
你们在做哪些新的特性?
Matt:CMake支持部分正在进行,虽然我不能找到神奇的捷径和马上完成某些东西的构建。新的代码查看很不错。Adam的文摘抽取方面干的很好,这样多种语言协同工作变得很简单。
Adam:新的配置框架允许对KDevelop所提供的对单个项目的任何基本选项进行设定。我们已经创建了一个位于全局与局部之间的二分系统。全局项目文件应不会包含硬件路径或其它局部配置的设定。而局部设定则将文件保存在一个隐藏的目录中。最终项目管理器将把项目文件提交到它们共享的源控制库中。
代码查看部分虽然还有漏洞但它已能工作。它是语言无关的,它依赖语言部分以生成一个代码模型然后交由代码查看部分显示出来。它利用了Qt的QSortFilterProxyModel和协商框架同时提供经个体翻译的代码模型和整体的代码模型的筛选功能。例如,您可以用过滤器调用代码查看部分以查看当前文档或者项目的翻译个体的集合。
到现在为止最酷的功能也许是Matt的连贯Qt4集成设计器。它真的可以把你从KDevelop3的世界里拖出来。
你们计划包括哪些新的特性?
Matt:真的很多。我们开发者中的一位正在做一个团队模式,这也是Google的代码之夏的项目之一。很多的工作也已经做了。我真的希望它将成为KDevelop的一个特性,被使用了的话就可以使开发者们更有效率。我也开始注意到KDevelop3.x系列中的某些流程影响了我们的工作效率,我将试图消除它们。那些问题主要是不能在IDE中做一些事,使得我不得不启用终端才能做。我就不多说了,多留点时间给别人说吧。
Adam:嗯,很多...但主要的特性,我希望KDevelop4将能够做到把好钢用到刀刃上。我们需要至少要集中精力做到KDevelop能够可以与四种语言很好地工作:C++,Java,C#,还有Ruby。我们需要把精力集中在确保诸如代码补全和分解等基本功能,而为各种程序提供任何能想到的模板则是次要的。另外,我希望KDevelop4把新的代码分解支持作为重要的特性。语言部分应该的变动...连贯的Qt4集成设计...我想要看到用户界面像XCode和Qt4设计器一样简单...我们规划中的特性会把你吓跑的...
我个人的目标是把KDevelop4做的足够好,以让KDE的核心部门的开发者如Zack Rusin(emacs帮的)和Aaron Seigo(vim帮的)不得不转过来。Zack和Aaron会告诉你这可不是一件容易的事。要是能够把那帮家伙变成KDevelop的用户,我将会非常开心。
Alex:特性是没有限制的,但目前我们把我们的工作做的更好而不是往我们的源代码里塞入各种小特性。
我个人的计划包括带有透视功能的新用户界面和为满足Rails开发需要而加入的大量特性的新的Ruby语言支持。
讲讲你们去年的会议吧。
Matt:那是 KDevelop 4 诞生的日子。 我当时没在, 所以没什么能说的。
Adem:没有出席。 不好意思。
Alex:我曾经许诺(在路德维希堡的 Akademy 2004 中的 IIRC 上),我们会在乌克兰相遇。 我一直保留我的这个诺言,我们(我,Roberto Raggi, Harald Fernengel, Ian Geiser, Richard Dale 和 Quanta 的 Jens Herden)确实在基辅相遇了,而且有过一天的会议和一个编码聚会(hacking session)。 那次会议并没有引起太多当地公众的注意, 但是编码聚会很有趣,我们喝了龙舌兰酒和伏特加酒, 当然还完成了大量代码。 Roberto Raggi 像疯了一样的在写代码,他实现了我们现在用来构建语言分析器的分析生成器(parser generator)。Harald Fernengel 忙于 KDevelop3 的 Qt4 移植和集成 MVC(模型—视图—控制器模式)方式到 KDevelop的源代码中。 Ian Geiser 和我则工作于 Qt3 qmake 的一种新的支持方法。Richard Dale 开始实现一个新的 Ruby 分析器。
把 KDevelop 和 Quanta 团队的努力结合起来, 使用相同的代码基础的想法是在路德维希堡上决定的。因为,我们也邀请了 Quanta 开发者前来与会。不幸的是,Andras Mantia 不能来, 但Jens Herden 来了, 他的出席和耐心的提示确实让我们考虑了 Quanta 的需要。
为一个迁升的平台,KDE4, 开发, 大概是什么样的?
Matt:现在不太难,因为 kdelibs4_snapshot 已经放出了。 那可能是最大的事情。 我们想快速的转换到新技术上去,因为我们也要求他们很久了。不为预览版发愁对我们而言会更好一点。
Adam:事实上是很不错的。 那才是个刚刚开始,但东西现在也算稳定些了。 使用 Qt 4 开发还有所有底层库的所有增强,都让我非常兴奋。
你们计划中的协作模式是如何的?
Matt:团队工作模式,像这个名字一样, 将允许开发者实时检查一系列的补丁。 同一文件或多个文件的协同编辑也在计划中, 但是我不知道什么时候可以完成。 目前, 补丁查看通过一个邮件列表已经基本实现,在这个方法有效的同时, 它也会花较长的时间来得到所有补丁的讨论,检查,同意等等。团队工作模式会允许一组开发者在接近实时的情况下检查补丁,处理时间会比现在用的快很多。
在构建系统支持方面, 已经采取什么样的增强或者说改变?
Matt:有成吨的东西。Autotools 和 CMake 一开始就支持了,而我们的目标是允许开发者在 IDE 内可以做任何事情。 易用在这里是关键。 在 KDevelop 3.x 中, 如果你想用 Autotools 加入一个包的检查, 你得去编辑 configure.in.in 文件,了解所有的语法等等。 用 KDevelop 4, 我的目标是让用户在工程上点右键, 选择“加入一个外部依赖” 然后用一个友好的对话框而不是编辑文件来创建这个配置检查。
Adam:项目管理器部分准备提供一个底层构建系统的 GUI(图像用户界面) 抽象。至少,计划中有这个。你不会再看到使用 Automake, QMake 和 CMake 构建系统时有什么不同。
我还想借这个机会寻求一些帮助。 我们在寻觅一个好的 Windows 骇客, 来帮助我们提供构建在 Windows 上的 KDevelop 4 的通用性测试, 可能是一个 MSBuild 目标。还有, 如果我们可以找到一个或者更多,对 KDevelop 4 是否在苹果上工作良好有兴趣的苹果骇客得话,那就锦上添花了。 要是你感兴趣, 请通过 kdevelop-devel 列表或者 freenode 上的 #kdevelop 频道来联系我们。
加入了什么新语言支持了?
Matt:Adam Treat 和 Jakob Petsovits 正在加入 Java 和 C# 支持。
Adam:目前支持 C++, Java 和 C#, 但是就我现在知道的, Alexander 和 Richard 给还我们火速加入了强大的 Ruby 语言部分。Java 和 C# 部分现在还没有代码模式, 但是 Jakob,Hamish 和我正在做这个事情。
Alex:Roberto Raggi 写的 kdevelop-pg 分析器生成器, 它让我们把语言支持推到了他们的极限。 有了 kdevelop-pg, 我们就有了免费的分析器来生成抽象语法树(AST), 也有了免费的AST 解析(AST walker)类。今天要感谢一下 Jakob Petsovits,让我们还有了分析器的回溯和错误恢复功能。这些都让我们可以实现更好的语言解析,比以前更快的速度集成到 KDevelop 中来。
新的理想的库是什么样子的?
Matt:那是 Alexander 的领域了,但我会花时间加上类似 Eclipse 一样的特性(Eclipse-like perspectives),我们是打算加到 KDevelop 4 中的。
Alex:从 KDevelop 3 alpha4 开始, 使用了 KMDI 库来实现它的图形界面需要。我觉得这是我们做的最糟糕的决定了。 KMDI 让我们有了四个UI模式,这样KDevelop可以看起来和 Delphi, MS Visual Studion(注:可能是笔误,应该是 Studio) 和 IntelliJ IDEA 有相似的模样。 但是,主要由于 KMDI 的高度复杂性, 和库代码的难维护性, 它把我们扔回到了编程的石器时代。现实中,我们用户的大多数都选择顶层(类Delphi)模式或者完美(类 IntelliJ IDEA)模式。因此, 我开始了新的用户界面库的实现,它叫做完美(Ideal)。设计的目标就是,简单性, 代码可读性和可维护性。新库的一些部分已经在 KDevelop 3.3 中了, KDevelop 3.3 用户可以感受额外的“简化的完美”模式。 已经增强的版本现在已经做为 KDevelop 3.4 的默认模式。我继续为 KDevelop 4 忙着, 已经做了大量的开发了。 新版本盖头之下必有新功能。
区域支持(the support for areas)已经可以用了(读一下类 Eclipse 特性)。 而且以前顶层模式的优点都集成到这个库里了,因此我们大量的用户也会很高兴的使用 KDevelop 4 的。