pete@iris49.biosym.COM (Pete Ware) (03/28/91)
For whatever perverse reason I like using the translation management facilities in my widget's -- probably because they're a good idea. Unfortunately, I'm on a machine that has a dial box (eight dials that control 8 different axis of rotation in 3d) implemented using the X Input Extensions. There does not seem to be anyway to add event types to the Intrinsics translation management. I'm planning on using XtAddEventHandler() to actually solve the problem -- but I'd much rather let the user specify the appropriate translations/action bindings. Did I miss something in manual? --pete Pete Ware / Biosym / San Diego CA / (619) 546-5532 uucp: scripps.edu!bioc1!pete Internet: bioc1!pete@scripps.edu
rthomson@mesa.dsd.es.com (Rich Thomson) (03/28/91)
In article <9103272355.AA07190@iris49.biosym.com> pete@iris49.biosym.COM (Pete Ware) writes: >For whatever perverse reason I like using the translation management >facilities in my widget's -- probably because they're a good idea. >Unfortunately, I'm on a machine that has a dial box (eight dials that >control 8 different axis of rotation in 3d) implemented using the X >Input Extensions. There does not seem to be anyway to add event types to >the Intrinsics translation management. The conversion from the string specification to the internal opaque translation table mechanism happens just like any other resource conversion. In theory, one could replace the internal resource converter provided in the Intrinsics for String->TranslationTable, but it gets messy. You see, the translation table is an opaque type internal to the Intrinsics and hence not visible to an application. You could examine the internals of the Intrinsics and roll your own converter, but then you hit the wall of deciding what the event specifications should look like for extension devices. These are non-trivial issues, but ones that can be redressed by the X consortium. A while back, there was a request for comments on proposed changes to Xlib and Xt for R5. I pointed out this shortcoming of the Intrinsics handling of translation tables. It turns out to be more generic than just the input extension. Any extension can generate events, and an Xt based application might like to be able to specify selecting these events in the translation table (which is after all, a generic way of mapping an event sequence to an application action, decoupling the semantics of the application from the event stream so as to provide customization by the user or site administrator). For instance, the E&S X server implements 3D picking under PEX via a custom picking extension that returns events indicating the 3D structures that were picked. It would be nice to be able to say: PickEvent: DeletePickedObject() in the translation table. (I understand DEC has based their picking approach on the same code.) I suggested that the consortium consider some kind of mechanism of mapping extension events into specifications for the translation table. Note that since the event types are determined by the linking order of the extensions into the server, you need some way to specify the mapping of event type numbers to translation table specifications at run-time. The same event name could have different event type identifiers on different servers. (Querying the extension gives you the base event number and other information.) In the short run you can do either of the following: 1) Select for the input extension events manually in the appropriate windows and write your own XtAppMainLoop that looks roughly like: do { XtNextEvent(&event); if (event->type < LASTEvent) /* non-extension event */ XtDispatchEvent(event); else { /* special extension event handling */ } } while (!QuitFlag); [This example is taken directly from a program that uses the X Input Extension for a dial box as you describe to modify 3D PEX structures] 2) Use XtAddEventHandler with a 0 event mask. By examining the source code for the EditRes handling in the Athena widget set, I see that they do the following: In the VendorShell widget's initialization procedure: XtAddEventHandler(new, (EventMask) 0, TRUE, _EditResCheckMessages, NULL); Inside _EditResCheckMessages, they just examine the type field of the event and do the proper thing if it is an EditRes message and nothing otherwise: if (event->type == ClientMessage) { /* handle editres message */ } /* else do nothing */ Either of those routes should work, although I have only used the first one in my PEX programs that dealt with the X input extension. I have thought about modifying the Intrinsic's internal string to translation table converter, but I believe that the internals of the toolkit are changing enough for R5 that I'm going to wait until after R5 comes out. And who knows, the consortium may have already provided some hooks for it by then. ;-) -- Rich -- ``Read my MIPS -- no new VAXes!!'' -- George Bush after sniffing freon Disclaimer: I speak for myself, except as noted. UUCP: ...!uunet!dsd.es.com!rthomson Rich Thomson ARPA: rthomson@dsd.es.com PEXt Programmer