jkh@pcsbst.UUCP (Jordan K. Hubbard) (02/15/89)
Not only do I not understand what they're good for, but using routines that require them doesn't seem to work! The scenario: The toolkit is initialized with XtToolkitInitialize() A new applications context is created with XtCreateApplicationContext() Display is opened with XtOpenDisplay() The top level shell is created with XtAppCreateShell() Widgets are created under it and we walk into XtAppMainLoop(). Zilch. No window(s) are mapped, deaf and dumb. Ok, so we go back and decide to do it the R2 way with XtInitialize() and XtMainLoop(). Voila! Everything comes up! Hmmm.. What gives? Looking at the code for XtInitialize() sheds no light since it seems to do pretty much what I did by hand, with the absense of an applications context. What am I missing? Just what are applications contexts for? Should we all be using the XtApp... calls for any special reason? Will things like XtMainLoop() quietly go away, making this mandatory? Confused.. Jordan Hubbard PCS Computer Systems pyramid!pcsbst!jkh
swick@ATHENA.MIT.EDU (Ralph R Swick) (02/16/89)
Date: 15 Feb 89 03:27:01 MEZ (Wed)
From: pcsbst!jkh ( Jordan K. Hubbard )
Not only do I not understand what they're good for, but using routines
that require them doesn't seem to work!
They're mostly good as a start to allow Xt to be implemented as a shared
library. They also make it possible for a single process to portray itself
to the user as multiple semi-independent applications, if it so desires.
Very few applications will be interested in having more than one context.
Widgets are created under it and we walk into XtAppMainLoop().
Zilch. No window(s) are mapped, deaf and dumb.
Ok, so we go back and decide to do it the R2 way with XtInitialize()
and XtMainLoop(). Voila! Everything comes up! Hmmm.. What gives?
I can't tell from your description what might be going wrong. We do
have applications that use these routines successfully. There _is_
a known bug having to do with registering type converters in application
contexts. Depending on the widget library, this bug may or may not bite
you. It's definitely a problem with Xaw (i.e. for now, if you're using
Xaw, use XtInitialize). The symptoms are manifest as "no type converter
registered..." error messages, which I assume you would have mentioned
if you were seeing them. [We have a fix for this bugs in the works.]
Will things like XtMainLoop() quietly go away, making this mandatory?
I don't see any good reason to ever remove appendix C from the specification.
There's certainly no proposal to that effect on the table.jlf@earth.cray.COM (John Freeman) (02/17/89)
I have had the same questions about application contexts. I sent a posting to xpert last week and have seen no responses to it. However, since then, I have been able to get some things to work with application contexts, a sample 'Hello, World.' is enclosed using appcontext. > 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. ---------------------------------------------------------------------------- /* "Hello, World" on two displays - John L. Freeman, Cray Research Inc. */ #include <X11/Xlib.h> #include <X11/Intrinsic.h> #include <X11/StringDefs.h> #include <X11/Shell.h> #include <X11/Label.h> #include <stdio.h> #define STRING1 "Hello, World!" #define STRING2 "Goodbye, World!" Arg label1_args[] = {XtNlabel, (XtArgVal) STRING1 }; Arg label2_args[] = {XtNlabel, (XtArgVal) STRING2 }; Arg argies[5]; main(argc,argv) int argc; char **argv; { Widget top1, top2, label1, label2; Display *d1p, *d2p; XtAppContext app1; XtToolkitInitialize(); app1 = XtCreateApplicationContext(); /* Sun 3/60 named "thelake" using screens 0 and 1 */ d1p = XtOpenDisplay(app1, "thelake:0.0", NULL, "Xlabel", NULL, 0, &argc, argv); if (d1p == NULL) { printf("XtOpenDisplay failed\n"); return; } d2p = XtOpenDisplay(app1, "thelake:0.1", NULL, "Xlabel", NULL, 0, &argc, argv); if (d2p == NULL) { printf("XtOpenDisplay failed\n"); return; } top1 = XtAppCreateShell("XShell", "xshell", applicationShellWidgetClass, d1p, NULL, 0); top2 = XtAppCreateShell("XShell", "xshell", applicationShellWidgetClass, d2p, NULL, 0); label1 = XtCreateManagedWidget(argv[0], labelWidgetClass, top1, label1_args, XtNumber(label1_args)); label2 = XtCreateManagedWidget(argv[0], labelWidgetClass, top2, label2_args, XtNumber(label2_args)); XtRealizeWidget(top1); XtRealizeWidget(top2); XtAppMainLoop(app1); }
asente@decwrl.dec.com (Paul Asente) (02/17/89)
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