Motif FAQ (Part 1 of 9) - Motif

This is a discussion on Motif FAQ (Part 1 of 9) - Motif ; Archive-name: motif-faq/part1 Last-modified: 1 FEB 2002 Posting-Frequency: irregular Organization: Kenton Lee, X/Motif Consultant, http://www.rahul.net/kenton/ URL: http://www.rahul.net/kenton/mfaq.html Version: 8.1 Subject: Motif FAQ (all parts) Newsgroups: comp.windows.x.motif,comp.answers,news.answers Reply-To: kenton@rahul.net (Ken Lee) Summary: Motif Frequently Asked Questions (with answers). Posting-Freq.: irregular (re-posted monthly ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Motif FAQ (Part 1 of 9)

  1. Motif FAQ (Part 1 of 9)

    Archive-name: motif-faq/part1
    Last-modified: 1 FEB 2002
    Posting-Frequency: irregular
    Organization: Kenton Lee, X/Motif Consultant, http://www.rahul.net/kenton/
    URL: http://www.rahul.net/kenton/mfaq.html
    Version: 8.1



    Subject: Motif FAQ (all parts)
    Newsgroups: comp.windows.x.motif,comp.answers,news.answers
    Reply-To: kenton@rahul.net (Ken Lee)
    Summary: Motif Frequently Asked Questions (with answers).
    Posting-Freq.: irregular (re-posted monthly to comp.windows.x.motif)
    Organization: Kenton Lee, X/Motif Consultant, http://www.rahul.net/kenton/
    URL: http://www.rahul.net/kenton/mfaq.html

    Motif FAQ

    [Last changed: 1 FEB 2002]

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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


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

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

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

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

    For more information on Open Motif, see:

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

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

    Some other web sites dedicated to Open Motif are:

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


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

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

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

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

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

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

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

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


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

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

    Ken Flowers, k.flowers@opengroup.org

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

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

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

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

    news:comp.windows.x.motif

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

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


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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

    and register the following ftp URL:

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

    This free service is brought to you by Netmind at:

    http://www.netmind.com/


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

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

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

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

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

    Ken Lee

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

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

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

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

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

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

    http://www.opengroup.org/


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

    Answer: The Open Group web page:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    To find the version of a compiled Motif library:

    grep XmVERSION_STRING libXm.a

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

    xmUseVersion

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

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

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


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

    Answer:

    New widgets

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

    New features

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

    Extensibility

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

    Desktop

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

    Performance & Quality

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Listing of the OSF/MotifR 2.0 Features and Benefits

    I. MORE EFFICIENT APPLICATION DEVELOPMENT

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

    Benefit Allows easier extensions to Motif for custom user


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

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

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

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

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

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

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

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

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

    Updates to documentation: Programmer's Guide, Reference

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

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

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

    Feature:
    Allows easy migration of applications to Motif 2.0

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

    Feature
    Makes applications easier to troubleshoot & maintain

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

    EASE OF USE

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

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

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

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

    Feature:
    Allows easier integration with the desktop

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

    Feature:
    Allows more natural organization of users' work

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

    EASE OF ENTERPRISE COMPUTING

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

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

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

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

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

    Feature:
    Ease of integrating Motif and PC environments

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


    WORLD-WIDE ACCEPTANCE

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

    Feature
    Applicable to a wider range of computer users

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

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

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

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

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

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

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

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

    The major differences from Motif 2.0 are:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  2. Motif FAQ (Part 2 of 9)

    Archive-name: motif-faq/part2
    Last-modified: 1 FEB 2002
    Posting-Frequency: irregular
    Organization: Kenton Lee, X/Motif Consultant, http://www.rahul.net/kenton/
    URL: http://www.rahul.net/kenton/mfaq.html
    Version: 8.1



    -----------------------------------------------------------------------------
    Subject: 20) Where can I find Motif 2.1 documentation?
    [Last modified: Mar 98]

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

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

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

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

    The O'Reilly Motif tutorial books are available at:

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

    Here are some Russian translations of the Motif manuals:

    http://motif.hut.ru/

    For other on-line Motif documentation, please see:

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


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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Ken Lee

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

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

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

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

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

    These are the only OSF published lists.

    No one else seems to publish a list.

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

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

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

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

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

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

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

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

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

    Overview
    --------

    Standards are to be defined in these areas:

    - desktop
    - networking
    - objects
    - graphics
    - system management

    CDE Functional Groups:

    High Level:
    - Desktop Management
    - Productivity Tools

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

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

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

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

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

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

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

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

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

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

    Guidelines
    ----------

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


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

    Answer: The CDE FAQ is located at:

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

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

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

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


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

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

    The Open Group Announces Common Desktop Environment 2.1

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


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

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

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

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

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

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

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

    The Open Group

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

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

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

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

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

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


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

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

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

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

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

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

    landers@osf.org
    617-621-7282"


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

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

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

    http://www.opengroup.org/

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


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

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

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

    http://www.opengroup.org/


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

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

    X Consortium to Transfer X Window System to The Open Group

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

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

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

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

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

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

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

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

    The Open Group Continues to Expand Product and Services Portfolio

    Leading Open Systems Consortium
    Absorbs X Window System Technology

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

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


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

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

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

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

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

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

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

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


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


    OSF Announces Formal Launch of CDE/Motif Project

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

  3. Motif FAQ (Part 3 of 9)

    Archive-name: motif-faq/part3
    Last-modified: 1 FEB 2002
    Posting-Frequency: irregular
    Organization: Kenton Lee, X/Motif Consultant, http://www.rahul.net/kenton/
    URL: http://www.rahul.net/kenton/mfaq.html
    Version: 8.1



    -----------------------------------------------------------------------------
    Subject: 40) How does Motif work with X11R5?

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

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

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

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

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

    Answer:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    For (old) documentation, see

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

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


    For information on using Mosaic by remote control, see

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


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

    To the numerous request for the NCSA HTML widget information.

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

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


    Documentation on the HTML widget can be located at:

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

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

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

    where htmlRef() looks like:

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

    where readHTMLFile() is

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

    I think this is enough to start you off.


    Thanks to: Samuel Effah

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

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

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

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

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

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

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

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


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

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

    Jan Borchers writes about his Xmtutor:

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

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


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

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


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

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

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

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

    http://www.motifzone.com/

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

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

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

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

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

    Answer: mwm is a window manager.

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

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

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

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

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

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

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

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

    Mwm*feedback*backgroundPixmap: white

    or

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

    or

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

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

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

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

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

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

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


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

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

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


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

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

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

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

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

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

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

    Mwm*XClock.clientDecoration: none

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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

    not_installed_yet = FALSE;
    }

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

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

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

    win = XtWindow(shell);

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

    winAttrs[0] = AtomWTOther;

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

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

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

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


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

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

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

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


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

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

    mwm.application_name.clientFunctions: -resize -close

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


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

    #include

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


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

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

    Ken Lee

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

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

    Ken Lee

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

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

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

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

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

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

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

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

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

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

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

    This works with R4 Intrinsics

    #include

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

    main()
    {
    Atom wm_delete_window;

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

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

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

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

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

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


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


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

    #include

    #include
    #include

    #include
    #include
    #include

    #include /* for popup */
    #include

    #include
    #include
    #include

    void CloseCB();
    void popup_handler();

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

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

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

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

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

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

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

    XtToolkitInitialize ();
    app_context = XtCreateApplicationContext ();

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    XtRealizeWidget( shell1 );

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

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

    XtAppMainLoop (app_context);
    }


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

  4. Motif FAQ (Part 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 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

+ Reply to Thread