KDE語言綁定──KDE

guitarhua 2012-12-26

展開全文

KDE語言綁定──KDE-Bindings

來源: ChinaUnix博客　日期： 2008.05.27 16:46　(共有條評論) 我要評論

來自：KDE中國
KDE-Bindings介紹對于開發(fā)人員來說，能夠使用稱心的編程語言不縮水地撰寫出原屬另一種語言的程序，跨越單一語言的界限是值得歡欣的事，除了個(gè)體偏好使然，這還可以讓各種編程語言的內(nèi)在優(yōu)點(diǎn)獲得更深層次的發(fā)揮，例如
Python
對
GTK+
的綁定就允許開發(fā)者使用自身不包含圖形構(gòu)件卻具備面向?qū)ο蟆惓z測處理、語法自由等風(fēng)格的Python解釋器來設(shè)計(jì)原本建筑在純C框架上的圖形界面程序。同樣，KDE組織也提供了許多這樣的機(jī)制，并不是一定要熟悉C++才能用KDE開發(fā)軟件，用其它您熟悉語言的語言也能達(dá)到同樣目的，甚至可能更加簡單高效。
在KDE-Bindings中有幾個(gè)需要預(yù)先確立的概念，即DCOP綁定、Qt綁定、KDE綁定三者間的區(qū)別。DCOP綁定專門針對
DCOP
這種KDE特有的進(jìn)程通訊機(jī)制，它不涉及圖形構(gòu)件，只是起到一個(gè)連接橋的作用，它可能被單獨(dú)分包，也可能被整合在一個(gè)完整的Qt/KDE綁定里，它只能讓要綁定的語言獲得對KDE中DCOP呼叫功能的繼承。Qt綁定的模塊組件只會(huì)動(dòng)態(tài)連接到屬于Qt的類庫中，它一一對應(yīng)實(shí)現(xiàn)的是Qt里的類而沒有KDE的，即與KDE完全沒有相依關(guān)系。KDE綁定要建立在已有的Qt綁定之上，它實(shí)現(xiàn)的才是KDE中特有的類。一個(gè)范例是，用戶可以對比下分別用PyQt和 PyKDE撰寫的圖形界面程序里的“文件選取”對話框，您會(huì)發(fā)現(xiàn)后者窗口里的構(gòu)件和功能遠(yuǎn)遠(yuǎn)比前者的多，這就是對于同一種功能，KDE和Qt里對應(yīng)的類的設(shè)計(jì)差異反映到語言綁定上的結(jié)果。
必須事先說明的是，并非所有的KDE-Bindings組件都具備良好的進(jìn)行中維護(hù)，其中有的項(xiàng)目由于種種原因已不再有繼續(xù)進(jìn)展的跡象。它們中許多仍然被保留在這里，但缺省時(shí)將不會(huì)被構(gòu)建安裝，只是因?yàn)楸в醒芯颗d趣的用戶可能會(huì)需要它們而存在。在下文中將會(huì)把正常工作的部件和其他可用性有問題（基本這也意味著缺乏維護(hù)而且沒有感興趣的后繼者）的部件分開說明，并根據(jù)官方的分類，從維護(hù)度高到低劃為Working（工作正常）、Possible Broken（可能已失效）和Broken（已失效）三個(gè)等級。
KDE-Bindings主要軟件：
[
Working
|
Possible Broken
|
Broken
]
Working
DCOPPerlDCOP對
Perl
的綁定。這是一個(gè)允許用戶編寫Perl腳本控制DCOP呼叫的連接橋，DCOP本身對腳本就很友好，使用Perl來做到這點(diǎn)意味著您可以使用自己熟悉的語法環(huán)境來達(dá)成同樣的目的。注意DCOPPerl并不等同于PerlQt/PerlKDE綁定，它不能創(chuàng)建以Perl撰寫的Qt/KDE圖形界面程序，而只是針對DCOP腳本特性的一種替換選擇。
作為題外話，實(shí)際上
PerlQt
和PerlKDE綁定組件并不被包含在KDE-Bindings中，您需要另行取得。其中PerlQt的可用性較高，繼承了Qt的400多個(gè)類和13000個(gè)以上的函數(shù)，它的一個(gè)較常見應(yīng)用場合是
GNU/Debian
操作系統(tǒng)的中的KDE風(fēng)格軟件包設(shè)置界面。而PerlKDE的完成度很低且項(xiàng)目停滯，目前基本沒有實(shí)際的應(yīng)用。
DCOPPythonDCOP對Python的綁定模塊。它的作用和DCOPPerl大抵類似，只是綁定語言不同。
QtJava+KDEJava(Koala)這一對軟件包分別在J2SE領(lǐng)域?qū)崿F(xiàn)了Qt對Java、KDE對Java的綁定。
QtJava包括一個(gè)qtjava.jar和共享庫libqtjava.so。其中qtjava.jar是一套預(yù)編譯的Java目標(biāo)碼，通過 JNI（Java Native Interface）技術(shù)允許用戶編寫的Java程序能調(diào)用Qt的圖形構(gòu)件庫代替Awt或Swing，而libkdejava則是連接橋，一一對應(yīng)地實(shí)現(xiàn) Qt里各個(gè)原生的類綁定到Java上的內(nèi)部流程。
KDEJava包括koala.jar和一個(gè)共享庫libkdejava。KDEJava同樣是利用JNI技術(shù)完成KDE圖形界面構(gòu)件對Awt/Swing的替換，在設(shè)計(jì)結(jié)構(gòu)上它和QtJava基本相同，只是改由KDE代替Qt作為包裝。
QtJava和KDEJava雖然為自己的目的作了很多努力，但很可惜盡管它們步入了實(shí)用階段，但卻沒有實(shí)際的項(xiàng)目使用它們。而現(xiàn)在，Qt4會(huì)以官方立場提供和Java語言的綁定，這里的QtJava和KDEJava項(xiàng)目恐怕將會(huì)無限期中止，事實(shí)上。我們不建議您現(xiàn)在以研究目的以外的動(dòng)機(jī)去擺弄這套軟件。
KJSEmbed

