Re: portable GUI , Ada backend, best design?

[mike@foolie.eco.twg.com (Mike Bartman)]

nma123@super.zippo.com wrote:
> I'd like to do this:
> 
>       +-----------+     +--------------------+
>       | GUI       |     | analysis           |
>       | for data  |<===>| and                |
>       | entry     |     | computational part |
>       +-----------+     +--------------------+
> 
> Where the software must be portable with no code changes when building the
> software on UNIX and Windows.
> 
> I looking at using  Ada (GNAT) for the analysis and computational part
> of the system, using Ada insures portability for the backend side.
> 
> The problem is what to use for the GUI part. the GUI part is for entering
> user input, the parameters for the analysis part, so it is not very advanced
> GUI, but it had to be portable.

Why not use X-windows as the GUI?  It exists on most Unix systems, and
for the Windows side of the port you can run an X server to make the
PC an X terminal.  Unless you've got a pretty crippled TCP/IP stack on
the Windows box it should be possible to open the X server socket on
the local machine from the Ada backend application...or from a
different machine...makes no difference to X.

Using Java you run into GUI portability problems as well as speed
problems.  X is more widely supported, and more standardized, and
gives you options you don't get with Java (like a relatively "dumb"
terminal approach using X terminals), as well as easier control over
the look than you might get with standalone GUI apps that run on your
data entry stations.

To make a bit more sense out of that last bit, consider what might
happen with the "thick client" type of approach...you write your GUI
as a smart front-end app, that communicates over some sort of link
with the analysis code.  The analysis code may run on machine type A,
while you've got data collection stations on types A, B and C.  You've
written variants of your GUI code for each of these, and everything's
working.  Now you get a change order.  You now have to modify three
seperate GUI apps on three different platforms...a lot of work and
probably not all with one programmer.  Use a "thin client" approach,
like X, and your GUI app is really running on type A (or whatever) all
the time, while getting support for interface function from
pre-existing X servers on types A, B, and C...which you never have to
alter.  A change requires a change to one X app on your central
machine(s), and you're in business.  There no need even to distribute
the code, since the next time it's used, the new code is run.  Put a
thick client on every workstation and upgrades for bug fixes or new
features start getting expensive.

    -- Mike "proprietary stuff can be deadly too" Bartman --