argv@Eng.Sun.COM (Dan Heller) (09/20/90)
On Sep 19, 4:45pm, Mitch Kuninsky (x2677) wrote: > Dan Heller writes: > > Let the application specify and provide whatever alternatives > > it thinks is reasonable and act as the mediator between the > > user and the toolkit. > Yes, and one way to do this is through the resources in > the application's app-defaults file. ... > All I wanted to do was augment the translation table of all my widgets > with the following: > <Key>Help: Help() I know this is a problem. I have been pulling my hair out about it myself! I don't disagree that there are definitely problems with the Motif toolkit in this regard. However, please don't misunderstand my point, which was a general one -- there is nothing "wrong" with making specifications for an arbitrary UI toolkit and making restrictions in the toolkit to provide for those specs. In this case (and many others, I might add), the Motif toolkit makes some errors that are quite distressing. --dan
nazgul@alphalpha.com (Kee Hinckley) (09/20/90)
> *translations: #augment\n\ > <Key>Help: Help() > > This is the only way that I can find to make the Help key call a widget's > help callback. Even if I had specified the translation argument for Really? All I did was add a helpCallback and it all just worked. 1.0 and 1.1.
argv@Eng.Sun.COM (Dan Heller) (09/21/90)
On Sep 19, 11:51pm, Kee Hinckley wrote: > > *translations: #augment\n\ > > <Key>Help: Help() > > > > This is the only way that I can find to make the Help key call a widget's > > help callback. Even if I had specified the translation argument for > > Really? All I did was add a helpCallback and it all just worked. 1.0 and 1.1. I tried that on my sun3/60 and it doesn't work. Motif seems to think my Help key doesn't exist. Could be my server, I guess. --dan
sjs@osf.org (09/21/90)
Dan Heller writes: > > On Sep 19, 11:51pm, Kee Hinckley wrote: > > > *translations: #augment\n\ > > > <Key>Help: Help() > > > > > > This is the only way that I can find to make the Help key call a widget's > > > help callback. Even if I had specified the translation argument for > > > > Really? All I did was add a helpCallback and it all just worked. 1.0 and 1.1. > > I tried that on my sun3/60 and it doesn't work. Motif seems to think my > Help key doesn't exist. > Could be my server, I guess. > > --dan > This is definitely a possibility. It has to do with the way the virtual bindings are set up. The first thing you need to check is if your server's vendor string matches the one that Motif has defined for key bindings. In case you don't know, this can be done using the command 'xdpyinfo' For example in 1.1: /*"X11/NeWS - Sun Microsystems Inc." * OpenWindows 1.0.1 Server for a Sun-4 * with a type 4 keyboard */ sunFallbackBindingString [ Stuff deleted ] osfHelp : <Key>Help \n\ The vendor string is "X11/NeWS - Sun Microsystems Inc." In this case, the Help key would work normally. However, if your vendor string doesn't match, you get the default bindings. (Help is the F1 key) In Motif 1.0, there weren't as many defines for various vendors, so if you're not on an HP or DEC machine, you are likely to have default bindings. (There is a good possibility that you would have defaults anyway). In addition, if you use mwm, you can set up key bindings in your .motifbind file. This would allow you to specify osfHelp to really be the Help key. Thie can also be done by setting defaultVirtualBindings in your .Xdefaults file. Lastly, your server has to actually know what the heck the key code is for the key you define. (ie. a Help key has to actually exist.) Simple huh? ;-) Hope this helps....
argv@Eng.Sun.COM (Dan Heller) (09/21/90)
On Sep 20, 4:03pm, sjs@osf.org wrote: > > ... on my sun3/60 and it doesn't work. Motif seems to think my > > Help key doesn't exist. > It has to do with the way the virtual > bindings are set up. The first thing you need to check is if your server's > vendor string matches the one that Motif has defined for key bindings. This is a vanilla MIT server -- not X11/news. > In this case, the Help key would work normally. However, if your vendor > string doesn't match, you get the default bindings. (Help is the F1 key) Ah -- I use F1 to raise the window under the mouse to the top. I knew that F1 was help, but I thought it would also recognize the Help key. > Hope this helps.... enormously -- thanx. -- dan ---------------------------------------------------- O'Reilly && Associates argv@sun.com / argv@ora.com Opinions expressed reflect those of the author only.
peebles@MIPS.COM (Andrew Peebles) (09/21/90)
>On Sep 19, 11:51pm, Kee Hinckley wrote: >> > *translations: #augment\n\ >> > <Key>Help: Help() >> > >> > This is the only way that I can find to make the Help key call a widget's >> > help callback. Even if I had specified the translation argument for >> >> Really? All I did was add a helpCallback and it all just worked. 1.0 and 1 ***.1. > >I tried that on my sun3/60 and it doesn't work. Motif seems to think my >Help key doesn't exist. >Could be my server, I guess. > >--dan Funny. I've been trying to get this to work all day, no go. I browsed through the 1.0 code, and there looks like there is little support for it. The 1.1 code looks like it works, but only when XmNtraversal = True. Here's the results of a " grep helpCallback *.c " in the 1.0 sources: FileSB.c: XtCallCallbacks (fs, XmNhelpCallback, &temp); Gadget.c: XmNhelpCallback, XmCCallback, XmRCallback, sizeof(XtCallbackList), Gadget.c: XtRemoveAllCallbacks (gw, XmNhelpCallback); List.c: XtCallCallbacks(lw,XmNhelpCallback,&cb); MainW.c: XtCallCallbacks(mw,XmNhelpCallback,&cb); Manager.c: XmNhelpCallback, XmCCallback, XmRCallback, sizeof(XtCallbackList) , Manager.c: XtRemoveAllCallbacks (w, XmNhelpCallback); PanedW.c: XtCallCallbacks (w, XmNhelpCallback, &call_value); Primitive.c: XmNhelpCallback, XmCCallback, XmRCallback, sizeof(caddr_t), Primitive.c: XtRemoveAllCallbacks (pw, XmNhelpCallback); ScrolledW.c: XtCallCallbacks(sw,XmNhelpCallback,&cb); TextIn.c: XtCallCallbacks(w, XmNhelpCallback, (Opaque) &cb); You can see that the FileSB widget supports it, probably through its help button, not translations. The List widget appears to support it, as well as MainWindow, PanedWindow, ScrolledWindow and Text. In 1.1, the support is centralized in the XmPrimitive class, but again, only if traversal is on. peeb
rlh2@ukc.ac.uk (Richard Hesketh) (09/22/90)
In article <9009191944.AA06345@turnpike.Eng.Sun.COM> <argv@Sun.COM> writes: >"good" applications should provide a GUI interface to allow the >user to selectively set allowable resources on user interface elements. >If a GUI interface for this is not possible, then a "language" would >be sufficient, but the cryptic .Xdefaults stuff is not usable by >the audiences that Motif is trying to address. A generic, graphical resource editor is entirely possible and can be produced such that it is a standalone tool that can edit any application through the use of a standard protocol. Restrictions can be made upon this editor by the application's programmer (or widget programmer) such that only certain resources can be modified. This helps the application's integrity. This tool would not preclude the application from having its own customization dialog boxes (ala DECwindows) however a generalized tool that can be used with every application (that talks the required protocol) would remove the general need for these dialog boxes. The X Resource Manager is a *mechanism*; setting resources by editing an Xrm database is IMHO a hack and cannot be called a usable *policy*. Graphical resource editors are not hot air .. they are coming! Ask me around Christmas 8-). Richard Hesketh : @nsfnet-relay.ac.uk:rlh2@ukc.ac.uk : rlh2@ukc.ac.uk ..!mcsun!ukc!rlh2 --- Computing Lab., University of Kent at Canterbury, Canterbury, Kent, CT2 7NF, United Kingdom. Tel: +44 227 764000 ext 7620/3682