KJSEmbed為KDE提供了嵌入JavaScript腳本支持，它其實(shí)是一種ECMAScript的具體應(yīng)用。ECMAScript本身并非是任何一種語言的代稱，它是可擴(kuò)充宿主環(huán)境腳本語言（在這里宿主環(huán)境就是Qt/KDE應(yīng)用程序）的最小特性規(guī)范。在原則上利用KJSEmbed機(jī)制可以讓開發(fā)者使用較易掌握和調(diào)試的JavaScript腳本語言以插件形式擴(kuò)充KDE軟件的功能。雖然它在KDE3中尚未被推廣，但未來的KDE4將賦予它重要的地位。
圖示的是KJSEmbed中內(nèi)置的一個(gè)控制臺，可供簡單的代碼測試。
QtRuby+KorundumQtRuby是Qt對腳本語言
Ruby
的綁定，而Korundum是KDE對Ruby的綁定。它們分別提供了一組Ruby語言模塊，可以在編寫Ruby腳本時(shí)導(dǎo)入，從而繼承Qt/KDE類的功能。
QtRuby+Korundum現(xiàn)今已有一些實(shí)際應(yīng)用，例如在
Amarok
這個(gè)KDE下的音頻播放器中支持腳本，還有研發(fā)中的數(shù)字音頻點(diǎn)播平臺
spectaKle
。其中Korundum之中還包含了四個(gè)小組件：

krubyinit：作用和Ruby解釋器主程序類似，但它使用kdeinit進(jìn)程代替ruby本身加載使用了Korundum模塊的Ruby腳本，在KDE環(huán)境下使用它運(yùn)行Korundum腳本可以加速程序啟動(dòng)，而且它所接受的參數(shù)規(guī)范也和ruby本身基本一致。
rbkconfig_compiler：用于將XML格式的KConfig界面定義配置文件源文件轉(zhuǎn)換為普通文本格式。
rbkdesh：雖然包含在Korundum內(nèi)，但它是交互式的QtRuby操作前端，界面完全采用Qt元素。
rbkdeapi：類似Java目標(biāo)碼反匯編器 javap，它可以將一個(gè)Korundum類里調(diào)用過的方法以可讀格式解析出來。

SIP+PyQt+PyKDE這是一套完整的KDE/Qt對Python的綁定程序，它在各種綁定語言中的開發(fā)用戶普及率也許在KDE-Bindings中是相對最高的，包含三個(gè)框架部分：

