由MFC程序是否能够在Linux上运行谈起

首先，必须面对的现实是，不经修改的mfc程序是不能在linux下运行的，道理很简单，mfc的基石是windowsAPI,而linux上不可能有他。那么mfc开发的程序就没办法在linux上重用了吗？下面这篇文章为我们提供了一种方法：将MFC应用程序移植到Linux当然，如果你在编写软件的一开始就知道自己的程序需要运行在window和linux下，那么有人会建议你放弃mfc，而直接使用GTK+做为基础类库进行开发：GTK+简介关于MFC与GTK+的对比有此一家之言：GTK+与MFC不完全对比可以看到，MFC程序经过改造是可以移植到linux下的，不过，更直接的方法就是使用移植性强的类库，比如GTK+。==========================摘录==========================将MFC应用程序移植到Linux将Windows应用程序移植到Linux不必涉及再培训的痛苦经历。MarkusNeifer演示了如何使用wxWindows移植MFC，指导读者使用wxWindows这一开放源码工具箱，并循序渐进地向读者介绍了一个完整的移植示例。您可能仍然在维护用微软基础类（（MicrosoftFoundationClasses（MFC））构建的旧的Windows应用程序，而现在却有客户要求Linux版本，该怎么办呢？在您的团队中可能有技术熟练MFC开发人员，但如何达到加速Linux开发呢？别急；本文就是针对您这种情况而写的。依靠wxWindows（一种用于C++和Python的可移植GUI工具箱）的帮助，我将以多文档界面MultipleDocumentInterface（MDI））文本编辑器为例向您演示如何将仅Windows的MFC应用程序移植到Linux。类似这样的小型应用程序有助于我们将讨论集中在移植框架的具体细节上，从而避免我们迷失在代码的汪洋中。可以在本文后面参考资料一节中获取完整的MFC应用程序和wxWindows应用程序的源代码。文档/视图概述我将演示的应用程序使用众所周知的文档/视图体系结构，因为它可以象大多数应用程序一样处理文档。即使您的应用程序不使用文档/视图体系结构，我也建议您读下去。只要您已在转向这种框架，您就可能想要添加这项功能。在我的关于wxWindows的前一篇文章中，曾经指出过MFC和wxWindows之间具有某些相似性。字符串类CString、WxString和事件系统之间都非常相似。但还不止这些相似性wxWindows工具箱还提供对文档/视图体系结构的类MFC支持。我将从核心类的比较开始。下表列出了两种框架的文档/视图体系结构所涉及的类。表1.文档/视图类比较类MFC类wxWindows类文档(Document)CDocumentwxDocument视图（View）CViewwxView编辑视图（Editview）CEditViewn/a模板类(Templateclass)CMultiDocTemplatewxDocTemplateMDI父框架(MDIparentframe)CMDIFrameWndwxDocMDIParentFrameMDI子框架(MDIchildframe)CMDIChildWndwxDocMDIChildFrame文档管理器(Documentmanager)n/awxDocManager除编辑视图类以外，每个MFC类都有其对应的wxWindows类。（最后一项中MFC的部分为空，因为MFC没有独立的文档管理器类。由应用程序类CWinAPP内部处理文档。）下列UML图演示了这些类之间的关系：图1.MFC类

釜SMopufM^MM图

每个框架都提供一个表示应用程序本身的类MFC应用程序类声明了一个构造器、一个用于初始化的方法、一个用于事件处理的方法和一个消息映射表。您需要这个消息映射表声明和事件处理方法，因为应用程序的tout"对话框将由该类处理。应用程序类：MFCclassCPortMeApp:publicCWinApp{public:CPortMeApp();virtualBOOLInitInstance();afx_msgvoidOnAppAbout();DECLARE_MESSAGE_MAP()};注：最初创建MFC应用程序时，我使用MicrosoftVisualStudio所包含的应用程序向导来创建，但在我的代码片段中，我将不给出由向导生成的、有时会使人迷惑的注释(//{{AFX_MSG及类似的东西)。完整的源代码，请参I阅沪压缩文档。成的、有时会使人迷惑的注释(//{{AFX_MSG及类似的东西)。完整的源代码，请参I阅沪压缩文档。对应的wxWindows类看起来略微有些不同。它也声明了一个构造器及一个用于初始化的方法，但却不需要任何东西来处理消息。如同您随后将看到的一样，在主框架类中处理about"^话框。应用程序类：wxWindowsclassPortedApp:publicwxApp{public:PortedApp();boolOnInit();intOnExit();protected:wxDocManager*m_docManager;};正如下面所描述的那样这个类需要一个wxDocManagerw性来处理在初始化方法OnInit()中创建的模板。应用程序退出时，清理方法OnExit()将删除这个wxDocManager对象。所有应用程序都需要其入口点(也称^jmain()或WinMain())。在实现这一点的方法上，两种框架略微有些不同。在FC中，象这样创建应用程序类的静态对象:

