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 8 of 8

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 5 of 9)

    Archive-name: motif-faq/part5
    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: 108) TOPIC: LIST WIDGET

    -----------------------------------------------------------------------------
    Subject: 109) Should I create an XmList widget as a child of automatic
    XmScrolledWindow or use the XmCreateScrolledList() convenience function?

    Answer: With most implementations, the convenience function use internal hooks
    to give somewhat better scrolling performance.

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

    -----------------------------------------------------------------------------
    Subject: 110) How do I best put a new set of items into a list?

    Answer: Set the new list count and list by XtSetArgs and install them by
    XtSetValues.

    XmString list[SIZE];
    int list_size;

    XtSetArg (args[n], XmNitemCount, list_size); n++;
    XtSetArg (args[n], XmNitems, list); n++;
    XtSetValues (w, args, n);


    or similarly with XtVaSetValues:


    XtVaSetValues (w,
    XmNitemCount, list_size,
    XmNitems, list,
    NULL);


    Each time the list is reset by this the old contents are freed by the widget
    and the new supplied list is copied. Do *not* free the old list of items
    yourself as this would result in the space being freed twice. It is not
    necessary to remove the items one at a time, nor to "zero" out the list first.

    -----------------------------------------------------------------------------
    Subject: 111) Can I have strings with different fonts in a list?
    [Last modified: Sept 95]

    Answer: Yes. The strings are XmStrings. Each one can be created using a
    different character set using a different font.

    However, arjav@caip.rutgers.edu (ARJAV PARIKH) wrote:

    If a string is added to the listbox, the font in the listbox overrides the
    font set using XmCreateString. The Command widget label retains the font set
    using XmCreateString. I read in the MOTIF FAQ that it is possible to add
    strings with multiple fonts to the listbox. I learned from one of the tech
    support persons that internal code of the listbox overrides the font.

    Madhusudan Poolu (madhu@corp.sgi.com) replied:

    You need to create a fontlist for your font and add it to your listbox widget
    using XtVaSetValues ( wList, XmNfontList, yourFontList, NULL). This technique
    can also be used to display multi-font strings in a list box.

    -----------------------------------------------------------------------------
    Subject: 112) Can I get a bitmap to show in a list item like I can in a
    Label? I want to place a bitmap along with some normal text in my list items.
    [Last modified: Jun 2000]

    Answer: Andrew Lister (lister@bain.oz.au) writes: The XbaeMatrix widget allows
    a bitmaps in a cell. There will be support for colour pixmaps to be displayed
    in version 4.4 which should be available very soon. (The XbaeMatrix can be
    made to look and behave like a list widget. The widget is compatible with
    Motif 1.2 and Motif 2.0.)

    Beginning with version 4.7, XbaeMatrix is being maintained by the Lesstif
    project. The current version is version 4.8. Source code and a FAQ are
    available from:

    http://www.lesstif.org/Xbae.html
    http://www.lesstif.org/Lessdox/XbaeFAQ.html


    Alan Peery (peery@isc.tamu.edu) writes: Motif 2.0 introduced the "container"
    widget, which offers 2-D icon and text layout similar to that found in many
    file management programs. It could probably be used as a 1-D list widget
    also.

    A previous source wrote: In Motif 1.x, you cannot do this. The list contains
    XmStrings, and these only allow text in various character sets. The workaround
    is to define your font containing the icons you want. Then you can create a
    fontlist containing your icon font and the font you want the text in, and then
    make your items multi-segment XmStrings where the first segment contains the
    code of the icon you want with a charset that matches the icon font in your
    fontlist and the second segment with a charset matching the text font.


    -----------------------------------------------------------------------------
    Subject: 113) Can I have items with different colors in a list widget?
    [Last modified: Jun 2000]

    Answer: Andrew Lister (lister@bain.oz.au) writes: The XbaeMatrix widget can
    have a different foreground and background in each cell, row or column. (The
    XbaeMatrix can be made to look and behave like a list widget. The widget is
    compatible with Motif 1.2 and Motif 2.0.) You can get the latest version of
    XbaeMatrix from:
    http://www.lesstif.org/Xbae.html

    Ken Lee wrote: Not in Motif 1.x. The list contains XmStrings, and these only
    allow text in various character sets.

    However, in Motif 2.0 you _can_ have multiple colors in the same list since
    colored XmStrings are supported.

    Thanks to Ken Lee, http://www.rahul.net/kenton/, for the update.

    If you're using Motif 1.2, another possibility is to use SCO Premier Motif
    (1.2) library has this extension built into the List widget, along with a few
    others. See http://www.premier.sco.com/

    Thanks to Richard Offer (offer@sgi.com)

    -----------------------------------------------------------------------------
    Subject: 114) How can I line up columns in a list widget?
    [Last modified: Jun 2000]

    Answer: The simplest answer is to use fixed-width fonts and spaces to line up
    columns. There are also some more general solutions follow.

    David Kaelbling writes:

    Motif 2.x supports tab components in XmStrings. Insert XmSTRING_COMPONENT_TAB
    segments into your XmStrings, either with XmStringComponentCreate() and
    XmStringConcatAndFree(), or with the XmStringParseText() api). Then use
    XmStringTableProposeTabList() to get a default set of non-overlapping tabs.
    Put that XmNtabList into a rendition in the list's render table.

    Andrew Lister (lister@bain.oz.au) writes:

    The XbaeMatrix can do this too, for both fixed and non fixed width fonts.
    (The XbaeMatrix can be made to look and behave like a list widget. The widget
    is compatible with Motif 1.2 and Motif 2.0.) You can get the latest version of
    XbaeMatrix from: http://www.lesstif.org/Xbae.html

    Ken Lee writes:

    Other Motif-compatible and matrix grid and matrix widgets are available. See
    the widgets FAQ for pointers.

    -----------------------------------------------------------------------------
    Subject: 115) Can I grey out an item in a list widget? I want to make
    insensitive items in a list so that they cannot be selected.
    [Last modified: Feb 98]

    Answer: W. Scott Meeks of OSF wrote:

    Unfortunately, you can't do it directly since the list items aren't individual
    widgets. We've had other requests for this technology, but it didn't make the
    cut for 1.2; it should be in some future release.

    However, you can probably fake it in your application with some difficulty.
    First, a list item is an XmString, so you can specify a different charset for
    the item than for other items in the list and then specify a font in the
    list's fontlist that matches the charset and gives you the visual you want.
    The next problem is making the item unselectable. One idea would be to have
    the application keep track of the insensitive items and the items currently
    selected. Then you would set up a selection callback that when called would
    check the item selected against the list of insensitive items and if the
    selected item matched would deselect that item and reselect the previously
    selected items. Otherwise it would just update the application's list of
    selected items. The major drawback with this approach is that you'll get
    flashing whenever the list selects an item and your application immediately
    de-selects. Unfortunately I can't think of a way around this without mucking
    with the list internals.

    Another alternative suggested is to use instead a column of say read only text
    widgets which you can make insensitive.

    Ken Lee adds: Motif 2.0 allows you to create multi-color XmStrings. You can
    use this feature to grey out specific list items.

    -----------------------------------------------------------------------------
    Subject: 116) Can I have multi-line items in a list?
    [Last modified: August 92]

    Answer: Motif 1.0 and 1.1 both have problems with multi-line items in a list.
    They should work okay in Motif 1.2.

    -----------------------------------------------------------------------------
    Subject: 117) How can I tell the position of selected items in a list?
    [Last modified: Oct 92]

    Answer: W. Scott Meeks wrote:

    1) All XmList selection callbacks get an XmListCallbackStruct which includes
    the item selected and its position. In addition, the multiple and extended
    selection callbacks also get a list of the selected items. This approach
    requires that your application saves this information if you need it outside
    of the immediate callback.

    2) At any time you can XtGetValues the XmNselectedItems and
    XmNselectedItemCount resources. The problem with this approach is that
    identical items may or may not show up in multiple times in this list and the
    position in the selectedItems list may not relate directly to the position in
    the items list.

    3) You can call XmListGetSelectedPos on the list widget. This will return a
    list of the positions of all selected items.

    -----------------------------------------------------------------------------
    Subject: 118) How can I configure a scrolled list widget to show a horizontal
    scrollbar when some list items are wider than the window?
    [Last modified: May 97]

    Answer: Set *XmList.listSizePolicy: XmCONSTANT

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 119) How can I programatically select all of the items in an XmList?
    [Last modified: May 98]

    Answer: Invoke the same action that "C-/" uses for selecting everything. Try
    something like:

    XtCallActionProc(list, "ListKbdSelectAll", event, NULL, 0);

    If you don't have an event handy passing NULL for it will probably work too.
    The lack of an XmListSelectAllItems() api was just an oversight.

    David KAELBLING

    -----------------------------------------------------------------------------
    Subject: 120) TOPIC: FILE SELECTION BOX WIDGET

    -----------------------------------------------------------------------------
    Subject: 121) What is libPW.a and do I need it? My manual says I need to
    link in libPW.a to use the File Selection Box. I can't find it on my system.
    [Last modified: Sept 94]

    Answer: The libPW.a is the Programmers Workbench library which is an ATT
    product not included in Berkeley based systems, hence it is not found in SunOS
    or Ultrix, but is found on HP-UX (a Berkeley/ATT hybrid which chose ATT in
    this case). It contains the regex(3) routines (regcmp, regex). Some systems
    which don't have these in the libc.a need to link with -lPW. Some systems
    which have the regex(3) routines in there also have the libPW.a. If you have
    regex(3) in libc, and it works, don't link with libPW. If you don't have
    regex(3) in libc, and you don't have a libPW, then check some sites on the net
    for public domain replacements (several exist), or call your vendor.

    In most versions of Motif (see the doco), you can compile FileSB.c with
    -DNO_REGEX if you don't have it.


    Casper H.S. Dik (asper@fwi.uva.nl), Faculty of Mathematics & Computer Science,
    University of Amsterdam, sent this update for Solaris 2.x users:

    The regex and regcmp function are part of libgen in SVR4. Motif applications
    should be linked with -lgen. (However, some SVR4 implementations, especially
    those of vendors that once shipped SVR3 still contain libPW.)

    On Solaris 2.x system, you'll need libgen which is located in /usr/ccs/lib.

    -----------------------------------------------------------------------------
    Subject: 122) What are these compile errors: Undefined symbol _regcmp and
    _regex?
    [Last modified: Sept 94]

    Answer: You need to link in the libPW or libgen library - see previous
    question.

    -----------------------------------------------------------------------------
    Subject: 123) What's wrong with the Motif 1.0 File Selection Box? I can't
    set the directory, change the directory or get the file mask to work.

    Answer: The 1.0 File Selection Box is broken, and these don't work. They
    weren't fixed until Motif 1.04. Use these later versions of 1.0 or switch to
    Motif 1.1 where it changed a lot.

    Joe Hildebrand has a work-around for some of this: Before popping up an
    XmFileSelectionDialog, change to the directory you want. When a file is
    selected, check if it is a directory, so that we can change to it. i.e.

    static void show_file_box_CB(w, client_data, call_data)
    Widget w;
    Widget client_data;
    XmAnyCallbackStruct *call_data;
    {
    chdir("/users/hildjj/files");
    XtManageChild(client_data);
    }

    static void val_save(w, client_data, call_data)
    Widget w;
    Widget client_data;
    XmSelectionBoxCallbackStruct *call_data;
    {
    struct stat buf; /* struct stat is defined in stat.h */
    char *filename;

    /* get the file name from the FileSelectionBox */
    filename = SmX(call_data->value);

    /* get the status of the file named filename, and put it into buf */
    if (!stat(filename, &buf))
    {
    /* if it's a directory */
    /* if it's a directory */
    if(S_ISDIR(buf.st_mode))
    {
    /* change to that directory, and update the FileSelectionBox */
    chdir(filename);
    XmFileSelectionDoSearch(w, NULL);
    }
    else
    /* if it's a regular file */
    if(S_ISREG(buf.st_mode))
    /* ask if it should be overwritten */
    XtManageChild(valbox);
    else
    /* it's another kind of file. What type, i can't think of,
    but it might happen */
    pop_up_error_box(client_data, "Error saving file");
    }
    else /* we couldn't get the file status */
    {
    /* if it's because the file doesn't exist, we're golden */
    if (errno == ENOENT)
    save_file();
    else /* there is some other problem getting the status.
    e.g. bad path */
    pop_up_error_box(client_data, "Error saving file");
    }
    }

    this still doesn't implement the file masking stuff.

    -----------------------------------------------------------------------------
    Subject: 124) How can I keep my file selection boxes from resizing when I
    change directories or filters?
    [Last modified: May 97]

    Answer: Set XmNresizePolicy (XmFileSelectionDialog is a subclass of
    XmBulletinBoard) to XmRESIZE_NONE.

    -----------------------------------------------------------------------------
    Subject: 125) What's wrong with the FileSelectionBox under Solaris?
    [Last modified: May 97]

    Answer: Jim Guyton (guyton@burton.cs.colorado.edu) writes:

    While not strictly a Motif problem, this one had me confused for [awhile].

    If under Solaris the entries in a FileSelectionBox look strange and seem to be
    missing the first two characters of many filenames, then be sure you're
    linking -lc before -lucb.

    If on the other hand, the filenames look strange and seem to have two garbage
    characters in front of every filename, be sure to link -lucb before -lc.

    There are two versions of readdir(). The one in -lucb returns a structure
    that has the filename at an offset of 8 bytes (which matches
    /usr/ucbinclude/sys/dir.h).

    But the version in -lc returns the filename at an offset of 10 bytes (which
    matches /usr/include/dirent.h).

    So depending on how Motif was built for your Solaris, vs. how you link your
    application, your filenames could be two bytes off in either direction.


    Harry Cohen (hbcohen@bell.tds-eagan.lmco.com) writes: I also had this problem
    (the missing horizontal scroll bar with Solaris 2.5.1 and 2.4) and have talked
    with Sun. This is a problem with the Sun Motif library in /usr/dt/lib.

    You need to install the following Sun patches to correct this problem: For
    Solaris 2.5.1: patch 103461-03 For Solaris 2.4: patch 102226-19

    Note: For Solaris 2.4, the horizontal scroll problem existed in a previous
    patch release, so most people haven't seen it.


    Scott W. Sadler (sws@iti-oh.com) writes: We had this same problem, and it took
    a while to figure it out. If you use the Motif libraries out of /usr/dt/lib,
    the file selection box gives the problem you indicate. However, if you use
    the Motif libraries out of /opt/SUNWspro/Motif_Solaris24/dt/lib, all is fine.

    Make sure your LD_LIBRARY_PATH, is set correctly to pick up the right shared
    libraries at run time. Also check out the "-R" option to the linker to encode
    the library search paths. Finally use the "ldd" program to make sure that you
    are picking up the correct libraries.


    -----------------------------------------------------------------------------
    Subject: 126) TOPIC: FORM WIDGET


    -----------------------------------------------------------------------------
    Subject: 127) Why don't labels in a Form resize when the label is changed?
    I've got some labels in a form. The labels don't resize whenever the label
    string resource is changed. As a result, the operator has to resize the window
    to see the new label contents. I am using Motif 1.1.

    Answer: This problem may happen to any widget inside a Form widget. The
    problem was that the Form will resize itself when it gets geometry requests
    from its children. If its preferred size is not allowed, the Form will
    disallow all geometry requests from its children. The workaround is that you
    should set any ancestor of the Form to be resizable. For the shell which
    contains the Form you should set the shell resource XmNallowShellResize to be
    True (by default, it is set to FALSE). There is currently an inconsistency on
    how resizing is being done, and it may get fixed in Motif 1.2.

    db@sunbim.be (Danny Backx) wrote:

    Basically what you have to do is set the XmNresizePolicy on the Form to
    XmRESIZE_NONE. The facts seem to be that XmRESIZE_NONE does NOT mean "do not
    allow resizes". You may also have to set XmNresizable on the form to True.

    -----------------------------------------------------------------------------
    Subject: 128) How can I center a widget in a form?
    [Last modified: Nov 96]

    Answer: One of Motif's trickier questions. The problems are that: Form gives
    no support for centering, only for edge attachments, and the widget must stay
    in the center if the form or the widget is resized. Just looking at
    horizontal centering (vertical is similar) some solutions are:

    a. Use the table widget instead of Form. A hack free solution is from Dan
    Heller:

    /* 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.
    */

    /* corners.c -- demonstrate widget layout management for a
    * BulletinBoard widget. There are four widgets each labeled
    * top-left, top-right, bottom-left and bottom-right. Their
    * positions in the bulletin board correspond to their names.
    * Only when the widget is resized does the geometry management
    * kick in and position the children in their correct locations.
    */
    #include
    #include

    char *corners[] = {
    "Top-Left", "Top-Right", "Bottom-Left", "Bottom-Right",
    };

    static void resize();

    main(argc, argv)
    int argc;
    char *argv[];
    {
    Widget toplevel, bboard;
    XtAppContext app;
    XtActionsRec rec;
    int i;

    /* Initialize toolkit and create toplevel shell */
    toplevel = XtVaAppInitialize(&app, "Demos", NULL, 0,
    &argc, argv, NULL, NULL);

    /* Create your standard BulletinBoard widget */
    bboard = XtVaCreateManagedWidget("bboard",
    xmBulletinBoardWidgetClass, toplevel, NULL);

    /* Set up a translation table that captures "Resize" events
    * (also called ConfigureNotify or Configure events). If the
    * event is generated, call the function resize().
    */
    rec.string = "resize";
    rec.proc = resize;
    XtAppAddActions(app, &rec, 1);

    /******** WARNING! Next statement is questionable in 1996. See
    ******** "Can you reuse the return value from XtParseTranslationTable?"
    ******** If someone corrects this code, send it to kenton@nojunk.rahul.net
    ********/

    XtOverrideTranslations(bboard,
    XtParseTranslationTable(": resize()"));

    /* Create children of the dialog -- a PushButton in each corner. */
    for (i = 0; i < XtNumber(corners); i++)
    XtVaCreateManagedWidget(corners[i],
    xmPushButtonGadgetClass, bboard, NULL);

    XtRealizeWidget(toplevel);
    XtAppMainLoop(app);
    }

    /* resize(), the routine that is automatically called by Xt upon the
    * delivery of a Configure event. This happens whenever the widget
    * gets resized.
    */
    static void
    resize(w, event, args, num_args)
    CompositeWidget w; /* The widget (BulletinBoard) that got resized */
    XConfigureEvent *event; /* The event struct associated with the event */
    String args[]; /* unused */
    int *num_args; /* unused */
    {
    WidgetList children;
    int width = event->width;
    int height = event->height;
    Dimension w_width, w_height;
    short margin_w, margin_h;

    /* get handle to BulletinBoard's children and marginal spacing */
    XtVaGetValues(w,
    XmNchildren, &children,
    XmNmarginWidth, &margin_w,
    XmNmarginHeight, &margin_h,
    NULL);

    /* place the top left widget */
    XtVaSetValues(children[0],
    XmNx, margin_w,
    XmNy, margin_h,
    NULL);

    /* top right */
    XtVaGetValues(children[1], XmNwidth, &w_width, NULL);

    /* To Center a widget in the middle of the BulletinBoard (or Form),
    * simply call:
    * XtVaSetValues(widget,
    XmNx, (width - w_width)/2,
    XmNy, (height - w_height)/2,
    NULL);
    * and return.
    */
    XtVaSetValues(children[1],
    XmNx, width - margin_w - w_width,
    XmNy, margin_h,
    NULL);

    /* bottom left */
    XtVaGetValues(children[2], XmNheight, &w_height, NULL);
    XtVaSetValues(children[2],
    XmNx, margin_w,
    XmNy, height - margin_h - w_height,
    NULL);

    /* bottom right */
    XtVaGetValues(children[3],
    XmNheight, &w_height,
    XmNwidth, &w_width,
    NULL);
    XtVaSetValues(children[3],
    XmNx, width - margin_w - w_width,
    XmNy, height - margin_h - w_height,
    NULL);
    }

    b. No uil solution has been suggested, because of the widget size problem.

    c. Cameron Hayne (hayne@crim.ca) suggests another solution:

    Attach the widget with XmATTACH_POSITION but offset it by half of its
    width. You will likely have to create the widget first and then query it
    to find out its width. Thus the following function is useful - you can
    call it immediately after the widget is created.

    void center_it(Widget wgt)
    {
    Dimension width;
    XtVaGetValues(wgt, XmNwidth, &width, NULL);
    XtVaSetValues(wgt, XmNleftAttachment, XmATTACH_POSITION,
    XmNleftPosition, 50, /* assumes fractionBase is 100 */
    XmNleftOffset, -width/2, NULL);
    }

    The idea is: get the size of the widget and then offset it by half that
    much from position 50. The above function will likely only work for
    primitive widgets if you call it immediately after the widget is created.
    For manager widgets you will likely have to wait to call the center_it()
    function until after the widget has been realized since it is only then
    that a manager widget's size is finally determined. (Refer to discussion
    by Daniel Dardailler "Application's Geometry Management Advanced
    Guidelines" in this FAQ.)

    -----------------------------------------------------------------------------
    Subject: 129) How do I line up two columns of widgets of different types? I
    have a column of say label widgets, and a column of text widgets and I want to
    have them lined up horizontally. The problem is that they are of different
    heights. Just putting them in a form or rowcolumn doesn't line them up
    properly because the label and text widgets are of different height.

    If you want the geometry to look like this

    -------------------------------------
    | -------------------------- |
    |a label |Some text ||
    | -------------------------- |
    ------------------- |
    |a longer label |Some more text ||
    | ------------------- |
    | ---------------- |
    |a very long label |Even more text ||
    | ---------------- |
    -------------------------------------

    try

    /* 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.
    */

    /* text_form.c -- demonstrate how attachments work in Form widgets.
    * by creating a text-entry form type application.
    */

    #include
    #include
    #include
    #include
    #include

    char *prompts[] = {
    "Name:", "Phone:", "Address:",
    "City:", "State:", "Zip:",
    };

    main(argc, argv)
    int argc;
    char *argv[];
    {
    Widget toplevel, mainform, subform, label, text;
    XtAppContext app;
    char buf[32];
    int i;

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

    mainform = XtVaCreateWidget("mainform",
    xmFormWidgetClass, toplevel,
    NULL);

    for (i = 0; i < XtNumber(prompts); i++) {
    subform = XtVaCreateWidget("subform",
    xmFormWidgetClass, mainform,
    /* first one should be attached for form */
    XmNtopAttachment, i? XmATTACH_WIDGET : XmATTACH_FORM,
    /* others are attached to the previous subform */
    XmNtopWidget, subform,
    XmNleftAttachment, XmATTACH_FORM,
    XmNrightAttachment, XmATTACH_FORM,
    NULL);
    label = XtVaCreateManagedWidget(prompts[i],
    xmLabelGadgetClass, subform,
    XmNtopAttachment, XmATTACH_FORM,
    XmNbottomAttachment, XmATTACH_FORM,
    XmNleftAttachment, XmATTACH_FORM,
    XmNalignment, XmALIGNMENT_BEGINNING,
    NULL);
    sprintf(buf, "text_%d", i);
    text = XtVaCreateManagedWidget(buf,
    xmTextWidgetClass, subform,
    XmNtopAttachment, XmATTACH_FORM,
    XmNbottomAttachment, XmATTACH_FORM,
    XmNrightAttachment, XmATTACH_FORM,
    XmNleftAttachment, XmATTACH_WIDGET,
    XmNleftWidget, label,
    NULL);
    XtManageChild(subform);
    }
    /* Now that all the forms are added, manage the main form */
    XtManageChild(mainform);

    XtRealizeWidget(toplevel);
    XtAppMainLoop(app);
    }

    If you resize horizontally it stretches the text widgets. If you resize
    vertically it leaves space under the bottom (if you don't resize, this is not
    problem).

    If you want the text widgets to be lined up on the left, as in

    ----------------------------------------
    | ------------------- |
    | a label |Some text ||
    | ------------------- |
    ------------------- |
    | a longer label |Some more text ||
    | ------------------- |
    | ------------------- |
    |a very long label |Even more text ||
    | ------------------- |
    ----------------------------------------

    try this

    /* 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.
    */

    /* text_entry.c -- This demo shows how the RowColumn widget can be
    * configured to build a text entry form. It displays a table of
    * right-justified Labels and Text widgets that extend to the right
    * edge of the Form.
    */
    #include
    #include
    #include

    char *text_labels[] = {
    "Name:", "Phone:", "Address:", "City:", "State:", "Zip:",
    };

    main(argc, argv)
    int argc;
    char *argv[];
    {
    Widget toplevel, rowcol;
    XtAppContext app;
    char buf[8];
    int i;

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

    rowcol = XtVaCreateWidget("rowcolumn",
    xmRowColumnWidgetClass, toplevel,
    XmNpacking, XmPACK_COLUMN,
    XmNnumColumns, XtNumber(text_labels),
    XmNorientation, XmHORIZONTAL,
    XmNisAligned, True,
    XmNentryAlignment, XmALIGNMENT_END,
    NULL);

    /* simply loop thru the strings creating a widget for each one */
    for (i = 0; i < XtNumber(text_labels); i++) {
    XtVaCreateManagedWidget(text_labels[i],
    xmLabelGadgetClass, rowcol,
    NULL);
    sprintf(buf, "text_%d", i);
    XtVaCreateManagedWidget(buf,
    xmTextWidgetClass, rowcol,
    NULL);
    }

    XtManageChild(rowcol);
    XtRealizeWidget(toplevel);
    XtAppMainLoop(app);
    }

    This makes all objects exactly the same size. It does not resize in nice
    ways.

    If you want the text widgets lined up on the left, and the labels to be the
    size of the longest string, resizing nicely both horizontally and vertically,
    as in

    -------------------------------------
    | ---------------- |
    | a label |Some text ||
    | ---------------- |
    ---------------- |
    | a longer label |Some more text ||
    | ---------------- |
    | ---------------- |
    |a very long label |Even more text ||
    | ---------------- |
    -------------------------------------


    Answer: Do this: to get the widgets lined up horizontally, use a form but
    place the widgets using XmATTACH_POSITION. In the example, attach the top of
    the first label to the form, the bottomPosition to 33 (33% of the height).
    Attach the topPosition of the second label to 33 and the bottomPosition to 66.
    Attach the topPosition of the third label to 66 and the bottom of the label to
    the form. Do the same with the text widgets.

    To get the label widgets lined up vertically, use the right attachment of
    XmATTACH_OPPOSITE_WIDGET: starting from the one with the longest label, attach
    widgets on the right to each other. In the example, attach the 2nd label to
    the third, and the first to the second. To get the text widgets lined up,
    just attach them on the left to the labels. To get the text in the labels
    aligned correctly, use XmALIGNMENT_END for the XmNalignment resource.

    /* geometry for label 2
    */
    n = 0;
    XtSetArg (args[n], XmNalignment, XmALIGNMENT_END); n++;
    XtSetArg (args[n], XmNleftAttachment, XmATTACH_FORM); n++;
    XtSetArg (args[n], XmNbottomAttachment, XmATTACH_FORM); n++;
    XtSetArg (args[n], XmNtopAttachment, XmATTACH_POSITION); n++;
    XtSetArg (args[n], XmNtopPosition, 66); n++;
    XtSetValues (label[2], args, n);

    /* geometry for label 1
    */
    n = 0;
    XtSetArg (args[n], XmNalignment, XmALIGNMENT_END); n++;
    XtSetArg (args[n], XmNbottomAttachment, XmATTACH_POSITION); n++;
    XtSetArg (args[n], XmNbottomPosition, 66); n++;
    XtSetArg (args[n], XmNtopAttachment, XmATTACH_POSITION); n++;
    XtSetArg (args[n], XmNtopPosition, 33); n++;
    XtSetArg (args[n], XmNleftAttachment, XmATTACH_FORM); n++;
    XtSetArg (args[n], XmNrightAttachment, XmATTACH_OPPOSITE_WIDGET); n++;
    XtSetArg (args[n], XmNrightWidget, label[2]); n++;
    XtSetValues (label[1], args, n);

    /* geometry for label 0
    */
    n = 0;
    XtSetArg (args[n], XmNalignment, XmALIGNMENT_END); n++;
    XtSetArg (args[n], XmNbottomAttachment, XmATTACH_POSITION); n++;
    XtSetArg (args[n], XmNbottomPosition, 33); n++;
    XtSetArg (args[n], XmNtopAttachment, XmATTACH_FORM); n++;
    XtSetArg (args[n], XmNleftAttachment, XmATTACH_FORM); n++;
    XtSetArg (args[n], XmNrightAttachment, XmATTACH_OPPOSITE_WIDGET); n++;
    XtSetArg (args[n], XmNrightWidget, label[1]); n++;
    XtSetValues (label[0], args, n);

    /* geometry for text 0
    */
    n = 0;
    XtSetArg (args[n], XmNtopAttachment, XmATTACH_FORM); n++;
    XtSetArg (args[n], XmNbottomAttachment, XmATTACH_POSITION); n++;
    XtSetArg (args[n], XmNbottomPosition, 33); n++;
    XtSetArg (args[n], XmNrightAttachment, XmATTACH_FORM); n++;
    XtSetArg (args[n], XmNleftAttachment, XmATTACH_WIDGET); n++;
    XtSetArg (args[n], XmNleftWidget, label[0]); n++;
    XtSetValues (text[0], args, n);

    /* geometry for text 1
    */
    XtSetArg (args[n], XmNtopAttachment, XmATTACH_POSITION); n++;
    XtSetArg (args[n], XmNtopPosition, 33); n++;
    XtSetArg (args[n], XmNbottomAttachment, XmATTACH_POSITION); n++;
    XtSetArg (args[n], XmNbottomPosition, 66); n++;
    XtSetArg (args[n], XmNrightAttachment, XmATTACH_FORM); n++;
    XtSetArg (args[n], XmNleftAttachment, XmATTACH_WIDGET); n++;
    XtSetArg (args[n], XmNleftWidget, label[1]); n++;
    XtSetValues (text[1], args, n);

    /* geometry for text 2
    */
    XtSetArg (args[n], XmNtopAttachment, XmATTACH_POSITION); n++;
    XtSetArg (args[n], XmNtopPosition, 66); n++;
    XtSetArg (args[n], XmNrightAttachment, XmATTACH_FORM); n++;
    XtSetArg (args[n], XmNleftAttachment, XmATTACH_WIDGET); n++;
    XtSetArg (args[n], XmNleftWidget, label[2]); n++;
    XtSetArg (args[n], XmNbottomAttachment, XmATTACH_FORM); n++;
    XtSetValues (text[2], args, n);


    -----------------------------------------------------------------------------
    Subject: 130) TOPIC: PUSHBUTTON WIDGET

    -----------------------------------------------------------------------------
    Subject: 131) Why doesn't the enter or return key activate the button with
    focus?
    [Last modified: Sep 98]

    Answer: Motif uses the return key to activate the default button on dialogs,
    bulletin boards, and forms. You can use the space key to activate the focus
    button. These are they same keyboard shortcuts as MS-Windows.

    -----------------------------------------------------------------------------
    Subject: 132) Why can't I use accelerators on buttons not in a menu?
    [Last modified: Sept 94]

    Answer: It is apparently a difficult feature to implement, but OSF are
    considering this for the future. It is problematic trying to use the Xt
    accelerators since the Motif method interferes with this. one workaround
    suggested is to duplicate your non-menu button by a button in a menu
    somewhere, which does have a menu-accelerator installed. When the user
    invokes what they think is the accelerator for the button they can see Motif
    actually invokes the button on the menu that they can't see at the time.
    Another method is described below and was contributed by Harald Albrecht of
    Institute of Geometry and Practical Mathematics Rhine Westphalia Technical
    University Aachen (RWTH Aachen), Germany


    albrecht@igpm.rwth-aachen.de wrote (Jul 8, 1993):

    NOTE: Pointers to a more recent solution by the same author follow this code
    sample.

    My work-around of this problem looks like this: (I've written that code for a
    Motif Object Library in C++ so please forgive me for being object orientated!)
    The hack consists of a rewritten message loop which checks for keypresses
    +. If MessageLoop() finds such a keypress HandleAcc() ist called
    and the widget tree is searched for a suitable widget with the right mnemonic.


    // --------------------------------------------------------------------------
    // traverse the widget tree starting with the given widget.
    //
    BOOL TraverseWidgetTree(Widget w, char *pMnemonic, XKeyEvent *KeyEvent)
    {
    Widget wChild;
    WidgetList ChildList;
    int NumChilds, Child;
    KeySym LabelMnemonic;
    char *pMnemonicString;

    // Check if the widget is a subclass of label -- then it may have an
    // accelerator attached...
    if ( XtIsSubclass(w, xmLabelWidgetClass) ) {
    // ok. Now: get the widget's mnemonic, convert it to ASCII and compare
    // it with the Key we're looking for.
    XtVaGetValues(w, XmNmnemonic, &LabelMnemonic, NULL);
    pMnemonicString = XKeysymToString(LabelMnemonic);
    if ( pMnemonicString &&
    (strcasecmp(pMnemonicString, pMnemonic) == 0) ) {
    // stimulate the keypress
    XmProcessTraversal((Widget)w, XmTRAVERSE_CURRENT);
    KeyEvent->type = KeyPress;
    KeyEvent->window = XtWindow(w);
    KeyEvent->subwindow = XtWindow(w);
    KeyEvent->state = 0;
    KeyEvent->keycode =
    XKeysymToKeycode(XtDisplay(w), XK_space);
    XSendEvent(XtDisplay(w), XtWindow(w),
    True,
    ButtonPressMask, (XEvent*) KeyEvent);
    KeyEvent->type = KeyRelease;
    XSendEvent(XtDisplay(w), XtWindow(w),
    True,
    ButtonReleaseMask, (XEvent*) KeyEvent);
    return True;
    }
    }
    // if this widget is a subclass of Composite check all the widget's
    // childs.
    if ( XtIsSubclass(w, compositeWidgetClass) ) {
    // if we're in a menu (or something like that) forget this leaf of the
    // widget tree!
    if ( XtIsSubclass(w, xmRowColumnWidgetClass) ) {
    unsigned char RowColumnType;
    XtVaGetValues(w, XmNrowColumnType, &RowColumnType, NULL);
    if ( RowColumnType != XmWORK_AREA ) return False;
    }
    XtVaGetValues(w, XmNchildren, &ChildList,
    XmNnumChildren, &NumChilds, NULL);
    for ( Child = 0; Child < NumChilds; ++Child ) {
    wChild = ChildList[Child];
    if ( TraverseWidgetTree(wChild, pMnemonic, KeyEvent) )
    return True;
    }
    }
    return False;
    } // TraverseWidgetTree
    // --------------------------------------------------------------------------
    // handle accelerators (keypress MAlt + key)
    //
    #define MAX_MAPPING 10
    BOOL HandleAcc(Widget w, XEvent *event)
    {
    Widget widget, OldWidget;
    static char keybuffer[MAX_MAPPING];
    int CharCount;
    static XComposeStatus composeStatus;

    // convert KeyPress to ASCII
    CharCount = XLookupString((XKeyEvent*) event,
    keybuffer, sizeof(keybuffer),
    NULL, &composeStatus);
    keybuffer[CharCount] = 0;
    // Only one char is alright -- then search the widget tree for a widget
    // with the right mnemonic
    if ( CharCount == 1 ) {
    keybuffer[0] = tolower(keybuffer[0]);
    widget = w;
    while ( (widget != NULL) &&
    !XtIsSubclass(widget, shellWidgetClass) ) {
    OldWidget = widget; widget = XtParent(widget);
    }
    if ( !widget ) widget = OldWidget;
    return TraverseWidgetTree(widget,
    keybuffer, (XKeyEvent*) event);
    }
    return False; // no-one found.
    } // HandleAcc
    // --------------------------------------------------------------------------
    // modified message loop
    // loops until the Boolean pFlag points to is set to False
    void MessageLoop(Boolean *pFlag)
    {
    XEvent nextEvent;

    while ( *pFlag ) {
    if ( XtAppPending(AppContext) ) {
    XtAppNextEvent(AppContext, &nextEvent);
    if ( nextEvent.type == KeyPress ) {
    // Falls es ein Tastendruck ist, bei dem auch noch die ALT-Taste
    // (=Modifier 1) gedrueckt ist, koennte es ein Accelerator sein!
    if ( nextEvent.xkey.state & Mod1Mask )
    if ( HandleAcc(XtWindowToWidget(nextEvent.xkey.display,
    nextEvent.xkey.window),
    &nextEvent) )
    continue; // Mitteilung konnte ausgeliefert werden
    // und darf daher nicht den ueblichen
    // Weg gehen!
    }
    XtDispatchEvent(&nextEvent);
    }
    }
    } // TApplication::MessageLoop


    Harald Albrecht albrecht@igpm.rwth-aachen.de Institute of Geometry and
    Practical Mathematics Rhine Westphalia Technical University Aachen (RWTH
    Aachen), Germany

    NOTE: Harald Albrecht has re-designed his solution so that you can assign
    hotkeys to *every* widget by placing a label near that widget. Get the code
    from:

    ftp.informatik.rwth-aachen.de (137.226.112.172) in:
    /pub/packages/Mnemonic/Mnemonic.tar.gz

    or from the WWW:

    file://134.130.161.30/arc/pub/unix/html/motifcorner.html

    -----------------------------------------------------------------------------
    Subject: 133) TOPIC: TOGGLEBUTTON WIDGET

    -----------------------------------------------------------------------------
    Subject: 134) What widgets give the look of push buttons, but behavior of
    toggle buttons?

    Answer: Use the XmToggleButton widget, setting XmNindicatorOn to False and
    XmNshadowThickness to 2. Also set XmNfillOnSelect to True. Otherwise, the
    background color of the button will not stay in the "armed" state.

    In Motif 1.2 (and later), if you specify a XmNselectColor and set
    XmNindicatorOn to False, then you need to set XmNfillOnSelect to True.
    XmNfillOnSelect is not necessary if you are not setting a XmNselectColor.

    Glenn McMillen, mcmillen@meadow.mdso.vf.ge.com and Ken Lee

    -----------------------------------------------------------------------------
    Subject: 135) Can I customize XmToggleButton to use my own indicator graphic
    (e.g., a check mark)?
    [Last modified: Nov 96]

    Answer: There is no direct resource for the graphic. One way to work around
    this is to disable the indicator (XmNindicatorOn False) and then install
    selected/unselected pixmaps containing both your graphic and your text
    (XmNselectPixmap and XmNselectPixmap). Also disable the button shadows
    (XmNshadowThickness 0) if you don't want those.

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 136) TOPIC: ICON WIDGET and PIXMAPS

    -----------------------------------------------------------------------------
    Subject: 137) What is XPM?
    [Last modified: Sept 98]

    Answer: XPM is file format for color images. A programming libary is also
    available. XPM is based on the standard XBM monochrome file format and Xlib
    related convenience functions.

    The XPM home page is: http://www.inria.fr/koala/lehors/xpm.html It has pointes
    to the source code and detailed documentation.

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 138) How do I convert my XPM file into a Pixmap?
    [Last modified: Sept 98]

    Answer: Motif 2.0 and later contain an XPM-to-pixmap resource converter, so
    you can specify your pixmaps as resources.

    In Motif 1.2, you have to use the XPM library to load the XPM files.

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 139) How can I display a multi-color image in a widget?
    [Last modified: Sept 95]

    Answer: Get the XPM library and read the documentation. Get xpaint from
    ftp.x.org, also get the jpeg and tiff libraries on the internet. From these
    you can easily create the code to read in gif, jpeg, and tiff.

    Read the images into and XpmImage format. Then use one of the Xpm conveneince
    functions to create wither an XImage or a Pixmap from your data. The xpm lib
    will take care of the color allocation and Pixmap/XImage creation, then you
    can just use expose routines to copy the Pixmap into a dialog or any
    window....

    Thanks to Ramiro Estrugo (restrugo@fateware.com)

    -----------------------------------------------------------------------------
    Subject: 140) Can I use XmGetPixmap in Motif 1.2 to create colored images?
    [Last modified: Oct 95]

    Answer: Doug Rand (drand@sgi.com) writes:

    XmGetPixmap only converts XBM [X bitmap] files in 1.2. In 2.0 it supports XPM
    [X Pixmap] files. You can register a more capable converter and set the
    pixmap via resources as a workaround. You can also use libXpm
    directly...[Note that] even now there isn't a "standard" color pixmap file
    format. There are several. It is relatively recently that many people have
    settled on XPM. But even so not everyone has done this.

    -----------------------------------------------------------------------------
    Subject: 141) Why does XpmCreatePixmapFromData fail with a pixmap containing
    a large number of colors? XpmCreatePixmapFromData gives me a -4 errno (which
    is XpmColorFailed) when I try using a pixmap with 242 colors
    [Last modified: Oct 95]

    Answer: Ramiro Estrugo (restrugo@fateware.com) writes:

    If you are allocating 242 colors in an 8 bit display, then you are likely to
    run out of colors. If you carefully read the Xpm manual, you will notice that
    one of the Xpm values that you can modify is the "closeness". This value will
    control the actual closness of the colors allocated by the Xpm library.
    According to the Xpm manual:

    o The "closeness" field(s) (when set) control if and how colors
    are found when they failed to be allocated. If the color cannot
    be allocated, Xpm looks in the colormap for a color that matches
    the desired closeness.

    o The value is an integer in the range 0 (black) - 65535 (white)

    o A closeness of less than 10000 will cause only "close" colors to
    match.

    o A cliseness of more than 50000 will allow quite disimilar colors
    to match.

    o A closeness of more than 65535 will allow any color to match.

    o A value of 40000 seems reasonable for many situations requiring
    reasonable but not perfect color matches.

    Try it and your application is less likely to die or look "ugly" due to the
    lack of colors. The worst that can happed is that the colors you get are not
    100% what you wanted them to be. Most of the time, you might not even notice
    the difference. This is usually due to badly designed icons or duplicate
    color entries (close rgb values) in .xpm files.

    NOTE: for even more control over Xpm color allocation, you can control the
    closeness of each RGB color component individually.

    For example:

    XpmAttributes attrib;
    int valuemask;
    attrib.valuemask |= XpmCloseness;
    attrib.closeness = 40000;

    /* also */

    attrib.valuemask |= XpmRGBCloseness;
    attrib.red_closeness = RED_CLOSENESS;
    attrib.green_closeness = GREEN_CLOSENESS;
    attrib.blue_closeness = BLUE_CLOSENESS;
    pix = XpmCreateXYZFromABC(...,&attrib);

    Also, look in the Xpm documentation for more color control parameters.

    -----------------------------------------------------------------------------
    Subject: 142) How can I convert a Sun/GIF/TIFF image to a pixmap?
    [Last modified: Oct 94]

    Answer: An application called "xv" (interactive image display for the X Window
    System) is useful for displaying and converting many image formats. From the
    man page:

    xv is an X11 program that displays images in the GIF, JPEG,
    TIFF, PBM, PGM, PPM, X11 bitmap, PDS/VICAR, Sun Rasterfile,
    and PM formats on 1-, 2-, 4-, 6-, 8-, 16-, 24-, and 32-bit X
    displays. xv will also read compress-ed versions of these
    files.

    You can get "xv" (shareware by John Bradley et al) from:

    ftp://ftp.cis.upenn.edu/pub/xv
    or:
    ftp://ftp.x.org/R5contrib/xv-3.01.tar.gz

    Another useful conversion package is "pbm" (portable bitmap file format) by
    Jef Poskanzer et al, available from:

    ftp://ftp.x.org/R5contrib/netpbm-1mar1994.tar.gz
    or:
    ftp://ftp.x.org/R5contrib/pbmplus10dec91.tar.Z (much older :-)

    You might also want to check the X11 FAQ for additional conversion options:

    ftp://ftp.x.org/contrib/faqs/FAQ


    -----------------------------------------------------------------------------
    Subject: 143) How can I use Motif's pre-defined pixmaps?
    [Last modified: May 97]

    Answer: Motif 1.2 loads the following into its image cache: background,
    25_foreground, 50_foreground, 75_foreground, horizontal, vertical,
    slant_right, and slant_left. These are defined in "man XmInstallImage". You
    can retrieve them with XmGetPixmap or XmGetPixmapByDepth.

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 144) TOPIC: SCALE AND SCROLLBAR WIDGET

    -----------------------------------------------------------------------------
    Subject: 145) Can the XmScale widget have arrows or tick marks in Motif 2.0?
    [Last modified: Sep 97]

    Answer: Daniel Dardailler (danield@w3.org) writes:

    In 2.0 and 2.1, Scale gets arrows (on both sides or same side), thermometer
    look, thumb slider option, tick marks, and editable resource.

    -----------------------------------------------------------------------------
    Subject: 146) How can I set the color of a XmScale widget's trough?
    [Last modified: May 95]

    Answer: Ken Lee wrote: There is no direct API for setting this, but you can
    set it through resource files with "*XmScale*troughColor: red".

    Ken Sall, ksall@cen.com, adds: If you need to do this at runtime, you can use
    XtGetValues to get the scale's children, find the scrollbar, and set the
    XmNtroughColor:

    #include // for XmIsScrollBar

    Pixel selectColor; // assume this is set to the desired color
    WidgetList *kids;
    int nkids;
    Arg argList[1], tmpargs[2];
    int i, s, t ;

    i = 0;
    XtSetArg ( argList[i], XmNtroughColor, selectColor ); i++;

    // Unfortunately, scale does not have a direct way
    // to get its scrollbar widget, so use Composite resources
    s = 0;
    XtSetArg (tmpargs[s], XmNnumChildren, &nkids ); s++ ;
    XtSetArg (tmpargs[s], XmNchildren, &kids ); s++ ;
    XtGetValues ( widgetId, tmpargs, s );
    for ( t = 0; t < nkids; t++ )
    {
    if ( XmIsScrollBar ( (Widget) kids[t]) ) // from ScrollBar.h
    {
    XtSetValues ( (Widget) kids[t], argList, i );
    }
    }


    -----------------------------------------------------------------------------
    Subject: 147) How does Motif implement mouse button auto-repeat on the
    scrollbar's arrow buttons?
    [Last modified: May 97]

    Answer: It installs a timer and checks the button state at each timeout. If
    the button is still down, it repeats the action. You can do this in your
    application, too.

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 148) TOPIC: LABEL WIDGET

    -----------------------------------------------------------------------------
    Subject: 149) How can I align the text in a label (button, etc) widget?

    Answer: The alignment for the label widget is controlled by the resource
    XmNalignment, and the default centers the text. Use this resource to change it
    to left or right alignment. However, when the label (or any descendant) is in
    a XmRowColumn, and XmNisAligned is True (the default), the XmRowColumn aligns
    text using its resource XmNentryAlignment. If you want simultaneous control
    over all widgets use this, but otherwise turn XmNisAligned off and do it
    individually.

    -----------------------------------------------------------------------------
    Subject: 150) Why doesn't label alignment work in a XmRowColumn?

    Answer: XmRowColumn has a resource XmNisAligned (default True) and and
    XmNentryAlignment (default XmALIGNMENT_BEGINNING). These control alignment of
    the labelString in Labels and descendants. Set XmNisAligned to False to turn
    this off.

    -----------------------------------------------------------------------------
    Subject: 151) How can I set a multi-line label?
    [Last modified: Mar 96]

    Answer: In .Xdefaults

    *XmLabel*labelString: Here\nis\nthe\nLabel

    This method does not seem to work in some of the older Motif 1.0 versions.

    In code,

    char buf[128];
    XmString msg;
    strcpy(buf, "Here\nis\nthe\nLabel");
    msg = XmStringCreateLtoR(buf, XmSTRING_DEFAULT_CHARSET);
    XtSetArg (args[n], XmNlabelString, msg);

    Gives a four line label, using the escape sequence \n for a newline. Here's
    another approach from Jean-Philippe Martin-Flatin

    #include
    #include

    /*-----------------------------------------------------
    Create a new XmString from a char*

    This function can deal with embedded 'newline' and
    is equivalent to XmStringCreateLtoR,
    except it does not use non AES compliant charset
    XmSTRING_DEFAULT_CHARSET
    ----------------------------------------------------*/
    XmString xec_NewString(char *s)
    {
    XmString xms1;
    XmString xms2;
    XmString line;
    XmString separator;
    char *p;
    char *t = XtNewString(s); /* Make a copy for strtok not to */
    /* damage the original string */

    separator = XmStringSeparatorCreate();
    p = strtok(t,"\n");
    xms1 = XmStringCreateLocalized(p);

    while (p = strtok(NULL,"\n"))
    {
    line = XmStringCreateLocalized(p);
    xms2 = XmStringConcat(xms1,separator);
    XmStringFree(xms1);
    xms1 = XmStringConcat(xms2,line);
    XmStringFree(xms2);
    XmStringFree(line);
    }

    XmStringFree(separator);
    XtFree(t);
    return xms1;
    }


    Do not use XmStringCreateLocalized() - it does not process the newline
    character in the way you want. In Motif 1.x, XmStringCreateLocalized() does
    NOT process newlines, but XmStringCreateLtoR() does.

    Thanks to Paul Tomblin (ptomblin@xcski.com) for the newline clarification.

    -----------------------------------------------------------------------------
    Subject: 152) How can I have a vertical label?

    Answer: Make a multi-line label with one character per line, as in the last
    question. There is no way to make the text rotated by 90 degrees though.


    -----------------------------------------------------------------------------
    Subject: 153) How can I have a Pixmap in a Label?

    Answer: Bob Hays (bobhays@spss.com) wrote:

    Pixmap px_disarm, px_disarm_insens;

    Widget Label1;
    Pixel foreground, background;
    Arg args[4];
    Arg arg[] = {
    { XmNforeground, &foreground },
    { XmNbackground, &background }
    };

    Label1 = XmCreateLabel ( Shell1, "Label1",
    (Arg *) NULL, (Cardinal) 0 );
    XtGetValues ( Label1, arg, XtNumber ( arg ) );
    px_disarm =
    XCreatePixmapFromBitmapData(display,
    DefaultRootWindow(display),
    mtn_bits, mtn_width, mtn_height,
    foreground,
    background,
    DefaultDepth(display,DefaultScreen(display)));
    px_disarm_insens =
    XCreatePixmapFromBitmapData(display,
    DefaultRootWindow(display),
    mtn_ins_bits, mtn_ins_width, mtn_ins_height,
    foreground,
    background,
    DefaultDepth(display,DefaultScreen(display)));

    n = 0;
    XtSetArg(args[n], XmNlabelType, XmPIXMAP); n++;
    XtSetArg(args[n], XmNlabelPixmap, px_disarm); n++;
    XtSetArg(args[n], XmNlabelInsensitivePixmap, px_disarm_insens ); n++;
    XtSetValues ( Label1, args, n );
    XtManageChild(Label1);

    That will cause the foreground and background of your pixmap to be inherited
    from the one that would be used by OSF/Motif when the label is displayed. The
    advantage is that this will utilize any resource values the user may have
    requested without looking explicitly into the resource database. And, you
    will have a pixmap handy if the application insensitizes the label (without an
    XmNlabelInsensitivePixmap your label will go empty if made insensitive).

    [Bob's original code was for a PushButton. Just change all Label to PushButton
    for them.]

    -----------------------------------------------------------------------------
    Subject: 154) Why doesn't the XmLabel widget obey the XmNwith and XmNheight
    that I give it?
    [Last modified: May 95]

    Answer: By default, XmLabel ignores these resources and instead computes a
    size based on the size of the label string or pixmap. You can change this
    behavior by setting XmNrecomputeSize to False. (Note that setting
    XmNrecomputeSize to False can dramatically improve performance if you have
    alot of labels or change them frequently.)

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 155) How do you set the background color of a label widget using
    XtVaTypedArg?
    [Last modified: July 96]

    Answer: Use the XmNbackground resource to control the background color, e.g.

    strcpy(bgcolor, "yellow");
    XtVaSetValues(widget,
    XtVaTypedArg, XmNbackground, XtRString, bgcolor,
    strlen(bgcolor) + 1, NULL);

    The length of the color string is plus one to include the null character.
    XtRString is the type to be converted. The conversion is required because
    XmNbackground expects a Pixel type.

    Thanks to Martin Squicciarini (msquicci@resd.vf.ge.com).

    -----------------------------------------------------------------------------
    END OF PART FIVE

  5. Motif FAQ (Part 7 of 9)

    Archive-name: motif-faq/part7
    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: 228) TOPIC: LANGUAGE BINDINGS

    -----------------------------------------------------------------------------
    Subject: 229) What is ViewKit? Is there a free version?
    [Last modified: Jun 98]

    Answer: ViewKit is an enhanced version of the C++/Motif framework that Doug
    Young describes in his book *Object-Oriented Programming with C++ and
    OSF/Motif* (Prentice-Hall).

    Viewkit is now available for a variety of platforms from ICS. The Linux
    version is free. Their web site include free technical papers and ordering
    information:

    http://www.viewkit.com/


    There is also a inexpensive ViewKit clone from the Hungry Programmers:

    http://www.hungry.com/cgi-bin/unjava/products/viewkit/
    ftp://ftp.hungry.com/pub/hungry/viewkit


    Allen Fogleson (foggie@dtx.net) writes: I have compiled [the Hungry
    Programmers' version] on my linux system using RedHat Motif 2.0, There is no
    documentation, but the technical paper on the SGI site should be enough to get
    most people going. There is very little in the way of documentation either, so
    I should note that if you are using Motif2.0 you must either #define
    USE_MOTIF20 in a header file, or add it to the CXXFLAGS, and CFLAGS line of
    the makefile or you will get many errors when compiling the combo box
    bindings. Also for some reason the viewkit did not install correctly for me
    and I ended up hand installing it myself. I have compiled some simple
    applications with it, and it seems to be working fine. It is intended to
    follow the SGI API. They are working on a programmers guide and a reference
    manual for the product. All in All this is a very affordable (spelled cheap)
    answer to C++ development of OSF/Motif Apps.

    -----------------------------------------------------------------------------
    Subject: 230) Is there a C++ binding for Motif?
    [Last modified: Nov 98]

    Answer: This answer is out-of-date and will probably be dropped in the near
    future. I recommend that you study other sources, such as trade magazines,
    for more current information on products.

    See also the previous answer concerning ViewKit (from Doug Young and the
    Hungry Programmers.

    (Added Oct. 95) YACL is a freely available C++ class library that includes GUI
    classes based on the Model-View-Controller paradigm. The class protocols are
    designed in a platform independent manner, and are implemented under Motif 1.2
    as well as under Microsoft Windows and OS/2. This makes it possible to
    maintain a single code base for an application that runs on all three
    platforms. YACL also includes a suite of container and data storage classes
    for general-purpose programming. YACL is available from ftp.cs.sc.edu in
    pub/yacl. For more information, see the web page:

    http://www.cs.sc.edu/~sridhar/yacl.html.

    Thanks to M. A. Sridhar, sridhar@usceast.cs.sc.edu.

    (Added Sept. 95; URL updated Jan. 96) Amulet User Interface Toolkit from Brad
    A. Myers, Rich McDaniel, Andrew Mickish, Alex Klimovitski, Carnegie Mellon
    University. Amulet is a user interface software environment for C++ to
    support future user interface software research. This environment, which will
    be portable across X/11, Microsoft Windows, and the Macintosh, is designed to
    be very flexible: parts can be replaced and new technologies and widgets can
    be easily created and evaluated. Built-in support will be provided for direct
    manipulation, multi-font text editing, gesture recognition, speech
    recognition, 2-D and 3-D animations, visualizations including maps and large
    data sets, world-wide-web browsing and editing, and multiple people
    interacting with the system at the same time (CSCW). Another goal is to be
    useful for students, which means that Amulet must be easy to learn. Finally,
    the system will provide sufficient performance, robustness and documentation
    so it will be useful for general user interface developers. See:

    http://www.cs.cmu.edu/Web/Groups/amu...ulet-home.html

    Answer: ObjectBuilder by Openware Technologies, Inc. is a complete C++
    implementation of Motif. Kris Gottschalk (kris@boulder.openware.com) wrote
    [I've condensed his features list and a few others details...ksall@cen.com]:

    Since Solbourne began developing OI around 1988, it was purchased by ParcPlace
    Systems (at which time ObjectBuilder was developed) and as of Oct. '94,
    ObjectBuilder/OI was purchased by Openware Technologies, Inc from ParcPlace.
    OI is now on release 4.6 and has a customer base of about 3,000 seats.

    [ObjectBuilder's features include: Visual Subclassing, Dynamic Reparenting,
    Customizable Main Window, Xt Kit, Resource Editors, Flexible Geometry
    Management, Customizable palattes and attribute editors, 16 Bit
    Internationalization, Mnemonics and Accelerator Editor, Motif or OPEN LOOK
    look-and-feel switch, Help Editor.]

    ObjectBuilder is currently available on Sun/Solaris, HP 9000/700 and IBM AIX
    RS6000. We will also be supporting SGI, DEC Alpha, Sco UNIX, Unysis Unixware
    and NCR SVR4 throughout the first half of 1995. And our anxiously awaited
    Windows NT platform will be available in late 1995. In addition, Openware
    will be launching a full array of C++ development tools including an Object
    Repository, Debugger, OI Table Widget and Adapter. Also anticipate an
    ObjectBuilder upgrade 2.6/4.6 in April and a new ObjectBuilder release 3.0/5.0
    in the summer.

    If you have any more interests or questions or would like to set up a
    evaluation of ObjectBuilder, please contact:

    Kris Gottschalk
    Account Manager
    Openware Technologies, Inc.
    Object Technologies Business Unit
    4909 East Pearl Circle Suite 200
    Boulder, CO 80301
    Phone: 303-440-9991 x4224
    Fax: 303-440-9934
    email: kris@boulder.openware.com


    Answer: Wind/U implements MFC (Microsoft Foundation Classes) on Unix using
    Motif. Bristol Technology, Inc. (203) 438-6969, info@bristol.com. Microsoft
    Visual C++ together with Wind/U can be used to create Motif applications.
    According to J. Daniel Smith , here's how it works: you
    create the application on the PC using MSVC++ and then port it to Unix (or
    VMS) using Wind/U. Since Wind/U uses X and Motif to implement the Windows
    API, you end up with a true Motif application running native on the target
    platform.

    Answer: WWL is a library which defines C++ classes around X Toolkit Widgets.
    It is intended to simplify the task of C++ code writers when using the Toolkit
    by providing them with C++ objects, methods, type checking and several utility
    functions and classes.

    WWL has been tested under SunOs4.0.3 on sun3 and sun4, HPUX version 6.5 and
    7.0 and Ultrix 4.0 on DECstation 3100 and 5000. It is expected to work on most
    other UNIX systems without too many problems.

    WWL is distributed as a tar file with all the source, documentation and
    example. The file is available using anonymous ftp from

    ftp.x.org /R5contrib/WWW-1.2.tar.Z

    ( ftp://ftp.x.org/R5contrib/WWW-1.2.tar.Z )

    Answer: Rogue Wave Software has a C++ binding for Motif called View.h++.

    "View.h++ is a complete C++ interface to OSF/Motif. It doesn't just
    encapsulate it, but also includes a set of classes that provide a level of
    abstraction above Motif, thus simplifying menu and dialog creation, XmStrings,
    XmFontLists, etc. View.h++ supports a Model- View-Controller architecture,
    allowing for an even more object-oriented interface design. Includes a copy
    of Rogue Wave's Tools.h++ (foundation class library)" Rogue Wave also offers
    full support for View.h++.

    It is currently available for Sun Sparc, IBM RS/6000, HP 9000/700 series, SCO,
    Intel SVR4 ESIX. Please call for Silicon Graphics and DEC Ultrix status.

    For additional information, please contact:

    Matt Steinauer
    Rogue Wave Software, Inc.
    P.O. Box 2328
    Corvallis, OR 97339
    Phone: (503)754-3010
    Fax: (503)757-6650
    email: matts@roguewave.com


    Answer: Builder Xcessory 3.0, an interface builder from ICS, allows the user
    to visually build C++ classes from Motif and user-written widgets. C++ code
    is generated in the "Doug Young" fashion. (Doug actually worked on this
    project with ICS.) C and UIL can also be generated.

    Integrated Computer Solutions, Inc. (ICS) 201 Broadway, Cambridge, MA 02139
    USA info@ics.com 617/621-0060

    Answer: Andreas.Baecker@gmd.de wrote: The GINA++ application framework
    contains an encapsulation of the OSF/Motif widg et classes and the Xt
    functionality into C++ classes. Its functionality is comparab le to that of
    the ULowell binding and the WWL. Additionally, it provides an easy-to -use
    framework for modeling new composite and primitive widget classes, plus an
    application framework similar to ET++ or MacApp build on top of it. The
    binding may be used independently from the framework classes. GINA++ is
    available through anonymous ftp from ftp.gmd.de in the directory
    /gmd/ginaplus. Documentation about the Motif binding has been published in
    the X Resource Journal, Number 2, 1992, Pages 106-130. The binding compiles
    with AT&T C++ 2.1 and GNU G+ + 2.1 and has been tested on SunOS 4.1.[12],
    X11R4 and Motif 1.1.3.

    Answer: Motif++ is a library that defines C++ class "wrappers" for the widgets
    defined in the X11R5 OSF/Motif-1.2 widget library. It also supports
    X11R4/Motif-1.1 as well.

    Motif++ is also an application toolkit that provides other tools in
    conjunction with the widget wrapper classes. It has support for the Xbae
    widget set, plus other widgets. It has Imake support, and lots of test files.
    Motif++ also has alot of contributed software.

    Motif++ is very similar to other public domain widget libraries such as The
    Widget Wrapper Library (WWL) and the C++ Binding for OSF/Motif developed at
    the University of Lowell. The two latter libraries are the result of much
    larger efforts.

    Available via anonymous ftp:

    ftp://src.doc.ic.ac.uk/packages/moti....jul.94.tar.gz

    The /packages/motif++ also contains documentation. For more information,
    contact Ronald van Loon (rvloon@motif.xs4all.nl). There is also mailing list
    for Motif++:

    motif++@motif.xs4all.nl

    To join, send email to the administrative address:

    motif++-request@motif.xs4all.nl


    Answer: C++ Report, a magazine published by SIGS Publications, now regularly
    publishes articles on X, Xt and Motif vs. C++ written by Ronald van Loon.

    Answer: Xm++ is a user interface framework for the C++ language built upon X11
    and the X-Toolkit. It is designed to be a simple and intuitive programming
    interface to access the functionality of commonly used widgets. Xm++ was
    initially created for the Motif widget set, now support for the Athena widgets
    was added. Applications created with Xm++ run in both environments without
    changes, although many nice features are only available when using Motif.

    Xm++ is available on: ftp.x.org as: /R5contrib/Xm++.0.53.tar.Z (
    ftp://ftp.x.org/R5contrib/Xm++.0.53.tar.Z ).

    Answer: (updated November. 98) wxWindows is a toolkit for platform-independent
    GUI programming in C++. It consists of several class libraries and tools.
    wxWindows has been made freely available with no commercial restrictions. For
    more information, see http://wxwin.home.ml.org

    Answer: (updated Sept. 95) Intersolv now markets, maintains, and enhances
    C++/Views (formerly from Liant). The C++/Views solution provides an
    extensible object class library with visual development environment. See
    http://www.intersolv.com/cpls.html. Thanks to Uwe Baemayr (uwe@liant.com) for
    the correction.

    Answer: Quest has ObjectViews.

    Answer: Doug Young has written a book "Object Oriented Programming with C++
    and Motif", Prentice-Hall ISBN 0-13-630252-1 about using C++ without requiring
    one of these toolkits.

    Unfortunately, this library (last released in 9/92) has the same name as the
    one by Ronald van Loon (rvloon@motif.hacktic.nl). Motif++1.2 is a library
    that defines C++ class "wrappers" for the widgets defined in the OSF/Motif-1.1
    widget library. Motif++1.2 is also an application toolkit that provides other
    tools in conjunction with the widget wrapper classes. One enhancement of
    Motif++1.2 beyond its wrapper classes are the addition of an "application"
    class which takes care of the low-level tasks including initializing X,
    creating and managing one or more top-level shells, and entering the main
    event loop. Another feature of Motif++1.2 is its integration with The Widget
    Creation Library (Wcl). Motif++1.2 makes it easy to initialize Wcl and create
    C++ wrappers for desired widgets in the widget tree. Availability: anonymous
    FTP at ftp.arc.umn.edu (137.66.130.11), file pub/Motif++1.2.tar.Z. Contact
    Paul Felix, felix@ahpcrc.umn.edu or pfelix@vx.cis.umn.edu.

    submitted by: mvc!biggers@duke.cs.duke.edu ( Mark R. Biggers )

    -----------------------------------------------------------------------------
    Subject: 231) How can I avoid C++ String class and typedef char *String
    conflicts? We're using the USL C++ Standard Components which has the String
    class. This, however, conflicts with the typedef char *String found in

    [Last modified: Oct 94]

    Answer: This is very simple to workaround. I agree that it is "wrong" but all
    you need to do is:

    #define String XtStringType
    #include "all the X files"
    #undef String


    This will translate the offending symbol.

    Thanks to Doug Rand

    -----------------------------------------------------------------------------
    Subject: 232) How can I have a C++ member function in a callback?
    [Last modified: Oct 94]

    Answer: There are three common user problems with C++ callbacks. First, make
    sure you use the correct function prototype for the function declarations.
    Second, the callback function must be declared as a static member of the
    class. Third, when registering it with XtAddCallback(), you must use its full
    signature. For example: (from Ken Lee, http://www.rahul.net/kenton/)


    class MyClass {
    void createWidgets();
    static void myButtonCB(Widget, XtPointer, XtPointer);
    };
    void MyClass::createWidgets() {
    w = XmCreatePushButton(...);
    XtAddCallback(w, XmNactivateCallback, &MyClass::myButtonCB,
    (XtPointer) this);
    }
    void myButtonCB(Widget w, XtPointer clientData, XtPointer callData) {
    MyClass *myclass = (MyClass *) clientData;
    }

    Note that the "this" pointer is used as the client data. This technique is
    popular, but not required.


    Motif++ has a nice tutorial summarizing mechanisms (Ronald van Loon,
    rvloon@motif.xs4all.nl). See his articles in the September, 1994 and
    Nov/December, 1994 issues of C++ Report.

    Doug Young's book deals extensively with one of these. The problem is that you
    don't get the object when you just use the function as a callback. You need
    to pass the object as a pointer through as the client_data. (use "this" as
    the client_data.) Then you can retrieve the object's address, and dereference
    from there. For example (Leo O'Donnell, Email: leo@avs.com),

    class MyButton {
    public:
    MyButton (Widget parent, const char *name) {
    _button = XtVaCreateManagedWidget (
    name, xmPushButtonWidgetClass, parent, NULL, 0);
    XtAddCallback (
    _button,
    XmNactivateCallback,
    &MyButton::activateCB,
    (XtPointer) this);
    }
    ~MyButton () { XtDestroyWidget (_button); }
    private:
    Widget _button;
    static void activateCB (Widget, XtPointer, XtPointer);
    };

    void MyButton::activateCB (Widget, XtPointer thisBtn, XtPointer)
    {
    MyButton *btn = (MyButton *) thisBtn;

    // OK you've got the button instance now. Do some stuff with it!
    }


    -----------------------------------------------------------------------------
    Subject: 233) Is there a Common Lisp binding for Motif?
    [Last modified: Oct 94]

    Answer: Try CLM. This includes a toolkit demon (in C) that takes a widget
    description (with callbacks), and forks a new process for each Motif
    application (which can be just a single menu, or whatever). Lisp can then
    continue running, with a separate lightweight lisp process handling the
    connection & callbacks. In North America & net environs, CLM-2.3.tar.Z is
    available from ftp.x.org.

    There is also CLIM, the Common Lisp Interface Manager. It provides access to
    motif and other toolkits and window systems. Here is some blurb: "Version 2.0
    of the Common Lisp Interface Manager (CLIM) provides access to Motif. CLIM is
    the emerging standard for GUI development in Common Lisp. It offers a set of
    high-level facilities that enable rapid construction of user interfaces.
    Applications written using CLIM are portable across a variety of window
    systems and toolkits. For example, on the X window System, both Motif
    (OSF/Motif) and Openlook (OLIT) are supported. CLIM accesses the toolkit
    directly rather than emulating the look and feel."

    CLIM is available from a variety of Common Lisp vendors including Symbolics
    and Franz Inc. (info@franz.com).

    -----------------------------------------------------------------------------
    Subject: 234) Is there an Ada binding for Motif? (Part 1 of 2)
    [Last modified: Jan 96]

    Answer: Most of the information in this answer (parts 1 and 2) is probably
    very dated by now. If anyone wants to provide updates, I'll include them. In
    the meantime, Ada users are encouraged to visit the Ada Information
    Clearinghouse (AdaIC) at:

    http://sw-eng.falls-church.va.us/AdaIC/

    (The Jan. 96 change updates the information provided by Thomson Software
    Products.)

    Answer: Integrated Computer Solutions, Inc. (ICS) supplies Ada bindings to
    Motif for a number of platforms and Ada compilers. ICS also provides Builder
    Xcessory, a Motif interface builder, which outputs Ada code usable with the
    Ada bindings. The product family is known collectively as the Ada Xcessories.

    Integrated Computer Solutions, Inc. (ICS) 201 Broadway, Cambridge, MA 02139
    USA info@ics.com 617/621-0060


    Information on Ada bindings to Motif and other services (such as SQL and
    POSIX) can be found in a document maintained by the Ada Information
    Clearinghouse. The report can be found at

    host: ajpo.sei.cmu.edu
    loc: /public/ada-info/bindings.hlp.*
    access: anonymous ftp

    The suffix to the file (indicated above with an asterix) is the date of the
    latest update to the document. For example, the full name of the report
    updated on 14 June 1993 would be

    /public/ada-info/bindings.hlp.14Jun93.

    The file is ASCII.

    ------ Included File


    [...Excerpted from the AdaIC report bindings.hlp.14Jun93...]
    [...Updates can be found on ajpo.sei.cmu.edu, in the ...]
    [...file /public/ada-info/bindings.hlp.* The suffix ...]
    [...is always the date of the lastest version to the ...]
    [...report. ...]

    SECTION 12
    X-Window System:
    OSF Motif and Open Look
    Available Ada Bindings


    12.1 Description and Standardization Efforts

    The X-Window System is a network-transparent window system. It supports one
    or more screens containing overlapping windows or subwindows. X display
    servers distribute user input to and accept output requests from various
    client programs located either on the same machine or elsewhere in the
    network.

    OSF Motif (Open Software Foundation/Motif) is a graphical user
    interface from OSF that provides a Presentation Manager look and
    feel for applications running on any system with X Window version
    11. It conforms to POSIX, ANSI C and X/Open's XPG3 standards.

    12.2 Resources Available from Software Reuse Libraries/Repositories


    ASSET (Updated: November 1992)

    The following information was taken in its entirety from the ASSET Library
    Repository Catalog, October 9, 1992. For more information on ASSET, see
    Appendix C.


    INTERFACE TO THE X WINDOW SYSTEM

    VERSION_NUMBER : 1.1
    DEVELOPED_BY : SAIC
    RELEASE_DATE : 29-SEP-88
    UNIQUE_IDENTIFIER : ASSET_A_240
    ALTERNATE_NAME : SAICX2
    ASSET_TYPE : SOFTWARE CODE
    FUNCTIONS : INTERFACE, BIND
    OBJECTS : ADA, X WINDOWS
    KEYWORDS : STANDARDS, BINDINGS
    COLLECTION : STARS FOUNDATIONS
    DISTRIBUTION : UNLIMITED

    DESCRIPTION :

    Interface to the X Window System An expression of the various concepts in Ada
    that provides a full, working Ada specification of the X Window system.
    Approved for public release; distribution is unlimited.

    12.3 Products Available from Vendors


    Advanced Technology Center (Updated: November 1992)

    The Advanced Technology Center (ATC) has an Ada binding to OSF Motif for their
    AXI~ product. AXI is currently available for most UNIX-based platforms, and
    is supported by Verdix, Meridian, and TeleSoft compilers.

    AXI is an Ada-to-X-Window System interface that provides the Ada programmer
    access to the 500+ functions, libraries, and procedures contained in the X
    library (Xlib), the X Toolkit (Xt), the X Extensible Library, the X
    Miscellaneous Utilities, the Motif widget set and the Motif Resource Manager.

    ATC is planning to develop an Ada binding to Open Look for AXI.

    For more information, contact:
    Larry Paulson, Advanced Technology Center, 22982
    Mill Creek Drive, Laguna Hills, CA 92653, USA; Phone:
    714-583-9119

    Thomson Software Products (formerly Alsys) (Updated: Jan
    1996)

    Thomson Software Products markets the following Ada products: ObjectAda,
    AdaWorld for Cross Development, ActivAda, ActivAda Real-Time, and perfoRMAx,
    each described below. (Contact Thomson for pricing info.)

    Product Name: ObjectAda Hardware SPARC-based systems OS Solaris

    ObjectAda is a complete object-oriented environment which is based on the new
    standard for the Ada language, Ada 95. ObjectAda gathers in a single
    integrated environment all the tools needed for the development of Object
    Oriented Ada applications and allows developers to increase productivity by
    simplifying the repetitive tasks of the programming process. ObjectAda
    includes an Ada compiler which emphasizes compile-time error checking to
    reduce mistakes and fully optimized code for compact, high-performance
    applications. A comprehensive, integrated toolset that is easy to use via an
    OSF/Motif-based graphical user interface is included in the ObjectAda
    environment, allowing programmers to reap the full power of all the tools with
    minimum training. The environment also includes an Ada sensitive editor,
    source-level symbolic debugger, profiler, and additional tools and bindings.

    Product Name: AdaWorld for Cross Development Hardware Hosts: SPARC-
    based systems, HP-RT, IBM,
    Targets: 680x0, 80x86, MIPS, PowerPC OS Solaris, SunOS, UNIX, DOS,
    LynxOS

    For developing embedded, real-time applications, Thomson Software Products+
    offers Ada development environments to assure maximum programmer productivity
    while generating highly-optimized Ada applications. Hosted on a broad range
    of platforms, each environment includes a powerful Ada compiler and runtime
    system, as well as a comprehensive, integrated toolset that is easy to use via
    an OSF/Motif-based graphical user interface. The environment also includes an
    Ada sensitive editor, multi-library system, source-level symbolic debugger,
    profiler, and additional tools and bindings. Ada development environments are
    available for cross development targeting the Motorola 680x0, Intel 386/486,
    MIPS, and PowerPC.


    Product Name: ActivAda Hardware 386, 486, or Pentium system OS
    Windows, Windows NT, Windows 95

    ActivAda is an Ada Integrated Development Environment (IDE) delivering the
    combined power of 32-bit architecture, the Windows operating system and Ada in
    one comprehensive product. ActivAda+s robust functionality assures reliable,
    high-quality code with dramatically reduced development time. ActivAda is
    geared to the entire development cycle, providing a Windows Graphical User
    Interface (GUI) with full point-and-click access to all development tools.
    Development of Win32 applications is possible for both Windows, Windows NT
    and Windows 95. In addition, a GUI Builder that generates Ada code, Ada
    bindings to the Win32s API, a Win32s CodeView Debugger, and an interface to
    Microsoft Visual C++ are all included. All of these features are bundled
    together with a validated Ada compiler and comprehensive toolset, providing a
    solid technology base that has been in use in major development projects for
    over 10 years.


    Product Name: ActivAda Real-Time Hardware Hosts: 386/486/Pentium
    Targets: 386/486/Pentium OS Windows, Windows 95

    Finally, developers can create tight, fast code for Intel targets from an
    easy-to-use Windows environment, while enjoying the full benefits of the Ada
    language. We+ve merged two powerful technologies: our award-winning ActivAda
    development environment, and our highly-optimized Intel cross compilation
    system to produce a uniquely powerful and economical real-time development
    platform. ActivAda provides real-time and embedded developers with everything
    they need to create cutting-edge, highly reliable Intel target code, all in
    one package.

    Product Name: perfoRMAx Hardware Hosts: PC OS Windows, Windows
    95, Windows NT

    perfoRMAx is a unique, easy-to-use graphical tool suite that applies the
    mathematical principles of Rate Monotonic Analyst and other scheduling
    techniques to your real-time system. Used during proposal, specification,
    design, implementation, and maintenance phases, perfoRMAx can save months or
    years of wasted effort, millions of wasted dollars, and can even save lives
    and assets. perfoRMAx is an advanced engineering tool that enables real-time
    developers and engineers to focus on the temporal aspects of real-time system
    development and maintenance. Through its unique analysis process, perfoRMAx
    provides a framework for analyzing system timing behavior.


    For more information, contact: Marianne Worley Thomson Software Products
    (formerly Alsys) 10251 Vista Sorrento Parkway Suite 300 San Diego, CA 92121
    Tel: (619) 457-2700 x244 Toll Free: (800) 833-0085 x244 Fax: (619) 452-2117
    Email: adainfo@thomsoft.com WWW: http://www.thomsoft.com/


    Digital Equipment Corporation (Updated: November 1992)

    Digital Equipment Corporation has bindings available for GKS, PHIGS, SQL, and
    OSF Motif for VAX Ada/VMS. The Ada bindings are provided either as part of a
    compiler product or the services/facilities that are provided by Digital and
    its suppliers.

    Host/TargetEC VAX under VMS

    For more information, contact:
    Mary Anne Cacciola, Digital Equipment
    Corporation, 110 Spit Brook Road, Nashua, NH 03062,
    USA; Phone: (603) 881-1028


    IBM (Updated: November 1992)

    IBM's AIX Ada/6000 product provides a binding to GPEF and IBM AIXWindows (X-
    Windows ... not Motif). It runs on all models of the IBM RISC System/6000
    under the IBM AIX Version 3.2 operating system. See also entries for Systems
    Engineering Research Corporation (SERC) and Advanced Technology Center (ATC)
    for Motif, GKS or PHIGS bindings for use with IBM AIX Ada/6000 products.


    The AIX Ada/6000 licensed programs (5706-291 and 5706-294) consist of an
    optimizing compiler, a run-time environment, a symbolic debugger, an Ada
    "makefile" generator for use in automating and minimizing recompilation, Ada
    library management tools and Ada language bindings to some key AIX subsystems.
    With the exception of some system-specific aspects of the language, the Ada
    language for the AIX operating system is source compatible with the Ada
    language supported by IBM licensed programs in VM/CMS and MVS.

    Host/Target:IBM RISC System/6000 under the IBM AIX Version 3.2 operating
    system

    This product conforms to the following standards: ANSI/MIL-STD-1815A - Ada at
    current level (1.11) of the ACVC test suite.


    For more information, contact:
    Barry Lee, IBM Corporation, 844 Don Mills Road,
    North York, Ontario, Canada M3C 1V7; Phone: (416)
    448-3174; Fax: (416) 448-4810


    Objective Interface Systems, Inc. (Updated: November 1992)

    Objective Interface Systems, Inc., has an Ada binding to X-windows (OSF Motif)
    for its Screen Machine~ product. The Screen Machine binding to Motif includes
    a WYSIWYG drawing tool and an Ada code generator.

    Host/Target:

    Sun SPARC/SunOS Rational R1000/Delta HP 9000/7XX; 8X7 IBM RISC
    System/6000/AIXPC 386/486/ISC UNIX HFSI WIS Workstation PC
    286/386/486/MS-DOS PC 386/486/SCO UNIX DEC Ultrix; DEC VMS

    For more information, contact:
    Phil Carrasco, Object Interface Systems, Inc.
    1895 Preston White Drive, Suite 250, Reston, VA
    22091-5448, USA; Phone: (703) 264-1900; Fax:
    703-264-1721; email info@ois.com (internet)


    SL Corporation (Updated: November 1992)

    SL Corporation's SL-GMS toolkit includes Ada bindings to GPEF, GPPF, POSIX,
    SQL, TCP/IP, OSF/Motif, and Open Look.

    SL-GMS is a toolkit for developing dynamic graphics screens for real-time or
    highly interactive applications. Non-programmers can design application
    screens in a standard drawing-tool mode, connect them to real-time data
    sources and animate screen objects to visualize changing data values. SL-GMS
    allows the design of custom "GISMOs" to input values or control the
    application and supports MOTIF, OPEN LOOK and other X toolkit widgets.

    SL-GMS is used extensively to provide real-time graphics for applications in
    the fields of manufacturing, process control, network management, avionics and
    financial tracking.

    Host/Target:Validated Verdix and DEC compilers support SL-GMS for the
    following machines as both host and target:


    DEC-DECstation/ULTRIX 4.0DEC-VAXstation/ULTRIX 4.0
    DEC-VAXstation/VMS 5.4 DEC-VAXstation/VMS 5.5

    IBM-RS6000/AIX

    HP-9000/300/UNIX HP-9000/400/UNIX
    HP-9000/800/UNIX HP-9000/700/UNIX

    PC-386/IX UNIX PC-386/SCO UNIX
    PC-386/Lynx PC-386/0S2
    PC-386/System 5.4

    SGI-4D/IRIX 3.3

    Sun-3/SunOS 4.1 SunSPARC/SunOS 4.1

    88 Open/BCS Compliant

    For more information, contact:
    Mike Meagher, SL Corporation, 240 Tamal Vista
    Boulevard, Corte Madera, CA 94926, USA Phone: (415)
    927-1724; Fax: (415) 927-2931


    Sunrise Software International (Updated: May 1992)

    Sunrise Software International's product, ezx, is a rapid application
    development tool that automates the creation of graphical user interfaces for
    OSF/MOTIF and generates C, UIL, or Ada. ezx provides WYSIWYG screen layout;
    color, font and pixmap editors; presentation tools and dialog management. A
    prototype can be developed in hours and using a script language similar to
    Hypertalk, demonstrated to end-users before the first line of code is written.
    Then portable C, UIL or Ada can be generated automatically. Ada bindings are
    provided. The total code required to develop a GUI is reduced by
    approximately 75%. The appearance and behavior of the GUI is defined in an X
    resource file which the application loads at run time. This provides explicit
    separation between the GUI and the computational core of the application. Thus
    the GUI can be revised without recompiling (and retesting) the application.

    ezx provides cost savings throughout the software development cycle, from
    requirements analysis through design, code, test and maintenance.


    Host/TargetEC RISC under ULTRIX, DEC VAX under VMS, IBM 386 under UNIX, IBM
    RS 6000 under AIX, SGI under, SUN SPARC under UNIX

    For more information, contact:
    Frederick Sells, Sunrise Software International,
    170 Enterprise Center, Middletown, RI 02840, USA;
    Phone: 401-847-7868

    Systems Engineering Research Corporation (SERC) (Updated: November 1992)

    -----------------------------------------------------------------------------
    Subject: 235) Is there an Ada binding for Motif? (Part 2 of 2)
    [Last modified: Apr 94 ]

    Answer: (This answer hasn't changed since the date given, but I needed to
    break it into 2 parts.)

    SERC's Ada/MOTIF is a complete binding to X Window and OSF/Motif for the Ada
    programming language that was based in part upon the SAIC/Unisys (STARS)
    public domain bindings. That work was leveraged as a starting point for this
    development; many of the bug fixes and additional capabilities beyond the
    public domain releases in Ada/MOTIF have been incorporated. Most noteworthy
    are the capabilities included in Ada/Motif for Ada tasking, callback
    registration, memory leak detection/prevention and capabilities for developing
    customized widgets. Paramax/STARS considers Ada/Motif to be the commercial
    version of their STARS bindings, according to SERC.

    Ada/MOTIF is supported by the ALSYS, VERDIX, SUNAda, IBM Ada, and SGI Ada
    compilers.


    Host/Target:SUN 4, HP 300/400, HP 700, IBM RS 6000, SGI, 386
    SUN OS 4.1.1, SOLARIS 2.0 (coming), HPUX 8.0, SGI 3.2 & 4.0, IBM
    ATX 3.2, SCO 3.2

    For more information, contact:

    Theo Kusiolek or Scott Cleveland, Systems Engineering Research Corporation
    (SERC), 2555 Charleston Road, Mountain View, CA 94043, USA; Phone: 800-ADA-
    SERC or 415/962-9092; Fax: 415/962-0330; E-mail: Well!sercmail@apple.com.


    TeleSoft (Updated: November 1992)

    TeleSoft's TeleUSE/Ada automates the creation of OSF/Motif graphical user
    interfaces for Ada applications. It includes a special version of the TeleUse
    User Interface Management System -- which generates Ada source code -- and Ada
    bindings to the TeleUSE run-time routines.

    TeleUse/Ada tools allow a GUI to be prototyped and designed using a WYSIWYG
    editor and a PDL, and also includes tools for debugging, generating production
    code and maintaining the GUI. TeleUse/Ada can save the developer up to 90
    percent of the time required to hand code X Window System GUIs.

    Host/Target:SPARC under UNIX, Sun-4 under UNIX

    TeleSoft's TeleWindows is a set of Ada bindings to the X Window System and
    OSF/Motif. This includes Xlib, XT, X extensions Library, XT+, X miscellaneous
    utilities, Motif widget set, XM, MWM, Motif resource manager. It supports X-
    11 R4 and is not based on the public domain version. It closely follows the C
    Xlib syntax and allows Ada applications to co-exist with C applications.

    Host/Target:IBM System/370 under VM/CMS

    For more information, contact:
    Karen Johnson, TeleSoft, 5959 Cornerstone Court
    West, San Diego, CA 92121-9891, USA; Phone: (619) 457-2700


    Verdix (Updated: May 1992)

    The Verdix Ada Development System (VADS), is a complete Ada Compiler System
    offering a fully validated Ada compiler with chapter 13 support. Verdix
    supplies VADSself and VADScross. VADSself provides a complete toolset for
    self-targeted applications. It easily interfaces to databases, windowing
    systems and program management tools. VADScross provides real-time support
    for host-to-target system development. VADScross produces small and fast
    object code. VADS is hosted on the largest number of platforms and targets
    the greatest number of microprocessors.

    Host/Target:88000 BCS under UNIX, DEC VAX under VMS / ULTRIX / UNIX,
    DECStation (RISC) under UNIX, DECSystem (RISC) under UNIX, HP 9000
    Series 300 under HP-UX (UNIX), IBM PS/2 under AIX (UNIX), IBM
    RISC System/6000 under AIX, SCO Systems V/386 (ABI) under UNIX,
    Sun SPARC systems under UNIX, Sun-3 systems under UNIX

    Verdix AXI provides an Ada binding to the full Motif, Xt, and Xlib libraries.
    The product works with user-supplied Motif 1.1 and X11R4 libraries regardless
    of source.

    Host/TargetEC RISC under Ultrix, IBM RS6000 under AIX, MIPS under MIPSos,
    Sun-4 under SunOS, Sys V386 under ISC UNIX, Sys V386 under SCO
    UNIX

    For more information, contact:
    Tim Ruhe, Verdix Corporation, 205 Van Buren,
    Herndon, VA 22070, USA; Phone: (703) 318-5800

    Answer: Integrated Computer Solutions, Inc. (ICS) supplies Ada bindings to
    Motif for a number of platforms and Ada compilers. ICS also provides Builder
    Xcessory, a Motif interface builder, which outputs Ada code usable with the
    Ada bindings. The product family is known collectively as the Ada Xcessories.

    Integrated Computer Solutions, Inc. (ICS) 201 Broadway, Cambridge, MA 02139
    USA info@ics.com 617/621-0060

    -----------------------------------------------------------------------------
    Subject: 236) Is there a Poplog binding for Motif?
    [Last modified: May 93]

    Answer: A integrated programming environment consisting of the programming
    languages Pop-11, Prolog, Standard ML, and Lisp which are compiled to machine
    code via a common virtual machine. Pop-11 provides a rich interface to the X
    Toolkit which can be accessed from all other Poplog languages. The OLIT,
    Motif, and Athena widget sets are supported, in addition to the custom Poplog
    (Xpw) widget set. XVed provides a sophisticated, customisable multi-window
    editor. Under OPEN LOOK and Motif the Poplog User Interface (PUI) provides a
    graphical interface to the Poplog system. High-level Pop-11 libraries allow
    graph drawing, turtle graphics, and the simple creation of basic button/menu
    based interfaces.

    Contact:

    UK EDUCATION SITES:
    Poplog Sales. School of Cognitive and Computing Sciences.
    Brighton. BN1 9QN. England.
    Phone: +44 (0)273 678188
    Email: popsales@cogs.susx.ac.uk
    USA AND CANADIAN EDUCATION SITES:
    Computable Functions Inc. 35 South Orchard Drive. Amherst.
    MA 01002. USA.
    Phone: (413) 253-7637
    ALL OTHER SALES:
    Integral Solutions Ltd. Unit 3, Campbell Court. Bramley.
    Basingstoke. Hampshire. RG26 5EG. England.
    Phone: +44 (0)256 882028
    Fax: +44 (0)256 882182
    Email: isl@integ.uucp


    -----------------------------------------------------------------------------
    Subject: 237) TOPIC: SPECIFIC PLATFORMS

    -----------------------------------------------------------------------------
    Subject: 238) Is it easy to build Motif for a Sun?

    Answer: See next question for Solaris 2. No pattern has emerged to problems
    about compiling Motif on the Sun (although people seem to have a lot of
    different minor problems), and many reports are that it is straightforward.
    Read the Motif install instructions (which often have specific reference to
    Sun installation), light the blue touch paper and just standback. [My
    experience was that I had to add -D_NO_PROTO for 1.1 on a Sparc OS 4.1, and
    that was all. Others have added STRINGS_ALIGNED and NO_REGEXP].

    -----------------------------------------------------------------------------
    Subject: 239) How do I build Motif 1.2.2 on Solaris 2.1 with Sun C?
    [Last modified: Oct 94]

    Prepared by Ric Steinberger. ric@updike.sri.com 4/09/93

    What follows is a description of the steps I used to build Motif 1.2.2 on a
    SUN IPX running Solaris 2.1. Sun's C compiler (2.0.1) was used. Many thanks
    go to Kaleb Keithley (kaleb@devvax.jpl.nasa.gov) for several useful
    suggestions. Other people, including OSF staff, especially David Brooks
    (dbrooks@osf.org), helped as well. My thanks to you all.

    1. Build X11R5 from the mit distribution. You need to retrieve the sources
    from ftp.x.org (in pub/R5) and patches 1 - 22 (or fixes 1-26) pub/R5/fixes).
    There are several other sites that contain the X11R5 sources. After
    installing patch 19, apply PEXlib.tar.Z, also available from ftp.x.org in
    pub/R5/fixes. You can apply also R5.Xsun.multi-screen and R5.SunOS5.patch.
    There are .README files that explain how to patch. Be SURE to read
    R5.SunOS5.patch.README for details on how to BUILD X11. You probably want to
    use the ProjectRoot feature in the site.def file in the mit/config directory.
    You will NEED to edit that file to do that.

    2. Obtain the Motif 1.2.2 distribution from OSF (617-621-7300). You may need
    to first install the 1.2 tape, then the 1.2.1 and finally the 1.2.2 tape. You
    might want to do a "chmod -R u+w ." after unloading each tape.

    3. In the config directory, there are several changes. Some of the changes
    are based on R5.SunOS5.patch files. A complete set of config files relevant
    to Solaris have been placed in the anon-ftp account of updike.sri.com in
    pub/motif/solaris21-motif122-config.tar.Z. They are also available from OSF
    on their mail response server (available to support contract holders) and they
    will send them directly to full support contract holders. Decompress and
    untar this file in your Motif config subdirectory. Copy site.def.sample to
    site.def, then edit site.def. You will probably want to uncomment the
    ProjectRoot section and use the same value used in your X11R5 build. Also,
    you will probably want to use /usr/ucb/install in you installed the UCB
    compatibility suite. Otherwise you might want to use the install supplied at
    the end of this memo. [I used the UCB version and can't swear that this
    works. Bit it should. Put it someplace like /usr/local/bin and chmod +x it.]

    There are two patches to consider. One fixes a cursor problem in
    ../lib/Xm/TextF.c. The other removes a Berkeleyism. These patches should
    probably be consider unofficial at present. Failure to deal with the
    Berkeleyism (bzero) means you will need to link with -lucb -lelf. This will
    probably work, but why bother? Furthermore, if you move the Motif binaries to
    a machine without the ucb compatability suite, you won't have the sharable
    libs you need.

    [The actual patches have been censored because they contain OSF source code]

    Patch 1: In TextF.c there are several places _XmTextFieldDrawInsertionPoint is
    called. These should be moved two or three lines further down *after* the "if
    (!XtIsRealized(tf)) return True;" statement.


    patch 2: The call to bzero in lib/Xm/Visual.c should be replaced by the
    equivalent call to memset


    Both these patches can be applied in the ./lib/Xm directory. If you don't
    have the patch program (how did you build X11?), you can get it in the
    vendor/cygnus directory of ftp.uu.net, or you can build it from source. Be
    sure to get the latest version (2.0.12.u8).

    4) Use the README-1.2.1 file as a guideline for building motif. I followed
    directions in the section called, "Using X11R5 Installed Libraries and Header
    Files." If you make a mistake after your first build attempt, copy
    Makefile.ini to Makefile before retrying. You may need to do this in the
    config subdirectory too, depending on what went wrong.

    5) After make Makefiles, do make includes, make depend, then make (or as OSF
    recommends, make -k). This gets as far as motifshell in the demos, which
    fails to build because O_RDONLY and L_XTND are not defined. O_RDONLY is in
    fcntl.h (actually , but fcntl.h includes this.) L_XTND can be
    replaced by SEEK_END. SEEK_END is in stdio.h. These two fixes will allow
    motifshell to build. Note: many MANY compiler warning messages will be
    generated during the build process.

    6) You can go to the demos/xmsamplers directory and do a make there. Other
    demos may build, or not depending on whatever. . . .

    7) make install will do the install. [It will fail at motifshell if you don't
    fix it, as mentioned above.] You can do a make install in demos/xmsamplers if
    you want these.

    8) If running on a SUN (as opposed to an X term), you will (probably) need to
    start openwin with something like:

    openwin -server /usr/X11R5/bin/Xsun


    [You might want to use an alias for this.] This fixes an annoying problem: The
    mouse keys stop working after you click on an icon to get the icon menu (on
    SUNs only, not X terms). The ALT keys still work, if you get stuck. I don't
    know whether this is a bug in SUN's server or whether it is Motif related.

    Here is a copy of my .xinitrc: It's not elegant. Sun's default openwin
    startup file is in: /usr/openwin/lib/Xinitrc. You can copy this to ~/.xinitrc
    and customize as desired. Obviously, the default behavior is to start the
    OpenLook environment (boo!).


    #!/bin/sh
    #
    # .xinitrc - OpenWindows startup script.
    #
    if [ -f $HOME/.Xdefaults ]; then
    xrdb $HOME/.Xdefaults # Load Users X11 resource database
    fi
    if [ -f $HOME/.Xdefaults.sun ]; then
    xrdb -merge $HOME/.Xdefaults.sun
    fi
    DISPLAY=`hostname`:0.0
    export DISPLAY
    xhost + > /dev/null
    #xterm -sb -sl 512 -T `hostname` -ls -n `hostname` &
    xterm -sb -sl 512 -T `hostname` -n `hostname` &
    mwm &
    xclock -geometry +1010+0 &
    xload -geometry +710+5 -fg red &
    xsetroot -solid salmon &
    xterm -sb -sl 100 -T CONSOLE_DO_NOT_LOGOUT -C -n console -iconic
    #wait

    Here's .Xdefaults.sun, which gives me a more readable font for use with
    motif on Sun monitors:

    !Some additional .Xdefaults values specifically for SUN
    !
    ! After loading .Xdefaults, xrdb -merge .Xdefaults.sun
    !
    Mwm*fontList: 8x16
    !Mwm*fontList: vtbold
    !Change as desired.


    You will probably want to maintain LD_LIBRARY_PATH to something like:
    /opt/SUNWspro/lib:/usr/ccs/lib:/usr/ucblib:/usr/X11R5/lib:/usr/lib:
    /usr/openwin/lib. If you use emacs, you will need to leave /usr/openwin/lib
    there. [This is because you probably, like me, used the distributed version
    of s-sol2.h, which explicitly refers to windowing libraries as being in the
    /usr/openwin locations. Yes, I know that emacs/Solaris ought to allow
    LibXt.so.N.M to be "picked up" from elsewhere, like /usr/X11R5/lib, but the
    one emacs links with is LibXt.so.4.something, and the mit one is
    LibXt.so.5.something. So it seems to want the .4 one. Any comments? I'd
    prefer not to rebuild emacs based on the X11R5 libs because I occassionally
    need to move the emacs binaries to machines without the mit files.]

    -----------------------------------------------------------------------------
    Subject: 240) What compile errors/warnings might I get in both Sun 3 and Sun
    4?

    Answer:


    make: Warning: Too many rules defined for target
    make: Warning: Too many rules defined for target
    "callbacks.c", line 1530: warning: illegal combination of pointer
    and integer, op =
    "callbacks.c", line 1531: warning: illegal combination of pointer
    and integer, op =
    "callbacks.c", line 1532: warning: illegal combination of pointer
    and integer, op =
    "utils.c", line 73: warning: illegal combination of pointer and integer, op =
    "utils.c", line 74: warning: illegal combination of pointer and integer, op =
    "utils.c", line 122: warning: illegal combination of pointer and integer, op =
    "utils.c", line 123: warning: illegal combination of pointer and integer, op =
    "utils.c", line 191: warning: illegal combination of pointer and integer, op =
    "utils.c", line 194: warning: illegal combination of pointer and integer, op =
    "utils.c", line 195: warning: illegal combination of pointer and integer, op =
    "utils.c", line 196: warning: illegal combination of pointer and integer, op =
    "utils.c", line 316: warning: illegal combination of pointer and integer, op =
    "utils.c", line 334: warning: illegal combination of pointer and integer, op =
    "utils.c", line 338: warning: illegal combination of pointer and integer, op =
    "utils.c", line 341: warning: illegal combination of pointer and integer, op =
    "xmdialogs.c", line 838: warning: illegal combination of pointer
    and integer, op =
    "xmeditor.c", line 1152: warning: illegal combination of pointer
    and integer, op =

    These warning messages can be ignored. OSF is aware of these warnings.


    -----------------------------------------------------------------------------
    Subject: 241) On a Sun 3, what are the mwm startup error messages about? I
    get

    mwm: Invalid accelerator specification on line 7 of
    specification string
    mwm: Invalid accelerator specification on line 31 of
    configuration file


    Answer: This is because some Sun keyboards do not have an F10 key and some sun
    workstations which have an F10 key do not have X-servers which recognize it.
    The F10 key is used by mwm. If the machine does have an F10 key, the user
    should use xmodmap to tell the server it exists. Otherwise, change the
    definition of the DefaultWindowMenu in /usr/lib/X11/system.mwmrc (after
    installation) or in /lib/clients/mwm/system.mwmrc (before installation).
    Change the accelerator of "Maximize" (it is "AltF10)" to something else.
    Also, you should change the definition of DEFAULTSYSTEMMENU in the file
    /clients/mwm/WmResource.c in a similar fashion. There is as yet no standard
    redefinition for F10.

    -----------------------------------------------------------------------------
    Subject: 242) Are there problems making shared libraries on a Sun?

    Answer: If you use the -pic option you may run out of offset table space. use
    the -PIC option instead.

    You may get the message "ld.so: Undefined symbol: __XtInherit" when executing
    UIL. There is a problem in shared library build when you compare a function
    variable to a routine name, but don't call the routine. Either, you can build
    the Xt library nonshared, or you can put a reference to XtToolkitInitialize in
    the UIL main program (or even include a module that references it). The
    routine doesn't even have to be called; it just has to be there.

    -----------------------------------------------------------------------------
    Subject: 243) Why does the OpenWindows server hangs when I popup a menu with
    Button 3?
    [Last modified: August 92]

    Answer: This is an OpenWindows problem, but if you have Motif source you can
    fix your own applications. From Steve Sistare of Thinking Machines Corp.:
    "Change the 2 calls to XtGrabButton in RowColumn.c such that ButtonReleaseMask
    | ButtonPressMask is passed for the event mask. Currently, only
    ButtonReleaseMask is passed. Also, change the owner_event argument to FALSE.
    " This has not been fixed in Motif as at 1.1.5.

    -----------------------------------------------------------------------------
    Subject: 244) Has anyone made shared libraries on an IBM RS/6000?

    Answer: [NOTE: This may not a problem any longer; I believe that AIX is now
    delivered with shared Xm libraries. If you know the status of this, email
    kenton@nojunk.rahul.net.]

    Sakari Jalovaara wrote: There is a problem: Xm redefines VendorShell and the
    AIX linker put _both_ Xm's and Xt's VendorShell into programs. When an AIX
    shared library is created as many references inside the library are resolved
    as possible. If the symbol vendorShellClassRec is defined in libXt and
    referenced, say, from a function XtFoo() also in libXt, the "ld" run that
    creates the shared library resolves the reference:

    XtFoo() -> vendorShellClassRec

    Then I create the Motif library that has its own vendorShellClassRec and an
    XmBar() function that uses it; libXm will also contain a resolved reference to
    vendorShellClassRec:

    XmBar() -> vendorShellClassRec

    Finally, I link a program that uses both XtFoo() and XmBar() and the program
    will end up with _two_ independent "vendorShellClassRec"s:

    XtFoo() -> vendorShellClassRec [Xt version]
    XmBar() -> vendorShellClassRec [Xm version]

    Instant schizo zaphod mode. In reality, vendorShellClassRec is not referenced
    from functions but from other widget class records.

    I can't just pull Vendor.o out from the shared Xt (Vendor.o appears to define
    the only external symbols redefined by libXm) because AIX shared libraries
    apparently can't contain unresolved external references. If I take out
    Vendor.o I have to take out every other file that uses symbols defined there -
    and then files that need those files, etc. I tried it and ended up with three
    or four object files in libXt and the res non-sharable.

    I kludged around this by putting all of libXt (minus Vendor.o) into the shared
    libXm. It isn't a pretty solution but it works - and beats having a
    statically linked two-megabyte "periodic" demo...

    -----------------------------------------------------------------------------
    Subject: 245) What is the error "Unaligned access in XmString" under Ultrix?

    Answer: Compile XmString.c with STRINGS_ALIGNED.

    -----------------------------------------------------------------------------
    Subject: 246) Can bugs in Sun's OpenWindows server cause Motif clients to
    crash?
    [Last modified: Oct 95]

    Answer: Yes. Patch 100444-73 (or later) from Sun fixes most of these bugs.
    Alternatively, you can compile and run the X11R6 sample server from MIT. See
    the SunSolve web page:

    http://sunsolve1.sun.com/pub-cgi/patchpage.pl

    Ken Lee and Bob Cox, rwcox@mcw.edu.

    -----------------------------------------------------------------------------
    Subject: 247) Why does Motif on Linux crash when I open a file selection box?
    [Last modified: Oct 98]

    Answer: Make sure you use a libc that is compatible with your Motif.
    Unfortunately, Linux libc is not binary compatible from release to release.
    Older versions of Motif require libc 4.6.27. Some newer Motifs need libc5;
    others need glibc.

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

    -----------------------------------------------------------------------------
    Subject: 248) Are there compatibility problems between some Linux Motif
    libraries and libc5 or glibc?
    [Last modified: Oct 98]

    Answer: Yes. People have reported problems with the file selection box and
    also with the OSF keysyms.

    The problem is that some newer Linux packages (e.g., Red Hat 5.0) use glibc
    (library and associated header files), which is not binary compatible with the
    older libc5. Some newer Motif libraries use glibc, while older ones will use
    libc5. Similarly the XFree and other libraries will be based on either libc5
    or glibc. You must make sure you use one other the other consistently for all
    your applications and libraries. The better Motif vendors should have an
    upgrade strategy in place to help you with the transition.

    This is a general problem that the Linux community is dealing with. If you
    can't get the correct version information from your Motif vendor, the Linux
    Usenet newgroups should be able to help you out.

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

    -----------------------------------------------------------------------------
    Subject: 249) How can I install Motif on my PC?
    [Last modified: Jun 98]

    Answer: There's a paper on this in the September, 1995 issue of *The X
    Advisor*:

    http://www.rahul.net/kenton/txa/sep95.html


    A 1996 update to this article is available at:

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

    Ken Lee

    -----------------------------------------------------------------------------
    END OF PART SEVEN

  6. 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

  7. Motif FAQ (Part 6 of 9)

    Archive-name: motif-faq/part6
    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: 156) TOPIC: DRAWING AREA WIDGET

    -----------------------------------------------------------------------------
    Subject: 157) How can I send an expose event to a Drawing Area widget? (or
    any other, come to that). I want to send an expose event so that it will
    redraw itself.
    [Last modified: Nov 97]

    Answer: Use the Xlib call

    XClearArea(XtDisplay(w), XtWindow(w), 0, 0, 0, 0, True)

    This clears the widget's window and generates an expose event in doing so.
    The widgets expose action will then redraw it. This uses a round trip
    request. An alternative, without the round trip is

    from orca!mesa!rthomson@uunet.uu.net (Rich Thomson):

    Widget da;
    XmDrawingAreaCallbackStruct da_struct;

    da_struct.reason = XmCR_EXPOSE;
    da_struct.event = (XEvent *) NULL;
    da_struct.window = XtWindow(da);

    XtCallCallbacks(da, XmNexposeCallback, (XtPointer) &da_struct);

    Thanks to rand@ling.umu.se (Ola Andersson) for a correction to the above.


    -----------------------------------------------------------------------------
    Subject: 158) How can I know when a DrawingArea has been resized? It
    generates an expose event whn it is enlarged, but not when it is shrunk.

    Answer: Use the resize callback.

    -----------------------------------------------------------------------------
    Subject: 159) How can I create a drawing area widget with a visual type
    different from its parent?
    [Last modified: Sep 97]

    Answer: The standard Motif drawing area does not support this. You can,
    however, easily create a subclass with a new Realize class method. You may
    want to create visual type, colormap, and depth resources so you can set these
    values at initialization time.

    In SGI's Motif, such a widget is called SgVisualDrawingArea. Other Motif
    implementations may have similar widgets.

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

    -----------------------------------------------------------------------------
    Subject: 160) How can I display postscript in a Motif widget, such as
    XmDrawingArea?
    [Last modified: Sept 95]

    Answer: Richard M. Goldstein (rickg@Eng.Sun.COM) writes: If your system
    supports the Display PostScript extension (or NX agent), the newer revs of the
    dpstkXm library contains a type of drawing area widget designed specifically
    for use with DPS. Source for the latest DPS client-side is also ftp'able from
    contrib.

    Ramiro Estrugo (restrugo@fateware.com) writes: Have a look at ghostscript.
    [With] a little editting, you can extract the Ghostview widget and use it in
    your application...

    -----------------------------------------------------------------------------
    Subject: 161) TOPIC: MAIN WINDOW WIDGET

    -----------------------------------------------------------------------------
    Subject: 162) How can I create a message window in an XmMainWindow?
    [Last modified: Nov 95]

    Answer: XmMainWindow supports a message window, but you cannot specify it via
    XmMainWindowSetAreas(). Instead, create the widget as a child of the
    XmMainWindow, then specify to the XmMainWindow with XtSetValues() of
    XmNmessageWindow.

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 163) TOPIC: SCROLLED WINDOW WIDGET

    -----------------------------------------------------------------------------
    Subject: 164) How do I tell if a scrolled window's scrollbars are visible?

    Answer: Use XtGetValues() to get the scrollbar widget ID's, then use
    XtIsManaged() to see if they are managed (visible).

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 165) How can I programatically scroll a XmScrolledWindow in
    XmAUTOMATIC mode?

    Answer: In Motif 1.2, use XmScrollVisible(). If you're using a scrolled text
    or scrolled list combination widget, use XmTextScroll() or XmListSet*()
    instead.

    The Motif manuals specifically forbid manipulating the scrollbars directly,
    but some people have reported success with XmScrollBarSetValues, with the
    "notify" parameter set to "True".

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 166) What widget does the XmScrolledWindow use for its clip window?
    [Last modified: Apr 98]

    Answer: In Motif 1.2, if the XmScrolledWindow is using the XmAUTOMATIC
    scrolling policy, it automatically creates an XmDrawingArea widget as its clip
    window. If you wish, you can retrieve the XmDrawingArea's widget ID by using
    XtGetValues on the XmNclipWindow resource and then set resources on that
    widget. Some useful resources are XmNbackground and XmNresizeCallback.

    Note that Motif 2.X uses a new XmClipWindow widget instead of the
    XmDrawingArea. Since XmClipWindow is subclassed from XmDrawingArea, the above
    resources should still work.

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 167) How do I create a scrolled window with only one scrollbar?
    [Last modified: July 95]

    Answer: If you're using the default application-defined scrolling mode, you
    can just create one and specify NULL for the other. If, however, you're using
    automatic scrolling, retrieve the ID of the unwanted scrollbar with
    XmNhorizontalScrollBar or XmNverticalScrollBar and unmanage that widget:


    Widget hScroll;
    XtVaGetValues(scrollbar, XmNhorizontalScrollBar, &hScroll, NULL);
    XtUnmanageChild(hScroll);


    Thanks to Ken Lee, http://www.rahul.net/kenton/. Typo corrected by Paul
    Tomblin, ptomblin@canoe.com.

    -----------------------------------------------------------------------------
    Subject: 168) TOPIC: MENUS

    -----------------------------------------------------------------------------
    Subject: 169) How can I change the cursor used in Motif menus?
    [Last modified: Oct 95]

    Answer: Set XmNmenuCursor on XmScreen (Motif 1.2) or XmRowColumn (Motif 1.1).
    This should be set globally at start-up time, e.g., usually via an app-
    defaults file.

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 170) How do I put my help menu on the far right of my menubar?
    [Last modified: Oct 95]

    Answer: Set the XmNmenuHelpWidget resource of the menu bar to the help menu's
    cascade button.

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 171) Can I change or disable the menu bar accelerator from the
    default (F10)?
    [Last modified: May 97]

    Answer: Changing it will confuse some of your users. If you must, this
    accelerator is controlled by these resources on the menu bar's XmRowColumn:
    XmNpopupEnabled (enables accelerators) and XmNmenuAccelerator (specifies the
    accelerator key).

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 172) How do I set the current choice in a radio box or an option
    menu?
    [Last modified: May 95]

    Answer: Set the XmNmenuHistory resource on its XmRowColumn parent.

    Ken Lee

    buser@tartan.com (Mark) sent this code fragment:

    Widget menu;
    int num_buttons;
    WidgetList buttons;

    XtVaGetValues( simple_option_widget, XmNsubMenuId, &menu, NULL);

    XtVaGetValues( menu, XmNnumChildren, &num_buttons,
    XmNchildren, &buttons, NULL ) ;

    and change current selection with:

    XtVaSetValues( simple_option_widget, XmNmenuHistory, buttons[index], NULL ) ;

    /* where index is between 0 and num_buttons */

    Thanks to Phil Gehlich for a correction.

    -----------------------------------------------------------------------------
    Subject: 173) How can I determine the item selected in a a radio box or
    option menu?

    Answer: The value of the XmNmenuHistory resource of the XmRowColumn parent is
    the widget ID of the last selected item. It works the same way for all menus
    and radio boxes.

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 174) How can I change the cascade indicator on an option menu?
    [Last modified: Dec 97]

    Answer: Set XmNcascadePixmap on the option menu's cascade button gadget.

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 175) How do I unset an XmToggleButton in a radio box? If a radio-
    mode toggle button is set and I XtSetValues XmNset a different toggle button,
    the first radio button is not automatically unset. How do can I automatically
    unset the first button?
    [Last modified: Jun 98]

    Answer: There are two easy ways to do this. First, you can set the toggle
    with XmNmenuHistory on the radio box instead of XmNset on the toggle button.
    Second, you can use XmToggleButtonSetState() with True for the notify
    argument.

    Note that some people have reported that XmNmenuHistory correctly sets the
    toggle state but the toggle is not always redrawn to show the new state. This
    is a bug in their implementation of Motif. If you cannot get a patch, you
    should use the XmToggleButtonSetState() method.

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 176) Can I place a radio box in a pulldown menu?
    [Last modified: May 97]

    Answer: You cannot place a XmRowColumn widget child in a menu pane. Since the
    menu pane itself is a XmRowColumn widget, however, you can enable
    XmNradioBehavior on it. This only works if all of the menu items are radio
    buttons.

    An alternative is to manage your radio behavior via your button callback
    functions. This is more work, but much more flexible.

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 177) How do I make a menu choice insensitive if it was created with
    XmVaCreateSimplePulldownMenu?
    [Last modified: Sept 94]

    Answer: According to the Motif manual, the buttons are named "button_n", where
    "n" is an integer starting from 0. You can use XtNameToWidget() to convert
    these names to widget ID's.

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 178) What widgets can I put inside a menubar?
    [Last modified: Oct 95]

    Answer: You can only put cascade buttons (widgets or gadgets) in the top level
    of menubars. However, the children of these cascade buttons can be pushbuttons
    with labels, pushbuttons with pixmaps, toggle buttons, separators, other
    cascade buttons.

    -----------------------------------------------------------------------------
    Subject: 179) Can I have a cascade button without a submenu in a pulldown
    menu?

    Answer: Yes you can. A cascade button has an activate callback which is called
    when you click on it and it doesn't have a submenu. It can have a mnemonic,
    but keyboard traversal using the arrow keys in the menu will skip over it.

    -----------------------------------------------------------------------------
    Subject: 180) Should I have a cascade button without a submenu in a pulldown
    menu?

    Answer: No. This is forbidden by the style guide. Technically you can do it
    (see previous question) but if you do it will not be Motif style compliant.
    This is unlikely to change - if a "button" is important enough to be in a
    pulldown menu bar with no pulldown, it should be a button elsewhere. (Mind
    you, you won't be able to put accelerators on it elsewhere though.)

    -----------------------------------------------------------------------------
    Subject: 181) What is the best way to create popup menus?
    [Last modified: August 92]

    Susan Murdock Thompson (from OSF): In general, create a popupMenu as the child
    from which you will be posting it from (ie: if you have a bulletinBoard with a
    PushButton in it and want MB2 on the pushButton to post the popupMenu, create
    the popupMenu as a child of the pushButton). [This parent-child relationship
    seems to make a big difference in the behavior of the popups.] Add an event
    handler to handle buttonPress events. You'll need to check for the correct
    button (what you've specified menuPost to be) before posting the menu.

    To create a popup that can be accessible from within an entire client window,
    create it as the child of the top-most widget (but not the shell) and add
    event handlers for the top-most widget and children widgets.

    ie:


    {

    XtManageChild(rc=XmCreateRowColumn(Shell1, "rc", NULL, 0));
    XtManageChild(label = XmCreateLabel(rc, "label", NULL, 0));
    XtManageChild(text = XmCreateText(rc, "text", NULL, 0));
    XtManageChild(pushbutton = XmCreatePushButton(rc, "pushbutton", NULL, 0));

    n = 0;
    XtSetArg(args[n], XmNmenuPost, ""); n++;
    popup = XmCreatePopupMenu(rc, "popup", args, n);

    XtAddEventHandler(rc, ButtonPressMask, False, PostMenu3, popup);
    XtAddEventHandler(text, ButtonPressMask, False, PostMenu3, popup);
    XtAddEventHandler(label, ButtonPressMask, False, PostMenu3, popup);
    XtAddEventHandler(pushbutton, ButtonPressMask, False, PostMenu3, popup);

    XtManageChild(m1 = XmCreatePushButton(popup, "m1", NULL, 0));
    XtManageChild(m2 = XmCreatePushButton(popup, "m2", NULL, 0));
    XtManageChild(m3 = XmCreatePushButton(popup, "m3", NULL, 0));

    XtAddCallback(m1, XmNactivateCallback, SayCB, "button M1");
    XtAddCallback(m2, XmNactivateCallback, SayCB, "button M2");
    XtAddCallback(m3, XmNactivateCallback, SayCB, "button M3");
    }

    /* where PostMenu3 is ... */

    PostMenu3 (w, popup, event)
    Widget w;
    Widget popup;
    XButtonEvent * event;
    {
    printf("menuPost = 3, button %d\n", event->button);

    if (event->button != Button3)
    return;
    XmMenuPosition(popup, event);
    XtManageChild(popup);
    }


    -----------------------------------------------------------------------------
    Subject: 182) How do popup menus work?
    [Last modified: Feb 98]

    Answer:

    When a popup menu is created as the child of a widget the menu system installs
    a translation on the parent of the popup and descendants with an action which:
    (1) when 3-rd button (the default for the menuPost resource) is pressed the
    cursor changes and the mouse is grabbed for 3 seconds; (2) disables event
    handlers on the descendants and the handlers are never called; (3) an event
    handler installed on the parent works fine.

    It is done so that the correct event handler will (in fact) be called. There
    is a grab with owner_events true. The grab is released by a timer, but
    normally the posted menu shell puts up it's own grab.

    If you only have widgets then you can use the subwindow field in the event to
    identify the original widget. If you have gadgets or other data that you want
    to change the menu for (or use a specific menu for) then you must do a walk of
    the parent's children to find the best match.

    One thing to beware of is that even with the grab, because the menu system
    does a grab with owner events true, you must either have an event handler, or
    nothing that will use the event on each widget in the hierarchy of the menu's
    parent. If a child widget has another event handler for button down, it may
    swallow the event and do something else.

    -----------------------------------------------------------------------------
    Subject: 183) How can I disable the button 3 grab if I am not using popup
    menus?
    [Last modified: Nov 98]

    Answer: The menu system initiates the 3 second grab if XmNpopupEnabled is true
    (the default), whether or not you will actually be popping up a menu. You can
    avoid this grab by setting XmNpopupEnabled to False for widgets that do no
    have popup menus.

    -----------------------------------------------------------------------------
    Subject: 184) Should I use translation tables or actions for popup menus?
    [Last modified: August 92]

    Answer: The original goal of popupMenus was that the user would not have to
    specify an event handler to manage popupMenus; however, that did not become
    reality. Larry Rogers wrote:

    > There appear to be two ways to manage popup menus. I
    > am curious what the correct way would be:


    1. Change the translation table of the widget with the
    popup child to popup the menu. Note that this does
    not currently working for many widgets, because aug-
    menting their translations, even for augment breaks
    the widget.

    2. Add an event handler at creation to the widget; then
    determine if the event that caused the event handler
    to be called is the current button being used by the
    menu as its activation button.

    Susan Murdock Thompson (from OSF) replied: *Theoretically, you should be able
    to do both.* Our documentation says use event handlers. Our tests for the
    toolkit use event handlers and for UIL use translations. (Although I tried an
    event handler with a UIL test and it works).

    -----------------------------------------------------------------------------
    Subject: 185) What are the known bugs in popup menus?
    [Last modified: August 92]

    Answer: As at Motif 1.1.4, the bugs for which an OSF PIR exists are:

    (3) Menus not being sticky (ie: posted on a Btn CLICK) [ Note:this problem
    occurs with OptionMenus as well] (PIR 3435)

    (6) Destroying a widget with an associated popupMenu results in "Warning:
    Attempt to remove non-existant passive grab" (PIR 2972)

    (7) Current documentation insufficient regarding requirements for success in
    using PopupMenus. (PIR 3433)


    -----------------------------------------------------------------------------
    Subject: 186) Can I have multiple popup menus on the same widget?
    [Last modified: July 96]

    Answer: Ken Lee wrote that with Motif 1.2.*, you can have multiple popup menus
    on a single widget as long as you set the menu's XmNmenuPost correctly.

    The older answer for Motif 1.1.* was: If you want to have several popups
    (activated by different mouse buttons) on the same widget..., well, that
    doesn't work yet.

    If you want to have several popups on different children... that works. But
    don't put a popup on the parent (manager) widget, or it will rule!

    -----------------------------------------------------------------------------
    Subject: 187) How can I change the shell title of a tear-off menu?
    [Last modified: Dec 97]

    Answer: There is menu title resource to set this in Motif 2.0. In Motif 1.*,
    explicitly set XmNtitle and XmNtitleEncoding on the menu shell, possibly in
    your XmNtearOffMenuActivateCallback.

    Note: The shell that is about to be mapped is the parent of the widget passed
    to the XmNtearOffMenuActivateCallback.

    Thanks to Ken Lee (http://www.rahul.net/kenton/), Fernando D. Mato Mira
    (matomira@lig.di.epfl.ch), and Michael O'Keefe
    (Michael.OKeefe@LMC.Ericsson.SE)

    -----------------------------------------------------------------------------
    Subject: 188) Can I programmatically tear-off a menu?
    [Last modified: Dec 97]

    Answer: As far as I know, there is no supported (or easy and unsupported) way
    to do this.

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 189) What widgets are valid within Motif menus?
    [Last modified: July 96]

    Answer: In Motif 1.*, menus may contain labels, push buttons, cascade buttons,
    toggle buttons, and separators (widgets or gadgets). RowColumn will complain
    if you use anything else within a menu. Note that drawn buttons and arrow
    buttons are not allowed.

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 190) Can I create multi-column popup or pulldown menus?
    [Last modified: Nov 96]

    Answer: Yes. Menu panes are just XmRowColumn widgets. Set XmNpacking to
    XmPACK_COLUMN and XmNnumColumns to the number of columns you want.

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 191) How can I keep my program from hanging if a user activates a
    popup that is a child of an insensitive push button?
    [Last modified: Nov 96]

    Answer: There are two workarounds for this problem. You need only use one.

    1. Set XmNancestorSensitive to False on the XmMenuShell when its parent is
    insensitive.

    2. Set XmNpopupEnabled on the menu pane (XmRowColumn widget) to False when
    the menu is insensitive.

    Reset the resource to True if you make your button sensitive again.

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 192) TOPIC: DRAG AND DROP

    -----------------------------------------------------------------------------
    Subject: 193) Where can I find info and examples of the Motif drag and drop
    protocol?
    [Last modified: Jul 97]

    Answer: A technical specification is available over the Internet:

    OSF/Motif Drag and Drop Protocol
    ftp://ftp.red-bean.com/pub/teak/

    Thanks to Elliot Lee, sopwith@redhat.com

    OSF's "Motif Programmers Guide" includes complete source code for several drag
    and drop demos. Chapter 15 has simple examples demonstrating the basic
    behaviour. Appendix B has a more complex example. (The source code for some
    of the demos also appears on the OSF tape.)

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 194) How can I disable Drag and Drop in my Motif 1.2 client ?
    [Last modified: Oct 94]

    Answer: Several people have reported that for complex hierarchies of widgets,
    drag and drop can slow down an application considerably. If you do not need
    drag and drop's significant power, you can disable it in your application.

    Set the XmDisplay drag-protocol resources to XmDRAG_NONE. The following code
    fragment demonstrates this:

    #include


    dw = XmGetXmDisplay(XtDisplay(shell)); /* where "shell" is your client's top-
    level shell. */

    XtVaSetValues(dw, XmNdragInitiatorProtocolStyle, XmDRAG_NONE, NULL);
    XtVaSetValues(dw, XmNdragReceiverProtocolStyle, XmDRAG_NONE, NULL);


    Thanks to Lance Purple (purple@austin.ibm.com)

    Ken Lee and Christoph Widmer (widmer@einsteinium.SLCS.SLB.COM) describe how to
    disable drag and drop from a resource file:

    *dragInitiatorProtocolStyle: XmDRAG_NONE
    *dragReceiverProtocolStyle: XmDRAG_NONE

    Ken Lee also notes that as of Motif 1.2, the "Xm" prefix is required for all
    token constants in resource files. (Which is why specifying "DRAG_NONE" won't
    work but "XmDRAG_NONE" will.)

    -----------------------------------------------------------------------------
    Subject: 195) Can I register client data for the Motif XmDropSite drop
    callback?
    [Last modified: Mar 96]

    Answer: Apparently not. You can, however, put your data in the drop site
    widget's XmNuserData. Or, you can use the Xlib context manager.

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 196) Can unmanged widgets be valid (drag-and-drop) drop sites?
    [Last modified: Nov 96]

    Answer: Yes, the drop site stacking order is independent of the window
    stacking order. You can modify the active drop site order with
    XmDropSiteConfigureStackingOrder() or by using XmDropSiteUpdate() to change
    the drop site's XmNdropSiteActivity resource (to XmDROP_SITE_ACTIVE or
    XmDROP_SITE_INACTIVE).

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 197) TOPIC: INPUT FOCUS

    -----------------------------------------------------------------------------
    Subject: 198) How can I specify the widget that should have the keyboard
    focus when my application starts up?
    [Last modified: June 95]

    Answer: In Motif 1.2 or later, use XmNinitialFocus on the manager widget.

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 199) How can I specify my own keyboard traversal order?
    [Last modified: May 97]

    Answer: In Motif 1.2 or later, set the XmNnavigationType resource for the
    widgets in your tab group. When any widget in a hierarchy has an
    XmNnavigationType of XmEXCLUSIVE_TAB_GROUP, traversal of tab groups in the
    hierarchy proceeds to widgets in the order in which their XmNnavigationType
    resources were specified as XmEXCLUSIVE_TAB_GROUP or XmSTICKY_TAB_GROUP.

    Earlier releases have a XmAddTabGroup(), but that is obsolete and has been
    replaced by XmNnavigationType.

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 200) How can I determine which widget has keyboard focus?
    [Last modified: Sept 95]

    Answer: In Motif 1.2 or later, use XmGetFocusWidget().

    Ken Lee

    --------------------------------------------------------------------------
    Subject: 201) How can I direct the keyboard input to a particular widget?

    Answer: In Motif 1.1 call XmProcessTraversal(target, XmTRAVERSE_CURRENT). The
    widget (and all of its ancestors) does need to be realized BEFORE you call
    this. Otherwise it has no effect. XmProcessTraversal is reported to have many
    bugs, so it may not work right. A common occurrence is that it doesn't move
    to the widget, but if you call XmProcessTraversal *twice* in a row, it will.
    If you can't get it to work, try this from Kee Hinckley:

    // This insane sequence is as follows:
    // On manage set up a focus callback
    // On focus callback set up a timer (and get rid of focus callback!)
    // On timer set the focus (which only works if the parent
    // has the focus,
    // which is why we went through all of this garbage)
    // There may be a better way, but I haven't time to try it now.
    //
    static void focusTO(void *data, XtIntervalId *) {
    XmProcessTraversal((Widget) data, XmTRAVERSE_CURRENT);
    }

    static void focusCB(Widget w, XtPointer data, XtPointer) {
    XtRemoveCallback(w, XmNfocusCallback, focusCB, data);
    XtAppAddTimeOut(XtWidgetToApplicationContext(w), 0, focusTO, data);
    }

    void OmXSetFocus(Widget parent, Widget w) {
    XtAddCallback(parent, XmNfocusCallback, focusCB, w);
    }


    In Motif 1.0 call the undocumented _XmGrabTheFocus(target).

    Do not use the X or Xt calls such as XtSetKeyboardFocus since this bypasses
    the Motif traversal layer and can cause it to get confused. This can lead to
    odd keyboard behaviour elsewhere in your application.

    -----------------------------------------------------------------------------
    Subject: 202) How can I have a modal dialog which has to be answered before
    the application can continue?
    [Last modified: Sep 97]

    Answer: Warning: the following answer relies on nested event loops. Use these
    with caution, as nested loops can affect the ordering of events and widget
    destruction, leading to several undesirable side effects.

    Ken Lee


    Note: J.-N. Meurisse (uunet!rc4.vub.ac.be!jnmeuris) sent a correction to the
    following code fragment. Change:

    XtAddCallback(dialog, XmNpopdownCallback, ...)
    to
    XtAddCallback(XtParent(dialog), XmNpopdownCallback, ...)

    The answer depends on whether you are using the Motif window manager mwm or
    not. Test for this by XmIsMotifWMRunning.

    The window manager mwm knows how to control event passing to dialog widgets
    declared as modal. If the dialog is set to application modal, then no
    interaction with the rest of the application can occur until the dialog is
    destroyed or unmanaged.

    Use the appropriate code in the following program. There is followup
    discussion after the program.


    /* 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.
    */

    /*
    * ask_user.c -- create a pushbutton that posts a dialog box
    * that asks the user a question that requires an immediate
    * response. The function that asks the question actually
    * posts the dialog that displays the question, waits for and
    * returns the result.
    */
    #include
    #include
    #include
    #include
    #include
    #include
    #include

    XtAppContext app;

    #define YES 1
    #define NO 2

    /* main() --create a pushbutton whose callback pops up a dialog box */
    main(argc, argv)
    char *argv[];
    int argc;
    {
    Widget parent, button, toplevel;
    XmString label;
    void pushed();

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

    label = XmStringCreateLocalized("/bin/rm *");
    button = XtVaCreateManagedWidget("button",
    xmPushButtonWidgetClass, toplevel,
    XmNlabelString, label,
    NULL);
    XtAddCallback(button, XmNactivateCallback,
    pushed, "Remove Everything?");
    XmStringFree(label);

    XtRealizeWidget(toplevel);
    XtAppMainLoop(app);
    }

    /* pushed() --the callback routine for the main app's pushbutton. */
    void
    pushed(w, question)
    Widget w;
    char *question;
    {
    if (AskUser(w, question) == YES)
    puts("Yes");
    else
    puts("No");
    }

    /*
    * AskUser() -- a generalized routine that asks the user a question
    * and returns the response.
    */
    AskUser(parent, question)
    char *question;
    {
    static Widget dialog;
    XmString text, yes, no;
    static int answer;
    extern void response();

    answer = 0;
    if (!dialog) {
    dialog = XmCreateQuestionDialog(parent, "dialog", NULL, 0);
    yes = XmStringCreateLocalized("Yes");
    no = XmStringCreateLocalized("No");
    XtVaSetValues(dialog,
    XmNdialogStyle, XmDIALOG_APPLICATION_MODAL,
    XmNokLabelString, yes,
    XmNcancelLabelString, no,
    NULL);
    XtSetSensitive(
    XmMessageBoxGetChild(dialog, XmDIALOG_HELP_BUTTON), False);
    XtAddCallback(dialog, XmNokCallback, response, &answer);
    XtAddCallback(dialog, XmNcancelCallback, response, &answer);
    /* if the user interacts via the system menu: */
    /* SEE CORRECTION ABOVE */
    XtAddCallback(dialog, XmNpopdownCallback, response, &answer);
    }
    text = XmStringCreateLocalized(question);
    XtVaSetValues(dialog,
    XmNmessageString, text,
    NULL);
    XmStringFree(text);
    XtManageChild(dialog);
    XtPopup(XtParent(dialog), XtGrabNone);

    /* while the user hasn't provided an answer, simulate XtMainLoop.
    * The answer changes as soon as the user selects one of the
    * buttons and the callback routine changes its value. Don't
    * break loop until XtPending() also returns False to assure
    * widget destruction.
    */
    while (answer == 0 || XtAppPending(app))
    XtAppProcessEvent(app, XtIMAll);
    return answer;
    }

    /* response() --The user made some sort of response to the
    * question posed in AskUser(). Set the answer (client_data)
    * accordingly and destroy the dialog.
    */
    void
    response(w, answer, reason)
    Widget w;
    int *answer;
    XmAnyCallbackStruct *reason;
    {
    switch (reason->reason) {
    case XmCR_OK:
    *answer = YES;
    break;
    case XmCR_CANCEL:
    *answer = NO;
    break;
    default:
    *answer = NO;
    return;
    }
    }


    If you aren't running a window manager that acknowledges this hint, then you
    may have to grab the pointer (and keyboard) yourself to make sure the user
    doesn't interact with any other widget. Change the grab flag in XtPopup to
    XtGrabExclusive, and XtRemoveGrab(XtParent(w)) to the response() function.

    -----------------------------------------------------------------------------
    Subject: 203) TOPIC: MEMORY AND SPEED

    -----------------------------------------------------------------------------
    Subject: 204) When can I free data structures passed to or retrieved from
    Motif?

    Answer: In most cases, especially for XmStrings and XmFontLists, Motif copies
    data passed to it or retrieved from it, so it may be freed immediately.
    Server-side resources, such as pixmaps and color cells, however, are not
    copied, so should not be freed. More recent versions of Motif are better than
    earlier versions and exceptions should be documented.

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 205) What memory leaks are known? Why does my application grow in
    size?
    [Last modified: Jun 98]

    Answer: Detailed information about Motif-related memory leaks (and how you can
    avoid them) can be found in two great articles by Kenton Lee:

    http://www.rahul.net/kenton/txa/feb96.html
    http://www.rahul.net/kenton/txa/mar96.html

    Answer: Motif 1.0 has many memory leaks, particularly in XmString
    manipulation. Switch to Motif 1.1. 1.2, or 2.0.

    Answer: In Motif 1.2.x, if one is using XmStringGetNextSegment very often
    (several 100 times) you'll get very big memory leaks, because one has to
    XtFree() also the charset variable and not only the variable holding the text
    value. Thanks to Ingo Schulz (ing@bb-data.de).

    Answer: The Intrinsics have a memory leak in accelerator table management, and
    Motif uses this heavily. Avoid this by mapping/unmapping widgets rather than
    creating/destroying them, or get X11R4 fix-15/16/17.

    Answer: The server may grow in size due to its own memory leaks. Switch to a
    later server.

    Answer: You are responsible for garbage collection in `C'. Some common cases
    where a piece of memory becomes garbage are

    a. Memory is allocated by Motif for XmStrings by the functions
    XmStringConcat, XmStringCopy, XmStringCreate, XmStringCreateLtoR,
    XmStringCreateLocalized, XmStringDirectionCreate, XmStringNConcat,
    XmStringNCopy, XmStringSegmentCreate, and XmStringSeparatorCreate. The
    values returned by these functions should be freed using XmStringFree
    when they are no longer needed.

    b. Memory is allocated by Motif for ordinary character strings (of type
    String) by Motif in XmStringGetLtoR, XmStringGetNextComponent, and
    XmStringGetNextSegment. After using the string, XtFree() it. [Note that
    XmStrings and Strings are two different data types. XmStrings are
    XmStringFree'd, Strings are XtFree'd.]

    c. If you have set the label (an XmString) in a label, pushbutton, etc
    widget, free it after calling XtSetValues() or the widget creation
    routine by XmStringFree().

    d. If you have set text in a text widget, the text widget makes its own
    copy. Unless you have a use for it, there is no need to keep your own
    copy.

    e. If you have set the strings in a list widget the list widget makes its
    own copy. Unless you have a use for it, there is no need to keep your
    own copy.

    f. When you get the value of a single compound string from a Widget e.g.
    XmNlabelString, XmNmessageString, ... Motif gives you a copy of its
    internal value. You should XmStringFree this when you have finished with
    it.

    g. On the other hand, when you get a value of a Table e.g. XmStringTable for
    a List, you get a *pointer* to the internal Table, and should not free
    it.

    h. When you get the value of the text in a widget by XmTextGetString or from
    the resource XmNvalue, you get a copy of the text. You should XtFree
    this when you have finished with it.

    Answer: Josef Nelissen wrote: at least in Motif 1.1.4, X11R4 on a HP 720, the
    XmText/XmTextFieldSetString() functions have a memory leak. The old
    value/contents of the Widget isn't freed correctly. To work around this bug,
    one should use a XmText Widget (in single-line-mode) instead of a XmTextField
    Widget (the solution fails with XmTextField Widgets !) and replace any

    XmTextSetString(text_widget, str);

    by

    XmTextReplace(text_widget, (XmTextPosition) 0,
    XmTextGetLastPosition(text_widget), str);


    -----------------------------------------------------------------------------
    Subject: 206) Why do I get so many uninitilized memory read (UMR) errors when
    I run Purify[tm] on my Motif programs?
    [Last modified: July 96]

    Answer: Purify's reports are suggestions and do not always indicate real bugs.
    The X libraries frequently allocate dynamic memory, e.g., for attribute or
    event structures, but don't explicitly initialize all of the memory. X keeps
    track of which structure fields are valid via a union type or a mask. When X
    tries to copy or write the memory (part of which is uninitialized) as one
    block, Purify reports a UMR. This is not a bug and you can safely supress or
    ignore the report. Yes, X could initialize the unused field, but since this
    happens alot, the needless operation could negatively affect your performance.

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 207) Why does my application take a long time to start up?

    Answer: You are probably creating too many widgets at startup time. Delay
    creating them until needed. If you have a large number of resources in text
    files (such as in app-defaults), time may be spent reading and parsing it.

    -----------------------------------------------------------------------------
    Subject: 208) My application is running too slowly. How can I speed it up?

    Answer: Use the R4 rather than R3 server. It is much faster.

    Answer: The standard memory allocator is not well tuned to Motif, and can
    degrade performance. Use a better allocator. e.g. with SCO Unix, link with
    libmalloc.a; use the allocator from GNU emacs; use the allocator from Perl.

    Answer: Avoid lots of widget creation and destruction. It fragments memory
    and slows everything down. Popup/popdown, manage/unmanage instead.

    Answer: Set mappedWhenManaged to FALSE, and then call XtMapWidget()
    XtUnmapWidget() rather than managing.

    Answer: Get more memory - your application, the server and the Operating
    System may be spending a lot of time being swapped.

    Answer: If you are doing much XmString work yourself, such as heavy use of
    XmStringCompare, speed may deteriorate due to the large amount of internal
    conversions and malloc'ing. Try using XmStringByteCompare if appropriate or
    ordinary Ascii strings if you can.

    Answer: There are some more hints at http://www.rahul.net/kenton/perf.html

    -----------------------------------------------------------------------------
    Subject: 209) Why is my application so huge?

    Answer: The typical size of a statically linked Motif app is in the megabytes.
    This is often caused by the size of libXm.a. A large part of this gets linked
    in to even trivial Motif programs. You can reduce the code size by linking
    against shared libraries if they are available. Running "strip" on the
    executable can often reduce size. Note that the size of the running program
    should be measured by "ps", not by the code size.

    -----------------------------------------------------------------------------
    Subject: 210) How can I improve performance when creating and deleting
    hundreds of text widgets?
    [Last modified: Feb 98]

    Answer: Ken Lee writes: This is mostly a problem with Motif 1.2.0 through
    1.2.2. Later versions are much better. If you're stuck with an early version
    of Motif 1.2, you may be able to greatly improve performance by batching the
    drop site updates: surround the create or delete code with
    XmDropSiteStartUpdate and XmDropSiteEndUpdate. Alternatively, you can
    completely disable drag-and-drop for your application. See the subject: "How
    can I disable Drag and Drop in my Motif 1.2 client?"

    Mike Youell adds: Using XmDropSiteStartUpdate sped up destruction of widgets
    in Motif 1.2.5. Also it may be worthwhile reminding people that it is not as
    simple as "surround the create or delete code with XmDropSiteStartUpdate and
    XmDropSiteEndUpdate" because it doesn't destroy the widgets when you do a
    XtDestroy. X does it at a later time, hence you still need to be inside the
    drop-site update when these destroys are completed by X.


    -----------------------------------------------------------------------------
    Subject: 211) After I call XtSetValues, when will I see the changes in my
    GUI?
    [Last modified: Nov 97]

    Answer: For each change you make, the widget decides if it needs to redraw.
    If so, Xt calls XtClearArea to generate an expose event. You main loop
    dispatches the resulting expose event to your widget, causing a redisplay.
    Note that the redisplay may be delayed somewhat if you do not immediately
    return to the event loop after calling XtSetValues. You can often work around
    this by calling XmUpdateDisplay().

    Note also that you should try to make all your changes in one large
    XtSetValues changing several values at once. If you call XtSetValues
    individually for each change you need to make, you could generate several
    expose events and redraw several times.

    -----------------------------------------------------------------------------
    Subject: 212) TOPIC: XMSTRING

    -----------------------------------------------------------------------------
    Subject: 213) What string functions differ in Motif 1.1 and 1.2? Is
    XmStringCreateSimple obsolete? What should I use instead?
    [Last modified: Feb 95]

    Answer: XmStringCreateSimple is obsolete. Use XmStringCreateLocalized instead.

    Matthew B. Evans (Evans@EDFUA6.ctis.af.mil) writes:

    We just upgraded from Motif 1.1 to 1.2. When we went to compile, no problem,
    but our XmStringCreateSimple() and XmStringGetLtoR() seemed to have problems.

    As we found out, Motif 1.2 STRONGLY recommends to use the constant
    XmFONTLIST_DEFAULT_TAG instead of XmSTRING_DEFAULT_CHARSET in all of the
    XmStringXXX() functions, as XmSTRING_DEFAULT_CHARSET is maintained only for
    compatibility (not a whole lot in my opinion). I got this information from
    Book 6B from O'Reilly.

    You may want to take a look at this book if you can. Some XmString functions
    are outdated and maintained only for compatibility, whereas some don't
    function correctly when using XmSTRING_DEFAULT_CHARSET (from our in-depth
    tests).

    We have changed all our XmStringCreateSimple() to XmStringCreateLocalized()
    (as suggested in book 6B) and changed all XmSTRING_DEFAULT_CHARSET to
    XmFONTLIST_DEFAULT_TAG.

    [Thanks to John West (jwest@nas.nasa.gov) for fixing a typo in the above.]

    NOTE: All string answers in this FAQ now use XmStringCreateLocalized rather
    than XmStringCreateSimple. The documentaton makes it clear that
    XmStringCreateSimple is obsolete and is only kept for compatibility with Motif
    1.1. New applications should not use this function since XmStringCreateSimple
    may disappear in a subsequent Motif release. (Thanks to Miguel Angel Chamochin
    (mangel@tid.es) for reminding me to fix this mess.)....ksall@cen.com.

    -----------------------------------------------------------------------------
    Subject: 214)* How can I get the ASCII text out of an XmString?
    [Last modified: Feb 02]

    Answer: In Motif 1.x, use XmStringGetLtoR:

    char *str;
    XmString xmstr;
    XmStringGetLtoR(xmstr, XmSTRING_DEFAULT_CHARSET, &str);


    In Motif 2.x, use XmStringUnparse:

    str = XmStringUnparse(xmstr, NULL, 0, XmCHARSET_TEXT, NULL, 0, NULL);


    In both cases, you should free the string to avoid a memory leak:

    XtFree(str);


    -----------------------------------------------------------------------------
    Subject: 215) When can XmStrings used as resources be freed?

    Answer: The policy OSF have been trying to enforce is that if you set an
    XmString or XmStringTable resource, the application is responsible for freeing
    the XmStrings used because the widget makes a copy. If you get an XmString
    resource, then the application must free the value gotten. If you get an
    XmStringTable, then the application should NOT free the value gotten. If the
    application wants to manipulate it, it should make a copy first. This policy
    appears to be implemented progressively, so may be less true for Motif 1.0
    than 1.1.

    -----------------------------------------------------------------------------
    Subject: 216) Why doesn't XmStringGetNextSegment() work properly?

    Answer: The documentation in Motif 1.0 is in error. Instead of

    XmStringGetnextSegment(context, ...)
    XmStringContext * context;

    it should be

    XmStringGetnextSegment(context, ...)
    XmStringContext context;

    i.e. with no indirection.


    -----------------------------------------------------------------------------
    Subject: 217) Why does using XmStringDraw cause a BadFont error?
    [Last modified: Mar 96]

    Answer: Thomas Berlage (berlage@gmdzi.gmd.de) wrote: You could call this a bug
    in Motif. You pass a GC to XmStringDraw, however, Motif wants to use the fonts
    from the font list to draw the string. Therefore it replaces the font of the
    GC temporarily with some fonts of its own as specified in the font list. In
    the end it tries to restore the old font of the GC. There comes the problem:

    If a GC uses the default font, the client side GC structure does not have a
    valid font id (that is the 0xffffffff you may see in the error message). Motif
    tries to restore this invalid id at the end.

    The workaround is: Before drawing with XmStringDraw, set the font id of the GC
    to any valid font id, for example using

    XSetFont (display, gc, XLoadFont (display, "fixed"));

    Another solution is available from "Harry's Motif Programming Corner", Harald
    Albrecht, albrecht@igpm.rwth-aachen.de, who writes:

    "It's somewhat longer but doesn't rely on a font named "fixed" installed on
    your platform. Instead it takes a fontlist and then uses the first font listed
    there. You'll find this source together with a short demo program (which
    creates a DrawingArea and then paints some text in it) on: ftp.igpm.rwth-
    aachen.de (134.130.161.30) in: /arc/pub/unix/motif/RenderXmString.tar.gz

    There's also a html page available: Harry's Motif Programming Corner
    http://www.igpm.rwth-aachen.de/~albr...tifcorner.html

    Thanks to Harald Albrecht (albrecht@igpm.rwth-aachen.de). URL corrected by
    irca (irca@zip.cra.enel.it).

    -----------------------------------------------------------------------------
    Subject: 218) How can I control color of individual strings to show status,
    etc.?
    [Last modified: June 95]

    Answer: This is difficult to do with Motif 1.X. If you can, upgrade to Motif
    2.0, which supports colored XmStrings.

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 219) TOPIC: DIALOGS

    -----------------------------------------------------------------------------
    Subject: 220) How do I stop my dialog disappearing when I press the help
    button?

    Answer: Bulletin board has the resource autoUnmanage which defaults to True.
    This unmanages the widget when any button child is activated - including the
    help button. Set this to False to stop it disappearing. Note that you then
    have to unmanage the bulletin board yourself when any other button is
    activated.

    -----------------------------------------------------------------------------
    Subject: 221) How do I make my own dialog? I want a dialog with my own set
    of buttons that stretch and shrink like the ones in e.g. PromptDialog and its
    own contents.

    Answer: Start off with say a PromptDialog. Unmanage the buttons you don't want
    or manage the Apply button if you want another. Unmanage the other bits of the
    selection box you don't want. You can add another WorkArea child to the
    selection box for any extra stuff you want.


    /* Copyright 1990, Kee Hinckley and Brian Holt Hawthorne */
    /* Permission granted for any use, provided this copyright */
    /* notice is maintained. */

    /* Create a dialog box */
    argcount = setArgs(&args, XmNautoUnmanage, False, NULL);
    SomeDialog = XmCreatePromptDialog(mainShell, "someDialog", args, argcount);

    /* Now get rid of the things we don't want */
    child = XmSelectionBoxGetChild(SomeDialog, XmDIALOG_SELECTION_LABEL);
    XtUnmanageChild(child);
    child = XmSelectionBoxGetChild(SomeDialog, XmDIALOG_TEXT);
    XtUnmanageChild(child);

    /* set the callbacks, and make sure the buttons we want are there */
    child = XmSelectionBoxGetChild(SomeDialog, XmDIALOG_OK_BUTTON);
    XtAddCallback(child, XmNactivateCallback, callSomeFunc, someArg);
    XtAddCallback(child, XmNactivateCallback, unManage, SomeDialog);
    XtManageChild(child);
    child = XmSelectionBoxGetChild(SomeDialog, XmDIALOG_APPLY_BUTTON);
    XtAddCallback(child, XmNactivateCallback, callSomeFunc, someOtherArg);
    XtManageChild(child);
    child = XmSelectionBoxGetChild(SomeDialog, XmDIALOG_CANCEL_BUTTON);
    XtAddCallback(child, XmNactivateCallback, dialogUnmanage, SomeDialog);
    XtManageChild(child);

    /* Add a new work area. This can be any manager. */
    child = XmCreateForm(SomeDialog, "someForm", NULL, 0);
    XtManageChild(child);

    /* and fill it up... */
    something = doYourStuff(child);

    another Answer:

    I had a some people asking about my xmSmartMessageBoxWidget

    It's public domain, and needs Motif-1.2 and is available at
    ftp.x.org:/contrib/widget/SmartMB.tar.Z.

    The basic idea behind it is that it allows the programmer to specify the
    management of child widgets in 4 areas: Label, Control, Separator and Action.
    You can have up to 1 Label, 1 Control, 1 Separator and as many Action children
    as you want. It does not REQUIRE any of these, and there is no unmanaging of
    extra widgets, as the programmer creates what is needed.

    Thanks for the smart dialog info to: John L. Cwikla Wolfram Research, Inc.
    cwikla@wri.com

    -----------------------------------------------------------------------------
    Subject: 222) Why do dialog title bars have "_popup" or "<-popup"
    concatenated onto the widget name?


    Answer: Motif 1.0.3 (?) "fixed" things such that title bars without an
    explicit dialogTitle setting use the widget name with "_popup" or whatever
    added on. Set the dialogTitle resource explicitly if you don't want this new
    default naming scheme.

    -----------------------------------------------------------------------------
    Subject: 223) How can I force a dialog window to display?

    I manage a "working" dialog, and do some computing, but the dialog window
    appears blank until the work has finished. How can I force it to be
    displayed?
    [Last modified: Dec '94]

    Answer: David Brooks writes: The dialog window won't get
    expose events until the window manager has fielded the map request, done the
    reparenting with all that entails, and finally convinced the server that the
    window is for real. The safe way of doing it is [below].

    Use this. (David Brooks, Systems Engineering, Open Software Foundation)

    /*
    * This procedure will ensure that, if a dialog window is being mapped,
    * its contents become visible before returning. It is intended to be
    * used just before a bout of computing that doesn't service the display.
    * You should still call XmUpdateDisplay() at intervals during this
    * computing if possible.
    *
    * The monitoring of window states is necessary because attempts to map
    * the dialog are redirected to the window manager (if there is one) and
    * this introduces a significant delay before the window is actually mapped
    * and exposed. This code works under mwm, twm, uwm, and no-wm. It
    * doesn't work (but doesn't hang) with olwm if the mainwindow is iconified.
    *
    * The argument to ForceDialog is any widget in the dialog (often it
    * will be the BulletinBoard child of a DialogShell).
    */

    ForceDialog(w)
    Widget w;
    {
    Widget diashell, topshell;
    Window diawindow, topwindow;
    Display *dpy;
    XWindowAttributes xwa;
    XEvent event;
    XtAppContext cxt;

    /* Locate the shell we are interested in. In a particular instance, you
    * may know these shells already.
    */

    for (diashell = w;
    !XtIsShell(diashell);
    diashell = XtParent(diashell))
    ;

    /* Locate its primary window's shell (which may be the same) */

    for (topshell = diashell;
    !XtIsTopLevelShell(topshell);
    topshell = XtParent(topshell))
    ;

    if (XtIsRealized(diashell) && XtIsRealized(topshell)) {
    dpy = XtDisplay(topshell);
    diawindow = XtWindow(diashell);
    topwindow = XtWindow(topshell);
    cxt = XtWidgetToApplicationContext(diashell);

    /* Wait for the dialog to be mapped. It's guaranteed to become so unless... */

    while (XGetWindowAttributes(dpy, diawindow, &xwa),
    xwa.map_state != IsViewable) {

    /* ...if the primary is (or becomes) unviewable or unmapped, it's
    probably iconified, and nothing will happen. */

    if (XGetWindowAttributes(dpy, topwindow, &xwa),
    xwa.map_state != IsViewable)
    break;

    /* At this stage, we are guaranteed there will be an event of some kind.
    Beware; we are presumably in a callback, so this can recurse. */

    XtAppNextEvent(cxt, &event);
    XtDispatchEvent(&event);
    }
    }

    /* The next XSync() will get an expose event if the dialog was unmapped. */

    XmUpdateDisplay(topshell);
    }


    -----------------------------------------------------------------------------
    Subject: 224) How can I control placement of a popup widget? Each time a
    popup is created, it is placed in or over the middle of its parent. How can I
    make it obey the XmNx and XmNy values?
    [Last modified: Feb 95]

    Answer: Set the resource XmNdefaultPosition for the popup to False. Set the
    position of the popup by the resource values of XmNx and XmNy. Do not use
    XtMoveWidget, as this is for widget writers only. Here's a demo program from
    Dan Heller:

    /* 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.
    */

    /* map_dlg.c -- Use the XmNmapCallback to automatically position
    * a dialog on the screen. Each time the dialog is displayed, it
    * is mapped down and to the right by 200 pixels in each direction.
    */
    #include
    #include

    /* main() --create a pushbutton whose callback pops up a dialog box */
    main(argc, argv)
    char *argv[];
    {
    Widget toplevel, button;
    XtAppContext app;
    void pushed();

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

    button = XtCreateManagedWidget("button", xmPushButtonWidgetClass,
    toplevel, NULL, 0);
    XtAddCallback(button, XmNactivateCallback, pushed, "Hello World");

    XtRealizeWidget(toplevel);
    XtAppMainLoop(app);
    }

    /* callback function for XmNmapCallback. Position dialog in 200 pixel
    * "steps". When the edge of the screen is hit, start over.
    */
    static void
    map_dialog(dialog, client_data, cbs)
    Widget dialog;
    XtPointer client_data;
    XmAnyCallbackStruct *cbs;
    {
    static Position x, y;
    Dimension w, h;

    XtVaGetValues(dialog, XmNwidth, &w, XmNheight, &h, NULL);
    if ((x + w) >= WidthOfScreen(XtScreen(dialog)))
    x = 0;
    if ((y + h) >= HeightOfScreen(XtScreen(dialog)))
    y = 0;
    XtVaSetValues(dialog, XmNx, x, XmNy, y, NULL);
    x += 200, y += 200;
    }

    /* pushed() --the callback routine for the main app's pushbutton.
    * Create and popup a dialog box that has callback functions for
    * the Ok, Cancel and Help buttons.
    */
    void
    pushed(w, message)
    Widget w;
    char *message; /* The client_data parameter passed by XtAddCallback */
    {
    Widget dialog;
    Arg arg[3];
    XmString t = XmStringCreateLocalized(message);
    extern void response();

    XtSetArg(arg[0], XmNautoUnmanage, False);
    XtSetArg(arg[1], XmNmessageString, t);
    XtSetArg(arg[2], XmNdefaultPosition, False);
    dialog = XmCreateMessageDialog(w, "notice", arg, 3);
    XmStringFree(t);

    XtAddCallback(dialog, XmNmapCallback, map_dialog, NULL);

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


    -----------------------------------------------------------------------------
    Subject: 225) How can I set the dialog's default button?
    [Last modified: June 95]

    Answer: Use XmNdefaultButton on the bulletin board widget.

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 226) How can I create a dialog that behaves like, but looks a little
    different from, XmMessageBox?
    [Last modified: June 95]

    Answer: Motif 1.2 provides a XmCreateTemplateDialog(), which allows you to
    specify any combination of child widgets.

    Ken Lee

    -----------------------------------------------------------------------------
    Subject: 227) How can I use Motif's message dialog bitmaps in my own dialogs?
    [Last modified: Nov 95]

    Answer: The bitmaps are normally stored in /usr/include/X11/bitmaps (or the
    equivalent bitmaps directory, which is vendor specific) and are cached if you
    create a XmMessageBox. You can retrieve them by name with XmGetPixmap() or
    XmGetPixmapByDepth(). The names of the bitmap files are in the XmMessageBox
    man page.

    Ken Lee

    -----------------------------------------------------------------------------
    END OF PART SIX

  8. 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