MULLEN_L@TREES.dnet.ge.com (LEO MULLEN) (06/06/91)
Here is the scenario: We are interested in developing a distributed HMI and we have 2 concerns: 1. Is there a way for a seperate process (process A) to call its on X window and then attach that called window to the main application that is already running? This is crtical for us so we can have the wm managing all the windows and so we know what windows are currently alive. 2. Are shared libraries hard to work with? Are they a lot of work? We are not sure we were wondering how some of you who have tried them feel? Thanks for all your help. Leo mullen_l@trees.dnet.ge.com
E_CMA@vaxa.nerc-murchison.ac.uk (06/07/91)
> 1. Is there a way for a seperate process (process A) to > call its on X window and then attach that called window to the > main application that is already running? This is crtical for us > so we can have the wm managing all the windows and so we know > what windows are currently alive. Yep. I have done that sort of thing in prototype and it works fine. There is a fairly comprehensive treatment on inter-client communications in Chapter 11 of Douglas A. Young's "The X Window System - Programming and Applications (with Xt)" and I dare say in other standard X tomes too. In essence seperate processes can communicate with each other via Atoms using Property Notify Events. Your "child" application defines an Atom with the same name and display i.d. as one defined by the main application and does a XChangeProperty on it. This is picked up by the main applications event loop where the PropertyChangeMask has been set using XSelectInput to allow the main application to "receive" Data can be retrieved from the Atom by any client for which it is defined using XGetWindowProperty. > 2. Are shared libraries hard to work with? Are they > a lot of work? We are not sure we were wondering how some of > you who have tried them feel? Not particularly, although one can come across problems e.g. with DECW$XLIBSHR.EXE and ORACRTL.EXE. On the plus side your .EXE files tend to be of a more manageable size. Cheers Carolyn ************************************************************************* * Snailmail: * E_Mail * * * CBS%UK.AC.NERC-MURCHISON.VAXA::E_CMA * * Dr C.M.Allen * JANET: e_cma@uk.ac.nmh.va * * British Geological Survey * * * Murchison House * * * West Mains Road ** * * * * * Edinburgh * Tel: 031-667-1000 x277 from U.K. * * Scotland * * * EH9,3LA * * *************************************************************************
carroll@cs.uiuc.edu (Alan M. Carroll) (06/08/91)
In article <9106061330.AA06740@ge-dab.GE.COM>, MULLEN_L@TREES.dnet.ge.com (LEO MULLEN) writes: > > Here is the scenario: > > We are interested in developing a distributed HMI and we have > 2 concerns: Heheheh, you could just wait till I finish my thesis in a couple months and have one for free :-) (assuming "HMI" means "Human-Machine Interface") > > 1. Is there a way for a seperate process (process A) to > call its on X window and then attach that called window to the > main application that is already running? There are several ways to do this. The main application creates a window, and send the window ID to A. A can then 1) use main window directly 2) create a window and reparent it to the main window 3) create a window that is a child of the main window. As an an example, we've built a Motif widget server (currently called "Biscuit") which provides frames with menus and buttons and things, and a DrawingArea for use by other clients. To provide text editing facilities, we use Epoch, which reparents an edit screen into the DrawingArea (method 3). In practice, a central server sends a message to Biscuit for the frame, and a message to Epoch for the text. Biscuit then sends a message to Epoch to tell it the window ID of the DrawingArea, and Epoch reparents an edit screen into the DrawingArea. -- Alan M. Carroll <-- Another casualty of applied metaphysics Epoch Development Team Urbana Il. "I hate shopping with the reality-impaired" - Susan
kern@asterix.cadlab.de (Thomas Kern) (06/10/91)
In article <9106071436.AA21149@ucbvax.Berkeley.EDU>, E_CMA@vaxa.nerc-murchison.ac.uk writes: [ stuff deleted ] |> In essence seperate processes can communicate with each other via |> Atoms using Property Notify Events. Your "child" application defines |> an Atom with the same name and display i.d. as one defined by the main |> application and does a XChangeProperty on it. This is picked up by |> the main applications event loop where the PropertyChangeMask has been |> set using XSelectInput to allow the main application to "receive" Not quite correct: Atoms are used to name Properties. You may call XChangeProperty and XSelectInput for a Property, not for an Atom. |> Data can be retrieved from the Atom by any client for which it is |> defined using XGetWindowProperty. Data can't be retrieved from an Atom. Atoms are nothing more than names (strings!) stored in the X-Server. You may read data from a Property named by an Atom. That's why those functions have the word 'property' in their names. |> Cheers |> Carolyn Thomas -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | Thomas Kern | Tel. : (+49) (+) 5251-284 111 | | CADLAB | Fax : (+49) (+) 5251-284 140 | | Bahnhofstr. 32 | E-Mail: kern@cadlab.uucp | | D-4790 Paderborn | kern@cadlab.cadlab.de | | Germany | ...!uunet!unido!cadlab!kern | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~