Resources
New forum topics
Recent comments
Poll
Do you depend on non-"native" Mac programs?
No, not at all.
13%
I have a few command-line programs.
8%
Yes, I need X11 on the Mac.
34%
Yes, I need Linux.
4%
Yes, I need Windows.
28%
Other (please comment below)
13%
Total votes: 53
Copyright © 2005-2007 MacResearch.org Privacy Policy
Comments
Background to poll
I've been approached by several companies recently who are thinking of bringing their applications to the Mac platform. The applications in question are major computational chemistry and chemoinformatics applications costing $000's. They were originally used in a UNIX enviroment (IRIX, Solaris, HP-UX etc.) and more recently support for LINUX has been added. Some parts of the applications have been ported to Windows but in the main they remain UNIX based. Prior to the move to Intel processors any thought of supporting MacOSX was out of the question but now it could be feasible.
The cost of porting to MacOSX will be significant and since much of their revenue comes from the Pharma industry, which is under severe financial pressure at the moment, they need to be really careful about where they put their development dollars.
One way to “test the water” would be to offer a fully supported version running under Parallels or VMWare. This would be fully tried, tested and optimised together with full support. If there were sufficient users it may then be possible to justify a Mac OS X port.
So the Poll question is which environment should they focus on? Parallels is well established but VMWare offers multi-processor and 64-bit support which may be critical for these sort of applications. The Linux versions are probably more fully featured but Windows might be more familiar?
Or is only MacOSX native acceptable even if this means the applications may never be ported?
So the Poll is there, please vote and if there are developers who want to add comments to the poll you would be more than welcome.
X11?
If the applicaiton remains mostly Unix, why not port to X11 for the Mac OS X 'half-way' version? It's much easier for an OS X user to run an X11 app with a bad (i.e. non-mac like) interface than to (buy) and install Windows or Linux + a VM. Take a look at the history of Matlab for OS X as an example of a Unix app that is now (mostly) OS X "native" (via a Java GUI). Even if they have to include Qt or some other X11 toolkit with the app, it still might be an easier port and an easier sell for Mac users than a Windows version.
X11
I am also using X11 for many applications that are popular in the Linux community. Probably X11 is more popular, at the moment, than virtualization environments. It's not ideal, but it depends on how much you are comfortable with X11. The fact that it already comes with the Mac is not secondary. I understand that the when the main application is so expensive, it doesn't mind to add the cost of Windows and the cost of Parallels (VMWare), but if there is a good free alternative...
Java and QT are, generally speaking, even better alternatives, but not in this case. Porting an existing program to a different library is more difficult than porting it to a different language.
X11 on Mac OS X is supported by Apple
I think that any UNIX software business with high price tag software would want to study the Mathworks MATLAB solution. As the previous poster noted, MATLAB has been very successful on the Mac and there is no third party dependency. In addition, MATLAB has become important to Apple and every effort is made to ensure that it is not broken by a system release. Emulation environments are great as stop gap measures when applied to existing software, but I just don't see a viable business model where your product relies on the proper function and feature set of a third party product. Managing machine and software version updates could be a nightmare. X11 isn't pretty, but it works, and with time and experience more of the user interface can be moved over to native Mac frameworks, while in the mean time Apple will continue to update and support their implementation of X11.
In terms of the poll, X11 is in no way a "native" Mac solution, and so there is no way to vote for this obvious choice.
Qt/Mac is fairly good
I think many Mac scientists would be happy with Qt/Mac solutions. Yes, there are some inconsistencies with straight Qt/UNIX ports to Qt/Mac (it takes a bit more work to get better Mac interfaces). But in general, if UNIX developers are using Qt, they can pretty easily generate a Qt/Mac app without much more than a recompile.
It's much better than a "half-way" solution.
Java
A Java front end can work on any system (linux/Unix/Mac/Windows). It might be quicker to write a Java front end that will use the Unix program in the background. Later, a better, native solution can be looked at. Native is better-but Java does ok
Supporting MacOSX
These are all useful comments and I hope the developers are taking notice.
I suspect that part of the problem is that programs of this type, and age, have evolved rather then been designed. Whilst if they were to start now they would have a clear separation of GUI and program logic it is possible that is not the case at present.
If they are to move to a separated model I suspect it requires significant rewriting effort, and whilst X11, Java, Qt etc. are all excellent options they would want to only support one in the future. Perhaps a future poll on cross-platform GUI would be of interest?
Different Programming Languages
You mentioned X11, Qt, and Java as goals to support only one interface in the future. But these are different programming models. They're also frequently used with different languages -- Qt is C++, but Java is ... well Java.
There are also great ways to bridge between different languages and GUI. For example, using Python or Ruby (or whatever) to help with the interface and leaving more of the computational work to C or Fortran or whatever.
As you say, this requires separation of GUI from program logic. Certainly once that happens, it's much easier to support multiple platforms and generally reduce development headaches.