Xref: utzoo comp.windows.x:34889 comp.windows.x.motif:2440
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!samsung!mitech!gjc
From: gjc@mitech.com
Newsgroups: comp.windows.x,comp.windows.x.motif
Subject: Secondary Loop (within XtMainLoop) SOLUTIONS, (and old programs become
Message-ID: <9904@mitech.com>
Date: 4 Apr 91 09:27:06 GMT
References: <1991Apr2.080151.10992@neon.Stanford.EDU> <1991Apr3.092416.8894@siesoft.co.uk>
Organization: Mitech Corporation, Concord MA
Lines: 61

In article <1991Apr3.092416.8894@siesoft.co.uk>, paulb@siesoft.co.uk (Paul Bentley) writes:
> ... I'm in the unfortunate position of maintaining old code ported
> to Motif (far from ideal) which has blocking subsiduary event loops called
> from 70 places !
> 

In this kind of situation, if you want to be 100% sure of avoiding subsiduary
event loop bugs, probably your best and only way of handling this is to
have all MOTIF/X activity handled by a front-end process, and run your
actual application as a subprocess, talking to it via pipes.

One example I have: Using a modified version of the XTEK (tek 4010 emulator)
code that I mentioned here and posted to VMSNET.SOURCES a while back,
myself and other people have added some pulldown menu capability and a
simple dialog box for text input, to

* Turn an arbitrary old (say) FORTRAN program which prompted the user
  for interactive commands and output graphics in Tektronics codes
  into "=>" a spiffy new looking X-Window program with pulldown menu's
  and mouse-sensitive graphical items.

The main issue is keeping track of the state of the conventional interactive
subprocess. That is: WHEN it is ready to accept input, and when it is not.
In some operating systems you can determine this without any modification
of the program. In most you cannot, although simple conventions will work
most of the time, and finally, replacing all READ requests with a subroutine
that will send an escape code to the superiour process at the start and
end of each READ will do the trick.

(1) start with a toplevel shell widget that has a 
   (a) pulldown menu bar.
   (b) simple window for drawing tex graphics commands.
   (c) a text widget for shunting otherwise non-handled text output.
   (d) a command line widget
   (e) a dialog box for handling the most common single-line-question,
       single-line-response commands.
   (f) other dialog boxes for handling choice-like menus. and other
       things you think up as the interface evolves.

(2) Shunting TEK graphics commands to the graphics window is trivial.
(3) Shunting non-graphics commands to the non-graphics text area
    is also trivial, since most old programs have a convention for
    going from graphics-output to "interactive mode". Many were already
    modified (or developed) to work with TEK-Emulation of VT100 or VT240.
    And there are specific escape codes involved here.
(4) Adding pulldown menu items to send specific commands is trivial.
(5) Even mouse-sensitive items is easy. A mouse click can be encoded
    in a conventional way and sent as a command:
    (a) CMD>MOUSE_CLICK_AT x,y
    or some simple recognition of object name (you have to keep a display
    list of all lines, circles, and strings written to your X window anyway)
    can turn things into
    (b) CMD>SELECT_DETAIL_ON OBJECTXYX


-gjc

p.s. XTEK is available for anonymous FTP.

An archive site for VMSNET.SOURCES is CERRITOS.EDU.
The GJC archive site is BU.EDU, cd to users/gjc