酒杯上的碟
交叉平台控件(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
UseDockMa 《酒杯上的碟》
本文链接地址：http://www.oyaya.net/fanwen/view/173009.html
从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
UseDockMa 《酒杯上的碟》
★读了本文的人也读了：