Motif FAQ (Part 1 of 9) - Motif

This is a discussion on Motif FAQ (Part 1 of 9) - Motif ; Archive-name: motif-faq/part1 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: Motif FAQ (all parts) Newsgroups: comp.windows.x.motif,comp.answers,news.answers Reply-To: kenton@rahul.net (Ken Lee) Summary: Motif Frequently Asked Questions (with answers). Posting-Freq.: irregular (re-posted monthly ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Motif FAQ (Part 1 of 9)

  1. Motif FAQ (Part 1 of 9)

    Archive-name: motif-faq/part1
    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: Motif FAQ (all parts)
    Newsgroups: comp.windows.x.motif,comp.answers,news.answers
    Reply-To: kenton@rahul.net (Ken Lee)
    Summary: Motif Frequently Asked Questions (with answers).
    Posting-Freq.: irregular (re-posted monthly to comp.windows.x.motif)
    Organization: Kenton Lee, X/Motif Consultant, http://www.rahul.net/kenton/
    URL: http://www.rahul.net/kenton/mfaq.html

    Motif FAQ

    [Last changed: 1 FEB 2002]

    This article contains the answers to some Frequently Asked Questions (FAQ)
    often seen in comp.windows.x.motif. It is posted to help reduce volume in
    this newsgroup and to provide hard-to-find information of general interest.
    This article includes answers to the questions listed below. Key:
    + questions NEW to this issue;
    * CHANGES since last issue.

    This FAQ is maintained by Ken Lee (kenton@nojunk.rahul.net)
    http://www.rahul.net/kenton/

    You can obtain the most recent version of this FAQ via anonymous ftp from
    a server which will seldom refuse you access. Try any of these URLs:
    ftp://ftp.rahul.net/pub/kenton/faqs/Motif-FAQ or
    ftp://ftp.rahul.net/pub/kenton/faqs/Motif-FAQ.gz

    or get the HTML version as one big 600KB file from:
    ftp://ftp.rahul.net/pub/kenton/faqs/Motif-FAQ.html or
    ftp://ftp.rahul.net/pub/kenton/faqs/Motif-FAQ.html.gz

    The Motif FAQ is mirrored at several sites around the world.
    Sites closer to you should load faster. These sites are listed at:
    http://www.rahul.net/kenton/mfaq.html

    I also maintain a WWW page of over 700 technical X Window System and OSF/Motif
    links at:
    http://www.rahul.net/kenton/xsites.framed.html

    Send updates and corrections to kenton@nojunk.rahul.net.
    Please include the phrase "For Motif FAQ" in your subject line.

    *** SUN READERS ***
    The Motif FAQ is now included in a different HTML format with Java applets
    on the premiere issue of the SunSoft Developer CD-ROM.

    *** CAVEAT ***
    If an answer does not have a "Last modified" date, it's possible the
    information may no longer be accurate. Modification dates go back to
    August 1992. More than half the answers have such a modification
    date. Note also that the older the "Last modified" date, the more
    likely the information may be suspect. Pay close attention to version
    information discussed in answers, since the information may pertain
    only to that specific release.

    This posting is Copyright (c) 1997-2002 by Kenton Lee.
    ALL RIGHTS RESERVED. Permission is hereby granted to read and
    distribute this posting for non-commercial purposes. Permission to use
    this material for any other purpose must first be obtained in writing
    from the author.

    -----------------------------------------------------------------------------
    0) TOPIC: SUBMITTING SUGGESTIONS, CORRECTIONS, NEW ANSWERS
    1) TOPIC: WHAT IS MOTIF?
    2)* Is the Motif source code publically available?
    3)* What is Motif and how does it relate to the X Toolkit and X Window Sys-
    tem?
    4) Where did the name "Motif" come from?
    5) TOPIC: OTHER RELEVANT NEWSGROUPS AND FAQS
    6) TOPIC: FAQ and NEWSGROUP FTP ARCHIVES
    7) Is the FAQ available via FTP?
    8) Can I receive email notification when the Motif FAQ is updated?
    9) Is this FAQ accessible via WWW?
    10)* Is this newsgroup archived?
    11) TOPIC: OSF, MOTIF VERSIONS, CDE, COSE, DCE, The OPEN GROUP
    12) How can I contact the Open Group?
    13) Where can I find OSF press releases on Motif and DCE?
    14)* What versions of Motif are there?
    15)* How can I find which version of Motif I have? Xlib or Xt version?
    16) Is there a concise features list for Motif 2.0?
    17) What are the details about new features in Motif 2.0?
    18) Is there a concise features list for Motif 2.1?
    19)+ Is there a concise features list for Motif 2.2?
    20) Where can I find Motif 2.1 documentation?
    21)* Is the official Motif documentation available on-line?
    22) I want to use C++ with Motif. Where can I find C++ examples?
    23) Is Motif 2.0 backward compatible with Motif 1.2?
    24) How compatible are Motif 1.2.* and X11R6?
    25) Why aren't the big UNIX vendors shipping Motif 2.0?
    26) Where can I get Motif for UNIX, Linux, or Microsoft Windows?
    27) Is there a list of Motif bugs?
    28) Where can I get a Motif 1.2 Certification Checklist?
    29) What is CDE? What is COSE and how does it relate to Motif?
    30)* Is there a CDE FAQ or newsgroup?
    31) What is the current version of CDE and what are its features?
    32) How does Motif relate to X/Open and CDE?
    33) What is The Open Group?
    34) Is The Open Group assuming responsibility for the X Window System?
    35) What are the current correct trademark statements for X and Motif?
    36) Will CDE and Motif converge? What is the CDE/Motif JDA?
    37)* Has anyone done a public domain Motif lookalike?
    38) Does the Open Group have an application compliance validation service?
    39) What is the motif-talk mailing list?
    40) How does Motif work with X11R5?
    41) Where can I find X technical info on the WWW?
    42) What is Broadway? I've heard it called "X on the Web".
    43) Where's an HTML version of the Motif FAQ on World Wide Web (WWW)?
    44) Where can I get the HTML widget used in Mosaic?
    45)* What widgets does Netscape use for its bookmarks list and preference
    panels?
    46) TOPIC: BOOKS and JOURNALS
    47) Is there a Motif tutorial? Xt tutorial? X11 tutorial?
    48) What books are available for Motif application programmers?
    49) What relevant journals are available?
    50) TOPIC: MWM and the SHELL WIDGET
    51) What is the difference between Motif and mwm?
    52) Does anyone have an alternative set of 3-D defaults for a monochrome
    screen?
    53) What are some useful mwm resources I can control?
    54) How can I configure mwm, such as changing or adding to root menus?
    55) How can my program determine which window manager is running?
    56) How can I modify the mwm's window decorations with a resource file?
    57) How can I programatically modify the mwm's window decorations?
    58) Is there an ICCCM compliant way of setting window manager decorations?
    59) How can I put decorations on transient windows using olwm?
    60) How can I turn off the Motif window manager functions from the system
    menu?
    61) How can I create a multi-colored window manager icon?
    62) How can I keep my shell windows fixed in size?
    63) Why is XtGetValues of XmNx and XmNy of my toplevel shell wrong?
    64) How do I get XmNx and XmNy positions to be honored correctly?
    65) How can my application know when the user has quit Mwm?
    66) How can I tell if the user has selected "Close" from the system menu? How
    do I catch the "Close"?
    67) Is there an mwm virtual desktop manager?
    68) Why does mwm 1.2 crash on startup?
    69) How do I obtain the size of a unmanaged shell widget?
    70) How can I create a shell widget with a non-default visual type?
    71) Can a non-shell Motif widget have a different visual type from its
    parent?
    72) Why do I get BadMatch errors from my menus when I use a non-default visu-
    al type for my application shell?
    73) How do I popup a scrolled list on top of other widgets?
    74) How can I keep my application's window always on top of all other appli-
    cations' windows?
    75) How can I maximize my top level shell?
    76) TOPIC: MOTIF DEVELOPMENT TOOLS (GUI BUILDERS and UIMS's)
    77)* What GUI tools exist to assist in developing Motif applications?
    78) TOPIC: GEOMETRY MANAGEMENT
    79) Why is geometry management so important?
    80) Why don't my labels resize in a RowColumn widget?
    81) Does XmRowColumn support multiple columns with different column widths?
    82) Why do composite widgets (including dialogs) that were created after
    their parents were realized appear smaller under 1.2.3 and later?
    83) How does the ScrolledWindow manage resizing?
    84) Does the XmPanedWindow widget support horizontal paning?
    85) TOPIC: TEXT WIDGET
    86) How do XmTextField and a single line XmText widget differ?
    87) Why does pressing RETURN in a text widget do nothing?
    88) Can you reuse the return value from XtParseTranslationTable?
    89) When I add text to a scrolling text widget, how can I get the new text to
    show?
    90) How do I scroll text to display the most recently added information?
    91) Does the text widget support 16 bit character fonts?
    92) How can I stop the text widget from echoing characters typed?
    93) How can I replace characters typed with say a `*'?
    94) How can I make a text widget insensitive without graying out the text?
    95) How can I best add a large piece of text to a scrolled text widget?
    96) How can I get the correct colors for scrolled text widget scrollbars (Sun
    only)?
    97) How can I highlight text in the Text widget?
    98) How can I select all of the text in a widget programmatically?
    99) Can I customize the pointer cursor or insert position indicator used by
    the text widget?
    100) How can I change colours of text in the Text widget?
    101) How can I change the font of text in the Text widget?
    102) Is there an emacs binding for the text widget?
    103) What if I have problems with the backspace/delete keys?
    104) How can I use a file as the text source for a Text widget?
    105) How can put Text in overstrike mode instead of insert?
    106) How can I make the Delete key do a Backspace?
    107) Can I change the tab stops in the XmText widget?
    108) TOPIC: LIST WIDGET
    109) Should I create an XmList widget as a child of automatic XmScrolledWin-
    dow or use the XmCreateScrolledList() convenience function?
    110) How do I best put a new set of items into a list?
    111) Can I have strings with different fonts in a list?
    112) Can I get a bitmap to show in a list item like I can in a Label?
    113) Can I have items with different colors in a list widget?
    114) How can I line up columns in a list widget?
    115) Can I grey out an item in a list widget?
    116) Can I have multi-line items in a list?
    117) How can I tell the position of selected items in a list?
    118) How can I configure a scrolled list widget to show a horizontal
    scrollbar when some list items are wider than the window?
    119) How can I programatically select all of the items in an XmList?
    120) TOPIC: FILE SELECTION BOX WIDGET
    121) What is libPW.a and do I need it?
    122) What are these compile errors: Undefined symbol _regcmp and _regex?
    123) What's wrong with the Motif 1.0 File Selection Box?
    124) How can I keep my file selection boxes from resizing when I change
    directories or filters?
    125) What's wrong with the FileSelectionBox under Solaris?
    126) TOPIC: FORM WIDGET
    127) Why don't labels in a Form resize when the label is changed?
    128) How can I center a widget in a form?
    129) How do I line up two columns of widgets of different types?
    130) TOPIC: PUSHBUTTON WIDGET
    131) Why doesn't the enter or return key activate the button with focus?
    132) Why can't I use accelerators on buttons not in a menu?
    133) TOPIC: TOGGLEBUTTON WIDGET
    134) What widgets give the look of push buttons, but behavior of toggle but-
    tons?
    135) Can I customize XmToggleButton to use my own indicator graphic (e.g., a
    check mark)?
    136) TOPIC: ICON WIDGET and PIXMAPS
    137) What is XPM?
    138) How do I convert my XPM file into a Pixmap?
    139) How can I display a multi-color image in a widget?
    140) Can I use XmGetPixmap in Motif 1.2 to create colored images?
    141) Why does XpmCreatePixmapFromData fail with a pixmap containing a large
    number of colors?
    142) How can I convert a Sun/GIF/TIFF image to a pixmap?
    143) How can I use Motif's pre-defined pixmaps?
    144) TOPIC: SCALE AND SCROLLBAR WIDGET
    145) Can the XmScale widget have arrows or tick marks in Motif 2.0?
    146) How can I set the color of a XmScale widget's trough?
    147) How does Motif implement mouse button auto-repeat on the scrollbar's ar-
    row buttons?
    148) TOPIC: LABEL WIDGET
    149) How can I align the text in a label (button, etc) widget?
    150) Why doesn't label alignment work in a XmRowColumn?
    151) How can I set a multi-line label?
    152) How can I have a vertical label?
    153) How can I have a Pixmap in a Label?
    154) Why doesn't the XmLabel widget obey the XmNwith and XmNheight that I
    give it?
    155) How do you set the background color of a label widget using XtVa-
    TypedArg?
    156) TOPIC: DRAWING AREA WIDGET
    157) How can I send an expose event to a Drawing Area widget?
    158) How can I know when a DrawingArea has been resized?
    159) How can I create a drawing area widget with a visual type different from
    its parent?
    160) How can I display postscript in a Motif widget, such as XmDrawingArea?
    161) TOPIC: MAIN WINDOW WIDGET
    162) How can I create a message window in an XmMainWindow?
    163) TOPIC: SCROLLED WINDOW WIDGET
    164) How do I tell if a scrolled window's scrollbars are visible?
    165) How can I programatically scroll a XmScrolledWindow in XmAUTOMATIC mode?
    166) What widget does the XmScrolledWindow use for its clip window?
    167) How do I create a scrolled window with only one scrollbar?
    168) TOPIC: MENUS
    169) How can I change the cursor used in Motif menus?
    170) How do I put my help menu on the far right of my menubar?
    171) Can I change or disable the menu bar accelerator from the default (F10)?
    172) How do I set the current choice in a radio box or an option menu?
    173) How can I determine the item selected in a a radio box or option menu?
    174) How can I change the cascade indicator on an option menu?
    175) How do I unset an XmToggleButton in a radio box?
    176) Can I place a radio box in a pulldown menu?
    177) How do I make a menu choice insensitive if it was created with XmVa-
    CreateSimplePulldownMenu?
    178) What widgets can I put inside a menubar?
    179) Can I have a cascade button without a submenu in a pulldown menu?
    180) Should I have a cascade button without a submenu in a pulldown menu?
    181) What is the best way to create popup menus?
    182) How do popup menus work?
    183) How can I disable the button 3 grab if I am not using popup menus?
    184) Should I use translation tables or actions for popup menus?
    185) What are the known bugs in popup menus?
    186) Can I have multiple popup menus on the same widget?
    187) How can I change the shell title of a tear-off menu?
    188) Can I programmatically tear-off a menu?
    189) What widgets are valid within Motif menus?
    190) Can I create multi-column popup or pulldown menus?
    191) How can I keep my program from hanging if a user activates a popup that
    is a child of an insensitive push button?
    192) TOPIC: DRAG AND DROP
    193) Where can I find info and examples of the Motif drag and drop protocol?
    194) How can I disable Drag and Drop in my Motif 1.2 client ?
    195) Can I register client data for the Motif XmDropSite drop callback?
    196) Can unmanged widgets be valid (drag-and-drop) drop sites?
    197) TOPIC: INPUT FOCUS
    198) How can I specify the widget that should have the keyboard focus when my
    application starts up?
    199) How can I specify my own keyboard traversal order?
    200) How can I determine which widget has keyboard focus?
    201) How can I direct the keyboard input to a particular widget?
    202) How can I have a modal dialog which has to be answered before the appli-
    cation can continue?
    203) TOPIC: MEMORY AND SPEED
    204) When can I free data structures passed to or retrieved from Motif?
    205) What memory leaks are known? Why does my application grow in size?
    206) Why do I get so many uninitilized memory read (UMR) errors when I run
    Purify[tm] on my Motif programs?
    207) Why does my application take a long time to start up?
    208) My application is running too slowly. How can I speed it up?
    209) Why is my application so huge?
    210) How can I improve performance when creating and deleting hundreds of
    text widgets?
    211) After I call XtSetValues, when will I see the changes in my GUI?
    212) TOPIC: XMSTRING
    213) What string functions differ in Motif 1.1 and 1.2?
    214)* How can I get the ASCII text out of an XmString?
    215) When can XmStrings used as resources be freed?
    216) Why doesn't XmStringGetNextSegment() work properly?
    217) Why does using XmStringDraw cause a BadFont error?
    218) How can I control color of individual strings to show status, etc.?
    219) TOPIC: DIALOGS
    220) How do I stop my dialog disappearing when I press the help button?
    221) How do I make my own dialog?
    222) Why do dialog title bars have "_popup" or "<-popup" concatenated onto
    the widget name?
    223) How can I force a dialog window to display?
    224) How can I control placement of a popup widget?
    225) How can I set the dialog's default button?
    226) How can I create a dialog that behaves like, but looks a little dif-
    ferent from, XmMessageBox?
    227) How can I use Motif's message dialog bitmaps in my own dialogs?
    228) TOPIC: LANGUAGE BINDINGS
    229) What is ViewKit? Is there a free version?
    230) Is there a C++ binding for Motif?
    231) How can I avoid C++ String class and typedef char *String conflicts?
    232) How can I have a C++ member function in a callback?
    233) Is there a Common Lisp binding for Motif?
    234) Is there an Ada binding for Motif? (Part 1 of 2)
    235) Is there an Ada binding for Motif? (Part 2 of 2)
    236) Is there a Poplog binding for Motif?
    237) TOPIC: SPECIFIC PLATFORMS
    238) Is it easy to build Motif for a Sun?
    239) How do I build Motif 1.2.2 on Solaris 2.1 with Sun C?
    240) What compile errors/warnings might I get in both Sun 3 and Sun 4?
    241) On a Sun 3, what are the mwm startup error messages about?
    242) Are there problems making shared libraries on a Sun?
    243) Why does the OpenWindows server hangs when I popup a menu with Button 3?
    244) Has anyone made shared libraries on an IBM RS/6000?
    245) What is the error "Unaligned access in XmString" under Ultrix?
    246) Can bugs in Sun's OpenWindows server cause Motif clients to crash?
    247) Why does Motif on Linux crash when I open a file selection box?
    248) Are there compatibility problems between some Linux Motif libraries and
    libc5 or glibc?
    249) How can I install Motif on my PC?
    250) TOPIC: KEYSYMS
    251) What is causing the messages "unknown keysym name osfDown..."?
    252) What happens if I can't install Motif Keysyms?
    253) Why has OSF introduced Keysyms into Motif 1.1?
    254) Why do accented characters not work with Motif applications linked with
    X11R6? What is the Compose file?
    255) TOPIC: UIL
    256) What is UIL and why is it so popular?
    257) What is Mrm?
    258) How do I specify a search path for ".uid" files?
    259) Can I specify callback functions in resource files?
    260) How can I set a multi-line label in UIL?
    261) Is there a program that can convert a UIL file to tclMotif?
    262) Why does my SCO UIL application fail to open 60 UID files?
    263) TOPIC: ICONIFICATION and DE-ICONIFICATION
    264) How can I keep track of changes to iconic/normal window state?
    265) How can I check if my application has come up iconic?
    266) How can I start my application in iconic state?
    267) How can an application iconify itself?
    268) How can an application de-iconify itself?
    269) Why doesn't MWM display an iconify button on my dialog windows?
    270) TOPIC: SPECIALIZED WIDGETS
    271) Where can I get ComboBox, SpinBox, or Tree graph widgets?
    272) How can I create a transparent widget?
    273) TOPIC: CREATING WIDGETS
    274) What are some good references for creating widgets (subclassing widg-
    ets)?
    275) How can I achieve binary compatibility using the XmResolvePartOffset
    API?
    276) TOPIC: MISCELLANEOUS
    277) How can an application be informed of signals?
    278) How do I control the repeat rate on a SUN keyboard?
    279) How can I identify the children of a manager widget?
    280) What functions can an application use to change the size or position of
    a widget?
    281) Can I use XtAddTimeOut, XtAddWorkProc, and XtAddInput with XtAppMain-
    Loop?
    282) Why does XtGetValues for XmNx and XmNwidth return extremely large
    values?
    283) Can I use XmGetPixmap() with widgets that have non-default visual types?
    284) What is the matter with Frame in Motif 1.2?
    285) What is IMUG and how do I join it?
    286) How do I set the title of a top level window?
    287) How can I disable the color scheme mechanism in CDE or HP VUE?
    288) Can I use editres with Motif? Is there an editres tutorial?
    289) Where is the editres protocol documented?
    290) Why does an augment translation appear to act as replace for some widg-
    ets?
    291) How do you "grey" out a widget so that it cannot be activated?
    292) Can I change the graphics drawn by insensitive widgets?
    293) Why doesn't the Help callback work on some widgets?
    294)* How can I implement "bubble help" or "tool tips" with Motif?
    295) Can I specify a widget in a resource file?
    296) Why are only some of my translations are being installed?
    297) Can I have separate translations for shifted and unshifted keys?
    298) What are these "non-existant passive grab" warnings?
    299) How do I have more buttons than three in a MessageBox?
    300) How do I create a "busy working cursor"?
    301) Can I use the hourglass that mwm uses?
    302) What order should the libraries be linked in?
    303) How do I use xmkmf for Motif clients?
    304) How do I use imake with Motif 2.0?
    305) How do I make context sensitive help?
    306) How do I debug a modal interaction?
    307) Why can't I install my own colormap using XInstallColormap?
    308) How do I install a private colormap?
    309) How do I get correct shadow colors to match other color changes?
    310) What color algorithm does Motif use?
    311) How can you access the superclass widget from which Motif convenience
    dialogs are subclassed?
    312) Can the Motif 2.0 Notebook widget display non-rectangular "file tabs"?
    313) How does the clipboard mechanism work?
    314) Why does the xyz application core dump when I cut and paste?
    315) Why is XtWindow(widget) == 0?
    316) How do I debug X protocol errors (e.g., BadWindow, BadMatch) in Motif
    applications?
    317) Why doesn't XtNameToWidget (widget, "MyName") work?
    318) Why does my callback's client data structure contain incorrect values
    when the callback is called?
    319) How can an application manage events on multiple displays?
    320) Can a Motif application create windows on mutiple screens (on a multi-
    screen workstation)?
    321) Why do I get "Error: attempt to add non-widget child "dsm" to parent"?
    322) Why do I get link errors about "XShape" symbols?
    323) Why do I get link errors about "ICE" and "SM" symbols?
    324) Why does my X11R6 program crash with undefined symbol "LowerCase"?
    325) How do I programatically control xwd to dump a specific window?
    326) How can I display an xwd in a window (without using xwud)?
    327) Can I write a multi-threaded Motif application?
    328) How can I dump my widget instance tree in a way that reflects the
    hierarchy?
    329) How do I get the events for gadgets? Or the name of the gadget?
    330) Can I set the foreground and background colors of gadgets (e.g., con-
    venience dialog buttons)?
    331) Can I use a gadget as the parent of a dialog shell?
    332) Which other widget features do gadgets lack?
    333) Where can I get the xmon or xscope programs to trace my X protocol?
    334) What does the error "Couldn't find per display information" mean?
    335) Can I set widget fallback resources after I've called XtAppInitialize()?
    336) Can I use the newline character in widget names?
    337) Is anybody out there selling Windows95 look-alike widgets?
    338) How can I convert my OLIT programs to the Motif look & feel?
    339) What does this mean: Warning: Cannot find callback list in XtAddCall-
    back?
    340) If a single widget has multiple callback functions, are they all execut-
    ed? If so, in what order?
    341) Why are some widgets still visible after I call XtDestroyWidget() on
    them?
    342) If I call XtGetValues on a resource that does not exist for a given
    widget, what value is returned?
    343) Can I reparent a widget (change its parent)?
    344) Are there any "year 2000" issues within Motif?
    345) Can I suppress or customize Motif warning and error messages?
    346) TOPIC: Motif FAQ HISTORY and ACKNOWLEDGEMENTS


    -----------------------------------------------------------------------------

    Subject: 0) TOPIC: SUBMITTING SUGGESTIONS, CORRECTIONS, NEW ANSWERS
    [Last modified: May 97]

    Answer: If you want to add to the FAQ, here's the procedure....

    If you have suggestions or corrections for any of these answers or any
    additional information, please send them to the e-mail address below. The
    information will be included in the next revision or two.

    o Send updates, suggestions, corrections, new answers to:
    kenton@nojunk.rahul.net (Ken Lee)
    X/Motif Consultant
    http://www.rahul.net/kenton/

    o _Please_ put "For Motif FAQ" in the Subject line!
    (This is the best way to catch my attention. Really.)

    o Please include answers with your FAQ questions.
    (If are looking for an answer to your questions, you may
    want to hire a consultant. My company can do e-mail consulting.)

    o For coding-related issues, I would prefer a short textual
    description of the your design rather than a long code sample.

    o If you do submit code, make sure it is well tested, portable,
    and robust.

    o If you _do not_ want your name or email address listed
    in the FAQ, explicitly state this.


    The information contained herein has been gathered from a variety of sources.
    In many cases attribution has been lost; if you would like to claim
    responsibility for a particular item, please let us know.

    -----------------------------------------------------------------------------
    Subject: 1) TOPIC: WHAT IS MOTIF?

    -----------------------------------------------------------------------------
    Subject: 2)* Is the Motif source code publically available?
    [Last modified: Jan 02]

    Answer: On May 15, 2000 the Open Group released the Motif source code for
    Motif 2.1, using a public license, to the Open Source community. On January
    29, 2002, Open Motif 2.2 was released.

    For more information on Open Motif, see:

    http://www.opengroup.org/openmotif/

    This web site includes the latest announcements, open source license details,
    a FAQ and other documentation, and allows you to download the Motif source
    code.

    Some other web sites dedicated to Open Motif are:

    http://www.motifzone.net/
    http://www.metrolink.com/openmotif/


    -----------------------------------------------------------------------------

    Subject: 3)* What is Motif and how does it relate to the X Toolkit and X
    Window System?
    [Last modified: Jan 02]

    Answer: Motif is a widely-accepted set of user interface guidelines developed
    by the Open Software Foundation (OSF) around 1989 which specifies how an X
    Window System application should "look and feel". Motif includes the Motif
    Toolkit (also called "Xm" or the "Motif widgets"), which enforce a policy on
    top of the X Toolkit Intrinsics ("Xt"). Xt is really a "mechanism not policy"
    layer, and Xm provides the specific "look and feel". For example, Xt does not
    insist that windows have titlebars or menus, but it provides hooks for
    developers of specific toolkits (Motif, OpenLook, Athena widgets) to take
    advantage of. In addition to widgets, Motif includes the Motif Style Guide
    document (as well as several others listed in my FAQ) which details how a
    Motif user interface should look and behave to be "Motif compliant".

    The X Toolkit Intrinsics are built upon the lowest programming level API
    called "Xlib" (X library). Both Xlib and Xt are specified by the Open Group
    (formerly called the MIT X Consortium), which you can reach at:

    http://www.camb.opengroup.org/tech/desktop/x/

    In early 1996, OSF merged with X/Open to form the Open Group. At the
    beginning of 1997, the X Consortium closed and transfered ownership of its
    projects to the Open Group. The Open Group continues development and support
    on the X Window System, Motif, CDE, and other technologies.

    On May 15, 2000 the Open Group released the Motif source code, using a public
    license, to the Open Source community. The current version of Open Motif 2.2,
    which was released January 29, 2002. For more information, see:

    http://www.opengroup.org/openmotif/
    http://www.motifzone.net/


    -----------------------------------------------------------------------------
    Subject: 4) Where did the name "Motif" come from?
    [Last modified: Jun 98]

    Answer: We had a contest inside of what was then The Open Software Foundation
    to name this thing that we had up to then called the UEC for User Environment
    Component. Lots of things were suggested, but Motif was suggested by one of
    the employees.

    Ken Flowers, k.flowers@opengroup.org

    FYI - in the art world, a motif is a recurring artistic symbol or theme. The
    meaning obviously carries over to the GUI world.

    Ken Lee, http://www.rahul.net/kenton/

    -----------------------------------------------------------------------------
    Subject: 5) TOPIC: OTHER RELEVANT NEWSGROUPS AND FAQS
    [Last modified: Aug 98]

    Answer: This newsgroup is "comp.windows.x.motif". The WWW URL is:

    news:comp.windows.x.motif

    Many other X-related newgroups and FAQs are available. For a full list, see

    http://www.rahul.net/kenton/xsites.framed.html


    -----------------------------------------------------------------------------
    Subject: 6) TOPIC: FAQ and NEWSGROUP FTP ARCHIVES

    -----------------------------------------------------------------------------
    Subject: 7) Is the FAQ available via FTP?
    [Last modified: Apr 98]

    Answer: The Motif FAQ is available as a large single file on Kenton Lee's web
    site:

    ftp://ftp.rahul.net/pub/kenton/faqs/Motif-FAQ
    ftp://ftp.rahul.net/pub/kenton/faqs/Motif-FAQ.gz
    ftp://ftp.rahul.net/pub/kenton/faqs/Motif-FAQ.html
    ftp://ftp.rahul.net/pub/kenton/faqs/Motif-FAQ.html.gz

    A number of FAQ's (including this one) are available via anonymous ftp at
    rtfm.mit.edu under the directory pub/usenet.

    The Motif FAQ is available in 9 parts via anonymous ftp in any of the
    following directories at rtfm.mit.edu:

    /pub/usenet-by-group/comp.windows.x.motif
    /pub/usenet-by-group/comp.answers/motif-faq
    /pub/usenet-by-group/news.answers/motif-faq

    There is also a mail server called mail-server@rtfm.mit.edu. To retrieve a
    file send mail to the server with a subject or body similar to

    send usenet/comp.windows.x.motif/Motif_FAQ_(Part_1_of_9).Z


    The Motif FAQ is also available via anonymous ftp as a single file:

    /contrib/faqs/Motif-FAQ from ftp.x.org.

    (See also "Is this FAQ accessible via WWW?")

    -----------------------------------------------------------------------------
    Subject: 8) Can I receive email notification when the Motif FAQ is updated?
    [Last modified: Sept 95]

    Answer: Yes! Simply follow this link to "The URL-minder: Your Own Personal Web
    Robot!"

    http://www.netmind.com/URL-minder/URL-minder.html

    and register the following ftp URL:

    ftp://ftp.rahul.net/pub/kenton/faqs/Motif-FAQ (text version)
    or
    ftp://ftp.rahul.net/pub/kenton/faqs/Motif-FAQ.html (HTML version)

    This free service is brought to you by Netmind at:

    http://www.netmind.com/


    -----------------------------------------------------------------------------
    Subject: 9) Is this FAQ accessible via WWW?
    [Last modified: Apr 98]

    Answer: You can access the HTML version of this FAQ from my web site, either
    uncompressed (600KB) or compressed (180KB):

    ftp://ftp.rahul.net/pub/kenton/faqs/Motif-FAQ.html
    ftp://ftp.rahul.net/pub/kenton/faqs/Motif-FAQ.html.gz

    A list of other web sites (including mirror sites around the world) carrying
    text and HTML versions of this FAQ is available at:

    http://www.rahul.net/kenton/mfaq.html

    Ken Lee

    Thanks to Greg Ercolano (erco@netcom.com) for providing an awk script that
    converts my Motif FAQ to HTML.

    -----------------------------------------------------------------------------
    Subject: 10)* Is this newsgroup archived?
    [Last modified: Nov 98]

    Answer: http://www.google.com/ archives several years of Usenet traffic.

    -----------------------------------------------------------------------------
    Subject: 11) TOPIC: OSF, MOTIF VERSIONS, CDE, COSE, DCE, The OPEN GROUP

    -----------------------------------------------------------------------------
    Subject: 12) How can I contact the Open Group?
    [Last modified: Aug 97]

    Answer: For more information on the Open Group, including a list of e-mail and
    telephone contacts, see their WWW home page:

    http://www.opengroup.org/


    -----------------------------------------------------------------------------
    Subject: 13) Where can I find OSF press releases on Motif and DCE?
    [Last modified: May 97]

    Answer: The Open Group web page:

    http://www.rdg.opengroup.org/press/titles.htm

    contains Motif and DCE press releases dating back to August, 1996.

    -----------------------------------------------------------------------------
    Subject: 14)* What versions of Motif are there?
    [Last modified: Jan 02]

    Answer: Motif 1.0 is based on the R3 toolkit. There are patch releases to
    1.0: 1.0.1, 1.0.A, 1.0.2 and 1.0.3, 1.0.4, 1.0.5. 1.0.A was a fairly major
    patch, as it involved a complete re-engineering of UIL and Mrm. Almost
    everyone who has 1.0.x has either 1.0.A or 1.0.3.

    Motif 1.1 is based on the R4 toolkit. The intial version was Motif 1.1.0.
    Motif 1.1.1 has been released as a patch to licensees with Full Support or
    Technical Update service. Motif 1.1.2 is a patch release which contains the
    necessary changes to fix over 80 bugs reported against Motif. It is available
    to support contract holders (including both full support and update service).
    The 1.1.3 release fixed a further 150 bugs and was available from August 1991
    to support contract holders (including both full support and update service).
    1.1.4 offers X11R5 support, but is not an X11R5 product. 1.1.5 was released
    in June 92 to licensees who hold a Motif Full Support or Update Support
    contract

    Motif 1.2.0 was released in April 1992 and is based on the X11R5 toolkit. It
    offers increased compatibility with international standards, PC-style
    behavior and binary compatibility with Motif 1.1 applications. New features
    include drag-and-drop, tear- off menus, toolkit enhancements and new
    documentation. toolkit. The code is totally ANSI C.

    Motif 1.2.1 was released September, 1992. Due to an optimisation from 1.2.0
    to 1.2.1 object code compiled under 1.2.1 (that is, using 1.2.1 header files)
    will not link with 1.2.0 libraries (and, very probably, clients that use
    shared libraries and are linked against 1.2.1 won't startup against 1.2).

    Motif 1.2.2 was released March, 1993. This release contains over 250 bug
    fixes, improved text, drag-and-drop features and has less than one reported
    defect per 1000 lines of code.

    from dbrooks@osf.org Motif 1.2.3 was released on September 13, 1993. The
    defect density is measured at < 0.8 known reports per thousand lines. In this
    release, we have paid particular attention to memory leaks, and have improved
    drag-and-drop performance greatly.

    Motif 1.2.4 was released April, 1994. from the OSF README: This patch release
    contains approximately 240 bug fixes for Motif 1.2. The number of CRs resolved
    in this release is about 330....Apart from the 64-bit changes, all changes
    made in this release are fixes for reported bugs.

    Motif 2.0 was released in August, 1994. For details, see the questions "Is
    there a concise features list for Motif 2.0?" and "What are the details about
    new features in Motif 2.0?" Due to binary compatibility problems, this
    release was not very popular with UNIX vendors.

    Motif 1.2.5 was released June 15, 1995 ONLY to OSF Motif Support Licensees as
    part of their maintenance agreement. Motif 1.2.5 includes minor enhancements
    to support CDE 1.0. Vendors not supporting CDE generally ignored this release
    and continued to use Motif 1.2.4.

    Motif 2.1 was released February 5, 1997. For details, see the questions "Is
    there a concise features list for Motif 2.1?"

    Open Motif 2.2 was released January 29, 2002. For details, see the questions
    "Is there a concise features list for Motif 2.2?"

    -----------------------------------------------------------------------------
    Subject: 15)* How can I find which version of Motif I have? Xlib or Xt
    version?
    [Last modified: Jan 02]

    Answer: The macro XmVERSION gives you the version number. The macro
    XmREVISION gives you the major revision number. The macro XmVersion combines
    these e.g. a value of 1002 is Motif 1.2. In Motif 1.2, the macro
    XmUPDATE_LEVEL was added to give the minor revision number (also known as the
    patch level).

    To find the version of a compiled Motif library:

    grep XmVERSION_STRING libXm.a

    To find the Motif version at run-time, use the global variable:

    xmUseVersion

    Ken Lee adds the following for determining the Xlib and Xt version:

    X11/Xlib.h should have macros like this:
    #define XlibSpecificationRelease 6
    meaning X11R6.

    Similarly, X11/Intrinsic.h has this in X11R6:
    #define XtSpecificationRelease 6


    -----------------------------------------------------------------------------
    Subject: 16) Is there a concise features list for Motif 2.0?
    [Last modified: Sept 94]

    Answer:

    New widgets

    ComboBox.
    Notebook.
    Container/IconGadget.
    SpinBox.
    CSText.

    New features

    Thermometer Scale and tic marks.
    ScrollBar sliding/arrow and snapback modes.
    ScrolledWindow autoscroll and childType.
    Toggle indeterminate state and new visual.
    Colors in Gadgets.
    XmIm API for I18N.
    XmNlayoutDirection resource everywhere.
    Natural UnitType conversion syntax.
    XPM3 (colored icon) format support.
    The Uniform Transfer Model.
    General Rendition attributes in XmString (color, multiple fonts, etc)
    Several Display resources for CDE visual/behavior compatibility.
    New FileSelectionBox mode (again from CDE).
    Quick navigate in List.
    Oriented PanedWindow.
    Popup menus support.
    and much more...

    Extensibility

    Traits.
    C++ foundry.
    Widget writer doc.
    Exm widget source examples.
    Xme API (useful _Xm).

    Desktop

    Virtual MWM.
    Workspace Manager.
    TearOff menu in MWM.
    Client Command Interface.
    Colored icon pixmaps (from Xm).

    Performance & Quality

    No known Memory Leaks.
    XmString sharing.
    XmList creation/setup speedup.
    GC usage improved.
    Malloc/free usage.
    Bitmap allowed for pixmap resources.
    XmManager no longer blindly selects for PointerMotion
    XmFileSelectionBox better stat cache.
    Broader use of Hash tables.
    Better link profile (Trait + remodularization).
    X11R6 unofficial support.
    Hundreds of bug fixes.


    -----------------------------------------------------------------------------
    Subject: 17) What are the details about new features in Motif 2.0?
    [Last modified: Aug 97]

    Answer: (See the previous question for a more compact features list.)

    NOTE: This is a posting by Douglas Rand that was composed by
    one of the OSF business managers, Darrell Crow (crow@osf.org).
    OSF also published a nice technical overview in the X Journal.
    A copy of that report is available on-line at:
    http://www.opengroup.org/tech/deskto...f/xjournal.htm

    Date: 11 Jul 94 15:49:27 GMT
    From: (Douglas Rand)
    Organization: Open Software Foundation
    Subject: Motif 2.0 announcement
    To: uunet!lobo.gsfc.nasa.gov!motif

    The following was composed by one of our business managers, Darrell Crow
    (crow@osf.org), questions may be directed to him.

    ----------------------------------------

    With this posting I hope to answer many questions I've been receiving
    regarding what is in Motif 2.0 and how does if differ from Release 1.2. This
    posting contains an overview followed by a bullet item listing of the features
    and benefits added to Motif in this release. If I didn't answer your questions
    feel free to direct them to me. At the end, I'll list additional
    documentation available from OSF. If you're also interested in the licensing
    and pricing information you can also contact me or the official OSF/Motif
    channel: direct@osf.org. I hope that this information update is of benefit to
    you.

    OSF/Motif has become the major Graphical User Interface (GUI) technology for
    Open Systems, as well as an IEEE 1295 standard. On Tuesday, June 21, OSF
    announced its next major release of OSF/Motif, Release 2.0. This release,
    which is the most extensive and colaborative release of Motif since Motif 1.0
    was introduced five years ago, includes new features organized around four
    major themes:
    I. Extensibility,
    2. Consistency,
    3. Improvements and
    4. CDE Convergence.

    Motif 2.0 was a collaborative development effort. Contributors to this
    release include Lotus Development, IBM, Hewlett-Packard, Digital Equipment,
    Integrated Computer Solutions, Computer Automation, Groupe Bull, HaL Computer
    Systems and Unix Systems Laboratories.

    This release had the goal of allowing developers to easily build new widgets
    and with support for C++ . This required new extensible features such as
    subclassing, traits, C++ support and detailed documentation. Like all Xt-
    based toolkits, subclassing requires detailed knowledge, experience and access
    to the source code to fully understand Motif's class methods. Motif 2.0
    simplified this process by providing extensive documentation and allowing
    subclassing from the Primitive and Manager classes without requiring access to
    source code. Documentation of Motif's class methods are included in a new
    book, The OSF/Motif Widget Writer's Guide. This book provides all necessary
    information to subclass from Primitive and Manager and numerous examples of
    subclassing are provided. Traits are a new feature with Motif 2.0 which
    essentially allow a given behaviour to be associated to a widget irrespective
    of the widget hierarchial relationships. The number of applications developped
    in C++ is rapidly growing and C++ programmers are now able to derive new
    subclasses and still have those C++ widgets usable as regular widgets with the
    standard API in Motif 2.0

    CDE (Common Desktop Environment) convergence. The previous version of
    OSF/Motif (Release 1.2) introduced major new features such as
    internationalization, drag-and-drop and tear-off menus. Those features were
    intended to allow application developers to produce interoperable, easy to use
    applications for a worldwide market. As a result, this technology was selected
    to become the basis of the Common Desktop Environment jointly developed by HP,
    IBM, Novell and SunSoft, proposed to become an X/Open standard. These features
    as well as the GUI extensions added to the CDE specifications have been added
    to Release 2.0.

    PC Consistency has been a major theme of this release. This includes
    improvements and completions to the toolkit that was begun with Motif 1.2 as
    well as the addition of seven new widgets (Container, Notebook, icon gadget,
    spinbox, combobox, CSText and thermometer) common to this environment and
    finally a new Style Guide. Extensive work has been expended to ensure the
    convergence of the Windows, CUA, CDE and Motif style both in technology and
    terminology into a single document. The work for this book will be submitted
    to the X/Open Fast Track process for incorporation into the X/Open set of
    specifications.

    Improvements to the OSF/Motif toolkit are far too numerous to adequately list
    here. However a brief mention of a few of the major improvements includes the
    addition of the Unified Transfer Model that simplifies data transfer by all
    Motif's previous methods, XPM support (ability to read colored icon file for
    pixmap resources), ScrolledWindow partial scroll and autodrag,Toggle
    checkmark, indeterminate state, documenting the input methods API for
    internationalization, upgrading UIL to support 64-bit architecture, platform
    independence, and support of the new extensibility features and widgets, and
    finally the Motif Window Manager support of virtual screen, workspace
    management protocol and root menu additions and etc.

    This release brings together the most requested features from development
    community with the single purpose of extending application developers' mission
    of producing portable, consistent and interoperable applications to the open
    systems community.

    Listing of the OSF/MotifR 2.0 Features and Benefits

    I. MORE EFFICIENT APPLICATION DEVELOPMENT

    Easier application development to meet new business opportunities and deploy
    applications faster...

    Benefit Allows easier extensions to Motif for custom user


    Features:
    * New, formal Xme API for integrating custom widgets interfaces,
    without access to Motif source code
    * All extensions using Xme API are "full citizens"
    * Widgets may be added to off-the-shelf Motif products, without
    recompiling Motif source code
    * Manager and primitive widget subclassing
    * C++ base classes provided for C++ widget development
    * C++ is used for inheritance, but X intrinsics are used for other
    characteristics
    * Trait mechanism for OSF/Motif widgets, allowing "multiple
    inheritance" of C class methods
    * Extensibility fully documented in Widget Writer's Guide, and
    Reference documentation
    * New OSF training: Widget Writing with Motif 2.0
    * Examples of custom widgets in C and C++

    Feature:
    Makes it easier for C++ developers to use Motif

    Benefit:
    * Motif source code compilable by C++ compiler
    * Ability to integrate C++ widget extensions (above)

    Feature:
    Allows easier exploitation of Motif features for end user benefits

    Benefit:
    XmNotebook
    * Subclass of XmManager
    * Organizes children into pages, tabs, status area and page scroller
    XmContainer
    * Subclass of XmManager
    * Manages IconGadget children
    XmIconGadget
    XmComboBox
    * Subclass of XmManager
    * Combines capabilities of a single line
    XmTextField and XmList
    XmSpinBox
    * Subclass of XmManager
    * Manages multiple traversable children
    XmScale (thermometer) widget
    * Subclass of XmManager
    * New resources added for thermometer behavior
    XmCSText
    * Subclass of XmPrimitive
    * Provides facilities which parallel XmText, but using XmString

    Uniform transfer model for primary transfer,
    * secondary transfer, cut and paste, drag and drop
    Uniform API (with backward compatibility)
    2 new callback functions for target identifcation

    Misc. toolkit enhancements:
    * Menu system
    Simplified programming of popup menus
    Source code reorganization
    * X pix map (XPM) format, with multicolor icons

    Misc. toolkit enhancements (continued):
    * New rendering characteristics for XmString:
    renditions (fonts, color), tabs, localization
    components, parsing
    * List -- Quick navigate
    * Traversal -- drawing area traversable via keys,
    virtual key associated with multiple real keys
    * Visuals (in addition to Toggle Button)
    * XmScreen resources
    * Resolution independence -- unit conversion

    UIL enhancements:
    * Support for new and custom widgets
    * UID files -- platform independence
    * 64-bit architecture support

    Updates to documentation: Programmer's Guide, Reference

    Updates to OSF training:
    * Introduction to Programming
    * User Interface Design
    * 2.0 Technical Update

    Feature:
    Allows easy integration of applications with Common Desktop
    Environment (CDE)

    Benefit:
    * Contains foundation GUI for CDE
    * Client-command interface allowing other clients to add commands to
    MWM menus

    Feature:
    Allows easy migration of applications to Motif 2.0

    Benefit
    * Upward binary compatibility of Motif 1.2 toolkit API
    (Motif 1.2 applications need only re-link)

    Feature
    Makes applications easier to troubleshoot & maintain

    Benefit
    * Overall quality improvements in Motif
    * Default density lower than 0.5 DPKLOC

    EASE OF USE

    Ease of use by individual computer users... at the application user
    interface level...

    Feature:
    Satisfies rising user expectations for ease of use, leveraging
    experience with other user interfaces

    Benefit:
    User interface capabilities equivalent to those on PCs:
    * Notebook widget
    * Container widget
    * ComboBox widget
    * SpinBox widget
    * Scale (thermometer) widget
    * Availability of formatted editable text
    Compound String text widget
    Compound String enhancements to support color, tabs, multiple
    fonts, etc.
    * Auto Scrolling
    * Vertical Paned Window
    * Update to User Guide

    Ease of use by individual computer users... at the desktop level...

    Feature:
    Allows easier integration with the desktop

    Benefit:
    * Contains foundation GUI for Common Desktop Environment (CDE)
    * Tear-off menu support of mwm's root menu

    Feature:
    Allows more natural organization of users' work

    Benefits:
    * Virtual screen (desktop panning) support
    * Workspace management protocol
    (for third party workspace management solutions that
    allow users to switch computing context "rooms" for
    different tasks)

    EASE OF ENTERPRISE COMPUTING

    Easier integration of Motif and Motif applications into the
    enterprise computing environment...

    Feature:
    Increases consistency of user interface style across platforms &
    applications; increases user skill portability

    Benefits:
    * Motif 2.0 Style Guide work Technical and terminology convergence
    among Motif, CDE and CUA
    * New widget support of converged style
    * Increased similarity to Windows & CUA behavior:
    Check marks and crosses in Toggle Button
    Indeterminate state in Toggle Button
    Ctrl Button 1 takes focus
    Menu unpost behavior
    Quick navigate in list

    Feature:
    Increases consistency of a complete user environment across open
    systems

    Benefits:
    * Consistency with the X/Open CDE specification, including virtually
    all CDE Motif vendor extensions:
    XmCascadeButton activation via BMenu
    Enhanced XmFileSelectionBox
    Default XmNshadowThickness to 1
    Thermometer-style XmScale
    Color pixmaps in XPM format
    Additional virtual key bindings
    SpinBox, ComboBox
    Message catalogs for toolkit error messages
    Other items controlled by a global resource:
    ColorObject (standarizes colormap allocation for
    applications, to enable use of Style Manager application)
    BSelect and BTransfer integration
    Dragging non-selectable items disabled
    Use of TAB key -- XmPushButton navigation
    Visual additions to XmToggleButton
    Visual modifications to menus (etched in)
    Visual modifications to default button in dialogs (focus
    highlight outside of default visual)
    Visual modifications to MWM
    Additional drag icons
    * Compliance with IEEE 1295 standard
    * Consistency of Motif vendor implementations:
    AES Rev D for API stability
    Validation Test Suite 2.0 for certification
    Updated Quality Assurance Test Suite for consistency in
    quality
    * Continued support of the X Window system (based on
    * X11R5; tested also with X11R6 )

    Feature:
    Ease of integrating Motif and PC environments

    Benefits:
    * Favorable licensing terms to support:
    PC client-server computing
    Deployment of PC applications using Motif DLLs
    * Style convergence to support hybrid user environments


    WORLD-WIDE ACCEPTANCE

    Even more acceptable as the preferred user interface for Open Systems,
    worldwide...

    Feature
    Applicable to a wider range of computer users

    Benefits:
    * Internationalization enhancements:
    New API for widget writers to make use of input methods
    Higher level of internationalization for Middle Eastern
    languages:
    Bi-directional layout -- left-to-right/right-to-left geometry
    management
    Bi-directional text editing -- left-to-right/right-to-left,
    single level (unsupported)
    * 64-bit architecture support
    * Favorable licensing terms to support:
    Single user systems
    Embedded systems
    Cross-vendor Motif upgrades
    Shared library distribution with applications
    * Performance
    Memory usage
    Start-up time, for list widget
    Decreased X resource usage
    Various optimizations

    ADDITIONAL AVAILABLE DOCUMENTS FROM OSF.
    OSF/Motif 2.0 Datasheet
    OSF/Motif 2.0 Price List
    OSF/Motif 2.0 Licensing Kit
    OSF/Motif 2.0 Laymen's Explanation
    OSF/Motif 2.0 FAQ
    X/Journal July-August Feature Article on Motif 2.0

    FOR MORE INFORMATION ABOUT OSF/MOTIF 2.0, PLEASE CONTACT OSF DIRECT CHANNELS
    AT: (617)621-7300; email: direct@osf.org

    OSF and Motif are registered trademarks of the Open Software Foundation, Inc.

    [end of message from Darrell Crow (crow@osf.org)]

    -----------------------------------------------------------------------------
    Subject: 18) Is there a concise features list for Motif 2.1?
    [Last modified: Aug 97]

    Answer: The Open Group's press release for Motif 2.1 is available at:
    http://www.rdg.opengroup.org/press/5feb97.htm

    A technical report is also available at:
    http://www.opengroup.org/tech/deskto...data.sheet.htm

    The major differences from Motif 2.0 are:

    1) The CS text widget from Motif 2.0 is not included.

    2) Motif 2.0 word-size independent UID files are no longer supported. Only
    the Motif 1.2 word-size dependent format is supported.

    3) To promote convergence with dtwm, mwm's panning, virtual screen, and
    workspace features have been removed

    4) Support was added for the X print server, including a new print dialog
    widget

    5) The Motif libraries are now thread-safe (if the underlying libraries and
    system are also thread-safe)

    6) Several internationalization features were added, including an on-the-spot
    input method and vertical text writing

    7) Motif 2.1 is based on X11R6.2 and will work properly with X11R6.3

    -----------------------------------------------------------------------------
    Subject: 19)+ Is there a concise features list for Motif 2.2?
    [Last modified: Jan 02]

    Answer: The Open Group's press release for Open Motif 2.2 is available at:

    http://www.opengroup.org/openmotif/openmotif-2.2.html

    OpenMotif 2.2 updates OpenMotif 2.1.30. The major change is the addition of
    10 new widgets:

    1) XmButtonBox
    2) XmColorSelector
    3) XmColumn
    4) XmDataField
    5) XmExt18List
    6) XmFontSelector
    7) XmIconBox
    8) XmIconButton
    9) XmTabStack
    10) XmTree

    In addition, a ToolTips feature is implemented within the XmPrimitive and
    XmGadget classes.

    ---------------------------------------------------------------------------
    END OF PART ONE

  2. Motif FAQ (Part 2 of 9)

    Archive-name: motif-faq/part2
    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: 20) Where can I find Motif 2.1 documentation?
    [Last modified: Mar 98]

    Answer: A full listing of current Motif and CDE manuals in book form is
    available at http://www.opengroup.org/pubs/catalog/mo.htm

    -----------------------------------------------------------------------------
    Subject: 21)* Is the official Motif documentation available on-line?
    [Last modified: Jan 02]

    Answer: Open Motif documentation in PDF and PostScript formats is available
    at:

    http://www.opengroup.org/openmotif/docs/

    The O'Reilly Motif tutorial books are available at:

    http://www.ist.co.uk/NEWS/archive/motifbooks.html
    http://www.oreilly.com/openbook/motif/

    Here are some Russian translations of the Motif manuals:

    http://motif.hut.ru/

    For other on-line Motif documentation, please see:

    http://www.rahul.net/kenton/xsites.framed.html


    Ken Lee, http://www.rahul.net/kenton/

    -----------------------------------------------------------------------------
    Subject: 22) I want to use C++ with Motif. Where can I find C++ examples?
    Motif 2.0 supports native C++ classes but I can't find documentation.
    [Last modified: Sept 95]

    Answer: Doug Rand writes: "There are some examples in the
    demos tree, look under demos/lib/ExmCxx for widget examples. The C++ support
    was only a widget writer's tool. When the widget writer's guide is out, you
    can also look in that for documentation."

    Scott W. Sadler replied to a related question about combining
    Motif with C++: "There are two books available (that I know of):

    Object-Oriented Programming with C++ and OSF/Motif - Second Edition
    Doug Young 0-13-209255-7 (c) 1995

    Using Motif with C++
    Daniel Bernstein 0-13-207390-0 or 1-884842-06-2 (c) 1995"

    See also the subject: "Is there a C++ binding for Motif?"

    -----------------------------------------------------------------------------
    Subject: 23) Is Motif 2.0 backward compatible with Motif 1.2? Does a program
    written for Motif 1.2 compile and run with Motif 2.0?
    [Last modified: Jan 96]

    Answer: (See also the next subject.) Doug Rand writes: "It is
    backward compatible except where it isn't

    1) Subclassed widgets which do not use XmResolvePartOffsets won't work.

    2) If you free your XmStrings using any technique other than XmStringFree, it
    is quite likely that your program either won't compile, or will crash with a


    core dump at runtime. [Wording change for (2) provided by Alan Ezust
    (ezust@learnix.ca).]

    3) If you use libMrm and relink with the new shared library, you'll need to
    make the new modern .uid files (but if you wait for the Motif from CDE you
    don't need to do this one).

    4) If you assume that XmStrings are ASN.1 strings and play with them, it won't
    work. They are now data structures. But the good news is that XmStringCopy
    just increments a reference count now.

    Note that #1 and #2 where always documented this way and aren't supposed to
    work.

    Otherwise, it's pretty compatible. We relinked a number of things and they
    continued fine. [These] include xrn (Motif), and a couple of other moderately
    big things. I want to say we did xmosaic, but I can't remember if I'm right
    about that.

    #1 isn't a problem if you recompile your subclassed widgets. But then there
    is a source compatibility problem that you may need to include the obsolete
    modules for the _Xm functions. Proper 2.0 subclasses use Xme functions, and
    there is even a document."

    -----------------------------------------------------------------------------
    Subject: 24) How compatible are Motif 1.2.* and X11R6?
    [Last modified: July 96]

    Answer: (See also the previous subject.) This is actually several related
    questions with answers from David B. Lewis (d.lewis@opengroup.org) and Kenton
    Lee (http://www.rahul.net/kenton/).

    1. Is it possible to run an X11R6 server with a Motif 1.2.* runtime
    environment (Motif libs and Motif Window Manager)?

    David> Yes. The X11 protocol has not changed in its various versions, so
    all X servers are compatible. There are differences, though, in
    the fonts that are available and in a few of the gray areas in the
    interpretation of the protocol. The fonts distributed by the X
    Consortium form a standard set, though, and I know of no cases in
    which changes in X11R6 cause problems for Motif programs (we are
    using Motif with X11R6 servers here).

    2. Is there any possible conflict with Motif 1.2.* applications and an
    X11R6 server (assuming a Motif 1.2.* runtime environment)?

    David> The only situation that I could imagine is a case in which Motif
    1.2 code was written to depend on a particular bug or behavior of
    an X11R5 server; I know of no such cases. Because of the stability
    of the X11 protocol, Motif 1.2 programs should work with any
    available X server, current and future.

    3. If Motif 2.0 is installed such that the Motif libraries and mwm are
    versions 2.0, is there 100% binary compatibility with statically linked
    Motif 1.2.* applications? If not, what are the known or potential problems?

    David> There are additional support files in both the Motif and X11 areas
    which are used at run-time. There are no known problems using Motif
    1.2 *static* applications in a Motif 2.0 environment.

    Kenton writes: R6 was designed to be backwards binary compatible with R5 and
    most vendors have done a good job in implementing this. Still, I wouldn't
    recommend that my customers do this until I tested configurations similar to
    theirs.

    Motif 2.0 is backwards compatible with Motif 1.X in most cases. I think Doug
    Rand's comments in [the previous subject of the Motif FAQ] covers the
    important issues. In general, well written applications shouldn't have
    problems, but some applications aren't well written. Again, I would test
    before making recommendations to my customers.

    The above comments apply to run-time linking (shared library) compatibility.
    If you statically link, the only problems I can imagine are the common ones
    like installed fonts, supported server extensions, input methods, color name
    databases, default visual types, etc.

    -----------------------------------------------------------------------------
    Subject: 25) Why aren't the big UNIX vendors shipping Motif 2.0?
    [Last modified: Aug 98]

    Answer: Most of these companies decided to move to CDE 1.0 first. CDE 1.0
    uses Motif 1.2.5, which is not binary compatible with Motif 2.0.

    Motif 2.1 was released in February, 1997. Motif 2.1 is compatible with CDE
    2.1 and (mostly) Motif 1.2. You should expect the big UNIX vendors to start
    shipping Motif 2.1 when they start shipping CDE 2.1.

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 26) Where can I get Motif for UNIX, Linux, or Microsoft Windows?
    [Last modified: Jun 98]

    Answer: A regularly updated list of Motif vendors for various operating
    systems (including Linux and Microsoft Windows) is available at:
    http://www.rahul.net/kenton/GettingMotif.html

    Please send any corrections to kenton@nojunk.rahul.net

    -----------------------------------------------------------------------------
    Subject: 27) Is there a list of Motif bugs?

    Answer: With each patch release of Motif shipped, there is a list of known
    bugs provided. The filename on the tape is "./OPENBUGS". There is also a
    list of all the issues closed/resolved in that patch. That is found as part
    of the "./README-1.1.n" (where n is the patch number) file.

    These are the only OSF published lists.

    No one else seems to publish a list.

    -----------------------------------------------------------------------------
    Subject: 28) Where can I get a Motif 1.2 Certification Checklist?
    [Last modified: Apr 95]

    Answer: Kevin Till (kev@osf.org) of OSF wrote: "The Checklist comes with the
    OSF/Motif 1.2 Style Guide documentation. It's in the Appendix B section."

    -----------------------------------------------------------------------------
    Subject: 29) What is CDE? What is COSE and how does it relate to Motif?
    [Last modified: Sept 94]

    Answer: [For more current information, see also the subjects which follow
    this one.]

    NOTE: This info dates back to a Nov. '93 conference.
    Most of the words should be credited to the lecturer,
    Nicholas J. Aiuto (nick@ps.quotron.com) of Cadence Design Systems, Inc.
    Any mistakes or inaccuracies are mine, however.
    I would appreciate updates and corrections...kenton@nojunk.rahul.net

    COSE is Common Open Software Environment, a major interoperability effort
    started by HP, Sun, Novell/UNIX System Labs (USL), IBM, and SCO, with over 70
    other companies pledging their support. The COSE announcement was made in
    March, 1993 and a "COSE CDE Conference" was held in San Jose in October, 1993.

    CDE is the Common Desktop Environment component of COSE. CDE is "a
    specification for components and services to give the UNIX desktop common and
    consistent capabilities like those found in other widely used environments
    (Mac, Windows)." [from class notes] CDE is not public domain; it will be
    provided by major vendors, possibly at extra cost as unbundled s/w
    approximately mid 1994. CDE will be based on Motif 1.2 and X11R5, although
    Motif 2.0 and X11R6 are expected around the same time. (CDE will be ported to
    Motif 2.0 eventually.)

    A CD-ROM was distributed at the October, 1993 conference, but this was "alpha"
    s/w, strictly for evaluation purposes, not for development.

    Another COSE/CDE Snapshot CD-ROM was released in April '94, available for HP,
    IBM, Novell, and Sun platforms.

    Overview
    --------

    Standards are to be defined in these areas:

    - desktop
    - networking
    - objects
    - graphics
    - system management

    CDE Functional Groups:

    High Level:
    - Desktop Management
    - Productivity Tools

    Low Level:
    - GUI Display and Printing
    - Application Integration
    - "Guidelines": a 100+ pg. checklist which is a superset of Motif's

    CDE Desktop Management
    ----------------------

    - Login Manager: like xdm
    - Session Manager: saving state based on ICCCM and HP's VUE [vuesession]
    - Workspace Manager: virtual screens; rooms; virtual win mgr
    - Front Panel: object and window management; access to favorite apps
    - File Manager: icon drag and drop
    - Application Manager
    - Style Manager: configure Session Mgr (colors, fonts, HOME session)

    Productivity Tools
    ------------------

    - Text Editor: based on XmText widget; not very fancy
    - Icon Editor: color pixmaps; based on HP's vueicon; need 16 icons per app
    - Help Viewer: can access app help without running application
    - Mailer and Calendar: can talk to each other
    - Terminal Emulator: improvement on xterm
    - Calculator
    - Create "Action": something you tell your system to do and associate with
    a specific icon (e.g., starting a favorite app); can also
    tag a specific command line and add to your desktop

    GUI Display and Printing
    ------------------------

    - Motif 1.2 with extras, X11R5
    - New widgets (subclasses of similar widgets to be in Motif 2.0):
    o ComboBox
    o SpinButton

    - dtksh: windowing Korn shell, a robust UNIX shell interface to X, Xlib, and
    Xm
    - Application Builder: port of Sun's DevGuide [not yet available]
    - X Print Server and X Server Print Extension

    Application Integration
    -----------------------

    - Data Interchange
    o Drag and Drop (DND): based on Motif 1.2 with improvements
    o Bento container format:
    "Japanese lunchbox"
    compartmented container developed by Apple;
    stores compound document on disk;
    apps can find audio compartment, for example
    100-page document describes Bento
    - ToolTalk
    o messaging/IPC facility developed by Sun
    o CDE message sets (sample msgsd: iconify yourself, close down, etc.)
    - Actions
    o define what can be done with files or arbitrary data (e.g., audio)
    - Data Typing
    o define data classes for objects (e.g., PS file, C source code)

    Guidelines
    ----------

    - Common Fonts (about 16): proportional, monospaced, with or without serif
    - Internationalization (I18N) compliance
    - Client/Server
    o Network execution model
    o end user model
    o system admin model: facilitates easy installation of new
    CDE-compliant apps
    o ISV model
    - Certification Checklist: 100 pages; superset of Motif 1.2 Certif. Checklist


    -----------------------------------------------------------------------------
    Subject: 30)* Is there a CDE FAQ or newsgroup?
    [Last modified: Aug 2001]

    Answer: The CDE FAQ is located at:

    http://www.laxmi.net/cde.htm

    There is also a newsgroup called news:comp.unix.cde

    -----------------------------------------------------------------------------
    Subject: 31) What is the current version of CDE and what are its features?
    [Last modified: May 97]

    Answer: The latest version of CDE is 2.1 as announced by OSF in February 1997.
    The following is the Open Group's press release:


    FOR IMMEDIATE RELEASE CONTACT
    Jane Smeloff
    The Open Group
    (617) 621-8997
    j.smeloff@opengroup.org

    Marilyn Kilcrease
    Fleishman Hillard, Inc.
    (415) 356-1031
    kilcream@fleishman.com

    The Open Group Announces Common Desktop Environment 2.1

    New features enhance the functionality and ease of use of the widely used
    graphical user interface for open desktop computing


    CAMBRIDGE, Massachusetts (February 5, 1997) - The Open Group, the leading
    organization for the advancement of open systems, today announced the release
    of CDE 2.1, the latest version of The Open Group's Common Desktop Environment.
    The current release integrates the Motif 2.0 graphical user interface, X
    Window System, and CDE to standardize application presentations in distributed
    multi-platform environments.

    "As a result of solid cooperation among project participants, we are
    delivering significant new features which makes CDE and Motif a unified face
    for UNIX environments," said Dave Lounsbury, vice president of collaborative
    development. "The CDE 2.1 project was the most extensive collaborative
    development effort in the history of The Open Group."

    The latest release of CDE features enhanced tools for creating integrated
    graphical desktop applications. New features include thread-safe libraries,
    64-bit system support, an X-based printing solution that implements a standard
    way of printing from any application, an enhanced, SGML-based on-line help
    system with a complete documentation set, "on the spot" input, and user-
    defined characters for Asian languages. Many capabilities have been added to
    ease programming, including traits, which enable user interface objects to
    automatically inherit multiple API specifications, and a uniform transfer
    model, which offer developers a consistent means of coding the different
    data-transfer mechanisms (such as cut-and-paste and drag-and-drop). The new
    release also provides a simple means of coding pop-up windows.

    CDE 2.1 also incorporates Motif 2.0 user interface objects (widgets) spin box,
    combo box, container, and notebook. With this release, the style guides for
    CDE and Motif converge.

    The fee for a CDE 2.1 full-distribution source code license is $40,000. An
    evaluation copy of source code costs $5,000. To order CDE 2.1, contact Open
    Group Direct, at 1-800-268-5245, or send e-mail to direct@opengroup.org.

    Introduced in 1995, CDE was jointly developed and licensed by Hewlett-Packard,
    IBM, Novell, and SunSoft. Since that time, the technology has evolved within
    The Open Group's Pre-Structured Technology (PST) process, a multi-vendor
    technology development program. Currently, Hitachi, Fujitsu, Digital Equipment
    Corporation and SCO work with the original CDE sponsors, IBM, HP and SunSoft
    within the Open Group's PST framework, to provide for the maintenance of CDE
    and the development of new releases.

    The Common Desktop Environment is a graphical user interface that delivers
    consistency and ease of use to system administrators as well as end users.
    With CDE, system administrators gain a degree of control over the desktop
    computing environment that has often been lost in the move from centralized to
    client-server or distributed computing. CDE gives end users access to the
    power and flexibility of today's networked desktop systems.

    The Open Group

    Dedicated to the advancement of multi-vendor information systems, The Open
    Group is an international consortium of systems and software vendors and
    customers from the industry, government and academia. The Open Group and its
    members work together to strengthen and streamline the development process and
    availability of open systems. The organization provides a focal point for the
    development of international specifications and test suites, standards based
    technologies, advanced open systems research, professional services and the
    management of the internationally recognized brand for open systems. The Open
    Group's brand mark is recognized worldwide and is a guarantee of compliance to
    open systems specifications. The Open Group is Headquartered in Cambridge, MA,
    with European headquarters in Reading, England and offices in Menlo Park, CA;
    Brussels, Belgium; Grenoble, France; and Tokyo, Japan.

    The Open Group is a trademark of the Open Software Foundation, Inc. and X/Open
    Company Ltd. OSF/Motif and Motif are registered trademarks of The Open Group.
    X Window System is a trademark of The Open Group and the X Consortium is a
    trademark of The Open Group. UNIX is a registered trademark in the US and
    other countries, licensed exclusively through X/Open Company Ltd. All other
    products or company names mentioned are used for identification purposes only,
    and may be trademarks of their respective owners.

    -----------------------------------------------------------------------------
    Subject: 32) How does Motif relate to X/Open and CDE?
    [Last modified: Mar 96]

    A. NOTE: This answer from Sept. 1995 is somewhat obsolete due to the
    formation of The Open Group. See "What is The Open Group?"....ksall@cen.com

    From OSF's CDE/Motif Program Manager, Terry Landers (landers@osf.org):

    "In response to the discussion [on comp.windows.x.motif] of Motif and
    "officially supported" APIs ... two areas were brought up that I hope to be
    able to clarify.


    Standards:
    =========
    As you probably know, Motif has become an X/Open standard.
    The X/Open specification was based on the OSF AES, and going
    forward the X/Open specification will take precedence.

    As part of the CDE/Motif PST, interface extensions to
    the XMotif specification will be proposed to X/Open.

    Although it is too early to discuss what will be proposed
    to X/Open, OSF members who are interested will have early
    access to CDE/Motif functional specifications as part of
    the Desktop SIG activities.

    Convergence:
    ===========
    OSF has taken the first step in convergence with the release
    of Motif 1.2.5. Motif 1.2.5 merges OSF Motif 1.2.4 with
    CDE Motif and defect fixes to the 1.2 code base that were
    made in Motif 2.0.

    The next step in convergence will come with the CDE/Motif PST
    deliverables.

    I hope this has helped ... if you have any questions you can
    contact me at:

    landers@osf.org
    617-621-7282"


    -----------------------------------------------------------------------------
    Subject: 33) What is The Open Group?
    [Last modified: Aug 97]

    Answer: On February 14, 1996, X/Open and OSF merged to form "The Open Group".

    which calls The Open Group a "New Organization to Improve Coordination of
    Efforts to Develop and Implement Common Standards and New Technologies". You
    might also want to read other press releases from The Open Group and visit
    their home page:

    http://www.opengroup.org/

    Below is the announcement sent by OSF's Kristen Knotts...ksall@cen.com


    To: OSF.Support.Subscribers:;@osf.org
    Subject: X/Open & OSF Join to Form The Open Group
    Date: Wed, 14 Feb 1996 12:26:53 -0500
    From: Kristen Knotts

    During a press conference at UniForum '96, officials of X/Open Company,
    Ltd. and the Open Software Foundation (OSF), the two leading consortia for
    the advancement of open systems, announced their consolidation into a new,
    more powerful worldwide organization known as The Open Group.

    The new entity has been formed to strengthen and streamline the entire open
    systems process, including adoption of open systems specifications,
    development of specification-compliant technologies, and promotion of their
    use in the global enterprise computing marketplace. Full information can
    be obtained from The Open Group Web Site:

    http://www.opengroup.org/


    -----------------------------------------------------------------------------
    Subject: 34) Is The Open Group assuming responsibility for the X Window
    System?
    [Last modified: July 96]

    A. Yes it will, at the beginning of 1997. See the X Consortium's announcement
    at:

    X Consortium to Transfer X Window System to The Open Group

    It is reproduced _in part_ below for your convenience, followed by a related
    announcement from The Open Group.

    Cambridge, Massachusetts - July 1, 1996 - X Consortium, Inc.
    today announced that it would transfer responsibility for the X
    Window System to The Open Group at the beginning of next year. "X
    is now mainstream technology, and since the first commercial release
    in 1986 it has matured to the point where a dedicated consortium is no
    longer essential to its on-going support," explains Robert W. Scheifler,
    president of the X Consortium. "Our industry will benefit greatly by
    continuing and accelerating the convergence of X, Motif and the
    Common Desktop Environment (CDE) into a unified technology
    stack. This is already well underway with the current CDE-Motif
    PST project, operating under the auspices of The Open Group, an
    organization that is well positioned to take this technology into the
    future." The Open Group will continue their existing work of
    publishing, testing and branding products which conform to
    international standards, including X.

    "As a long standing partner with the X Consortium in the Open
    Systems industry, The Open Group supports this decision. On a
    personal note, I want to add that the computer industry owes an
    enormous debt of gratitude to Bob Scheifler and the X Consortium for
    the service they have provided for the last eight years," commented
    Jim Bell, CEO of The Open Group. "Their very positive impact on our
    industry will continue to be felt for years to come."

    As part of this change, X Consortium plans to wind down all
    engineering operations at the end of this year. "I have made a
    commitment to our members, and to the sponsors of the CDE-Motif
    project, to oversee the entire transition process from now until our
    current engineering projects are finished and the hand-off is
    complete," said Scheifler. The X Consortium will work with its
    members and The Open Group to determine whether the organization
    should continue on in some reduced fashion.

    Broadway, the code name for the next release of the X Window
    System, will be completed as planned by the end of the year, and will
    be made freely available to the public under the same terms as
    previous X Consortium releases. Broadway enables interactive UNIX
    and Windows applications to be integrated, unmodified, into HTML
    documents and published on World Wide Web servers, using plug-in
    technology, and includes network protocols for graphics and audio to
    provide remote access to those applications from inside Web
    browsers. The Broadway release is expected to be available from
    current sources, including worldwide ftp sites and CDROM
    distributors.

    The X Consortium will fulfill its obligations as prime contractor in The
    Open Group's Pre-Structured Technology (PST) project developing
    the next release of CDE and Motif. "The plan has always been to
    complete both the CDE-Motif project and Broadway by the end of
    this year," says Jim Fournier, Director of Engineering. "We are
    confident in our ability to deliver as planned."

    ************************

    A related announcement from corpcom@opengroup.com (The Open Group Corporate
    Communications) was sent July 1, 1996, an excerpt of which appears below:

    The Open Group Continues to Expand Product and Services Portfolio

    Leading Open Systems Consortium
    Absorbs X Window System Technology

    The Open Group announced today as an addition to its growing portfolio of
    products and services, it will assume custodianship for the X Window System
    technology, currently owned and managed by the X Consortium. In its
    press release today, the X Consortium also declared that it will continue to
    fulfill its obligations as prime contractor in The Open Group CDE Pre-
    Structured Technology (PST) project, developing the next releases of CDE and
    Motif, scheduled to be completed by year end, and then cease its internal
    engineering operations.

    "Since its first commercial release in 1986, the X Window System has
    matured to the point where a full-scale, dedicated consortium is no longer
    essential to the on-going support of the technology," said Robert W. Scheifler,
    X Consortium president and founder. "In light of our existing relationship it
    makes sense to fold our ongoing work into The Open Group. Furthermore,
    given the overlapping membership of the two organizations, this move will
    greatly streamline and enhance the process of defining open standards."


    -----------------------------------------------------------------------------
    Subject: 35) What are the current correct trademark statements for X and
    Motif?
    [Last modified: May 97]

    Answer: The Open Group is a trademark of the Open Software Foundation, Inc.
    and X/Open Company Ltd. OSF/Motif and Motif are registered trademarks of The
    Open Group. X Window System is a trademark of The Open Group and the X
    Consortium is a trademark of The Open Group. UNIX is a registered trademark
    in the US and other countries, licensed exclusively through X/Open Company
    Ltd.

    -----------------------------------------------------------------------------
    Subject: 36) Will CDE and Motif converge? What is the CDE/Motif JDA?
    [Last modified: May 97]

    Answer: I'm leaving the following announcement here for historical reference.
    Note that the converged CDE/Motif was released in February, 1997 and is called
    CDE/Motif 2.1. A press release is included earlier in this FAQ.

    In September, 1995, OSF announced the Joint Development Agreement under which
    vendors will participate in a plan to converge Motif and CDE. The announcement
    follows.

    From kjk@osf.org Fri Sep 8 17:55:55 1995
    To: OSF.Motif.Support.Subscribers:;@osf.org
    Cc: OSF.Service.Subscribers:;@osf.org
    Subject: OSF Press Release Announcing Signing of CDE/Motif JDA
    Date: Fri, 08 Sep 1995 17:46:04 -0400
    From: Kristen Knotts

    To: OSF Motif Support Subscribers
    From: The Open Software Foundation

    ************************************************** **********
    OSF MOTIF SUPPORT ELECTRONIC UPDATE
    ************************************************** **********
    An electronic mail news update for Motif Support Subscribers
    from the Open Software Foundation (OSF)


    CONTACT: Jack Dwyer
    Open Software Foundation
    (617) 621-7246
    Email: dwyer@osf.org


    OSF Announces Formal Launch of CDE/Motif Project

    Multi-vendor project to enhance and converge OSF/Motif and the Common
    Desktop Environment

    CAMBRIDGE, MA September 7, 1995 -- The Open Software Foundation today
    announced the formal signing of the Joint Development Agreement for the
    further enhancement and evolution of the Common Desktop Environment (CDE)
    and OSF/Motif under the Open Software Foundation's Pre-Structured
    Technology (PST) development process. The seven sponsors of the CDE/Motif
    PST are Digital Equipment Corp., Fujitsu Limited, Hewlett-Packard Company,
    Hitachi, Ltd, IBM Corp., Novell, Inc., and SunSoft, Inc.

    The CDE/Motif PST is a cooperative, multi-vendor, development project. The
    Open Software Foundation's PST process allows for existing technologies
    from multiple vendors to be further developed and integrated into a
    complete open system technology. The X Consortium has been designated as
    the project's prime contractor.

    CDE/Motif will continue the evolution of the desktop technologies necessary
    to meet the expanding user requirements in such areas as On-line
    Information Access, Printing, and Internationalization. A key objective of
    the PST is to fully converge OSF/Motif and the CDE version of Motif into a
    single development stream. The resulting PST technology will be binary
    compatible with CDE 1.0.

    Mr. Don Harbert, Vice President of UNIX Business Segment for Digital
    Equipment Corporation said, "Digital is an enthusiastic participant in the
    development of the next version of CDE. As a founding member of the Open
    Software Foundation and the first vendor to ship a commercial version of
    the X Window System, Digital recognizes the importance of standard user
    interfaces and the importance of the PST process in developing code."

    "Fujitsu is pleased to support the evolution of CDE and Motif technology,
    both by contributing the Fujitsu OLIAS technology for a robust CDE Online
    Information Access feature, and by improving CDE/Motif
    Internationalization. Providing a common user interface over many different
    hardware systems is critical to the future of Open Systems", said Mitsuru
    Sanagi, General Manager of the Client Server System Strategy and Alliance
    Division, Fujitsu Limited.

    "As one of the original development partners for CDE and as a current
    supplier of CDE technology in AIX, IBM is committed to enhanced usability
    for our AIX customers," said Donna Van Fleet, Vice President for AIX
    Systems Development, IBM RISC System/6000 Division. "Now, as one of the
    sponsors of this new PST, we continue the enhancements to CDE that will
    provide even more ease-of-use value for our customers, while maintaining
    all the benefits of an open technology."

    "CDE is important, industry-unifying technology and Novell is looking
    forward to working with the other CDE/Motif sponsors to continue its
    development," noted Don McGovern, Vice President, Operating System
    Division, Novell, Inc.

    "As chair of the CDE/Motif PST Steering Committee, SunSoft is pleased by
    the active participation and strong commitment for this project. This
    clearly underscores the strong industry support for open systems," said
    Paula Sager, Vice President of Desktop Technologies, SunSoft, Inc. "We are
    looking forward to working with our partners to deliver the best open user
    environment available."

    "We're excited that we are able to contribute to this important industry
    initiative ", said Robert W. Scheifler, President of X Consortium.
    "CDE/Motif combines premier desktop technologies and builds on what is now
    a long line of products founded upon X. There is a lot of synergy between
    the X Consortium's objectives and the goals of the CDE/Motif PST. Our
    involvement as the prime contractor for this project is a logical extension
    of that fact."

    The base technologies for the CDE/Motif PST are CDE 1.0 and OSF/Motif 2.0.
    On-line Information Access will include an SGML-based browser, the ability
    to display and print SGML documents, full text search and retrieval, and
    integration with the on-line help facility. Enhanced internationalization
    capabilities will include the ability to display vertical text, support for
    user defined characters, input method selection at run time, and an
    on-the-spot input method capability. Print capabilities include a graphical
    interface for print job submission, a single API for both display and
    printing, printing support for Motif text and label widgets, help,
    calendar, mail and the text editor. In the process, CDE/Motif will be made
    thread safe and will include support for 64-bit architectures.

    The output of this PST joint development will be a merged CDE/Motif source
    package, a standalone version of Motif, and conformance tests for both CDE
    and Motif. Upon completion, the conformance test suites will be offered to
    X/Open for their branding purposes. Also offered to X/Open will be a merged
    style guide for CDE and Motif, the Motif Drag and Drop protocol, and API
    extensions to CDE and Motif.

    The first deliverable of the CDE/Motif PST will be a maintenance release
    for CDE 1.0 planned for the end of 1995. The schedule further calls for a
    CDE/Motif snapshot to be made available to licensees in mid-1996, with
    general availability of CDE/Motif scheduled for the end of 1996.

    For more information on CDE/Motif, you are invited to contact David Knorr,
    OSF CDE/Motif Business Area Manager, at +617-621-7227 or dknorr@osf.org.

    The Open Software Foundation delivers technology innovations in all areas
    of open systems, including interoperability, scalability, portability, and
    usability. OSF has created a coalition of worldwide vendors and users in
    industry, government and academia that leverage their economic investments
    by working together to provide the best open systems technology solutions
    for distributed computing environments. Headquartered in Cambridge, MA,
    with offices in Brussels, Grenoble and Tokyo, OSF has more then 380 members
    worldwide.
    ###

    OSF, OSF/Motif, and Open Software Foundation are trademarks of the Open
    Software Foundation, Inc.


    -----------------------------------------------------------------------------
    Subject: 37)* Has anyone done a public domain Motif lookalike?
    [Last modified: Feb 02]

    Answer: Open Motif is open source, but not public domain. This following may
    be of interest to public domain purists.

    LessTif is a freeware version of Motif from the Hungry Programmers. It is
    still in development and is intended to be source code compatible with Motif,
    meaning that the same source will compile with both libraries and work exactly
    the same. [Thanks to John W. Carbone, jwc@li.net, Chris Toshok
    (toshok@hungry.com), and Jon Fo (jonf@protocol.com)] For more information, see
    http://www.lesstif.org/

    Tcl/Tk is available for ftp from allspice.berkeley.edu, and although
    implemented without Xt, has a "strict Motif" mode. There is also Tix, the Tk
    Interface Extension. See:

    http://www.sunlabs.com/research/tcl/
    http://www.cis.upenn.edu/~ioi/tix/tix.html

    Strom Sytems (18666 Redmond Way o-2118, Redmond, WA 98052-6725) have a Simple
    Toolkit for X-Windows (sic) that appears to follow the Style Guide even though
    it doesn't quite look like Motif.

    MOOLIT is a USL product that can be runtime switched between the Sun Open Look
    and Motif appearance. It is based on OLIT 4i.

    Interviews is a C++ based product with appearance similar to Motif. A ftp-
    able version of the source code and documentation can be found on
    interviews.stanford.edu. Fresco (http://www.iuk.tu-harburg.de/fresco/) and
    ivtools (http://www.vectaport.com/ivtools/) are based on Interviews.

    Simon J. Lyall (simon@darkmere.midland.co.nz) reported about a package called:
    Xu-lib & Widget Set- a library & widget set to "emulate" the look&feel and the
    programming interface of Motif. Contact the author Udo Baumgart
    (U.BAUMGART@ldb.han.de) for details.

    -----------------------------------------------------------------------------
    Subject: 38) Does the Open Group have an application compliance validation
    service?
    [Last modified: Aug 97]

    Answer: The Motif Toolkit API Verification Suite (VSM4) replaces the earlier
    Motif Branding Program. For more information on VSM4, see
    http://www.opengroup.org/tech/deskto...t.htm#branding

    -----------------------------------------------------------------------------
    Subject: 39) What is the motif-talk mailing list?

    Answer: The motif-talk mailing list is only for those who have purchased a
    Motif source code license. You can be placed on this list by emailing to
    motif-talk-request@osf.org, citing your Company name and source license
    number.

    ---------------------------------------------------------------------------
    END OF PART TWO

  3. Motif FAQ (Part 3 of 9)

    Archive-name: motif-faq/part3
    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: 40) How does Motif work with X11R5?

    Answer: Motif 1.1.X is only intended to be built with X11R4. Motif 1.2.X is
    for X11R5. however, Motif 1.1.4 has been set to also work with X11R5.

    For Motif 1.1.1, 1.1.2 and 1.1.3 you will need to compile Xlib and Xt with a
    MOTIFBC flag set to YES (page 8, section 3.3 of the R5 release notes), or
    you'll also have a link problem (LowerCase) and a fatal run time problem
    (XContext manager). If your applications come up with "Unknown keysym name:
    osfActivate" errors, check the variable ProjectRoot. The name
    /$PROJECTROOT/lib/XKeysymDB will have been wired into your Xlib.

    In Motif 1.1.0, XtCallCallback uses NULL as the first argument instead of a
    widget ID. This was ok under R4, but must be changed in the source for R5. It
    was changed by OSF from Motif 1.1.1 onward.

    Mrm won't work at all (can't link since it uses an X private variable that has
    disappeared in R5). There is an MIT patch that may fix this??

    -----------------------------------------------------------------------------
    Subject: 41) Where can I find X technical info on the WWW?
    [Last modified: Mar 96]

    Answer:

    Technical X Window System and OSF/Motif WWW sites
    http://www.rahul.net/kenton/xsites.html

    This web site currently lists over 700 X Window System links, including
    technical papers, tutorials, FAQs, product reviews, etc.

    -----------------------------------------------------------------------------
    Subject: 42) What is Broadway? I've heard it called "X on the Web".
    [Last modified: Jun 98]

    Answer: Broadway was the X Consortium's internal code name for the X11R6.3
    release. It includes a collection of X-based technologies for the World Wide
    Web. For details, see:

    http://www.camb.opengroup.org/tech/d...x/broadway.htm

    And if you're wondering. "Why did they call it Broadway?", the X Consortium
    was located at 201 Broadway, Cambridge, MA.... ksall@cen.com

    -----------------------------------------------------------------------------
    Subject: 43) Where's an HTML version of the Motif FAQ on World Wide Web
    (WWW)?
    [Last modified: Feb 95]

    Answer: An automatically generated HTML version of this Motif FAQ can be found
    at WWW URL:

    http://www.cis.ohio-state.edu/hypert...f-faq/top.html

    For a searchable version of the Motif FAQ and other FAQs (via WAIS), see:

    http://www.cs.ruu.nl/cgi-bin/faqwais

    The WAIS search is great way to find a topic which may appear in several FAQs
    (Motif, X, Xt, Widget FAQ, etc.)

    -----------------------------------------------------------------------------
    Subject: 44) Where can I get the HTML widget used in Mosaic?
    [Last modified: Mar 96]

    Answer: Thanks to Matthew Freedman (mattf@cac.washington.edu) and
    intasoft@cix.compulink.co.u for updates to the URLs mentioned in this answer.

    Ken Sall (ksall@cen.com) writes: The HTML (HyperText Markup Language) widget
    is part of the NCSA Mosaic source code available from ftp.ncsa.uiuc.edu. Look
    in the "libhtmlw" subdirectory of the "Mosaic-src-*" subdirectory of:

    ftp://ftp.ncsa.uiuc.edu/Mosaic/Unix/source/

    or, more generally, look for the files HTML.c, HTML.h, HTMLP.h, etc. in your
    "libhtmlw" subdirectory of the Mosaic source.

    For (old) documentation, see

    http://www.ncsa.uiuc.edu/SDG/Softwar...tmlwidget.html.

    However, Matthew M. Freedman (mattf@cac.washington.edu) pointed out the
    document is out of date: "One important thing to know is that the on-line
    documentation for the Mosaic html widget is out of synch with the source code.
    I e-mailed NCSA about this in May, but they seem to have ignored the report.
    The one that I wasted half a day because of is HTMLSetText(). The on-line docs
    list four arguments, but in fact there are seven. I have no idea what the
    extra three undocumented parameters are used for, I just plugged in NULL's and
    it works. The other error I noticed is that they document a "page" field in
    WbAnchorCallbackData, but it does not actually exist. Also, at least for me,
    after I call HTMLSetText() the first time, the widget remains blank. I have to
    lower and raise the window for it to be drawn. Anybody know what is wrong? I
    guess will probably just spoof an expose in my code."


    For information on using Mosaic by remote control, see

    http://www.ncsa.uiuc.edu/SDG/Softwar.../cci-spec.html
    and
    http://www.ncsa.uiuc.edu/SDG/Softwar...e-control.html


    Here are more details from ah627@FreeNet.Carleton.CA (Samuel Effah):

    To the numerous request for the NCSA HTML widget information.

    Everything not already copyrighted by CERN is copyrighted by NCSA (including
    the contents of the libhtmlw, libnet, libXmx, and src directories, but not
    including the contents of libdtm, which is entirely public domain). ...

    * The UI grants you (hereafter, Licensee) a license to use the Software *
    * for academic, research and internal business purposes only, without a *
    * fee. Licensee may distribute the binary and source code (if released) *
    * to third parties provided that the copyright notice and this statement *
    * appears on all copies and that no charge is associated with such *
    * copies. *
    * *
    ( you can read more about the copyright in the Mosaic source code ).


    Documentation on the HTML widget can be located at:

    http://www.ncsa.uiuc.edu/SDG/Softwar...tmlwidget.html
    ( it's on the older version, I think Mosaic1.x )

    For starters, you can compile directory Mosaic2.4/libhtmlw for the widget.
    Using: To create widget:
    htlmWid = XtCreateManagedWidget( "htlmWid",
    htmlWidgetClass, parent,
    htlmArgs,
    XtNumber( htlmArgs ));

    Callback for anchors:
    XtAddCallback(htlmWid, WbNanchorCallback, htmlRef, NULL);

    where htmlRef() looks like:

    static void htmlRef(widget, client_data, call_data) Widget widget; XtPointer
    client_data; WbAnchorCallbackData* call_data; {
    buffer = readHTMLFile( call_data->href );
    XtVaSetValues( widget, WbNtext, buffer, NULL ); }

    where readHTMLFile() is

    char * readHTMLFile( in_file ) char *in_flie; {
    /* function to read a file and return its content, given
    the file's name */ }

    I think this is enough to start you off.


    Thanks to: Samuel Effah

    -----------------------------------------------------------------------------
    Subject: 45)* What widgets does Netscape use for its bookmarks list and
    preference panels?
    [Last modified: Jan 02]

    Answer: Netscape uses the Microline widget set. Microline was purchased by
    Neuron Data (http://www.neurondata.com/), but they no longer sell the
    Microline widget set.

    Some of the Microline widgets are available in the Mozilla source code:
    http://lxr.mozilla.org/classic/sourc.../Microline3.0/

    Ken Lee, http://www.rahul.net/kenton/

    -----------------------------------------------------------------------------
    Subject: 46) TOPIC: BOOKS and JOURNALS

    -----------------------------------------------------------------------------
    Subject: 47) Is there a Motif tutorial? Xt tutorial? X11 tutorial?
    [Last modified: Nov 96]

    Answer: For the most up-to-date links to Motif/X11/Xt tutorials, see:

    http://www.rahul.net/kenton/xsites.html#Xtutorials
    On-line X programming tutorials (Kenton Lee's multi-lingual links)


    See http://www.cm.cf.ac.uk/Dave/X_lecture/X_lecture.html
    for a hypertext Motif tutorial (by David Marshall) with source code and
    illustrations.

    Marshall Brain at brain@adm.csc.ncsu.edu posted a set of simple and useful
    Motif tutorials at http://www.iftech.com/ .

    Jan Borchers writes about his Xmtutor:

    "Xmtutor" is an interactive tutorial teaching you how to write Motif
    applications. While it comes with a complete printable book file, its key
    component is the online version of the tutorial: It's a Motif application
    itself, and its examples are actual running Motif applications. You can modify
    their resource settings from within the tutorial, and then play with them to
    see how their interface reacts. For the free version, screen shots,
    registration, and more information check out the Xmtutor home page at:

    http://www.stanford.edu/~borchers/xmtutor/


    More on-line Motif tutorials and technical papers are listed on my web site:

    http://www.rahul.net/kenton/


    -----------------------------------------------------------------------------
    Subject: 48) What books are available for Motif application programmers?
    [Last modified: Mar 98]

    Answer: NOTE: This subject is impossible to keep meaningfully up to date and
    has been deleted.

    -----------------------------------------------------------------------------
    Subject: 49) What relevant journals are available?
    [Last modified: Jun 98]

    Answer: In October, 1997, ICS has launched The Motif Zone at

    http://www.motifzone.com/

    This web site contains a Motif reference section and an on-line magazine
    called *The Motif Developer*.

    Several other Motif-oriented magazines have existed in the past, but are
    ceased publishing. Their back issues are still very interesting, though.
    Back issues of the print magazines may be available from their publishers or
    at better technical libraries. Back issues of "The X Advisor" are no longer
    on line.

    "The X Journal" was published bimonthly by SIGS Publications, +1-212-274-0640.
    "The X Resource: A Practical Journal of the X Window System" was published
    quarterly by O'Reilly and Associates, +1-800-998-9938.

    -----------------------------------------------------------------------------
    Subject: 50) TOPIC: MWM and the SHELL WIDGET

    -----------------------------------------------------------------------------
    Subject: 51) What is the difference between Motif and mwm?

    Answer: mwm is a window manager.

    Motif itself is made up of four parts: a User Interface Style Guide, an API
    toolkit of `C' routines which helps in the building of applications which
    conform to the style guide, the window manager mwm, and a language UIL which
    is designed to ease user interface development.

    In general mwm will run any application built with any X Window System API,
    and in general an application built using the Motif toolkit will run under any
    window manager.

    -----------------------------------------------------------------------------
    Subject: 52) Does anyone have an alternative set of 3-D defaults for a
    monochrome screen?

    Answer: This is obviously a matter of taste. Some alternatives suggested
    include

    !Benjamin Schreiber, bs@osf.osf.org, bs@cs.brandeis.edu
    Mwm*foreground: black ! Actually, when a window is
    Mwm*background: white ! deactivated, the background
    Mwm*backgroundPixmap: 50_foreground ! becomes white, insted of
    Mwm*topShadowPixmap: white ! 50% foreground (grey)

    Mwm*activeForeground: black
    Mwm*activeBackground: white
    Mwm*activeBackgroundPixmap: 50_foreground
    Mwm*activeTopShadowPixmap: white

    Mwm*menu*backgroundPixmap: background
    Mwm*menu*topShadowPixmap: 50_foreground

    Mwm*title*foreground: black
    Mwm*title*background: white
    Mwm*title*backgroundPixmap: white
    Mwm*title*topShadowPixmap: 50_foreground
    Mwm*title*activeForeground: white
    Mwm*title*activeBackground: black
    Mwm*title*activeBackgroundPixmap: black
    Mwm*title*activeBottomShadowPixmap: 50_foreground

    Mwm*feedback*backgroundPixmap: white

    or

    ! From: tsang@isi.com (Kam C. Tsang)
    Mwm*background: White
    Mwm*activeBackground: White
    Mwm*activeBackgroundPixmap: 25_foreground
    Mwm*foreground: Black
    Mwm*activeForeground: Black
    Mwm*menu*background: white
    Mwm*menu*foreground: black
    xterm*Foreground: black
    xterm*Background: white

    or

    ! From: ucsd.edu!usc!snorkelwacker!paperboy!yee (Michael K. Yee)
    Mwm*cleanText: True

    Mwm*activeBackground: white
    Mwm*activeForeground: black
    Mwm*background: white
    Mwm*foreground: black

    Mwm*client*activeBackgroundPixmap: 50_foreground
    Mwm*client*activeTopShadowPixmap: foreground
    Mwm*client*activeBottomShadowPixmap: background

    !Mwm*client*background: white
    !Mwm*client*foreground: black
    Mwm*client*backgroundPixmap: 75_foreground
    Mwm*client*topShadowPixmap: foreground
    Mwm*client*bottomShadowPixmap: background

    !Mwm*feedback*background: white
    !Mwm*feedback*foreground: black
    Mwm*feedback*backgroundPixmap: 50_foreground
    !Mwm*feedback*topShadowPixmap: 25_foreground
    !Mwm*feedback*bottomShadowPixmap: background

    !Mwm*menu*background: white
    !Mwm*menu*foreground: black
    Mwm*menu*backgroundPixmap: foreground
    !Mwm*menu*topShadowPixmap: foreground
    !Mwm*menu*bottomShadowPixmap: background

    !Mwm*icon*background: white
    !Mwm*icon*foreground: black
    Mwm*icon*activeBackgroundPixmap: 50_foreground
    Mwm*icon*activeBottomShadowPixmap: foreground
    Mwm*icon*backgroundPixmap: 75_foreground


    -----------------------------------------------------------------------------
    Subject: 53) What are some useful mwm resources I can control?
    [Last modified: Sept 95]

    Answer: Ken Sall (ksall@cen.com) writes: The following are described in the
    mwm(1) man page:

    clientAutoPlace (class ClientAutoPlace)
    focusAutoRaise (class FocusAutoRaise)
    interactivePlacement (class InteractivePlacement)
    positionIsFrame (class PositionIsFrame)
    positionOnScreen (class PositionOnScreen)
    useIconBox (class UseIconBox)


    -----------------------------------------------------------------------------
    Subject: 54) How can I configure mwm, such as changing or adding to root
    menus?
    [Last modified: Oct 95]

    Answer: Read the mwm(1) man page which describes how to configure mwm using
    the .mwmrc file. The default location of the system-wide version of this file
    is /usr/lib/X11/system.mwmrc. You can override settings in the global file by
    creating your own $HOME/.mwmrc.

    -----------------------------------------------------------------------------
    Subject: 55) How can my program determine which window manager is running?
    [Last modified: Nov 97]

    Answer: Each window manager has its own signature, but unfortunately there is
    no standard query mechanism. Motif provides XmIsMotifWMRunning() to test for
    mwm.

    -----------------------------------------------------------------------------

    Subject: 56) How can I modify the mwm's window decorations with a resource
    file?
    [Last modified: Dec 97]

    Answer: Set mwm's client resource "clientDecoration" for your particular
    application. For example,

    Mwm*XClock.clientDecoration: none

    turns off all clock decorations. See the mwm man page for other options and
    other mwm client resources.

    -----------------------------------------------------------------------------

    Subject: 57) How can I programatically modify the mwm's window decorations?
    [Last modified: July 95]

    Answer: Programmatically, set the VendorShell resource XmNmwmDecorations to 0,
    such as:

    #include /* see MWM_DECOR_* and MWM_FUNC_* */
    #include
    popupShell =
    XtVaCreatePopupShell( "PopupShell",
    xmDialogShellWidgetClass, toplevel,
    XmNmwmDecorations, 0,
    NULL );

    With the 0, you have no decorations at all, but if you want just a little
    frame, use MWM_DECOR_BORDER instead.

    Thanks to Guillaume.Gallais@asm.thomson.fr for the code fragment and pointing
    out that there is no MWM_DECOR_NONE.

    Reinhard M. Weiss (weissrm@execpc.com) also pointed out that MWM_DECOR_NONE
    was fictitious. He also added:

    "I have found that the resource XtNoverrideRedirect does cause the olwm to
    remove all decorations (my guess is that it would work in mwm roughly the
    same). This works programmatically as well as in resource files (i.e.
    *.className*overrideRedirect: true). There are some undesirable effects to
    this, however, particularly with focus and managing dialogs and popups."

    -----------------------------------------------------------------------------
    Subject: 58) Is there an ICCCM compliant way of setting window manager
    decorations?

    Answer: Tom LaStrange (toml@LaStrange.COM) writes: "No, there is no ICCCM
    portable way to alter decorations."

    -----------------------------------------------------------------------------
    Subject: 59) How can I put decorations on transient windows using olwm?

    Answer: This code is from Jean-Philippe Martin-Flatin :

    /************************************************** ********************
    ** WindowDecorations.c
    **
    ** Manages window decorations under the OpenLook window manager (OLWM).
    **
    ** Adapted from a C++ program posted to comp.windows.x.motif by:
    **
    ** +--------------------------------------------------------------+
    ** | Ron Edmark User Interface Group |
    ** | Tel: (408) 980-1500 x282 Integrated Systems, Inc. |
    ** | Internet: edmark@isi.com 3260 Jay St. |
    ** | Voice mail: (408) 980-1590 x282 Santa Clara, CA 95054 |
    ** +--------------------------------------------------------------+
    ************************************************** *********************/

    #include
    #include
    #include
    #include
    #include
    #include
    #include
    #include

    /*
    ** Decorations for OpenLook:
    ** The caller can OR different mask options to change the frame decoration.
    */
    #define OLWM_Header (long)(1<<0)
    #define OLWM_Resize (long)(1<<1)
    #define OLWM_Close (long)(1<<2)

    /*
    ** Prototypes
    */
    static void InstallOLWMAtoms (Widget w);
    static void AddOLWMDialogFrame(Widget widget, long decorationMask);


    /*
    ** Global variables
    */
    static Atom AtomWinAttr;
    static Atom AtomWTOther;
    static Atom AtomDecor;
    static Atom AtomResize;
    static Atom AtomHeader;
    static Atom AtomClose;
    static int not_installed_yet = TRUE;


    static void InstallOLWMAtoms(Widget w)
    {
    AtomWinAttr = XInternAtom(XtDisplay(w), "_OL_WIN_ATTR" , FALSE);
    AtomWTOther = XInternAtom(XtDisplay(w), "_OL_WT_OTHER", FALSE);
    AtomDecor = XInternAtom(XtDisplay(w), "_OL_DECOR_ADD", FALSE);
    AtomResize = XInternAtom(XtDisplay(w), "_OL_DECOR_RESIZE", FALSE);
    AtomHeader = XInternAtom(XtDisplay(w), "_OL_DECOR_HEADER", FALSE);
    AtomClose = XInternAtom(XtDisplay(w), "_OL_DECOR_CLOSE", FALSE);

    not_installed_yet = FALSE;
    }

    static void AddOLWMDialogFrame(Widget widget, long decorationMask)
    {
    Atom winAttrs[2];
    Atom winDecor[3];
    Widget shell = widget;
    Window win;
    int numberOfDecorations = 0;

    /*
    ** Make sure atoms for OpenLook are installed only once
    */
    if (not_installed_yet) InstallOLWMAtoms(widget);

    while (!XtIsShell(shell)) shell = XtParent(shell);

    win = XtWindow(shell);

    /*
    ** Tell Open Look that our window is not one of the standard OLWM window
    ** types. See OLIT Widget Set Programmer's Guide pp.70-73.
    */

    winAttrs[0] = AtomWTOther;

    XChangeProperty(XtDisplay(shell),
    win,
    AtomWinAttr,
    XA_ATOM,
    32,
    PropModeReplace,
    (unsigned char*)winAttrs,
    1);

    /*
    ** Tell Open Look to add some decorations to our window
    */
    numberOfDecorations = 0;
    if (decorationMask & OLWM_Header)
    winDecor[numberOfDecorations++] = AtomHeader;
    if (decorationMask & OLWM_Resize)
    winDecor[numberOfDecorations++] = AtomResize;
    if (decorationMask & OLWM_Close)
    {
    winDecor[numberOfDecorations++] = AtomClose;

    /*
    ** If the close button is specified, the header must be
    ** specified. If the header bit is not set, set it.
    */
    if (!(decorationMask & OLWM_Header))
    winDecor[numberOfDecorations++] = AtomHeader;
    }

    XChangeProperty(XtDisplay(shell),
    win,
    AtomDecor,
    XA_ATOM,
    32,
    PropModeReplace,
    (unsigned char*)winDecor,
    numberOfDecorations);
    }


    /*
    ** Example of use of AddOLWMDialogFrame, with a bit of extra stuff
    */
    void register_dialog_to_WM(Widget shell, XtCallbackProc Cbk_func)
    {
    Atom atom;

    /*
    ** Alias the "Close" item in system menu attached to dialog shell
    ** to the activate callback of "Exit" in the menubar
    */
    if (Cbk_func)
    {
    atom = XmInternAtom(XtDisplay(shell),"WM_DELETE_WINDOW",TRUE);
    XmAddWMProtocolCallback(shell,atom, Cbk_func,NULL);
    }

    /*
    ** If Motif is the window manager, skip OpenLook specific stuff
    */
    if (XmIsMotifWMRunning(shell)) return;

    /*
    ** Register dialog shell to OpenLook.
    **
    ** WARNING: on some systems, adding the "Close" button allows the title
    ** to be properly centered in the title bar. On others, activating
    ** "Close" crashes OpenLook. The reason is not clear yet, but it seems
    ** the first case occurs with OpenWindows 2 while the second occurs with
    ** Openwindows 3. Thus, comment out one of the two following lines as
    ** suitable for your site, and send e-mail to syj@ecmwf.int if you
    ** find out what is going on !
    */
    AddOLWMDialogFrame(shell,(OLWM_Header | OLWM_Resize));
    /* AddOLWMDialogFrame(shell,(OLWM_Header | OLWM_Resize | OLWM_Close)); */
    }


    -----------------------------------------------------------------------------
    Subject: 60) How can I turn off the Motif window manager functions from the
    system menu?
    [Last modified: October 92]

    Answer: The user of an application can control functions in the system menu
    for an application using the mwm resource clientFunctions:

    mwm.application_name.clientFunctions: -resize -close

    Note that mwm will have to be restarted after putting this in their resource
    database.


    Answer: The writer of an application can only remove items. Be warned that
    your users will probably gnash their teeth, swear furiously at your product
    and stop using it if they discover that you have done this. (Especially if
    you have removed the Close button, your application has hung and it has taken
    up all of memory and swap so it can't be killed.) Much better is to catch the
    action gracefully as in the next question.

    #include

    XtVaGetValues(shell, XmNmwmFunctions, &int_val, NULL);
    int_val &= ~(MWM_FUNC_CLOSE | MWM_FUNC_ALL);
    XtVaSetValues(shell, XmNmwmFunctions, int_val, NULL);


    -----------------------------------------------------------------------------
    Subject: 61) How can I create a multi-colored window manager icon?
    [Last modified: Oct 95]

    Answer: The only portable way to do this is with icon windows. The WMShell
    widget supports icon windows with its XmNiconWindow resource. Set this to a
    window that your application has created. The window could be the XtWindow()
    of a realized shell widget. The window must be created with the default
    visual and colormap of its screen. Other requirements on icon windows are
    specified in section 4.1.9 of the X11R6 ICCCM. Note that some window managers
    provide alternate techniques for creating color icons; none of these are
    standard or portable.

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 62) How can I keep my shell windows fixed in size?
    [Last modified: Apr 95]

    Answer: In addition to the decoration controls mentioned in the previous few
    subjects of this FAQ, you can also specify size hints for your shell widget's
    windows with these resources: XmNminWidth, XmNmaxWidth, XmNminHeight,
    XmNmaxHeight. If you set the min and max values to the same size, most window
    managers will not allow the user to resize the window.

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 63) Why is XtGetValues of XmNx and XmNy of my toplevel shell wrong?
    [Last modified: Oct 95]

    Answer: [Note: This answer is borrowed from the Xt FAQ,
    ftp://ftp.x.org/contrib/faqs/FAQ-Xt, devoted to X Toolkit Intrinsics.]

    XmNx and XmNy are the coordinates relative to your shell's parent window,
    which is usually a window manager's frame window. To translate to the root
    coordinate space, use XtTranslateCoords().

    -----------------------------------------------------------------------------
    Subject: 64) How do I get XmNx and XmNy positions to be honored correctly?
    [Last modified: Nov 96]

    Answer: One answer is to pass the right hints to the window manager, perhaps
    using XSetWMNormalHints. Another approach comes from Shane Burgess
    (shane@radionics.com) who writes:

    By setting the XmNdefaultPosition resource (on XmBulletinBoard or its
    subclasses, including the message dialogs) to False, I've found that all my
    XmNx & XmNy requests gets set correctly.

    Pete Sakalaukus (sakalauk@pelican.st.usm.edu) says that XmNdefaultPosition
    only works with olwm, not mwm.

    -----------------------------------------------------------------------------
    Subject: 65) How can my application know when the user has quit Mwm?
    [Last modified: Feb 95]

    Answer: Looking for an answer to this one. ANY TAKERS? (Still looking.)

    -----------------------------------------------------------------------------
    Subject: 66) How can I tell if the user has selected "Close" from the system
    menu? How do I catch the "Close"? I need to do some clean up before exiting.
    [Last modified: Aug 95]

    Answer: Catching the mwm Close involves using XmAddWMProtocolCallback and
    possibly setting the XmNdeleteResponse resource. Note that whether your
    application involves multiple applicationShells vs. a single applicationShell
    and multiple toplevelShells is significant. Following the two older code
    fragments is a complete test application which can be compiled with different
    #defines to alter the behavior.

    This works with R4 Intrinsics

    #include

    void FinalCleanupCB(w, client_data, call_data)
    Widget w;
    caddr_t client_data, call_data;
    {
    /* tidy up stuff here */
    ...
    /* exit if you want to */
    exit (0);
    }

    main()
    {
    Atom wm_delete_window;

    ...
    XtRealizeWidget(toplevel);
    ...
    wm_delete_window =
    XmInternAtom(XtDisplay(toplevel),
    "WM_DELETE_WINDOW", False);
    XmAddWMProtocolCallback(toplevel, wm_delete_window,
    FinalCleanupCB, NULL);
    XtMainLoop();
    }

    This will still kill the application. To turn this behaviour off so that the
    application is not killed, set the shell resource XmNdeleteResponse to
    XmDO_NOTHING. This means that users cannot kill your application via the
    system menu, and may be a bad thing.

    If you are running R3, Bob Hays (bobhays@spss.com) has suggested this:
    "Trapping on the delete window atom does not work as I cannot force my action
    routine to the top of the action list for the activity desired, so the window
    manager kills my window anyway BEFORE I can do anything about it. And, to
    make matters worse, the window manager (Motif in this case) tacks its atoms
    and handlers onto the window at some unknown point down the line after the
    creation of the shell widget as far as I can tell. So....

    I have a procedure as an action routine for ClientMessage. Then, if I get a
    property change event on the window manager protocols, I then tack on
    WM_SAVE_YOURSELF. If I get this request, I clean up (it seems to happen on
    WM_DELETE_WINDOW, BTW, if you remove WM_DELETE_WINDOW from the WM protocols
    atom) and exit. Works great and is less filling overall:-)."

    The following similar code fragment is from Dave Mink
    (mink@cadcam.pms.ford.com):

    void setupCloseCallback(Widget shell, XtCallbackProc closeProc)
    {
    /* get window manager delete protocol atom */
    Atom deletewin_protocol = XmInternAtom(
    XtDisplay(shell), "WM_DELETE_WINDOW", True
    );
    /* turn off default delete response */
    XtVaSetValues( shell,
    XmNdeleteResponse, XmDO_NOTHING,
    NULL);
    /* add callback for window manager delete protocol */
    XmAddWMProtocolCallback(shell, deletewin_protocol, closeProc, NULL);
    }


    Here is a complete code example which can be compiled several different ways,
    as per the comments in the code.


    /*
    * MWM Close test program.
    *
    * Creates 4 shells, testing each of 3 different values of XmNdeleteResponse.
    * Compile will -DMULTIPLE_APP_SHELLS to make all 4 shells of type
    * applicationShellWidgetClass. Otherwise, first shell created is
    * applicationShellWidgetClass, but other 3 are topLevelShellWidgetClass.
    * Results differ. You can also experiment with #defining POPUP_SHELL,
    * BEFORE_CREATE, or AFTER_CREATE.
    *
    * Ken Sall (ksall@cen.com)
    */

    #include

    #include
    #include

    #include
    #include
    #include

    #include /* for popup */
    #include

    #include
    #include
    #include

    void CloseCB();
    void popup_handler();

    #ifdef MULTIPLE_APP_SHELLS
    #define P1_TITLE "P1: applicationShell: XmDO_NOTHING"
    #define P2_TITLE "P2: applicationShell: XmDESTROY"
    #define P3_TITLE "P3: applicationShell: XmUNMAP"
    #define P4_TITLE "P4: applicationShell: default"
    #else
    #define P1_TITLE "P1: applicationShell: XmDO_NOTHING"
    #define P2_TITLE "P2: topLevelShell: XmDESTROY"
    #define P3_TITLE "P3: topLevelShell: XmUNMAP"
    #define P4_TITLE "P4: topLevelShell: XmDO_NOTHING"
    #endif

    void CloseCB (w, client_data, call_data)
    Widget w; /* widget id */
    caddr_t client_data; /* data from application */
    caddr_t call_data; /* data from widget class */
    {
    XmAnyCallbackStruct *cb = (XmAnyCallbackStruct *) call_data;

    printf ("caught Close from: %s\n", (char *)client_data );
    if (strcmp ( P1_TITLE, (char *)client_data ) == 0 )
    {
    /* do something */
    }
    else if (strcmp ( P2_TITLE, (char *)client_data ) == 0 )
    {
    /* do something else */
    }
    else if (strcmp ( P3_TITLE, (char *)client_data ) == 0 )
    {
    /* do something else */
    }
    else if (strcmp ( P4_TITLE, (char *)client_data ) == 0 )
    {
    /* do something else */
    }
    else /* unreachable */
    {
    printf ("oops\n");
    }
    }

    void popup_handler()
    {
    printf ("popup handler\n");
    }

    int main (argc,argv, envp)
    int argc;
    char **argv;
    char **envp;
    {
    XtAppContext app_context;
    Display *theDisplay;
    Widget shell1, shell2, shell3, shell4;
    Widget label, DrawWindow, WindowPopupMenu;
    Arg al[10];
    int ac;
    Atom delwinAtom1, delwinAtom2, delwinAtom3, delwinAtom4;
    XmString xms;

    #ifdef MULTIPLE_APP_SHELLS
    printf ("This version will demonstrate a problem if you Close P2.\n");
    printf ("Since there are multiple appshells, closing (destroying) P2 cause the app to exit.\n");
    #else
    #ifdef POPUP_SHELL
    printf ("This version uses XtCreatePopupShell rather than XtAppCreateShell \n");
    #else
    printf ("Compile with '-DMULTIPLE_APP_SHELLS' to demonstrate a problem.\n");
    #endif
    #endif

    #ifdef BEFORE_CREATE
    printf ("This version adds the XmNdeleteResponse _before_ the shell is created.\n");
    #else
    printf ("This version adds the XmNdeleteResponse _after the shell is created.\n");
    #endif

    XtToolkitInitialize ();
    app_context = XtCreateApplicationContext ();

    theDisplay = XtOpenDisplay ( app_context, NULL,
    "my_program", "ProgramClass",
    NULL, 0, &argc, argv);

    /* --------------------- BEGIN P1 -------------------- */
    ac = 0;
    XtSetArg(al[ac], XmNx, 0); ac++;
    XtSetArg(al[ac], XmNy, 0); ac++;
    XtSetArg(al[ac], XmNwidth, 350); ac++;
    XtSetArg(al[ac], XmNheight, 200); ac++;
    XtSetArg (al[ac], XmNtitle, P1_TITLE); ac++;
    #ifdef BEFORE_CREATE
    XtSetArg (al[ac], XmNdeleteResponse, XmDO_NOTHING); ac++;
    #endif

    /* The ONLY applicationShell unless MULTIPLE_APP_SHELLS is defined. */

    shell1 = XtAppCreateShell ("shell1", "ProgramClass",
    applicationShellWidgetClass, theDisplay, al, ac);

    /* Tell mwm to exec CloseCB when close is detected. */
    delwinAtom1 = XmInternAtom (XtDisplay(shell1),
    "WM_DELETE_WINDOW", False);
    XmAddWMProtocolCallback (shell1, delwinAtom1, CloseCB, P1_TITLE);

    #ifndef BEFORE_CREATE
    XtVaSetValues( shell1, XmNdeleteResponse, XmDO_NOTHING, NULL);
    #endif

    /* --------------------- BEGIN P2 -------------------- */
    ac = 0;
    XtSetArg(al[ac], XmNx, 375); ac++;
    XtSetArg(al[ac], XmNy, 0); ac++;
    XtSetArg(al[ac], XmNwidth, 350); ac++;
    XtSetArg(al[ac], XmNheight, 200); ac++;
    XtSetArg (al[ac], XmNtitle, P2_TITLE); ac++;
    #ifdef BEFORE_CREATE
    XtSetArg (al[ac], XmNdeleteResponse, XmDESTROY); ac++;
    #endif

    #ifdef MULTIPLE_APP_SHELLS
    shell2 = XtAppCreateShell ("shell2", "ProgramClass",
    applicationShellWidgetClass, theDisplay, al, ac);
    #else
    #ifdef POPUP_SHELL
    /*
    * NOTE use of XtCreatePopupShell (not XtCreateMAnagedWidget) and
    * topLevelShellWidgetClass (not applicationShellWidgetClass).
    * Parent of topLevelShell is applicationShell.
    * Use XtPopup rather than XtRealize for topLevelShell.
    */
    shell2 = XtCreatePopupShell ("shell2",
    topLevelShellWidgetClass, shell1, al, ac);
    #else
    shell2 = XtAppCreateShell ("shell2", "ProgramClass",
    topLevelShellWidgetClass, theDisplay, al, ac);
    #endif
    #endif

    /* Tell mwm to exec CloseCB when close is detected. */
    delwinAtom2 = XmInternAtom (XtDisplay(shell2),
    "WM_DELETE_WINDOW", False);
    XmAddWMProtocolCallback (shell2, delwinAtom2, CloseCB, P2_TITLE);

    #ifndef BEFORE_CREATE
    XtVaSetValues( shell2, XmNdeleteResponse, XmDESTROY, NULL);
    #endif

    /* --------------------- BEGIN P3 -------------------- */
    ac = 0;
    XtSetArg(al[ac], XmNx, 750); ac++;
    XtSetArg(al[ac], XmNy, 0); ac++;
    XtSetArg(al[ac], XmNwidth, 350); ac++;
    XtSetArg(al[ac], XmNheight, 200); ac++;
    XtSetArg (al[ac], XmNtitle, P3_TITLE); ac++;
    #ifdef BEFORE_CREATE
    XtSetArg (al[ac], XmNdeleteResponse, XmUNMAP); ac++;
    #endif

    #ifdef MULTIPLE_APP_SHELLS
    shell3 = XtAppCreateShell ("shell3", "ProgramClass",
    applicationShellWidgetClass, theDisplay, al, ac);
    #else
    #ifdef POPUP_SHELL
    /* See comments for shell2 */
    shell3 = XtCreatePopupShell ("shell3",
    topLevelShellWidgetClass, shell1, al, ac);
    #else
    shell3 = XtAppCreateShell ("shell3", "ProgramClass",
    topLevelShellWidgetClass, theDisplay, al, ac);
    #endif
    #endif

    /* Tell mwm to exec CloseCB when close is detected. */
    delwinAtom3 = XmInternAtom (XtDisplay(shell3),
    "WM_DELETE_WINDOW", False);
    XmAddWMProtocolCallback (shell3, delwinAtom3, CloseCB, P3_TITLE);

    #ifndef BEFORE_CREATE
    XtVaSetValues( shell3, XmNdeleteResponse, XmUNMAP, NULL);
    #endif

    /* --------------------- BEGIN P4 -------------------- */
    ac = 0;
    XtSetArg(al[ac], XmNx, 0); ac++;
    XtSetArg(al[ac], XmNy, 250); ac++;
    XtSetArg(al[ac], XmNwidth, 350); ac++;
    XtSetArg(al[ac], XmNheight, 200); ac++;
    XtSetArg (al[ac], XmNtitle, P4_TITLE); ac++;
    #ifdef BEFORE_CREATE
    XtSetArg (al[ac], XmNdeleteResponse, XmDO_NOTHING); ac++;
    #endif

    #ifdef MULTIPLE_APP_SHELLS
    shell4 = XtAppCreateShell ("shell4", "ProgramClass",
    applicationShellWidgetClass, theDisplay, al, ac);
    #else
    #ifdef POPUP_SHELL
    /* See comments for shell2 */
    shell4 = XtCreatePopupShell ("shell4",
    topLevelShellWidgetClass, shell1, al, ac);
    #else
    shell4 = XtAppCreateShell ("shell4", "ProgramClass",
    topLevelShellWidgetClass, theDisplay, al, ac);
    #endif
    #endif

    /* Tell mwm to exec CloseCB when close is detected. */
    delwinAtom4 = XmInternAtom (XtDisplay(shell4),
    "WM_DELETE_WINDOW", False);
    XmAddWMProtocolCallback (shell4, delwinAtom4, CloseCB, P4_TITLE);

    #ifndef BEFORE_CREATE
    XtVaSetValues( shell4, XmNdeleteResponse, XmDO_NOTHING, NULL);
    #endif

    /* just for fun */
    ac = 0;
    WindowPopupMenu = XmCreatePopupMenu(shell1, "PopupMenu", al, ac);
    XtAddEventHandler( shell1, ButtonPressMask, FALSE, popup_handler,
    WindowPopupMenu);

    ac = 0;
    xms = (XmString) XmStringCreateLocalized ( "Button3 = popup; Button2 = DnD.");
    XtSetArg(al[ac], XmNlabelString, xms); ac++;
    XtSetArg(al[ac], XmNshadowThickness, 2); ac++;
    label = XmCreateLabel (shell1, "label", al, ac);
    XtManageChild ( label );

    XtRealizeWidget( shell1 );

    /* NOTE use of XtPopup rather than XtRealizeWidget for topLevels */

    #ifdef MULTIPLE_APP_SHELLS
    XtRealizeWidget( shell2 );
    XtRealizeWidget( shell3 );
    XtRealizeWidget( shell4 );
    #else
    #ifdef POPUP_SHELL
    XtPopup ( shell2, XtGrabNone );
    XtPopup ( shell3, XtGrabNone );
    XtPopup ( shell4, XtGrabNone );
    #else
    XtRealizeWidget( shell2 );
    XtRealizeWidget( shell3 );
    XtRealizeWidget( shell4 );
    #endif
    #endif

    XtAppMainLoop (app_context);
    }


    -----------------------------------------------------------------------------
    END OF PART THREE

  4. Motif FAQ (Part 8 of 9)

    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.

    : "240"
    : "241"
    : "242"
    : "243"
    : "244"
    : "245"
    : "246"
    : "247"
    : "250"
    : "251"
    : "252"
    : "253"
    : "255"
    : "255"
    : "256"
    : "257"
    : "260"
    : "261"
    : "262"
    : "263"
    : "264
    : "265"
    : "266"
    : "267"
    : "240"
    : "271"
    : "272"
    : "273"
    : "274"
    : "275"
    : "276"
    : "277"
    : "300"
    : "301"
    : "302"
    : "303"
    : "304"
    : "305"
    : "306"
    : "307"
    : "310"
    : "311"
    : "312"
    : "313"
    : "314"
    : "315"
    : "316"
    : "317"
    : "320"
    : "321"
    : "322"
    : "323"
    : "324"
    : "325"
    : "326"
    : "327"
    : "330"
    : "331"
    : "332"
    : "333"
    : "334"
    : "335"
    : "336"
    : "337"
    : "340"
    : "341"
    : "342"
    : "343"
    : "344"
    : "345"
    : "346"
    : "347"
    : "350"
    : "351"
    : "352"
    : "353"
    : "354"
    : "355"
    : "356"
    : "357"
    : "360"
    : "361"
    : "362"
    : "363"
    : "364"
    : "365"
    : "366"
    : "367"
    : "370"
    : "371"
    : "372"
    : "373"
    : "374"
    : "375"
    : "376"
    : "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
    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

  5. Motif FAQ (Part 9 of 9)

    Archive-name: motif-faq/part9
    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: 293) Why doesn't the Help callback work on some widgets?
    [Last modified: May 95]

    Answer: If you press the help key the help callback of the widget with the
    keyboard focus is called (not the one containing the mouse). You can't get
    the help callback of a non-keyboard-selectable widget called. To get `context
    sensitive' help on these, you have to find the mouse, associate its position
    with a widget and then do the help.

    The X Resource, Issue 6, has an article on implementing context help in Motif
    in this manner, that is, using the mouse position to indicate the widget for
    which context help is desired, as well as using resources to specify the help.

    The demo program lets you toggle between using the method described in the
    article and XmTrackingLocate() for comparision purposes.

    Contributed by: Jay Schmidgall jay@vnet.ibm.com (author of the article
    mentioned above). Thanks to chen@adi.com (Franklin Chen) for correcting the
    URL.

    -----------------------------------------------------------------------------
    Subject: 294)* How can I implement "bubble help" or "tool tips" with Motif?
    [Last modified: Jan 02]

    Answer: Open Motif 2.2 includes a built-in ToolTips feature. The following
    material may be of interest to users of earlier versions of Motif.

    Gary Aviv (gary@compgen.com) informed this maintainer about the free LiteClue
    widget from Computer Generation, Inc. (http://www.compgen.com/). LiteClue is
    a widget which pops a one line help message when the user passes the pointer
    over another "watched" widget. This is known by various names in the industry
    such as hints, clues, tips, bubble help and balloon help. Technical
    documentation and source for the LiteClue widget are available from:

    http://www.compgen.com/widgets/LiteClue.html
    ftp://ftp.compgen.com/pub/widgets/LiteClue.tar.Z


    Ken Lee (http://www.rahul.net/kenton/) writes: A simple technique is to popup
    a shell containing your message whenever an enter event occurs (possibly
    delayed by a timer) and pop it down again after a leave event.

    David Lewis (dbl@ics.com) writes: To those resources I should add that the
    XmHTML sources (HTML parser, browser, etc) have this ToolTip/bubble-help/popup
    feature, in readily-usable code. In addition, the ICS EnhancementPak widget
    set (http://www.ics.com) has both a toolbar with built-in popups for its
    entries and a small library which adds popup capabilities to any widget.

    -----------------------------------------------------------------------------
    Subject: 295) Can I specify a widget in a resource file?

    Answer: This answer, which uses the Xmu library, is due to David Elliott. If
    the converter is added, then the name of a widget (a string) can be used in
    resource files, and will be converted to the appropriate widget.

    This code, which was basically stolen from the Athena Form widget, adds a
    String to Widget converter. I wrote it as a general routine that I call at
    the beginning of all of my programs, and made it so I could add other
    converters as needed (like String to Unit Type ;-).

    #include
    #include
    #include
    #include
    #include
    #include

    void
    setupConverters()
    {
    static XtConvertArgRec parentCvtArgs[] = {
    {XtBaseOffset, (caddr_t)XtOffset(Widget, core.parent),
    sizeof(Widget)}
    };
    XtAddConverter(XmRString, XmRWindow, XmuCvtStringToWidget,
    parentCvtArgs, XtNumber(parentCvtArgs));
    }


    -----------------------------------------------------------------------------
    Subject: 296) Why are only some of my translations are being installed? I
    have a translation table like the following, but only the first ones are
    getting installed and the rest are ignored.

    *Text.translations: #override \
    Ctrla: beginning-of-line() \n\
    Ctrle: end-of-line() \n\
    Ctrlf: forward-character() \n\

    Answer: Most likely, you have a space at the end of one of the lines (the
    first in this case).

    Ctrla: beginning-of-line() \n\
    ^ space here

    The second backslash in each line is there to protect the real newline
    character and so you must not follow it with anything other than the newline
    itself. Otherwise it acts as the end of the resource definition and the
    remaining lines are not added.

    -----------------------------------------------------------------------------
    Subject: 297) Can I have separate translations for shifted and unshifted
    keys?
    [Last modified: Jan 99]

    Answer: Alec Flett writes:

    I've got an addition for the motif FAQ that just solved a problem I've been
    wrestling with for a month - it's really an addition to #303 "Why are only
    some of my translations being installed?"

    On certain platforms you cannot use an upper-case key in combination with the
    Shift modifier. For example,

    Meta Shift F: find-in-list()

    will not always work because the F is capitalized.

    The reason for this is because some platforms (such as IRIX) distinguish upper
    case and lowercase keysyms. Using Jamie Zawinski's xkeycaps program
    (http://www.jwz.org/xkeycaps/), you will see that on Solaris the "F" key just
    has one keysym: "F" On IRIX they same key has two: "f" and "F".

    -----------------------------------------------------------------------------
    Subject: 298) What are these "non-existant passive grab" warnings? When I
    destroy certain widgets I get a stream of messages

    Warning: Attempt to remove non-existant passive grab


    Answer: They are meaningless, and you want to ignore them. Do this (from Kee
    Hinckley) by installing an XtWarning handler that explicitly looks for them
    and discards them:

    static void xtWarnCB(String message) {
    if (asi_strstr(message, "non-existant passive grab", TRUE)) return;
    ...

    They come from Xt, and (W. Scott Meeks): "it's something that the designers of
    Xt decided the toolkit should do. Unfortunately, Motif winds up putting
    passive grabs all over the place for the menu system. On the one hand, we
    want to remove all these grabs when menus get destroyed so that they don't
    leak memory; on the other hand, it's almost impossible to keep track of all
    the grabs, so we have a conservative strategy of ungrabbing any place where a
    grab could have been made and we don't explicitly know that there is no grab.
    The unfortunate side effect is the little passive grab warning messages.
    We're trying to clean these up where possible, but there are some new places
    where the warning is generated. Until we get this completely cleaned up (1.2
    maybe), your best bet is probably to use a warning handler."

    -----------------------------------------------------------------------------
    Subject: 299) How do I have more buttons than three in a MessageBox? I want
    to have something like a MessageBox (or other widget) with more than three


    buttons, but with the same nice appearance.
    [Last modified: Feb 95]

    Answer: The Motif 1.2 MessageBox widget allows extra buttons to be added after
    the OK button. Just create the extra buttons as children of the MessageBox.
    Similarly with the SelectionBox.

    Pre-Motif 1.2, you have to do one of the following methods.

    A SelectionBox is created with four buttons, but the fourth (the Apply button)
    is unmanaged. To manage it get its widget ID via
    XmSelectionBoxGetChild(parent, XmDIALOG_APPLY_BUTTON) and then XtManage it.
    Unmanage all of the other bits in the SelectionBox that you don't want. If
    you want more than four buttons, try two SelectionBoxes (or similar) together
    in a container, where all of the unwanted parts of the widgets are unmanaged.

    Alternatively, build your own dialog:

    /* Written by Dan Heller. Copyright 1991, O'Reilly && Associates.
    * This program is freely distributable without licensing fees and
    * is provided without guarantee or warranty expressed or implied.
    * This program is -not- in the public domain. This program is
    * taken from the Motif Programming Manual, O'Reilly Volume 6.
    */

    /* action_area.c -- demonstrate how CreateActionArea() can be used
    * in a real application. Create what would otherwise be identified
    * as a PromptDialog, only this is of our own creation. As such,
    * we provide a TextField widget for input. When the user presses
    * Return, the Ok button is activated.
    */
    #include
    #include
    #include
    #include
    #include
    #include
    #include
    #include

    typedef struct {
    char *label;
    void (*callback)();
    caddr_t data;
    } ActionAreaItem;

    static void
    do_dialog(), close_dialog(), activate_cb(),
    ok_pushed(), cancel_pushed(), help();

    main(argc, argv)
    int argc;
    char *argv[];
    {
    Widget toplevel, button;
    XtAppContext app;

    toplevel = XtVaAppInitialize(&app, "Demos",
    NULL, 0, &argc, argv, NULL, NULL);

    button = XtVaCreateManagedWidget("Push Me",
    xmPushButtonWidgetClass, toplevel, NULL);
    XtAddCallback(button, XmNactivateCallback, do_dialog, NULL);

    XtRealizeWidget(toplevel);
    XtAppMainLoop(app);
    }

    /* callback routine for "Push Me" button. Actually, this represents
    * a function that could be invoked by any arbitrary callback. Here,
    * we demonstrate how one can build a standard customized dialog box.
    * The control area is created here and the action area is created in
    * a separate, generic routine: CreateActionArea().
    */
    static void
    do_dialog(w, file)
    Widget w; /* will act as dialog's parent */
    char *file;
    {
    Widget dialog, pane, rc, label, text_w, action_a;
    XmString string;
    extern Widget CreateActionArea();
    Arg args[10];
    static ActionAreaItem action_items[] = {
    { "Ok", ok_pushed, NULL },
    { "Cancel", cancel_pushed, NULL },
    { "Close", close_dialog, NULL },
    { "Help", help, "Help Button" },
    };

    /* The DialogShell is the Shell for this dialog. Set it up so
    * that the "Close" button in the window manager's system menu
    * destroys the shell (it only unmaps it by default).
    */
    dialog = XtVaCreatePopupShell("dialog",
    xmDialogShellWidgetClass, XtParent(w),
    XmNtitle, "Dialog Shell", /* give arbitrary title in wm */
    XmNdeleteResponse, XmDESTROY, /* system menu "Close" action */
    NULL);

    /* now that the dialog is created, set the Close button's
    * client data, so close_dialog() will know what to destroy.
    */
    action_items[2].data = (caddr_t)dialog;

    /* Create the paned window as a child of the dialog. This will
    * contain the control area (a Form widget) and the action area
    * (created by CreateActionArea() using the action_items above).
    */
    pane = XtVaCreateWidget("pane", xmPanedWindowWidgetClass, dialog,
    XmNsashWidth, 1,
    XmNsashHeight, 1,
    NULL);

    /* create the control area (Form) which contains a
    * Label gadget and a List widget.
    */
    rc = XtVaCreateWidget("control_area", xmRowColumnWidgetClass, pane, NULL);
    string = XmStringCreateLocalized("Type Something:");
    XtVaCreateManagedWidget("label", xmLabelGadgetClass, rc,
    XmNlabelString, string,
    XmNleftAttachment, XmATTACH_FORM,
    XmNtopAttachment, XmATTACH_FORM,
    NULL);
    XmStringFree(string);

    text_w = XtVaCreateManagedWidget("text-field",
    xmTextFieldWidgetClass, rc, NULL);

    /* RowColumn is full -- now manage */
    XtManageChild(rc);

    /* Set the client data "Ok" and "Cancel" button's callbacks. */
    action_items[0].data = (caddr_t)text_w;
    action_items[1].data = (caddr_t)text_w;

    /* Create the action area -- we don't need the widget it returns. */
    action_a = CreateActionArea(pane, action_items, XtNumber(action_items));

    /* callback for Return in TextField. Use action_a as client data */
    XtAddCallback(text_w, XmNactivateCallback, activate_cb, action_a);

    XtManageChild(pane);
    XtPopup(dialog, XtGrabNone);
    }

    /*--------------*/
    /* The next four functions are the callback routines for the buttons
    * in the action area for the dialog created above. Again, they are
    * simple examples, yet they demonstrate the fundamental design approach.
    */
    static void
    close_dialog(w, shell)
    Widget w, shell;
    {
    XtDestroyWidget(shell);
    }

    /* The "ok" button was pushed or the user pressed Return */
    static void
    ok_pushed(w, text_w, cbs)
    Widget w, text_w; /* the text widget is the client data */
    XmAnyCallbackStruct *cbs;
    {
    char *text = XmTextFieldGetString(text_w);

    printf("String = %s0, text);
    XtFree(text);
    }

    static void
    cancel_pushed(w, text_w, cbs)
    Widget w, text_w; /* the text field is the client data */
    XmAnyCallbackStruct *cbs;
    {
    /* cancel the whole operation; reset to NULL. */
    XmTextFieldSetString(text_w, "");
    }

    static void
    help(w, string)
    Widget w;
    String string;
    {
    puts(string);
    }
    /*--------------*/

    /* When Return is pressed in TextField widget, respond by getting
    * the designated "default button" in the action area and activate
    * it as if the user had selected it.
    */
    static void
    activate_cb(text_w, client_data, cbs)
    Widget text_w; /* user pressed Return in this widget */
    XtPointer client_data; /* action_area passed as client data */
    XmAnyCallbackStruct *cbs; /* borrow the "event" field from this */
    {
    Widget dflt, action_area = (Widget)client_data;

    XtVaGetValues(action_area, XmNdefaultButton, &dflt, NULL);
    if (dflt) /* sanity check -- this better work */
    /* make the default button think it got pushed. This causes
    * "ok_pushed" to be called, but XtCallActionProc() causes
    * the button appear to be activated as if the user selected it.
    */
    XtCallActionProc(dflt, "ArmAndActivate", cbs->event, NULL, 0);
    }

    #define TIGHTNESS 20

    Widget
    CreateActionArea(parent, actions, num_actions)
    Widget parent;
    ActionAreaItem *actions;
    int num_actions;
    {
    Widget action_area, widget;
    int i;

    action_area = XtVaCreateWidget("action_area", xmFormWidgetClass, parent,
    XmNfractionBase, TIGHTNESS*num_actions - 1,
    XmNleftOffset, 10,
    XmNrightOffset, 10,
    NULL);

    for (i = 0; i < num_actions; i++) {
    widget = XtVaCreateManagedWidget(actions[i].label,
    xmPushButtonWidgetClass, action_area,
    XmNleftAttachment, i? XmATTACH_POSITION : XmATTACH_FORM,
    XmNleftPosition, TIGHTNESS*i,
    XmNtopAttachment, XmATTACH_FORM,
    XmNbottomAttachment, XmATTACH_FORM,
    XmNrightAttachment,
    i != num_actions-1? XmATTACH_POSITION : XmATTACH_FORM,
    XmNrightPosition, TIGHTNESS*i + (TIGHTNESS-1),
    XmNshowAsDefault, i == 0,
    XmNdefaultButtonShadowThickness, 1,
    NULL);
    if (actions[i].callback)
    XtAddCallback(widget, XmNactivateCallback,
    actions[i].callback, actions[i].data);
    if (i == 0) {
    /* Set the action_area's default button to the first widget
    * created (or, make the index a parameter to the function
    * or have it be part of the data structure). Also, set the
    * pane window constraint for max and min heights so this
    * particular pane in the PanedWindow is not resizable.
    */
    Dimension height, h;
    XtVaGetValues(action_area, XmNmarginHeight, &h, NULL);
    XtVaGetValues(widget, XmNheight, &height, NULL);
    height += 2 * h;
    XtVaSetValues(action_area,
    XmNdefaultButton, widget,
    XmNpaneMaximum, height,
    XmNpaneMinimum, height,
    NULL);
    }
    }

    XtManageChild(action_area);

    return action_area;
    }


    -----------------------------------------------------------------------------
    Subject: 300) How do I create a "busy working cursor"?
    [Last modified: Feb 95]

    Answer: - in Baudouin's code (following), the idea is to keep in an array an
    up-to-date list of all shells used in the application, and set for all of them
    the cursor to a watch or to the default cursor, with the 2 functions provided.

    - in Dan Heller's code (later), the idea is to turn on the watch cursor for
    the top-level shell only, popup a working window to possibly abort the
    callback, and manage some expose events during the callback.

    - in the FAQ for comp.windows.x, the idea is to bring a large window on top of
    the application, hide all windows below it, and turn on the watch cursor on
    this large window. Unmapping the large window resets the default cursor,
    mapping it turns on the watch cursor.

    Baudouin Raoult (mab@ecmwf.int) wrote:

    void my_SetWatchCursor(w)
    Widget w;
    {
    static Cursor watch = NULL;

    if(!watch)
    watch = XCreateFontCursor(XtDisplay(w),XC_watch);

    XDefineCursor(XtDisplay(w),XtWindow(w),watch);
    XmUpdateDisplay(w);
    }

    void my_ResetCursor(w)
    Widget w;
    {
    XUndefineCursor(XtDisplay(w),XtWindow(w));
    XmUpdateDisplay(w);
    }


    Answer: A solution with lots of bells and whistles is

    /* Written by Dan Heller. Copyright 1991, O'Reilly && Associates.
    * This program is freely distributable without licensing fees and
    * is provided without guarantee or warrantee expressed or implied.
    * This program is -not- in the public domain.
    */

    /* busy.c -- demonstrate how to use a WorkingDialog and to process
    * only "important" events. e.g., those that may interrupt the
    * task or to repaint widgets for exposure. Set up a simple shell
    * and a widget that, when pressed, immediately goes into its own
    * loop. First, "lock" the shell so that a timeout cursor is set on
    * the shell and pop up a WorkingDialog. Then enter loop ... sleep
    * for one second ten times, checking between each interval to see
    * if the user clicked the Stop button or if any widgets need to be
    * refreshed. Ignore all other events.
    *
    * main() and get_busy() are stubs that would be replaced by a real
    * application; all other functions can be used "as is."
    */
    #include
    #include
    #include

    Widget shell;
    void TimeoutCursors();
    Boolean CheckForInterrupt();

    main(argc, argv)
    int argc;
    char *argv[];
    {
    XtAppContext app;
    Widget button;
    XmString label;
    void get_busy();

    shell = XtVaAppInitialize(&app, "Demos",
    NULL, 0, &argc, argv, NULL, NULL);

    label = XmStringCreateLocalized(
    "Boy, is *this* going to take a long time.");
    button = XtVaCreateManagedWidget("button",
    xmPushButtonWidgetClass, shell,
    XmNlabelString, label,
    NULL);
    XmStringFree(label);
    XtAddCallback(button, XmNactivateCallback, get_busy, argv[1]);

    XtRealizeWidget(shell);
    XtAppMainLoop(app);
    }

    void
    get_busy(widget)
    Widget widget;
    {
    int n;

    TimeoutCursors(True, True);
    for (n = 0; n < 10; n++) {
    sleep(1);
    if (CheckForInterrupt()) {
    puts("Interrupt!");
    break;
    }
    }
    if (n == 10)
    puts("done.");
    TimeoutCursors(False, NULL);
    }

    /* The interesting part of the program -- extract and use at will */
    static Boolean stopped; /* True when user wants to stop processing */
    static Widget dialog; /* WorkingDialog displayed when timed out */

    /* timeout_cursors() turns on the "watch" cursor over the application
    * to provide feedback for the user that he's going to be waiting
    * a while before he can interact with the appliation again.
    */
    void
    TimeoutCursors(on, interruptable)
    int on, interruptable;
    {
    static int locked;
    static Cursor cursor;
    extern Widget shell;
    XSetWindowAttributes attrs;
    Display *dpy = XtDisplay(shell);
    XEvent event;
    Arg args[1];
    XmString str;
    extern void stop();

    /* "locked" keeps track if we've already called the function.
    * This allows recursion and is necessary for most situations.
    */
    on? locked++ : locked--;
    if (locked > 1 || locked == 1 && on == 0)
    return; /* already locked and we're not unlocking */

    stopped = False; /* doesn't matter at this point; initialize */
    if (!cursor) /* make sure the timeout cursor is initialized */
    cursor = XCreateFontCursor(dpy, XC_watch);

    /* if "on" is true, then turn on watch cursor, otherwise, return
    * the shell's cursor to normal.
    */
    attrs.cursor = on? cursor : None;

    /* change the main application shell's cursor to be the timeout
    * cursor (or to reset it to normal). If other shells exist in
    * this application, they will have to be listed here in order
    * for them to have timeout cursors too.
    */
    XChangeWindowAttributes(dpy, XtWindow(shell), CWCursor, &attrs);

    XFlush(dpy);

    if (on) {
    /* we're timing out, put up a WorkingDialog. If the process
    * is interruptable, allow a "Stop" button. Otherwise, remove
    * all actions so the user can't stop the processing.
    */
    str = XmStringCreateLocalized("Busy. Please Wait.");
    XtSetArg(args[0], XmNmessageString, str);
    dialog = XmCreateWorkingDialog(shell, "Busy", args, 1);
    XmStringFree(str);
    XtUnmanageChild(
    XmMessageBoxGetChild(dialog, XmDIALOG_OK_BUTTON));
    if (interruptable) {
    str = XmStringCreateLocalized("Stop");
    XtVaSetValues(dialog, XmNcancelLabelString, str, NULL);
    XmStringFree(str);
    XtAddCallback(dialog, XmNcancelCallback, stop, NULL);
    } else
    XtUnmanageChild(
    XmMessageBoxGetChild(dialog, XmDIALOG_CANCEL_BUTTON));
    XtUnmanageChild(
    XmMessageBoxGetChild(dialog, XmDIALOG_HELP_BUTTON));
    XtManageChild(dialog);
    } else {
    /* get rid of all button and keyboard events that occured
    * during the time out. The user shouldn't have done anything
    * during this time, so flush for button and keypress events.
    * KeyRelease events are not discarded because accelerators
    * require the corresponding release event before normal input
    * can continue.
    */
    while (XCheckMaskEvent(dpy,
    ButtonPressMask | ButtonReleaseMask | ButtonMotionMask
    | PointerMotionMask | KeyPressMask, &event)) {
    /* do nothing */;
    }
    XtDestroyWidget(dialog);
    }
    }

    /* User Pressed the "Stop" button in dialog. */
    void
    stop(dialog)
    Widget dialog;
    {
    stopped = True;
    }

    Boolean
    CheckForInterrupt()
    {
    extern Widget shell;
    Display *dpy = XtDisplay(shell);
    Window win = XtWindow(dialog);
    XEvent event;

    /* Make sure all our requests get to the server */
    XFlush(dpy);

    /* Let motif process all pending exposure events for us. */
    XmUpdateDisplay(shell);

    /* Check the event loop for events in the dialog ("Stop"?) */
    while (XCheckMaskEvent(dpy,
    ButtonPressMask | ButtonReleaseMask | ButtonMotionMask |
    PointerMotionMask | KeyPressMask | KeyReleaseMask,
    &event)) {
    /* got an "interesting" event. */
    if (event.xany.window == win)
    XtDispatchEvent(&event); /* it's in our dialog.. */
    else /* uninteresting event--throw it away and sound bell */
    XBell(dpy, 50);
    }
    return stopped;
    }


    -----------------------------------------------------------------------------
    Subject: 301) Can I use the hourglass that mwm uses?
    [Last modified: March 93]

    Answer: The hourglass used by mwm is hard-coded into code that is subject to
    OSF copyright. In Motif 1.2 though, the bitmaps for this and other things
    (information, no_enter, question, warning, working) were made available. The
    install process will probably add them to /usr/include/X11/bitmaps.
    Otherwise, just use the watch cursor XC_watch of the previous question,
    because that has the same semantics.

    -----------------------------------------------------------------------------
    Subject: 302) What order should the libraries be linked in?
    [Last modified: August 92]

    Answer: At link time, use the library order -lXm -lXt -lX11. There are two
    reasons for this (dbrooks@osf.org):

    On most systems, the order matters because the linker won't re-scan a library
    once it is done with it. Thus any references to Xlib calls from Xm will
    probably be unresolved.

    The [other] problem is that there are two VendorShell widgets. A dummy is
    provided in the Xt library, but a widget set will rely on its own being
    referenced. If you mention Xt first, the linker will choose the wrong one.

    Motif code will wrongly assume the Motif VendorShell has been class-
    initialized [and will probably crash]. Xaw has a similar problem, but a
    softer landing; it only complains about unregistered converters.


    -----------------------------------------------------------------------------
    Subject: 303) How do I use xmkmf for Motif clients?
    [Last modified: July 96]

    Answer: This advice comes from dbrooks@osf.org. For another answer, see the
    question immediately following this one ("How do I use imake with Motif
    2.0?").

    There are a number of intractable problems with using X configuration files
    and xmkmf, while trying to make it easy to build Motif. Not the least of
    these, but one I've never heard mentioned yet, is that the rules for
    contructing the names of shared library macros are machine-dependent, and in
    the various xxxLib.tmpl files. Do we edit all those files to add definitions
    for XMLIB, DEPXMLIB, etc., or do we put a maze of #ifdefs into the Motif.tmpl
    file?

    Please note that, if you install Motif, it overwrites your installed
    Imake.tmpl with one that includes Motif.tmpl and Motif.rules.

    With those caveats, I think the following guidelines will help.

    David Brooks OSF

    Clients in the X11R5 release use the xmkmf command to build Makefiles. In
    general, the xmkmf command cannot be used for Motif clients, because of the
    need to consider the UseInstalledMotif flag separately. Since xmkmf is a
    simple script that calls imake, it is easy to construct the proper call to
    imake using the following rules.

    In the following, replace {MTOP} by the toplevel directory with the Motif
    source tree, and {XTOP} by the toplevel ("mit") directory with the X source.
    It is assumed that the directory containing your installed imake is in your
    PATH.

    When needed, the imake variables XTop and MTop are normally set in your
    site.def (to {XTOP} amd {MTOP} respectively); however they may also be set
    with additional -D arguments to imake.

    1. With both X and Motif in their source trees, ensure the imake variables
    XTop and MTop are set, and use:

    ${XTOP}/config/imake -I{MTOP}/config

    2. With Motif in its source tree, and X installed, ensure MTop is set, and
    use:

    imake -I{MTOP}/config -DUseInstalled

    3. With both Motif and X installed, and a nonstandard ProjectRoot (see
    site.def for an explanation of this), use:

    imake -DUseInstalled -DUseInstalledMotif -I{ProjectRoot}/lib/X11/config

    or, if the configuration files are in /usr/lib/X11/config:

    imake -DUseInstalled -DUseInstalledMotif -I/usr/lib/X11/config

    [Thanks to Paul DuBois (dubois@primate.wisc.edu) for correcting this.]

    To build a simple Imakefile, remember to include lines like this:

    LOCAL_LIBRARIES = XmClientLibs
    DEPLIBS = XmClientDepLibs

    Or, for a client that uses uil/mrm, replace these by MrmClientLibs and
    MrmClientDepLibs, and also use:

    MSimpleUilTarget(program)

    to build the client and uid file. Look at the demos for more examples.


    And Paul Howell added:

    i did this, calling the new script "xmmkmf". It passes both -DUseInstalled
    and -DUseInstalledMotif.

    and i modified the stock R5 Imake.tmpl to do this:

    #include
    #ifdef UseInstalledMotif
    #include
    #endif

    #include
    #ifdef UseInstalledMotif
    #include
    #endif

    the result was something that does both athena and motif rules. and it really
    works, just that easy!

    -----------------------------------------------------------------------------
    Subject: 304) How do I use imake with Motif 2.0?
    [Last modified: July 96]

    Answer: Paul DuBois (dubois@primate.wisc.edu), the author of the O'Reilly and
    Associates book, Software Portability with imake, recently wrote some notes on
    the use of imake to configure Motif (2.0). It has some discussion on the roles
    of UseInstalled and UseInstalledMotif, for instance, which seem to be murky to
    many people. The document is available at:

    http://www.primate.wisc.edu/software/imake-stuff

    -----------------------------------------------------------------------------
    Subject: 305) How do I make context sensitive help? The Motif Style Guide
    says that an application must initiate context-sensitive help by changing the
    shape of the pointer to the question pointer. When the user moves the pointer
    to the component help is wanted on and presses BSelect, any available context
    sensitive help for the component must be presented, and the pointer reverts
    from the question pointer.
    [Last modified: August 92]

    Answer: A widget that gives context sensitive help would place this help in
    the XmNhelpCallback function. To trigger this function: (from Martin G C
    Davies, mgcd@se.alcbel.be)

    I use the following callback that is called when the "On Context" help
    pulldown menu is selected. It does the arrow bit and calls the help callbacks
    for the widget. It also zips up the widget tree looking for help if needs be.
    I don't restrict the arrows motion so I can get help on dialog boxes. No
    prizes for guessing what "popup_message" does.


    static void ContextHelp(
    Widget w ,
    Opaque * tag ,
    XmAnyCallbackStruct * callback_struct
    )
    {
    static Cursor context_cursor = NULL ;
    Widget context_widget ;

    if ( context_cursor == NULL )
    context_cursor = XCreateFontCursor( display, XC_question_arrow ) ;

    context_widget = XmTrackingLocate( top_level_widget,
    context_cursor, FALSE ) ;

    if ( context_widget != NULL ) /* otherwise its not a widget */
    {
    XmAnyCallbackStruct cb ;

    cb.reason = XmCR_HELP ;
    cb.event = callback_struct->event ;

    /*
    * If there's no help at this widget we'll track back
    up the hierarchy trying to find some.
    */

    do
    {
    if ( ( XtHasCallbacks( context_widget, XmNhelpCallback ) ==
    XtCallbackHasSome ) )
    {
    XtCallCallbacks( context_widget, XmNhelpCallback, & cb ) ;
    return ;
    }
    else
    context_widget = XtParent( context_widget ) ;
    } while ( context_widget != NULL ) ;
    }

    popup_message( "No context-sensitive help found0or the selected object." ) ;
    }


    Dave Bonnett suggested, to use the following translations for XmText (and
    XmTextField) widgets to get the same help with key strokes, and to provide an
    accelerator label in the Context help menu entry.

    MyApp*XmText*translations: #override\n\
    F1: Help()

    MyApp*Help_menu*Contextual Help.acceleratorText: F1

    MyApp*defaultVirtualBindings: osfBackSpace : Delete\n\
    osfRight : Right\n\
    osfLeft : Left\n\
    osfUp : Up\n\
    osfHelp : F1\n\
    osfDown : Down


    -----------------------------------------------------------------------------
    Subject: 306) How do I debug a modal interaction?

    When an application crashes in a modal section (such as in a modal dialog, a
    menu or when a drag and drop is in action), I cannot access the debugger.
    [Last modified: January 1993]

    Answer: Run the debugger on one display while the application writes to
    another display.

    -----------------------------------------------------------------------------
    Subject: 307) Why can't I install my own colormap using XInstallColormap?
    [Last modified: Nov 96]

    Answer: You shouldn't install the colormap yourself using XInstallColormap.
    See the ICCCM document for all the reasons. Instead put the colormap as an
    argument on the Shell widget and the window manager will take care of this.

    When the colormap is installed, unless you have a display with multiple
    colormaps, the other windows will go "technicolor" and there is no way around
    this problem.

    Thanks to Doug Rand (drand@sgi.com)

    Kenton Lee (http://www.rahul.net/kenton/) adds: Use XtSetWMColormapWindows()
    to specify non-default colormaps.

    -----------------------------------------------------------------------------
    Subject: 308) How do I install a private colormap?
    [Last modified: Jan 96]

    Answer: Mark Buser (buser@tartan.com) writes: If you find that your
    XAllocNamedColor is failing or XpmCreatePixmapFromData is dieing from
    XpmColorFaileds, you may have exhausted the number of colormap entries. One
    way to install a new colormap is the following:


    Toplevel = XtVaAppInitialize ( &app, ...
    dpy = XtDisplay (Toplevel);
    cmap = DefaultColormapOfScreen ( XtScreen( Toplevel) );
    /* Detect color errors due to colormap depletion */
    if (colors_depleted) {
    cmap = XCopyColormapAndFree ( dpy, cmap );

    /* Run through color allocation again to see if ok now */
    }

    /* Install colormap into toplevel widget. This must be done
    ** before any child widgets are created.
    */
    XtVaSetValues ( Toplevel, XmNcolormap, cmap, NULL);

    /* Create any children of toplevel, they will inherit new colormap */


    This is only one way to go, there are other possibilities, but this seems to
    be the simplest.

    -----------------------------------------------------------------------------
    Subject: 309) How do I get correct shadow colors to match other color
    changes?
    [Last modified: Sept 95]

    Answer: Thanks to Craig MacFarlane (craigm@chateau-rouge.ICS.UCI.EDU) for the
    following explanation and code:

    You have to make a call to calculate the new shadow colors. The trick is
    actually getting a value of type Pixel when all you have is the string "Blue".
    I use the XtConvertAndStore() function to convert from a char * to a Pixel.
    For example:


    char *color = "blue";
    XrmValue color_value, pixel_value;
    Pixel background;

    color_value.size = strlen(color);
    color_value.addr = (XtPointer) color;
    pixel_value.size = sizeof(Pixel);
    pixel_value.addr = (XtPointer) 0;

    result = XtConvertAndStore(widget,
    XtRString, &color_value,
    XtRPixel, &pixel_value);

    background = (*(Pixel *)pixel_value.addr);


    You can then use the pixel value obtained by XtConvertAndStore() in the
    XmGetColors call. XmGetColors calculates appropriate foreground, topshadow,
    bottomshadow, and select colors for the given background. e.g.


    XmGetColors(screen,
    DefaultColormap(display_id, DefaultScreen(display_id)),
    background,
    &foreground, &topshadow, &bottomshadow, &select);


    Then it's trivial to set the shadow colors at the same time you set the
    foreground and background colors. For example:


    XtVaSetValues(widget,
    XmNforeground, foreground,
    XmNbackground, background,
    XmNarmColor, select,
    XmNtopShadowColor, topshadow,
    XmNbottomShadowColor, bottomshadow,
    NULL);


    You'll get asthetically pleasing colors every time.

    Wolfram Gries <1gries@informatik.uni-hamburg.de> adds:

    The function XmChangeColor() takes a Widget and a Pixel-value for the new
    background-color and does the calculation of the new shadow-colors on its own.
    But it seems to me that this function is rather slow, so if you often change
    the color of your widgets, the XmGetColors()/XmSetColors() approach might be
    better.

    -----------------------------------------------------------------------------
    Subject: 310) What color algorithm does Motif use? I am told that Motif uses
    some sort of algorithm that will take a single color that is defined for the
    "background" and scale it so that the widget remains discriminable from the
    background, etc. What is the algorithm?
    [Last modified: Oct 94]

    Answer: Chris Flatters (cflatter@nrao.edu) writes: Shiz Kobara's book "Visual
    Design with OSF/Motif", Addison Wesley, 1991, ISBN 0-201-56320-7) is a good
    source for information of this sort. I haven't seen it in bookshops for a
    while so it may have gone out of print (which would be a pity). In essence
    each widget has 4 colours which, to first order, are

    background
    select (background * 85%)
    top shadow (background * 150%)
    bottom shadow (background * 50%)

    An additional correction may be applied to the hues of the calculated colours
    if any of the RGB values saturates. The algorithm works best if the brightest
    of the RGB components lies in the range 155-175 (on a scale of 0-255). The
    top shadow becomes darker than the background for light background colours
    which does not lead to a particularly pleasing effect.

    -----------------------------------------------------------------------------
    Subject: 311) How can you access the superclass widget from which Motif
    convenience dialogs are subclassed?
    [Last modified: Oct 94]

    Answer: Kim Frei (uunet!ask.uniras.dk!kimf) wrote: If you are using Motif 1.2,
    read about XmTemplateDialog.

    -----------------------------------------------------------------------------
    Subject: 312) Can the Motif 2.0 Notebook widget display non-rectangular "file
    tabs"? Is it possible to use the Shape extension to fiddle with the shape of
    the major tabs (XmPushButtons right now) to get non-rectangular buttons, going
    for that "file tab" look?
    [Last modified: May 95]

    Answer: Vania Joloboff wrote:

    On the Motif 2.0* CD-ROM, in the demos directory, there is a library of
    additional widgets lib/Exm. Among the widgets, there is a ExmTabButton
    especially designed to fit within a Notebook. It has a smooth shape like real
    tabs in folders.


    It also a good example on how to use the new traits and the Xme API for widget
    writers.

    (Thanks to Ken Lee, http://www.rahul.net/kenton/, for a correction here.)

    -----------------------------------------------------------------------------
    Subject: 313) How does the clipboard mechanism work?
    [Last modified: Dec 94]

    A. Doug Rand writes:

    Basically there are two selections CLIPBOARD_MANAGER and CLIPBOARD which are
    used. The Motif clipboard is not a clipboard manager, but xclipboard, or a
    more functional clipboard client would be. The newest ICCCM (2.0) spells this
    out.

    The basic process is that the clipboard manager:

    1) Check to see if CLIPBOARD_MANAGER is owned by anyone, abort if it is.

    2) Assert ownership of CLIPBOARD_MANAGER and CLIPBOARD

    3) When the CLIPBOARD selection is lost, query new owner for data and then
    retake ownership of CLIPBOARD

    #3 is done until the application exists. What you do with the data is up to
    the application.

    -----------------------------------------------------------------------------
    Subject: 314) Why does the xyz application core dump when I cut and paste?

    Answer: Application crashes when text is cut and pasted into an XmText widget
    may occur with statically linked executables linked with X11R5 libraries under
    SunOS. For example, a Netscape README file says:

    The SunOS 4.1 [Netscape 0.94] distribution also includes a directory called
    "nls". This directory is a standard part of the MIT X11R5 distribution, but
    is not included with OpenWindows 3.0 or earlier. We have linked Netscape
    against the MIT R5 libraries because they are less buggy in general; however,
    they have one rather serious bug, which is that if this "nls" directory does
    not exist, the program will dump core any time you try to paste into a text
    field!

    So, if you don't have the "nls" directory on your system, you will need to
    install it first. The usual place is /usr/lib/X11/nls, but you can put it
    anywhere: just point the $XNLSPATH environment variable at it.

    Some sites don't have their X libraries installed in /usr/lib/X11/. This
    doesn't matter. You either need to put the nls directory in /usr/lib/X11/, or
    every user will need to set this environment variable.

    So, for example, we do:

    setenv XNLSPATH /usr/local/x11r5/lib/X11/nls

    since our X11R5 is not installed in the default location.

    -----------------------------------------------------------------------------
    Subject: 315) Why is XtWindow(widget) == 0?
    [Last modified: Oct 95]

    Answer: The window is not created (and is NULL) until the widget is realized.
    In general, using XtWindow() is a bad idea. In most cases, you can create
    more robust code by subclassing the widget and putting your window code in new
    wiget class methods.

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 316) How do I debug X protocol errors (e.g., BadWindow, BadMatch) in
    Motif applications?

    [Last modified: Jun 98]
    Answer: For a general tutorial on X protocol errors, see:

    http://www.rahul.net/kenton/perrors.html


    Here are two common problems. First, if you get a BadWindow error showing a
    0x0 window ID, you're probably calling XtWindow() on a widget that is not
    realized. See the previous subject.

    Second, a BadMatch error often indicates that the depth of a window or a
    pixmap is not correct. You could be using a depth 1 pixmap when you should be
    using a pixmap with the depth of the associated window. Or, you could be
    creating a new shell with a depth that does not match its visual type or
    colormap.

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 317) Why doesn't XtNameToWidget (widget, "MyName") work?
    [Last modified: Apr 95]

    Answer: The second argument must be a qualified specification (like a resource
    specification). In most cases, you'll use something like "*MyName". The
    leading '*' is required.

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 318) Why does my callback's client data structure contain incorrect
    values when the callback is called? I created a structure and used a pointer
    to it as callback client data.
    [Last modified: Apr 95]

    Answer: If your structure is declared as automatic, the callback will probably
    not be executed within the structure's scope, so the pointer to the structure
    will become invalid. You can avoid this problem by declaring your structure
    external or by allocating with malloc or (in C++) new.

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 319) How can an application manage events on multiple displays?
    [Last modified: May 95]

    Answer: Just put multiple display pointers into one application context. (You
    normally specify which application context as an argument to XtOpenDisplay()).
    XtAppNextEvent() and XtAppMainLoop() automatically poll all displays in the
    application context.

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 320) Can a Motif application create windows on mutiple screens (on a
    multi-screen workstation)?
    [Last modified: Sep 97]

    Answer: Multiple screens is simpler than multiple displays, since one X server
    controls all of the screens. Simply specify the XmNscreen resource when you
    create your top level (or other) shell widget and the X Toolkit will create
    the shell on that screen. You should generally also explicitly set your
    XmNcolormap, XmNdepth, and XmNvisual resources for the new shell, since the
    defaults may not be valid on the second screen.

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 321) Why do I get "Error: attempt to add non-widget child "dsm" to
    parent"?
    [Last modified: May 95]

    Answer: Most likely, you are linking your libraries in the wrong order. You
    must link -lXm *before* -lXt.

    Ken Lee

    Ken Sall (ksall@cen.com) adds: This same error occurs if you combine Motif and
    Athena widgets in the same application. If you link with "-lXaw" before "-
    lXm", you get the runtime error. However, if you switch the order of the two
    libraries, there is no problem. For example:

    cc mothena.c -o mothena -lXm -lXaw -lXt -lXmu -lX11


    -----------------------------------------------------------------------------
    Subject: 322) Why do I get link errors about "XShape" symbols?
    [Last modified: May 95]

    Answer: You must link with the X extensions library, -lXext, after any widget
    libraries. For example,

    cc -o myapp myapp.o -lXm -lXt -lXext -lX11

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 323) Why do I get link errors about "ICE" and "SM" symbols?
    [Last modified: Sep 97]

    Answer: You must link with the the X ICE and/or SM libraries. For example,

    cc -o myapp myapp.o -lXm -lXt -lXext -lICE -lSM -lX11

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 324) Why does my X11R6 program crash with undefined symbol
    "LowerCase"?
    [Last modified: May 95]

    Answer: If you are using Motif version 1.1.[123], then the problem may be a
    failure to set MotifBC to YES in your site.def.

    Thanks to Geoffrey Leach, geoff@netcom.com

    -----------------------------------------------------------------------------
    Subject: 325) How do I programatically control xwd to dump a specific window?
    I need a non-interactive way to tell xwd what X window to make an image of...
    NOT by the traditional point-and-click method.
    [Last modified: July 95]

    Answer: Ken Sall (ksall@cen.com) wrote:

    1. Get the window id of the toplevel shell widget using the "XtWindow"
    function.
    2. Invoke "xwd" from the program that has access to the window id, such as:

    Window dumpId; /* returned from XtWindow */
    sprintf (cmd_string, "xwd -frame -out tmp.xwd -id 0x%x", dumpId);
    system (cmd_string);


    -----------------------------------------------------------------------------
    Subject: 326) How can I display an xwd in a window (without using xwud)?
    [Last modified: Sept 95]

    Answer:

    1. read the xwd file into an XImage
    2. create a pixmap and XPutImage the image into the pixmap
    3. use the pixmap as the XmNlabelPixmap of a label widget

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 327) Can I write a multi-threaded Motif application?
    [Last modified: May 97]

    Answer: Motif 2.1 can be compiled to be thread-safe (if libX11 and libXt are
    also compiled to be thread-safe).

    Motif releases prior to Motif 2.1 were not thread-safe. In these releases,
    you can use Motif from one thread and do other things in other threads but you
    cannot call Motif functions from more than one thread.

    Try looking in the X FAQ for information on threads:

    http://www.cis.ohio-state.edu/hypert...x-faq/top.html
    ftp://ftp.x.org/contrib/faqs/FAQ

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 328) How can I dump my widget instance tree in a way that reflects
    the hierarchy?
    [Last modified: July 97]

    Answer: Jeremy Jameson (jameson@drmail.dr.att.com) posted this code to c.w.x.m
    in 5/95.

    [Note: this code does not consider popup children, which are not listed in
    the XmNchildren array. To find those, you have to peek at the popup_list in
    core widget record. - K.Lee 7/97]


    /************************************************** *****************************
    * dumpWidgetTree( Widget w )
    *
    * This function will recursively descend throught the Widget tree
    * and print the children and their pointer addresses.
    *
    * Jeremy Jameson 5/17/95
    *
    ************************************************** *****************************/

    static void dumpWidgetTree( Widget w )
    {
    WidgetList list = NULL;
    Cardinal num_children = 0;
    int i;
    static int n = 0;
    Widget child;
    static char* indent =
    "-----------------------------------------------------------------------------";
    char tmp[256];

    *tmp = ' ';

    if ( n >= strlen( indent ) +1 )
    {
    printf(
    "ERROR:Widget tree is too deep, not enough indent string ( < %d )!\n",
    n );
    n = 0;
    return;
    }

    strncpy( tmp, indent, n );
    tmp[n] = ' ';

    printf( "%s> Dumping widget tree of %s - %#x \n", tmp, XtName( w ), w );

    if ( ! XtIsComposite( w ) )
    {
    printf(
    "%s> %s is not a subclass of Composite and therefore has no children\n",
    tmp, XtName( w ) );
    return;
    }

    XtVaGetValues( w,
    XmNchildren, &list,
    XmNnumChildren, &num_children,
    NULL );

    printf( "%s> %s has %d %s\n", tmp, XtName( w ),
    num_children, num_children == 1 ? "child" : "children" );

    for ( i = 1; i <= num_children; i++ )
    {
    child = list[i-1];
    printf( "%s> child %2d %20s \t (%#x)\n", tmp, i, XtName( child ), child );
    }

    printf( "\n" );

    for ( i = 1; i <= num_children; i++ )
    {
    child = list[i-1];
    n += 3;
    dumpWidgetTree( child );

    n -= 3;
    }
    printf( "\n" );
    }


    -----------------------------------------------------------------------------
    Subject: 329) How do I get the events for gadgets? Or the name of the gadget?
    [Last modified: July 96]

    Answer: Get events from the gadget's parent. Ken Lee

    A related question is "How the name of a gadget an event is directed to?"
    Daniel Dardailler (daniel@x.org) writes:

    Motif 2.0 provides a XmObjectAtPoint public function that support this
    functionality. For earlier version, something like the undocumented
    _XmInputInGadget( wid, x, y ) should do it.

    _XmInputInGadget
    Given a composite widget and an (x, y) coordinate, see if the
    (x, y) lies within one of the gadgets contained within the
    composite. Return the gadget if found, otherwise return NULL.


    -----------------------------------------------------------------------------
    Subject: 330) Can I set the foreground and background colors of gadgets
    (e.g., convenience dialog buttons)?
    [Last modified: Nov 96]

    Answer: Not in Motif 1.x. Gadgets don't have their own colors, they use those
    of their parents. Notice that Motif's convenience dialogs generally use label
    gadgets, not widgets, so you cannot customize the colors of individual
    buttons.

    Beginning in Motif 2.0, gadgets do have their own color resources.

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 331) Can I use a gadget as the parent of a dialog shell?
    [Last modified: Dec 97]

    Answer: No. The Core widget class contains the functionality for popup
    children. Since the Gadget class is not a subclass of Core, gadgets cannot
    have popup children (like dialogs).

    -----------------------------------------------------------------------------
    Subject: 332) Which other widget features do gadgets lack?
    [Last modified: Dec 97]

    Answer: Here's a list from Asente & Swick (p. 397). Note that many of these
    restrictions are primarily of interest to widget (and gadget) writers, not to
    application writers.

    1. gadgets have no background or border colors or pixmaps
    2. gadgets cannot have event handlers
    3. gadgets have no translations, accelerators, or actions
    4. gadgets cannot have pop-up children
    5. gadgets cannot do grabs
    6. gadgets cannot redirect the Intrincis keyboard focus or take the X focus
    7. gadgets cannot own or request selections
    8. gadgets do not need to be and cannot be realized
    9. gadgets cannot have their window, display, or screen queried (but
    there are separate functions for computing these)
    10. gadgets have no stacking order


    -----------------------------------------------------------------------------
    Subject: 333) Where can I get the xmon or xscope programs to trace my X
    protocol?
    [Last modified: Mar 96]

    Answer: Both are included in the contrib section of X11R5:
    ftp://ftp.x.org/pub/R5/

    Xmon is also available at: ftp://ftp.x.org/contrib/devel_tools/ and
    ftp://ftp.crl.research.digital.com/p...b/devel_tools/

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 334) What does the error "Couldn't find per display information"
    mean?
    [Last modified: Mar 96]

    Answer: Xt often needs information about the current X display. It generates
    this error when it couldn't find the display pointer. Common causes
    applications accidentally destroying widgets twice or trying to generate fake,
    incomplete events with XSendEvent().

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 335) Can I set widget fallback resources after I've called
    XtAppInitialize()?
    [Last modified: Mar 96]

    Answer: No. Fallbacks are only checked when displays are initialized.

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 336) Can I use the newline character in widget names?
    [Last modified: Mar 96]

    Answer: No. Widget names are designed to be used in resource specifications.
    The Xlib resource file syntax says the only alphanumeric characters (plus '-'
    and '_') may be used in a resource component name. If you want more than one
    line of text in a label widget, set the XmNlabelString resource.

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 337) Is anybody out there selling Windows95 look-alike widgets? Why
    isn't there a Widget builder for Motif/X yet? Something like OCX (I believe on
    Windows95).
    [Last modified: Mar 96]

    Answer: David B. Lewis (dbl%craft@uunet.uu.net) writes:

    None that I know of. There are similar widgets available in Motif 2.0. There
    are similar widgets available in the ICS EnhancementPak.

    [For the second part of the question...] Because it's very hard to do. I don't
    know what OCX is, but I can't imagine that the technology is so much better
    than that used in Xt that it's possible to write something to generate real
    code. It's trivial, of course, to generate the framework for a widget given
    only its name, superclass, and resources; but everything else is real code.

    -----------------------------------------------------------------------------
    Subject: 338) How can I convert my OLIT programs to the Motif look & feel?
    [Last modified: July 96]

    Answer: Mark Fresolone (mjf@mjm.com) writes: There are a number of translator
    products on the market which translate OLIT source code or DevGuide builder
    files into Motif source code and builder files.

    In 1995, MJM Software (Melillo Consulting Inc.) released the MoOLIT 5.1
    toolkit, which allows one to simply re-compile Sun or UnixWare OLIT programs,
    and have them be switchable between the OPENLOOK and Motif look and feels.
    MoOLIT 5.1 is available on most popular UNIX platforms. More information is
    available at:

    http://www.mjm.com/Products/MoOLIT

    -----------------------------------------------------------------------------
    Subject: 339) What does this mean: Warning: Cannot find callback list in
    XtAddCallback?
    [Last modified: July 96]

    Answer: It means that you gave an invalid callback name to XtAddCallback,
    e.g., using XmNactivateCallback when the widget does not have a callback with
    that name.

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 340) If a single widget has multiple callback functions, are they
    all executed? If so, in what order?
    [Last modified: Nov 96]

    Answer: Yes, they are all executed. The order, however, is not defined by the
    X Toolkit specifications. If you really want a certain order, you should
    register a single callback function and have it call your other functions in
    the order you want.

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 341) Why are some widgets still visible after I call
    XtDestroyWidget() on them?
    [Last modified: Nov 96]

    Answer: To avoid memory corruption problems, the X Toolkit uses a 2 phase
    destroy process. When you call XtDestroyWidget(), the widgets are not really
    destroyed until after you return to the Xt main loop. Until then, the widget
    will behave (mostly) as if they were not destroyed. If this is a problem, you
    should unmanage them as well (you can safely unmanage them after you destroy
    them and before you return to the main loop).

    Ken Lee

    Note: The details of the two-phase destruction are described on the
    XtCreateWidget(3Xt)/XtDestroyWidget(3Xt) man page. - ksall@cen.com

    -----------------------------------------------------------------------------
    Subject: 342) If I call XtGetValues on a resource that does not exist for a
    given widget, what value is returned?
    [Last modified: Nov 96]

    Answer: No value is returned. Your return variable is not modified. If it
    was uninitialized (i.e., garbage) before the call to XtGetValues, it will
    remain uninitialized.

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 343) Can I reparent a widget (change its parent)?
    [Last modified: Aug 97]

    Answer: Xt does not support reparenting of widgets within the widget
    hierarchy. This would complicate the hierarchical resource model. You can
    destroy the old hierarchy and create a new one. On most systems, this is
    pretty fast for reasonably sized widget hierarchies.

    Note, however, that X11R6.3 provides an "application group" extension that
    allows one X client to act as the root of another X client's window hierarchy.
    See the X11R6.3 documentation for more details.

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 344) Are there any "year 2000" issues within Motif?
    [Last modified: Jun 98]

    Answer: According to

    http://www.camb.opengroup.org/tech/desktop/faq/y2k.htm


    Dear Customer:

    The Open Group has completed a review of Motif (OSF/Motif) and the X Window
    System with regard to Year 2000 issues, and has determined that Motif
    (versions 1.0 through 2.1) and X Window System (X11 Releases 5 through 6.4)
    source code, as provided directly by The Open Group (or, previously provided
    by Open Software Foundation, Inc.; or X Consortium in the case of X Window
    System) does not contain any date-dependent source code. The arrival of the
    year 2000 should have no effect on the operation of Motif or X Window System
    source code.

    Please note, however, that Motif & X Window System object code or
    applications, or derivative works thereof, which would have been provided to
    you by a third party, are not covered by the above statement. You are hereby
    referred to your supplier for statements regarding Year 2000 issues for such
    third-party products.

    Very truly yours,

    The Open Group

    -----------------------------------------------------------------------------
    Subject: 345) Can I suppress or customize Motif warning and error messages?
    [Last modified: Aug 97]

    Answer: A better idea is usually to fix problems indicated by the messages.
    If you must, Motif justs uses Xt's message system which can be customized with
    XtAppSetWarningHandler and XtAppSetErrorHandler.

    -----------------------------------------------------------------------------
    Subject: 346) TOPIC: Motif FAQ HISTORY and ACKNOWLEDGEMENTS
    [Last modified: April 97]

    Answer:

    History:
    -------
    November 89 to July 93: FAQ was maintained by Jan Newmarch
    (jan@ise.canberra.edu.au)

    July 93 to August 94: FAQ was maintained by Brian Dealy
    (dealy@c3i.saic.com)

    Sept. 94 to April 97: FAQ was maintained by Ken Sall
    (ksall@cen.com)

    beginning April 97: FAQ was maintained by Kenton Lee
    (http://www.rahul.net/kenton/)

    Acknowledgments:
    ----------------
    This list was compiled using questions and answers posed to
    comp.windows.x.motif and motif-talk. Some information was excerpted from the
    comp.windows.x FAQ. To all who contributed one way or the other, thanks! We
    try to give individual references, but you may recognize something
    (jan@ise.canberra.edu.au)

    July 93 to August 94: FAQ was maintained by Brian Dealy
    (dealy@c3i.saic.com)

    Sept. 94 to April 97: FAQ was maintained by Ken Sall
    (ksall@cen.com)

    beginning April 97: FAQ was maintained by Kenton Lee
    (http://www.rahul.net/kenton/)

    Acknowledgments:
    ----------------
    This list was compiled using questions and answers posed to
    comp.windows.x.motif and motif-talk. Some information was excerpted from the
    comp.windows.x FAQ. To all who contributed one way or the other, thanks! We
    try to give individual references, but you may recognize something uncredited
    as your contribution. If we've mangled the words (or, heaven forbid, the code)
    too much, let the current maintainer know.

    NOTE: If you are a two-or-more-time contributor to this FAQ and you have a WWW
    personal home page which you'd like to have listed, see the subject: "Which X
    and Motif developers have their own home page URLs?"

    Jan Newmarch, Information Science and Engineering,
    University of Canberra, PO Box 1, Belconnen, Act 2616
    Australia. Tel: (Aust) 6-2522422. Fax: (Aust) 6-2522999

    ACSnet: jan@ise.canberra.edu.au
    ARPA: jan%ise.canberra.edu.au@uunet.uu.net
    UUCP: {uunet,ukc}!munnari!ise.canberra.edu.au!jan
    JANET: jan%au.edu.canberra.ise@EAN-RELAY


    Jan Newmarch maintained this FAQ for a long time and has really helped a great
    many of us by providing this valuable service. He deserves a big round of
    applause for his efforts. I use this resource all the time and it has saved
    me countless hours with manuals and source code trying to relearn what others
    have already discovered. Jan`s efforts are gratefully acknowledged here.

    Brian Dealy, SAIC
    dealy@c3i.saic.com


    Likewise, Brian Dealy of SAIC did an admirable job taking over the Motif FAQ
    from Jan. A considerable amount of information was added during his tenure and
    we greatly appreciate Brian's work on the FAQ, as well as his efforts in
    maintaining the comp.windows.x.motif newsgroup reflector, for the good of all
    Motif-dom.

    Ken Sall
    ksall@cen.com
    Tel: (301) 953-3330 FAX: (301) 953-2368
    Century Computing, Inc.
    http://www.cen.com/


    My thanks to Ken Sall for maintaining the FAQ for 1994-1997. During Ken's
    tenure the FAQ more than doubled in size. Ken was one of the first FAQ
    maintainers to change all ftp references to URLs and to incorporate http URLs
    thoroughout the FAQ.

    Kenton Lee
    X/Motif Consultant
    kenton@nojunk.rahul.net
    http://www.rahul.net/kenton/


    The end.



+ Reply to Thread