Reputation: 8885
There is a large existing code base for a complex app that is written in C++ using MFC and WinAPI which needs to be ported to Mac OS X. The ideal solution is to have as much code common between the different platforms, especially code such as business logic. The GUI might be different depending on how good tools are available for a cross platform GUI. There are some low level OS calls which will be different on different platforms. The major goal is not to end up with two separate versions of the software that need to be developed and maintained separately.
I have been looking at Qt but I would be curious to know what other alternatives are there, and how people have solved this problem in the past.
Upvotes: 6
Views: 889
Reputation: 4381
I would stick with the "native" GUI for either platform. This requires to separate your presentation layer into two sub-layers: (1) The actual implementation which uses the concrete Widget/Control types and (2) a presentation abstraction layer. That way you get native look on each platform while using the same presentation logic.
By the way, you can do this uniformly even in managed code, assuming that MonoMac really works as promised (haven't tried it, no will and need to follow the Mac-Mania). That way you could have a perfectly clean CLR-backed code for your abstract presentation with bindings to WPF on Windows and to proper CLR-AppKit wrappers on Mac.
Upvotes: 2
Reputation: 9764
We had to make a similar decision a couple of years ago and decided to go with Qt. The application was a Windows Forms/Managed C++ combination (we did not have the crossplatform requirement), we did an evaluation of some of the ui kits out there we also considered Java.
If you are familiar with MFC you might find WxWidgets more "comfortable" i would guess as it's object structure is closer to that. This is actually what made us not use it. The Qt design is very well thought out and was a better match for what we were doing. Java was discarded as an option as we did not really have a lot of knowledge in house.
Starting from scratch i would chose Qt again (even with some of things going on with Nokia) I still like the toolkit. Options that I might consider that we did not consider when we did our first evaluaten (due to availability and constraints of the project) Mono, Adobe Air, or a purely web based application.
Upvotes: 5
Reputation: 5733
•If you were to port an existing app written in MFC what would you use / how would you do it?
I would use wxWidgets. It has great documentation, supports multiple platforms and has been around a while. As far as the how portion of your question... I would replace all MFC/Win32 specific calls with wxWidget calls. That's oversimplifying things, but essentially that is what needs to happen to get true multi-platform capability.
•If you could start the project from scratch on both platforms, what would you use / how would you do it?
I would still use wxWidgets, solely because I'm familiar with it. Qt, is an awesome framework, very capable and has a larger user base (guessing).
I realize there are other frameworks out there, but Qt & wxWidgets seem to be the cross platform framework leaders. I don't think you can go wrong with either choice.
EDIT: This answer was influenced from my personal experience porting a large MFC app written with Visual C++ 6 to use wxWidgets for the purpose of running on Linux.
Upvotes: 3