Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!ATHENA.MIT.EDU!swick
From: swick@ATHENA.MIT.EDU (Ralph R Swick)
Newsgroups: comp.windows.x
Subject: Re: confusion about "application contexts"
Message-ID: <8902151637.AA21974@LYRE.MIT.EDU>
Date: 15 Feb 89 16:37:04 GMT
References: <8902150327.AA00175@meepmeep.UUCP>
Sender: daemon@bloom-beacon.MIT.EDU
Organization: DEC/MIT Project Athena
Lines: 32


     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.