Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cwjcc!hal!nic.MR.NET!csd4.milw.wisc.edu!bionet!ames!amdcad!sun!pitstop!sundc!seismo!uunet!mcvax!ukc!harrier.ukc.ac.uk!rlh2
From: rlh2@ukc.ac.uk (Richard Hesketh)
Newsgroups: comp.windows.x
Subject: Re: Deficiency in the translation mechanism
Message-ID: <31@harrier.ukc.ac.uk>
Date: 31 Jan 89 14:41:16 GMT
References: <6312@eagle.ukc.ac.uk> <8901261848.AA02930@DORA.MIT.EDU>
Reply-To: rlh2@ukc.ac.uk (Richard Hesketh)
Organization: Computing Lab, University of Kent at Canterbury, UK.
Lines: 46

In article <8901261848.AA02930@DORA.MIT.EDU> kit@ATHENA.MIT.EDU (Chris D. Peterson) writes:
>
>> You supply a translation table which binds
>
>> 	<Key>Return	to	Bell()
>
>> rather than
>
>>	<Key>Return:	newline()
>
>> This is not good enough to my thinking. It means that the application
>> writer has to second guess the bindings which the user may or may not
>> supply for all these actions.
>
>There is no need to replace the entire translation table, just use 
>XtOverrideTranslations() in your application to override only the
>translation for Return.
>

I think the point Peter was trying to make is that although it is very easy
to override the event-to-action bindings by replacing the action called
when a particular event sequence is caught.  It is impossible to replace the
action side of the translations.  For example he wants to catch all calls
to the "newline()" action and therefore wishes to replace the "newline()"
action defined in the textWidgetClass with a "newline()" action defined
by the application.

The fact that the user can modify the translations from a defaults file
so that s/he could specify that the "newline()" action is called by,
say the <Meta><Shift><Key>[ sequence cannot be guessed by the application.
Just because a widgetclass defines actions does not mean that an application
wants them to be used.  The application may not want a particular action
to be ever called in a particular widget instance.  However the action
can still be called by the user specifying an event-to-action binding in a
defaults file and therefore upsets the designed interface!

Would any of the toolkit designers care to comment on the usefulness of
having a facility to override the action tables defined in widget classes
for particular widget instances?  Would the inclusion of an action resource
in the core part of the instance record be applicable or are we missing
something important which precludes this facility?

Richard Hesketh   :   rlh2@ukc.ac.uk    ..!mcvax!ukc!rlh2
---                                               
Computing Lab., University of Kent at Canterbury,
Canterbury, Kent, CT2 7NF, England.