duanev@kauai.ACA.MCC.COM (Duane Voth) (10/11/89)
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
--swick@ATHENA.MIT.EDU (Ralph R. Swick) (10/11/89)
> 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.
duanev@MCC.COM (Duane Voth) (10/11/89)
swick@ATHENA.MIT.EDU (Ralph R. Swick) writes: > (I write...) > > 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. How can I do this without modifying widget code? duane
kit@EXPO.LCS.MIT.EDU (Chris D. Peterson) (10/12/89)
>> Ralph Swick > Duane Voth > > 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. XtSetValues() will also not let the user override. > > 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. The way we have accomplished this in our applications is by using the application defaults file. You can specify a translation for the widget as a resource, and the user is then free to override this resource with his own translation. This is much more preferable to munging the widget class data for the widget, it is also more portable. Chris D. Peterson MIT X Consortium Net: kit@expo.lcs.mit.edu Phone: (617) 253 - 9608 Address: MIT - Room NE43-213