SIP：它是C++對Python的綁定接口代碼生成器，在PyQt和PyKDE中，它被用于自動(dòng)創(chuàng)建編譯PyQt/PyKDE時(shí)所需的一系列代碼文件。
PyQt：Qt對Python的綁定，實(shí)現(xiàn)了Qt3的300多個(gè)類和5700多個(gè)函數(shù)。它們被通過一組Python模塊的形式來安裝，PyQt的每個(gè)模塊都對應(yīng)一個(gè)主要的Qt名字空間（namespace），即qt、qtcanvas、qtnetwork、qtsql、 qttable、qtui、qtxml、qtgl，以及一個(gè)附加的Scintillar源碼編輯器類接口模塊qtext。由于Python和Qt都具有跨平臺特性，所以PyQt其實(shí)也是一套跨平臺產(chǎn)品。
PyKDE：KDE對Python的綁定，它和PyQt都是同一個(gè)項(xiàng)目組的產(chǎn)物，但由于KDE3的性質(zhì)它不是跨平臺的。PyKDE和PyQt類似，也是以一組Python模塊的形式一一綁定了KDE對應(yīng)的功能模塊和名字空間，這些模塊是
dcop
、
kdecore
、
kdesu
、
kdefx
、
kdeui
、
kio
、
kutils
、kfile、
kparts、khtml
、
kspell
、
kdeprint
、
kmdi
，這其中包括KDE繼承并拓展自Qt的600多個(gè)類和10000多種函數(shù)（不是全部）。

應(yīng)當(dāng)認(rèn)為，基于Python的綁定在桌面應(yīng)用上現(xiàn)在已愈加受青睞?？梢哉业胶芏喱F(xiàn)成的例子，如
Red Hat Linux
自創(chuàng)的圖形界面系統(tǒng)配置工具基本都是使用Python輔助外部模塊寫成；著名的P2P軟件BitTorrent客戶端也是Python程序；KDE下功能最出眾的的音頻播放管理軟件
AmaroK
中有大量使用PyQt/PyKDE寫成的帶圖形界面腳本……綜觀整體，PyQt/PyKDE的快速開發(fā)優(yōu)勢在桌面小部件上體現(xiàn)得最為明顯，但也有規(guī)模較大的應(yīng)用如
Eric
，它是一個(gè)面向Python和Ruby兩種腳本語言的集成開發(fā)/調(diào)試環(huán)境。從這些現(xiàn)狀我們也可以看出Python綁定技術(shù)在桌面開發(fā)上的熱門度和成熟度。
在PyQt和PyKDE之中，PyQt因框架較輕便和平臺限制少等原因其應(yīng)用范圍要明顯要大于PyQt，而且它的發(fā)布協(xié)議和Qt3一樣，都是雙重授權(quán)。PyKDE雖然功能很強(qiáng)大，但由于綁定的層次較高，依賴龐大，實(shí)際應(yīng)用項(xiàng)目很少。
SMOKESMOKE是一種腳本元數(shù)據(jù)編譯引擎，可以只與Qt結(jié)合使用，也可同時(shí)和Qt/KDE結(jié)合。作為一套框架類庫，它的設(shè)計(jì)目的是要在通用層面上供其它開發(fā)者靈活易用地?cái)U(kuò)展KDE和腳本語言的綁定接口，一個(gè)新的腳本語言綁定在編寫時(shí)要關(guān)注的不應(yīng)該是Qt/KDE的類與方法如何完成和自身語法的映射，只要注重如何處理句柄、參數(shù)指針的傳遞等不多的因素。而SMOKE則在背后對Qt/KDE中每一個(gè)類里的每一個(gè)函數(shù)予以包裝，同時(shí)對函數(shù)的可用參數(shù)與返回值類型都提供了便于查詢的元信息，SMOKE將Qt/KDE的接口以交叉引用的數(shù)組形式完成映射和轉(zhuǎn)換，從而大大減緩了腳本語言綁定程序在針對Qt /KDE開發(fā)時(shí)的復(fù)雜度。
現(xiàn)在基于SMOKE引擎的綁定套件有
PerlQt
（不屬于KDE-Bindings）、
QtRuby、Korundum
三種，即使作為普通桌面用戶，您也可以發(fā)現(xiàn)QtRuby/Korundum的代碼量要遠(yuǎn)遠(yuǎn)少于PyQt/PyKDE，這其中很大部分是緣于SMOKE的功勞。
Possible Broken
DCOPCDCOP對GTK 1.x的綁定。GTK 1.x是早期的圖像制作軟件
Gimp
1.x的圖形開發(fā)包，也是
GNOME
1.x 的底層，現(xiàn)基本已被
GTK
2.x所替代，GTK也是開源領(lǐng)域內(nèi)應(yīng)用最廣泛的圖形界面程序開發(fā)包之一，以C作為開發(fā)語言。
DCOPC是個(gè)歷史產(chǎn)物，它源碼最后一次更新還是在2003年前后，在現(xiàn)在的操作系統(tǒng)中由于頭文件引用路徑定義的錯(cuò)誤若您想要編譯它都有一定困難。有理由認(rèn)為此項(xiàng)目不會(huì)再繼續(xù)，考慮到GTK1.x本身的現(xiàn)狀這應(yīng)該是合理且可以接受的結(jié)果。
XParts

