rusty@VIOLET.BERKELEY.EDU (07/24/88)
Suppose I have a program that continuously computes and generates graphic output; how can I wrap the toolkit around this program? It seems to me that once I call XtMainLoop() I've given up control and there's no way for me to get to the main routine of my program that generates the output.
bobtl@tekecs.TEK.COM (Bob Toole) (07/25/88)
In article <8807240059.AA13157@violet.berkeley.edu> rusty@VIOLET.BERKELEY.EDU writes: >Suppose I have a program that continuously computes and generates >graphic output; how can I wrap the toolkit around this program? It >seems to me that once I call XtMainLoop() I've given up control and >there's no way for me to get to the main routine of my program that >generates the output. There is nothing sacred about XtMainLoop. It simply gets an event and dispatches it. So just build your own main loop which checks to see if any input is present before attempting to do the get/dispatch sequence, and generates your graphics output. You probably could do other things like build a widget which requests periodic timeouts, but this seems simpler.
haynes@WSL.DEC.COM (07/25/88)
Suppose I have a program that continuously computes and generates graphic output; how can I wrap the toolkit around this program? It seems to me that once I call XtMainLoop() I've given up control and there's no way for me to get to the main routine of my program that generates the output. As usual with the toolkit there are at least four equally valid ways of solving your problem, depending on your exact requirements. They are: Work Procs Timer Events Custom XtMainLoop "Pull" instead of "Push" The Work Proc solution would be to divide your program into small pieces, each of which would be expected to finish in a small amount of time (say 100 millisecs) and register each piece as a work proc. If your graphics program can be decomposed into a 100 millisec task that is run over and over, this would be your best solution. Timer Events are a way of getting the toolkit to "wake up" every so often and call some procedure of yours. This solution is almost always inferior to work procs, but if you already have some work procs and want to guarantee that your program runs every n milliseconds, this is the route to take. A Custom XtMainLoop is another possibility. Write your own XtMainLoop with your graphics processing interspersed between the calls to XtNextEvent and XtDispatchEvent. Further, you can avoid blocking by use of XtPending. The last alternative "pull" instead of "push" is actually an elaboration of the custom XtMainLoop. Take your existing graphics program and sprinkle "XtNextEvent" followed by "XtDispatchEvent" in appropriate places. You can even look at the event delivered by XtNextEvent to decide exactly what it is you want to do. Good luck. -- Charles
klee@daisy.UUCP (Ken Lee) (07/26/88)
In article <8807240059.AA13157@violet.berkeley.edu> rusty@VIOLET.BERKELEY.EDU writes: >Suppose I have a program that continuously computes and generates >graphic output; how can I wrap the toolkit around this program? It >seems to me that once I call XtMainLoop() I've given up control and >there's no way for me to get to the main routine of my program that >generates the output. Here are 2 simple ideas. There are probably more complex ones for Xt hackers. 1. Explicit dispatching: have your graphics output module control the program, but, every once in a while, call XtDispatchEvent() to handle input. 2. 2 processes: put your output module in a process separate from your Xt widget/input handler. Communicate with sockets or pipes. Let UNIX scheduling worry about the who's running when. Ken -- uucp: {ames!atari, ucbvax!imagen, nsc, pyramid, uunet}!daisy!klee arpanet: atari!daisy!klee@ames.arc.nasa.gov Don't applaud, just throw money.
haynes@WSL.DEC.COM (07/26/88)
[Rusty sent me a message explaining that the program he was trying to adapt was basically a "black box" and it's behaviour couldn't be guaranteed, and certainly couldn't be modified. Here is my reply.] Well, as usual with the toolkit there is a fifth, very obscure and slightly dangerous way of doing what you want. I don't normally recommend it since it can get you into serious trouble, but Xlib lets you register a procedure to be called as X events come in, and before they are queued on Xlib's event queue. You can dispatch from this procedure, but because it is truly asynchronous, you are letting yourself in for all sorts of potential trouble. As long as you do ALL event dispatching from this routine, and make sure that you finish processing an event before you dispatch the next one, you should be safe. Realize that you will be operating in the far outer limits of expected Xlib and toolkit behaviour, and be conservative about what you want to accomplish, and you should be able to get away with it. I don't remember precisely, but one of the potential pitfalls is that you may be dispatching events into the toolkit while Xlib has the display structure locked. If true, this will make it difficult (impossible!) to do Xlib calls in your toolkit routines. -- Charles
vixie@palo-alto.DEC.COM (Paul Vixie) (07/26/88)
In <8807240059.AA13157@violet.berkeley.edu> rusty@VIOLET.BERKELEY.EDU writes: # Suppose I have a program that continuously computes and generates # graphic output; how can I wrap the toolkit around this program? It # seems to me that once I call XtMainLoop() I've given up control and # there's no way for me to get to the main routine of my program that # generates the output. You say you want to "continuously" compute and display graphics; if this is indeed the case, I assume that you want the toolkit to interrupt you in the form of button callbacks getting called if the user clicks something. You should do: while (XtPending()) { XEvent xevent; XtNextEvent(&xevent); XtDispatchEvent(&xevent); } This will give Xt a chance to do anything it could want to do, callback-wise. If you look at the source for XtMainLoop(), you'll see that there's no magic involved there, either. -- Paul Vixie Digital Equipment Corporation Work: vixie@dec.com Play: paul@vixie.UUCP Western Research Laboratory uunet!decwrl!vixie uunet!vixie!paul Palo Alto, California, USA +1 415 853 6600 +1 415 864 7013
bw@hpcvlx.HP.COM (Bill Wilhelmi) (07/26/88)
You might want to think in terms of wrapping your program around
the toolkit rather than the other way around.
If you are using the HP Widgets, you might consider
using a Workspace Widget. This widget provides a
"drawing board" for non-widget applications. It
provides callback routines for exposure events,
resize events, key down events, selection, and release.
One way to use this widget is to make it a child of
a Panel widget. A Panel manages a title area and a
menu area as well as a workspace area.
A set of HP Widgets is available from expo at MIT. The widgets
are to be updated around late August or early September.
Bill Wilhelmi
Hewlett-Packard Company
Corvallis Workstation Operation
Corvallis, Oregon
______________________________________________________________________________
bw@hpcvlx.hp.com
UUCP:{ihnp4|cbosgd|allegra|decvax|gatech|sun|tektronix}!hplabs!hp-pcd!hpcvlx!bw
USnail : 1000 N.E. Circle Blvd., Corvallis, Oregon, 97330, USA