Motif FAQ

[Last changed: 04 APR 94]

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.

		Please redistribute this article!

This FAQ is maintained by Brian Dealy <dealy@kong.gsfc.nasa.gov>.  Send
updates and corrections to me at that mail address.  It would help if
the subject line contained the phrase "FAQ".  I will Be making a
HTML version available in the very near (MAY)? future. It will hopefully 
provide a much fuller set of resources including URLs for examples and 
free software. It will require a bit of reorganizing and rewriting, but 
it should be well worth the wait.

History:
From November 89-July 93 the FAQ was maintained by Jan Newmarch
<jan@ise.canberra.edu.au>

This article includes answers to the following questions. Ones marked with
a + indicate questions new to this issue; those with changes of content since
the last issue are marked by *:


 0)* TOPIC: WHAT ARE OTHER RELEVANT NEWSGROUPS?
 1)  TOPIC: FTP ARCHIVES
 2)  Is the FAQ list available for FTP anywhere?
 3)* Is this FAQ accessible via WWW?
 4)  Is this newsgroup accessible via email?
 5)  Is this newsgroup archived?
 6)  Is the mail list motif-talk archived?
 7)  TOPIC: OSF AND MOTIF
 8)  Because of COSE, is Motif now in the public domain?
 9)* What versions of Motif are there?
10)* Where can I get Motif?
11)  Is there a list of Motif bugs?
12)  Where can I get public domain Motif source?
13)* Are the Motif examples publically available?
14)* Has anyone done a public domain Motif lookalike?
15)  Does anyone from OSF pay attention to our questions/suggestions?
16)  Does OSF have an application compliance validation service?
17)  What is the motif-talk mailing list?
18)  What MIT patches do I use, and when do I use fix-osf?
19)  How does Motif work with X11R5?
20)* How can I find which version of Motif I have?
21)  TOPIC: LITERATURE
22)* What books should I read or do I need to program using Motif?
23)  TOPIC: MWM
24)  What is the difference between Motif and mwm?
25)  Does anyone have an alternative set of  3-D  defaults  for  a  monochrome
screen?
26)  How can I modify the Motif window manager decorations?
27)  How can I turn off the Motif window manager  functions  from  the  system
menu?
28)  How can tell I if the user has selected the "Close" item  on  the  system
menu attached to the top-level shell?
29)  Is there an mwm virtual desktop manager?
30)  Why does mwm 1.2 crash on startup?
31)  TOPIC: MOTIF GENERATORS
32)  What prototyping tools are there to generate Motif code?
33)  TOPIC: TEXT WIDGET
34)  What is the difference between a XmTextField widget and a single
35)  Why does  pressing  <return> in a text widget do nothing?
36)  When I add text to a scrolling text widget how can I get the new text  to
show?
37)  Does the text widget support 16 bit character fonts?
38)  How can I stop the text widget from echoing characters typed?
39)  How can I replace characters typed with say a `*'?
40)  How can I best add a large piece of text to a scrolled text widget?
41)  How can I highlight text in the Text widget?
42)  How can I select all of the text in a widget programmatically?
43)  How can I change colours of text in the Text widget?
44)  How can I change the font of text in the Text widget?
45)  Is there an emacs binding for the text widget?
46)  How can I use a file as the text source for a Text widget?
47)  How can put Text in overstrike mode instead of insert?
48)  How can I make the Delete key do a backspace?
49)  TOPIC: LIST WIDGET
50)  Should I create an XmList widget as a child of automatic  
     XmScrolledWindow or use the XmCreateScrolledList() convenience function?
51)  How do I best put a new set of items into a list?
52)  Can I have strings with different fonts in a list?
53)  Can I get a bitmap to show in a list item like I can in a Label?
54)  Can I have items with different colours in a list?
55)  Can I grey out an item in a list?
56)  Can I have multi-line items in a list?
57)  How can I tell the position of selected items in a list?
58)  TOPIC: FILE SELECTION BOX WIDGET
59)  What is libPW.a and do I need it?
60)  What are these compile errors: Undefined symbol _regcmp and _regex?
61)  What's wrong with the Motif 1.0 File Selection Box?
62)  TOPIC: FORM WIDGET
63)  Why don't labels in a Form resize when the label is changed?
64)  How can I center a widget in a form?
65)  How do I line up two columns of widgets of different types?
66)  TOPIC: PUSHBUTTON WIDGET
67)  Why can't I use accelerators on buttons not in a menu?
68)  TOPIC: LABEL WIDGET
69)  How can I align the text in a label (button, etc) widget?
70)  Why doesn't label alignment work in a RowColumn?
71)  How can I set a multiline label?
72)  How can I have a vertical label?
73)  How can I have a Pixmap in a Label?
74)  TOPIC: DRAWING AREA WIDGET
75)  How can I send an expose event to a Drawing Area widget?
76)  How can I know when a DrawingArea has been resized?
77)  TOPIC: MENUS
78)  What can I put inside a menu bar?
79)  Can I have a cascade button without a submenu in a pulldown menu?
80)  Should I have a cascade button without a submenu in a pulldown menu?
81)  What is the best way to create popup menus?
82)  How do popup menus work?
83)  Should I use translation tables or actions for popup menus?
84)  What are the known bugs in popup menus?
85)  Can I have multiple popup menus on the same widget?
86)  TOPIC: INPUT FOCUS
87)  How can I specify the widget that should have the keyboard focus  when  my
     application starts up?
88)  How can I direct the keyboard input to a particular widget?
89)  How can I have a modal dialog which has to be answered before the  
     application can continue?
90)  TOPIC: MEMORY AND SPEED
91)  When can I free data structures passed to or retrieved from Motif?
92)  Why does my application grow in size?
93)  Why does my application take a long time to start up?
94)  My application is running too slowly. How can I speed it up?
95)  Why is my application so huge?
96)  TOPIC: XMSTRING
97)  How can I get the Ascii text out of an XmString?
98)  When can XmStrings used as resources be freed?
99)  Why doesn't XmStringGetNextSegment() work properly?
100)  Why does using XmStringDraw cause a Bad Font error?
101)  TOPIC: DIALOGS
102)  How do I stop my dialog disappearing when I press the help button?
103)  How do I make my own dialog?
104)  How come the title bars for my dialogs now have  "_popup"  or  
      "<-popup" concatenated onto the widget name?
105)  How can I force a dialog window to display?
106)  How can I control placement of a popup widget?
107)  TOPIC: LANGUAGE BINDINGS
108)* Is there a C++ binding for Motif?
109)  How can I have a C++ member function in a callback?
110)  Is there a Common Lisp binding for Motif?
111)* Is there an Ada binding for Motif?
112)  Is there a Poplog binding for Motif?
113)  TOPIC: SPECIFIC PLATFORMS
114)  Is it easy to build Motif for a Sun?
115)  How do I build Motif 1.2.2 on Solaris 2.1 with Sun C?
116)  What compile errors/warnings might I get in both Sun 3 and Sun 4?
117)  On a Sun 3, what are the mwm startup error messages about?
118)  Are there problems making shared libraries on a Sun?
119)  The OpenWindows server hangs when I popup a menu with Button 3.
120)  Has anyone made shared libraries on an IBM RS/6000?
121)  What is the error  "Unaligned access in XmString" under Ultrix?
122)  TOPIC: KEYSYMS
123)  What is causing the messages "unknown keysym osfDown..."?
124)  What happens if I can't install Motif Keysyms?
125)  Why has OSF introduced Keysyms into Motif 1.1?
126)  TOPIC: ICONS
127)  How can I keep track of changes to iconic/normal window state?
128)  How can I check if my application has come up iconic?
129)  How can I start my application in iconic state?
130)  How can an application iconify itself?
131)  How can an application de-iconify itself?
132)  TOPIC: MISCELLANEOUS
133)+ How do I controll the repeat rate on a SUN keyboard ??
134)  How can I identify the children of a manager widget?
135)  How do I tell if a scrolled window's scrollbars are visible?
136)  How can I programatically scroll a XmScrolledWindow in XmAUTOMATIC mode?
137)  What functions can an application use to change the size or position  
      of a widget?
138)  What widgets should I use to get the look of push buttons, but
139)+ How do I obtain the size of a unmanaged shell widget?
140)  Can  I  use  XtAddTimeOut(),  XtAddWorkProc(),  and  XtAddInput()  
      with XtAppMainLoop()?
141)  Why does XtGetValues() XmNx and XmNwidth return extremely large values.
142)  Can I specify callback functions in resource files?
143)  How do I specify a search path for ".uid" files?
144)  XtGetValues() on XmNx and XmNy of my top level shell  don't  return  
      the correct root window coordinates.  How do I compute these?
145)  Can I use XmGetPixmap() with widgets that have non-default visual types?
146)  How can I determine the item selected in a option menu or a RadioBox?
147)  What is the matter with Frame in Motif 1.2?
148)  What is IMUG and how do I join it?
149)  What is the X Professional Organization
150)  How do I set the title of a top level window?
151)  Can I use editres with Motif?
152)  How can I put decorations on transient windows using olwm?
153)  Why does an augment translation appear to act as replace for some 
      widgets?
154)  How do you "grey" out a widget so that it cannot be activated?
155)  Why doesn't the Help callback work on some widgets?
156)  Where can I get a Table widget?
157)  Has anyone done a bar graph widget?
158)  Does anyone know of a source code of a graph widget
159)+ Is there a help system available, such as in Windows 3?
160)  Can I specify a widget in a resource file?
161)  Why are only some of my translations are being installed?
162)  Where can I get the PanHandler code?
163)  What are these passive grab warnings?
164)  How do I have more buttons than three in a box?
165)  How do I create a "busy working cursor"?
166)  Can I use the hourglass that mwm uses?
167)  What order should the libraries be linked in?
168)  How do I use xmkmf for Motif clients?
169)  How do I make context sensitive help?
170)  How do I debug a modal interaction?
171)+ How can I disable Drag and Drop in my Motif 1.2 client ?
172)  Where can I get info on the Motif drag and drop protocol?
173)  TOPIC: ACKNOWLEDGEMENTS













If you have suggestions or corrections for any of these answers or any 
additional information, please send them directly to dealy@kong.gsfc.nasa.gov;
the information will be included in the next revision (or possibly the one 
after that; thanks for the many suggestions which haven't been incorporated 
yet).  The answers in this iteration are acknowledged to be partial.

This posting is intended to be distributed at approximately the beginning of 
each month.

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. 

Conventions used below: telephone numbers tend to be Bell-system unless 
otherwise noted; prices on items are not included.
copyright 1993 b.dealy







-----------------------------------------------------------------------------
Subject:  0)* TOPIC: WHAT ARE OTHER RELEVANT NEWSGROUPS?

[Last modified: Feb 93]

Answer: This newsgroup is comp.windows.x.motif.

The nearest related group is comp.windows.x.  It also maintains an FAQ, which
deals in all sorts of X, Xlib and Xt questions. Look there for answers to
questions such as "How do I get a screendump of my application?", "where do I
get X11R4,X11R5, X11R6", etc.  Other groups which may have relevant
information are comp.windows.x.pex, comp.windows.x.apps,
comp.windows.x.intrinsics, comp.windows.news, comp.windows.misc and
comp.windows.open-look.  The intrinsics and open-look groups also have an FAQ.

The newsgroup news.answers contains *lots* of FAQs (including this one).  Look
there for lots of info on everything.

-----------------------------------------------------------------------------
Subject:  1)  TOPIC: FTP ARCHIVES

-----------------------------------------------------------------------------
Subject:  2)  Is the FAQ list available for FTP anywhere?

[Last modified: Dec 93]

Answer: A number of FAQ's (including this one) are available for anonymous ftp
at rtfm.mit.edu, under the directory pub/usenet.  (Motif is under
pub/usenet/comp.windows.x.motif and also under
pub/usenet/comp/windows/x/motif) 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_5).Z

This service is looked after by Jonathan Kamens (jik@rtfm.mit.edu).

It has also been placed in contrib/Motif-FAQ at
ftp://ftp.x.org/contrib/Motif-FAQ

This files are also accessible from WAIS (Wide Area Information System) under
UC-Motif-FAQ, allowing keyword-based searches of the FAQ.  ---------
--------------------------------------------------------------------
Subject:  3)+ Is this FAQ accessible via WWW?

[Last modified: Dec 93]

Answer: A simple version of the FAQ has been htmlized on news.answers But a
more in-depth restructuring is under way and should be available soon at a web
server near you.

-----------------------------------------------------------------------------
Subject:  4)  Is this newsgroup accessible via email?

[Last modified: April 93]

Answer: An email link is maintained by Brian Dealy.  To join, send mail to
motif-request@lobo.gsfc.nasa.gov.

-----------------------------------------------------------------------------
Subject:  5)  Is this newsgroup archived?

[Last modified: November 1992]

Answer: The newsgroup files from August 1991 are available from
csc.canberra.edu.au (137.92.1.1) by anonymous ftp.  They are in the directory
/pub/motif/comp.windows.x.motif.

These files are also accessible from WAIS (Wide Area Information System) under
comp.windows.x.motif, allowing keyword-based searches of the newsgroup
articles (this time on machine services.canberra.edu.au (137.92.1.12)).

-----------------------------------------------------------------------------
Subject:  6)  Is the mail list motif-talk archived?

Answer: If you have purchased support from OSF then you have access to their
archive server for motif-talk.

-----------------------------------------------------------------------------
Subject:  7)  TOPIC: OSF AND MOTIF

-----------------------------------------------------------------------------
Subject:  8)  Because of COSE, is Motif now in the public domain?

Answer: The *specification* for Motif is no longer controlled by OSF, but by
X/Open.  This does not affect the *implementation*. The implementation is
still in the hands of OSF, and will not be released into the public domain.
So no, the OSF source code will still only be available to those who buy a
source code license from OSF.

The specification does not include UIL or obsolete features (ie 1.0 bugs in
design), but these will continue to be supported by the OSF code.

-----------------------------------------------------------------------------
Subject:  9)* What versions of Motif are there?
[Last modified: March 93]

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 OSF/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.  OSF distributes a 10
pages sheet entitled "OSF/Motif R1.1 to R1.2: detailed overview of changes",
which is available from OSF Motif direct channels.  (617-621-7300 or email
direct@osf.org)

Motif 1.2.1 was released September 92.  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 93.  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.


-----------------------------------------------------------------------------
Subject: 10)* Where can I get Motif?

[Last modified: APR 94]

Answer:
    Various hardware vendors produce developer's toolkits of binaries, header
files, and documentation; check your hardware vendor, particularly if that
vendor is an OSF member. Systems known to be shipping now: HP (sans UIL),
Apollo (sans UIL), SCO, ICS, Mips (RISCwindows=X11R3 + full Motif), IBM, Data
General for AViioNs (includes UIL), Bull (?), Concurrent Computer Corporation
5000, 6000, 8000 series machines, Convex, Sequent.

    In addition, independent binary vendors produce Motif toolkits .

[An FAQ is for "personal opinions" on these toolkits.  I don't think it is
appropriate to give such opinions through this particular posting, so I
haven't included any.]

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

ICS provides binary distributions of Motif for Sun platforms.  Other platforms
are available as well, call or send mail for current info.  ICS also provides
in-depth programming support for Motif and additional tools such as Builder
Xcessory, a Motif interface builder, and the Widget Databook, a source for
third party, commercially available and supported widgets, class libraries,
and subsystems.

Quest (408-496-1900) sells kits for Suns, as well;

IXI (+44 223 236 555) offers kits for Sun3         (SunOS 3.5 or later, and
Sun4         (SunOS 4.0.1 or later).         (Solaris 2.1 or later ( both
SPARC  and Intel ))         ( both M1.1.5 and Motif 1.2.2 for SPARC, Motif
1.2.2 for Intel ).

Sun Microsystems is now shipping a version of Motif also.

NSL (+33 (1) 43 36 77 50; requests@nsl.fr) offers kits for the Sun 3 and Sun
4.


In Australia, Information Technology Consultants Pty Ltd has Motif 1.1.2 for
Sun Sparc 4.1 ( phone on (02) 360 6999, fax on (02) 360 6695 or e-mail to
motif@itcsyd.itc.oz.au)

SILOGIC (+33 61.57.95.95), 78 chemin des Sept Deniers - 31200 TOULOUSE FRANCE
sells Motif 1.1 and 1.2 on Sun4 machines. They also provide customers with
Motif maintenance and support, and do consulting on the X window System at
large, including software development.

METRO LINK INC., has Motif 1.2.3 and Motif 1.2.2 Runtime and Development
packages available for a variety of operating systems.  All versions ship with
shared library version of libXm.  Linux version includes free O'Reilly volume
and FTP shipping option.  Send mail to:

Motif 1.2.3 (available Dec. 1, 1993)
    Linux 0.99, Solaris 2.x (SPARC), SunOS 4.1.x      --->  $199.00
    Solaris 2.1 (x86)                                 --->  $299.00

Motif 1.2.2
    Linux 0.99, Solaris 2.x (SPARC), SunOS 4.1.x      --->  $199.00
    QNX, SVR3, SVR4.[012], SCO, UnixWare, SINIX,
    LynxOS, Venix, ISC, NCR SVR4 MP                   --->  Under $299.00

Metro Link Incorporated.  2213 W. McNab Rd. Pompano Beach,  Florida  33069
Voice: +1.305.970.7353x412  Fax: +1.305.970.7351  Email: ken@metrolink.com




BIM (Fax : +32(2)759.47.95) offer Motif 1.1 for Sun-3, Sun-4, Sun-386i.
Includes shared libraries.

Metrolink Inc. (+1-305-566-9586, sales@metrolink.com; in Europe contact ADNT,
(33 1) 3956 5333) ships an implementation of X11R4 and Motif 1.1 for several
386 systems.

    An OSF/Motif source license must be obtained from OSF before source can be
obtained from the Open Software Foundation. Call the Direct Channel Desk at
OSF at 617-621-7300 or email direct@osf.org for ordering information.

Bluestone offers Motif for $99.  Bluestone's  MWM is the compiled version of
OSF/ Motif for Sun/SPARC. It is plain vanilla Motif based on X11 and Xt
Intrinsics.  There is no license manager.  Platforms: Sun/OS 4.1+ and Solaris
V2.1,2.2. Contact: Bluestone @609-727-4600

In addition to the full Motif source, "option C" allows you to purchase source
for the window manager mwm to run on X terminals.


-----------------------------------------------------------------------------
Subject: 11)  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: 12)  Where can I get public domain Motif source?

Answer: You cannot.  Motif source is not publically available.


-----------------------------------------------------------------------------
Subject: 13)* Are the Motif examples publically available?

[Last modified: DEC 93]

Answer: OSF has produced a list of which of the example programs can be
distributed. Call OSF Direct for a copy of it.  Most of the example programs
have been freed from distribution limitations so should be available.

In addition to these, many programs on export.lcs.mit.edu in the contrib
directory use Motif.  Source code posted to comp.sources.x often uses Motif.

The examples from Dan Heller's book are on export in
/contrib/OReilly/motif/examples.tar.Z.  The examples from Thomas Berlages's
book are on export in /contrib/berlage.motif.tar.Z The examples from Donald L.
McMinds's book are on export in /contrib/mastering.motif.tar.Z The examples
from Jan Newmarch's book are export in /contrib/newmarch.tar.Z The examples
from Jerry Smith's book are on export in contrib/smith.motif.tar.Z

Also from a list maintained by: qizeng@acsu.buffalo.edu (Qi Y. Zeng) FTP sites
for X/MOTIF source codes:

         ftp.uu.net
                published/brain.motif.tar.Z

         ftp.x.org
                contrib/young.C++.tar.Z

         ftp.x.org
                contrib/pwmxmpl.tar.Z

         ftp.x.org
                contrib/newmarch.tar.Z

         ora.com
                pub/examples/xresource

         skye.aiai.ed.ac.uk(192.41.104.6)
                pub/wxwin/wxwin150.tar.Z (UNIX)
                pub/wxwin/wxwin150.zip (PC)

-----------------------------------------------------------------------------
Subject: 14)* Has anyone done a public domain Motif lookalike?

[Last modified: March 93]

Answer: Not yet.  The specification is available (AES), and the validation
suite can be bought, but no-one has taken up the challenge.  There are some
commercial lookalikes (Looking Glass and Neuron Data), but no workalikes.

Applications that follow the Style Guide might be certified Motif-compliant
through the checklist process, even though they're not using OSF/Motif
binaries.

Tcl/Tk is available for ftp from allspice.berkeley.edu, and although
implemented without Xt, has a "strict Motif" mode.

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 is on interviews.stanford.edu.  A commercial version is available
as InterViews Plus.


-----------------------------------------------------------------------------
Subject: 15)  Does anyone from OSF pay attention to our questions/suggestions?

Answer: Yes, and they quite often post answers too. But they may not respond
to *your* problem because they have other things to do as well.  This
newsgroup is not run by OSF, and has no formal connection with OSF.  OSF is a
member-driven company.  The membership (and anyone can be a member) provides
the primary input for future development of Motif.

-----------------------------------------------------------------------------
Subject: 16)  Does OSF have an application compliance validation service?

Answer: They have a checklist and a certification process which you can
request from them.  Ask for the Level One Certification Checklist.  The
process is one of self-certification.  It tests only the appearance and
behavior of the application against Motif style.  The product will also be put
in the OSF reference listing.  There's a one-time fee of $250.  According to
the master license agreement, you can't use any OSF identifying mark unless
you have done a certification.


-----------------------------------------------------------------------------
Subject: 17)  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.



-----------------------------------------------------------------------------
Subject: 18)  What MIT patches do I use, and when do I use fix-osf?

Answer: The Motif 1.1.0 tape contains MIT patches 1-14. Apply these and any
others you can get.  If your MIT patch level only goes up to fix-16, you also
need to apply fix-osf.  Fix-osf was an emergency patch for a problem that
existed when the Motif 1.1 tape was cut, The MIT fix-17 completely superseded
osf-fix, so if you have applied fix-17 do not apply fix-osf.  The 1.1.1 tape
contains MIT fixes 15-18, as well as an OSF-developed fix that deals with a
subtle bug in the Selection mechanism of the Intrinsics.  Most people will
have fix-15 to 18 by now; if you don't have them:

        Back out fix-osf if you have applied it
        Apply fix-15 to 18
        Apply fix-osf-1.1.1

The Selection fix was submitted to MIT, who came up with a different fix.  It
will not be made into an R4 fix but should be in R5. The MIT fix was posted to
motif-talk.


-----------------------------------------------------------------------------
Subject: 19)  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).  Thre is an MIT patch that may fix this??  [I confess
ignorance of Mrm and UIL].

-----------------------------------------------------------------------------
Subject: 20)* How can I find which version of Motif I have?

[Last modified: October 93]

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.

To find the minor revision number is not easy.  From Motif 1.1.3 onwards, try
this:

   'strings `which mwm` | grep OSF'.

to get the full version number e.g. 1.1.3.

In Motif 1.2, the macro XmUPDATE_LEVEL was added to give the minor revision
number.

+ ( above also known as the patch level).  + In addition there was a macro
string added,  XmVERSION_STRING which has all + the above info in a char
string.

+ grepping through a strings of libXm.a for OSF can also sometime give +
something useful.

Version X11R6 is due out in spring of 1994 (april 15?)

thanks to hops@x.co.uk Mike Hopkirk

-----------------------------------------------------------------------------
Subject: 21)  TOPIC: LITERATURE

-----------------------------------------------------------------------------
Subject: 22)* What books should I read or do I need to program using Motif?

[Last modified: April 93]

Answer: Ken Lee of the DEC Western Software Laboratory (klee@wsl.dec.com)
regularly posts to comp.windows.x and ba.windows.x a list of reference books
and articles on X and X programming.  In FAQ comp.windows.x an extract of his
list appears. Specifically for Motif programming, though:

OSF/Motif Programmers Guide, Prentice-Hall ISBN 13-640525-8 (Motif 1.0), ISBN
0-13-640681-5 (Motif 1.1), ISBN 0-13-643107-0 (Motif 1.2) (NB: This makes use
of the demo programs that you get with a Motif source license.  The programs
are not included and may or may not be available on your system.)

OSF/Motif Programmers Reference Manual, Prentice-Hall ISBN 13-640517-17 (Motif
1.0),
 ISBN 0-13-640616-5 (Motif 1.1), ISBN 0-13-643115-1 (Motif 1.2) You will need
this for the system calls.

OSF/Motif Style Guide, Prentice-Hall 13-640491-X (Motif 1.0), ISBN 0-13-
640673-4 (Motif 1.1), ISBN 13-643123-2 (Motif 1.2) You will need this to get
some idea of how to write programs with the correct `look and feel'.

