Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!asente
From: asente@decwrl.dec.com (Paul Asente)
Newsgroups: comp.windows.x
Subject: Re: confusion about "application contexts"
Message-ID: <1094@bacchus.dec.com>
Date: 17 Feb 89 01:50:07 GMT
References: <8902161733.AA15972@thelake.cray.com>
Organization: DEC Western Software Lab
Lines: 43

In article <8902161733.AA15972@thelake.cray.com> jlf@earth.cray.COM (John Freeman) writes:
>> Just what are applications contexts for?
>
>Well, although the data type XtAppContext is opaque,
>if you look at it, you'll find it does have a pointer
>to a list of displays, allowing the programmer to 
>bring up widgets/windows on multiple displays.  (See
>the example) It also has a resources pointer, 
>meaning each AppContext could have different resource 
>specifications.  Beyond that, they still mystify me.

Well, if you think of an application context as a list of displays, you
aren't too far off.  Why might you want more than one of them?

The idea is to allow multiple logical applications to coexist in one
address space.  Some things, like the resource cache and the widget class
records, can be shared among the logical applications (this is the only
good reason to try to do this at all, really).  Other things, like the
display(s) each application has open, the resource database, and the
alternate event sources (timeouts, input, work procedures) are specific to
each logical application.  The application context provides a place for
the toolkit to store the per-application data.

These logical applications can act pretty much independently of each
other.  The only time the program needs to know that there are multiple
logical applications is when it does event dispatching.  It obviously
can't go into XtAppMainLoop for one application context, since that would
never return and the other applications would starve.  You would need to
write your own customized event loop that looked in each application
context for an event and dispatched them appropriately.

This is hard to do at present since there are no intrinsics routines which
allow you to block pending input on any of a list of application contexts.
This is a deficiency.

If we ever get good shared library support including shared data, multiple
application contexts will be a big win.  Also, if you have a multithreaded
system, application contexts (even without the multiplexing event
handlers) will win for you there, too.  The intrinsics will have to be
changed to do locking on shared data structures in that case, though...

	-paul asente
	    asente@decwrl.dec.com	decwrl!asente