[Comp.Sci.Dept, Utrecht] Note from archiver<at>cs.uu.nl: This page is part of a big collection of Usenet postings, archived here for your convenience. For matters concerning the content of this page, please contact its author(s); use the source, if all else fails. For matters concerning the archive as a whole, please refer to the archive description or contact the archiver.

Subject: Motif FAQ (Part 8 of 9)

This article was archived around: 23 May 2006 04:24:20 GMT

All FAQs in Directory: motif-faq
All FAQs posted in: comp.windows.x.motif
Source: Usenet Version

Archive-name: motif-faq/part8 Last-modified: 1 FEB 2002 Posting-Frequency: irregular Organization: Kenton Lee, X/Motif Consultant, http://www.rahul.net/kenton/ URL: http://www.rahul.net/kenton/mfaq.html Version: 8.1
----------------------------------------------------------------------------- Subject: 250) TOPIC: KEYSYMS ----------------------------------------------------------------------------- Subject: 251) What is causing the messages "unknown keysym name osfDown..."? [Last modified: Oct 98] Answer: There is an OSF supplied addition to the /usr/lib/X11/XKeysymDB file. It is found on the release tape and should have been automatically installed if the installation procedure was followed in the Release Notes. You have to copy (or append) lib/Xm/XKeysymDB into /usr/lib/X11. This may require root permission. It is not clear how to fix the problem if you can't do this. The error comes from Xt translation table parsing and can't be fixed in Motif, so if you can't get root permission you may be stuck. The file is not copyrighted so you can install it on other systems. If X has been built so that XKeysymDB is not in this directory, and you don't know where it is looking, run 'strings libX11.a | grep XKeysymDB' to find the path. On a Sun running openwin with shared libraries, you may need to put the path for the library containing XKeysymDB *first* in the path list in LD_LIBRARY_PATH, or it may find the wrong XKeysymDB in the wrong directory. XKeysymDB simply contains the registered keysym values for the OSF keysyms. The OSF values are server-independent. And, all registered keysyms will be included in an XKeysymDB file to be shipped with X11R5. In the meantime (till all systems are X11R5+), a list of the registered keysyms can be found in the X11R4 release in mit/doc/Registry/Xregistry. Also note the XKEYSYMDB environment variable. Setting this to point to the XKeysymDB file often helps, but not always... Some people have also reported getting this error if their Motif libraries were built with libc headers that are not compatible with those installed on their system. For example, Linux has two incompatible libraries libc5 and glibc. You may get keysym (and other) errors if your Motif was built with libc5 but you run your Motif application with glibc. Contact your Motif vendor for information on the required libc. Ken Lee ----------------------------------------------------------------------------- Subject: 252) What happens if I can't install Motif Keysyms? tessi!george@nosun.West.Sun.COM (George Mitchell) wrote: Here's what appears to happen if you don't have XKeysymDB in place to define OSF's virtual keysyms: 1. At class initialize time, for a widget (such as XmText) that uses virtual keysyms in its event translation table, all entries which refer to those keysyms fail to parse correctly. In the case of XmText, instead of ending up with a translation table with roughly 90 entries, you end up with one that has 29. 2. XKeysymDB doesn't exist, so you'd assume that KeyPress events will get translated to plain vanilla keysyms, right? WRONG! All Motif widgets install a virtual keysym translator ANYWAY! Consequently, the backspace key (for example) gets translated to the keysym osfBackSpace. 3. Therefore, if you augment or override your widget's translations with translations that refer to plain vanilla BackSpace, they will never be triggered, because you will NEVER see plain vanilla BackSpace, only osfBackSpace. 4. But you can't use osfBackSpace in an event translation entry, because you don't have XKeysymDB installed! Here's how I'm "dealing" with the problem right now: Motif installs its virtual keysym translator by calling XtSetKeyTranslator every time a VendorShell (or subclass) widget is created. So every time I create a shell, I immediately call XtSetKeyTranslator (display, XtTranslateKey) to restore the default translator. No more funny virtual keysyms! Now I can reinstall non- osfKeySym translations and have them work the way I expect. ----------------------------------------------------------------------------- Subject: 253) Why has OSF introduced Keysyms into Motif 1.1? They weren't there in Motif 1.0. Answer: ellis@osf.org wrote: Virtual Keysyms are meant to provide a consistent keyboard model for Motif applications running in a heterogeneous environment in which proprietary (i.e. vendor specific) non-Motif applications may also be running. First of all, for the sake of the rest of the readers, let's explain why this is an issue: It would be lovely if Motif's translation tables could just use the obvious keysyms predefined by X. For example, there are keysyms for XK_BackSpace, XK_Delete, XK_Left, XK_Right, etc. Shouldn't these be the ones that are used in our translations? Unfortunately, the problem is not so simple. Some specific examples: While most vendors bind XK_BackSpace to the key at the top right of the standard keyboard (often engraved with a leftwards pointing arrow), not all do. In fact, some vendors (including DEC) bind that key to XK_Delete. While most vendors bind the arrow keys to XK_Up, etc, a number of vendors (including Sun, on some servers) bind them to function key keysyms. A simplistic solution would require the use of xmodmap to change the offending bindings. That would work swell in an all Motif environment. However, OSF's goal (not always perfectly achieved) is interoperability. That is, we'd like to make sure that both Motif and non-Motif programs can happily run in the same environment. It is expected that a vendor may have a wide variety of existing X-based software that uses the keysyms as established by that vendor for specific purposes. It is expected that these applications may run at the same time as Motif-based software. Using xmodmap to change keysyms on the server side could "break" the existing applications (or at the very least their documentation) by making some keys unavailable, or by moving the location. So, we chose not to use xmodmap. By the way, though OpenLook uses a different implementation (they recompile their virtual translation tables into actual translation tables), they basically adopted the same approach, presumably for similar reasons. To work properly, the virtual keysym model we implemented depends on Xlib finding XKeysymDB installed appropriately (which standard Motif installation does). This simply defines the keysyms (not the key they are bound to). This unfortunate piece of stupidity is necessary because MIT only includes standard keysyms in keysymdef.h. It should be said that our lives would be made easier if MIT would also see fit to include registered keysyms in keysymdef.h as well. Motif applications determine how to bind virtual to actual keys by looking for either a resource or a property on the root window which describes what to do. Note that this information is on the server side, so that all applications use the same virtual bindings regardless of where they are running. Mwm will happily create the property if it finds a .motifbind file in your home directory when it starts up. (Actually, things generally work even if none of this is done, since if all else fails, the Motif toolkit chooses a virtual bindings table to use based on the identification of the server). The actual implementation of virtual keys is made possible by a hook in the Intrinsics. Undoubtably, the implementation would be simpler and cleaner if virtual key support was more directly supported by the Intrinsics. We will be exploring this possibility in the future. -- Ellis ----------------------------------------------------------------------------- Subject: 254) Why do accented characters not work with Motif applications linked with X11R6? What is the Compose file? [Last modified: June 95] Answer: Note: The list of codes below _should_ contain a backslash before every numeric value. My FAQ maintainence tools have been stripping the backslash. Sorry for the confusion...ksall@cen.com. Roman Czyborra (czyborra@cs.tu-berlin.de) writes: I've xmodmapped a few accented characters onto my keyboard. They've worked fine in most every window, but were dead in the Motif applications linked with X11R6. My LC_CTYPE has always been set to iso_8859_1, so that was not the problem. It turns out that I can activate the keys by patching $XLOCALEDIR/iso8859-1/Compose to also include the lines listed below. <nobreakspace> : "240" <exclamdown> : "241" <cent> : "242" <sterling> : "243" <currency> : "244" <yen> : "245" <brokenbar> : "246" <section> : "247" <diaeresis> : "250" <copyright> : "251" <ordfeminine> : "252" <guillemotleft> : "253" <notsign> : "255" <hyphen> : "255" <registered> : "256" <macron> : "257" <degree> : "260" <plusminus> : "261" <twosuperior> : "262" <threesuperior> : "263" <acute> : "264 <mu> : "265" <paragraph> : "266" <periodcentered> : "267" <cedilla> : "240" <onesuperior> : "271" <masculine> : "272" <guillemotright> : "273" <onequarter> : "274" <onehalf> : "275" <threequarters> : "276" <questiondown> : "277" <Agrave> : "300" <Aacute> : "301" <Acircumflex> : "302" <Atilde> : "303" <Adiaeresis> : "304" <Aring> : "305" <AE> : "306" <Ccedilla> : "307" <Egrave> : "310" <Eacute> : "311" <Ecircumflex> : "312" <Ediaeresis> : "313" <Igrave> : "314" <Iacute> : "315" <Icircumflex> : "316" <Idiaeresis> : "317" <ETH> : "320" <Ntilde> : "321" <Ograve> : "322" <Oacute> : "323" <Ocircumflex> : "324" <Otilde> : "325" <Odiaeresis> : "326" <multiply> : "327" <Ooblique> : "330" <Ugrave> : "331" <Uacute> : "332" <Ucircumflex> : "333" <Udiaeresis> : "334" <Yacute> : "335" <THORN> : "336" <ssharp> : "337" <agrave> : "340" <aacute> : "341" <acircumflex> : "342" <atilde> : "343" <adiaeresis> : "344" <aring> : "345" <ae> : "346" <ccedilla> : "347" <egrave> : "350" <eacute> : "351" <ecircumflex> : "352" <ediaeresis> : "353" <igrave> : "354" <iacute> : "355" <icircumflex> : "356" <idiaeresis> : "357" <eth> : "360" <ntilde> : "361" <ograve> : "362" <oacute> : "363" <ocircumflex> : "364" <otilde> : "365" <odiaeresis> : "366" <division> : "367" <oslash> : "370" <ugrave> : "371" <uacute> : "372" <ucircumflex> : "373" <udiaeresis> : "374" <yacute> : "375" <thorn> : "376" <ydiaeresis> : "377" ----------------------------------------------------------------------------- Subject: 255) TOPIC: UIL [NOTE: As you can see, this is a new topic area. Send me your ideas for answered questions pertaining to this topic.] ----------------------------------------------------------------------------- Subject: 256) What is UIL and why is it so popular? [Last modified: Sept 94] Answer: UIL is the acronym for "User Interface Language", a Motif standard which permits separation of the user interface from application code. UIL is a textual description of the user interface which is compiled into binary form called UID ("User Interface Definition") using the Motif-provided compiler called "uil". It is important to realize that UIL is a static description of the UI in that connections between buttons and the dialogs they invoke, for example, is not expressed here; dynamic UI behavior appears in C code. The Period Table of Widgets, called "periodic" (delivered by many Motif vendors) is an example of a UIL application. There are many advantages and disadvantages of UIL applications. A few of the advantages are: UIL is a standard format which encourages separation of the user interface from application code. UIL can be read and/or written by many of the GUI builders and UIMS tools mentioned elsewhere in this FAQ, making your interface portable (to a degree) across builder tools. UIL is a much better language than C for defining a widget hierarchy: in C, the widget hierarchy is expressed "linearly" by referencing a previously- created parent widget when creating a child widget; in UIL, widget trees are defined more naturally using nesting. With UIL, you separate the definition of the widget tree from the application. You can make major changes to the look-and-feel without re-building the application. It is possible to write a "general-purpose" application that defines a library of callbacks. The application may "execute" any UIL file that references callbacks from the library. For a good UIL reference, see "Motif Programming Manual", Volume 6A, published by O'Reilly and Associates. [See "BOOKS" for details.] ----------------------------------------------------------------------------- Subject: 257) What is Mrm? [Last modified: Nov 94] Answer: Mrm is the "Motif Resource Manager", a set of functions (whose names begin with Mrm, such as MrmFetchWidget and MrmRegisterNames) in libMrm.a which retrieve the widget hierarchy from the UID file, associate callbacks, and create the widgets. Mrm is usually discussed in books which cover UIL. Motif Programming Manual, Volume 6A OSF/Motif Programmers Guide OSF/Motif Programmers Reference Manual See the BOOKS section for detailed references. ----------------------------------------------------------------------------- Subject: 258) How do I specify a search path for ".uid" files? Answer: Use the UIDPATH environment variable. It is documented on the MrmOpenHierarchy() man page. ----------------------------------------------------------------------------- Subject: 259) Can I specify callback functions in resource files? Answer: To specify callbacks, you must use UIL in addition to or in place of resource files. You can, however, specify translations in resource files, which give you most of the same functionality as callback functions. Ken Lee, http://www.rahul.net/kenton/ ----------------------------------------------------------------------------- Subject: 260) How can I set a multi-line label in UIL? [Last modified: Sept 94] Answer: In UIL, you have to explicitly create a compound string with a separator. Here's what W. Scott Meeks suggests: value nl : compound_string('', seperate=true); object my_label : XmLabel { arguments { XmNlabelString = 'Here' & nl & 'is' & nl & 'the' & nl & 'Label'; }; }; ----------------------------------------------------------------------------- Subject: 261) Is there a program that can convert a UIL file to tclMotif? I have an old Motif program that I used on SCO unix. Now that I switched to Linux, I would like to "reprogram" it without the Motif libraries under Linux. [Last modified: Aug 95] Answer: Jan Newmarch (jan@ise.canberra.edu.au) writes: The latest version of tclMotif (v 1.3) will allow you to load uil files (actually, the uid files output from the uil compiler) directly into tclMotif. So you don't need to convert at all. The source is available at ftp.x.org. This, plus a Linux binary are also at ftp://ftp.canberra.edu.au/pub/motif/tclMotif (Thanks to Ben Elliston (ben@ise.canberra.edu.au) for correcting this URL.) ----------------------------------------------------------------------------- Subject: 262) Why does my SCO UIL application fail to open 60 UID files? [Last modified: Sept 95] Answer: Make sure that you call MrmCloseHierarchy. There is no need to keep the file open after you fetch the widgets from it. Thanks to Tom Schutter (tom@platte.com) ----------------------------------------------------------------------------- Subject: 263) TOPIC: ICONIFICATION and DE-ICONIFICATION Iconification/de-iconification is a co-operative process between a client and a window manager. The relevant standards are set by ICCCM. Mwm is ICCCM compliant. The toplevel (non-override-redirect) windows of an application may be in three states: WithdrawnState (neither the window nor icon visible), NormalState (the window visible) or IconicState (the icon window or pixmap visible). This information is contained in the WM_STATE property but ordinary clients are not supposed to look at that (its values have not yet been standardised). Movement between the three states is standardised by ICCCM. ----------------------------------------------------------------------------- Subject: 264) How can I keep track of changes to iconic/normal window state? Answer: You can look at the WM_STATE property, but this breaks ICCCM guidelines. ICCCM compliant window managers will map windows in changing them to normal state and unmap them in changing them to iconic state. Look for StructureNotify events and check the event type: XtAddEventHandler (toplevel_widget, StructureNotifyMask, False, StateWatcher, (Opaque) NULL); void StateWatcher (w, unused, event) Widget w; caddr_t unused; XEvent *event; { if (event->type == MapNotify) printf ("normal\n"); else if (event->type == UnmapNotify) printf ("iconified\n"); else printf ("other event\n"); } If you insist on looking at WM_STATE, here is some code (from Ken Sall) to do it: /* ------------------------------------------------------------------ Try a function such as CheckWinMgrState below which returns one of IconicState | NormalState | WithdrawnState | NULL : ------------------------------------------------------------------ */ #define WM_STATE_ELEMENTS 1 unsigned long *CheckWinMgrState (dpy, window) Display *dpy; Window window; { unsigned long *property = NULL; unsigned long nitems; unsigned long leftover; Atom xa_WM_STATE, actual_type; int actual_format; int status; xa_WM_STATE = XInternAtom (dpy, "WM_STATE", False); status = XGetWindowProperty (dpy, window, xa_WM_STATE, 0L, WM_STATE_ELEMENTS, False, xa_WM_STATE, &actual_type, &actual_format, &nitems, &leftover, (unsigned char **)&property); if ( ! ((status == Success) && (actual_type == xa_WM_STATE) && (nitems == WM_STATE_ELEMENTS))) { if (property) { XFree ((char *)property); property = NULL; } } return (property); } /* end CheckWinMgrState */ One problem with testing WM_STATE is that a race condition is possible; immediately after testing it, it could change, and the logic proceeds to behave as if it were in the old state. ----------------------------------------------------------------------------- Subject: 265) How can I check if my application has come up iconic? I want to delay initialization code and other processing. Answer: Use XtGetValues and check for the XmNinitialState value of the toplevel shell just before XtMainLoop. -- IconicState is iconic, NormalState is not iconic. ----------------------------------------------------------------------------- Subject: 266) How can I start my application in iconic state? Answer: Try this from the command line: application -iconic Using the resource mechanism, set the resource XmNinitialState to IconicState of the toplevel shell widget (the one returned from XtInitialise). ----------------------------------------------------------------------------- Subject: 267) How can an application iconify itself? Answer: In R4 and later, use the call XIconifyWindow. Ken Lee adds "Set XmNiconic on your shell. This should work in X11R6 and later patch levels of X11R5." For R3, send an event to the root window with a type of WM_CHANGE_STATE and data IconicState. void IconifyMe (dpy, win) Display *dpy; Window win; /* toplevel window to iconify */ { Atom xa_WM_CHANGE_STATE; XClientMessageEvent ev; xa_WM_CHANGE_STATE = XInternAtom (dpy, "WM_CHANGE_STATE", False); ev.type = ClientMessage; ev.display = dpy; ev.message_type = xa_WM_CHANGE_STATE; ev.format = 32; ev.data.l[0] = IconicState; ev.window = win; XSendEvent (dpy, RootWindow (dpy, DefaultScreen(dpy)), True, (SubstructureRedirectMask | SubstructureNotifyMask), &ev); XFlush (dpy); } ----------------------------------------------------------------------------- Subject: 268) How can an application de-iconify itself? [Last modified: Aug 98] Answer: Carolyn Allen writes: if(XtIsRealized(shell_widget)) { Display *dpy = XtDisplay(shell_widget); Window win = XtWindow(shell_widget); Window client = XmuClientWindow(dpy,win); XMapRaised(dpy,client); } If all you want to do is pop the icon to the top, use XRaiseWindow(dpy,client) instead. ----------------------------------------------------------------------------- Subject: 269) Why doesn't MWM display an iconify button on my dialog windows? [Last modified: May 95] Answer: MWM (and some other window managers) does not allow transient windows to be iconified. Transients are automatically unmapped when the main shell is iconified and they are re-mapped when the main shell is restored. If you do not want this transient behavior, you should use top a TopLevelShell widget instead of a XmDialogShell widget for your windows. Ken Lee ----------------------------------------------------------------------------- Subject: 270) TOPIC: SPECIALIZED WIDGETS [Last modified: Jan 95] This section describes a few specialized widgets people have asked about. A _far_ more comprehensive illustrated list is maintained by Richard Offer (offer@sgi.com). His list covers these widget categories: Complete Listing Composite Widgets Non-Composite Widgets Motif 1.1 Compatible Motif 1.2 Compatible Athena Compatible FWF Widget Set By Author Shareware Widgets Commercial Widgets For Richard Offer's Widget FAQ Home Page, WWW users should see: http://reality.sgi.com/widgetFAQ/ The Widget FAQ is also available in ASCII as: ftp://ftp.x.org/contrib/faqs/Widget.FAQ.Z If you don't have access to the World Wide Web, the Widget FAQ (sans pictures) can be obtained from ftp.x.org: /contrib/faqs/Widget.FAQ.Z ----------------------------------------------------------------------------- Subject: 271) Where can I get ComboBox, SpinBox, or Tree graph widgets? [Last modified: Apr 98] Motif 2.0 and later include an XmContainer widget which displays hierarchal trees. Motif 2.0 also includes XmComboBox and XmSpinBox, which many users requested. For Motif 1.x versions of these widgets and listings of other types of widgets, see the widgets FAQ mentioned in the previous subject. ----------------------------------------------------------------------------- Subject: 272) How can I create a transparent widget? [Last modified: Dec 98] Answer: The simplest way is probably to use the SHAPE protocol extension. The xeyes, xlogo, and oclock demo programs in X11R5 (and later) are good examples of using SHAPE with widgets. You should be able to use the same techniques with your Motif widget subclasses. Ken Lee Ken Sall (ksall@cen.com) adds: The official name for this extension is "X11 Nonrectangular Window Shape Extension". If you have X11R5 source, the Shape extension document is $TOP/mit/hardcopy/extensions/shape.PS or $TOP/mit/doc/extensions/shape.ms. In X11R6, see $TOP/xc/doc/hardcopy/Xext/shape.PS or $TOP/xc/doc/specs/Xext/shape.ms. There is also a terse man page: $TOP/mit/man/Xext/XShape.man (X11R5) and $TOP/xc/doc/man/Xext/XShape.man (X11R6). Ken Lee adds: Some graphics-oriented systems (e.g., SGI, HP) include hardware overlay planes that support transparency directly. The APIs for accessing these capabilities from Motif programs are non-standard. Read your system's documentation or contact your vendor for more details. ----------------------------------------------------------------------------- Subject: 273) TOPIC: CREATING WIDGETS [This section is for widget writers.] ----------------------------------------------------------------------------- Subject: 274) What are some good references for creating widgets (subclassing widgets)? [Last modified: May 99] Answer: Ken Sall (ksall@cen.com) writes: If you have Motif 2.0 or later, see the new document provided by OSF called "OSF/Motif Widget Writer's Guide" in the directory: doc/widgetGuide/Output/draft/ps. If you have Motif 1.*, try these references (details in the BOOKS topic): Paul Asente, Donna Converse, and Ralph Swick, X Window System Toolkit, Second Edition, 1998. Nye, Adrian & O'Reilly, Tim, X Toolkit Intrinsics Programming Manual.Motif Edition, Volume 4M Flanagan, David, Editor, X Toolkit Intrinsics Reference Manual, Volume 5 joe shelby (jshelby@autometric.com) writes: Alastair Gourlay, a former member of the Motif Development group at OSF, has written 2 articles for _The X Resource_, published by O'Reilly and Associates. The first, "Writing Motif Widgets : A Pragmatic Approach" can be found in Issue 6. It covers writing a XmPrimitive-derived widget, deriving from that widget, and writing a XmManager-derived widget. Also included are brief summaries of several _Xm private functions for widget writers, how to use the Motif 1.2 Representation Type functions, and adding the widgets to Mrm/Uil. The second, "The One-Minute Manager : Custom Motif Layout Widgets Made Easy" can be found in Issue 10. It expands and greatly simplifies creating composite widgets for Motif. Gourlay has created and released a new widget, the XmpGeometry widget that handles all of the geometry management issues for you and provides convenience functions for determiningparent and child widgets' perfered sizes. All the programmer has to do to derive from this widget is create the new resources and constraints and implement 2 new class methods to override the XmpGeometry's methods. Included with the XmpGeometry class are 3 example derived widgets. Donald L. McMinds and Joseph P. Whitty have written a book, _Writing Your Own OSF/Motif Widgets_, published by Prentice Hall for Hewlett-Packard Professional Books. Both authors work at HP's Workstation Systems Division, and have been involved with Motif developement since its beginnings. The book (which is mostly code with explanations) gives details on writing XmPrimitive-derived, XmManager-derived, and XmGadget-derived widgets, with one example widget for each. In addition, the book provides "man-pages" for several _Xm private functions for programmer convenience. ----------------------------------------------------------------------------- Subject: 275) How can I achieve binary compatibility using the XmResolvePartOffset API? [Last modified: July 96] Answer: Daniel Dardailler (daniel@x.org) recently provided the following URL: http://www.x.org/people/daniel/xmresolve Achieving Binary Compatibility using the XmResolvePartOffset API which addresses the problem caused by the fact that many widget writers "never used the XmResolvePartOffsets API in their subclass code, therefore ensuring it will break when dynamically relinked with newer version of libXm". Unfortunately, this URL is no longer valid. Does anyone know of a new location? Thanks. ----------------------------------------------------------------------------- Subject: 276) TOPIC: MISCELLANEOUS ----------------------------------------------------------------------------- Subject: 277) How can an application be informed of signals? [Last modified: Jun 98] Answer: The answer differs depending on whether you're using X11R5 or X11R6. For those using X11R6, Ken Lee (http://www.rahul.net/kenton/) writes: In X11R6, the Xt library has the new XtAppAddSignal() function. Ken Lee's December, 1995 *The X Advisor* column has an example: http://www.rahul.net/kenton/txa/dec95.html For those using X11R5, these older responses apply: blackman@hodgkin.med.upenn.edu (David Blackman) writes: According to comp.windows.x FAQ, you shouldn't make Xt/Xlib calls from a Unix signal handler: "You can work around the problem by setting a flag in the interrupt handler and later checking it with a work procedure or a timer event which has previously been added." Kaleb KEITHLEY (fedora.x.org!kaleb) adds: Xt is not reentrant and it is not safe to call any Xt functions from a signal handler... I think [the signaling] technique is covered in the [X] FAQ. On most POSIX-type systems write(2) is guaranteed to be reentrant and atomic. If you establish a simple pipe with the pipe(2) system call, and add it as an XtInput with XtAppAddInput(), then you can write to the pipe in the signal handler. Xt will notice that input is available and call the input-handler proc. This technique is inherently better than setting the flag because the write to the pipe will result in XtAppNextEvent returning immediately without the latency you observe in using the flag technique. In R6 you can use the XtAppAddSignal function. Ken Sall (ksall@cen.com) adds: See the "Signal Handling" chapter of "Motif Programming Manual" by Heller and Ferguson, listed in the BOOKS topic. Paul Davey (pd@uit.co.uk) adds: The write and XtAppAddInput input method is often the best - but be warned it does not work on some SVR3 based Unixes, where a pipe may not be selected on. SCO Unix exhibits this behaviour so here the external flag method should be used. ----------------------------------------------------------------------------- Subject: 278) How do I control the repeat rate on a SUN keyboard? Answer: [...] -ar1 milliseconds This option specifies amount of time in milliseconds before which a pressed key should begin to autorepeat. -ar2 milliseconds This option specifies the interval in milliseconds between autorepeats of pressed keys. Of course this presumes you're using a server based on the MIT sample server. Thanks to kaleb@x.org (Kaleb Keithley) ----------------------------------------------------------------------------- Subject: 279) How can I identify the children of a manager widget? Answer: Use XtGetValues() on XmNchildren (array of widget IDs) and XmNnumChildren (number of widgets in array). ----------------------------------------------------------------------------- Subject: 280) What functions can an application use to change the size or position of a widget? Answer: Applications should set the values of the XmNx, XmNy, XmNwidth, and XmNheight resources. Note that many manager widgets ignore the XmNx and XmNy resources of their children, relying instead on their internal layout algorithms. If you really want specific positions, you must use a manager widget that allows them, e.g., XmBulletinBoard. Also note that some manager widgets reject size change requests from their children when certain resources are set (e.g., XmNresizable on XmForm). Others allow the the children to resize, but clip the results (e.g., XmNallowShellResize on shell widgets). Make sure you have these resources set to the policy you want. Due to bugs, some widgets (third party widgets) do not respond to changes in their width and height. Sometimes, you can get them to respond correctly by unmanaging them, setting the resources, then managing them again. Under no circumstances should applications use routines like XtConfigureWidget() or XtResizeWidget(). These routines are reserved for widget internals and will seriously confuse many widgets. Ken Lee ----------------------------------------------------------------------------- Subject: 281) Can I use XtAddTimeOut, XtAddWorkProc, and XtAddInput with XtAppMainLoop? Answer: On many systems, the obsolete XtAdd*() functions are not compatible with the XtAppMainLoop(). Instead, you should use newer XtAppAddTimeOut(), XtAppAddWorkProc(), and XtAppAddInput() functions with XtAppMainLoop() Ken Lee ----------------------------------------------------------------------------- Subject: 282) Why does XtGetValues for XmNx and XmNwidth return extremely large values? Answer: You must use the 16 bit "Dimension" and "Position" data types for your arguments. If you use 32 bit integers, some implementations will fill the remaining 16 bits with invalid data, causing incorrect return values. The *Motif Programmer's Manual* and the widget man pages specify the correct data type for each resource. Ken Lee ----------------------------------------------------------------------------- Subject: 283) Can I use XmGetPixmap() with widgets that have non-default visual types? Answer: XmGetPixmap() assumes that you are using the default screen depth. If you're using a different depth, use XmGetPixmapByDepth() instead. Ken Lee ----------------------------------------------------------------------------- Subject: 284) What is the matter with Frame in Motif 1.2? [Last modified: November 92] Answer: This announcement has been made by OSF: "IMPORTANT NOTICE We have discovered two problems in the new 1.2 child alignment resources in XmFrame. Because some vendors may have committed, or are soon to commit to field releases of Motif 1.2 and 1.2.1, OSF's options for fixing them are limited. We are trying to deal with these in a way that does not cause hardship for application developers who will develop applications against various point versions of Motif. OSF's future actions for correction are summarized. WHAT YOU SHOULD DO AND KNOW 1. Mark the following change in your documentation. On page 1-512 of the OSF/Motif Programmer's Reference, change the descriptions under XmNchildVerticalAlignment as follows (what follows is the CORRECT wording to match the current implementation): XmALIGNMENT_WIDGET_TOP Causes the BOTTOM edge of the title area to align vertically with the top shadow of the Frame. XmALIGNMENT_WIDGET_BOTTOM Causes the TOP edge of the title area to align vertically with the top shadow of the Frame. 2. Note the following limitation on resource converters for Motif 1.2 and 1.2.1 implementations. The rep types for XmFrame's XmNentryVerticalAlignment resource were incorrected implemented, which means that converters will not work properly. The following resource settings will not work from a resource file in 1.2 and 1.2.1: *childVerticalAlignment: alignment_baseline_bottom *childVerticalAlignment: alignment_baseline_top *childVerticalAlignment: alignment_widget_bottom *childVerticalAlignment: alignment_widget_top If you wish to set these values for these resources (note they are new constraint resources in XmFrame) you will have to set them directly in C or via uil. WHAT WE WILL DO The problem described in note #1 above will not be fixed in the OSF/Motif implementation until the next MAJOR release of Motif. At that time we will correct the documentation and modify the code to match those new descriptions, but we will preserve the existing enumerated values and their behavior for backward compatibility for that release. The fix for the problem described in note #2 will be shipped by OSF in Motif 1.2.2. SUMMARY We are sorry for any difficulty this causes Motif users. If you have any questions or flames (I suppose I deserve it) please send them directly to me. We sincerely hope this proactive response is better for our customers than you having to figure it out yourselves! Libby ----------------------------------------------------------------------------- Subject: 285) What is IMUG and how do I join it? [Last modified: July 96] Answer: CAUTION: As of March, 1996, IMUG could not be contacted. If anyone is aware of the status of IMUG, please send mail to me (kenton@nojunk.rahul.net). Thanks to Lou Farho (farho@harris.com) for this update. IMUG is the International Motif User Group founded by Quest Windows Corporation and co-sponsored by FedUNIX. IMUG is a non-profit organization working to keep users informed on technical and standards issues, to strengthen user groups on a local level, to increase communication among users internationally, and to promote the use of an international conference as a forum for sharing and learning more about Motif. You can join it by 1. Pay the annual membership fee of $20 USD directly to IMUG. Contact IMUG 5200 Great America Parkway Santa Clara, CA 95054 (408) 496-1900 imug@quest.com 2. Register at the International Motif User Conference, and automatically become an IMUG member. 3. Donate a pd widget, widget tool or widget builder to the IMUG Widget Depository and receive a free one year IMUG membership. ----------------------------------------------------------------------------- Subject: 286) How do I set the title of a top level window? [Last modified: September 92] Answer: Set XmNtitle (and optionally XmNtitleEncoding) for TopLevelShells. (Note that this is of type String rather than XmString.) You can also set XmNiconName if you want its icon to show this title. For XmDialogShells, set the XmNdialogTitle of its immediate child, assuming it's a BulletinBoard subclass. These can also be set in resource files. ----------------------------------------------------------------------------- Subject: 287) How can I disable the color scheme mechanism in CDE or HP VUE? [Last modified: May 97] Answer: Put this in your app-defaults file: *useColorObj: False Ken Lee ----------------------------------------------------------------------------- Subject: 288) Can I use editres with Motif? Is there an editres tutorial? [Last modified: Mar 96] Answer: Editres, part of the MIT delivery, is a powerful widget tree analysis tool and is highly recommended. There's negligible overhead in making editres available to an application and many projects keep the editres "hook" active even for operational programs. It isn't built in to Motif (at 1.2.*), but you can do this in your application: #include <X11/Xmu/Editres.h> XtAddEventHandler(shell_widget, (EventMask) 0, True, (XtEventHandler) _XEditResCheckMessages, NULL); once for each shell widget that you want to react to the "click to select client" protocol. Then link your client with the R5 libXmu. Thanks to David Brooks, OSF, for the original answer. Jan Sandquist (ehsjasa@ehs.ericsson.se) supplied the current code snipet above. Joachim Fabini (jo@vmars.tuwien.ac.at) suggested that I remove the older use of "extern void _XEditResCheckMessages()" which resulted in core dumps on some platforms. NOTE: Ken Lee has placed his November, 1994 editres tutorial on the Web: http://www.rahul.net/kenton/editres.html ----------------------------------------------------------------------------- Subject: 289) Where is the editres protocol documented? [Last modified: Apr 95] Answer: In /usr/include/X11/Xmu/EditresP.h. Ken Lee ----------------------------------------------------------------------------- Subject: 290) Why does an augment translation appear to act as replace for some widgets? When I use either augment or override translations in .Xdefaults it seems to act as replace in both Motif 1.0 and 1.1 Answer: By default, the translation table is NULL. If there is nothing specified (either in resource file, or in args), the widget's Initialize finds: Oh, there is NULL in translations, lets use our default ones. If, however, the translations have become non-NULL, the default translations are NOT used at all. Thus, using #augment, #override or a new table has identical effect: defines the new translations. The only way you can augment/override Motif's default translations is AFTER Initialize, using XtSetValues. Note, however, that Motif managers do play with translation tables as well ... so that results are not always easy to predict. OSF wrote: A number of people have complained about not being able to augment/override translations from the .Xdefaults. This is due to the complexity of the menu system/keyboard traversal and the necessary translations changes required to support the Motif Style Guide in menus. It cannot be fixed in a simple way. Fixing it requires re-design of the menus/buttons and it is planned to be fixed in 1.2. ----------------------------------------------------------------------------- Subject: 291) How do you "grey" out a widget so that it cannot be activated? Answer: Use XtSetSensitive(widget, False). Do not set the XmNsensitive resource directly yourself (by XtSetValues) since the widget may need to talk to parents first. ----------------------------------------------------------------------------- Subject: 292) Can I change the graphics drawn by insensitive widgets? Some become very difficult to read. [Last modified: Aug 97] Answer: There is no general mechanism for this; each widget chooses its own insensitive graphics. Some are customizable, however. Label and button widgets have a XmNlabelInsensitivePixmap resource. Others, such as the text widgets, have an XmNeditable resource; setting this to false is similar to insensitive, except tha the graphics do not change. Other possibilities would be to install an empty translation table to ignore input or to create an occluding InputOnly window to block input. ----------------------------------------------------------------------------- END OF PART EIGHT