Gra*_*erg 3 wpf cocoa cross-platform
我正在寻找一些可以向我的老板和开发人员提出的论点.
我们目前正在完成初步的UI模型,并准备进入下一个开发阶段.与此同时,我一直在挖掘Carbon,Win32和wxWidgets API的深度,尝试使一些控件在Mac和Windows平台上具有更原生的外观.
我越深入到Win32和碳的API来实现我们希望在我们的项目的UI的东西,越陈旧,他们的感觉,而我开始更多地认为,在最后一段描述我们应该实施该项目在这里.
我们正在为当前的项目使用wxWidgets.wxWidgets正在wxCocoa端口上出现,但在我们开始对我们的新应用程序进行重大开发之前,看起来它还没有准备好进入黄金时段.在Windows方面,它包装Win32 API而不是WinForms或WPF(可能是由于本机代码与托管代码).
我们已经在设计系统时考虑了MVC模式,因此除了必须编写两个本机UI之外,它应该是非常可行的,并且,恕我直言,使用现代API(如Cocoa和WPF)更容易获得所需的UI效果.
我一直试图巧妙地推动这些观点,但重大发展的开始即将到来.有没有人对如何在我们的下一个应用程序中使用本机UI工具包与坚持使用wxWidgets有任何建议？
提前致谢.
使用标准C++创建核心代码,并使用Objective-C++和Cocoa在Mac和C++/CLI以及使用WPF的C#上创建用户体验,以在Windows上创建用户体验.请遵循Mac版本中适用于Mac的平台准则,适用于Windows版本中的Windows,甚至不必考虑尝试共享用户界面代码.
管理这个的一个好方法是遵循模型 - 模型控制器 - 视图控制器 - 视图架构,而不仅仅是模型 - 视图 - 控制器.您的模型控制器与平台无关,可以管理应用程序的更高级功能.(例如,它的整个文档概念,文件格式,作业队列等.)您的视图控制器依赖于平台,并在模型控制器和用户体验之间进行调解.
当然,你可能也想在模型级别使用一些与平台相关的代码; 例如,在Mac上使用NSOperation,在Windows上使用线程池来实现作业队列.为这类事情创建自己的轻量级抽象.
| 归档时间： |
|
| 查看次数： |
2346 次 |
| 最近记录： |