Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!ATHENA.MIT.EDU!kit
From: kit@ATHENA.MIT.EDU (Chris D. Peterson)
Newsgroups: comp.windows.x
Subject: Re: Dynamically Replacing Widget Translations
Message-ID: <8812282235.AA00618@DORA.MIT.EDU>
Date: 28 Dec 88 22:34:59 GMT
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 82


> I started to make a Toggle widget...

If you are only interesed in a toggle widget, see my recent posting of a
toggle widget implementation.

> Then I discovered I didn't know how to completely replace a translation
> table.  A CorePart TMRec is more than an XtTranslations, which is what
> the translation compiler returns.

> Question 1a: Am I attempting something against the spirit of X or the
>             Athena Toolkit?

No, Replacing translations is fine, but should be done as described below.

Note: Replacing a translation table inside and action routine is bad business,
      and it is not clear wether or not the intrinsics even support this, 
      we are currently looking into this question.

> Question 1b: If so, what is an approach in the approved spirit to provide
>             state-sensitive behavior?

The Athena widget set implements state information by storing the information
in the widget's instance structure, this is how the command widget knows wether
or not it is set, for instance.

> Poking around the R3 Xt/TMstate.c, it seems that the common code
> to XtOverrideTranslations and XtAugmentTranslations does what I
> want, namely...

> Question 2a: Is there more to it than that?

The only "Standardized" part of the X Toolkit is the Intrinsics document, the
implementation provided by the MIT X Consortium is only a sample implementation.
Things that are internal to that should remain there, and they are not
portable to other toolkit implementations.  Copying source code, and using 
internal functions is strongly discouraged.  If you need to do this then you are
either doing something wrong, or we did something wrong.

> Question 2b: If not, wouldn't this be a good candidate for encapsulation
>             as a new public function: _XtReplaceTranslations?

This functionality can be obtained two ways, the first is to use 
XtSetValues to set the new translations table for the widget.  The other
is do use the convience routines XtUninstallTranslations(), and
XtOverrideTranslations().

> Looking back into the R2 sources, which are what I am running now,
> XtUninstallTranslations doesn't exist, and _XtInstallTranslations is
> never used.
 
If you need this functionality use R3.

> Question 3a: Can Core be substituted safely for WindowObj?

Core is a sub-class of WindowObj, and should contain all its functionality.
WindowObj is and internal Intrinsics object, and should not be used in
widgets or applications.  A good rule of thumb here is:  "If is isn't in
the intrinsics manual it is not portable".

> Question 3b: Can the R3 code for XtUninstallTranslations be used in R2?

Doubtful.

> Question 3c: With those substitutions, will the R3 solution work in R2?

Your solutions will not even work with other Xt R3 compatible implementations.

> Question 3d: If not, is it all practical to attempt tm table replacement in
> R2?

Probabally not.

						Chris D. Peterson     
						MIT X Consortium /
						Project Athena 

Net:	kit@athena.mit.edu		
Phone: (617) 253 - 1326			
USMail: MIT - Room E40-321
	77 Massachusetts Ave.		
	Cambridge, MA 02139