swick@ATHENA.MIT.EDU (Ralph Swick) (05/08/90)
> (kit) > I > will argue that it is more trouble that it is worth. And a bit of trouble it will be, too. The most immediate problem will be deciding how to multiplex events/inputs/timers across several app contexts. Probably, you'll wind up polling using XtAppPending() and XtAppProcessEvent(). I could invent a reason or two why a single process might want more than one app context, but since Andy didn't give any details I wonder if he found a good reason - Andy? Also, at least one thing that sounds like maybe it should be independently specifiable across app contexts within a single process isn't. The case that readily jumps to mind is error and warning handlers.
rlh2@ukc.ac.uk (R.L.Hesketh) (05/08/90)
In article <9005071732.AA17014@lyre.MIT.EDU> swick@ATHENA.MIT.EDU (Ralph Swick) writes: >The most immediate problem >will be deciding how to multiplex events/inputs/timers across >several app contexts. Probably, you'll wind up polling using >XtAppPending() and XtAppProcessEvent(). Yup, I've tried this and its not nice. On a VAXstation I found that it was spending upto 90% of the CPU looping on XtAppPending(). I was using a Work Procedure which called a polling loop which would process up to 10 waiting events. I haven't tried using a timeout callback, would that be much better? I would like to use a separate application context because ... >I could invent a reason or two why a single process might want more >than one app context, but since Andy didn't give any details I wonder >if he found a good reason - Andy? ... My UI builder requires a separate application context so that when a user is editing a translation table in a prototype he only picks up the Action routines available to the prototype and not those used internally by the builder. Richard
swick@ATHENA.MIT.EDU (Ralph Swick) (05/08/90)
> I haven't tried using > a timeout callback, would that be much better? > > ... My UI builder requires a separate application context so that when a user > is editing a translation table in a prototype he only picks up the Action routines > available to the prototype and not those used internally by the builder. Timeouts might improve things, but if you're not yet using them yet you might be better served (:-) by performing your own select() calls on the several display connections. You'll need to do some linker tricks to wrap XtAppAddTimeOut and XtAppAddInput in case a widget uses them internally. Or, if you can arrange to have all timeouts and alternate input sources registered in 1 app context, simply register the display connections from the other app contexts as alternate input sources in the "master" app context. But, when editing a translation table can't you simply filter out the internal action routines explicitly?