Cross-Platform Applications With Graphical User Interface

Related Sites

From a UI point of view, depending on what you want to achieve, you have two options.

If you want the UI to be specific to the OS (ie with all the wizzy features), then you need to write a UI layer specifically for each OS that you use.

If you don't really care about the wizzy features - but would just like to be able to input/export data - then you can use a platform generic UI library - of which their are many.

I use an architecture called Model-View-Controller which separates the business code from the UI code. What this means is that you can write your C or C++ code and test it on the different platforms, then basically compile it into a library and call it from your UI programs.

Keep the interface to your code library very simple - generally you just want simple methods such as GetxxxData(), PutxxxData(), PerformxxxProcess(). Typically in a generic UI, GetxxxData() is called when a screen is created or initialized, PutxxxData() is called when a save or Ok button is pressed and PerformxxxData() is called when an action button is pressed. xxx btw is the screen name or some other meaningful description.

The sad fact is that ensuring portability of a GUI is difficult; all multi-platform solutions have a significant set of trade-offs on at least one of the targeted systems. More important, IMHO, is structuring your software so that the intelligence (eg background processing) is as portable as possible AND has a well defined interface that allows it to be ported. There are a few strategies to consider, all involving ensuring independence of background intelligence from GUI code.

1) Background intelligence provided by standalone programs. Advantages are that the boundary between the main functions and the GUI is well defined, and it is easy to replace particular background modules. Disadvantages are that different systems do different things with command lines (eg expression expansion), have different limits (eg length of command line), the mechanism for running one program within another from C/C++ is not standardized between operating systems. There are gotchas with communication between processes (eg use of files affects performance, difficult to communicate with a program that is half-way through processing in a portable manner).

2) Background intelligence provided by a load library (eg windows DLL). Advantage is also related to boundary between GUI and support code, and ability to replace particular background modules. Disadvantage is that implementation of run time libraries is system and compiler dependent.

3) Link a class library directly into your GUI code. This is easier to implement than the previous approaches, but also has disadvantages such as big executable files, and the need for a complete rebuild to maintain the background code. The previous two approaches *force* you to have a well-defined interface (communication happens via function calls, typically) whereas this approach allows direct access to static data and to public data members of classes. That means this approach relies of programmer discipline to ensure clean separation between GUI and implementation.

In all of the above, the main idea is to keep as little intelligence in the GUI as possible (eg all substantial work is handed off to a set of functions that just happen to be implemented portably). The problem is that implementing that scheme introduces trade-offs.

Li-Cheng (Andy) Tai, The GUI Toolkit-Framework Page