點(diǎn)擊放大

這其實(shí)不是一套語言間的綁定，而是一種特殊的組件嵌入技術(shù)模型。
正如通常所認(rèn)知的那樣，
KParts
這一KDE核心技術(shù)只能由KDE程序調(diào)用，但理論上非KDE程序是不是也可以利用KParts思想，讓不同框架的程序都可以在KDE里以嵌入組件的形式廣泛應(yīng)用卻是一個(gè)讓人感興趣的大膽課題，XParts就是出于這樣一個(gè)動(dòng)機(jī)的嘗試。
在KDE-Bindings中，XParts還是一個(gè)框架性質(zhì)大于實(shí)用性質(zhì)的組件，包括嵌入式記事本和KMozilla兩個(gè)成型的試驗(yàn)產(chǎn)物。Mozilla Navigator是一個(gè)以GTK+為圖形構(gòu)件的網(wǎng)絡(luò)瀏覽器（不過現(xiàn)在已經(jīng)終止，原開發(fā)組轉(zhuǎn)向了其它項(xiàng)目，官方網(wǎng)站
點(diǎn)此
）。從原理上講，XParts組件容器雖然會(huì)被KDE應(yīng)用程序當(dāng)作一個(gè)標(biāo)準(zhǔn)的KParts部件，但其實(shí)它是一個(gè)藉由DCOP進(jìn)程通訊連接的代理，代理背后的進(jìn)程才是組件本身的實(shí)例。由于這之中的種種不可預(yù)料的多變性，XParts的開發(fā)遇到了比想像的更多的障礙，開發(fā)者必須試圖重重克服KParts技術(shù)的先天限制，因此盡管作者對這條道路頗有信心，但至今其真實(shí)進(jìn)度也許仍然在水下，并不明朗。
Broken
Qt#Qt對C#，即.NET的編程語言的綁定。應(yīng)該說Qt#的開發(fā)已經(jīng)停滯，自2004年3月后沒有再發(fā)布過新版，盡管它曾經(jīng)的發(fā)展?fàn)顩r不錯(cuò)，已對Qt的476個(gè)類完成C#語言包裝，不過到現(xiàn)在它的實(shí)用價(jià)值已被研究參考價(jià)值所取代。
另一方面，雖然類Unix平臺上的.NET技術(shù)發(fā)展較慢，但現(xiàn)今已有
Mono
項(xiàng)目成為了這個(gè)方向的領(lǐng)頭羊，.NET程序運(yùn)行庫mono、編譯器mcs、集成開發(fā)環(huán)境monodevelop這一條完整的開發(fā)工具鏈都已經(jīng)步入了實(shí)際應(yīng) 用階段，但還未達(dá)到企業(yè)標(biāo)準(zhǔn)的程度。它致力于創(chuàng)建在類Unix平臺上原生的C#應(yīng)用程序，并做到跨平臺（類Unix平臺和Windows）運(yùn)行。
雖然Qt#遙遙無期，但Qt自身其實(shí)也是跨平臺的開發(fā)類庫。在Qt4發(fā)布后，Windows、MacOS也獲得了在這個(gè)平臺上以GPL授權(quán)發(fā)布的開放源碼版本Qt，這也讓KDE走向多平臺原生運(yùn)行的最后一條天然屏障被撤去，因此我們并不認(rèn)為Qt#的癱瘓是個(gè)重大損失。

本文來自ChinaUnix博客，如果查看原文請點(diǎn)：http://blog./u/31/showart_709270.html

本站是提供個(gè)人知識管理的網(wǎng)絡(luò)存儲(chǔ)空間，所有內(nèi)容均由用戶發(fā)布，不代表本站觀點(diǎn)。請注意甄別內(nèi)容中的聯(lián)系方式、誘導(dǎo)購買等信息，謹(jǐn)防詐騙。如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容，請點(diǎn)擊一鍵舉報(bào)。

午夜视频在线网站,日韩视频精品在线,中文字幕精品一区二区三区在线,在线播放精品,1024你懂我懂的旧版人,欧美日韩一级黄色片,一区二区三区在线观看视频

KDE語言綁定──KDE