From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c72ce603711bd113 X-Google-Attributes: gid103376,public From: mike@foolie.eco.twg.com (Mike Bartman) Subject: Re: portable GUI , Ada backend, best design? Date: 1998/02/04 Message-ID: #1/1 X-Deja-AN: 322115259 Content-Transfer-Encoding: 7bit References: <69s0vf$aao@drn.zippo.com> <34C1C729.F9B@online.no> X-Orig-Message-ID: <34dbe416.2880749238@library.airnews.net> NNTP-Posting-Time: Wed Feb 4 16:07:28 1998 Mime-Version: 1.0 Reply-To: mike@foolie.eco.twg.com Content-Type: text/plain; charset=us-ascii Organization: Mjolnir Enterprises NNTP-Proxy-Relay: library.airnews.net Newsgroups: comp.lang.ada Date: 1998-02-04T00:00:00+00:00 List-Id: 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 --