marbru@auto-trol.UUCP (Martin Brunecky) (08/21/89)
How to use an explicit application_context along with XtAddConverter ???
I want to have an application with a connection to multiple displays,
using XtCreateApplicationContext, adding displayes to it etc...
However, I found a gotcha: - my resource convertors are UNKNOWN in this
application context.
What happens, is as follows:
My widgets (similarly to ALL widgets I'v seen sofar, including XUI/Xaw/Xmu),
use XtAddConverter (called from widget's ClassIntialize).
Looking at R3 Intrinsics code, XtAddConverter merely calls XtAppAddConverter
using DEFAULT APPLICATION CONTEXT !!! (the context created IF a had called
the old good XtInitialize).
I know of several workarounds, such as using NULL (default) application
context etc. But none of those sounds right. To me, there is a MAJOR
issue to be resolved by the (R5?) Intrinsics:
1) Only the Widget knows what converters it needs. Hence, it was absolutely
correct to call XtAddConverter in the widgets ClassInitialize.
2) Widget's Class Intialize has NO WAY to find out what application
contexts are out there. Hence, it can NOT use XtAppAddConverter.
3) Application Context may be created AFTER the widget has been intialized.
How do we add converters here ?
A simple soulution would be to make the resource converters table GLOBAL,
common to ALL application contexts. But this would go against the "shared
address space" concept of the Intrinsics == one application would be able to
overload a convertor for the other application(s).
More complex soulution may be to put the first instance of converter into
this "GLOBAL" table, any attmpts to override/overload it will go into
per-application-context table. The XtConvert woukld have to be modified
to look up the hierarchy of converter tables: per-application-context
first, global next. However, there is still an issue of widget adding and
overloading converter from ClassIntialize...
Even more complex soultion would be to implement ClassPerApplicationContext
intialization for each widget. Sounds really scary - each widget would than
have ApplicationContextClassPart....
Since we are trying to "finalize" our widget set, I would wellcome any
suggestions how to approach the scenario above. May be the R4 Intrinsics
do something about it ????
==============================================================================
Martin Brunecky, Auto-trol Technology Corporation
12500 North Washington Street, Denver, CO - 80241-2404 (303)252-2499
{...ncar!ico!auto-trol!marbru}
==============================================================================rws@EXPO.LCS.MIT.EDU (08/22/89)
I want to have an application with a connection to multiple displays,
using XtCreateApplicationContext, adding displayes to it etc...
However, I found a gotcha: - my resource convertors are UNKNOWN in this
application context.
Install official fix #9 (which has been around since March ...)gabe@hpcvlx.HP.COM (Gabe Begeddov) (08/23/89)
/ hpcvlx:comp.windows.x / marbru@auto-trol.UUCP (Martin Brunecky) / 9:46 am Aug 21, 1989 / How to use an explicit application_context along with XtAddConverter ??? Since we are trying to "finalize" our widget set, I would wellcome any suggestions how to approach the scenario above. May be the R4 Intrinsics do something about it ???? The problem you describe was addressed in the patches (patch 9 ?) for R3. The approach used was that any converters added/overriden to the "default" app_context are also added/override to all other existing and future app_contexts. The R4 intrinsics will most likely include some additional capabilities in the area of converters. Two of the areas being addressed are lack of per-display information in the converters (for errors and freeing of stale data) and lack of control over whether results are cached or not.