You should read at least one of the the non-OSF books on Motif:

Sebern, Mark "Building OSF/Motif Applications: A Practical Introduction". The
ISBN is 0-13-122409-3. Prentice-Hall.

The book uses a large, realistic Motif application (a program to make slides
for presentations) to demonstrate the use of Motif features. Both UIL and
toolkit calls are discussed, though UIL is featured, both in the examples and
in a reference chapter.

Young, Doug. "The X Window System: Applications and Programming with Xt (Motif
Version)," Prentice Hall, 1989 (ISBN 0-13-497074-8). The excellent tutorial "X
Window Systems Programming and Applications with Xt," (ISBN 0-13-972167-3)
updated for Motif.

Marshall Brain at brain@adm.csc.ncsu.edu posted a set of simple and useful
Motif tutorials.

Berlage, Thomas Berlage, OSF/Motif: Concepts and Programming, Addison-Wesley,
UK, 1991. ISBN 0-201-55792-4.

Johnson, Eric F. and Kevin Reichard, Power Programming Motif, MIS: Press,
Portland, OR, 1991. ISBN 1-55828-059-6. Book with disk, ISBN 1-55828-061-8.

Ferguson, Paula M, The Motif Reference Manual, Volume 6B of the O'Reilly
series on X.  This is the new volume of a two volume set on Motif programming.
ISBN 1-56592-038-4 (Motif 1.2)  (Volume 6A is expected to ship soon)

Barkakati, Nabajyoti, X Window System Programming, SAMS. ISBN 0-672-22750-9.
This contains a section on Motif.

Smith, Jerry, Designing X Clients with Xt/Motif, ISBN 1-55860-255-0 Morgan
Kaufmann Publishers This adopts a higher-level approach to many of the objects
that commonly occur in Motif but are not in the Motif API.


Newmarch, Jan, The X Window System and Motif - A Fast Track Approach.
Addison-Wesley, ISBN 0-201-53931-4.

You will also need books and references on Xt such as:

Asente, Paul J., and Swick, Ralph R., "X Window System Toolkit, The Complete
Programmer's Guide and Specification", Digital Press, 1990.  The bible on Xt.
A treasury of information, excellent and invaluable.  Distributed by Digital
Press, ISBN 1-55558-051-3, order number EY-E757E-DP; and by Prentice- Hall,
ISBN 0-13-972191-6.

Nye, Adrian, and Tim O'Reilly, "X Toolkit Programming Manual, Volume 4,"
O'Reilly and Associates, 1989. The folks at O'Reilly give their comprehensive
treatment to programming with the MIT Intrinsics; R4 versions are now
available, as is a Motif 1.1 version (Volume 4M).

Dan Heller's version of the Motif Programming Manual is still a widely used
and useful book. It is being replaced by Volume 6a and 6b but is a very useful
resource. Volume 6, Oreilly and Associates, Motif Edition.

Flanagan, David, ed.,  "X Toolkit Reference Manual, Volume 5," O'Reilly and
Associates, 1992a, Third Edition. A professional reference manual for the MIT
X11R4 and X11R5 Xt.

Books and reference manuals on Xlib may also be useful.

If you want to learn about UIL, look in the Motif Programmers's Guide.  This
seems to be the only information.


-----------------------------------------------------------------------------
Subject: 23)  TOPIC: MWM

