|
|
继我们上个月对Phil Thomson的PyQt作了采访之后，我们对KDE自身对Python绑定PyKDE的维护者作了采访。下面是有关他是如何加入维护PyKDE的，为何你需要用到它以及他对未来的计划的访谈。
请介绍下您自己以及您在KDE中的角色。
我是Jim Bublitz。我维护了PyKDE-Python语言对KDE的绑定。
什么是PyKDE，为什么我们得用到它？
PyKDE允许您用python使用kdelibs中大多数重要的类和方法。我自己使用它的原因是它可以让我开发出与KDE兼容的好看的图形化应用程序，并允许我用Python开发。我觉得python是一个比C++更有效率更方便的开发环境。
我更喜欢面对KDE的Python绑定（与Qt/PyQt相比较），因为KDE提供了更多的方便且高级的器件，对话框等，这比单独调用Qt要好。对图形界面而言，速度方面一般不是什么问题，我怀疑我会看到在向c++的速度的目标前进的更多改进。PyKDE的绝大多数的部分实际上是以C++的形式运行，而它只是以python来调用方法而已。
PyKDE是如何开始的？
Phil Thompson ( PyQt和sip作者, sip是PyQt 和PyKDE的基础)为 KDE 1.x写了PyKDE的最初版本。
您是如何参与到这个项目的？
在2001年，我用PyKDE为KDE 1.x开发了一个程序，当时KDE2.0和Qt2.0已发布了。当时的PyKDE版本并不与KDE2.0兼容，所以我向PyKDE邮件列表去了一封邮件。Phil回信说他不再维护PyKDE或为KDE2.0开发新版本了。简而言之，他触动了我为KDE2.0做PyKDE的新版--“就做你需要的那一部分，然后别人会把剩下的补上的。”--但这样做不太可能，你不得不最后自己完成整个项目。Phil在我开发最初版本和后续版本时向我提供了大量的帮助和支持。
我也许不是维护PyKDE的最佳人选。我不是一个编程老手（但比业余爱好者要懂得多一点），我不是做软件的并身上担子也很重，所以我维护PyKDE时很困难。但是没有其它人志愿加入这个项目，所以我坚持了下去（并享受了这个过程）。
维护时做了多少工作呢？
很明显频繁的KDE版本更替是维护PyKDE最大的问题，所以在我手工做完最初的版本之后，我开始让工作自动化。只要花十分钟就可以自动生成一个新的PyKDE版本，然后可能在几个小时内接触到一些由小的有待我解决的bug产生的错误信息。我编写了一个脚本让我可以及时下载到KDE的源代码，然后直接生成PyKDE的版本，但有一些东西可能那时就被损坏了。
phil不断地对sip进行改进，但好象每一次改进都会在某种程度上破坏PyKDE。另一方面，大量的改进支持了KDE中C++特性，而这些特性是Qt不需要。所以我加入Phil的工作中，并做了很多工作。
最花时间的部分是对不同的KDE版本和不同的发行版进行测试。不过Phil的sip设计方式以及我们展开构建程序和发行版源代码的方式很妙。我们采用了一套相对无痛的方法，为所有的Qt和KDE版本构建了相同一套文件。这很重要，因为用户和发行版从不会与他们所用的版本同步，如Debian Stable版与最新的SuSe发行版等。这么长的时间里，从Qt/KDE2.0到现在的Qt/KDE3.x，我们一直保持着对Qt和KDE的向后兼容。甚至现在PyKDE都可以与任何一个KDE/Qt 3.x版本兼容。此外，我们也不得不考虑一系列Python和gcc版本的问题。
现在还有很多用户在使用KDE 3.0，我很高兴我们现在仍然保持对他们的支持。我目前用KDE3.4工作，而且只是最近的一次硬件升级才转到这个版本的，但PyKDE包括了对至KDE3.5.2的所有改变的支持，并且对3.5.3和3.5.4的支持正在做。
调试也很花时间，因为代码的堆积，较长的PyKDE构建时间（特别是当我不得不使用较慢的机器的时候），还有我对一些特别复杂的KDE API不太熟悉。
很多人为PyKDE做了重要的捐献--报告bug，要求新特性，编写示例，或者找出代码问题等。PyKDE的致谢名单很长，而且我还可以漏掉一些人了。当然如果没有Qt，KDE以及所有为之努力的开发者的心血，PyKDE也不可能存在。
PyKDE的完整程度如何？
它涵盖了kdelibs的绝大多数部分。我最近去掉了对一些东西的支持，如kjs和kdesu，因为从Python的角度看不太有用，我想也没人会用到它们。一些部分，如kparts，还有一些问题有待解决，还有就是有一用户最近捐献了一些对DCOP功能支持增强的代码。一些较少用到的部分可能还缺少测试，但对kdecore，kdeui，kio，kfile，kmdi以及其它的kdelibs组件都是支持的。
我还没计算过PyKDE的总行数，但我的自动化工具产生大约60000行初步的代码（*.sip文件），所有的PyKDE文件加起来可能超过1百万行C++代码（由.sip文件生成的）。而它们更是能有多紧凑就有多紧凑。
对KDE 4有什么计划吗？
现在我计划实现KDE4的PyKDE。最难的部分-sip和PyQt支持-已由Phil完成了。我已看过了Qt 4，但现在还远远提不上熟悉。就我目前看来，KDE4的设计还得经过“定形”，想要对其进行绑定还言之尚早。
PyKDE将可能会在KDE4的发布时间稍后一点的时间内发布-可能一两个月吧。对alpha和beta版本的工作一定会遇到大量问题的，而sip和PyQt也可能作些调整，但我不希望拖的太久了。
KDE4将是一个很好的机会去对PyKDE进行重新思考，对它的构建做些改变，这在PyKDE的邮件列表中已有相当多的讨论了。
在riverbankcomputing.co.uk的PyKDE版本和kdebindings中的版本有什么联系吗？
我从不将我的PyKDE时刻计划表与KDE发布计划表绝对地同步，所以我没有把PyKDE放在KDE CVS库中。幸运的是Simon Edwards可以对PyKDE重新打包，并维护它在kdebinding中的部分，我也很欣赏他的工作。
在kdebinding版本的Python落后我的PyKDE版本一点，但自从KDE变得成熟，kdelibs版本之间的改变越来越小。我想这不会对百分之九十九的潜在用户或程序构成影响。
有人为您的工作付您薪水吗？
没有，但我用PyKDE为我的商业项目写程序（最近大多是帐目会计类的，但过去有过其它的），所以我以那种方式被“支付”薪水。
您是否知道PyKDE的令人激动的用户？
我很高兴看到在各个领域涌现在基于PyKDE的程序，还有一些因为直到最近才发现的一些问题有些尴尬。Simon的工作变得很重要，他向开发基于PyKDE的程序的人们提供了一个一致的平台。我没有对PyKDE程序的用户进行跟踪调查。
还有一些代码我还来不及去看，这些代码是Troy Melhase在Google做的。这是一些PyKDE功能的演示。Troy向PyKDE捐献了一些示例代码，我可肯定pykde示例是很不错的。
Eric是什么？
Eric是一个进行Python的集成开发环境/调试器，特别是为PyQt和PyKDE开发做的很好，但不仅于此。它包含了对每个已发明的软件工具的支持，甚至BBicycle Repairman, CVS 和subversion,还有 Qt Designer的支持。它的创建者和维护者是Detlev Offenbach，无论从输出的数量和质量来看，它可能是一个编程工具的集大成者。一个Qt 4的版本马上就可用了。
我就是一个Eric的粉丝和用户，但不是开发者。
您是否希望看到PyKDE在KDE中的大量应用？
在KDE和KOffice中PyKDE得到越来越多的应用和并提供了对Python的更简便 的接口，这是其它语言如perl和Ruby没有做到的。使用sip生成绑定几乎像没有困难（当你克服了学习困难之后），举个例子，很多KDE插件需要加载一个C++（.so）库，大多数人用Python就完成了，他们不懂c++或是不想用C++来处理它们。
像一些如面板小程序之类的东西，我们（主要是David Boddie）懂得编写一个.so库然后欺骗kicker用它来加载任何基于Python的小程序，但通常这种方法对绝大多数KDE程序是无效的，虽然它有可能成功。这也可能可以为Python程序员开发出可以自动生成这些.so或.la文件的工具，但我还是喜欢一个更清楚的作法。
DCOP是一种可以实现它们的途径，但它常常不会暴露出应用程序足够的真正有用的API。绑定插件时理解程序的部分API是很有用的，程序如OpenOffice的Python-UNO太过复杂而使新手望而生畏，老手不愿去用。KDE作为一个平台，似乎很清晰也很容易去使用其接口。
我的目标是可以使任何大型语言在平台及其应用程序上可以像Windows用户使用VB一样方便，或者更方便。我当然希望更多用户使用PyKDE，但对于某些工作（如编辑一个电子表格），使用PyKDE就显得杀鸡用牛刀了。 |
|
IP卡
狗仔卡
发表于 2006-9-10 22:21:06
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
显身卡
楼主