KDE言语绑定──KDE-Bindings
来自：KDE中国
KDE-Bindings介绍
关于开辟人员来说，可以利用快意的编程言语不缩水地撰写出原属另一种言语的程序，超越单一言语的边界是值得欢欣的事，除了个人偏好使然，这还可以让种种编程言语的内涵优点获得更深条理的发扬，比方Python对GTK 的绑定就允许开辟者利用本身不搜聚图形构件却具有面向工具、异常检测措置责罚、语法自在等作风的Python表白器来计划正本修建在纯C框架上的图形界面程序。异常，KDE机关也供应了良多这样的机制，并不是必然要熟习C 才干用KDE开辟软件，用此外您熟习言语的言语也能抵达异常目标，甚至大要愈加也许高效。
在KDE-Bindings中有几个需求事后设立确立的不雅点，即DCOP绑定、Qt绑定、KDE绑定三者间的区别。DCOP绑定专门针对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 | Possible Broken | Broken ]
Working
DCOPPerl
DCOP对Perl的绑定。这是一个允许用户编写Perl脚本控制DCOP呼喊的衔接桥，DCOP本身对脚本就很和睦，利用Perl来做到这点意味着您可以利用本身熟习的语法状态来杀青异常的目标。看重DCOPPerl并不同等于PerlQt/PerlKDE绑定，它不克不及建树以Perl撰写的Qt/KDE图形界面程序，而只是针对DCOP脚本特性的一种替换选择。
作为题外话，理论上PerlQt和PerlKDE绑定组件并不被搜聚在KDE-Bindings中，您需求另行获得。个中PerlQt的可用性较高，负担负责了Qt的400多个类和13000个以上的函数，它的一个较有数运用场所是GNU/Debian操作琐细的中的KDE作风软件包设置界面。而PerlKDE的完成度很低且项目停滞，现在根蒂根底没有理论的运用。
DCOPPython
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 Korundum
QtRuby是Qt对脚本言语Ruby的绑定，而Korundum是KDE对Ruby的绑定。它们告别供应了一组Ruby言语模块，可以在编写Ruby脚本时导入，从而负担负责Qt/KDE类的效果。
QtRuby Korundum现今已有一些理论运用，比方在Amarok这个KDE下的音频播放器中支撑脚本，另有研发中的数字音频点播平台spectaKle。个中Korundum之中还搜聚了四个小组件：
- krubyinit：浸染和Ruby表白器主程序雷同，但它利用kdeinit历程替换ruby本身加载利用了Korundum模块的Ruby脚本，在KDE状态下利用它运转Korundum脚本可以减速程序启动，而且它所接受的参数规范也和ruby本身根蒂根底分歧。
- rbkconfig_compiler：用于将XML式子的KConfig界面定义设置文件源文件转换为深入文本式子。
- rbkdesh：固然搜聚在Korundum内，但它是交互式的QtRuby操作前端，界面完全回收Qt元素。
- rbkdeapi：雷同Java目标码反汇编器 javap，它可以将一个Korundum类里挪用过的方法以可读式子分解出来。
SIP PyQt PyKDE
这是一套完备的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对应的效果模块和名字空间，这些模块是dcop、kdecore、kdesu、kdefx、kdeui、kio、kutils、kfile、kparts、khtml、kspell、kdeprint、kmdi，这个中搜聚KDE负担负责并拓展自Qt的600多个类和10000多种函数（不是全数）。
在PyQt和PyKDE之中，PyQt因框架较笨重战争台限定少等缘由其运用局限要明闻达年夜于PyQt，而且它的发布协议和Qt3一样，都是双重授权。PyKDE固然效果很丁壮夜，但由于绑定的条理较高，托付宏年夜，理论运用项目很少。
SMOKE
SMOKE是一种脚本元数据编译引擎，可以只与Qt结合利用，也可同时和Qt/KDE结合。作为一套框架类库，它的计划目标是要在通用层面上供此外开辟者无邪易用地扩展KDE和脚本言语的绑定接口，一个新的脚本言语绑定在编写时要关注的不该该是Qt/KDE的类与方法怎样完成和本身语法的映射，只需看重怎样措置责罚句柄、参数指针的传递等不久不多的身分。而SMOKE则在面前对Qt/KDE中每一个类里的每一个函数予以包装，同时对函数的可用参数与前往值类型都供应了便于究诘的元信息，SMOKE将Qt/KDE的接口以交错援用的数组形式完成映射和转换，从而年夜年夜减缓了脚本言语绑定程序在针对Qt/KDE开辟时的庞英俊。
现在基于SMOKE引擎的绑定套件有PerlQt（不属于KDE-Bindings）、QtRuby、Korundum三种，即便作为深入桌面用户，您也可以发明QtRuby/Korundum的代码量要远远少于PyQt/PyKDE，这个中很年夜部分是缘于SMOKE的功烈。
Possible Broken
DCOPC
DCOP对GTK 1.x的绑定。GTK 1.x是晚期的图像制作软件Gimp 1.x的图形开辟包，也是GNOME 1.x 的底层，现根蒂根底已被GTK 2.x所替换，GTK也是开源局限内运用最广泛的图形界面程序开辟包之一，以C作为开辟言语。
DCOPC是个历史产品，它源码末端一次更新还是在2003年前后，在现在的操作琐细中由于头文件援用途径定义的错误若您想要编译它都有必然坚苦。有来由以为此项目不会再延续，考虑到GTK1.x本身的近况这应该是合理且可以接受的结果。
XParts
点击缩小
这实在不是一套言语间的绑定，而是一种特殊的组件嵌入技术手段模型。
正如经常所认知的那样，KParts这一KDE焦点技术手段只能由KDE程序挪用，但抱负上非KDE程序是不是也可以利用KParts脑筋，让不同框架的程序都可以在KDE里以嵌入组件的形式广泛运用倒是一个让人感兴味的英勇课题，XParts便是出于这样一个念头的尝试。
在KDE-Bindings中，XParts还是一个框架性质年夜于适用性质的组件，搜聚嵌入式记事本和KMozilla两个成型的实施产品。Mozilla Navigator是一个以GTK 为图形构件的收集阅读器（不外现在已经中止，原开辟组转向了此外项目，官方网站点此）。从事理上讲，XParts组件容器固然会被KDE运用程序当作一个规范的KParts部件，但实在它是一个藉由DCOP历程通讯衔接的代理，代理面前的历程才是组件本身的实例。由于这之中的种种弗成料想的多变性，XParts的开辟遇到了比想像的更多的妨碍，开辟者必须试图重重制止KParts技术手段的后天限定，是以尽管作者对这条路途颇有信心，但至今其真实进度大要仍然在水下，并不敞亮阴晦。
Broken
Qt#
Qt对C#，即.NET的编程言语的绑定。应该说Qt#的开辟已经停滞，自2004年3月后没有再发布过新版，尽管它已经的展开状态不错，已对Qt的476个类完成C#言语包装，不外到现在它的适用代价已被研讨参考代价所代替。
另一方面，固然类Unix平台上的.NET技术手段展开较慢，但现今已有Mono项目成为了这个标的目标的领头羊，.NET程序运转库mono、编译器mcs、集成开辟状态monodevelop这一条完备的开辟工具链都已经步入了理论运用阶段，但还未抵达企业规范的水平。它欢欣于建树在类Unix平台上原生的C#运用程序，并做到跨平台（类Unix平台和Windows）运转。
固然Qt#遥遥无期，但Qt本身实在也是跨平台的开辟类库。在Qt4发布后，Windows、MacOS也获得了在这个平台上以GPL授权发布的开放源码版本Qt，这也让KDE走向多平台原生运转的末端一条天然屏障被撤去，是以我们并不以为Qt#的瘫痪是个严峻丧失落。
版权声明：
原创作品，允许转载，转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。不然将追查法则责任。