-----------------------------------------------------------------------------
Subject: 24)  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 Guideline, an API toolkit of `C' routines which helps in the
building of applications which conform to the Guideline, the window manager
mwm, and a language UIL which is designed to ease user interface development.
In general mwm will run an application built with any X-windows API, and in
general an application built using the Motif toolkit will run under any window
manager.


-----------------------------------------------------------------------------
Subject: 25)  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: 26)  How can I modify the Motif window manager decorations?

Answer: In resource files, use the window manager's client resource (which is
the application) and the resource clientDecoration:

Mwm*XClock.clientDecoration:   none

turns off all clock decorations.  See the mwm(1) entry for other
possibilities.

Programmatically, set the VendorShell resource XmNmwmDecorations to
appropriate values: MWM_DECOR_NONE (or a bitwise or of values).

-----------------------------------------------------------------------------
Subject: 27)  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 <Xm/MwmUtil.h>

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



-----------------------------------------------------------------------------
Subject: 28)  How can tell I if the user has selected the "Close" item on the
system menu attached to the top-level shell?  I need to do some clean up
before exiting.

[Last modified: May 93]

Answer:          This works with R4 Intrinsics

        #include <Xm/Protocols.h>

        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:-)."


-----------------------------------------------------------------------------
Subject: 29)  Is there an mwm virtual desktop manager?

Answer: Peter E. Wagner (pew@cs.brown.edu): Imagine that your "desktop"
extends beyond the view provided by your monitor.  A virtual window manager
gives you access to the space beyond your viewport (i.e. your screen) by
allowing you to move the viewport to other areas of the extended desktop.

The first one is Solbourne's swm, which spawned vtwm/tvtwm/olvwm.

David B. Lewis created one.  suresh@unipalm.co.uk has further developed it
into the UniPalm product DOORS, which is only available as a source code
extension to the MOTIF window manager.  The price of the source and unlimited
right to distribute binaries is 10,000 pounds Sterling.  Alternately, source
and right to use within one company is 2,000 pounds Sterling.  Contact Peter
Dawe

Unipalm Limited                         Voice: +44 (0) 223 420002
216 The Science Park                    Fax:   +44 (0) 223 426868
CAMBRIDGE
CB4 4WA



An enhancement request for such an object has been filed with OSF.

-----------------------------------------------------------------------------
Subject: 30)  Why does mwm 1.2 crash on startup?

[Last modified: March 93]

Answer: From David Brooks: The commonest cause of early mwm demise is as
follows:

- You, or someone, built Xlib in the default way using the Xsi
  internationalization functions.

- Your Xlib wasn't installed completely (or at all).

- Early on, mwm calls the function XmbTextListToTextProperty, which calls
  _XConvertMBToCT, which looks for the Xsi locale database, finds it
  missing, ignores this fact and tries to dereference zero.

The workaround is to find the database *somewhere*, and point the environment
variable XNLSPATH at it.  For example, in my personal X source tree:

        setenv XNLSPATH /home/X11r5src/mit/lib/nls/Xsi


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

-----------------------------------------------------------------------------
Subject: 31)  TOPIC: MOTIF GENERATORS

-----------------------------------------------------------------------------
Subject: 32)  What prototyping tools are there to generate Motif code?

[Last modified: June 93]

Answer: [An FAQ is for "personal opinions" on these tools.  I don't think it
is appropriate to give such opinions through this particular posting, so I
haven't included any. I will include vendor-provided descriptions provided
they are consise and informative]

`Prototyping tools' come in two forms: those that can be used to design the
interface only (GUI builder), and those that go beyond this to give support
for application code (User Interface Management Systems).  There are a number
of commercial and non-commercial tools of both kinds that will support the
Motif interface.  They include:

GUI builders:

Builder Xcessory
iXBUILD (formerly X Build)
ExoCODE/xm
MOTIFATION
X-Designer
Druid


UIMS:

WINTERP
ALEX
TAE Plus
Widget Creation Library
UIMX
Serpent
TeleUse
XFaceMaker2
MetaCard
ezX User Interface Management System


Some contact addresses are:



TAE Plus: Don Link, Century Computing, Inc. (301) 953-3330 tae-facts@cen.com

TAE Plus is a mature, portable software development environment that supports
rapid building, tailoring, and management of Motif-based graphical user
interfaces.  The code generator can produce C, C++ and Ada code and allows for
merging regenerated code with previously modified parts of the interface.  You
an also generate a UIL/Mrm representation of your interface.  Scripting
capabilities are provided which facilitate automatic testing, on-line demos,
and tutorials.  A record and playback feature lets you build scripts simply by
interacting with your GUI.  A library of Dynamic Data Objects allows the user
to create truly graphical objects whose dynamic portions can reflect data as
well as be directly manipulated by the end-user. TAE Plus is available on
virtually all the standard X platforms and comes with a wide array of support
vehicles. (i.e., support office, newsletter, user's conference, etc.)

WINTERP: You may obtain the current source, documentation, and examples via
anonymous ftp from host export.lcs.mit.edu: in directory contrib/winterp you
will find the compress(1)'d tar(1) file winterp.tar.Z. If you do not have
Internet access you may request the source code to be mailed to you by sending
a message to winterp-source%hplnpm@hplabs.hp.com or hplabs!hplnpm!winterp-
source.

Serpent: The S/W is free (anonymous ftp) from ftp.sei.cmu.edu.  For more info
contact erik/robert at serpent-info@sei.cmu.edu.  This is no longer supported,
and is apparently replaced by a commercial product called Alpha.  TeleUSE:
Built around X Windows and OSF/Motif, TeleUSE's comprehensive toolset gives
you maximum control over every phase of graphical user interface development,
including static screen layout and design, automatic implementation of
callbacks, building the executable, and the interactive test, debug, and
maintenance cycles.

For more information, please contact:

In North America and countries not specified below:

Alsys (formerly TeleSoft)
10251 Vista Sorrento Parkway Suite 300
San Diego, CA 92121 USA

(619) 457-2700 X244
(619) 452-1334 (fax)
leigh@alsys.com

In France: +33 1 47 66 21 83
In the UK: +49 491 579 090
In Scandinavia: +46 8 520 69010
In the Benelux: +31 15 62 21 21
In Germany: +49 7531 65022
In Italy: +39 6 5045 1
In Japan: +81 3 522 85620
In South Korea: +82 2 577 2044



Builder Xcessory from ICS.  More details are available by sending a request to
info@ics.com.  Address: ICS Inc., 201 Broadway, Cambridge MA 02139, Tel. (617)
621-0060, Fax. (617) 621-9555

X-Designer: From Imperial Software Technology in the UK.  Email address is
sales@ist.co.uk.  (+44) 743 587055

Recently, V.I. Corporation have become the distributor for the X-Designer
product in the United States.  In addition, IST and V.I. Corporation have
developed a product called DVX-Designer that merges X-Designer with their GUI
product called DataViews.  Other merged products are in the works.  For more
information, people can contact:

        V.I. Corporation
        47 Pleasant Street
        Northampton, MA  01060
        Phone: (413) 586-4144
        Fax: (413) 586-3805
        Email: vi@vicorp.com

ExoCODE/xm: From Expert Object Corp., 7250 Cicero Avenue, Lincolnwood, IL
60646 (708)676-5555.

X Build: iXOS Software GmbH, Bretonischer Ring 12,
        8011 Grasbrunn/Munich,
        Germany,
        email support@ixos.de or office@ixos.de,
        phone ++49-89-46005 0

or in the US

        UniPress Software,
        2025 Lincoln Hwy.,
        Edison, NJ 08817,
        phone 1-800-222-0550

ExoCode: From EXOC (Chicago, IL)

UIMX: Visual Edge Software Limited, 3870 Cote Vertu, St Laurent, Quebec, H4R
1V4, Phone: (514) 332-6430, Fax:   (514) 332-5914, or: Visual Edge Software
Ltd., 101 First Street, Suite 443, Los Altos, CA 94022, Phone: (415) 948-0753,
Fax:   (415) 948-0843

The Widget Creation Library: The distribution is available in several ways.
The preferred approach it for you to get the compressed tar file using
anonymous ftp from:

    export.lcs.mit.edu    (18.30.0.238) /contrib/Wcl.1.06.tar.Z


XFaceMaker2: NSL -  Non Standard Logics S.A., 57-59, rue Lhomond, 75005  Paris
- France, Phone: +33 (1) 43.36.77.50, Fax:   +33 (1) 43.36.59.78 email:
requests@nsl.fr or requests%nsl.fr@inria.fr for information.

Their North American office: Non Standard Logics, Inc., 4141 State Street,
Suite B-11, Santa Barbara CA 93110, Tel: 805 964 9599, Fax: 805 964 4367


MOTIFATION: PEM GmbH, Vaihinger Strasse 49, 7000 Stuttgart 80, Germany, Tel:
+49 (0) 711 713045, Fax: +49 (0) 711 713047 Email: basien@pem-stuttgart.de.
Available for (Motif 1.2/1.1) on SunOS, Solaris 2.1, HP, Interactive, ODT 3.0,
Silicon Graphics, PCS, ...


ALEX: For more information contact Michael Karliner on (+44) 81 566 2307 or
E-mail to alex@s-strat.co.uk.  ALEX Technologies, Waterman's Yard, 32a The
Mall, Ealing, London W5, UK.

MetaCard: MetaCard 1.0 is supported on five popular UNIX/X11 platforms: SPARC,
Sun3, DECstation, HP-9000/300, and SCO ODT.  An HP-9000/700 port is underway
and should be available by the end of July.  [They] plan to support IBM
RS/6000, SGI Iris, and DG AViiON sometime fall '92.  For more information, or
to receive a free save-disabled but licensable copy of MetaCard, email to
info@metacard.com or call 303- 447-3936.  If you have anonymous FTP access to
the Internet, you can download the current engines, documentation, and an
unlicensed Home stack from ftp.metacard.com (128.138.213.21), directory
MetaCard.  Commercial users can get MetaCard from world.std.com
(192.74.137.5), directory pub/Metacard.  If you don't have an anonymous ftp
access, you can also download MetaCard from The World using kermit or xmodem
from the ~ftp/pub/MetaCard directory.  Sign up by calling 617-739-0202 (voice)
or via modem by dialing 617-739-9753 (7 bits even parity) and logging in as
new.

MetaCard 1.2 Beta 5 is now available for anonymous FTP from ftp.metacard.com
(directory MetaCard/1.2B5), and ftp.uu.net (directory vendor/MetaCard/1.2B5).

There is also a MetaCard mailing list.  To subscribe to the metacard-list,
send mail to listserv@grot.starconn.com with the following commands in the
body of the message:

      subscribe metacard-list firstname lastname
      quit


Replace "firstname lastname" with your name, not your e-mail address.



ezX User Interface Management System
Sunrise Software, International
170 Enterprise Center
Middletown, RI 02840
401-847-7868
email: support@sunrise.com



WKSH (Windowing Korn Shell):

   EXtensible Korn Shell (C language calling interface,
                          dynamic library loading, etc.)
   Motif or OpenLook API
   X Toolkit Intrinsics
   WKSH Convenience Functions
   Fast Learning and Prototyping Feature (ksh interpreter)


Contact:
   Acacia Computer,
   PO Box 4376,
   Warren, NJ 07059,
   Phone: 908 548 6955,
   Email: uunet!aca1

or

Computer Aid Inc, 1-(800)-444-WKSH

or

Consensys Corp, Europe: +(44)-734-833241 (Roger Chalke), +(44)0734-835391
(Fax), US: (416)-940-2903, (416)-940-2903 (Fax).


WKSH was developed by USL. Binaries are available through Acacia Computer for
SUNOS, Solaris, SCO ODT, Intel SVR4.0


Druid is a commercial product. It currently supports Motif1.1 and 4 unix
platforms: SPARC, HP 9000, RS6000, and SGI.

For further information contact: Mr. Fred Lee, Automated Systems (Pte)
Limited, 203 Henderson Road, #12-07/14, Henderson Industrial Park, Singapore
0315.  FAX: (65)272-2029

Or: Dr. Gurminder Singh (gsingh@iss.nus.sg), Institute of Systems Science,
National University of Singapore




-----------------------------------------------------------------------------
Subject: 33)  TOPIC: TEXT WIDGET

-----------------------------------------------------------------------------
Subject: 34) What is the difference between a XmTextField widget and a single
line XmText widget?

Answer: Their functionality is the same, but the XmTextField is designed to
give superior performance.  thanks to Ken Lee, klee@synoptics.com


-----------------------------------------------------------------------------
Subject: 35)  Why does  pressing  <return> in a text widget do nothing?  This
happens using Motif 1.0 when I have a text widget inside a bulletin board (or
form) inside a dialog shell. (In Motif 1.1 it is fixed for both text and list
widgets.)

Answer: In single line mode, pressing the <return> key usually invokes the
activate() action, and in multi-line mode, the newline() action.  However,
whenever a widget is the child of a bulletin board widget which is the child
of a dialog shell, the bulletin board forces all of its children to translate
<return> to the bulletin board action Return() which is usually associated
with the default button of the dialog.  To restore the text actions of
activate() or newline(), you need to overide the Return() action of the
bulletin board.


        /* declarations */
        /* for a single line widget */
        char newTrans[] = "<Key>Return : activate()";
        /* for a multi line widget */
        char newTrans[] = "<Key>Return : newline()";
        XtTranslations transTable;

        /* in executable section */

        transTable = XtParseTranslationTable(newTrans);

        /* after creating but before managing text widget */

        XtOverrideTranslations(textWidget, transTable);


-----------------------------------------------------------------------------
Subject: 36)  When I add text to a scrolling text widget how can I get the new
text to show?

Answer: Use the call undocumented in Motif 1.0

        void XmTextShowPosition(w, position)
        Widget w;
        XmTextPosition position;

where the position is the number of characters from the beginning of the
buffer of the text to be displayed. If you don't know how many characters are
in the buffer, use another call undocumented in Motif 1.0

        position = XmTextGetLastPosition(w)


-----------------------------------------------------------------------------
Subject: 37)  Does the text widget support 16 bit character fonts?


[Last modified: November 92]

Answer: R5 has support for 16 bit character sets, and Motif 1.2 uses that.
Neither Motif 1.0 nor 1.1 support 16 bit sets.

