Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!bellcore!texbell!sequoia!execu!cs.utexas.edu!milano!pp!kauai!duanev
From: duanev@kauai.ACA.MCC.COM (Duane Voth)
Newsgroups: comp.windows.x
Subject: R3 Athena translations
Message-ID: <349@kauai.ACA.MCC.COM>
Date: 11 Oct 89 00:18:49 GMT
Organization: MCC, Austin, TX
Lines: 71


Since there are about a half a dozen ways to modify the event
translations for a widget, I though I'd post a summary and try
to figure out how they are all supposed to work together.
I'm guessing at some of this and I'm hoping that others will post
corrections.


1)  Internal widget default - the widget designer may choose to set up
    a default translation table that they expect will be the most common
    usage of event bindings for the widget.  This is done by setting
    the "tm_table" field in the widgets core class record to a string
    that can be passed to XtParseTranslationTable().  This default is
    thus linked into an application that uses this widget.

2)  User's resource database - the user running the application can
    set up the application's resources via the resource manager.
    (a whole different saga)  The user may prepend a translation
    resource string with "#replace", "#override", or "#augment" to
    replace the entire translation list, override only the new event
    translations listed in the string, or add event translations which
    don't yet exist, respectively.  This happens (I assume) when the
    toolkit is initialized at run time.

3)  XtNtranslations arg at widget create time - an XtTranslations pointer
    (usually created by XtParseTranslationTable()) can be set as an arg
    to XtCreate*Widget() to change the "tm_table" field in the new widgets
    core class record.  This has the affect of replacing all designer
    chosen defaults *and* any user resource values.  (or are they supposed
    to be combined somehow?)

4)  XtAugmentTranslations() and XtOverrideTranslations() - functions that,
    when passed a XtTranslations pointer, modify the translation table for
    the specified widget after the widget has been created.

5)  XtSetArgs() with XtNtranslations - same as (3) but used after the
    widget is created.


If there are more ways to monkey with the translation tables or if any
of the above is incorrect please correct me.  In any case, I have an
example application that I would also like comments on:

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.  In addition,
I have some other translations that I don't want to let the user override.

Now it seems to me that I am forced to do my own resource managment
calls and that the app*Text.translations resource that normally allows
the user to provide changes must now be done in the application
specifically with XtOverrideTranslations() after the widget is created.
This is because, in order to set up my own defaults I have to a) supply
translations via XtNtranslations at create time (3), b) with XtSetArgs()
just after create time, or c) XtOverrideTranslations().  Now, once the
defaults are set, I fetch the application resources (I assume there is a
way to fetch app*Text.translations so that the user doesn't have to learn
some new resource names) and do a XtOverrideTranslations() call to install
these changes.  (and even though #replace and #augment are sort of meaningless
in this case - will #augment be honored by XtOverrideTranslations()??)
Finally, I call XtOverrideTranslations() once again to install the
translations I want to always be in effect.

Is there a better way to do this?

-- 
--- duane voth             duanev@mcc.com
----           ALL systems are arbitrary!
--- effectiveness is the measure of Truth
--