CPortMeApptheApp;十鼻"REIMPLEMENTAPP(L在wxWindows中，则象这样使用宏:IMPLEMENT_APP(PortedApp)中它的定义，在可下载的源代码中找到该头文件基本上，它是为所使用的平台插如果对该宏所做的事情感兴趣，请查看头文件wx/app,h入适当的入口点函数。创建了应用程序类的对象之后，需要对其进行初始化。对于C，Microsoft建议不使用应用程序对象的构造器来初始化对象。而是应该使用其【niHnstancel)方法。要执行任何清理，请实『iHnstanceO方法。中它的定义，在可下载的源代码中找到该头文件基本上，它是为所使用的平台插虽然应用程序初始化有很多事情要做，这里我将只着重讨论与文档/视图有关的代码。要建立文档/视图框架nitInstance()方法必须创建一个CMultiDocTemplate如下所示:创建文档/视图代码:MFCCMultiDocTemplate*pDocTemplate;pDocTemplate=newCMultiDocTemplate(IDR_PORTMETYPE,RUNTIME_CLASS(CPortMeDoc),RUNTIME_CLASS(CChildFrame),RUNTIME_CLASS(CPortMeView));wxWindows应用程序提供OnInit()方法来做任何初始化"，并提供0nExit()用于清理。要在wxWindows应用程序中建立文档/视图框架，OnInit()方法必须象这样创建wXDocTemplate创建文档/视图代码：wxWindowswxWindows应用程序提供OnInit()方法来做任何初始化"，并提供0nExit()用于清理。要在wxWindows应用程序中建m_docManager=newwxDocManager();wxDocTemplate*pDocTemplate;pDocTemplate=newwxDocTemplate(m_docManager,"Pom”,"*.pom”,"”,"pom”,"PomDoc”,"TextView",CLASSINFO(PortedDoc),CLASSINFO(PortedView));MFC和wxWindows所做的事情基本上相同。框架需要关于哪个文档同哪个视图有关以及这个组合处理哪种文档的信息。类型包括文档的描述性名称以及这类文档的文件扩展名。两种框架都使用模板来处理这一问题(请注意这与标准+模板没有什么关系)。MFCCMultiDocTemplat%保存关于同文档相关联的子框架的信息，并且该模板被添加到管理该模板的应用程序对象中。wdwxDocTemplate额外需要一个管理模板的wxDocManager对象请记住wxDocManager是wxWindows应用程序的应用程序类的一个属性。完成文档/视图框架初始化之后，就创建了应用程序的主框架。MFC应用程序的InitInstance()、、+方法中，按如下创建一个主框架:完成文档/视图框架初始化之后，就创建了应用程序的主框架。MFC应用程序的创建主框架：MFCCMainFrame*pMainFrame=newCMainFrame;if(!pMainFrame->LoadFrame(IDR_MAINFRAME))returnFALSE;m_pMainWnd=pMainFrame;pMainFrame->ShowWindow(m_nCmdShow);pMainFrame->UpdateWindow();调用pMainFrame->LoadFrame(IDR_MAINFRAME)资源文件装入所有关于主框架的信息。在wxWindows中，可以从资源文件建立菜单、对话框以及控件，或者可以在代码中创建它们。我更喜欢在代码中创建它们，但如果您愿意将代码同资源分离，就应该看一^wxWindows资源系统(请参阅wxWindows文档中的主题概述)。创建主框架：wxWindowsm_mainFrame=newMainFrame(m_docManager,(wxFrame*)NULL,"DocViewDemo”,wxPoint(0,0),wxSize(500,400),wxDEFAULT_FRAME_STYLE);//Setupmenubar...m_mainFrame->SetMenuBar(menu_bar);m_mainFrame->Centre(wxBOTH);m_mainFrame->Show(TRUE);SetTopWindow(m_mainFrame);在查看应用程序初始化完成后发生了什么事情之前，让我向您演示每个框架的文档和视图类。文档文档保存应用程序处理的基于文件的数据。它负责从文件装入该数据，并在必要的时候将该数据保存回文件竹咸类的声明类似于这样:文档类声明：MFCclassCPortMeDoc:publicCDocument{protected:CPortMeDoc();DECLARE_DYNCREATE(CPortMeDoc)public:virtualBOOLOnNewDocument();virtualvoidSerialize(CArchive&ar);virtual~CPortMeDoc();DECLARE_MESSAGE_MAP()};请注意：该类有一个受保护Protected)的构造器。决不要直接创建该类的任何对象；相反，框架使用序列化来创建文档。因此，需要使用DECLARE_DYNCREATE()宏。wxWindows类的声明类似于这样：文档类声明：wxWindowsclassPortedDoc:publicwxDocument{public:virtualboolOnSaveDocument(constwxString&filename);virtualboolOnOpenDocument(constwxString&filename);virtualboolIsModified()const;virtualvoidModify(boolmod);private:DECLARE_DYNAMIC_CLASS(PortedDoc)};DECLARE_DYNAMIC_CLASS()宏是必需的，因为wxWindows就象MFC一样动态地创建该类的对象。回页首回页首视图CEditView派生视图类是一个好主意。该类已经在其客户机窗口内提供了基本的编辑功能和如果MFC应用程序处理文本文档，那么从CEd1eW文本控件。这里我遵循自己的建议MFC视图类的声明类似于这样:派生视图类是一个好主意。该类已经在其客户机窗口内提供了基本的编辑功能和视图类声明：MFCclassCPortMeView:publicCEditView{protected:CPortMeView();DECLARE_DYNCREATE(CPortMeView)public:CPortMeDoc*GetDocument();virtualvoidOnDraw(CDC*pDC);virtualBOOLPreCreateWindow(CREATESTRUCT&cs);virtual~CPortMeView();DECLARE_MESSAGE_MAP()};在wxWindows中，(还)没有专门的编辑视图。但是创建您自己的编辑视图却很容易。只需在视图框架内有一个由^xtCtrl派生的文本控件。视图类将控件和框架都当作类属性来处理。因此xWindows声明类似于这样：视图类声明:wxWindowsclassPortedView:publicwxView{public:MyTextCtrl*textsw;PortedView();boolOnCreate(wxDocument*doc,longflags);voidOnDraw(wxDC*dc);boolOnClose(booldeleteWindow=TRUE);private:wxMDIChildFrame*CreateChildFrame(wxDocument*doc,wxView*view);wxFrame*frame;DECLARE_DYNAMIC_CLASS(PortedView)};除了常见的用于窗口创建、窗口重画以及窗口关闭的事件处理程序之外，该类还有一个创建框架并填充其菜单栏的方法。虽然拥有公共(public)属性不是一个好主意，但是为简单起见，我在这里还是这么做。在您的应用程序中应该避免这么做(我将在以后的版本中除去它)。回页首主框架既然已经有了处理和显示数据的文档和视图类，并且也有了处理文档/视图框架的应用程序类，现在需要一个主框架类来同用户交互。同样，两种框架提供类似的功能，而实际实现有略微不同。FC主框架类将一个状态栏和一个工具栏作为属性保存，同时FC主框架类还提供一些方法来派生而来的，因为该应用程序有一个Q1界面。处理窗口创建，以及声明消息映射表。请注意：该类是gMDIFrameWnd主框架类：MFC派生而来的，因为该应用程序有一个Q1界面。classCMainFrame:publicCMDIFrameWnd{public:CMainFrame();virtual~CMainFrame();virtualBOOLPreCreateWindow(CREATESTRUCT&cs);protected:CStatusBarm_wndStatusBar;CToolBarm_wndToolBar;afx_msgintOnCreate(LPCREATESTRUCTlpCreateStruct);DECLARE_MESSAGE_MAP()private:DECLARE_DYNAMIC(CMainFrame)};wxWindows主框架类将菜单作为属性保存，还具有创建其工具栏的方法，以及声明一个事件表外加一个处理应用程序的ut对话框的方法。wxDocMDIParentFrameL』十+因为这个应用程序有一个MQ1界面，所以该类是从冰生而来。因为这个应用程序有一个MQ1界面，所以该类是从主框架类：wxWindowsclassMainFrame:publicwxDocMDIParentFrame{public:wxMenu*editMenu;MainFrame(wxDocManager*manager,wxFrame*frame,constwxString&title,constwxPoint&pos,constwxSize&size,longtype);voidOnAbout(wxCommandEvent&event);voidRecreateToolbar();private:DECLARE_CLASS(MainFrame);DECLARE_EVENT_TABLE();};全部工作原理移植完成了。我来回顾一下实现这一点所需做的事情MFC应用程序类（派生自CWinAPP）移植到派生自WXApP的应用程序类，包括初始化代码将MFC文档类（派生自CDocument）移植到派生自WxD0CUment的文档类将MFC视图类（派生自CVieW）移植到派生自wxView的文档类。除了这些同文档/视图有关的类之外，饰C主框架类（派生自CMDIFrameWnd）移植到派…wxDocMDIParentFrame,生自的类。在其目前的版本中，该应用程序已经能够做很多工作。可以处理多个文本文件。可以打开、编辑并保存这些文件，并且应用程序保持最近打开文件的历史记录。如果不得不从头编写这些功能，那么将需要更多行代码更多行代码意味着要测试和维护更多行。在两种框架中，都使用了专门的命令标识符来处理常用的同文档/视图有关的命令。常用的文件命令是新建、打开和保存。常用的编辑命令是剪切、复制和粘贴。其它经常使用的命令有打印命令（这个应用程序中还没有实现该命令）和帮助命令。下表列出了这两种框架结构的文档/视图体系结构所包含的命令标识符。表2.标准的命令标识符MFCwxWindowsID_FILE_OPENwxID_OPENID_FILE_CLOSEwxID_CLOSEID_FILE_NEWwxID_NEWID_FILE_SAVEwxID_SAVEID_FILE_SAVE_ASwxID_SAVEASID_EDIT_CUTwxID_CUTID_EDIT_COPYwxID_COPYID_EDIT_PASTEwxID_PASTEID_APP_EXITwxID_EXITID_EDIT_UNDOwxID_UNDOID_EDIT_REDOwxID_REDOID_HELP_INDEXwxID_HELPID_FILE_PRINTwxID_PRINTID_FILE_PRINT_SETUPwxID_PRINT_SETUPID_FILE_PRINT_PREVIEWwxID_PREVIEW回页首窗口管理器如果您对Linux开发真的很感兴趣，则可能已经做了一些研究，发^nux上有不同的窗口管理器。曾经是彻FC开发人员的您可能觉得这很奇怪。在进行Windows开发时，您无须操心不同的窗口管理器，因为只有一个窗口管理器。开始wxWindows开发时，您可能想知道您的应用程序是否将运行在两个主流的窗口管理器K桌面环境（KDesktopEnvironment（KDE》和GNOME—之上。我已经在MicrosoftWindowsNT4.0使用公共桌面环境CommonDesktopEnvironment（CDE））的SunSolaris2.6以及使用KDE的Linux2.2上使用了wxWindows工具箱，没有任何问题。由于wxWindows仅仅是一个建立在其它低级别GW工具箱上的高级别层次，所以可以选择如何构建inux应用程序。可以使用Motif版本（或者还要更好一些的，免费Lesstif）或者wxWindows的GTK+版本。GTK+是GNOME使用的基础窗口构件工具箱，但是它在＜DE下也运行得非常好。我建议您使用GTK+版本，因为它通常更新，有许多开发人员对它进行开发，而且有用户在使用它。因此，如果您希望获得更多帮助，则可以求助于邮件列表或新闻组，询问关于版本的问题。下面是前前后后的抓屏，可以让您对移植的应用程序有一个大致的认识。图3.原始的MFC应用程序图4.Windows上的wxWindows应用程序iF^nFtedEditiFileWindowHelp图5.Linux/KDE上的wxWindows应用程序+回页首真实的故事wxWindows工具箱不只是书呆子的另一个玩具。它成熟、稳定，并且人们在实际应用程序中用它来解决实际问题。wxWindows项目创始人JulianSmart目前致力于RedHat，他已经将eCos配置工具（eCosConfigurationTOo/）移植到了wxWindowsoeCos配置工具是一个配置eCos嵌入式操作系统的图形工具人们已将最初的MFC应用程序移植到了wxWindows，尤其是在Linux上（参阅参考资料）。SciTechSoftware的人员也已经使用wxWindows来全部重新开发用于SciTechDisplayDoctor产品的前端GUI。IBM已经获得了SciTechDisplayDoctor的一个专门版本的许可证，IBM现在将其作为IBM所有基于OS/2Warp的操作系统（包括WarpClient、WorkspaceOnDemand及WarpServerfore-business）的主要显示驱动程序来分发SciTechSoftware对wxWindows社区做出了积极的贡献，它提交了扩展包wxApplet、wxUniversal和wxMGL。使用wxMGL,wxWindows应用程序甚至可以运行在DOS和其它嵌入式操作系统之上，例如QNX、RT-Target、SMX等等。SciTechSoftware全力资助wxUniversal和wxMGL项目（参阅参考资料）。+回页首结束语本文演示了使用wxWindows工具箱将MFC文档/视图框架的Windows应用程序移植到Linux的基本原理。wxWindows工具箱同MFC框架有一些相似性，从而帮助MFC开发人员可以达到加速Linux开发。有了这些基础知识，您应该能够将最棒的应用程序移植到nux。但不要忘了：wxWindows不是只能用于Linux。也许该是考虑在其它UMX或者甚至Macintosh上来运行您的应用程序一个版本的时候了。参考资料您可以参阅本文在developerWorks全球站点上的英文原文从Markus的主页下载本文所演示的原始应用程序和移植的应用程序完整源代码有关wxWindows的概述，请阅读Markus的文章细述wxWindows（developerWorks，2001年2月）。wxWindows主页是wxWindows社区成员要去的主要场所。它提供关于wxWindows的信息及对它的支持，包括下载、邮件列表、样本应用程序以及与wxWindows有关的工具。CodingwithKParts讨论了K桌面环境（KDesktopEnvironment）图形组件的KParts体系结构（developerWorks,2002年2月）。有关更多关于K桌面环境的内容，请访问KDE主页有关更多关于GNOME的信息，请查看GNOME主页在RedHat站点上可以找到更多关于RedHateCos配置工具的内容。可以在SciTechSoftware站点上获取更多关于SciTechDisplayDoctor的信息。可以在OS/2Warp页面上找到更多关于OS/2设备驱动程序包（它使用SciTechDisplayDoctor）的信息。在developerWorksLinux专区里可以找到更多Linux文章关于作者MarkusNeifer最初使用LOGO教学语言来编程，后来他使用过多种BASIC语言。在研究地理信息学期间，他学了一些C，但很快又转向了C++和Java，因为这两种语言具有面向对象的本质。他曾在研发领域工作过，期间他出版过关于科技软件的面向对象开发的文章。目前，他是地理信息系统领域的软件工程师。可以通过howlingmad@和Markus联系。GTK+最初，GTK+是作为另一个著名的开放源码项目一一GNUImageManipulationProgram（GIMP）——的副产品而创建的。在开发早期的GIMP版本时，PeterMattis和SpencerKimball创建了GTK（它代表GIMPToolkit），作为Motif工具包的替代，后者在那个时候不是免费的。（当这个工具包获得了面向对象特性和可扩展性之后，才在名称后面加上了一个加号。）这差不多已经10年过去了。今天，在GTK+的最新版本一一2.8版上，仍然在进行许多活动，同时，GIMP无疑仍然是使用GTK+的最著名的程序之一，不过现在它已经不是惟一的使用GTK+的程序了。已经为GTK+编写了成百上千的应用程序，而且至少有两个主要的桌面环境（Xfce和GNOME）用GTK+为用户提供完整的工作环境。为什么使用GUI工具包？使用GTK+这样的库比起编写自己的GUI代码来有多个优势。例如，它可以显著节约开发时间，让开发人员把精力集中在项目真正重要和真正独特的地方，而不必重复公共的功能。对于用户来说，这意味着他们使用的应用程序之间具有更好的一致性：工具包能在哪使用，应用程序就能跟到哪里。就像使用LEGO一样，所有的人都使用同一兼容尺寸这一事实，意味着设计可以在使用库的人之间共享，不论他们在哪里使用它。在现实中，现代的GUI工具包做的工作不仅仅是避免重复。它们提供了许多高级功能，用户希望在他们的应用程序中拥有这些功能，但是用别的方法得不到这些功能，因为在这类工具包上所投入的时间和工作，要远远超过在单一应用程序上的花费。所以，如果在应用程序中使用GUI对您来说很重要，那么请使用工具包。除此之外别无他法。现在剩下的惟一问题就是，应当使用哪个工具包？GTK+的优势不论开发的需要是什么，GTK+可能就是您正在寻找的答案。GTK+提供了许多东西：它既现代，而且得到了积极的开发与维护，围绕它有一个充满活力的社区。它提供了广泛的选项，用于把工作扩展到尽可能多的人，其中包括一个针对国际化、本地化和可访问性的完善的框架。它简单易用，对开发人员和用户来说都是这样。它的设计良好、灵活而可扩展。它是自由软件，有一个自由的开放源码许可。它是可移植的，从用户和开发人员的角度都是这样。现代的且开发积极的工具包GTK+是采用软件开发中的最新技术开发的，只要发现缺陷（肯定有缺陷，因为没有任何软件是完美的），开发人员就会尽力在下一版本中修补缺陷。使用现代的软件意味着，您不会陷在过时的工作中，而跟不上时代的发展。持续的维护和开发也意味着您拥有影响工具包的未来发展方向的能力。另外，在出现新的发行版时，会引入基于用户反馈的新特性和新功能，而旧的问题则得到修补。国际化、本地化和可访问性在创建要让所有人使用的软件的时候，请记住三个关键字：国际化、本地化和可访问性（通常分别缩写为i18n、l10n和a11y）。国际化是将程序准备为被母语不是开发应用程序所采用的语言的人使用的过程，所以应用程序不依赖于对任何特定语言的任何假设。i18n远远不只是对程序使用的文本进行翻译。它还意味着要考虑所使用的不同脚本和字母表、不同的编写方向、显示许多语言所需要的特殊处理以及为用户提供输入文本的适当方法。不是每种语言都可以简单地把每个字母映射到键盘上的不同键，而且还必须实现更好的复杂性，例如确保在错误消息中使用正确的复数。本地化与i18n密切相关，因为为国际用户准备应用程序不仅仅是改变语言。程序还必须能够理解并尊重日期、货币显示、数字标注、文本排序所使用的不同习惯，以及许多可能不太注意的细节之处一一例如有些符号的使用，在世界的不同地方可能会被认为是不恰当的或无礼的。正像i18n，正确的l10n要求在代码中添加很多东西，而这些是事后很难轻松加入的。GTK+提供了针对i18n和l10n的恰当工具，会让代码（和二进制）可以在许多语言和地域上不加修改地运行。切换地域所需要的就是随操作系统（针对l10n）或者一个可独立于实际的程序进行处理和发布的翻译文件（针对i18n）一起发布的一组数据。带来的灵活性会得到开发人员、翻译者和用户的热爱。可访问性是让每个人都可以使用您的程序。有些用户的视力不佳，有些人可能不能用键盘或鼠标，而有些人可能只能移动他们的眼睛。要确保每个想使用您的应用程序的用户都能使用，需要做许多工作。幸运的是，GTK+提供了一个途径，可以通过一个完善的预先存在的a11y框架，立即得到这方面的支持，而您这边几乎什么工作也不需要做。使用这个框架（它是UNIX®系统上的事实标准），可以把应用程序带给各类用户。您也能享受a11y的许多优势一一例如执行自动GUI测试的能力。通过让特殊需求用户运行的可访问性软件可以使用您的应用程序，您也可以让测试软件可以访问它，例如，检查行为是否正确一一这在传统的GUI编程中会带来严重的问题。（还值得记住的是：现在，a11y不再被当作'、好"东西。许多法规一一例如有关美国政府用软件的规则一一实际上要求软件对特殊需求的用户有恰当的支持。）以上三点可能是使用工具包的充足理由一一特别是GTK+，它在这三个领域都有优秀的支持。这个支持绝不完美，但在同类软件中是最好的，而且把这些关键字整合进应用程序的重要性并没有提到应有高度。在今天的世界中，计算机无处不在，用户众多而且独特，所以不能认为一个遗漏一整群用户的应用程序是一个完整的产品。简单易用这一点应当很明显，但是它实际上含义丰富。工具包对用户应当容易，这样才有可能创建简单的、直觉的和乐于使用的界面，哪怕针对的是新手。创建人机交互的正确模型不是一项简单的任务，GTK+正是长时间工作的结果，而且是众多的甚至困难的决策的结果。GTK+对于开发人员也易于使用。它允许开发人员用简单的方式说出自己想要的东西，不会用所谓正规方式给开发人员带来负担，这些正规方式是计算机为了弥补它们固有的缺乏想像力的缺陷而施加给人类的负担。设计良好、灵活和可扩展编写GTK+的方式允许在不扭曲基本设计的情况下，让维护人员添加新功能、让用户利用新功能。工具包也是可扩展的，这意味着可以向其中添加自己的块，并用使用内置块一样的方式使用它们。例如，可以编写自己的控制元素，比如说用于显示应用程序处理的科学数据，并让它正确地遵照用户选择的显示风格，就像GTK+自身的控件那样。更进一步，GTK+是可定制的，这样就可以让它适应自己的需求。GTK+有一个系统，可以在所有应用程序之间复制设置，包括主题的选择。主题是一组一同发布的定制设置，会影响GTK+使用的基本控件看起来的效果，甚至某种程度上的行为方式。使用主题，可以（例如）模拟另一个操作系统的观感。带有自由开放源码许可的自由软件自由软件意味着每个人不仅可以自由地获得和使用这个工具包，还可以在满足某些条件的情况下修改并重新发布它。自由开放源码许可意味着这些条件不是严格限制的，可以得到的自由程度是显著的。最重要的是，GTK+采用了LesserGeneralPublicLicense（LGPL）许可，这是GNU许可家族中一个不太严格的许可。LGPL允许自由地获取、修改和发布它覆盖的任何软件，只要对修改也保持自由即可。LGPL还允许任何人使用该库提供的功能，而不要求用户公开应用程序代码。（这对于许多工业应用来说很重要，因为由于以前的协议或许可，这种场合下一般不希望公开代码或者公开代码是显然不现实的。）使用LGPL许可，您既可以是开放源码社区的好伙伴也可以是好公民。可移植最后（但并不是最不重要），GTK+是可移植的。这意味着用户可以在许多平台和系统上运行它。另一方面，开发人员可以把软件提供给众多用户，却只要编写一次程序，还可以使用许多不同的编程和开发平台、工具和编程语言。所有这些都可以理解为更多的潜在用户，您可以利用更好地满足需求的更广泛的技能和工具。所有这些优势组合在一起，让GTK+成为软件开发的坚实基础。有了它，就能够把注意力集中在解决实际问题上，而不必重新发明轮子，而且您也可以确信创建的应用程序会按照用户预期的方式运作、解决他们的问题，而不必创建新的应用程序。GTK+与MFC不完全对比台ChinaItLab-^absurd」2006-11-27电保存本文②推荐给好友为收藏本页欢迎进入Linux社区论坛，与200万技术人员互动交流>>进入MFC已经江河日下，日渐式微，而GTK+可谓欣欣向荣，如日中天。这里无意于落井下石，痛打落水狗，贬MFC而尊GTK+。自己即在使用MFC也在使用GTK+，不会偏袒其中之任何一方。这个对比完全出于个人对两者的理解，说它是不完全对比，一方面只是一时兴起想做个笔记而已，另外一方面我对两者的理解也是有限的。1.两者都是基于面向对象设计的。尽管MFC是用C++写的，而GTK+是用C写的，但思想都是面向对象的。GTK+使用glib的对象机制，由于用C写的，其实现相对有点繁琐。1.2.两者都是基于消息驱动的。这是GUI系统的共性，消息可以是硬件上报的，如鼠标事件、键盘事件和触摸屏等等，也可以是程序产生，如一个窗口给另外一个窗口发送了一个消息。但两者并不完全相同，GTK+通过select挂在多个文件描述符上，可以同时等待多个事件源，比如socket、子进程退出和内核事件等等，而MFC只能通过GetMessage挂到消息队列上。2.3.两者都不是线程安全的，即只有一个线程可以操作GUI资源。主要是出于性能的考虑，这个问题不大，因大多数应用程序都是单线程的。3.而且它们都提供一些机制，让其它线程可以在必要时操作GUI资源。在GTK+中可以通过idle函数来实现，在MFC中可以通过PostMessage来实现（附带说明一下：Win32原生的GUIAPI是线程安全的）。GTK+整合了一系列的基础函数库，功能强大，而MFC孤军做战，势单力薄。Glib是G