On Mar 3, 2010, at 4:20 AM, H. Gluender wrote:

> We've done some rather massive inventory / POS applications, as well as front-ends to scientific data. The basic rule is that to create a "Mac-like" interface in a cross-platform application, you do need some conditional compiling. For example, the "OK Cancel" buttons on Windows and Linux need to be swapped on the Mac and usually changed, since "OK" in the Apple universe is replaced with the specific action, such as "Update" or "Import" instead of a generic "OK."
> 
> -- Thanks for this information!
> -- Evidently, the compiler front end doesn't yet do all platform specific adaptations.

It cannot and no compiler ever can do the platform adaptations. For example, how would the compiler know that in my science application the "OK" in a dialog should be "Map Neurons" on a Mac? The Apple UI guidelines are that the "action button" must be the verb, while that is seldom the case in Windows and even less rarely the case in Linux apps. 

The UI designs are quite different. Even the measurements are not the same from platform to platform, which is why the old VBA forms in Office never worked across two platforms. On Windows the "twips" were not actually equal to pixels. Very annoying. VB.net uses pixels, I think. Not sure if VBA changed. You'd get a great form designed on the Mac and it would be trimmed on Windows. And you could't code for this because MS redefined what a twip was at least three times. 

There are other issues, from basics like menus on the Mac always being "merged" to the main menu to the UI elements behaving differently. You simply cannot code for this without having separate source sections for separate platforms (or even Windows versions). The key is the develop ways to "reuse" common code. Most REALbasic (and C++/Qt) developers write code that lets them store the OS X and Windows settings easily. You still have to do a fair amount of work, or users of one platform will complain that your application looks foreign. 

> If you are willing to spend money (of course), you can buy any number of libraries that add OS X-specific features. You can, in theory, access any OS X API and some libraries already include Cocoa features.
> 
> -- Well, I was asking for _cross-platform_ coding.

You can't do cross-platform "Cocoa" programming. Cross-platform, by definition, means settling for the lowest-common-denominator of features on the platforms supported. For example, if you included "Drawers" or "Sheets" in an OS X application, they could be "foreign" to a Windows user. More importantly, there are no native parallels in the Windows UI. 

Using Cocoa in a REALbasic / Real Studio application has the same negatives that using Active X does -- you get added features, but sacrifice the very selling point that Real Software claims. You have to decide, do I want the whiz-bang coolness of Cocoa or do I want a program I can also sell to Windows users? I only care about the Mac. 

Java has the same issues on OS X. Some Mac users would never care, but purists sure notice UI violations. 

- CSW