-----------------------------------------------------------------------------
Subject: 38)  How can I stop the text widget from echoing characters typed?  I
need to turn off echo for password input.

Answer: Use the modifyVerifyCallback to tell when input is received. Set the
`doit' field in the XmTextVerifyCallbackStruct to False to stop the echo. In
Motif 1.0 this will cause a beep per character: Live with it, because at 1.1
you can turn it off.  Note that password hiding is inherently insecure in X -
someone may have an X grab on the keyboard and be reading all characters typed
in anyway.

Another solution often proposed is to set the foreground and background
colours to be the same, effectively hiding the text.  This has a major flaw:
someone may select the text (triple click the mouse to get the line), and then
paste the password into say an xterm with *different* foreground and
background colours.  This immediately shows the password.

-----------------------------------------------------------------------------
Subject: 39)  How can I replace characters typed with say a `*'?  I want to
replace input for password entry.

[Last modified: April 93]

Answer: In Motif 1.1 Use the modifyVerifyCallback to tell when input is
received.  Set text->ptr in the callback structure to '*'. This does not work
under 1.0 because of an oversight in which changes to this are ignored.  In
Motif 1.0, what you can do is set the doit flag to 'false' so the text is not
displayed. Then set a static boolean to True to prevent re-entrance.  Next
call XmTextReplace() to display your '*'.  then reset your re-entrance flag to
False.  XmTextReplace() will call the XmNmodifyVerify callback.  To prevent
getting into an infinite loop, you need the re-entrance flag.

The following program from Dan Heller illustrates 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 appears
 * in the Motif Programming Manual, O'Reilly Volume 6.
 */

/* passwd.c -- prompt for a passwd.  Meaning, all input looks like
 * a series of *'s.  Store the actual data typed by the user in
 * an internal variable.  Don't allow paste operations.  Handle
 * backspacing by deleting all text from insertion point to the
 * end of text.
 */
#include <Xm/Text.h>
#include <Xm/LabelG.h>
#include <Xm/RowColumn.h>
#include <ctype.h>

void check_passwd();
char *passwd; /* store user-typed passwd here. */

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

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

    rowcol = XtVaCreateWidget("rowcol",
        xmRowColumnWidgetClass, toplevel,
        XmNorientation, XmHORIZONTAL,
        NULL);

    XtVaCreateManagedWidget("Password:",
        xmLabelGadgetClass, rowcol, NULL);
    text_w = XtVaCreateManagedWidget("text_w",
        xmTextWidgetClass, rowcol, NULL);

    XtAddCallback(text_w, XmNmodifyVerifyCallback, check_passwd, NULL);
    XtAddCallback(text_w, XmNactivateCallback, check_passwd, NULL);

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

void
check_passwd(text_w, unused, cbs)
Widget        text_w;
XtPointer     unused;
XmTextVerifyCallbackStruct *cbs;
{
    char *new;
    int len;

    if (cbs->reason == XmCR_ACTIVATE) {
        printf("Password: %s\n", passwd);
        return;
    }

    if (cbs->text->ptr == NULL) { /* backspace */
        cbs->endPos = strlen(passwd); /* delete from here to end */
        if (cbs->endPos <= 0) return; /* catch null passwd - Mark Scoville */
        passwd[cbs->startPos] = 0; /* backspace--terminate */
        return;
    }

    if (cbs->text->length > 1) {
        cbs->doit = False; /* don't allow "paste" operations */
        return; /* make the user *type* the password! */
    }

    new = XtMalloc(cbs->endPos + 2); /* new char + NULL terminator */
    if (passwd) {
        strcpy(new, passwd);
        XtFree(passwd);
    } else
        new[0] = NULL;
    passwd = new;
    strncat(passwd, cbs->text->ptr, cbs->text->length);
    passwd[cbs->endPos + cbs->text->length] = 0;

    for (len = 0; len < cbs->text->length; len++)
        cbs->text->ptr[len] = '*';
}


-----------------------------------------------------------------------------
Subject: 40)  How can I best add a large piece of text to a scrolled text
widget?  In some versions of Motif 1.0 even using XmTextSetString, it insists
on adding the text one line at a time, adjusting the scroll bar each time. It
looks awful and is slow.

Answer: If you don't have this problem, use XmTextSetString to set all of the
text in the widget.  If you do have this slowdown problem even using
XmTextSetString, unmanage the widget, add the text and then manage it again.
This may cause the window to blink, but you have to put up with that or switch
to a different version of Motif.

-----------------------------------------------------------------------------
Subject: 41)  How can I highlight text in the Text widget?

Answer: From: argv@zipcode.com (Dan Heller)

If you don't need font or color changes, you can do all this using a Text
widget very easily [in Motif 1.1, anyway].

        loop() {
            pos = offset_of_pattern_in_text_widget(pattern, text_w);
            search_len = strlen(pattern);
            XmTextSetHighlight(text_w, pos, pos+search_len,
                        XmHIGHLIGHT_SELECTED);
        }


There are two choices for highlighting: reverse video (HIGHLIGHT_SELECTED) and
underlined (HIGHLIGHT_SECONDARY_SELECTED).  Be careful that your users won't
confuse your highlights with actual selections!

-----------------------------------------------------------------------------
Subject: 42)  How can I select all of the text in a widget programmatically?
So that some initial text is displayed, but anything typed replaces it.

Answer: XmTextSetSelection(Text1, 0, XmTextGetLastPosition(Text1), event-
>xbutton.time);

where Text1 is the widget in question (obviously) and event is some event that
triggered this call.  You can use XtLastTimestampProcessed( display) instead
of xbutton.time if you don't happen to have an event pointer handy.




-----------------------------------------------------------------------------
Subject: 43)  How can I change colours of text in the Text widget?  I want
some of the text in one colour, some in another.

