[Subject Prev][Subject Next][Thread Prev][Thread Next][Subject Index][Thread Index]
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
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
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
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
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:
Li-Cheng (Andy) Tai, The GUI Toolkit-Framework Page:
| Object Orientation Tips |---------<>| Yonat Sharon |
| http://ootips.org | | mailto:yonat@xxxxxxx |