Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!decwrl!asente
From: asente@decwrl.dec.com (Paul Asente)
Newsgroups: comp.windows.x
Subject: Re: Deficiency in the translation mechanism
Message-ID: <1051@bacchus.dec.com>
Date: 1 Feb 89 19:20:09 GMT
References: <6312@eagle.ukc.ac.uk> <8901261848.AA02930@DORA.MIT.EDU> <31@harrier.ukc.ac.uk>
Organization: DEC Western Software Lab
Lines: 42

In article <31@harrier.ukc.ac.uk> rlh2@ukc.ac.uk (Richard Hesketh) writes:
>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?

I'm always happy to comment on anything whatsoever!

It would definitely be useful to be able to change action bindings.  For
example, you might have a text editing widget with an action for "visit
new file".  In a particular application, you might want this to call your
own version of the action procedure to make use of additional context (the
current directory, for example).  Modifying the translation table to do
this only works assuming that the user hasn't changed the default binding
for this action (e.g. the default binding might be escape-f for find file,
but the user might have rebound it to control-x control-v).

What is really needed here is a way to rebind an action name to a
different or an additional action procedure.  While this would be useful
on a per-widget rather than a per-class basis, that is unlikely to happen
since it would involve changing the core widget records, something we are
reluctant to do any more.  However, it could certainly be done on a
per-class basis, and the new class action procedure could do different
things depending upon the widget it's being passed.

You really need several new functions:
    XtAddActionName(widgetClass, actionName, newActionName)
to add a new name to an action procedure so you can still get to it after
you do an
    XtReplaceActionBinding(widgetClass, actionName, newActionProcedure)
to replace an action procedure with a new one.  You also need
    XtCallActionProc(widget, actionName, event, params, numParams)
to call the original action procedure from within your new action
procedure, if appropriate.  This last function is generally useful,
anyway; application should be able to call action procedures by name.

Anybody on the intrisics list think these are important enough to make
into a formal proposal?

	-paul asente
	    asente@decwrl.dec.com	decwrl!asente