来自：KDE中国
KDE-Bindings介绍
对于开发人员来说，能够使用称心的编程语言不缩水地撰写出原属另一种语言的程序，跨越单一语言的界限是值得欢欣的事，除了个体偏好使然，这还可以让各种编程语言的内在优点获得更深层次的发挥，例如对的绑定就允许开发者使用自身不包含图形构件却具备面向对象、异常检测处理、语法自由等风格的Python解释器来设计原本建筑在纯C框架上的图形界面程序。同样，KDE组织也提供了许多这样的机制，并不是一定要熟悉C++才能用KDE开发软件，用其它您熟悉语言的语言也能达到同样目的，甚至可能更加简单高效。
在KDE-Bindings中有几个需要预先确立的概念，即DCOP绑定、Qt绑定、KDE绑定三者间的区别。DCOP绑定专门针对这种KDE特有的进程通讯机制，它不涉及图形构件，只是起到一个连接桥的作用，它可能被单独分包，也可能被整合在一个完整的Qt/KDE绑定里，它只能让要绑定的语言获得对KDE中DCOP呼叫功能的继承。Qt绑定的模块组件只会动态连接到属于Qt的类库中，它一一对应实现的是Qt里的类而没有KDE的，即与KDE完全没有相依关系。KDE绑定要建立在已有的Qt绑定之上，它实现的才是KDE中特有的类。一个范例是，用户可以对比下分别用PyQt和PyKDE撰写的图形界面程序里的“文件选取”对话框，您会发现后者窗口里的构件和功能远远比前者的多，这就是对于同一种功能，KDE和Qt里对应的类的设计差异反映到语言绑定上的结果。
必须事先说明的是，并非所有的KDE-Bindings组件都具备良好的进行中维护，其中有的项目由于种种原因已不再有继续进展的迹象。它们中许多仍然被保留在这里，但缺省时将不会被构建安装，只是因为抱有研究兴趣的用户可能会需要它们而存在。在下文中将会把正常工作的部件和其他可用性有问题（基本这也意味着缺乏维护而且没有感兴趣的后继者）的部件分开说明，并根据官方的分类，从维护度高到低划为
Working（工作正常）、
Possible Broken（可能已失效）和
Broken（已失效）三个等级。
KDE-Bindings主要软件：
[ | | ]
Working DCOP对的绑定。这是一个允许用户编写Perl脚本控制DCOP呼叫的连接桥，DCOP本身对脚本就很友好，使用Perl来做到这点意味着您可以使用自己熟悉的语法环境来达成同样的目的。注意DCOPPerl并不等同于PerlQt/PerlKDE绑定，它不能创建以Perl撰写的Qt/KDE图形界面程序，而只是针对DCOP脚本特性的一种替换选择。
作为题外话，实际上和PerlKDE绑定组件并不被包含在KDE-Bindings中，您需要另行取得。其中PerlQt的可用性较高，继承了Qt的400多个类和13000个以上的函数，它的一个较常见应用场合是操作系统的中的KDE风格软件包设置界面。而PerlKDE的完成度很低且项目停滞，目前基本没有实际的应用。
DCOP对Python的绑定模块。它的作用和DCOPPerl大抵类似，只是绑定语言不同。
QtJava+KDEJava(Koala)
这一对软件包分别在J2SE领域实现了Qt对Java、KDE对Java的绑定。
QtJava包括一个qtjava.jar和共享库libqtjava.so。其中qtjava.jar是一套预编译的Java目标码，通过JNI（Java Native Interface）技术允许用户编写的Java程序能调用Qt的图形构件库代替Awt或Swing，而libkdejava则是连接桥，一一对应地实现Qt里各个原生的类绑定到Java上的内部流程。
KDEJava包括koala.jar和一个共享库libkdejava。KDEJava同样是利用JNI技术完成KDE图形界面构件对Awt/Swing的替换，在设计结构上它和QtJava基本相同，只是改由KDE代替Qt作为包装。
QtJava和KDEJava虽然为自己的目的作了很多努力，但很可惜尽管它们步入了实用阶段，但却没有实际的项目使用它们。而现在，Qt4会以官方立场提供和Java语言的绑定，这里的QtJava和KDEJava项目恐怕将会无限期中止，事实上。我们不建议您现在以研究目的以外的动机去摆弄这套软件。
![kjsembed]()
KJSEmbed为KDE提供了嵌入JavaScript脚本支持，它其实是一种ECMAScript的具体应用。ECMAScript本身并非是任何一种语言的代称，它是可扩充宿主环境脚本语言（在这里宿主环境就是Qt/KDE应用程序）的最小特性规范。在原则上利用KJSEmbed机制可以让开发者使用较易掌握和调试的JavaScript脚本语言以插件形式扩充KDE软件的功能。虽然它在KDE3中尚未被推广，但未来的KDE4将赋予它重要的地位。
图示的是KJSEmbed中内置的一个控制台，可供简单的代码测试。
QtRuby是Qt对脚本语言的绑定，而Korundum是KDE对Ruby的绑定。它们分别提供了一组Ruby语言模块，可以在编写Ruby脚本时导入，从而继承Qt/KDE类的功能。
QtRuby+Korundum现今已有一些实际应用，例如在这个KDE下的音频播放器中支持脚本，还有研发中的数字音频点播平台。其中Korundum之中还包含了四个小组件：
- krubyinit：作用和Ruby解释器主程序类似，但它使用kdeinit进程代替ruby本身加载使用了Korundum模块的Ruby脚本，在KDE环境下使用它运行Korundum脚本可以加速程序启动，而且它所接受的参数规范也和ruby本身基本一致。
- rbkconfig_compiler：用于将XML格式的KConfig界面定义配置文件源文件转换为普通文本格式。
- rbkdesh：虽然包含在Korundum内，但它是交互式的QtRuby操作前端，界面完全采用Qt元素。
- rbkdeapi：类似Java目标码反汇编器 javap，它可以将一个Korundum类里调用过的方法以可读格式解析出来。
这是一套完整的KDE/Qt对Python的绑定程序，它在各种绑定语言中的开发用户普及率也许在KDE-Bindings中是相对最高的，包含三个框架部分：
- SIP：它是C++对Python的绑定接口代码生成器，在PyQt和PyKDE中，它被用于自动创建编译PyQt/PyKDE时所需的一系列代码文件。
- PyQt：Qt对Python的绑定，实现了Qt3的300多个类和5700多个函数。它们被通过一组Python模块的形式来安装，PyQt的每个模块都对应一个主要的Qt名字空间（namespace），即qt、qtcanvas、qtnetwork、qtsql、qttable、qtui、qtxml、qtgl，以及一个附加的Scintillar源码编辑器类接口模块qtext。由于Python和Qt都具有跨平台特性，所以PyQt其实也是一套跨平台产品。
- PyKDE：KDE对Python的绑定，它和PyQt都是同一个项目组的产物，但由于KDE3的性质它不是跨平台的。PyKDE和PyQt类似，也是以一组Python模块的形式一一绑定了KDE对应的功能模块和名字空间，这些模块是、、、、、、、kfile、、、、，这其中包括KDE继承并拓展自Qt的600多个类和10000多种函数（不是全部）。
应当认为，基于Python的绑定在桌面应用上现在已愈加受青睐。可以找到很多现成的例子，如自创的图形界面系统配置工具基本都是使用Python辅助外部模块写成；著名的P2P软件BitTorrent客户端也是Python程序；KDE下功能最出众的的音频播放管理软件中有大量使用PyQt/PyKDE写成的带图形界面脚本……综观整体，PyQt/PyKDE的快速开发优势在桌面小部件上体现得最为明显，但也有规模较大的应用如，它是一个面向Python和Ruby两种脚本语言的集成开发/调试环境。从这些现状我们也可以看出Python绑定技术在桌面开发上的热门度和成熟度。
在PyQt和PyKDE之中，PyQt因框架较轻便和平台限制少等原因其应用范围要明显要大于PyQt，而且它的发布协议和Qt3一样，都是双重授权。PyKDE虽然功能很强大，但由于绑定的层次较高，依赖庞大，实际应用项目很少。
SMOKE是一种脚本元数据编译引擎，可以只与Qt结合使用，也可同时和Qt/KDE结合。作为一套框架类库，它的设计目的是要在通用层面上供其它开发者灵活易用地扩展KDE和脚本语言的绑定接口，一个新的脚本语言绑定在编写时要关注的不应该是Qt/KDE的类与方法如何完成和自身语法的映射，只要注重如何处理句柄、参数指针的传递等不多的因素。而SMOKE则在背后对Qt/KDE中每一个类里的每一个函数予以包装，同时对函数的可用参数与返回值类型都提供了便于查询的元信息，SMOKE将Qt/KDE的接口以交叉引用的数组形式完成映射和转换，从而大大减缓了脚本语言绑定程序在针对Qt/KDE开发时的复杂度。
现在基于SMOKE引擎的绑定套件有（不属于KDE-Bindings）、三种，即使作为普通桌面用户，您也可以发现QtRuby/Korundum的代码量要远远少于PyQt/PyKDE，这其中很大部分是缘于SMOKE的功劳。
Possible Broken DCOP对GTK 1.x的绑定。GTK 1.x是早期的图像制作软件 1.x的图形开发包，也是 1.x 的底层，现基本已被 2.x所替代，GTK也是开源领域内应用最广泛的图形界面程序开发包之一，以C作为开发语言。
DCOPC是个历史产物，它源码最后一次更新还是在2003年前后，在现在的操作系统中由于头文件引用路径定义的错误若您想要编译它都有一定困难。有理由认为此项目不会再继续，考虑到GTK1.x本身的现状这应该是合理且可以接受的结果。
这其实不是一套语言间的绑定，而是一种特殊的组件嵌入技术模型。
正如通常所认知的那样，这一KDE核心技术只能由KDE程序调用，但理论上非KDE程序是不是也可以利用KParts思想，让不同框架的程序都可以在KDE里以嵌入组件的形式广泛应用却是一个让人感兴趣的大胆课题，XParts就是出于这样一个动机的尝试。
在KDE-Bindings中，XParts还是一个框架性质大于实用性质的组件，包括嵌入式记事本和KMozilla两个成型的试验产物。Mozilla Navigator是一个以GTK+为图形构件的网络浏览器（不过现在已经终止，原开发组转向了其它项目，官方网站）。从原理上讲，XParts组件容器虽然会被KDE应用程序当作一个标准的KParts部件，但其实它是一个藉由DCOP进程通讯连接的代理，代理背后的进程才是组件本身的实例。由于这之中的种种不可预料的多变性，XParts的开发遇到了比想像的更多的障碍，开发者必须试图重重克服KParts技术的先天限制，因此尽管作者对这条道路颇有信心，但至今其真实进度也许仍然在水下，并不明朗。
Broken Qt对C#，即.NET的编程语言的绑定。应该说Qt#的开发已经停滞，自2004年3月后没有再发布过新版，尽管它曾经的发展状况不错，已对Qt的476个类完成C#语言包装，不过到现在它的实用价值已被研究参考价值所取代。
另一方面，虽然类Unix平台上的.NET技术发展较慢，但现今已有项目成为了这个方向的领头羊，.NET程序运行库mono、编译器mcs、集成开发环境monodevelop这一条完整的开发工具链都已经步入了实际应用阶段，但还未达到企业标准的程度。它致力于创建在类Unix平台上原生的C#应用程序，并做到跨平台（类Unix平台和Windows）运行。
虽然Qt#遥遥无期，但Qt自身其实也是跨平台的开发类库。在Qt4发布后，Windows、MacOS也获得了在这个平台上以GPL授权发布的开放源码版本Qt，这也让KDE走向多平台原生运行的最后一条天然屏障被撤去，因此我们并不认为Qt#的瘫痪是个重大损失。