Answer: You can't.  Text stores an ordinary string, and points where
`highlights' of various types begin and end.  These highlights are all the
control you have over components of the text.  See the previous question.


-----------------------------------------------------------------------------
Subject: 44)  How can I change the font of text in the Text widget?  I want
some of the text in one font, some in another.

Answer: You can't in Text (see the previous question).  If you wanted readonly
text, you could do it by using a label instead.  Label uses XmStrings, which
can contain multiple character sets in the one string.

-----------------------------------------------------------------------------
Subject: 45)  Is there an emacs binding for the text widget?

Answer: This set is due to Kee Hinckley (nazgul@alfalfa.com):

*XmText.translations: #override\n\
        Ctrl <Key>b:            backward-character()\n\
        Alt <Key>b:             backward-word()\n\
        Meta <Key>b:            backward-word()\n\
        Shift Alt <Key>b:       backward-word(extend)\n\
        Shift Meta <Key>b:      backward-word(extend)\n\
        Alt <Key>[:             backward-paragraph()\n\
        Meta <Key>[:            backward-paragraph()\n\
        Shift Alt <Key>[:       backward-paragraph(extend)\n\
        Shift Meta <Key>[:      backward-paragraph(extend)\n\
        Alt <Key><:             beginning-of-file()\n\
        Meta <Key><:            beginning-of-file()\n\
        Ctrl <Key>a:            beginning-of-line()\n\
        Shift Ctrl <Key>a:      beginning-of-line(extend)\n\
        Ctrl <Key>osfInsert:    copy-clipboard()\n\
        Shift <Key>osfDelete:   cut-clipboard()\n\
        Shift <Key>osfInsert:   paste-clipboard()\n\
        Alt <Key>>:             end-of-file()\n\
        Meta <Key>>:            end-of-file()\n\
        Ctrl <Key>e:            end-of-line()\n\
        Shift Ctrl <Key>e:      end-of-line(extend)\n\
        Ctrl <Key>f:            forward-character()\n\
        Alt <Key>]:             forward-paragraph()\n\
        Meta <Key>]:            forward-paragraph()\n\
        Shift Alt <Key>]:       forward-paragraph(extend)\n\
        Shift Meta <Key>]:      forward-paragraph(extend)\n\
        Ctrl Alt <Key>f:        forward-word()\n\
        Ctrl Meta <Key>f:       forward-word()\n\
        Ctrl <Key>d:            kill-next-character()\n\
        Alt <Key>BackSpace:     kill-previous-word()\n\
        Meta <Key>BackSpace:    kill-previous-word()\n\
        Ctrl <Key>w:            key-select() kill-selection()\n\
        Ctrl <Key>y:            unkill()\n\
        Ctrl <Key>k:            kill-to-end-of-line()\n\
        Alt <Key>Delete:        kill-to-start-of-line()\n\
        Meta <Key>Delete:       kill-to-start-of-line()\n\
        Ctrl <Key>o:            newline-and-backup()\n\
        Ctrl <Key>j:            newline-and-indent()\n\
        Ctrl <Key>n:            next-line()\n\
        Ctrl <Key>osfLeft:      page-left()\n\
        Ctrl <Key>osfRight:     page-right()\n\
        Ctrl <Key>p:            previous-line()\n\
        Ctrl <Key>g:            process-cancel()\n\
        Ctrl <Key>l:            redraw-display()\n\
        Ctrl <Key>osfDown:      next-page()\n\
        Ctrl <Key>osfUp:        previous-page()\n\
        Ctrl <Key>space:        set-anchor()\n


! If you'd like the Delete key to work like backspace instead of deleting
! backwards, add the following definition to the lines above.
!       <Key>osfDelete: delete-previous-character()\n\

! These aren't included because they could intefere with
| menu accelerators (or vice versa)
!       Alt <Key>p:             backward-paragraph()\n\
!       Meta <Key>p:            backward-paragraph()\n\
!       Shift Alt<Key>p:        backward-paragraph(extend)\n\
!       Shift Meta<Key>p:       backward-paragraph(extend)\n\
!       Alt <Key>w:             copy-clipboard()\n\
!       Meta <Key>w:            copy-clipboard()\n\
!       Ctrl Alt <Key>w:        cut-clipboard()\n\
!       Ctrl Meta <Key>w:       cut-clipboard()\n\
!       Alt <Key>y:             paste-clipboard()\n\
!       Meta <Key>y:            paste-clipboard()\n\
!       Alt <Key>f:             forward-word()\n\
!       Meta <Key>f:            forward-word()\n\
!       Alt <Key>n:             forward-paragraph()\n\
!       Meta <Key>n:            forward-paragraph()\n\
!       Shift Alt <Key>n:       forward-paragraph(extend)\n\
!       Shift Meta <Key>n:      forward-paragraph(extend)\n\
!       Shift Alt <Key>f:       forward-word(extend)\n\
!       Shift Meta <Key>f:      forward-word(extend)\n\
!       Alt <Key>d:             kill-next-word()\n\
!       Meta <Key>d:            kill-next-word()\n\
!       Alt <Key>h:             select-all()\n\
!       Meta <Key>h:            select-all()\n\

Similar sets of translations have been suggested by others.

-----------------------------------------------------------------------------
Subject: 46)  How can I use a file as the text source for a Text widget?

Answer: You can't do it directly like you can with the Athena Text widget.
Instead, read the text from the file into a string (all of it!) and then use
XmTextSetString.  Alternatively, read blocks of characters and add them at the
end of the text using XmTextInsertString.  The following is an excerpt from
Dan Heller's "file_browser.c":

    /* file_browser.c -- use a ScrolledText object to view the
     * contents of arbitrary files chosen by the user from a
     * FileSelectionDialog or from a single-line text widget.
     */

    ...
    struct stat statb;

    /* make sure the file is a regular text file and open it */
    if (stat(filename, &statb) == -1 ||
            (statb.st_mode & S_IFMT) != S_IFREG ||
            !(fp = fopen(filename, "r"))) {
        if ((statb.st_mode & S_IFMT) == S_IFREG)
            perror(filename); /* send to stderr why we can't read it */
        else
            fprintf(stderr, "%s: not a regular file0, filename);
        XtFree(filename);
        return;
    }

    /* put the contents of the file in the Text widget by allocating
     * enough space for the entire file, reading the file into the
     * allocated space, and using XmTextFieldSetString() to show the file.
     */
    if (!(text = XtMalloc((unsigned)(statb.st_size+1)))) {
        fprintf(stderr, "Can't alloc enough space for %s", filename);
        XtFree(filename);
        fclose(fp);
        return;
    }

    if (!fread(text, sizeof(char), statb.st_size+1, fp))
        fprintf(stderr, "Warning: may not have read entire file!0);

    text[statb.st_size] = 0; /* be sure to NULL-terminate */

    /* insert file contents in Text widget */
    XmTextSetString(text_w, text);




-----------------------------------------------------------------------------
Subject: 47)  How can put Text in overstrike mode instead of insert?

Answer: There is no direct way. This was posted by Edmond Pitt
(ejp@bohra.cpg.oz) The correct answer to the question is to put the following
in a modifyVerify callback, where 'mvcb' is the XmTextVerifyCallbackStruct,
and 'overstriking' is defined by you:

    if (overstriking && mvcb->text->length == 1)
    {
        _XmTextDisableRedisplay(w,FALSE);
        XtCallActionProc(w,"delete-next-character",mvcb->event,0);
        _XmTextEnableRedisplay(w);
    }

_XmText{Dis,En}ableRedisplay() are XmText{Dis,En}ableRedisplay() in 1.0, but
X11R3 has no XtCallActionProc() anyway. For this environment you need my 1.0.3
Text widget patches posted last year & available on request.


-----------------------------------------------------------------------------
Subject: 48)  How can I make the Delete key do a backspace?

Answer: Put this in your .Xdefaults

    *XmText.translations: #override <Key>osfDelete: delete-previous-character()


-----------------------------------------------------------------------------
Subject: 49)  TOPIC: LIST WIDGET

-----------------------------------------------------------------------------
Subject: 50) 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.  thanks to Ken Lee,
klee@synoptics.com

-----------------------------------------------------------------------------
Subject: 51)  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);

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: 52)  Can I have strings with different fonts in a list?

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


-----------------------------------------------------------------------------
Subject: 53)  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.

Answer: No. 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: 54)  Can I have items with different colours in a list?

Answer: No.  The list contains XmStrings, and these only allow text in various
character sets. Since the items are XmStrings, you can already change the font
of an item by replacing it with an item with the same text and a different
charset tag.  Adding support for color would require modification of the
internal data structure in XmList as well as modification to the drawing
routines.  A possible workaround is to use a rowcolumn of buttons which can be
individually set.  However, you would have to do all list functionality
yourself.


-----------------------------------------------------------------------------
Subject: 55)  Can I grey out an item in a list?  I want to make insensitive
items in a list so that they cannot be selected.

Answer:

From W. Scott Meeks of OSF:

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.

-----------------------------------------------------------------------------
Subject: 56)  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: 57)  How can I tell the position of selected items in a list?

[Last modified: Oct 92]

Answer: From  W. Scott Meeks:

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: 58)  TOPIC: FILE SELECTION BOX WIDGET

-----------------------------------------------------------------------------
Subject: 59)  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.

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.

-----------------------------------------------------------------------------
Subject: 60)  What are these compile errors: Undefined symbol _regcmp and
_regex?

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


-----------------------------------------------------------------------------
Subject: 61)  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.


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

-----------------------------------------------------------------------------
Subject: 62)  TOPIC: FORM WIDGET


-----------------------------------------------------------------------------
Subject: 63)  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.

From db@sunbim.be (Danny Backx)

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: 64)  How can I center a widget in a form?

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.

 b.  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 <Xm/BulletinB.h>
     #include <Xm/PushBG.h>

     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);
         XtOverrideTranslations(bboard,
             XtParseTranslationTable("<Configure>: 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);
     }

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

-----------------------------------------------------------------------------
Subject: 65)  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 <Xm/PushB.h>
#include <Xm/PushBG.h>
#include <Xm/LabelG.h>
#include <Xm/Text.h>
#include <Xm/Form.h>

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 <Xm/LabelG.h>
#include <Xm/RowColumn.h>
#include <Xm/Text.h>

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: 66)  TOPIC: PUSHBUTTON WIDGET

-----------------------------------------------------------------------------
Subject: 67)  Why can't I use accelerators on buttons not in a menu?

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


From albrecht@igpm.rwth-aachen.de Thu Jul  8 11:44:21 1993

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
<MAlt>+<key>. 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


-----------------------------------------------------------------------------
Subject: 68)  TOPIC: LABEL WIDGET

-----------------------------------------------------------------------------
Subject: 69)  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 row column, and XmNisAligned is True (the default), the row column 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: 70)  Why doesn't label alignment work in a RowColumn?

Answer: RowColumn 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: 71)  How can I set a multiline label?
[Last modified: September 92]

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;
      sprintf(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.  However,
XmStringCreateLtoR() is obsoleted from version 1.1 on, and may disappear.
This is because it it is only in the AES as "trial-use" and has been proposed
for removal from the AES. Realistically, it will probably not be removed from
any backward compatible versions of Motif, but the potential is there.  If it
does disappear (or if you want to avoid using the non-AES compliant
XmSTRING_DEFAULT_CHARSET), try this from Jean-Philippe Martin-Flatin
<syj@ecmwf.co.uk>

#include <Xm/Xm.h>
#include <string.h>

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

    This function can deal with embedded 'newline' and
    is equivalent to the obsolete 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      = XmStringCreateSimple(p);

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

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


Do not use XmStringCreateSimple() - it does not process the newline character
in the way you want.

In UIL, you have to explicitly create a compound string with a separator.
Here's what W. Scott Meeks suggests:

value nl : compound_string('', seperate=true);

object my_label : XmLabel
{
    arguments
    {
        XmNlabelString = 'Here' & nl & 'is' & nl & 'the' & nl & 'Label';
    };
};


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

Answer: Make a multiline 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: 73)  How can I have a Pixmap in a Label?

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

    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: 74)  TOPIC: DRAWING AREA WIDGET

-----------------------------------------------------------------------------
Subject: 75)  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.

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);


-----------------------------------------------------------------------------
Subject: 76)  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: 77)  TOPIC: MENUS

-----------------------------------------------------------------------------
Subject: 78)  What can I put inside a menu bar?

Answer: You can only put cascade buttons in menu bars. No pushbuttons, toggle
buttons or gadgets are allowed. When you create a pulldown menu with parent a
menu bar, its real parent is a shell widget.

-----------------------------------------------------------------------------
Subject: 79)  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: 80)  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: 81)  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, "<Btn3Down>"); 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 %d0, event->button);

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



-----------------------------------------------------------------------------
Subject: 82)  How do popup menus work?
[Last modified: August 92]

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 5 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: 83)  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: 84)  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: 85)  Can I have multiple popup menus on the same widget?
[Last modified: August 92]

Answer: 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: 86)  TOPIC: INPUT FOCUS

-----------------------------------------------------------------------------
Subject: 87) How can I specify the widget that should have the keyboard focus
when my application starts up?  Answer: In Motif 1.2, use XmNinitialFocus on
the manager widget.  thanks to Ken Lee, klee@synoptics.com


-----------------------------------------------------------------------------
Subject: 88)  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: 89)  How can I have a modal dialog which has to be answered before
the application can continue?
[Last modified: July 92]

Answer: 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 <X11/Intrinsic.h>
#include <Xm/DialogS.h>
#include <Xm/SelectioB.h>
#include <Xm/RowColumn.h>
#include <Xm/MessageB.h>
#include <Xm/PushBG.h>
#include <Xm/PushB.h>

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 = XmStringCreateSimple("/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 = XmStringCreateSimple("Yes");
        no = XmStringCreateSimple("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: */
        XtAddCallback(dialog, XmNpopdownCallback, response, &answer);
    }
    text = XmStringCreateSimple(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: 90)  TOPIC: MEMORY AND SPEED

-----------------------------------------------------------------------------
Subject: 91)  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.  thanks to klee*synoptics.com
(Ken Lee)

-----------------------------------------------------------------------------
Subject: 92)  Why does my application grow in size?

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

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,
     XmStringCreateSimple, 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: From Josef Nelissen: 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: 93)  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: 94)  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.



-----------------------------------------------------------------------------
Subject: 95)  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.

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


-----------------------------------------------------------------------------
Subject: 96)  TOPIC: XMSTRING

-----------------------------------------------------------------------------
Subject: 97)  How can I get the Ascii text out of an XmString?

Answer: To get the first line of text from a string created left-to-right


        char *str;
        XmString xmstr;

        /* stuff to create xmstr */
        ...

        /* set str to point to the text */
        XmStringGetLtoR(xmstr, XmSTRING_DEFAULT_CHARSET, &str);
        /* use the string */
        ...

        /* and reclaim space */
        XtFree(str);


-----------------------------------------------------------------------------
Subject: 98)  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: 99)  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: 100)  Why does using XmStringDraw cause a Bad Font error?

[Last modified: May 93]

Answer: From Thomas Berlage (berlage@gmdzi.gmd.de): 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"));




-----------------------------------------------------------------------------
Subject: 101)  TOPIC: DIALOGS

-----------------------------------------------------------------------------
Subject: 102)  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: 103)  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: 104)  How come the title bars for my dialogs now 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: 105)  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?

Answer: 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: 106)  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?

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 <Xm/MessageB.h>
#include <Xm/PushB.h>

/* 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 = XmStringCreateSimple(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: 107)  TOPIC: LANGUAGE BINDINGS

-----------------------------------------------------------------------------
Subject: 108)* Is there a C++ binding for Motif?

[Last modified: May 93]


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

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

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

        export.lcs.mit.edu (18.30.0.238   contrib/WWL-1.0.tar.Z
        lri.lri.fr (129.175.15.1)      pub/WWL-1.0.tar.Z


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

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

An object license is $795 "per seat" and a source code license is available
for $2,995 "per seat."  Rogue Wave also offers full support for View.h++.

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

For additional information, please contact:

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

email:   matts@roguewave.com


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

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



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

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

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


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

Availability:

Anonymous ftp at decuac.dec.com (192.5.214.1), directory /pub/X11,
file motif++.28.jul.93.tar.Z

For more information, contact Ronald van Loon (rvloon@motif.hacktic.nl).
There is also mailing list for Motif++. Send e-mail to

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

Xm++ is available on: export.lcs.mit.edu as: /contrib/Xm++.0.5.tar.Z

Answer: The Solbourne OI toolkit (not Motif) also has a C++ binding.

Answer: Liant have C++/Views.

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

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


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

Answer: Unfortunately, this library (last released in 9/92) has the same name
as the one by Ronald van Loon (rvloon@motif.hacktic.nl).

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

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

-----------------------------------------------------------------------------
Subject: 109)  How can I have a C++ member function in a callback?

[Last modified: October 93]
Answer: There are three common user problems with C++ callbacks.  First, make
sure you use the correct function prototype for the function declarations.
Second, the callback function must be declared as a static member of the
class.  Third, when registering it with XtAddCallback(), you must use its full
signature.  For example: (Ken Lee klee@synoptics.com)

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

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


Motif++ has a nice tutorial summarising mechanisms (this is available
separately by email from Ronald van Loon (rvloon@motif.hacktic.nl)). Doug
Young's book deals extensively with one of these. The problem is that you
don't get the object when you just use the function as a callback.  You need
to pass the object as a pointer through as the client_data.  (use "this" as
the client_data.) Then you can retrieve the object's address, and dereference
from there. For example (Leo O'Donnell, Email: leo@avs.com),

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

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

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



-----------------------------------------------------------------------------
Subject: 110)  Is there a Common Lisp binding for Motif?

[Last modified: November 92]

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

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

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


-----------------------------------------------------------------------------
Subject: 111)* Is there an Ada binding for Motif?

[Last modified: Apr 94 ]

Answer:

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

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



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

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

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

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

The file is ASCII.

------ Included File


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

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


12.1  Description and Standardization Efforts

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

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

12.2  Resources Available from Software Reuse Libraries/Repositories


ASSET                                                      (Updated:  November
1 992)

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


INTERFACE TO THE X WINDOW SYSTEM

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

DESCRIPTION       :

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

12.3  Products Available from Vendors


Advanced Technology Center                                 (Updated:  November
1 992)

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

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

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

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


Alsys, Inc.                                                     (Updated:  May
1 992)

The Alsys Ada Software Development Environment (Alsys's validated Ada compiler
#901221W1.11103) for 386 UNIX is a production-quality Ada environment capable
of handling very large Ada applications (over 500,000 lines of code).  The
product includes the Compiler; Multi-Library Environment, which provides a
powerful and flexible way to manage Ada development effort and share program
units; Binder, which supports unused subprograms elimination; High-and Low-
Level Optimizers for improving code quality and performance; and Run-Time
Executive for efficient support for executing Ada programs.  Also included is
the Developer's Toolset including:  Ada Probe, a symbolic source level
debugger and program viewer; AdaXref, a cross-reference generator; AdaMake, a
recompilation aid; AdaReformat, a source reformatter.

Alsys currently has Ada bindings to POSIX, X-Windows (OSF Motif), and the
Generic Package of Elementary Functions for the Alsys Ada Software Development
Environment, running on 386 UNIX 386/486-based machines supported as both host
and target and running 386/ix or SCO UNIX.  They are also planning a binding
to SQL for  386/486 machines.

Host/Target:386/486 PC under IX UNIX, 386/486 PC under SCO UNIX

The Alsys Ada Software Development Environment for the IBM RS/6000 is a
production-quality Ada environment capable of handling very large Ada
applications.  Hosted on and targeted to the IBM RS/6000 workstation under
IBM's AIX operating system, the product includes the Compiler; Multi-Library
Environment, which provides a  powerful and flexible way to manage Ada
development efforts and share program units; Binder; Run-Time Executive; and
both a High and Low-Level Optimizer for improving code quality and
performance.  Also included is the Alsys Ada Toolset including Ada Probe,
symbolic source level debugger and program viewer; AdaXref, cross-reference
generator; AdaMake, recompilation aid; and AdaReformat, source reformatter.

Alsys has bindings currently available to the Generic Package of Elementary
Functions and to X-Windows (OSF Motif) for the Alsys Ada Development
Environment for the IBM RS/6000 running on any RISC System/6000 machine as
both host and target and running IBM's AIX operating system (Alsys's validated
Ada compiler #910809W1.11195).   Alsys also plans to develop a POSIX binding
for the RS/6000.

Host/Target:RISC System/6000 under AIX

The Alsys Ada Software Development Environment for SPARC Workstations is a
production-quality Ada environment capable of handling very large Ada
applications.  Hosted on any SPARC-based workstation under SunOS or SunView,
the product helps you realize the full potential of Ada on SPARC machines. The
product includes the Compiler (with High- and Low-Level Optimizers); Binder,
which supports unused subprogram elimination; Multi-Library system (Family,
Library, and Unit Managers) which provides a powerful and flexible way to
manage Ada development efforts and share program units;  AdaExec real-time
executive, for complete and efficient support for executing Ada programs; and
ISO-standard mathematical library.  Also included is the Alsys Ada Toolset
including AdaProbe, symbolic source level debugger and program viewer;
AdaXref, cross-reference  generator; AdaMake, recompilation aid; and
AdaReformat, source reformatter.

Bindings to the Generic Package of Elementary Functions and to OSF/Motif are
currently available for the Alsys Ada Software Development Environment running
on any SPARC-based Workstation as both host and target and running SunOS or
SunView.

Host/Target:SPARC under SUNOS

For more information, contact:Scott Garren, Alsys, Inc., 67 South Bedford
                        Street, Burlington, MA  01803-5152, USA;  Phone:
                        (617) 270-0030


Digital Equipment Corporation                              (Updated:  November
1 992)

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

Host/Target:DEC VAX under VMS

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


IBM                                                        (Updated:  November
1 992)

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


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

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

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

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

Objective Interface Systems, Inc.                          (Updated:  November
1 992)

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

Host/Target:

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

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


SL Corporation                                              (Updated: November
1 992)

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

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

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

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


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

      IBM-RS6000/AIX

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

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

      SGI-4D/IRIX 3.3

      Sun-3/SunOS 4.1         SunSPARC/SunOS 4.1

      88 Open/BCS Compliant

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


Sunrise Software International                                  (Updated:  May
1 992)

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

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


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

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

Systems Engineering Research Corporation (SERC)            (Updated:  November
1 992)

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

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


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

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


TeleSoft                                                   (Updated:  November
1 992)

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

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

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


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

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

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

Verdix                                                          (Updated:  May
1 992)

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

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

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

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

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

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

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



-----------------------------------------------------------------------------
Subject: 112)  Is there a Poplog binding for Motif?

[Last modified: May]

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

Contact:

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



-----------------------------------------------------------------------------
Subject: 113)  TOPIC: SPECIFIC PLATFORMS

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

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


-----------------------------------------------------------------------------
Subject: 115)  How do I build Motif 1.2.2 on Solaris 2.1 with Sun C?

[Last modified: May 93]

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

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

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

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

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

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

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

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


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


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

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

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

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

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

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

        openwin -server /usr/X11R5/bin/Xsun


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

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


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

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

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


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

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

Answer:


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

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


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

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


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



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

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

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


-----------------------------------------------------------------------------
Subject: 119)  The OpenWindows server hangs when I popup a menu with Button 3.
[Last modified: August 92]

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

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

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

        XtFoo() -> vendorShellClassRec

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

        XmBar() -> vendorShellClassRec

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

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

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

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

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


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

Answer: Compile  XmString.c with STRINGS_ALIGNED.

-----------------------------------------------------------------------------
Subject: 122)  TOPIC: KEYSYMS

-----------------------------------------------------------------------------
Subject: 123)  What is causing the messages "unknown keysym osfDown..."?  It
happens when I run an application under Motif 1.1

Answer: There is an OSF supplied addition to the /usr/lib/X11/XKeysymDB file.
It is found on the release tape and should have been automatically installed
if the installation procedure was followed in the Release Notes.

You have to copy (or append) lib/Xm/XKeysymDB into /usr/lib/X11.  This may
require root permission.  It is not clear how to fix the problem if you can't
do this.  The error comes from Xt translation table parsing and can't be fixed
in Motif, so if you can't get root permission you may be stuck.  The file is
not copyrighted so you can install it on other systems.

If X has been built so that XKeysymDB is not in this directory, and you don't
know where it is looking, run 'strings libX11.a | grep XKeysymDB' to find the
path.

On a Sun running openwin with shared libraries, you may need to put the path
for the library containing XKeysymDB *first* in the path list in
LD_LIBRARY_PATH, or it may find the wrong XKeysymDB in the wrong directory.

XKeysymDB simply contains the registered keysym values for the OSF keysyms.
The OSF values are server-independent.  And, all registered keysyms will be
included in an XKeysymDB file to be shipped with X11R5.

In the meantime (till all systems are X11R5+), a list of the registered
keysyms can be found in the X11R4 release in mit/doc/Registry/Xregistry.

Also note the XKEYSYMDB environment variable. Setting this to point to the
XKeysymDB file often helps, but not always...


-----------------------------------------------------------------------------
Subject: 124)  What happens if I can't install Motif Keysyms?

From: tessi!george@nosun.West.Sun.COM (George Mitchell)

Here's what appears to happen if you don't have XKeysymDB in place to define
OSF's virtual keysyms:

1. At class initialize time, for a widget (such as XmText) that uses virtual
keysyms in its event translation table, all entries which refer to those
keysyms fail to parse correctly.  In the case of XmText, instead of ending up
with a translation table with roughly 90 entries, you end up with one that has
29.

2. XKeysymDB doesn't exist, so you'd assume that KeyPress events will get
translated to plain vanilla keysyms, right?  WRONG!  All Motif widgets install
a virtual keysym translator ANYWAY!  Consequently, the backspace key (for
example) gets translated to the keysym osfBackSpace.

3. Therefore, if you augment or override your widget's translations with
translations that refer to plain vanilla BackSpace, they will never be
triggered, because you will NEVER see plain vanilla BackSpace, only
osfBackSpace.

4. But you can't use osfBackSpace in an event translation entry, because you
don't have XKeysymDB installed!

Here's how I'm "dealing" with the problem right now: Motif installs its
virtual keysym translator by calling XtSetKeyTranslator every time a
VendorShell (or subclass) widget is created.  So every time I create a shell,
I immediately call XtSetKeyTranslator (display, XtTranslateKey) to restore the
default translator.  No more funny virtual keysyms!  Now I can reinstall non-
osfKeySym translations and have them work the way I expect.


-----------------------------------------------------------------------------
Subject: 125)  Why has OSF introduced Keysyms into Motif 1.1?  They weren't
there in Motif 1.0.

Answer: From: ellis@osf.org

Virtual Keysyms are meant to provide a consistent keyboard model for Motif
applications running in a heterogeneous environment in which proprietary (i.e.
vendor specific) non-Motif applications may also be running.

First of all, for the sake of the rest of the readers, let's explain why this
is an issue:

It would be lovely if Motif's translation tables could just use the obvious
keysyms predefined by X.  For example, there are keysyms for XK_BackSpace,
XK_Delete, XK_Left, XK_Right, etc.  Shouldn't these be the ones that are used
in our translations?  Unfortunately, the problem is not so simple.  Some
specific examples:

   While most vendors bind XK_BackSpace to the key at the top right
   of the standard keyboard (often engraved with a leftwards
   pointing arrow), not all do.  In fact, some vendors (including DEC)
   bind that key to XK_Delete.

   While most vendors bind the arrow keys to XK_Up, etc, a number of
   vendors (including Sun, on some servers) bind them to function key
   keysyms.

A simplistic solution would require the use of xmodmap to change the offending
bindings.  That would work swell in an all Motif environment.  However, OSF's
goal (not always perfectly achieved) is interoperability.  That is, we'd like
to make sure that both Motif and non-Motif programs can happily run in the
same environment.

It is expected that a vendor may have a wide variety of existing X-based
software that uses the keysyms as established by that vendor for specific
purposes.  It is expected that these applications may run at the same time as
Motif-based software.  Using xmodmap to change keysyms on the server side
could "break" the existing applications (or at the very least their
documentation) by making some keys unavailable, or by moving the location.

So, we chose not to use xmodmap.  By the way, though OpenLook uses a different
implementation (they recompile their virtual translation tables into actual
translation tables), they basically adopted the same approach, presumably for
similar reasons.

To work properly, the virtual keysym model we implemented depends on Xlib
finding XKeysymDB installed appropriately (which standard Motif installation
does).  This simply defines the keysyms (not the key they are bound to).  This
unfortunate piece of stupidity is necessary because MIT only includes standard
keysyms in keysymdef.h.  It should be said that our lives would be made easier
if MIT would also see fit to include registered keysyms in keysymdef.h as
well.

Motif applications determine how to bind virtual to actual keys by looking for
either a resource or a property on the root window which describes what to do.
Note that this information is on the server side, so that all applications use
the same virtual bindings regardless of where they are running.  Mwm will
happily create the property if it finds a .motifbind file in your home
directory when it starts up.  (Actually, things generally work even if none of
this is done, since if all else fails, the Motif toolkit chooses a virtual
bindings table to use based on the identification of the server).

The actual implementation of virtual keys is made possible by a hook in the
Intrinsics.  Undoubtably, the implementation would be simpler and cleaner if
virtual key support was more directly supported by the Intrinsics.  We will be
exploring this possibility in the future.

  -- Ellis

-----------------------------------------------------------------------------
END OF PART FOUR

-----------------------------------------------------------------------------
Subject: 126)  TOPIC: ICONS

Iconification/de-iconification is a co-operative process between a client and
a window manager.  The relevant standards are set by ICCCM.  Mwm is ICCCM
compliant.  The toplevel (non-override-redirect) windows of an application may
be in three states: WithdrawnState (neither the window nor icon visible),
NormalState (the window visible) or IconicState (the icon window or pixmap
visible).  This information is contained in the WM_STATE property but ordinary
clients are not supposed to look at that (its values have not yet been
standardised).  Movement between the three states is standardised by ICCCM.

-----------------------------------------------------------------------------
Subject: 127)  How can I keep track of changes to iconic/normal window state?

Answer: You can look at the WM_STATE property, but this breaks ICCCM
guidelines.  ICCCM compliant window managers will map windows in changing them
to normal state and unmap them in changing them to iconic state. Look for
StructureNotify events and check the event type:

        XtAddEventHandler (toplevel_widget,
                        StructureNotifyMask,
                        False,
                        StateWatcher,
                        (Opaque) NULL);
        ....
        void StateWatcher (w, unused, event)
        Widget w;
        caddr_t unused;
        XEvent *event;
        {
                if (event->type == MapNotify)
                        printf ("normal\n");
                else if (event->type == UnmapNotify)
                        printf ("iconified\n");
                else    printf ("other event\n");
        }


If you insist on looking at WM_STATE, here is some code (from Ken Sall) to do
it:

        /*
        ------------------------------------------------------------------
        Try a function such as CheckWinMgrState below which returns one of
        IconicState | NormalState | WithdrawnState | NULL :
        ------------------------------------------------------------------
        */
        #define WM_STATE_ELEMENTS 1

        unsigned long *CheckWinMgrState (dpy, window)
        Display *dpy;
        Window window;
        {
          unsigned long *property = NULL;
          unsigned long nitems;
          unsigned long leftover;
          Atom xa_WM_STATE, actual_type;
          int actual_format;
          int status;

            xa_WM_STATE = XInternAtom (dpy, "WM_STATE", False);

            status = XGetWindowProperty (dpy, window,
                          xa_WM_STATE, 0L, WM_STATE_ELEMENTS,
                          False, xa_WM_STATE, &actual_type, &actual_format,
                          &nitems, &leftover, (unsigned char **)&property);

            if ( ! ((status == Success) &&
                        (actual_type == xa_WM_STATE) &&
                        (nitems == WM_STATE_ELEMENTS)))
                {
                if (property)
                    {
                    XFree ((char *)property);
                    property = NULL;
                    }
                }
            return (property);
        } /* end CheckWinMgrState */


-----------------------------------------------------------------------------
Subject: 128)  How can I check if my application has come up iconic?  I want
to delay initialisation code and other processing.

Answer: Use XtGetValues and check for the XmNinitialState value of the
toplevel shell just before XtMainLoop. -- IconicState is iconic, NormalState
is not iconic.




-----------------------------------------------------------------------------
Subject: 129)  How can I start my application in iconic state?

Answer: From the command line

        application -iconic

Using the resource mechanism, set the resource XmNinitialState to IconicState
of the toplevel shell widget (the one returned from XtInitialise).

-----------------------------------------------------------------------------
Subject: 130)  How can an application iconify itself?

Answer: In R4 and later, use the call XIconifyWindow.

For R3, send an event to the root window with a type of WM_CHANGE_STATE and
data IconicState.

        void
        IconifyMe (dpy, win)
        Display *dpy;
        Window win;     /* toplevel window to iconify */
        {
                Atom xa_WM_CHANGE_STATE;
                XClientMessageEvent ev;

                xa_WM_CHANGE_STATE = XInternAtom (dpy,
                                        "WM_CHANGE_STATE", False);

                ev.type = ClientMessage;
                ev.display = dpy;
                ev.message_type = xa_WM_CHANGE_STATE;
                ev.format = 32;
                ev.data.l[0] = IconicState;
                ev.window = win;

                XSendEvent (dpy,
                        RootWindow (dpy, DefaultScreen(dpy)),
                        True,
                        (SubstructureRedirectMask | SubstructureNotifyMask),
                        &ev);
                XFlush (dpy);
        }


-----------------------------------------------------------------------------
Subject: 131)  How can an application de-iconify itself?

Answer: XMapWindow (XtDisplay (toplevel_widget), XtWindow (toplevel_widget)).

-----------------------------------------------------------------------------
Subject: 132)  TOPIC: MISCELLANEOUS

-----------------------------------------------------------------------------
Subject: 133)+ How do I controll the repeat rate on a SUN keyboard ??


Answer:

     [...]

     -ar1 milliseconds
             This option specifies amount of time in milliseconds
             before   which   a   pressed  key  should  begin  to
             autorepeat.

     -ar2 milliseconds
             This option specifies the interval  in  milliseconds
             between autorepeats of pressed keys.

Of course this presumes you're using a server based on the MIT sample server.
submitted by: kaleb@x.org (Kaleb Keithley)

-----------------------------------------------------------------------------
Subject: 134)  How can I identify the children of a manager widget?

Answer: XmNnumChildren (number of widgets in array).

-----------------------------------------------------------------------------
Subject: 135)  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).

thanks to Ken Lee, klee@synoptics.com

-----------------------------------------------------------------------------
Subject: 136)  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".

thanks to Ken Lee, klee@synoptics.com

-----------------------------------------------------------------------------
Subject: 137)  What functions can an application use to change the size or
position of a widget?

Answer: Applications should set the values of the XmNx, XmNy, XmNwidth, and
XmNheight resources.

Note that many manager widgets ignore the XmNx and XmNy resources of their
children, relying instead on their internal layout algorithms.  If you really
want specific positions, you must use a manager widget that allows them, e.g.,
XmBulletinBoard.

Also note that some manager widgets reject size change requests from their
children when certain resources are set (e.g., XmNresizable on XmForm).
Others allow the the children to resize, but clip the results (e.g.,
XmNallowShellResize on shell widgets).  Make sure you have these resources set
to the policy you want.

Due to bugs, some widgets (third party widgets) do not respond to changes in
their width and height.  Sometimes, you can get them to respond correctly by
unmanaging them, setting the resources, then managing them again.

Under no circumstances should applications use routines like
XtConfigureWidget() or XtResizeWidget().  These routines are reserved for
widget internals and will seriously confuse many widgets.  _ thanks to Ken
Lee, klee@synoptics.com ----------
-------------------------------------------------------------------
Subject: 138)  What widgets should I use to get the look of push buttons, but
the behaviour of toggle buttons?

Answer:
  Use the XmToggleButton widget, setting XmNindicatorOn to False and
XmNshadowThickness to 2.

thanks to Ken Lee, klee@synoptics.com ----------
-------------------------------------------------------------------
Subject: 139)+ How do I obtain the size of a unmanaged shell widget?

Answer: In the code below, use getsize() for widgets which have been managed,
and getsize2() for newly created shell widgets which have not yet been
managed.

getsize2() takes two widget parameters because popup dialogs etc.  _consist_
of two separate widgets - the parent shell and the child bulletin board, form,
whatever.  This important distinction (somewhat glossed over in the Motif
manuals) is the cause of a large number of queries in comp.windows.x.motif.
XmCreate...Dialog() functions return the (bulletin board, form, whatever)
_child_ of the pair, not the parent shell.

getsize2() takes the _shell_ widget as it's first parameter, and the shell's
_child_ (the bulletin board, form, whatever) as it's second.  Thus, if you are
using code like widget = XmCreate...Dialog() to create your popup dialogs, use
code like getsize2(XtParent(widget),widget,&width,&height) to get the width
and height. If you use e.g. XmCreateDialogShell() or XtCreatePopupShell(),
then you are creating the the shell widget and it's child explicitly, and can
just pass them into getsize2() with no problem.

Note: getsize2() calls getsize().

/* getsize(widget,width,height);
 * Widget widget;
 * int *width,*height;
 *
 * returns the width and height of a managed widget */




void getsize(l,w,h) Widget l; int *w,*h; { Dimension w_,h_,b_;

static Arg size_args[] =
  {
  { XmNwidth,0 },
  { XmNheight,0 },
  { XmNborderWidth,0 },
  };

size_args[0].value = (XtArgVal)&w_; size_args[1].value = (XtArgVal)&h_;
size_args[2].value = (XtArgVal)&b_;

XtGetValues(l,size_args,3);

if (w) *w = w_ + b_; if (h) *h = h_ + b_; } /*
getsize2(shell,child,width,height);
 * Widget shell,child;
 * int *width,*height;
 *
 * returns the width, height of an unmanaged shell widget */

void getsize2(p,c,w,h) Widget p,c; int *w,*h; { XtSetMappedWhenManaged(p,0);

XtManageChild(c);

getsize(p,w,h);

XtUnmanageChild(c);

XtSetMappedWhenManaged(p,-1); } submitted by: [ Huw Rogers  Communications
Software Engineer, NEC Corporation, Tokyo, Japan ] [ Email:
rogersh@ccs.mt.nec.co.jp  Fax: +81-3-5476-1005  Tel: +81-3-5476-1096 ]

-----------------------------------------------------------------------------
Subject: 140)  Can I use XtAddTimeOut(), XtAddWorkProc(), and XtAddInput()
with XtAppMainLoop()?

Answer: On many systems, the obsolete XtAdd*() functions are not compatible
with the XtAppMainLoop().  Instead, you should use newer XtAppAddTimeOut(),
XtAppAddWorkProc(), and XtAppAddInput() functions with XtAppMainLoop()

thanks to Ken Lee, klee@synoptics.com ----------
-------------------------------------------------------------------
Subject: 141)  Why does XtGetValues() XmNx and XmNwidth return extremely large
values.

Answer: You must use the 16 bit "Dimension" and "Position" data types for your
arguments.  If you use 32 bit integers, some implementations will fill the
remaining 16 bits with invalid data, causing incorrect return values.  The
*Motif Programmer's Manual* and the widget man pages specify the correct data
type for each resource.

thanks to Ken Lee, klee@synoptics.com ----------
-------------------------------------------------------------------
Subject: 142)  Can I specify callback functions in resource files?

Answer: To specify callbacks, you must use UIL in addition to or in place of
resource files.  You can, however, specify translations in resource files,
which give you most of the same functionality as callback functions.

thanks to Ken Lee, klee@synoptics.com ----------
-------------------------------------------------------------------
Subject: 143)  How do I specify a search path for ".uid" files?  Answer: Use
the UIDPATH environment variable.  It is documented on the MrmOpenHierarchy()
man page.

-----------------------------------------------------------------------------
Subject: 144)  XtGetValues() on XmNx and XmNy of my top level shell don't
return the correct root window coordinates.  How do I compute these?

Answer: 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() or XTranslateCoordinates().

thanks to Ken Lee, klee@synoptics.com ----------
-------------------------------------------------------------------
Subject: 145)  Can I use XmGetPixmap() with widgets that have non-default
visual types?

Answer: If you're using a different depth, use XmGetPixmapByDepth() instead.

 thanks to Ken Lee, klee@synoptics.com ----------
-------------------------------------------------------------------
Subject: 146)  How can I determine the item selected in a option menu or a
RadioBox?

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.  thanks to Ken Lee, klee@synoptics.com

-----------------------------------------------------------------------------
Subject: 147)  What is the matter with Frame in Motif 1.2?

[Last modified: November 92]

Answer: This announcement has been made by OSF:

"IMPORTANT NOTICE

We have discovered two problems in the new 1.2 child alignment resources in
XmFrame. Because some vendors may have committed, or are soon to commit to
field releases of Motif 1.2 and 1.2.1, OSF's options for fixing them are
limited. We are trying to deal with these in a way that does not cause
hardship for application developers who will develop applications against
various point versions of Motif. OSF's future actions for correction are
summarized.

WHAT YOU SHOULD DO AND KNOW

1. Mark the following change in your documentation.

On page 1-512 of the OSF/Motif Programmer's Reference, change the descriptions
under XmNchildVerticalAlignment as follows (what follows is the CORRECT
wording to match the current implementation):

XmALIGNMENT_WIDGET_TOP
        Causes the BOTTOM edge of the title area to align
        vertically with the top shadow of the Frame.

XmALIGNMENT_WIDGET_BOTTOM
        Causes the TOP edge of the title area to align
        vertically with the top shadow of the Frame.

2. Note the following limitation on resource converters for Motif 1.2 and
1.2.1 implementations.

The rep types for XmFrame's XmNentryVerticalAlignment resource were
incorrected implemented, which means that converters will not work properly.
The following resource settings will not work from a resource file in 1.2 and
1.2.1:

        *childVerticalAlignment: alignment_baseline_bottom
        *childVerticalAlignment: alignment_baseline_top
        *childVerticalAlignment: alignment_widget_bottom
        *childVerticalAlignment: alignment_widget_top

If you wish to set these values for these resources (note they are new
constraint resources in XmFrame) you will have to set them directly in C or
via uil.

WHAT WE WILL DO

The problem described in note #1 above will not be fixed in the OSF/Motif
implementation until the next MAJOR release of Motif.  At that time we will
correct the documentation and modify the code to match those new descriptions,
but we will preserve the existing enumerated values and their behavior for
backward compatibility for that release.

The fix for the problem described in note #2 will be shipped by OSF in Motif
1.2.2.

SUMMARY

We are sorry for any difficulty this causes Motif users.  If you have any
questions or flames (I suppose I deserve it) please send them directly to me.
We sincerely hope this proactive response is better for our customers than you
having to figure it out yourselves!

Libby


-----------------------------------------------------------------------------
Subject: 148)  What is IMUG and how do I join it?

Answer: IMUG is the International Motif User Group founded by Quest Windows
Corporation and co-sponsored by FedUNIX.  IMUG is a non-profit organization
working to keep users informed on technical and standards issues, to
strengthen user groups on a local level, to increase communication among users
internationally, and to promote the use of an international conference as a
forum for sharing and learning more about Motif.  You can join it by

 1.  Pay the annual membership fee of $20 USD directly to IMUG.  Contact

     IMUG
     5200 Great America Parkway
     Santa Clara,  CA  95054
     (408) 496-1900
     imug@quest.com

 2.  Register at the International Motif User Conference, and automatically
     become an IMUG member.

 3.  Donate a pd widget, widget tool or widget builder to the IMUG Widget
     Depository and receive a free one year IMUG membership.


-----------------------------------------------------------------------------
Subject: 149)  What is the X Professional Organization

[Last modified: JAN 02 1994]

Answer: The X Professional Organization's (XPO) purpose is to provide service
to the X community.  It will serve as an information conduit for professional
users of X.  XPO will participate in X activities, and help keep its members
informed on X related issues.

http://
In addition to the communication that professional organizations offer, XPO
provides these other benefits to members:

    * subscription to the The X Resource, a quarterly publication
      by O'Reilly & Associates, Inc.,

    * discounts on X related products, 20% off most new books

*** For a sample issue of the newsletter,
*** email  XPO@DELPHI.COM and include your surface address:

    * the XPO quarterly newsletter featuring:
         o highlights of conference activities,
         o new product information,
         o articles highlighting the latest innovations in X,
         o feedback from developers and users of X,
         o calendar of activities,
         o forum for X professionals to interact and learn,
         o and much more...

Membership Information:
Annual pricing information in US dollars.

Associate:  Quarterly newsletter
Regular: Quarterly newsletter + subscription to The X Resource
Special: Regular + The X Resource  supplemental issues

Country               Associate    Regular     Special
USA                     $35.00     $100.00     $120.00
Canada & Mexico         $40.00     $105.00     $135.00
Europe & Africa         $45.00     $125.00     $175.00
Asia & Australia        $50.00     $130.00     $185.00


Contact:  X Professional Organization, Post Office Box 78, Beltsville,
Maryland, 20704  USA

phone: (301) 681 - 2230
fax:   (410) 465 - 9918, email: XPO@DELPHI.COM

<A HREF= "http://nearnet.gnn.com/gnn/meta/internet/mkt/xpo/profile.html" XPO Company profile </a>


-----------------------------------------------------------------------------
Subject: 150)  How do I set the title of a top level window?

[Last modified: September 92]

Answer: Set XmNtitle (and optionally XmNtitleEncoding) for TopLevelShells.
(Note that this is of type String rather than XmStrin.) Ypu can also set
XmNiconName if you want its icon to show this title.  For XmDialogShells, set
the XmNdialogTitle of its immediate child, assuming it's a BulletinBoard
subclass.  These can also be set in resource files.


-----------------------------------------------------------------------------
Subject: 151)  Can I use editres with Motif?
[Last modified: January 93]

Answer: It isn't built in to Motif (at 1.2.0), but you can do this in your
application

    extern void _XEditResCheckMessages();
    ...
    XtAddEventHandler(shell_widget, (EventMask)0, True,
                        _XEditResCheckMessages, NULL);

once for each shell widget that you want to react to the "click to select
client" protocol.  Then link your client with the R5 libXmu.

David Brooks, OSF

From Marc Quinton (quinton@stna7.stna7.stna.dgac.fr):

With X11R4 see the Editres package which is a port of the X11R5 Editres
protocol and client. You can find it at :

 ftp.stna7.stna.dgac.fr(143.196.9.83):/pub/dist/Editres.tar.Z

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

Answer: From Jean-Philippe Martin-Flatin <syj@ecmwf.co.uk>

/**********************************************************************
** 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 <X11/X.h>
#include <X11/Xlib.h>
#include <X11/Xatom.h>
#include <X11/Intrinsic.h>
#include <X11/StringDefs.h>
#include <X11/Protocols.h>
#include <Xm/Xm.h>
#include <Xm/AtomMgr.h>

/*
** 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.co.uk if you
        ** find out what is going on !
        */
        AddOLWMDialogFrame(shell,(OLWM_Header | OLWM_Resize));
/*      AddOLWMDialogFrame(shell,(OLWM_Header | OLWM_Resize | OLWM_Close)); */
}


-----------------------------------------------------------------------------
Subject: 153)  Why does an augment translation appear to act as replace for
some widgets?  When I use either augment or override translations in
.Xdefaults it seems to act as replace in both Motif 1.0 and 1.1

Answer: By default, the translation table is NULL.  If there is nothing
specified (either in resource file, or in args), the widget's Initialize
finds: Oh, there is NULL in translations, lets use our default ones.  If,
however, the translations have become non-NULL, the default translations are
NOT used at all. Thus, using #augment, #override or a new table has identical
effect: defines the new translations. The only way you can augment/override
Motif's default translations is AFTER Initialize, using XtSetValues.  Note,
however, that Motif managers do play with translation tables as well ... so
that results are not always easy to predict.

From OSF: A number of people have complained about not being able to
augment/override translations from the .Xdefaults.  This is due to the
complexity of the menu system/keyboard traversal and the necessary
translations changes required to support the Motif Style Guide in menus.  It
cannot be fixed in a simple way. Fixing it requires re-design of the
menus/buttons and it is planned to be fixed in 1.2.





-----------------------------------------------------------------------------
Subject: 154)  How do you "grey" out a widget so that it cannot be activated?

Answer: Use XtSetSensitive(widget, False). Do not set the XmNsensitive
resource directly yourself (by XtSetValues) since the widget may need to talk
to parents first.


-----------------------------------------------------------------------------
Subject: 155)  Why doesn't the Help callback work on some widgets?

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

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

         ftp.uu.net:/published/oreilly/xresource/helpdemo.tar.Z

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

contributed by: Jay Schmidgall  jay@vnet.ibm.com (author of the article
mentioned above) --



-----------------------------------------------------------------------------
Subject: 156)  Where can I get a Table widget?

[Last modified: December 92]

Answer: Send email to Kee Hinckley (nazgul@alfalfa.com) asking for a copy of
his table widget.  The Widget Creation Library also has one.  See under Motif
prototyping tools for the contact.

Expert Database Systems, Inc., 377 Rector Place, Suite 3L New York, NY 10280.
Phone: (212) 783-6981 has a very comprehensive table widget that uses both
motif scrollbars or a "virtual" scrollbar showing a miniature version of the
entire spreadsheet. Allows for different width columns, changing colors in
each cell.  Only one X-Window is used so as to reduce the amount of system
resources used.  Contact Ken Jones email: ken@mr_magoo.sbi.com)


-----------------------------------------------------------------------------
Subject: 157)  Has anyone done a bar graph widget?
[Last modified: September 92]

Answer: You can fake one by using for each bar a scroll bar or even a label
which changes in size, put inside a container of some kind.

Try the StripChart widget in the Athena widget set. Set the XtNupdate resource
to 0 to keep it from automatically updating.

The comp.windows.x FAQ mentions a bar graph widget.

Expert Database Systems, Inc.  sells a bar graph widget as well as a multi-
line graph with automatic scaling, a 3-D surface graph, and a high/Low graph
with two lines for moving averages.  Contact Ken Jones Expert Database
Systems, Inc., 377 Rector Place, Suite 3L New York, NY 10280.  Phone: (212)
783-6981


The Xtra XWidget library contains a set of widgets that are subclassed from
and compatible with either OSF/Motif or OLIT widgets.  The library includes
widgets that implement the following:

   Spreadsheet
   Bar Graph
   Stacked Bar Graph
   Line Graph
   Pie Chart
   XY Plot
   Hypertext
   Hypertext based Help System
   Entry Form with type checking

Contact Graphical Software Technology at 310-328-9338  (info@gst.com) for
information.

The XRT/graph widget, available for Motif, XView and OLIT, displays X-Y plots,
bar and pie charts, and supports user-feedback, fast updates and PostScript
output. Contact KL Group Inc. at 416-594-1026 (xrt_info%klg@uunet.ca)

The product Xmath, made by Integrated Systems Inc. is a product which has
interactive 2d and 3d graphics for bar,strip,line,symbol,
surface,contour,etc... that costs $2500.00 for commercial use and a mere
$250.00 for university use that also has complete numerics capabilities, an
easy to use debugger, a complete high level language, a spreadsheet, a motif
gui access capability, and much more all created on top of motif.

You can either email to xmath-info@isi.com or call (408)980-1500.

Digital Equipment Corporation (DEC) provides the following product NetEd: "The
network editor widget is a Motif toolkit conforming widget that applications
can use to express complex interrelationships graphically in the form of
networks or graphs. The network editor supports interactive or application-
controlled creation and editing of directed graphs or networks."


ACE/gr is an X based XY plotting tool implemented with a point 'n click
paradigm.  A few of its features are:

   * Plots up to 10 graphs with 30 data sets per graph.
   * Data read from files and/or pipes.
   * Graph types XY, log-linear, linear-log, log-log, bar,
        stacked bar charts.

it is available from

        ftp.ccalmr.ogi.edu (presently amb4.ccalmr.ogi.edu)

with IP address 129.95.72.34. The XView version (xvgr) will be found in
/CCALMR/pub/acegr/xvgr-2.09.tar.Z and the Motif version (xmgr) in
/CCALMR/pub/acegr/xmgr-2.09.tar.Z.  Comments, suggestions, bug reports to
pturner@amb4.ccalmr.ogi.edu (if mail fails, try pturner@ese.ogi.edu). Due to
time constraints, replies will be few and far between.



-----------------------------------------------------------------------------
Subject: 158)  Does anyone know of a source code of a graph widget where you
can add vertices and edges and get an automated updating?

[Last modified: March 93]

Answer: The XUG FAQ in comp.windows.x includes information on graph display
widgets.  There is also an implementation in the Asente/Swick book.

  From Martin Janzen: "You could have a look at DataViews, from V.I.
   Corporation.  This package is used mainly to display a variety of graph
   drawings (eg. bar, line, pie, high/low, and other charts), and to update
   the graphs as information is received from "data sources" such as files,
   processes (through pipes), or devices.

   However, it also provides "node" and "edge" objects which can be used
   when working with network graphs.  The DV-Tools function library
   provides routines which traverse a graph, count visits to each node or
   edge, mark nodes or edges of interest, and so on.  A node or edge object
   can have an associated "geometry object" (such as a symbol or a line),
   which represents that node or edge.

   Drawbacks: There's no automatic positioning algorithm; when you add a
   node or edge, you have to create and position its geometry object
   yourself.  Also, this isn't a set of add-on widgets; you can either have
   DataViews create an X window (ie. a separate shell), or you can create
   your own XmDrawingArea and use DataViews to update its window when
   expose events are received.  Finally, the package is quite expensive,
   and there is a run-time charge.

   The vendor's address is:
     V.I. Corporation,
     47 Pleasant Street,
     Northampton, MA  01060,
            Email: vi@vicorp.com, Phone: (413) 586-4144, Fax:   (413) 584-2649

   or

     V.I. Corporation (Europe) Ltd.,
     First Base, Beacontree Plaza,
     Gillette Way,                      Email: viesales@eurovi.uucp
     Reading, Berkshire  RG2 0BP"
   Phone: +44 734 756010,      Fax:   +44 734 756104

From Craig Timmerman: Just wanted others to know that there is a third
competitor in what may be come a big market for generic APIs.  The product is
called Open Interface and Neuron Data is the vendor.  Neuron has added some
extra, more complex widgets to their set.  The two most notable are a table
and network widget.  [...] I believe that the network widget got its name from
its ability to display expert system networks that Neuron's AI tools needed.
It would be more aptly named the graph widget.  It can display and manipulate
graphs of various types (trees, directed graphs, etc).  Contact is

        Neuron Data
        156 University Avenue
        Palo Alto,  CA  94301
        (415) 321-4488


prism!gt3273b@gatech.edu  (RENALDS,ANDREW THEODORE) posted a set of public
domain routines for graph drawing.  Contact him for a later set.

From Ramon Santiago (santiago@fgssu1.fgs.slb.com): HP has released source code
for XmGraph and XmArc, part of the InterWorks library, which does exactly
this. The sources can be obtained by contacting Dave Shaw,
librarian@iworks.ecn.uiowa.edu. A few trivial source code changes need to be
made to get these widgets to compile under Motif 1.2.

Free DAG - directed acyclic graph drawing software in motif environment is
available. Please send a note to address below if you want it:

Budak Arpinar, TUBITAK Software Research & Development Center, Ankara,
TURKIYE, E-mail : C51881@TRMETU.BITNET



-----------------------------------------------------------------------------
Subject: 159)+ Is there a help system available, such as in Windows 3?  Or any
Motif based hypertext system.

[Last modified: apr 94]

Answer:

HTML Widget from NCSA:

The NCSA Mosaic for X package contains a html widget which is freely available
and is the main vehicle for viewing html documents in the Mosaic program. It
has callbacks for anchor hits, selections, etc and many many resources for
customizing the viewing area of your hypertext documents.

GWHIS:

There is a new product from Quadralay Corporation, called the Global-Wide Help
& Information Systems (GWHIS).

from a press release: AUSTIN, TX (March 3, 1994) Quadralay Corporation today
announced its newest software development tool, Global Wide Help & Information
System (GWHIS).  GWHIS allows third party application developers to add online
documentation and context sensitive help to their applications like never
before.  This documentation may consist of plain text, rich format text,
hypertext, images, audio, and/or video animation and may easily be distributed
either locally or over a wide area network such as the Internet.

GWHIS consists of two primary components.  An application programming
interface (API), and a hypermedia viewer (based on technology licensed from
the NCSA Mosaic project).  Several ancillary conversion programs are also
available allowing end users to easily convert existing documentation into
GWHIS' native HTML format.

GWHIS is available on the following platforms: SPARC SunOS 4.1.x, SPARC
Solaris 2.x, INTEL SCO Open Desktop, INTEL Solaris 2.x, HP 9000/700, and the
RS/6000. Support for additional platforms (including MS Windows and Macintosh)
is under consideration.  Fully functional evaluation copies of this software
are available upon request or via anonymous ftp from ftp.quadralay.com.

Brian Combs Quadralay Corporation combs@quadralay.com



Bristol Technology have a hypertext system HyperHelp with the look-and-feel of
either Motif or OpenLook. It should be available from january 31, 1992.
Contact

        Bristol Technology Inc.
        898 Ethan Allen Highway
        Ridgefield, CT  06877
        203-438-6969 (phone)
        203-438-5013 (fax)
        uunet.uu.net!bristol!keith

Demos are available by anonymous ftp from  ftp.uu.net (137.39.1.9) in the
vendor/Bristol/HyperHelp as files sun.motif.tar.Z and hp.tar.Z.

There was a posting of a motif hypertext-widget to comp.sources.x (Author:
B.Raoult ( mab@ecmwf.co.uk ) ).  It had the facility to read in helptext from
a file.

From Francois Felix Ingrand (felix@idefix.laas.fr): I have translated the Info
AW (originally written by Jordan Hubbard) to Motif. It is a Widget to browse
Info files (format used by GNU for their various documentations). I use it as
the help system of various tool I wrote.  It is available on laas.laas.fr
(140.93.0.15) in /pub/prs/xinfo-motif.tar.Z

Form Scott Raney (raney@metacard.com) MetaCard is a commercial package that
can be used to implement hypertext help.  The text fields support multiple
typefaces, sizes, styles, colors, subscript/superscript, and hypertext links.
It has a Motif interface, and a template for calling it from an Xt/Motif
application is included.  You can FTP a save-disabled distribution from
ftp.metacard.com or from world.std.com.  For more info, email to
info@metacard.com.


The Motifation GbR also provides a hypertext-helpsystem named 'XpgHelp'.
(Motif look-and-feel / features like those known from MS Windows Help ) For a
free demo or more information send email either to griebel@uni-paderborn.d e
or contact the distributor:

        PEM GmbH,
        Vaihinger Strasse 49,
        7000 Stuttgart 80,
        Germany,
        +49 (0) 711 713045 (phone),
        +49 (0) 711 713047 (fax),
        email: basien@pem-stuttgart.de

XpgHelp has nearly the same features like HyperHelp: (multiple fonts, graphics
in b&w and color, different styles, tabs, links, short links, notepad, ...)

The Interface Builder MOTIFATION uses XpgHelp as its hypertext helpsystem.



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

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

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

        #include <X11/Intrinsic.h>
        #include <X11/StringDefs.h>
        #include <Xm/Xm.h>
        #include <X11/Xmu/Converters.h>
        #include <X11/IntrinsicP.h>
        #include <X11/CoreP.h>

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

                XtAddConverter(XmRString, XmRWindow, XmuCvtStringToWidget,
                        parentCvtArgs, XtNumber(parentCvtArgs));
        }



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

 *Text.translations:    #override \
     Ctrl<Key>a:    beginning-of-line() \n\
     Ctrl<Key>e:    end-of-line() \n\
     Ctrl<Key>f:    forward-character() \n\


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

     Ctrl<Key>a:    beginning-of-line() \n\
                                           ^ space here

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


-----------------------------------------------------------------------------
Subject: 162)  Where can I get the PanHandler code?

Answer: It is available by email from Chuck Ocheret:  chuck@IMSI.COM.

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

    Warning: Attempt to remove non-existant passive grab


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

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

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

-----------------------------------------------------------------------------
Subject: 164)  How do I have more buttons than three in a box?  I want to have
something like a MessageBox (or other widget) with more than three buttons,
but with the same nice appearance.

[Last modified: May 93]

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

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

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

Alternatively, build your own dialog:

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

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

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

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

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

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

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

    XtRealizeWidget(toplevel);
    XtAppMainLoop(app);
}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#define TIGHTNESS 20

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

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

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

    XtManageChild(action_area);

    return action_area;
}



-----------------------------------------------------------------------------
Subject: 165)  How do I create a "busy working cursor"?

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

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

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

From Baudouin Raoult (mab@ecmwf.co.uk)

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

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

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

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


Answer: A solution with lots of bells and whistles is

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

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

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

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

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

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

    XtRealizeWidget(shell);
    XtAppMainLoop(app);
}

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

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

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

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

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

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

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

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

    XFlush(dpy);

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

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

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

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

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

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


-----------------------------------------------------------------------------
Subject: 166)  Can I use the hourglass that mwm uses?

[Last modified: March 93]

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



-----------------------------------------------------------------------------
Subject: 167)  What order should the libraries be linked in?

[Last modified: August 92]

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

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

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

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


-----------------------------------------------------------------------------
Subject: 168)  How do I use xmkmf for Motif clients?

[Last modified: October 1992]

Answer: This advice comes from dbrooks@osf.org:

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

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

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

David Brooks OSF

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

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

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

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

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

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

        imake -I{MTOP}/config -DUseInstalled

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

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

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

        imake -DUseInstalled -DUseInstalledMotif


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

        LOCAL_LIBRARIES = XmClientLibs
                DEPLIBS = XmClientDepLibs

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

        MSimpleUilTarget(program)

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


And Paul Howell <grue@engin.umich.edu> added:

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

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

#include <Project.tmpl>
#ifdef UseInstalledMotif
#include <Motif.tmpl>
#endif

#include <Imake.rules>
#ifdef UseInstalledMotif
#include <Motif.rules>
#endif

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


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

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

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


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

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

    context_widget = XmTrackingLocate( top_level_widget,
                                context_cursor, FALSE ) ;

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

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

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

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

    popup_message( "No context-sensitive help found\n\
for the selected object." ) ;
}



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

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

MyApp*Help_menu*Contextual Help.acceleratorText:   F1

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


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

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

[Last modified: January 1993]

Answer: Run the debugger on one display while the application writes to
another display.  ---------
--------------------------------------------------------------------
Subject: 171)+ How can I disable Drag and Drop in my Motif 1.2 client ?

[Last modified: December]

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

#include <Xm/Display.h>


    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)

-----------------------------------------------------------------------------
Subject: 172)  Where can I get info on the Motif drag and drop protocol?

[Last modified: March]

Answer: The drag and drop protocol implemented by OSF is not stable, so they
have not published it yet. The API should remain stable though.  The OSF
protocol is not compatable with the OpenLook protocol.  OSF and Sun are
working on a joint protocol for publication.

For programming examples on Motif D&D, see the Motif 1.2 Programmers Guide.

For a third alternative, try Roger Reynolds D&D protocol, available from
netcom.com in /pub/rogerr.

-----------------------------------------------------------------------------
Subject: 173)  TOPIC: ACKNOWLEDGEMENTS

This list was compiled using questions and answers posed to
comp.windows.x.motif and motif-talk. Some extracts were also taken from FAQs
of comp.windows.x.  To all who contributed one way or the other, thanks! I
haven't often given individual references, but  you may recognise
contributions. If I have mangled them too much, let me know.



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

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


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

I am maintaining the FAQ now and will strive to maintain the quality
that Jan has acheived. Enjoy!
Brian

Brian Dealy - X Professional Organization
dealy@kong.gsfc.nasa.gov


(301) 572-8267
(410) 799-7197 (FAX)
+--------------------------+