pete@esosun.UUCP (Pete Ware) (03/25/89)
I'm having some trouble with with translation management.
Specifically, I'm trying to add a translation to all widgets in order
to provide a help function. Unfortunately, when I do so some widgets
loose. For example:
xman -xrm '*Translations:#override<Key>Alt_R: Help()'
and now the grip widgets fail to work (ignore the "X Toolkit Warning:
Actions not found: Help").
Is a "<Key>Alt_R" more specific then a "<Btn1Down>" action and the
translation is getting tacked on to the end of the translation table?
If so, does that make it impossible to bind an action to all widgets?
Details:
X.V11R3, fixes1-9, awm.
I'll file a bug report if discussion indicates this is a problem and
not just another stupid user.
--
esosun!pete@seismo.CSS.GOV (Pete Ware) (619) 458-2520
{seismo,ucsd,uunet}!esosun!petekit@ATHENA.MIT.EDU (Chris D. Peterson) (03/29/89)
> Unfortunately, when I do so some widgets loose (sic). For example:
xman -xrm '*Translations:#override<Key>Alt_R: Help()'
I am surprised that this works at all, the specification states that
there must be a "\n" after the directive (#override in this case).
That might help things work better.
Also, where is this action defined? The toolkit will look in each
widget's action list from subclass to superclass order, then look in
the application's action list. If it cannot then find the action it
will print a warning message.
One side effect that may cause you problems is that you have just told
all of your widgets to look for key press events, this means that it is
no longer possible for child windows to pass events up to their parents.
Some applications may depend upon this behavior. Just a word to the
wise.
Chris D. Peterson
MIT X Consortium /
Project Athena
Net: kit@athena.mit.edu
Phone: (617) 253 - 1326
USMail: MIT - Room E40-321
77 Massachusetts Ave.
Cambridge, MA 02139 pete@ESOSUN.CSS.GOV (Pete Ware) (03/29/89)
>Date: Tue, 28 Mar 89 15:31:43 EST >From: Chris D. Peterson <seismo!ATHENA.MIT.EDU!kit> >> Unfortunately, when I do so some widgets loose (sic). For example: ^^^^^ Sorry for the typo, it does make it rather difficult to read. >>xman -xrm '*Translations:#override<Key>Alt_R: Help()' >I am surprised that this works at all, the specification states that >there must be a "\n" after the directive (#override in this case). >That might help things work better. In section 10.3 when talking about the string-to-translation resource converter, it says: As an option, you can specify a number sign (#) as the first character of the table followed by ``replace'' (default), ``augment'', or ``override'' to indicate whether to replace, augment, or override any existing table. So it looks like it does not need a '\n' for the directive (the source confirms this). Even with the '\n' it still didn't work. >Also, where is this action defined? The toolkit will look in each >widget's action list from subclass to superclass order, then look in >the application's action list. If it cannot then find the action it >will print a warning message. "Help()" is not defined. It's an action in a program I'm writing. I just used "xman" as an example so others could repeat the problem. Try it and see if you can develop a hypothesis as to what is going wrong. >One side effect that may cause you problems is that you have just told >all of your widgets to look for key press events, this means that it is >no longer possible for child windows to pass events up to their parents. >Some applications may depend upon this behavior. Just a word to the >wise. > > Chris D. Peterson Yes, this is a problem and one I knew of. I think the toolkit and the protocol are inconsistent in that translation management talks about individual events, like "<Key>Alt_R" but selecting for an event causes like event's (any other keypress) not to go to the parent widget. It would be better (or at least more intuitive) if events worked their way up the widget hierarchy until some widget had an action for that event or the top of the hierarchy is reached. Note I'm talking about widgets and not windows. --pete esosun!pete@seismo.CSS.GOV (Pete Ware) (619) 458-2520 {seismo,ucsd,uunet}!esosun!pete
kit@ATHENA.MIT.EDU (Chris D. Peterson) (03/30/89)
> So it looks like it does not need a '\n' for the directive (the source > confirms this). Even with the '\n' it still didn't work. I would contend this, take a look at appendix B. > (the source confirms this). Sounds like an implementation bug. In any case this is not your problem. This is really strange, this allows the grips to work fine: xmh -xrm '*translations:#override<Key>Alt_R: Help()' but this causes them to fail. xmh -xrm '*Translations:#override<Key>Alt_R: Help()' Why should this matter? I haven't a clue, it looks to me like you have found a bug, but I am not sure where it is. I have glanced at the VPaned widget code (it creates the grips), and it looks just fine. In fact it should not be able to override the grip translations at all (they are set via an arglist at widget creation time). I am cunfused, and the translation stuff is so hairy that I really don't want to go hunting. I would suggest that you wait about a week to see if someone else comes up with an explanation, and then send it into xbugs. Chris