Path: utzoo!attcan!uunet!bloom-beacon!ATHENA.MIT.EDU!swick
From: swick@ATHENA.MIT.EDU (Ralph R. Swick)
Newsgroups: comp.windows.x
Subject: Re: R3 Athena translations
Message-ID: <8910111611.AA02603@LYRE.MIT.EDU>
Date: 11 Oct 89 16:10:58 GMT
References: <349@kauai.ACA.MCC.COM>
Sender: daemon@bloom-beacon.MIT.EDU
Organization: DEC/MIT Project Athena
Lines: 62

> there are about a half a dozen ways to modify the event
> translations for a widget,

Not so many distinct ways; most are variations on common mechanisms.

> 2)  User's resource database -
...
> This happens (I assume) when the
>    toolkit is initialized at run time.

Nope, it happens when each new instance of the widget is created.
The difference isn't noticeable to applications that aren't
munging the resource database themselves, though.

> 3)  XtNtranslations arg at widget create time -
...
> This has the affect of replacing all designer
>    chosen defaults *and* any user resource values

Not exactly.  As for any other resource, this should logically be
equivalent to hardwiring a resource database entry into the
application.  The spec doesn't say so, but the input to
XtParseTranslationTable is a translation resource string; i.e. it
can contain the '#' operator at the beginning.  The returned
XtTranslations encode this operator.  The effect you describe
is due to the fact that the default operator is #replace.

4)  XtAugmentTranslations() and XtOverrideTranslations() -

Yep.  These two procedures ignore the operation that was encoded
by XtParseTranslationTable.

> If there are more ways to monkey with the translation tables

There are lots more ways to specify resource values.  Of particular
interest to application developers are the application class
'app-defaults' file.  This file allows an application developer
to replace the wired-in widget defaults with whatever the
application may need but still (if desired) permit the site or
user to modify the bindings if necessary.  If site or user
modification is to be supported, the application should document
the location of its default event bindings specification as there's
no built-in mechanism to allow a user to incrementally modify
bindings that were specified in a higher-level resource file,
as you note later.

> Lets suppose I have an application that uses text widgets.
> I don't like some of the widget designer's defaults and so I've created
> "defaultTranslations" that I want to override the widget's internal
> defaults but that can still be overridden by the user.

If your own defaults are to apply to every instance of the widget,
then you could consider simply writing them into the WidgetClass
data structure before creating the first text widget.  If your
machine architecure permits multiple applications to share
data space, this approach will cause some problems, but there
are alternate equivalent approaches.

> I have some other translations that I don't want to let the user override.

The only way to guarantee this is via XtOverrideTranslations()
after the widget has been created, as you note.