Cross Platform Look and Feel
Here are some responses to frequently asked cross-platform questions.
What's the best way to do a cross-platform product that has the native XXX look and feel?
It depends on exactly what you mean by native look and feel. There are several GUI toolkits that produce the right pixels, so that in a screen shot it would look just like an XXX application, but which still don't produce an application that feels right. For example, on Mac, if you select a range of text and then press right-arrow, what happens? The insertion point should move to the right boundary of the previous selection. However, on Windows, it typically moves one character beyond that point. I find this inconsistency very frustrating in several of the cross-platform apps that I use regularly.
Also, applications may have the right pixels for all the individual controls, but the overall layout of their UI doesn't feel comfortable for an XXX user. The classic example is the relative ordering of OK and Cancel buttons in dialogs. Most toolkits now take care of this transparently, but there are other things, such as the extent to which toolbars are used, that can be uncomfortable for users. For example, Mac applications typically use toolbars very sparingly, and Windows apps use them extensively.
Will Mono produce native Mac look and feel? How about Java? Python?
The look and feel is determined mostly by the choice of UI toolkit, and the way the UI is laid out, and very little by the choice of programming language. Most toolkits can be used from most languages.
The three leading cross-platform toolkits, Qt, GTK and wxWidgets can all be used from .Net, Python and a variety of other languages. .Net (and Mono) also support Windows Forms, the UI toolkit provided in .Net, but from what I have seen so far it doesn't produce nice UIs on anything but Windows (surprise!).
Java programs typically use Swing, which does a fairly good job of producing a native Mac look and feel, especially since Apple has helped with the development of the Mac version of Swing, but many of the cross-platform annoyances I mentioned above still apply, unless the application designers have taken special care to produce a good Mac version.
What's the best way to produce a native look and feel using Python on the Mac?
PyObjC is a bridging technology between Python and Objective-C. This allows you to use Cocoa from Python. If you want the ultimate in native look and feel on the Mac, using Cocoa is probably the way to go, but of course this is completely non-portable. Cocoa can be used from other languages, too, including .Net ones (Cocoa#).
PyObjC makes use of InterfaceBuilder, which is the layout designer for Cocoa. Almost all toolkits offer an interactive GUI layout designer, which saves the layout definition in a data file (or sometimes in source code) for the application to pick up and use at run time.
Although Cocoa produces the best look and feel, it is also possible to get very close with the various cross-platform toolkits, if appropriate care is taken.
wxWidgets uses a different approach from the other toolkits, in that is a wrapper for the native widgets (aka controls) of whichever platform it is running on. This takes care of a lot of look and feel issues, but I have still seen a good number of wx programs that didn't feel right on the Mac, and I believe the same sort of thing would apply on other platforms. Programs tend to take on the feel of whichever platform they started on (or whichever platform the programmer is most familiar with).
Does there exist somewhere a "Guide for Windows-Experienced Programmers on the Common Cross Platform Issues for Mac & Linux"? Without a list of all of these sorts of things, it seems hopeless that a windows programmer could ever write a truly cross-platform app.
Although there are challenges, it's still possible to do a good job. However, it's important to avoid the extremes of pessimism or optimism.
For example, some people have an overly simplistic and dismissive idea of how simple it is to make cross-platform apps, and think that the toolkit solves everything for you. A good toolkit can do a lot, but not everything. It's still necessary to put in more than a bare minimum of effort into porting.
On the other hand, you can get reasonably good behaviour, eg in text selection, by letting the toolkit handle as much of the work as possible. For example, always try to use a text-edit widget/control instead of a home-grown solution, since the toolkit designers tend to know a lot more about all of the platforms than a typical application programmer does.
However, this isn't possible for everything, for example when implementing a full-blown text editor. In this case, you do need a source of information. Most GUI environments have published their own "Human Interface Guidelines" documents, which are meant to be the last word in how applications are meant to behave on those platforms. For example, Apple, GNOME, KDE and OLPC have all published guidelines. There is also a Wikipedia article on the subject, with a larger set of links.