酒杯上的碟

来源：非常论文网 www.verylw.com

酒杯上的碟
(The Dish on Kylix)
CLX / Customs controls / Cross-platform
作者: Robert Kozak
翻译: cAkk

交叉平台控件(Cross-platform Controls)
从windows到Linux,或者相反

Borland处在一个令人兴奋的时期.并不是自从delphi--这个Borland的令人兴奋的产品的第一声.我正在谈论的当然是关于Kylix,这个把C Builder和Delphi带到Linux操作系统的项目.Delphi版本将首先面世,所以在本文余下部分,Kylix指的是Delphi for Linux.

我们正在为Delphi开发崭新的能够在Windows和Linux下工作的VCL.这意味着你可以在windows下写一个应用程序,然后把源代码转移到Linux下面重新编译--反之亦然.这个新的VCL叫CLX,意即"交叉平台控件库(Component Library Cross-Platform)",CLX包含整个随Kylix发布的交叉平台库.在我写本文时它被分为下面四个子类:

BaseCLX就是RTL,包含并且升级了Classes.pas
VisualCLX包含了用户界面类,比如常用的控件
DataCLX包含交叉平台的数据库控件
NetCLX包含Internet部分,比如Apache等等..

在我写这篇文章的时候(2000年5月之前),Kylix的第一部分测试已经正在进行了.当你读到这篇文章的时候,我正在使用的Kylix和你将要看到的正式版本将会有很大不同.这为我的工作带来很多不便.是简单地谈一谈便罢?还是涉及一下底层的结构?我更倾向于详细的讨论,这样无论如何你能得到一点关于CLX控件构造的头绪.但是要牢记一点: 当你阅读此文的时候,很可能这篇文章中很多细节的讨论已经改变了.

没有更接近的了(No One Else Comes Close)

这篇文章是关于写定制VisualCLX控件的初级读本.从本质上说,VisualCLX就是你所知道并热爱的VCL.当你这样认为的时候,"可视构件库"(Visual Component Library)有一点用词不当:还有比"可视构件"更多的东西.但是在这篇文章里面,我只谈论"可视"控件.类似Button, Edit, ListBox, PageControl, StatusBar, ProgressBar等等的控件,都已经在交叉平台下重新实现.但是目前的VCL如此依赖Windows,我们是怎么做到这些的呢?简单地说,我们剥离了所有的Windows元素,然后把它们用别的工具包(toolkit)代替.

在Linux下,有大量的工具包包含标准windows控件(如Buttons).它们被称做"widgets".其中GTK和Qt(被发音成"cute")就是两个非常流行的.Qt是一个工作在windows和Linux下的widgets,因为它非常接近我们的目标,所以Qt被选择作为CLX的基础.换句话说,Qt和CLX就好像Windows API/通用控件和VCL的关系.对于Linux下的Delphi的定制构件开发者来说,Qt有一些明显的好处:

它是一个广泛使用的Linux下的widgets集,被流行的KDE桌面采用.
它的开发和Windows API风格非常相似
它的图形模块和VCL的图形模块相似
它的类看上去非常像VCL控件
它引入大量标准widgets,并且具有消息循环

这将引发两个疑问:是否这意味着Kylix只支持KDE,而不支持其他的桌面(desktop)?比如Gnome?并且,以Qt为基础的CLX会给我带来多大影响? 第一个问题的回答是:kylix应用程序将运行在所有Linux桌面下,特别是Gnome和KDE. 本文的余下部分将回答第二个问题.

不让你返回(????)(Don''t Want You Back)

我们的目标是让开发者容易地将应用程序转移到linux下,并且困难要最小化.大部分(新旧控件)的名字都是一样的,大部分的属性也是一样的.尽管有一些控件的少数属性去掉了,增加了一些新的属性,但对于绝大部分来说,应该可以平稳的转移你的应用程序.

对控件作者来说有一些不同. 对于一个新手,现在没有Windows.pas了,也没有Windows API了.你可以对message标识和所有CN,CM通知(notifications)说再见了.这些都转换成了动态的(dynamics)(???).在第一版中也不再有dock,BiDi相关的方法/属性,输入法(IME),远东语言支持了.当然,更不会有ActiveX,COM或者OLE支持,Windows 3.1控件也去掉了.

Methods
CreateParams
CreateSubClass
CreateWindowHandle
CreateWnd
DestroyWindowHandle
DestroyWnd
DoAddDockClient
DockOver
DoDockOver
DoRemoveDockClient
DoUnDock
GetDeviceContext
MainWndProc
ResetIme
ResetImeComposition
SetIme
SetImeCompositionWindow
WndProc
Properties
Ctl3D
DefWndProc
DockManager
DockSite
ImeMode
ImeName
ParentCtl3D
UseDockManager
WheelAccumulator

附图1: 从TWidgetControl(和TWinControl相类似)里面去掉的Methods和properties.

此刻我打赌你正在想:"还不坏.转移我的应用程序听上去不是很难",但是请等等----还有更多的.在写此文的时候,CLX类的名字都被加上了一个"Q"的前缀,比如StdCtrls变成了QStdCtrls,有些类被稍微搅乱了一点,在类继承上面只有一些细微差别.(见附图 2)

附图 2: 在类继承上面的细微区别.

CLX的这个"Q"前缀不一定是最终版本的前缀.TWinControl现在变成了TWidgetControl,不过为了安抚痛苦,我们为TWidgetControl添加了一个TWinControl的别名.TWidgetControl和它的后代都有一个Handle属性,隐式地指向Qt对象,有一个Hooks属性指向一个hook对象,用来实现事件机制.(Hooks是一个复杂的话题,已经超出本文的讨论范围)

OwnerDraw将被一种叫做Styles的方法替代. 基本上Styles是widget或应用程序显示新面孔的一种机制,类似于windows下面的贴图(skins). 这部分正在开发当中,所以本文中我无法更进一步的介绍,我只能说:它非常酷!

(新旧控件中)有没有什么是一样的?当然有,TCanvas(包括Pens,Brushes等)和你记得的一样.就像我说过的,类的继承基本上一样,还有事件,比如OnMouseDown, OnMouseMove, OnClick...等等都还在.

让我看看内涵(Show Me the Meaning)(???)

让我们进入到CLX的躯体,看看它是如何工作的.Qt是一个C 的工具集,所以所有的widgets都是C 对象.另一方面,CLX是用Object Pascal写的,并且Object Pascal不能直接和C 对象对话.越想简单就越难,Qt在几个地方使用了多继承,所以我们建立了一个接口层(interface layer)来获得所有Qt的类,并且把它们还原成一系列普通的C函数,然后把它们包装成Windows下的DLL或是Linux下的共享对象(shared object).

共5页:

上一篇：Windows NT中的登记项及其完整性下一篇：微机UNIX直接视频图形程序设计

服务项目