[no subject]

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.

o+< Robert O'Dowd added:

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.


o+< More Info:

ootips, Model-View-Controller:
http://ootips.org/mvc-pattern.html

Li-Cheng (Andy) Tai, The GUI Toolkit-Framework Page:
http://www.geocities.com/SiliconValley/Vista/7184/guitool.html


+-------------------------------+           +------------------------+
|    Object Orientation Tips    |---------<>|      Yonat Sharon      |
|       http://ootips.org       |           |  mailto:yonat@xxxxxxx  |
+-------------------------------+           +------------------------+