支持Mac和Windows桌面的建议 [英] Advice for supporting both Mac and Windows Desktops

问题描述

构建同时支持Windows和OS X的GUI桌面应用程序的最佳实践是什么?假设它是预算软件，因此有一些数学运算和一些大数据结构.用户数据保存在XML文件中；没有单独的数据库或网络.

What are the best practices for building a GUI desktop app that will support both Windows and OS X? Let's say it's budgeting software, so there is a bit of math and some big data structures. User data is saved in XML files; there is no separate database or networking.

在一个极端情况下，您可以只在C#中构建Windows版本，而在Objective C中构建Mac版本.是否有更好的方法，因此您可以更轻松地使两个版本保持同步并减少重复代码?您是否会用C ++编写数学和数据结构以及业务逻辑"，使用针对诸如IO之类的简单系统调用的预处理器指令，然后为Windows编写一次单独的GUI层，为OS X编写一次单独的GUI层?假设您想要本机代码，C/C ++是跨平台后端的唯一选择吗?有没有办法一次性编写GUI部分? (我希望不会.)

At one extreme, you could just build the Windows version in C# and the Mac version in Objective C. Is there a better approach, so you can more easily keep the two versions in sync and write less duplicate code? Would you write the math and data structures and "business logic" in C++, with pre-processor directives for simple system calls like IO, and then a separate GUI layer written once for Windows and once for OS X? Is C/C++ the only choice for the cross-platform back end, assuming you want native code? Is there any way to write even the GUI part a single time? (I expect not.)

请注意，我并不是在问如何使用交叉编译器.我对您如何以最小的麻烦来构造整个项目很感兴趣.

Please note that I'm not asking how to use a cross-compiler. I'm interested in how you'd structure your overall project for the least hassle.

推荐答案

考虑到我对平台本机用户界面和控件/小部件的强烈看法，我很有可能与大多数人持不同意见.倾向于选择第二种方法.甚至我还没有足够的自虐能力来解决分别构建整个应用程序的麻烦.

It's very likely that I have a different view from most on this issue, given my strong feelings about platform native user interfaces and controls/widgets, but I very much tend to prefer your second approach. Even I'm not masochistic enough to go through the hassle of building the entire application separately.

因此，我将确定编写完全独立于GUI层的库或数据层代码.用C ++进行处理是一个显而易见的选择，尤其是如果您已经熟悉该语言，那么以后会再介绍.关键是该代码应仅限于您的业务逻辑"，因此应完全独立于平台.如果您遵循扎实的面向对象原则，则应该确定在此级别上完成了 bulk 编程工作.

So I would definitely write the library or data layer code entirely separate from the GUI layer. Doing it in C++ is an obvious choice, especially if you're already comfortable with that language, but more on that later. The point is that this code should be limited only to your "business logic", and thus completely platform independent. If you follow solid object-oriented principles, it should work out that the bulk of the programming work is done on this level.

与此不同，您将在Windows和OS X的核心OS和UI函数上编写一个瘦的包装器"库.包装器库将是唯一负责直接与平台和数据进行交互的实体.层代码应从该包装器库中调用函数，而不是直接从平台的API中调用.

Separately from that, you would write a thin, "wrapper" library over the core OS and UI functions for both Windows and OS X. The wrapper library would be the sole entity responsible for directly interacting with the platform, and your data layer code should call functions from this wrapper library, rather than directly from the platform's API.

当然，你们中的一些人可能在尖叫:"但这就是QT已经为您服务的！！ "是的，我知道.但是它不使用本机窗口小部件，并且在很多地方都不符合标准平台约定.这意味着它很烂.我见过其他 do 适用于Windows的包装器库，但是我还没有看到OS X上看起来不错的一个包装器库.是的，我很挑剔，但您的典型Mac用户也很挑剔.他们只是不会忍受Windows用户会在屏幕上看到的垃圾类型，甚至Mac Office团队也知道这一点. (我们共同为您为实现这一目标而称赞.)

Of course, several of you reading this are probably screaming "But that's what QT already does for you!" Yeah, I know. But it doesn't use native widgets, and it doesn't conform to standard platform conventions in so many places. That means it sucks. I've seen other wrapper libraries for Windows that do get this right, but I've yet to see one on OS X that looked halfway decent. Yes, I'm picky, but so is your typical Mac user. They just won't put up with the type of garbage on their screen that Windows users will, and even the Mac Office team knows this. (We all collectively applaud you for trying to get this right.)

就您所选择的语言而言，您表示您正在这两种平台上寻找 native 代码.果冻很难固定在墙上.例如，您是否认为符合JIT的代码是本地代码?如果不是，那就排除C#.排除任何类型的解释性代码都会排除许多其他潜在语言.除了C ++和Objective-C之外，您没有很多 other 选项.但是C ++/Win32编程并不比Cocoa编程困难得多，只是有所不同.

As far as your choice of languages, you say that you are looking for native code on both platforms. That's a pretty difficult blob of jelly to pin to the wall. For example, do you consider JIT-complied code to be native? If not, that rules out C#. Excluding any type of interpreted code rules out a host of other potential languages. You aren't left with many options other than C++ and Objective-C. But C++/Win32 programming isn't that much more difficult than Cocoa programming, just different.

这篇关于支持Mac和Windows桌面的建议的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！