酒杯上的碟.docVIP

酒杯上的碟 酒杯上的碟 (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,包含并且升级了 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. 本文的余下部分将回答第二个问题. 不让你返回(????)(Dont Want You Back) 我们的目标是让开发者容易地将应用程序转移到linux下,并且困难要最小化.大部分(新旧控件)的名字都是一样的,大部分的属性也是一样的.尽管有一些控件的少数属性去掉了,增加了一些新的属性,但对于绝大部分来说,应该可以平稳的转移你的应用程序. 对控件作者来说有一些不同. 对于一个新手,现在没有了,也没有Windows API了.你可以对message标识和所有CN,CM通知(notifications)说再见了.这些都转换成了动态的(dynamics)(???).在第一版中也不再有dock,BiDi相关的方法/属性,输入法(IME),远东语言支持了.当然,更不会有ActiveX,COM或者OLE支持,控件也去掉了. Methods CreatePa