MOTIF Frequently Asked Questions
Subject: Motif FAQ (all parts)
Newsgroups: comp.windows.x.motif,comp.answers,news.answers
Reply-To: kenton@rahul.net (Ken Lee)
Summary: Motif Frequently Asked Questions (with answers).
Posting-Freq.: irregular (re-posted monthly to comp.windows.x.motif)
Organization: Kenton Lee, X/Motif Consultant, http://www.rahul.net/kenton/
URL: http://www.rahul.net/kenton/mfaq.html
Motif FAQ
[Last changed: 1 JUL 2000]
This article contains the answers to some Frequently Asked Questions (FAQ)
often seen in comp.windows.x.motif. It is posted to help reduce volume in
this newsgroup and to provide hard-to-find information of general interest.
This article includes answers to the questions listed below. Key:
+ questions NEW to this issue;
* CHANGES since last issue.
This FAQ is maintained by Ken Lee (kenton@rahul.net)
http://www.rahul.net/kenton/
You can obtain the most recent version of this FAQ via anonymous ftp from
a server which will seldom refuse you access. Try any of these URLs:
ftp://ftp.rahul.net/pub/kenton/faqs/Motif-FAQ or
ftp://ftp.rahul.net/pub/kenton/faqs/Motif-FAQ.gz or
ftp://ftp.rahul.net/pub/kenton/faqs/Motif-FAQ.Z
or get the HTML version as one big 600KB file from:
ftp://ftp.rahul.net/pub/kenton/faqs/Motif-FAQ.html or
ftp://ftp.rahul.net/pub/kenton/faqs/Motif-FAQ.html.gz
The Motif FAQ is mirrored at several sites around the world.
Sites closer to you should load faster. These sites are listed at:
http://www.rahul.net/kenton/mfaq.html
Note: See "Can I receive email notification when the Motif FAQ is updated?"
I also maintain a WWW page of over 700 technical X Window System and OSF/Motif
links at:
http://www.rahul.net/kenton/xsites.html
These links include X programming tutorials, technical papers, FAQs,
major X-related technologies, product reviews, etc.
Ken Sall also has an excellent Motif web page at:
http://www.cen.com/mw3/
For more information on these web pages, see the subject "Is there a
central location for Motif information on the WWW?"
Send updates and corrections to kenton@nojunk.rahul.net.
Please include the phrase "For Motif FAQ" in your subject line.
*** SUN READERS ***
The Motif FAQ is now included in a different HTML format with Java applets
on the premiere issue of the SunSoft Developer CD-ROM.
*** CAVEAT ***
If an answer does not have a "Last modified" date, it's possible the
information may no longer be accurate. Modification dates go back to
August 1992. More than half the answers have such a modification
date. Note also that the older the "Last modified" date, the more
likely the information may be suspect. Pay close attention to version
information discussed in answers, since the information may pertain
only to that specific release.
In some cases, I've repeated information in different contexts to make
these details a bit easier to find.
This posting is Copyright (c) 1997-2000 by Kenton Lee.
ALL RIGHTS RESERVED. Permission is hereby granted to read and
distribute this posting for non-commercial purposes. Permission to use
this material for any other purpose must first be obtained in writing
from the author.
-----------------------------------------------------------------------------
0) TOPIC: SUBMITTING SUGGESTIONS, CORRECTIONS, NEW ANSWERS
1) TOPIC: WHAT IS MOTIF?
2)+ Is the Motif source code publically available?
3)* What is Motif and how does it relate to the X Toolkit and X Window Sys-
tem?
4) Where did the name "Motif" come from?
5) TOPIC: OTHER RELEVANT NEWSGROUPS AND FAQS
6) TOPIC: FAQ and NEWSGROUP FTP ARCHIVES
7) Is the FAQ available via FTP?
8) Can I receive email notification when the Motif FAQ is updated?
9) Is this FAQ accessible via WWW?
10) Is this newsgroup accessible via email?
11) Is this newsgroup archived?
12) Is the mail list motif-talk archived?
13) TOPIC: OSF, MOTIF VERSIONS, CDE, COSE, DCE, The OPEN GROUP
14) How can I contact the Open Group?
15) Where can I find OSF press releases on Motif and DCE?
16) What versions of Motif are there?
17) How can I find which version of Motif I have? Xlib or Xt version?
18) Is there a concise features list for Motif 2.0?
19) What are the details about new features in Motif 2.0?
20) Is there a concise features list for Motif 2.1?
21) Where can I find Motif 2.1 documentation?
22) Is the official Motif documentation available on-line?
23) I want to use C++ with Motif. Where can I find C++ examples?
24) Is Motif 2.0 backward compatible with Motif 1.2?
25) How compatible are Motif 1.2.* and X11R6?
26) Why aren't the big UNIX vendors shipping Motif 2.0?
27) Where can I get Motif for UNIX, Linux, or Microsoft Windows?
28) Is there a list of Motif bugs?
29) Where can I get a Motif 1.2 Certification Checklist?
30) What is CDE? What is COSE and how does it relate to Motif?
31) Is there a CDE FAQ or newsgroup?
32) What is the current version of CDE and what are its features?
33) How does Motif relate to X/Open and CDE?
34) What is The Open Group?
35) Is The Open Group assuming responsibility for the X Window System?
36) What are the current correct trademark statements for X and Motif?
37) Will CDE and Motif converge? What is the CDE/Motif JDA?
38) Where can I get public domain Motif source?
39) Are Motif code examples publically available?
40) Has anyone done a public domain Motif lookalike?
41) Does anyone from the Open Group pay attention to our
questions/suggestions?
42) Does the Open Group have an application compliance validation service?
43) What is the motif-talk mailing list?
44) What MIT patches do I use, and when do I use fix-osf?
45) How does Motif work with X11R5?
46) TOPIC: X and MOTIF on the WORLD WIDE WEB (WWW)
47) Is there a central location for Motif information on the WWW?
48) Where can I find X technical info on the WWW?
49) What is Broadway? I've heard it called "X on the Web".
50) Where's an HTML version of the Motif FAQ on World Wide Web (WWW)?
51) Where can I get the HTML widget used in Mosaic?
52) What widgets does Netscape use for its bookmarks list and preference
panels?
53) TOPIC: BOOKS and JOURNALS
54) Is there a bibliography available?
55) Is there a Motif tutorial? Xt tutorial? X11 tutorial?
56) What books are available for Motif application programmers?
57) Which Xt and X books would also be helpful?
58) Are there books for X11R6 yet?
59) What relevant journals are available?
60) Is there a Motif book for shell programming, such as ksh (kornshell)?
61) TOPIC: MWM and the SHELL WIDGET
62) What is the difference between Motif and mwm?
63) Does anyone have an alternative set of 3-D defaults for a monochrome
screen?
64) What are some useful mwm resources I can control?
65) How can I configure mwm, such as changing or adding to root menus?
66) How can my program determine which window manager is running?
67) How can I modify the mwm's window decorations with a resource file?
68) How can I programatically modify the mwm's window decorations?
69) Is there an ICCCM compliant way of setting window manager decorations?
70) How can I put decorations on transient windows using olwm?
71) How can I turn off the Motif window manager functions from the system
menu?
72) How can I create a multi-colored window manager icon?
73) How can I keep my shell windows fixed in size?
74) Why is XtGetValues of XmNx and XmNy of my toplevel shell wrong?
75) How do I get XmNx and XmNy positions to be honored correctly?
76) How can my application know when the user has quit Mwm?
77) How can I tell if the user has selected "Close" from the system menu? How
do I catch the "Close"?
78) Is there an mwm virtual desktop manager?
79) Why does mwm 1.2 crash on startup?
80) How do I obtain the size of a unmanaged shell widget?
81)* How can I create a shell widget with a non-default visual type?
82) Can a non-shell Motif widget have a different visual type from its
parent?
83) Why do I get BadMatch errors from my menus when I use a non-default visu-
al type for my application shell?
84) How do I popup a scrolled list on top of other widgets?
85) How can I keep my application's window always on top of all other appli-
cations' windows?
86) How can I maximize my top level shell?
87) TOPIC: MOTIF DEVELOPMENT TOOLS (GUI BUILDERS and UIMS's)
88) What GUI tools exist to assist in developing Motif applications?
89) TOPIC: GEOMETRY MANAGEMENT
90) Why is geometry management so important?
91) What are good references for reading about geometry management?
92) Why don't my labels resize in a RowColumn widget?
93) Does XmRowColumn support multiple columns with different column widths?
94) Why do composite widgets (including dialogs) that were created after
their parents were realized appear smaller under 1.2.3 and later?
95) How does the ScrolledWindow manage resizing?
96) Does the XmPanedWindow widget support horizontal paning?
97) TOPIC: TEXT WIDGET
98) How do XmTextField and a single line XmText widget differ?
99) Why does pressing RETURN in a text widget do nothing?
100) Can you reuse the return value from XtParseTranslationTable?
101) When I add text to a scrolling text widget, how can I get the new text
to show?
102) How do I scroll text to display the most recently added information?
103) Does the text widget support 16 bit character fonts?
104) How can I stop the text widget from echoing characters typed?
105) How can I replace characters typed with say a `*'?
106) How can I make a text widget insensitive without graying out the text?
107) How can I best add a large piece of text to a scrolled text widget?
108) How can I get the correct colors for scrolled text widget scrollbars
(Sun only)?
109) How can I highlight text in the Text widget?
110) How can I select all of the text in a widget programmatically?
111) Can I customize the pointer cursor or insert position indicator used by
the text widget?
112) How can I change colours of text in the Text widget?
113) How can I change the font of text in the Text widget?
114) Is there an emacs binding for the text widget?
115) What if I have problems with the backspace/delete keys?
116) How can I use a file as the text source for a Text widget?
117) How can put Text in overstrike mode instead of insert?
118) How can I make the Delete key do a Backspace?
119) Can I change the tab stops in the XmText widget?
120) TOPIC: LIST WIDGET
121) Should I create an XmList widget as a child of automatic XmScrolledWin-
dow or use the XmCreateScrolledList() convenience function?
122) How do I best put a new set of items into a list?
123) Can I have strings with different fonts in a list?
124)* Can I get a bitmap to show in a list item like I can in a Label?
125)* Can I have items with different colors in a list widget?
126)* How can I line up columns in a list widget?
127) Can I grey out an item in a list widget?
128) Can I have multi-line items in a list?
129) How can I tell the position of selected items in a list?
130) How can I configure a scrolled list widget to show a horizontal
scrollbar when some list items are wider than the window?
131) How can I programatically select all of the items in an XmList?
132) TOPIC: FILE SELECTION BOX WIDGET
133) What is libPW.a and do I need it?
134) What are these compile errors: Undefined symbol _regcmp and _regex?
135) What's wrong with the Motif 1.0 File Selection Box?
136) How can I keep my file selection boxes from resizing when I change
directories or filters?
137) What's wrong with the FileSelectionBox under Solaris?
138) TOPIC: FORM WIDGET
139) Why don't labels in a Form resize when the label is changed?
140) How can I center a widget in a form?
141) How do I line up two columns of widgets of different types?
142) TOPIC: PUSHBUTTON WIDGET
143) Why doesn't the enter or return key activate the button with focus?
144) Why can't I use accelerators on buttons not in a menu?
145) TOPIC: TOGGLEBUTTON WIDGET
146) What widgets give the look of push buttons, but behavior of toggle but-
tons?
147) Can I customize XmToggleButton to use my own indicator graphic (e.g., a
check mark)?
148) TOPIC: ICON WIDGET and PIXMAPS
149) What is XPM?
150) How do I convert my XPM file into a Pixmap?
151) How can I display a multi-color image in a widget?
152) Can I use XmGetPixmap in Motif 1.2 to create colored images?
153) Why does XpmCreatePixmapFromData fail with a pixmap containing a large
number of colors?
154) How can I convert a Sun/GIF/TIFF image to a pixmap?
155) How can I use Motif's pre-defined pixmaps?
156) TOPIC: SCALE AND SCROLLBAR WIDGET
157) Can the XmScale widget have arrows or tick marks in Motif 2.0?
158) How can I set the color of a XmScale widget's trough?
159) How does Motif implement mouse button auto-repeat on the scrollbar's ar-
row buttons?
160) TOPIC: LABEL WIDGET
161) How can I align the text in a label (button, etc) widget?
162) Why doesn't label alignment work in a XmRowColumn?
163) How can I set a multi-line label?
164) How can I have a vertical label?
165) How can I have a Pixmap in a Label?
166) Why doesn't the XmLabel widget obey the XmNwith and XmNheight that I
give it?
167) How do you set the background color of a label widget using XtVa-
TypedArg?
168) TOPIC: DRAWING AREA WIDGET
169) How can I send an expose event to a Drawing Area widget?
170) How can I know when a DrawingArea has been resized?
171) How can I create a drawing area widget with a visual type different from
its parent?
172) How can I display postscript in a Motif widget, such as XmDrawingArea?
173) TOPIC: MAIN WINDOW WIDGET
174) How can I create a message window in an XmMainWindow?
175) TOPIC: SCROLLED WINDOW WIDGET
176) How do I tell if a scrolled window's scrollbars are visible?
177) How can I programatically scroll a XmScrolledWindow in XmAUTOMATIC mode?
178) What widget does the XmScrolledWindow use for its clip window?
179) How do I create a scrolled window with only one scrollbar?
180) TOPIC: MENUS
181) How can I change the cursor used in Motif menus?
182) How do I put my help menu on the far right of my menubar?
183) Can I change or disable the menu bar accelerator from the default (F10)?
184) How do I set the current choice in a radio box or an option menu?
185) How can I determine the item selected in a a radio box or option menu?
186) How can I change the cascade indicator on an option menu?
187) How do I unset an XmToggleButton in a radio box?
188) Can I place a radio box in a pulldown menu?
189) How do I make a menu choice insensitive if it was created with XmVa-
CreateSimplePulldownMenu?
190) What widgets can I put inside a menubar?
191) Can I have a cascade button without a submenu in a pulldown menu?
192) Should I have a cascade button without a submenu in a pulldown menu?
193) What is the best way to create popup menus?
194) How do popup menus work?
195) How can I disable the button 3 grab if I am not using popup menus?
196) Should I use translation tables or actions for popup menus?
197) What are the known bugs in popup menus?
198) Can I have multiple popup menus on the same widget?
199) How can I change the shell title of a tear-off menu?
200) Can I programmatically tear-off a menu?
201) What widgets are valid within Motif menus?
202) Can I create multi-column popup or pulldown menus?
203) How can I keep my program from hanging if a user activates a popup that
is a child of an insensitive push button?
204) TOPIC: DRAG AND DROP
205) Where can I find info and examples of the Motif drag and drop protocol?
206) How can I disable Drag and Drop in my Motif 1.2 client ?
207) Can I register client data for the Motif XmDropSite drop callback?
208) Can unmanged widgets be valid (drag-and-drop) drop sites?
209) TOPIC: INPUT FOCUS
210) How can I specify the widget that should have the keyboard focus when my
application starts up?
211) How can I specify my own keyboard traversal order?
212) How can I determine which widget has keyboard focus?
213) How can I direct the keyboard input to a particular widget?
214) How can I have a modal dialog which has to be answered before the appli-
cation can continue?
215) TOPIC: MEMORY AND SPEED
216) When can I free data structures passed to or retrieved from Motif?
217) What memory leaks are known? Why does my application grow in size?
218) Why do I get so many uninitilized memory read (UMR) errors when I run
Purify[tm] on my Motif programs?
219) Why does my application take a long time to start up?
220) My application is running too slowly. How can I speed it up?
221) Why is my application so huge?
222) How can I improve performance when creating and deleting hundreds of
text widgets?
223) After I call XtSetValues, when will I see the changes in my GUI?
224) TOPIC: XMSTRING
225) What string functions differ in Motif 1.1 and 1.2?
226) How can I get the Ascii text out of an XmString?
227) When can XmStrings used as resources be freed?
228) Why doesn't XmStringGetNextSegment() work properly?
229) Why does using XmStringDraw cause a BadFont error?
230) How can I control color of individual strings to show status, etc.?
231) TOPIC: DIALOGS
232) How do I stop my dialog disappearing when I press the help button?
233) How do I make my own dialog?
234) Why do dialog title bars have "_popup" or "<-popup" concatenated onto
the widget name?
235) How can I force a dialog window to display?
236) How can I control placement of a popup widget?
237) How can I set the dialog's default button?
238) How can I create a dialog that behaves like, but looks a little dif-
ferent from, XmMessageBox?
239) How can I use Motif's message dialog bitmaps in my own dialogs?
240) TOPIC: LANGUAGE BINDINGS
241) What is ViewKit? Is there a free version?
242) Is there a C++ binding for Motif?
243) How can I avoid C++ String class and typedef char *String conflicts?
244) How can I have a C++ member function in a callback?
245) Is there a Common Lisp binding for Motif?
246) Is there an Ada binding for Motif? (Part 1 of 2)
247) Is there an Ada binding for Motif? (Part 2 of 2)
248) Is there a Poplog binding for Motif?
249) TOPIC: SPECIFIC PLATFORMS
250) Is it easy to build Motif for a Sun?
251) How do I build Motif 1.2.2 on Solaris 2.1 with Sun C?
252) What compile errors/warnings might I get in both Sun 3 and Sun 4?
253) On a Sun 3, what are the mwm startup error messages about?
254) Are there problems making shared libraries on a Sun?
255) Why does the OpenWindows server hangs when I popup a menu with Button 3?
256) Has anyone made shared libraries on an IBM RS/6000?
257) What is the error "Unaligned access in XmString" under Ultrix?
258) Can bugs in Sun's OpenWindows server cause Motif clients to crash?
259) Why does Motif on Linux crash when I open a file selection box?
260) Are there compatibility problems between some Linux Motif libraries and
libc5 or glibc?
261) How can I install Motif on my PC?
262) TOPIC: KEYSYMS
263) What is causing the messages "unknown keysym name osfDown..."?
264) What happens if I can't install Motif Keysyms?
265) Why has OSF introduced Keysyms into Motif 1.1?
266) Why do accented characters not work with Motif applications linked with
X11R6? What is the Compose file?
267) TOPIC: UIL
268) What is UIL and why is it so popular?
269) What is Mrm?
270) How do I specify a search path for ".uid" files?
271) Can I specify callback functions in resource files?
272) How can I set a multi-line label in UIL?
273) Is there a program that can convert a UIL file to tclMotif?
274) Why does my SCO UIL application fail to open 60 UID files?
275) TOPIC: ICONIFICATION and DE-ICONIFICATION
276) How can I keep track of changes to iconic/normal window state?
277) How can I check if my application has come up iconic?
278) How can I start my application in iconic state?
279) How can an application iconify itself?
280) How can an application de-iconify itself?
281) Why doesn't MWM display an iconify button on my dialog windows?
282) TOPIC: SPECIALIZED WIDGETS
283) Where can I get ComboBox, SpinBox, or Tree graph widgets?
284) Is there a help system or Motif hypertext system available?
285) Is there a canvas widget or drawing widget for graphical display?
286) How can I create a transparent widget?
287) TOPIC: CREATING WIDGETS
288) What are some good references for creating widgets (subclassing widg-
ets)?
289) How can I achieve binary compatibility using the XmResolvePartOffset
API?
290) TOPIC: MISCELLANEOUS
291) How can an application be informed of signals?
292) How do I control the repeat rate on a SUN keyboard?
293) How can I identify the children of a manager widget?
294) What functions can an application use to change the size or position of
a widget?
295) Can I use XtAddTimeOut, XtAddWorkProc, and XtAddInput with XtAppMain-
Loop?
296) Why does XtGetValues for XmNx and XmNwidth return extremely large
values?
297) Can I use XmGetPixmap() with widgets that have non-default visual types?
298) What is the matter with Frame in Motif 1.2?
299) What is IMUG and how do I join it?
300) How do I set the title of a top level window?
301) How can I disable the color scheme mechanism in CDE or HP VUE?
302) Can I use editres with Motif? Is there an editres tutorial?
303) Where is the editres protocol documented?
304) Why does an augment translation appear to act as replace for some widg-
ets?
305) How do you "grey" out a widget so that it cannot be activated?
306) Can I change the graphics drawn by insensitive widgets?
307) Why doesn't the Help callback work on some widgets?
308) How can I implement "bubble help" or "tool tips" with Motif?
309) Can I specify a widget in a resource file?
310) Why are only some of my translations are being installed?
311) Can I have separate translations for shifted and unshifted keys?
312) What are these "non-existant passive grab" warnings?
313) How do I have more buttons than three in a MessageBox?
314) How do I create a "busy working cursor"?
315) Can I use the hourglass that mwm uses?
316) What order should the libraries be linked in?
317) How do I use xmkmf for Motif clients?
318) How do I use imake with Motif 2.0?
319) How do I make context sensitive help?
320) How do I debug a modal interaction?
321) Why can't I install my own colormap using XInstallColormap?
322) How do I install a private colormap?
323) How do I get correct shadow colors to match other color changes?
324) What color algorithm does Motif use?
325) How can you access the superclass widget from which Motif convenience
dialogs are subclassed?
326) Can the Motif 2.0 Notebook widget display non-rectangular "file tabs"?
327) How does the clipboard mechanism work?
328) Why does the xyz application core dump when I cut and paste?
329) Why is XtWindow(widget) == 0?
330) How do I debug X protocol errors (e.g., BadWindow, BadMatch) in Motif
applications?
331) Why doesn't XtNameToWidget (widget, "MyName") work?
332) Why does my callback's client data structure contain incorrect values
when the callback is called?
333) How can an application manage events on multiple displays?
334) Can a Motif application create windows on mutiple screens (on a multi-
screen workstation)?
335) Why do I get "Error: attempt to add non-widget child "dsm" to parent"?
336) Why do I get link errors about "XShape" symbols?
337) Why do I get link errors about "ICE" and "SM" symbols?
338) Why does my X11R6 program crash with undefined symbol "LowerCase"?
339) How do I programatically control xwd to dump a specific window?
340) How can I display an xwd in a window (without using xwud)?
341) Can I write a multi-threaded Motif application?
342) How can I dump my widget instance tree in a way that reflects the
hierarchy?
343) How do I get the events for gadgets? Or the name of the gadget?
344) Can I set the foreground and background colors of gadgets (e.g., con-
venience dialog buttons)?
345) Can I use a gadget as the parent of a dialog shell?
346) Which other widget features do gadgets lack?
347) Where can I get the xmon or xscope programs to trace my X protocol?
348) What does the error "Couldn't find per display information" mean?
349) Can I set widget fallback resources after I've called XtAppInitialize()?
350) Can I use the newline character in widget names?
351) Is anybody out there selling Windows95 look-alike widgets?
352) How can I convert my OLIT programs to the Motif look & feel?
353) Where can I obtain X and Motif applications?
354) What does this mean: Warning: Cannot find callback list in XtAddCall-
back?
355) If a single widget has multiple callback functions, are they all execut-
ed? If so, in what order?
356) Why are some widgets still visible after I call XtDestroyWidget() on
them?
357) If I call XtGetValues on a resource that does not exist for a given
widget, what value is returned?
358) Can I reparent a widget (change its parent)?
359) Are there any "year 2000" issues within Motif?
360) Can I suppress or customize Motif warning and error messages?
361) TOPIC: Motif FAQ HISTORY and ACKNOWLEDGEMENTS
-----------------------------------------------------------------------------
Subject: 0) TOPIC: SUBMITTING SUGGESTIONS, CORRECTIONS, NEW ANSWERS
[Last modified: May 97]
Answer: Are you posting articles to comp.windows.x.motif and expecting them to
be added to the Motif FAQ? If so, please note that I no longer read the
newsgroup on a regular basis. If you want to add to the FAQ, here's the
procedure....
If you have suggestions or corrections for any of these answers or any
additional information, please send them to the e-mail address below. The
information will be included in the next revision or two.
o Send updates, suggestions, corrections, new answers to:
kenton@nojunk.rahul.net (Ken Lee)
X/Motif Consultant
http://www.rahul.net/kenton/
o _Please_ put "For Motif FAQ" in the Subject line!
(This is the best way to catch my attention. Really.)
o Please include answers with your FAQ questions.
(If are looking for an answer to your questions, you may
want to hire a consultant. My company can do e-mail consulting.)
o For coding-related issues, I would prefer a short textual
description of the your design rather than a long code sample.
o If you do submit code, make sure it is well tested, portable,
and robust.
o If you _do not_ want your name or email address listed
in the FAQ, explicitly state this.
NOTE TO BUSINESSES: Please send your announcements/updates/corrections in a
brief, ready-to-include form. I'd rather not spend alot of time editing the
information.
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: telephone numbers tend to be Bell-system unless otherwise
noted; prices on items are not included.
-----------------------------------------------------------------------------
Subject: 1) TOPIC: WHAT IS MOTIF?
-----------------------------------------------------------------------------
Subject: 2)+ Is the Motif source code publically available?
[Last modified: May 00]
Answer: On May 15, 2000 the Open Group released the Motif source code, using a
public license, to the Open Source community. For more information on Open
Motif, see:
http://www.opengroup.org/openmotif/
This web site includes the open source license details, a FAQ and other
documentation, and allows you to download the Motif source code.
Some other web sites dedicated to Open Motif are:
http://www.motifzone.net/
http://www.metrolink.com/openmotif/
-----------------------------------------------------------------------------
Subject: 3)* What is Motif and how does it relate to the X Toolkit and X
Window System?
[Last modified: May 00]
Answer: Motif is a widely-accepted set of user interface guidelines developed
by the Open Software Foundation (OSF) around 1989 which specifies how an X
Window System application should "look and feel". Motif includes the Motif
Toolkit (also called "Xm" or the "Motif widgets"), which enforce a policy on
top of the X Toolkit Intrinsics ("Xt"). Xt is really a "mechanism not policy"
layer, and Xm provides the specific "look and feel". For example, Xt does not
insist that windows have titlebars or menus, but it provides hooks for
developers of specific toolkits (Motif, OpenLook, Athena widgets) to take
advantage of. In addition to widgets, Motif includes the Motif Style Guide
document (as well as several others listed in my FAQ) which details how a
Motif user interface should look and behave to be "Motif compliant".
The X Toolkit Intrinsics are built upon the lowest programming level API
called "Xlib" (X library). Both Xlib and Xt are specified by the Open Group
(formerly called the MIT X Consortium), which you can reach at:
http://www.camb.opengroup.org/tech/desktop/x/
In early 1996, OSF merged with X/Open to form the Open Group. At the
beginning of 1997, the X Consortium closed and transfered ownership of its
projects to the Open Group. The Open Group continues development and support
on the X Window System, Motif, CDE, and other technologies.
On May 15, 2000 the Open Group released the Motif source code, using a public
license, to the Open Source community. For more information, see:
http://www.opengroup.org/openmotif/
-----------------------------------------------------------------------------
Subject: 4) Where did the name "Motif" come from?
[Last modified: Jun 98]
Answer: We had a contest inside of what was then The Open Software Foundation
to name this thing that we had up to then called the UEC for User Environment
Component. Lots of things were suggested, but Motif was suggested by one of
the employees.
Ken Flowers, k.flowers@opengroup.org
FYI - in the art world, a motif is a recurring artistic symbol or theme. The
meaning obviously carries over to the GUI world.
Ken Lee, http://www.rahul.net/kenton/
-----------------------------------------------------------------------------
Subject: 5) TOPIC: OTHER RELEVANT NEWSGROUPS AND FAQS
[Last modified: Aug 98]
Answer: This newsgroup is "comp.windows.x.motif". The WWW URL is:
news:comp.windows.x.motif
Many other X-related newgroups and FAQs are available. For a full list, see
http://www.rahul.net/kenton/xsites.framed.html
-----------------------------------------------------------------------------
Subject: 6) TOPIC: FAQ and NEWSGROUP FTP ARCHIVES
-----------------------------------------------------------------------------
Subject: 7) Is the FAQ available via FTP?
[Last modified: Apr 98]
Answer: The Motif FAQ is available as a large single file on Kenton Lee's web
site:
ftp://ftp.rahul.net/pub/kenton/faqs/Motif-FAQ
ftp://ftp.rahul.net/pub/kenton/faqs/Motif-FAQ.Z
ftp://ftp.rahul.net/pub/kenton/faqs/Motif-FAQ.gz
ftp://ftp.rahul.net/pub/kenton/faqs/Motif-FAQ.html
ftp://ftp.rahul.net/pub/kenton/faqs/Motif-FAQ.html.gz
A number of FAQ's (including this one) are available via anonymous ftp at
rtfm.mit.edu under the directory pub/usenet.
The Motif FAQ is available in 9 parts via anonymous ftp in any of the
following directories at rtfm.mit.edu:
/pub/usenet-by-group/comp.windows.x.motif
/pub/usenet-by-group/comp.answers/motif-faq
/pub/usenet-by-group/news.answers/motif-faq
There is also a mail server called mail-server@rtfm.mit.edu. To retrieve a
file send mail to the server with a subject or body similar to
send usenet/comp.windows.x.motif/Motif_FAQ_(Part_1_of_9).Z
The Motif FAQ is also available via anonymous ftp as a single file:
/contrib/faqs/Motif-FAQ from ftp.x.org.
(See also "Is this FAQ accessible via WWW?")
The FAQ is also accessible from WAIS (Wide Area Information System) under UC-
Motif-FAQ, allowing keyword-based searches of the FAQ.
-----------------------------------------------------------------------------
Subject: 8) Can I receive email notification when the Motif FAQ is updated?
[Last modified: Sept 95]
Answer: Yes! Simply follow this link to "The URL-minder: Your Own Personal Web
Robot!"
http://www.netmind.com/URL-minder/URL-minder.html
and register the following ftp URL:
ftp://ftp.rahul.net/pub/kenton/faqs/Motif-FAQ (text version)
or
ftp://ftp.rahul.net/pub/kenton/faqs/Motif-FAQ.html (HTML version)
This wonderful free service is brought to you by Netmind at:
http://www.netmind.com/
-----------------------------------------------------------------------------
Subject: 9) Is this FAQ accessible via WWW?
[Last modified: Apr 98]
Answer: You can access the HTML version of this FAQ from my web site, either
uncompressed (600KB) or compressed (180KB):
ftp://ftp.rahul.net/pub/kenton/faqs/Motif-FAQ.html
ftp://ftp.rahul.net/pub/kenton/faqs/Motif-FAQ.html.gz
A list of other web sites (including mirror sites around the world) carrying
text and HTML versions of this FAQ is available at:
http://www.rahul.net/kenton/mfaq.html
Ken Lee
Thanks to Greg Ercolano (erco@netcom.com) for providing an awk script that
converts my Motif FAQ to HTML.
-----------------------------------------------------------------------------
Subject: 10) Is this newsgroup accessible via email?
[Last modified: Nov 94]
Answer: The email link, formerly maintained by Brian Dealy (via motif-
request@lobo.gsfc.nasa.gov), is no longer being attended.
NOTE: As of October 31, 1994, Brian was seeking a new maintainer for
the mail reflector for people without access to comp.windows.x.motif.
If interested, email him at his new address: bdealy@c3i.saic.com.
-----------------------------------------------------------------------------
Subject: 11) Is this newsgroup archived?
[Last modified: Nov 98]
Answer: If you have WWW access, many sites are now archiving some amount of
recent Usenet traffic. Try one of these:
http://www.altavista.digital.com/
http://www.dejanews.com/
http://www.excite.com/
http://www.hotbot.com/
http://www.infoseek.com/
Ken Lee
-----------------------------------------------------------------------------
Subject: 12) 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: 13) TOPIC: OSF, MOTIF VERSIONS, CDE, COSE, DCE, The OPEN GROUP
-----------------------------------------------------------------------------
Subject: 14) How can I contact the Open Group?
[Last modified: Aug 97]
Answer: For more information on the Open Group, including a list of e-mail and
telephone contacts, see their WWW home page:
http://www.opengroup.org/
-----------------------------------------------------------------------------
Subject: 15) Where can I find OSF press releases on Motif and DCE?
[Last modified: May 97]
Answer: The Open Group web page:
http://www.rdg.opengroup.org/press/titles.htm
contains Motif and DCE press releases dating back to August, 1996.
-----------------------------------------------------------------------------
Subject: 16) What versions of Motif are there?
[Last modified: May 97]
Answer: Motif 1.0 is based on the R3 toolkit. There are patch releases to
1.0: 1.0.1, 1.0.A, 1.0.2 and 1.0.3, 1.0.4, 1.0.5. 1.0.A was a fairly major
patch, as it involved a complete re-engineering of UIL and Mrm. Almost
everyone who has 1.0.x has either 1.0.A or 1.0.3.
Motif 1.1 is based on the R4 toolkit. The intial version was Motif 1.1.0.
Motif 1.1.1 has been released as a patch to licensees with Full Support or
Technical Update service. Motif 1.1.2 is a patch release which contains the
necessary changes to fix over 80 bugs reported against Motif. It is available
to support contract holders (including both full support and update service).
The 1.1.3 release fixed a further 150 bugs and was available from August 1991
to support contract holders (including both full support and update service).
1.1.4 offers X11R5 support, but is not an X11R5 product. 1.1.5 was released
in June 92 to licensees who hold a Motif Full Support or Update Support
contract
Motif 1.2.0 was released in April 1992 and is based on the X11R5 toolkit. It
offers increased compatibility with international standards, PC-style
behavior and binary compatibility with Motif 1.1 applications. New features
include drag-and-drop, tear- off menus, toolkit enhancements and new
documentation. toolkit. The code is totally ANSI C.
Motif 1.2.1 was released September, 1992. Due to an optimisation from 1.2.0
to 1.2.1 object code compiled under 1.2.1 (that is, using 1.2.1 header files)
will not link with 1.2.0 libraries (and, very probably, clients that use
shared libraries and are linked against 1.2.1 won't startup against 1.2).
Motif 1.2.2 was released March, 1993. This release contains over 250 bug
fixes, improved text, drag-and-drop features and has less than one reported
defect per 1000 lines of code.
from dbrooks@osf.org Motif 1.2.3 was released on September 13, 1993. The
defect density is measured at < 0.8 known reports per thousand lines. In this
release, we have paid particular attention to memory leaks, and have improved
drag-and-drop performance greatly.
Motif 1.2.4 was released April, 1994. from the OSF README: This patch release
contains approximately 240 bug fixes for Motif 1.2. The number of CRs resolved
in this release is about 330....Apart from the 64-bit changes, all changes
made in this release are fixes for reported bugs.
Motif 2.0 was released in August, 1994. For details, see the questions "Is
there a concise features list for Motif 2.0?" and "What are the details about
new features in Motif 2.0?" Due to binary compatibility problems, this
release was not very popular with UNIX vendors.
Motif 1.2.5 was released June 15, 1995 ONLY to OSF Motif Support Licensees as
part of their maintenance agreement. Motif 1.2.5 includes minor enhancements
to support CDE 1.0. Vendors not supporting CDE generally ignored this release
and continued to use Motif 1.2.4.
Motif 2.1 was released February 5, 1997. For details, see the questions "Is
there a concise features list for Motif 2.1?"
-----------------------------------------------------------------------------
Subject: 17) How can I find which version of Motif I have? Xlib or Xt
version?
[Last modified: Oct 95]
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 (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.
Also, grepping through the strings of libXm.a for OSF can also be useful.
Thanks to hops@x.co.uk Mike Hopkirk
Ken Lee adds the following for determining the Xlib and Xt version:
X11/Xlib.h should have macros like this:
#define XlibSpecificationRelease 6
meaning X11R6.
Similarly, X11/Intrinsic.h has this in X11R6:
#define XtSpecificationRelease 6
-----------------------------------------------------------------------------
Subject: 18) Is there a concise features list for Motif 2.0?
[Last modified: Sept 94]
Answer:
New widgets
ComboBox.
Notebook.
Container/IconGadget.
SpinBox.
CSText.
New features
Thermometer Scale and tic marks.
ScrollBar sliding/arrow and snapback modes.
ScrolledWindow autoscroll and childType.
Toggle indeterminate state and new visual.
Colors in Gadgets.
XmIm API for I18N.
XmNlayoutDirection resource everywhere.
Natural UnitType conversion syntax.
XPM3 (colored icon) format support.
The Uniform Transfer Model.
General Rendition attributes in XmString (color, multiple fonts, etc)
Several Display resources for CDE visual/behavior compatibility.
New FileSelectionBox mode (again from CDE).
Quick navigate in List.
Oriented PanedWindow.
Popup menus support.
and much more...
Extensibility
Traits.
C++ foundry.
Widget writer doc.
Exm widget source examples.
Xme API (useful _Xm).
Desktop
Virtual MWM.
Workspace Manager.
TearOff menu in MWM.
Client Command Interface.
Colored icon pixmaps (from Xm).
Performance & Quality
No known Memory Leaks.
XmString sharing.
XmList creation/setup speedup.
GC usage improved.
Malloc/free usage.
Bitmap allowed for pixmap resources.
XmManager no longer blindly selects for PointerMotion
XmFileSelectionBox better stat cache.
Broader use of Hash tables.
Better link profile (Trait + remodularization).
X11R6 unofficial support.
Hundreds of bug fixes.
-----------------------------------------------------------------------------
Subject: 19) What are the details about new features in Motif 2.0?
[Last modified: Aug 97]
Answer: (See the previous question for a more compact features list.)
NOTE: This is a posting by Douglas Rand that was composed by
one of the OSF business managers, Darrell Crow (crow@osf.org).
OSF also published a nice technical overview in the X Journal.
A copy of that report is available on-line at:
http://www.opengroup.org/tech/desktop/motif/xjournal.htm
Date: 11 Jul 94 15:49:27 GMT
From: (Douglas Rand)
Organization: Open Software Foundation
Subject: Motif 2.0 announcement
To: uunet!lobo.gsfc.nasa.gov!motif
The following was composed by one of our business managers, Darrell Crow
(crow@osf.org), questions may be directed to him.
----------------------------------------
With this posting I hope to answer many questions I've been receiving
regarding what is in Motif 2.0 and how does if differ from Release 1.2. This
posting contains an overview followed by a bullet item listing of the features
and benefits added to Motif in this release. If I didn't answer your questions
feel free to direct them to me. At the end, I'll list additional
documentation available from OSF. If you're also interested in the licensing
and pricing information you can also contact me or the official OSF/Motif
channel: direct@osf.org. I hope that this information update is of benefit to
you.
OSF/Motif has become the major Graphical User Interface (GUI) technology for
Open Systems, as well as an IEEE 1295 standard. On Tuesday, June 21, OSF
announced its next major release of OSF/Motif, Release 2.0. This release,
which is the most extensive and colaborative release of Motif since Motif 1.0
was introduced five years ago, includes new features organized around four
major themes:
I. Extensibility,
2. Consistency,
3. Improvements and
4. CDE Convergence.
Motif 2.0 was a collaborative development effort. Contributors to this
release include Lotus Development, IBM, Hewlett-Packard, Digital Equipment,
Integrated Computer Solutions, Computer Automation, Groupe Bull, HaL Computer
Systems and Unix Systems Laboratories.
This release had the goal of allowing developers to easily build new widgets
and with support for C++ . This required new extensible features such as
subclassing, traits, C++ support and detailed documentation. Like all Xt-
based toolkits, subclassing requires detailed knowledge, experience and access
to the source code to fully understand Motif's class methods. Motif 2.0
simplified this process by providing extensive documentation and allowing
subclassing from the Primitive and Manager classes without requiring access to
source code. Documentation of Motif's class methods are included in a new
book, The OSF/Motif Widget Writer's Guide. This book provides all necessary
information to subclass from Primitive and Manager and numerous examples of
subclassing are provided. Traits are a new feature with Motif 2.0 which
essentially allow a given behaviour to be associated to a widget irrespective
of the widget hierarchial relationships. The number of applications developped
in C++ is rapidly growing and C++ programmers are now able to derive new
subclasses and still have those C++ widgets usable as regular widgets with the
standard API in Motif 2.0
CDE (Common Desktop Environment) convergence. The previous version of
OSF/Motif (Release 1.2) introduced major new features such as
internationalization, drag-and-drop and tear-off menus. Those features were
intended to allow application developers to produce interoperable, easy to use
applications for a worldwide market. As a result, this technology was selected
to become the basis of the Common Desktop Environment jointly developed by HP,
IBM, Novell and SunSoft, proposed to become an X/Open standard. These features
as well as the GUI extensions added to the CDE specifications have been added
to Release 2.0.
PC Consistency has been a major theme of this release. This includes
improvements and completions to the toolkit that was begun with Motif 1.2 as
well as the addition of seven new widgets (Container, Notebook, icon gadget,
spinbox, combobox, CSText and thermometer) common to this environment and
finally a new Style Guide. Extensive work has been expended to ensure the
convergence of the Windows, CUA, CDE and Motif style both in technology and
terminology into a single document. The work for this book will be submitted
to the X/Open Fast Track process for incorporation into the X/Open set of
specifications.
Improvements to the OSF/Motif toolkit are far too numerous to adequately list
here. However a brief mention of a few of the major improvements includes the
addition of the Unified Transfer Model that simplifies data transfer by all
Motif's previous methods, XPM support (ability to read colored icon file for
pixmap resources), ScrolledWindow partial scroll and autodrag,Toggle
checkmark, indeterminate state, documenting the input methods API for
internationalization, upgrading UIL to support 64-bit architecture, platform
independence, and support of the new extensibility features and widgets, and
finally the Motif Window Manager support of virtual screen, workspace
management protocol and root menu additions and etc.
This release brings together the most requested features from development
community with the single purpose of extending application developers' mission
of producing portable, consistent and interoperable applications to the open
systems community.
Listing of the OSF/MotifR 2.0 Features and Benefits
I. MORE EFFICIENT APPLICATION DEVELOPMENT
Easier application development to meet new business opportunities and deploy
applications faster...
Benefit Allows easier extensions to Motif for custom user
Features:
* New, formal Xme API for integrating custom widgets interfaces,
without access to Motif source code
* All extensions using Xme API are "full citizens"
* Widgets may be added to off-the-shelf Motif products, without
recompiling Motif source code
* Manager and primitive widget subclassing
* C++ base classes provided for C++ widget development
* C++ is used for inheritance, but X intrinsics are used for other
characteristics
* Trait mechanism for OSF/Motif widgets, allowing "multiple
inheritance" of C class methods
* Extensibility fully documented in Widget Writer's Guide, and
Reference documentation
* New OSF training: Widget Writing with Motif 2.0
* Examples of custom widgets in C and C++
Feature:
Makes it easier for C++ developers to use Motif
Benefit:
* Motif source code compilable by C++ compiler
* Ability to integrate C++ widget extensions (above)
Feature:
Allows easier exploitation of Motif features for end user benefits
Benefit:
XmNotebook
* Subclass of XmManager
* Organizes children into pages, tabs, status area and page scroller
XmContainer
* Subclass of XmManager
* Manages IconGadget children
XmIconGadget
XmComboBox
* Subclass of XmManager
* Combines capabilities of a single line
XmTextField and XmList
XmSpinBox
* Subclass of XmManager
* Manages multiple traversable children
XmScale (thermometer) widget
* Subclass of XmManager
* New resources added for thermometer behavior
XmCSText
* Subclass of XmPrimitive
* Provides facilities which parallel XmText, but using XmString
Uniform transfer model for primary transfer,
* secondary transfer, cut and paste, drag and drop
Uniform API (with backward compatibility)
2 new callback functions for target identifcation
Misc. toolkit enhancements:
* Menu system
Simplified programming of popup menus
Source code reorganization
* X pix map (XPM) format, with multicolor icons
Misc. toolkit enhancements (continued):
* New rendering characteristics for XmString:
renditions (fonts, color), tabs, localization
components, parsing
* List -- Quick navigate
* Traversal -- drawing area traversable via keys,
virtual key associated with multiple real keys
* Visuals (in addition to Toggle Button)
* XmScreen resources
* Resolution independence -- unit conversion
UIL enhancements:
* Support for new and custom widgets
* UID files -- platform independence
* 64-bit architecture support
Updates to documentation: Programmer's Guide, Reference
Updates to OSF training:
* Introduction to Programming
* User Interface Design
* 2.0 Technical Update
Feature:
Allows easy integration of applications with Common Desktop
Environment (CDE)
Benefit:
* Contains foundation GUI for CDE
* Client-command interface allowing other clients to add commands to
MWM menus
Feature:
Allows easy migration of applications to Motif 2.0
Benefit
* Upward binary compatibility of Motif 1.2 toolkit API
(Motif 1.2 applications need only re-link)
Feature
Makes applications easier to troubleshoot & maintain
Benefit
* Overall quality improvements in Motif
* Default density lower than 0.5 DPKLOC
EASE OF USE
Ease of use by individual computer users... at the application user
interface level...
Feature:
Satisfies rising user expectations for ease of use, leveraging
experience with other user interfaces
Benefit:
User interface capabilities equivalent to those on PCs:
* Notebook widget
* Container widget
* ComboBox widget
* SpinBox widget
* Scale (thermometer) widget
* Availability of formatted editable text
Compound String text widget
Compound String enhancements to support color, tabs, multiple
fonts, etc.
* Auto Scrolling
* Vertical Paned Window
* Update to User Guide
Ease of use by individual computer users... at the desktop level...
Feature:
Allows easier integration with the desktop
Benefit:
* Contains foundation GUI for Common Desktop Environment (CDE)
* Tear-off menu support of mwm's root menu
Feature:
Allows more natural organization of users' work
Benefits:
* Virtual screen (desktop panning) support
* Workspace management protocol
(for third party workspace management solutions that
allow users to switch computing context "rooms" for
different tasks)
EASE OF ENTERPRISE COMPUTING
Easier integration of Motif and Motif applications into the
enterprise computing environment...
Feature:
Increases consistency of user interface style across platforms &
applications; increases user skill portability
Benefits:
* Motif 2.0 Style Guide work Technical and terminology convergence
among Motif, CDE and CUA
* New widget support of converged style
* Increased similarity to Windows & CUA behavior:
Check marks and crosses in Toggle Button
Indeterminate state in Toggle Button
Ctrl Button 1 takes focus
Menu unpost behavior
Quick navigate in list
Feature:
Increases consistency of a complete user environment across open
systems
Benefits:
* Consistency with the X/Open CDE specification, including virtually
all CDE Motif vendor extensions:
XmCascadeButton activation via BMenu
Enhanced XmFileSelectionBox
Default XmNshadowThickness to 1
Thermometer-style XmScale
Color pixmaps in XPM format
Additional virtual key bindings
SpinBox, ComboBox
Message catalogs for toolkit error messages
Other items controlled by a global resource:
ColorObject (standarizes colormap allocation for
applications, to enable use of Style Manager application)
BSelect and BTransfer integration
Dragging non-selectable items disabled
Use of TAB key -- XmPushButton navigation
Visual additions to XmToggleButton
Visual modifications to menus (etched in)
Visual modifications to default button in dialogs (focus
highlight outside of default visual)
Visual modifications to MWM
Additional drag icons
* Compliance with IEEE 1295 standard
* Consistency of Motif vendor implementations:
AES Rev D for API stability
Validation Test Suite 2.0 for certification
Updated Quality Assurance Test Suite for consistency in
quality
* Continued support of the X Window system (based on
* X11R5; tested also with X11R6 )
Feature:
Ease of integrating Motif and PC environments
Benefits:
* Favorable licensing terms to support:
PC client-server computing
Deployment of PC applications using Motif DLLs
* Style convergence to support hybrid user environments
WORLD-WIDE ACCEPTANCE
Even more acceptable as the preferred user interface for Open Systems,
worldwide...
Feature
Applicable to a wider range of computer users
Benefits:
* Internationalization enhancements:
New API for widget writers to make use of input methods
Higher level of internationalization for Middle Eastern
languages:
Bi-directional layout -- left-to-right/right-to-left geometry
management
Bi-directional text editing -- left-to-right/right-to-left,
single level (unsupported)
* 64-bit architecture support
* Favorable licensing terms to support:
Single user systems
Embedded systems
Cross-vendor Motif upgrades
Shared library distribution with applications
* Performance
Memory usage
Start-up time, for list widget
Decreased X resource usage
Various optimizations
ADDITIONAL AVAILABLE DOCUMENTS FROM OSF.
OSF/Motif 2.0 Datasheet
OSF/Motif 2.0 Price List
OSF/Motif 2.0 Licensing Kit
OSF/Motif 2.0 Laymen's Explanation
OSF/Motif 2.0 FAQ
X/Journal July-August Feature Article on Motif 2.0
FOR MORE INFORMATION ABOUT OSF/MOTIF 2.0, PLEASE CONTACT OSF DIRECT CHANNELS
AT: (617)621-7300; email: direct@osf.org
OSF and Motif are registered trademarks of the Open Software Foundation, Inc.
[end of message from Darrell Crow (crow@osf.org)]
-----------------------------------------------------------------------------
Subject: 20) Is there a concise features list for Motif 2.1?
[Last modified: Aug 97]
Answer: The Open Group's press release for Motif 2.1 is available at:
http://www.rdg.opengroup.org/press/5feb97.htm
A technical report is also available at:
http://www.opengroup.org/tech/desktop/motif/motif.data.sheet.htm
The major differences from Motif 2.0 are:
1) The CS text widget from Motif 2.0 is not included.
2) Motif 2.0 word-size independent UID files are no longer supported. Only
the Motif 1.2 word-size dependent format is supported.
3) To promote convergence with dtwm, mwm's panning, virtual screen, and
workspace features have been removed
4) Support was added for the X print server, including a new print dialog
widget
5) The Motif libraries are now thread-safe (if the underlying libraries and
system are also thread-safe)
6) Several internationalization features were added, including an on-the-spot
input method and vertical text writing
7) Motif 2.1 is based on X11R6.2 and will work properly with X11R6.3
---------------------------------------------------------------------------
END OF PART ONE
-----------------------------------------------------------------------------
Subject: 21) Where can I find Motif 2.1 documentation?
[Last modified: Mar 98]
Answer: Prentice Hall published the Motif 2.1 documentation in October, 1997.
The books are:
Motif 2.1 - User's Guide (ISBN 1-85912-173-X)
Motif 2.1 - Style Guide (ISBN 1-85912-104-7)
Motif 2.1 - Style Guide Certification Check List (ISBN 1-85912-109-8)
Motif 2.1 - Style Guide Reference (ISBN 1-85912-114-4)
Motif 2.1 - Programmer's Guide (ISBN 1-85912-134-9)
Motif 2.1 - Programmer's Reference, Volume 1 (ISBN 1-85912-119-5)
Motif 2.1 - Programmer's Reference, Volume 2 (ISBN 1-85912-124-1)
Motif 2.1 - Programmer's Reference, Volume 3 (ISBN 1-85912-164-0)
Motif 2.1 - Widget Writer's Guide (ISBN 1-85912-129-2)
A full listing of current Motif and CDE manuals (including various packaged
sets) is available at http://www.rdg.opengroup.org/public/pubs/catalog/mo.htm
Note that the Motif source distribution and many commercial versions come with
the full documentation set on-line.
-----------------------------------------------------------------------------
Subject: 22) Is the official Motif documentation available on-line?
[Last modified: Jun 98]
Answer: SCO has placed the Motif 1.2 documentation set (user's guide, style
guide, programmer's guide, and reference manual pages) on line at:
http://www.premier.sco.com/guide/
I know of no on-line copies of the Motif 2.1 documentation.
Ken Lee, http://www.rahul.net/kenton/
-----------------------------------------------------------------------------
Subject: 23) I want to use C++ with Motif. Where can I find C++ examples?
Motif 2.0 supports native C++ classes but I can't find documentation.
[Last modified: Sept 95]
Answer: Doug Rand <drand@sgi.com> writes: "There are some examples in the
demos tree, look under demos/lib/ExmCxx for widget examples. The C++ support
was only a widget writer's tool. When the widget writer's guide is out, you
can also look in that for documentation."
Scott W. Sadler <sws@iti-oh.com> replied to a related question about combining
Motif with C++: "There are two books available (that I know of):
Object-Oriented Programming with C++ and OSF/Motif - Second Edition
Doug Young 0-13-209255-7 (c) 1995
Using Motif with C++
Daniel Bernstein 0-13-207390-0 or 1-884842-06-2 (c) 1995"
See also the subject: "Is there a C++ binding for Motif?"
-----------------------------------------------------------------------------
Subject: 24) Is Motif 2.0 backward compatible with Motif 1.2? Does a program
written for Motif 1.2 compile and run with Motif 2.0?
[Last modified: Jan 96]
Answer: (See also the next subject.) Doug Rand <drand@sgi.com> writes: "It is
backward compatible except where it isn't :)
1) Subclassed widgets which do not use XmResolvePartOffsets won't work.
2) If you free your XmStrings using any technique other than XmStringFree, it
is quite likely that your program either won't compile, or will crash with a
core dump at runtime. [Wording change for (2) provided by Alan Ezust
(ezust@learnix.ca).]
3) If you use libMrm and relink with the new shared library, you'll need to
make the new modern .uid files (but if you wait for the Motif from CDE you
don't need to do this one).
4) If you assume that XmStrings are ASN.1 strings and play with them, it won't
work. They are now data structures. But the good news is that XmStringCopy
just increments a reference count now.
Note that #1 and #2 where always documented this way and aren't supposed to
work.
Otherwise, it's pretty compatible. We relinked a number of things and they
continued fine. [These] include xrn (Motif), and a couple of other moderately
big things. I want to say we did xmosaic, but I can't remember if I'm right
about that.
#1 isn't a problem if you recompile your subclassed widgets. But then there
is a source compatibility problem that you may need to include the obsolete
modules for the _Xm functions. Proper 2.0 subclasses use Xme functions, and
there is even a document."
-----------------------------------------------------------------------------
Subject: 25) How compatible are Motif 1.2.* and X11R6?
[Last modified: July 96]
Answer: (See also the previous subject.) This is actually several related
questions with answers from David B. Lewis (d.lewis@opengroup.org) and Kenton
Lee (http://www.rahul.net/kenton/).
1. Is it possible to run an X11R6 server with a Motif 1.2.* runtime
environment (Motif libs and Motif Window Manager)?
David> Yes. The X11 protocol has not changed in its various versions, so
all X servers are compatible. There are differences, though, in
the fonts that are available and in a few of the gray areas in the
interpretation of the protocol. The fonts distributed by the X
Consortium form a standard set, though, and I know of no cases in
which changes in X11R6 cause problems for Motif programs (we are
using Motif with X11R6 servers here).
2. Is there any possible conflict with Motif 1.2.* applications and an
X11R6 server (assuming a Motif 1.2.* runtime environment)?
David> The only situation that I could imagine is a case in which Motif
1.2 code was written to depend on a particular bug or behavior of
an X11R5 server; I know of no such cases. Because of the stability
of the X11 protocol, Motif 1.2 programs should work with any
available X server, current and future.
3. If Motif 2.0 is installed such that the Motif libraries and mwm are
versions 2.0, is there 100% binary compatibility with statically linked
Motif 1.2.* applications? If not, what are the known or potential problems?
David> There are additional support files in both the Motif and X11 areas
which are used at run-time. There are no known problems using Motif
1.2 *static* applications in a Motif 2.0 environment.
Kenton writes: R6 was designed to be backwards binary compatible with R5 and
most vendors have done a good job in implementing this. Still, I wouldn't
recommend that my customers do this until I tested configurations similar to
theirs.
Motif 2.0 is backwards compatible with Motif 1.X in most cases. I think Doug
Rand's comments in [the previous subject of the Motif FAQ] covers the
important issues. In general, well written applications shouldn't have
problems, but some applications aren't well written. Again, I would test
before making recommendations to my customers.
The above comments apply to run-time linking (shared library) compatibility.
If you statically link, the only problems I can imagine are the common ones
like installed fonts, supported server extensions, input methods, color name
databases, default visual types, etc.
-----------------------------------------------------------------------------
Subject: 26) Why aren't the big UNIX vendors shipping Motif 2.0?
[Last modified: Aug 98]
Answer: Most of these companies decided to move to CDE 1.0 first. CDE 1.0
uses Motif 1.2.5, which is not binary compatible with Motif 2.0.
Motif 2.1 was released in February, 1997. Motif 2.1 is compatible with CDE
2.1 and (mostly) Motif 1.2. You should expect the big UNIX vendors to start
shipping Motif 2.1 when they start shipping CDE 2.1.
Ken Lee
-----------------------------------------------------------------------------
Subject: 27) Where can I get Motif for UNIX, Linux, or Microsoft Windows?
[Last modified: Jun 98]
Answer: A regularly updated list of Motif vendors for various operating
systems (including Linux and Microsoft Windows) is available at:
http://www.rahul.net/kenton/GettingMotif.html
Please send any corrections to kenton@nojunk.rahul.net
-----------------------------------------------------------------------------
Subject: 28) 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: 29) Where can I get a Motif 1.2 Certification Checklist?
[Last modified: Apr 95]
Answer: Kevin Till (kev@osf.org) of OSF wrote: "The Checklist comes with the
OSF/Motif 1.2 Style Guide documentation. It's in the Appendix B section."
-----------------------------------------------------------------------------
Subject: 30) What is CDE? What is COSE and how does it relate to Motif?
[Last modified: Sept 94]
Answer: [For more current information, see also the subjects which follow
this one.]
NOTE: This info dates back to a Nov. '93 conference.
Most of the words should be credited to the lecturer,
Nicholas J. Aiuto (nick@ps.quotron.com) of Cadence Design Systems, Inc.
Any mistakes or inaccuracies are mine, however.
I would appreciate updates and corrections...kenton@nojunk.rahul.net
COSE is Common Open Software Environment, a major interoperability effort
started by HP, Sun, Novell/UNIX System Labs (USL), IBM, and SCO, with over 70
other companies pledging their support. The COSE announcement was made in
March, 1993 and a "COSE CDE Conference" was held in San Jose in October, 1993.
CDE is the Common Desktop Environment component of COSE. CDE is "a
specification for components and services to give the UNIX desktop common and
consistent capabilities like those found in other widely used environments
(Mac, Windows)." [from class notes] CDE is not public domain; it will be
provided by major vendors, possibly at extra cost as unbundled s/w
approximately mid 1994. CDE will be based on Motif 1.2 and X11R5, although
Motif 2.0 and X11R6 are expected around the same time. (CDE will be ported to
Motif 2.0 eventually.)
A CD-ROM was distributed at the October, 1993 conference, but this was "alpha"
s/w, strictly for evaluation purposes, not for development.
Another COSE/CDE Snapshot CD-ROM was released in April '94, available for HP,
IBM, Novell, and Sun platforms.
Overview
--------
Standards are to be defined in these areas:
- desktop
- networking
- objects
- graphics
- system management
CDE Functional Groups:
High Level:
- Desktop Management
- Productivity Tools
Low Level:
- GUI Display and Printing
- Application Integration
- "Guidelines": a 100+ pg. checklist which is a superset of Motif's
CDE Desktop Management
----------------------
- Login Manager: like xdm
- Session Manager: saving state based on ICCCM and HP's VUE [vuesession]
- Workspace Manager: virtual screens; rooms; virtual win mgr
- Front Panel: object and window management; access to favorite apps
- File Manager: icon drag and drop
- Application Manager
- Style Manager: configure Session Mgr (colors, fonts, HOME session)
Productivity Tools
------------------
- Text Editor: based on XmText widget; not very fancy
- Icon Editor: color pixmaps; based on HP's vueicon; need 16 icons per app
- Help Viewer: can access app help without running application
- Mailer and Calendar: can talk to each other
- Terminal Emulator: improvement on xterm
- Calculator
- Create "Action": something you tell your system to do and associate with
a specific icon (e.g., starting a favorite app); can also
tag a specific command line and add to your desktop
GUI Display and Printing
------------------------
- Motif 1.2 with extras, X11R5
- New widgets (subclasses of similar widgets to be in Motif 2.0):
o ComboBox
o SpinButton
- dtksh: windowing Korn shell, a robust UNIX shell interface to X, Xlib, and
Xm
- Application Builder: port of Sun's DevGuide [not yet available]
- X Print Server and X Server Print Extension
Application Integration
-----------------------
- Data Interchange
o Drag and Drop (DND): based on Motif 1.2 with improvements
o Bento container format:
"Japanese lunchbox"
compartmented container developed by Apple;
stores compound document on disk;
apps can find audio compartment, for example
100-page document describes Bento
- ToolTalk
o messaging/IPC facility developed by Sun
o CDE message sets (sample msgsd: iconify yourself, close down, etc.)
- Actions
o define what can be done with files or arbitrary data (e.g., audio)
- Data Typing
o define data classes for objects (e.g., PS file, C source code)
Guidelines
----------
- Common Fonts (about 16): proportional, monospaced, with or without serif
- Internationalization (I18N) compliance
- Client/Server
o Network execution model
o end user model
o system admin model: facilitates easy installation of new
CDE-compliant apps
o ISV model
- Certification Checklist: 100 pages; superset of Motif 1.2 Certif. Checklist
-----------------------------------------------------------------------------
Subject: 31) Is there a CDE FAQ or newsgroup?
[Last modified: Mar 98]
Answer: The CDE FAQ is located at:
http://www.pobox.com/~burnett/cde/index.html
There is also a newsgroup called news:comp.unix.cde
-----------------------------------------------------------------------------
Subject: 32) What is the current version of CDE and what are its features?
[Last modified: May 97]
Answer: The latest version of CDE is 2.1 as announced by OSF in February 1997.
The following is the Open Group's press release:
FOR IMMEDIATE RELEASE CONTACT
Jane Smeloff
The Open Group
(617) 621-8997
j.smeloff@opengroup.org
Marilyn Kilcrease
Fleishman Hillard, Inc.
(415) 356-1031
kilcream@fleishman.com
The Open Group Announces Common Desktop Environment 2.1
New features enhance the functionality and ease of use of the widely used
graphical user interface for open desktop computing
CAMBRIDGE, Massachusetts (February 5, 1997) - The Open Group, the leading
organization for the advancement of open systems, today announced the release
of CDE 2.1, the latest version of The Open Group's Common Desktop Environment.
The current release integrates the Motif 2.0 graphical user interface, X
Window System, and CDE to standardize application presentations in distributed
multi-platform environments.
"As a result of solid cooperation among project participants, we are
delivering significant new features which makes CDE and Motif a unified face
for UNIX environments," said Dave Lounsbury, vice president of collaborative
development. "The CDE 2.1 project was the most extensive collaborative
development effort in the history of The Open Group."
The latest release of CDE features enhanced tools for creating integrated
graphical desktop applications. New features include thread-safe libraries,
64-bit system support, an X-based printing solution that implements a standard
way of printing from any application, an enhanced, SGML-based on-line help
system with a complete documentation set, "on the spot" input, and user-
defined characters for Asian languages. Many capabilities have been added to
ease programming, including traits, which enable user interface objects to
automatically inherit multiple API specifications, and a uniform transfer
model, which offer developers a consistent means of coding the different
data-transfer mechanisms (such as cut-and-paste and drag-and-drop). The new
release also provides a simple means of coding pop-up windows.
CDE 2.1 also incorporates Motif 2.0 user interface objects (widgets) spin box,
combo box, container, and notebook. With this release, the style guides for
CDE and Motif converge.
The fee for a CDE 2.1 full-distribution source code license is $40,000. An
evaluation copy of source code costs $5,000. To order CDE 2.1, contact Open
Group Direct, at 1-800-268-5245, or send e-mail to direct@opengroup.org.
Introduced in 1995, CDE was jointly developed and licensed by Hewlett-Packard,
IBM, Novell, and SunSoft. Since that time, the technology has evolved within
The Open Group's Pre-Structured Technology (PST) process, a multi-vendor
technology development program. Currently, Hitachi, Fujitsu, Digital Equipment
Corporation and SCO work with the original CDE sponsors, IBM, HP and SunSoft
within the Open Group's PST framework, to provide for the maintenance of CDE
and the development of new releases.
The Common Desktop Environment is a graphical user interface that delivers
consistency and ease of use to system administrators as well as end users.
With CDE, system administrators gain a degree of control over the desktop
computing environment that has often been lost in the move from centralized to
client-server or distributed computing. CDE gives end users access to the
power and flexibility of today's networked desktop systems.
The Open Group
Dedicated to the advancement of multi-vendor information systems, The Open
Group is an international consortium of systems and software vendors and
customers from the industry, government and academia. The Open Group and its
members work together to strengthen and streamline the development process and
availability of open systems. The organization provides a focal point for the
development of international specifications and test suites, standards based
technologies, advanced open systems research, professional services and the
management of the internationally recognized brand for open systems. The Open
Group's brand mark is recognized worldwide and is a guarantee of compliance to
open systems specifications. The Open Group is Headquartered in Cambridge, MA,
with European headquarters in Reading, England and offices in Menlo Park, CA;
Brussels, Belgium; Grenoble, France; and Tokyo, Japan.
The Open Group is a trademark of the Open Software Foundation, Inc. and X/Open
Company Ltd. OSF/Motif and Motif are registered trademarks of The Open Group.
X Window System is a trademark of The Open Group and the X Consortium is a
trademark of The Open Group. UNIX is a registered trademark in the US and
other countries, licensed exclusively through X/Open Company Ltd. All other
products or company names mentioned are used for identification purposes only,
and may be trademarks of their respective owners.
-----------------------------------------------------------------------------
Subject: 33) How does Motif relate to X/Open and CDE?
[Last modified: Mar 96]
A. NOTE: This answer from Sept. 1995 is somewhat obsolete due to the
formation of The Open Group. See "What is The Open Group?"....ksall@cen.com
From OSF's CDE/Motif Program Manager, Terry Landers (landers@osf.org):
"In response to the discussion [on comp.windows.x.motif] of Motif and
"officially supported" APIs ... two areas were brought up that I hope to be
able to clarify.
Standards:
=========
As you probably know, Motif has become an X/Open standard.
The X/Open specification was based on the OSF AES, and going
forward the X/Open specification will take precedence.
As part of the CDE/Motif PST, interface extensions to
the XMotif specification will be proposed to X/Open.
Although it is too early to discuss what will be proposed
to X/Open, OSF members who are interested will have early
access to CDE/Motif functional specifications as part of
the Desktop SIG activities.
Convergence:
===========
OSF has taken the first step in convergence with the release
of Motif 1.2.5. Motif 1.2.5 merges OSF Motif 1.2.4 with
CDE Motif and defect fixes to the 1.2 code base that were
made in Motif 2.0.
The next step in convergence will come with the CDE/Motif PST
deliverables.
I hope this has helped ... if you have any questions you can
contact me at:
landers@osf.org
617-621-7282"
-----------------------------------------------------------------------------
Subject: 34) What is The Open Group?
[Last modified: Aug 97]
Answer: On February 14, 1996, X/Open and OSF merged to form "The Open Group".
which calls The Open Group a "New Organization to Improve Coordination of
Efforts to Develop and Implement Common Standards and New Technologies". You
might also want to read other press releases from The Open Group and visit
their home page:
http://www.opengroup.org/
Below is the announcement sent by OSF's Kristen Knotts...ksall@cen.com
To: OSF.Support.Subscribers:;@osf.org
Subject: X/Open & OSF Join to Form The Open Group
Date: Wed, 14 Feb 1996 12:26:53 -0500
From: Kristen Knotts <kjk@osf.org>
During a press conference at UniForum '96, officials of X/Open Company,
Ltd. and the Open Software Foundation (OSF), the two leading consortia for
the advancement of open systems, announced their consolidation into a new,
more powerful worldwide organization known as The Open Group.
The new entity has been formed to strengthen and streamline the entire open
systems process, including adoption of open systems specifications,
development of specification-compliant technologies, and promotion of their
use in the global enterprise computing marketplace. Full information can
be obtained from The Open Group Web Site:
http://www.opengroup.org/
-----------------------------------------------------------------------------
Subject: 35) Is The Open Group assuming responsibility for the X Window
System?
[Last modified: July 96]
A. Yes it will, at the beginning of 1997. See the X Consortium's announcement
at:
X Consortium to Transfer X Window System to The Open Group
It is reproduced _in part_ below for your convenience, followed by a related
announcement from The Open Group.
Cambridge, Massachusetts - July 1, 1996 - X Consortium, Inc.
today announced that it would transfer responsibility for the X
Window System to The Open Group at the beginning of next year. "X
is now mainstream technology, and since the first commercial release
in 1986 it has matured to the point where a dedicated consortium is no
longer essential to its on-going support," explains Robert W. Scheifler,
president of the X Consortium. "Our industry will benefit greatly by
continuing and accelerating the convergence of X, Motif and the
Common Desktop Environment (CDE) into a unified technology
stack. This is already well underway with the current CDE-Motif
PST project, operating under the auspices of The Open Group, an
organization that is well positioned to take this technology into the
future." The Open Group will continue their existing work of
publishing, testing and branding products which conform to
international standards, including X.
"As a long standing partner with the X Consortium in the Open
Systems industry, The Open Group supports this decision. On a
personal note, I want to add that the computer industry owes an
enormous debt of gratitude to Bob Scheifler and the X Consortium for
the service they have provided for the last eight years," commented
Jim Bell, CEO of The Open Group. "Their very positive impact on our
industry will continue to be felt for years to come."
As part of this change, X Consortium plans to wind down all
engineering operations at the end of this year. "I have made a
commitment to our members, and to the sponsors of the CDE-Motif
project, to oversee the entire transition process from now until our
current engineering projects are finished and the hand-off is
complete," said Scheifler. The X Consortium will work with its
members and The Open Group to determine whether the organization
should continue on in some reduced fashion.
Broadway, the code name for the next release of the X Window
System, will be completed as planned by the end of the year, and will
be made freely available to the public under the same terms as
previous X Consortium releases. Broadway enables interactive UNIX
and Windows applications to be integrated, unmodified, into HTML
documents and published on World Wide Web servers, using plug-in
technology, and includes network protocols for graphics and audio to
provide remote access to those applications from inside Web
browsers. The Broadway release is expected to be available from
current sources, including worldwide ftp sites and CDROM
distributors.
The X Consortium will fulfill its obligations as prime contractor in The
Open Group's Pre-Structured Technology (PST) project developing
the next release of CDE and Motif. "The plan has always been to
complete both the CDE-Motif project and Broadway by the end of
this year," says Jim Fournier, Director of Engineering. "We are
confident in our ability to deliver as planned."
************************
A related announcement from corpcom@opengroup.com (The Open Group Corporate
Communications) was sent July 1, 1996, an excerpt of which appears below:
The Open Group Continues to Expand Product and Services Portfolio
Leading Open Systems Consortium
Absorbs X Window System Technology
The Open Group announced today as an addition to its growing portfolio of
products and services, it will assume custodianship for the X Window System
technology, currently owned and managed by the X Consortium. In its
press release today, the X Consortium also declared that it will continue to
fulfill its obligations as prime contractor in The Open Group CDE Pre-
Structured Technology (PST) project, developing the next releases of CDE and
Motif, scheduled to be completed by year end, and then cease its internal
engineering operations.
"Since its first commercial release in 1986, the X Window System has
matured to the point where a full-scale, dedicated consortium is no longer
essential to the on-going support of the technology," said Robert W. Scheifler,
X Consortium president and founder. "In light of our existing relationship it
makes sense to fold our ongoing work into The Open Group. Furthermore,
given the overlapping membership of the two organizations, this move will
greatly streamline and enhance the process of defining open standards."
-----------------------------------------------------------------------------
Subject: 36) What are the current correct trademark statements for X and
Motif?
[Last modified: May 97]
Answer: The Open Group is a trademark of the Open Software Foundation, Inc.
and X/Open Company Ltd. OSF/Motif and Motif are registered trademarks of The
Open Group. X Window System is a trademark of The Open Group and the X
Consortium is a trademark of The Open Group. UNIX is a registered trademark
in the US and other countries, licensed exclusively through X/Open Company
Ltd.
-----------------------------------------------------------------------------
Subject: 37) Will CDE and Motif converge? What is the CDE/Motif JDA?
[Last modified: May 97]
Answer: I'm leaving the following announcement here for historical reference.
Note that the converged CDE/Motif was released in February, 1997 and is called
CDE/Motif 2.1. A press release is included earlier in this FAQ.
In September, 1995, OSF announced the Joint Development Agreement under which
vendors will participate in a plan to converge Motif and CDE. The announcement
follows.
From kjk@osf.org Fri Sep 8 17:55:55 1995
To: OSF.Motif.Support.Subscribers:;@osf.org
Cc: OSF.Service.Subscribers:;@osf.org
Subject: OSF Press Release Announcing Signing of CDE/Motif JDA
Date: Fri, 08 Sep 1995 17:46:04 -0400
From: Kristen Knotts <kjk@osf.org>
To: OSF Motif Support Subscribers
From: The Open Software Foundation
************************************************************
OSF MOTIF SUPPORT ELECTRONIC UPDATE
************************************************************
An electronic mail news update for Motif Support Subscribers
from the Open Software Foundation (OSF)
CONTACT: Jack Dwyer
Open Software Foundation
(617) 621-7246
Email: dwyer@osf.org
OSF Announces Formal Launch of CDE/Motif Project
Multi-vendor project to enhance and converge OSF/Motif and the Common
Desktop Environment
CAMBRIDGE, MA September 7, 1995 -- The Open Software Foundation today
announced the formal signing of the Joint Development Agreement for the
further enhancement and evolution of the Common Desktop Environment (CDE)
and OSF/Motif under the Open Software Foundation's Pre-Structured
Technology (PST) development process. The seven sponsors of the CDE/Motif
PST are Digital Equipment Corp., Fujitsu Limited, Hewlett-Packard Company,
Hitachi, Ltd, IBM Corp., Novell, Inc., and SunSoft, Inc.
The CDE/Motif PST is a cooperative, multi-vendor, development project. The
Open Software Foundation's PST process allows for existing technologies
from multiple vendors to be further developed and integrated into a
complete open system technology. The X Consortium has been designated as
the project's prime contractor.
CDE/Motif will continue the evolution of the desktop technologies necessary
to meet the expanding user requirements in such areas as On-line
Information Access, Printing, and Internationalization. A key objective of
the PST is to fully converge OSF/Motif and the CDE version of Motif into a
single development stream. The resulting PST technology will be binary
compatible with CDE 1.0.
Mr. Don Harbert, Vice President of UNIX Business Segment for Digital
Equipment Corporation said, "Digital is an enthusiastic participant in the
development of the next version of CDE. As a founding member of the Open
Software Foundation and the first vendor to ship a commercial version of
the X Window System, Digital recognizes the importance of standard user
interfaces and the importance of the PST process in developing code."
"Fujitsu is pleased to support the evolution of CDE and Motif technology,
both by contributing the Fujitsu OLIAS technology for a robust CDE Online
Information Access feature, and by improving CDE/Motif
Internationalization. Providing a common user interface over many different
hardware systems is critical to the future of Open Systems", said Mitsuru
Sanagi, General Manager of the Client Server System Strategy and Alliance
Division, Fujitsu Limited.
"As one of the original development partners for CDE and as a current
supplier of CDE technology in AIX, IBM is committed to enhanced usability
for our AIX customers," said Donna Van Fleet, Vice President for AIX
Systems Development, IBM RISC System/6000 Division. "Now, as one of the
sponsors of this new PST, we continue the enhancements to CDE that will
provide even more ease-of-use value for our customers, while maintaining
all the benefits of an open technology."
"CDE is important, industry-unifying technology and Novell is looking
forward to working with the other CDE/Motif sponsors to continue its
development," noted Don McGovern, Vice President, Operating System
Division, Novell, Inc.
"As chair of the CDE/Motif PST Steering Committee, SunSoft is pleased by
the active participation and strong commitment for this project. This
clearly underscores the strong industry support for open systems," said
Paula Sager, Vice President of Desktop Technologies, SunSoft, Inc. "We are
looking forward to working with our partners to deliver the best open user
environment available."
"We're excited that we are able to contribute to this important industry
initiative ", said Robert W. Scheifler, President of X Consortium.
"CDE/Motif combines premier desktop technologies and builds on what is now
a long line of products founded upon X. There is a lot of synergy between
the X Consortium's objectives and the goals of the CDE/Motif PST. Our
involvement as the prime contractor for this project is a logical extension
of that fact."
The base technologies for the CDE/Motif PST are CDE 1.0 and OSF/Motif 2.0.
On-line Information Access will include an SGML-based browser, the ability
to display and print SGML documents, full text search and retrieval, and
integration with the on-line help facility. Enhanced internationalization
capabilities will include the ability to display vertical text, support for
user defined characters, input method selection at run time, and an
on-the-spot input method capability. Print capabilities include a graphical
interface for print job submission, a single API for both display and
printing, printing support for Motif text and label widgets, help,
calendar, mail and the text editor. In the process, CDE/Motif will be made
thread safe and will include support for 64-bit architectures.
The output of this PST joint development will be a merged CDE/Motif source
package, a standalone version of Motif, and conformance tests for both CDE
and Motif. Upon completion, the conformance test suites will be offered to
X/Open for their branding purposes. Also offered to X/Open will be a merged
style guide for CDE and Motif, the Motif Drag and Drop protocol, and API
extensions to CDE and Motif.
The first deliverable of the CDE/Motif PST will be a maintenance release
for CDE 1.0 planned for the end of 1995. The schedule further calls for a
CDE/Motif snapshot to be made available to licensees in mid-1996, with
general availability of CDE/Motif scheduled for the end of 1996.
For more information on CDE/Motif, you are invited to contact David Knorr,
OSF CDE/Motif Business Area Manager, at +617-621-7227 or dknorr@osf.org.
The Open Software Foundation delivers technology innovations in all areas
of open systems, including interoperability, scalability, portability, and
usability. OSF has created a coalition of worldwide vendors and users in
industry, government and academia that leverage their economic investments
by working together to provide the best open systems technology solutions
for distributed computing environments. Headquartered in Cambridge, MA,
with offices in Brussels, Grenoble and Tokyo, OSF has more then 380 members
worldwide.
###
OSF, OSF/Motif, and Open Software Foundation are trademarks of the Open
Software Foundation, Inc.
-----------------------------------------------------------------------------
Subject: 38) Where can I get public domain Motif source?
Answer: You cannot. Motif source is not publically available. However, see
"Has anyone done a public domain Motif lookalike?"
-----------------------------------------------------------------------------
Subject: 39) Are Motif code examples publically available?
[Last modified: May 95]
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.
Source code posted to comp.sources.x often uses Motif.
In addition, many Motif programs are available via anonymous ftp from
ftp.x.org. The following are listed alphabetically by author. (See the
"BOOKS" topic.)
If you don't understand the URL notation below, see 'What is an URL?' subject.
Thomas Berlages's book:
ftp://ftp.x.org/R5contrib/berlage.motif.tar.Z
Dan Heller's book:
ftp://ftp.x.org/R5contrib/OReilly/motif/examples.tar.Z
Donald L. McMinds's book:
ftp://ftp.x.org/R5contrib/mastering.motif.tar.Z and
ftp://ftp.x.org/R5contrib/master.1.2.tar.Z
Jan Newmarch's book:
ftp://ftp.x.org/R5contrib/newmarch.tar.Z
Jerry Smith's book:
ftp://ftp.x.org/R5contrib/smith.ooxt.tar.Z
Doug Young's source code for the current editions of his several books:
ftp://ftp.x.org/contrib/book_examples/young.cxx.tar.Z
ftp://ftp.x.org/contrib/book_examples/young2.motif.tar.Z
ftp://ftp.x.org/contrib/book_examples/young.debug.tar.Z
Doug Young's examples for OLDER editions of his books:
ftp://ftp.x.org/R5contrib/young.cxx.tar.Z
ftp://ftp.x.org/R5contrib/young.motif.tar.Z
ftp://ftp.x.org/R5contrib/young.motif2.tar.Z
ftp://ftp.x.org/R5contrib/young.tar.Z
Examples appearing in "The X Resource" (by O'Reilly and Associates) appear
organized by issue in the directory:
ftp://ftp.ora.com/pub/examples/xresource or:
ftp://ftp.uu.net/published/oreilly/xresource
Examples from O'Reilly and Associates books can be found in subdirectories of:
ftp://ftp.ora.com/pub/examples/xbook or:
ftp://ftp.uu.net/published/oreilly/xbook
Also from a list maintained by: qizeng@acsu.buffalo.edu (Qi Y. Zeng) FTP sites
for X/MOTIF source code examples:
ftp://ftp.uu.net/published/books/brain.motif.tar.Z
ftp://ftp.uu.net/published/books/pwm-examples.tar.Z
Marshall Brain's Motif tutorials can be found at:
http://www.iftech.com/
Thanks to Steve Swanson <swany@math.lsa.umich.edu>, the following code
examples correspond to Programming with Motif, Keith D. Gregory, Springer-
Verlag, 1992, which apparently is more suited for Motif/X beginners.
ftp://ftp.x.org/R5contrib/pwm-xmpl.tar.Z
-----------------------------------------------------------------------------
Subject: 40) Has anyone done a public domain Motif lookalike?
[Last modified: Feb 99]
Answer: LessTif is a freeware version of Motif from the Hungry Programmers.
It is still in development and is intended to be source code compatible with
Motif, meaning that the same source will compile with both libraries and work
exactly the same. [Thanks to John W. Carbone, jwc@li.net, Chris Toshok
(toshok@hungry.com), and Jon Fo (jonf@protocol.com)] For more information, see
http://www.lesstif.org/
Tcl/Tk is available for ftp from allspice.berkeley.edu, and although
implemented without Xt, has a "strict Motif" mode. There is also Tix, the Tk
Interface Extension. See:
http://www.sunlabs.com/research/tcl/
http://www.cis.upenn.edu/~ioi/tix/tix.html
Strom Sytems (18666 Redmond Way o-2118, Redmond, WA 98052-6725) have a Simple
Toolkit for X-Windows (sic) that appears to follow the Style Guide even though
it doesn't quite look like Motif.
MOOLIT is a USL product that can be runtime switched between the Sun Open Look
and Motif appearance. It is based on OLIT 4i.
Interviews is a C++ based product with appearance similar to Motif. A ftp-
able version of the source code and documentation can be found on
interviews.stanford.edu. Fresco (http://www.iuk.tu-harburg.de/fresco/) and
ivtools (http://www.vectaport.com/ivtools/) are based on Interviews.
Simon J. Lyall (simon@darkmere.midland.co.nz) reported about a package called:
Xu-lib & Widget Set- a library & widget set to "emulate" the look&feel and the
programming interface of Motif. Contact the author Udo Baumgart
(U.BAUMGART@ldb.han.de) for details.
-----------------------------------------------------------------------------
Subject: 41) Does anyone from the Open Group 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 the Open Group, and has no formal connection with the
Open Group. The Open Group is a member-driven company. The membership (and
anyone can be a member) provides the primary input for future development of
Motif.
-----------------------------------------------------------------------------
Subject: 42) Does the Open Group have an application compliance validation
service?
[Last modified: Aug 97]
Answer: The Motif Toolkit API Verification Suite (VSM4) replaces the earlier
Motif Branding Program. For more information on VSM4, see
http://www.opengroup.org/tech/desktop/ordering/motif.price.list.htm#branding
-----------------------------------------------------------------------------
Subject: 43) 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: 44) 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: 45) How does Motif work with X11R5?
Answer: Motif 1.1.X is only intended to be built with X11R4. Motif 1.2.X is
for X11R5. however, Motif 1.1.4 has been set to also work with X11R5.
For Motif 1.1.1, 1.1.2 and 1.1.3 you will need to compile Xlib and Xt with a
MOTIFBC flag set to YES (page 8, section 3.3 of the R5 release notes), or
you'll also have a link problem (LowerCase) and a fatal run time problem
(XContext manager). If your applications come up with "Unknown keysym name:
osfActivate" errors, check the variable ProjectRoot. The name
/$PROJECTROOT/lib/XKeysymDB will have been wired into your Xlib.
In Motif 1.1.0, XtCallCallback uses NULL as the first argument instead of a
widget ID. This was ok under R4, but must be changed in the source for R5. It
was changed by OSF from Motif 1.1.1 onward.
Mrm won't work at all (can't link since it uses an X private variable that has
disappeared in R5). There is an MIT patch that may fix this??
-----------------------------------------------------------------------------
END OF PART TWO
-----------------------------------------------------------------------------
Subject: 46) TOPIC: X and MOTIF on the WORLD WIDE WEB (WWW)
-----------------------------------------------------------------------------
Subject: 47) Is there a central location for Motif information on the WWW? Is
there a home page for Motif developers?
[Last modified: Nov 96]
Answer: On March 31, 1995, Ken Sall announced a Web page called:
"MW3: Motif on the World Wide Web"
http://www.cen.com/mw3/
MW3 is a meta reference intended to connect you to a wealth of resources for
Motif and X Window System development. MW3 presently contains over 700 links!
The current Table of Contents follows:
FAQs: Frequently Asked Questions
Widgets, Toolkits, Libraries, and GUIs
Organizations
Motif Providers
Non-Commercial Applications and Shareware
Multimedia
Commercial Products and Vendors
Publications and References
Code Examples and Tutorials
Tips and Pointers
Security
Internationalization
Usenet Newsgroups
Conferences
Personal Home Pages
MW3 is sponsored by Century Computing, Inc.
-----------------------------------------------------------------------------
Subject: 48) Where can I find X technical info on the WWW?
[Last modified: Mar 96]
Answer: If you couldn't find what you were looking for in "MW3: Motif on the
WWW" (http://www.cen.com/mw3/), then check Ken Lee's excellent page:
Technical X Window System and OSF/Motif WWW sites
http://www.rahul.net/kenton/xsites.html
This web site currently lists over 700 X Window System links, including
technical papers, tutorials, FAQs, product reviews, etc. This site is more
technical and less product oriented than the MW3 site listed above. Visit
them both; one probably has what you want.
-----------------------------------------------------------------------------
Subject: 49) What is Broadway? I've heard it called "X on the Web".
[Last modified: Jun 98]
Answer: Broadway was the X Consortium's internal code name for the X11R6.3
release. It includes a collection of X-based technologies for the World Wide
Web. For details, see:
http://www.camb.opengroup.org/tech/desktop/x/broadway.htm
And if you're wondering. "Why did they call it Broadway?", the X Consortium
was located at 201 Broadway, Cambridge, MA.... ksall@cen.com
-----------------------------------------------------------------------------
Subject: 50) Where's an HTML version of the Motif FAQ on World Wide Web
(WWW)?
[Last modified: Feb 95]
Answer: An automatically generated HTML version of this Motif FAQ can be found
at WWW URL:
http://www.cis.ohio-state.edu/hypertext/faq/usenet/motif-faq/top.html
For a searchable version of the Motif FAQ and other FAQs (via WAIS), see:
http://www.cs.ruu.nl/cgi-bin/faqwais
The WAIS search is great way to find a topic which may appear in several FAQs
(Motif, X, Xt, Widget FAQ, etc.)
-----------------------------------------------------------------------------
Subject: 51) Where can I get the HTML widget used in Mosaic?
[Last modified: Mar 96]
Answer: Thanks to Matthew Freedman (mattf@cac.washington.edu) and
intasoft@cix.compulink.co.u for updates to the URLs mentioned in this answer.
If you can't find things in the places listed below, check MW3
(http://www.cen.com/mw3/) which is updated more frequently than is this FAQ.
Also see the question "Is there a help system or Motif hypertext system
available?"
Ken Sall (ksall@cen.com) writes: The HTML (HyperText Markup Language) widget
is part of the NCSA Mosaic source code available from ftp.ncsa.uiuc.edu. Look
in the "libhtmlw" subdirectory of the "Mosaic-src-*" subdirectory of:
ftp://ftp.ncsa.uiuc.edu/Mosaic/Unix/source/
or, more generally, look for the files HTML.c, HTML.h, HTMLP.h, etc. in your
"libhtmlw" subdirectory of the Mosaic source.
For (old) documentation, see
http://www.ncsa.uiuc.edu/SDG/Software/Mosaic/Docs/htmlwidget.html.
However, Matthew M. Freedman (mattf@cac.washington.edu) pointed out the
document is out of date: "One important thing to know is that the on-line
documentation for the Mosaic html widget is out of synch with the source code.
I e-mailed NCSA about this in May, but they seem to have ignored the report.
The one that I wasted half a day because of is HTMLSetText(). The on-line docs
list four arguments, but in fact there are seven. I have no idea what the
extra three undocumented parameters are used for, I just plugged in NULL's and
it works. The other error I noticed is that they document a "page" field in
WbAnchorCallbackData, but it does not actually exist. Also, at least for me,
after I call HTMLSetText() the first time, the widget remains blank. I have to
lower and raise the window for it to be drawn. Anybody know what is wrong? I
guess will probably just spoof an expose in my code."
For information on using Mosaic by remote control, see
http://www.ncsa.uiuc.edu/SDG/Software/XMosaic/CCI/cci-spec.html
and
http://www.ncsa.uiuc.edu/SDG/Software/Mosaic/Docs/remote-control.html
Here are more details from ah627@FreeNet.Carleton.CA (Samuel Effah):
To the numerous request for the NCSA HTML widget information.
Everything not already copyrighted by CERN is copyrighted by NCSA (including
the contents of the libhtmlw, libnet, libXmx, and src directories, but not
including the contents of libdtm, which is entirely public domain). ...
* The UI grants you (hereafter, Licensee) a license to use the Software *
* for academic, research and internal business purposes only, without a *
* fee. Licensee may distribute the binary and source code (if released) *
* to third parties provided that the copyright notice and this statement *
* appears on all copies and that no charge is associated with such *
* copies. *
* *
( you can read more about the copyright in the Mosaic source code ).
Documentation on the HTML widget can be located at:
http://www.ncsa.uiuc.edu/SDG/Software/Mosaic/Docs/htmlwidget.html
( it's on the older version, I think Mosaic1.x )
For starters, you can compile directory Mosaic2.4/libhtmlw for the widget.
Using: To create widget:
htlmWid = XtCreateManagedWidget( "htlmWid",
htmlWidgetClass, parent,
htlmArgs,
XtNumber( htlmArgs ));
Callback for anchors:
XtAddCallback(htlmWid, WbNanchorCallback, htmlRef, NULL);
where htmlRef() looks like:
static void htmlRef(widget, client_data, call_data) Widget widget; XtPointer
client_data; WbAnchorCallbackData* call_data; {
buffer = readHTMLFile( call_data->href );
XtVaSetValues( widget, WbNtext, buffer, NULL ); }
where readHTMLFile() is
char * readHTMLFile( in_file ) char *in_flie; {
/* function to read a file and return its content, given
the file's name */ }
I think this is enough to start you off.
Thanks to: Samuel Effah
-----------------------------------------------------------------------------
Subject: 52) What widgets does Netscape use for its bookmarks list and
preference panels?
[Last modified: June 99]
Answer: Netscape uses the Microline widget set. Microline was purchased by
Neuron Data (http://www.neurondata.com/), but they no longer sell the
Microline widget set.
Ken Lee, http://www.rahul.net/kenton/
-----------------------------------------------------------------------------
Subject: 53) TOPIC: BOOKS and JOURNALS
-----------------------------------------------------------------------------
Subject: 54) Is there a bibliography available?
[Last modified: Jun 98]
Answer: The X Bibliography, originally maintained by Ken Lee (
http://www.rahul.net/kenton/index.shtml ), is now maintained by Steve Mikes,
smikes@unx.com. Steve regularly posts to comp.windows.x a list of reference
books and articles on X and X programming. The X FAQ from comp.windows.x
reproduces part of this list.
The complete X bibliography is available from these URLs:
ftp://ftp.x.org/contrib/docs/ (several suffixes)
-----------------------------------------------------------------------------
Subject: 55) Is there a Motif tutorial? Xt tutorial? X11 tutorial?
[Last modified: Nov 96]
Answer: For the most up-to-date links to Motif/X11/Xt tutorials, see:
http://www.cen.com/mw3/code.html
MW3: Code Examples and Tutorials
and
http://www.rahul.net/kenton/xsites.html#Xtutorials
On-line X programming tutorials (Kenton Lee's multi-lingual links)
See http://www.cm.cf.ac.uk/Dave/X_lecture/X_lecture.html
for a hypertext Motif tutorial (by David Marshall) with source code and
illustrations.
Marshall Brain at brain@adm.csc.ncsu.edu posted a set of simple and useful
Motif tutorials at http://www.iftech.com/ .
Jan Borchers <job@ira.uka.de> writes about his Xmtutor:
A free version of "Xmtutor", a menu-driven Motif application that contains an
interactive tutorial about programming with Motif with many executable
examples, is available via anonymous ftp. (Thanks to Allen Fogleson
(foggie@dtx.net) and Thomas Madeya (madeya@ira.uka.de) for the updates.) The
exact version varies, so look in the directory:
ftp://ftp.vse.cz/pub/386-unix/linux/freeware_for_motif/motif-tutor/xmtutor-1.3/
or:
ftp://ftp.uni-stuttgart.de/pub/X11/programming/
Xmtutor is very useful to learn Motif easier than with a book, and it is a
convenient Quick Reference and resource-settings testbed for Motif application
developers.
It has been tested on SUN Sparcs (SunOS 4.1) and DEC Alphas (OSF/1 1.3a), but
should be working OK on most other Unix / X11R4/R5 / Motif 1.1/1.2 systems.
The demo version contains all the information to get you started with Motif,
and upon registration, which costs 49 DM, you get the complete tutorial,
describing all widgets, other topics such as inter-client communication,
Compound Strings, etc., as well as a formatted TeX file of the tutorial to
print out, which gives you a complete book about Motif.
More on-line Motif tutorials and technical papers are listed on my web site:
http://www.rahul.net/kenton/
-----------------------------------------------------------------------------
Subject: 56) What books are available for Motif application programmers?
[Last modified: Mar 98]
Answer: NOTE: This answer is always out-of-date, but tries to list books that
readers have found to be very useful. If you find a particular book to be
much better than others (for your purposes), please send a brief review to
kenton@nojunk.rahul.net.
For official Motif 2.1 documentation, see also the earlier subject "Where can
I find Motif 2.1 documentation?". These have been published in book form by
Prentice-Hall. Some Xlib and Xt books are listed in the next subject. See
also the CREATING WIDGETS topic for some books on writing your own Motif-
compliant widgets.
The following are listed alphabetically by author.
Berlage, Thomas Berlage, OSF/Motif: Concepts and Programming, Addison-Wesley,
UK, 1991. ISBN 0-201-55792-4.
Ferguson, Paula & Brennan, David, Motif Reference Manual, Volume 6B, O'Reilly
& Associates, 1st Edition June 1993, 920 pages, ISBN: 1-56592-038-4. "Dan
Heller's Motif Programming Manual [Volume 6A, below] has long been considered
the most authoritative and insightful work on Motif. Now, with the addition of
this companion reference manual, programmers can dispense completely with the
original OSF documentation. In addition to covering the entire Motif toolkit,
this book also covers OSF's "User Interface Language" or UIL, and the Motif
Resource Manager (MRM) functions used to tie together applications with user
interfaces defined in UIL."
Updated Sept. 95:
Flanagan, David, Motif Tools: Streamlined GUI Design and Programming with the
Xmt Library, O'Reilly & Associates, 1st Edition August 1994, 1024 pages, ISBN:
1-56592-044-9. "Motif Tools and the Xmt programming library that accompanies
it on CD-ROM offer resources to empower Motif programmers and dramatically
speed up application development with the X Toolkit and Motif. The Xmt
library contains nine custom widgets and over 250 convenience routines that
handle many tricky aspects of GUI programming. The Layout widget, for example,
is an incredibly flexible manager widget that makes the confusing and awkward
Motif Form widget a thing of the past. And a single Menu widget will create an
entire pulldown menu system for your application by reading a special menu
description from a resource file or your C code. Other features of the library
dramatically simplify the use of Motif XmStrings, automate the transfer of
data between the fields of an application's data structures and the widgets of
its dialog boxes, and make it possible to automatically create a widget
hierarchy completely described in a resource file."
NOTE: Xmt version 2.1.2 is available for Motif 2.0. See:
ftp://ftp.ora.com/pub/examples/xbook/Xmt/xmt212.tar.gz
http://www.davidflanagan.com/Xmt/
Added Sept. 95:
George, Alistair and Riches, Mark, Advanced Motif Programming Techniques,
Prentice Hall, 1994. ISBN: 0-13-219965-3. Glenn Carr (gcarr@lgc.com) writes:
"This is a concise book that has alot of great tips and other insightful
information about less obvious Motif characteristics."
Heller, Dan, Ferguson, Paula M. & Brennan, David, Motif Programming Manual,
Volume 6A, O'Reilly & Associates, 2nd Edition February 1994, ISBN: 1-56592-
016-3. "The Motif Programming Manual describes how to write applications
using the Motif toolkit from the Open Software Foundation (OSF). The book goes
into detail on every Motif widget class, with useful examples that will help
programmers to develop their own code. Anyone doing Motif programming who
doesn't want to have to figure it out on their own needs this book."
Johnson, Eric F. and Kevin Reichard, Power Programming Motif, second edition,
MIS: Press, New York, NY, 1993. ISBN 1-55828-322-6.
Kimball, Paul E., The X Toolkit Cookbook, Prentice Hall, 1995. ISBN 0-13-
973132-6. Covers the Toolkit in detail and also covers Motif & Athena widgets;
good chapter on inter-client communication and working with other toolkits.
Discussion of X11R6 features. Code examples in
ftp://ftp.netcom.com/pub/pk/pkimball/cookbook/. Submitted by
raju@BooBoo.wes.army.mil (Raju Kala).
Newmarch, Jan, The X Window System and Motif - A Fast Track Approach.
Addison-Wesley, ISBN 0-201-53931-4. As the long-time maintainer of this Motif
FAQ, Jan's book is bound to contain unusual and useful insights.
O'Reilly and Associates publishes an entire series of books concerning
different aspects of the X Window System, including a number of books about
Motif, as well as books on Xlib, Xt, and PEX. In this FAQ, we list O'Reilly
books by the authors' names. For a summary of all of O'Reilly's X11 series,
see:
ftp://ftp.x.org/contrib/docs/Xbibliography.OReilly
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. The example code is
available at ftp://ftp.x.org/contrib/book_examples/sebern.motifapp-1.1.tar.Z.
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.
Young, Douglas, "Object-Oriented Programming with C++ and OSF/Motif", Prentice
Hall, 1992. ISBN 0-13-630252-1. Source code is
ftp://ftp.x.org/contrib/book_examples/young.cxx.tar.Z
Young, Douglas, "The X Window System: Programming and Applications with Xt,
Motif Edition", Prentice Hall, 1994. ISBN 0-13-123803-5. This is the classic
tutorial from 1989 updated for Motif 1.2. Source code is
ftp://ftp.x.org/contrib/book_examples/young2.motif.tar.Z
Young, Douglas, "Motif Debugging and Performance Tuning", Prentice Hall, 1995.
ISBN 0-13-147984-9. Source code is
ftp://ftp.x.org/contrib/book_examples/young.debug.tar.Z
If you want to learn about UIL, one source is the "Motif Programmers's Guide"
from Prentice-Hall. However, excellent UIL coverage appears in the O'Reilly
and Associates books "Motif Programming Manual, Volume 6A" by Dan Heller and
Paula M. Ferguson and in "Motif Reference Manual, Volume 6B" by Paula M.
Perguson with UIL Material by David Brennan. (Yes, 6A and 6B were worth the
wait!)
Added May 97:
Thomas C. McFarland, "X Windows on the World, Developing Internationalized
Software with X, Motif, and CDE". ISBN 0-13-359787-3. Source code is
ftp://ftp.prenhall.com/pub/ptr/hewlett_packard_professional_books.w-
064/mcfarland/xwindows.wld
-----------------------------------------------------------------------------
Subject: 57) Which Xt and X books would also be helpful?
[Last modified: Apr 97]
Answer: You will also need books and references on Xt and Xlib, such as:
Paul Asente, Donna Converse, and Ralph Swick, X Window System Toolkit, Second
Edition, 1998. The first edition of this book was the Xt bible for X11R3 and
X11R4. The expanded second edition covers releases throuch X11R6.3 as well.
This is the most accurate and thorough book on Xt, including sections for both
application writers and for widget writers. Published by Digital Press, ISBN
1-55558-178-1.
Cutler, Ellie, Gilly Daniel, and O'Reilly, Tim, The X Window System in a
Nutshell, O'Reilly & Associates, 2nd Edition April 1992, 424 pages, ISBN: 1-
56592-017-1. A quick reference guide to Xlib functions datatypes and events,
Xt functions and datatypes, and the standard X clients. The second edition is
expanded and covers X11R4 and X11R5.
Flanagan, David, Programmer's Supplement for R5 of the X Window System,
O'Reilly & Associates, 1991, ISBN: 0-937175-86-2. A programmer's guide to all
the new features in X11R5, with reference pages for the new functions.
[NOTE: Out-of-print; material incorporated in recent editions of Volumes 1, 2,
4 and 5. X11R6 supplement is in the works.]
Flanagan, David, Editor, X Toolkit Intrinsics Reference Manual, Volume 5,
O'Reilly & Associates, 3rd Edition April 1992, 916 pages, ISBN: 1-56592-007-4.
"The X Toolkit Intrinsics Reference Manual is a complete programmer's
reference for the X Toolkit. It provides reference pages for each of the Xt
functions as well as the widget classes defined by Xt and the Athena widgets.
This volume is based on Xt documentation from the X Consortium and has been
re-edited, reorganized, and expanded... The third edition of Volume 5 has
been completely revised. In addition to covering Release 4 and Release 5 of X,
all the man pages have been completely rewritten for clarity and ease of use,
and new examples and descriptions have been added throughout the book."
Mui, Linda and Pearce, Eric, X Window System Administrator's Guide, Volume 8,
O'Reilly & Associates, 1st Edition October 1992, CD-ROM Released May 1993,
ISBN: 1-56592-052-X (with CD-ROM) "This book is the first and only book
devoted to the issues of system administration for X and X-based networks,
written not just for UNIX system administrators but for anyone faced with the
job of administering X (including those running X on stand-alone
workstations)..." A book for X system administrators, covering XDM, security,
font management, X terminals, building X, etc. Available with a CD-ROM
containing the complete X source code.
Nye, Adrian, Xlib Programming Manual, Volume 1, O'Reilly and Associates, 3rd
Edition July 1992, 824 pages, ISBN: 1-56592-002-3. "Updated to cover X11
Release 5, the Xlib Programming Manual is a complete guide to programming the
X library (Xlib), the lowest level of programming interface to X. It includes
introductions to internationalization, device-independent color, font service,
and scalable fonts. Includes chapters on: X Window System concepts, A simple
client application, Window attributes, The graphics context, Graphics in
practice, Color, Events, Interclient communication, Internationalization, The
Resource Manager, A complete client application, Window management, and Other
programming techniques."
Nye, Adrian, Editor, Xlib Reference Manual, Volume 2, O'Reilly & Associates,
3rd Edition June 1992, ISBN 1-56592-006-6. Contains reference pages, derived
from the MIT specification, for all Xlib functions. The third edition covers
X11R4 and X11R5, including all the new internationalization and Xcms (Color
Management System) functions.
Nye, Adrian & O'Reilly, Tim, X Toolkit Intrinsics Programming Manual, Motif
Edition, Volume 4M, O'Reilly and Associates, 2nd Edition August 1992, 674
pages, ISBN: 1-56592-013-9. "Volume 4 is a complete guide to programming with
the X Toolkit Intrinsics, the library of C language routines that facilitates
the design of user interfaces with reusable components called widgets. It
provides concepts and examples that show how to use the various X Toolkit
routines. The first few chapters are devoted to using widgets; the remainder
of the book covers the more complex task of writing new widgets. Volume 4 is
available in two editions. The Motif Edition uses the Motif 1.2 widget set in
examples, and covers X11 Release 5."
Quercia, Valerie & O'Reilly, Tim, X Window System User's Guide, Motif Edition,
Volume 3M, O'Reilly and Associates, 2nd Edition January 1993, 956 pages, ISBN:
1-56592-015-5. "The X Window System User's Guide, Motif Edition orients the
new user to window system concepts and provides detailed tutorials for many
client programs, including the xterm terminal emulator and the window manager.
Building on this basic knowledge, later chapters explain how to customize the
X environment and provide sample configurations. This alternative edition of
the User's Guide highlights the Motif window manager, for users of the Motif
graphical user interface. Revised for Motif 1.2 and X11 Release 5."
Scheifler, Robert W., and Gettys, James, X Window System, The Complete
Reference to Xlib, X Protocl, ICCCM, XLFD. Digital Press, 1992. The Xlib
bible. Third edition covers X11R5. ISBN 1-55558-088-2, Digital Press order
number EY-J802E-DP.
For those interested in PHIGS and PEXlib, O'Reilly & Associates also publishes
several books on these topics. See:
gopher://gopher.ora.com/11/descriptions/prox
-----------------------------------------------------------------------------
Subject: 58) Are there books for X11R6 yet?
[Last modified: Feb 95]
Answer: Check the X FAQ at:
ftp://ftp.x.org/contrib/faqs/FAQ or
http://www.cis.ohio-state.edu/hypertext/faq/usenet/x-faq/top.html
Also O'Reilly and Associates have a mini-FAQ regarding their plans for X11
Release 6 books:
http://nearnet.gnn.com/gnn/bus/ora/news/r6.html
-----------------------------------------------------------------------------
Subject: 59) What relevant journals are available?
[Last modified: Jun 98]
Answer: In October, 1997, ICS has launched The Motif Zone at
http://www.motifzone.com/
This web site contains a Motif reference section and an on-line magazine
called *The Motif Developer*.
Several other Motif-oriented magazines have existed in the past, but are
ceased publishing. Their back issues are still very interesting, though.
Back issues of the print magazines may be available from their publishers or
at better technical libraries. Back issues of "The X Advisor" are no longer
on line.
"The X Journal" was published bimonthly by SIGS Publications, +1-212-274-0640.
"The X Resource: A Practical Journal of the X Window System" was published
quarterly by O'Reilly and Associates, +1-800-998-9938.
-----------------------------------------------------------------------------
Subject: 60) Is there a Motif book for shell programming, such as ksh
(kornshell)?
[Last modified: Jan 96]
Answer: Steve Pendergrast recently wrote a book about Motif programming using
the desktop kornshell (dtksh) interpreter (which is now shipped with the
latest versions of Solaris, HP/UX, AIX, and DEC OSF/1). This is not a book
about programming with Motif in the C language, it is a Motif book for shell
programmers, and does not assume the reader has any prior X experience.
TITLE: "Desktop KornShell Graphical Programming"
AUTHOR: J. Stephen Pendergrast, Jr.
ISBN: 0-201-63375-2
PUBLISHER: Addison-Wesley
DESCRIPTION: 840 pages, includes bibliography and index, over 100 figures,
over 140 programming examples
Was awarded "Best X Book of 1995" by The X Advisor magazine.
-----------------------------------------------------------------------------
Subject: 61) TOPIC: MWM and the SHELL WIDGET
-----------------------------------------------------------------------------
Subject: 62) What is the difference between Motif and mwm?
Answer: mwm is a window manager.
Motif itself is made up of four parts: a User Interface Style Guide, an API
toolkit of `C' routines which helps in the building of applications which
conform to the style guide, the window manager mwm, and a language UIL which
is designed to ease user interface development.
In general mwm will run any application built with any X Window System API,
and in general an application built using the Motif toolkit will run under any
window manager.
-----------------------------------------------------------------------------
Subject: 63) 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: 64) What are some useful mwm resources I can control?
[Last modified: Sept 95]
Answer: Ken Sall (ksall@cen.com) writes: Some you might consider, taken from
the mwm(1) man page, are:
clientAutoPlace (class ClientAutoPlace)
This resource determines the position of a window
when the window has not been given a program- or
user-specified position. With a value of True, win-
dows are positioned with the top-left corners of the
frames offset horizontally and vertically. A value
of False causes the currently configured position of
the window to be used. In either case, mwm will
attempt to place the windows totally on-screen. The
default value is True.
focusAutoRaise (class FocusAutoRaise)
When the value of this resource is True, clients are
raised when they get the keyboard input focus. If
the value is False, the stacking of windows on the
display is not changed when a window gets the key-
board input focus. The default value is True when
keyboardFocusPolicy is explicit and False when key-
boardFocusPolicy is pointer.
interactivePlacement (class InteractivePlacement)
This resource controls the initial placement of new
windows on the screen. If the value is True, the
pointer shape changes before a new window is placed
on the screen to indicate to the user that a position
should be selected for the upper-left corner of the
window. If the value is False, windows are placed
according to the initial window configuration attri-
butes. The default value of this resource is False.
positionIsFrame (class PositionIsFrame)
This resource indicates how client window position
information (from the WM_NORMAL_HINTS property and
from configuration requests) is to be interpreted.
If the resource value is True, the information is
interpreted as
the position of the MWM client window frame. If the
value is False, it is interpreted as being the posi-
tion of the client area of the window. The default
value of this resource is True.
positionOnScreen (class PositionOnScreen)
This resource is used to indicate that windows should
initially be placed (if possible) so that they are
not clipped by the edge of the screen (if the
resource value is True). If a window is larger than
the size of the screen, at least the upper-left
corner of the window is on-screen. If the resource
value is False, windows are placed in the requested
position even if totally off-screen. The default
value of this resource is True.
useIconBox (class UseIconBox)
If this resource is given a value of True, icons are
placed in an icon box. When an icon box is not used,
the icons are placed on the root window (default
value).
-----------------------------------------------------------------------------
Subject: 65) How can I configure mwm, such as changing or adding to root
menus?
[Last modified: Oct 95]
Answer: Read the mwm(1) man page which describes how to configure mwm using
the .mwmrc file. The default location of the system-wide version of this file
is /usr/lib/X11/system.mwmrc. You can override settings in the global file by
creating your own $HOME/.mwmrc.
-----------------------------------------------------------------------------
Subject: 66) How can my program determine which window manager is running?
[Last modified: Nov 97]
Answer: Each window manager has its own signature, but unfortunately there is
no standard query mechanism. Motif provides XmIsMotifWMRunning() to test for
mwm.
-----------------------------------------------------------------------------
Subject: 67) How can I modify the mwm's window decorations with a resource
file?
[Last modified: Dec 97]
Answer: Set mwm's client resource "clientDecoration" for your particular
application. For example,
Mwm*XClock.clientDecoration: none
turns off all clock decorations. See the mwm man page for other options and
other mwm client resources.
-----------------------------------------------------------------------------
Subject: 68) How can I programatically modify the mwm's window decorations?
[Last modified: July 95]
Answer: Programmatically, set the VendorShell resource XmNmwmDecorations to 0,
such as:
#include <Xm/MwmUtil.h> /* see MWM_DECOR_* and MWM_FUNC_* */
#include <Xm/DialogS.h>
popupShell =
XtVaCreatePopupShell( "PopupShell",
xmDialogShellWidgetClass, toplevel,
XmNmwmDecorations, 0,
NULL );
With the 0, you have no decorations at all, but if you want just a little
frame, use MWM_DECOR_BORDER instead.
Thanks to Guillaume.Gallais@asm.thomson.fr for the code fragment and pointing
out that there is no MWM_DECOR_NONE.
Reinhard M. Weiss (weissrm@execpc.com) also pointed out that MWM_DECOR_NONE
was fictitious. He also added:
"I have found that the resource XtNoverrideRedirect does cause the olwm to
remove all decorations (my guess is that it would work in mwm roughly the
same). This works programmatically as well as in resource files (i.e.
*.className*overrideRedirect: true). There are some undesirable effects to
this, however, particularly with focus and managing dialogs and popups."
-----------------------------------------------------------------------------
Subject: 69) Is there an ICCCM compliant way of setting window manager
decorations?
Answer: Tom LaStrange (toml@LaStrange.COM) writes: "No, there is no ICCCM
portable way to alter decorations."
-----------------------------------------------------------------------------
Subject: 70) How can I put decorations on transient windows using olwm?
Answer: This code is from Jean-Philippe Martin-Flatin <syj@ecmwf.int>:
/**********************************************************************
** 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.int if you
** find out what is going on !
*/
AddOLWMDialogFrame(shell,(OLWM_Header | OLWM_Resize));
/* AddOLWMDialogFrame(shell,(OLWM_Header | OLWM_Resize | OLWM_Close)); */
}
-----------------------------------------------------------------------------
Subject: 71) 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: 72) How can I create a multi-colored window manager icon?
[Last modified: Oct 95]
Answer: The only portable way to do this is with icon windows. The WMShell
widget supports icon windows with its XmNiconWindow resource. Set this to a
window that your application has created. The window could be the XtWindow()
of a realized shell widget. The window must be created with the default
visual and colormap of its screen. Other requirements on icon windows are
specified in section 4.1.9 of the X11R6 ICCCM. Note that some window managers
provide alternate techniques for creating color icons; none of these are
standard or portable.
Ken Lee
-----------------------------------------------------------------------------
Subject: 73) How can I keep my shell windows fixed in size?
[Last modified: Apr 95]
Answer: In addition to the decoration controls mentioned in the previous few
subjects of this FAQ, you can also specify size hints for your shell widget's
windows with these resources: XmNminWidth, XmNmaxWidth, XmNminHeight,
XmNmaxHeight. If you set the min and max values to the same size, most window
managers will not allow the user to resize the window.
Ken Lee
-----------------------------------------------------------------------------
Subject: 74) Why is XtGetValues of XmNx and XmNy of my toplevel shell wrong?
[Last modified: Oct 95]
Answer: [Note: This answer is borrowed from the Xt FAQ,
ftp://ftp.x.org/contrib/faqs/FAQ-Xt, devoted to X Toolkit Intrinsics.]
XmNx and XmNy are the coordinates relative to your shell's parent window,
which is usually a window manager's frame window. To translate to the root
coordinate space, use XtTranslateCoords().
-----------------------------------------------------------------------------
Subject: 75) How do I get XmNx and XmNy positions to be honored correctly?
[Last modified: Nov 96]
Answer: One answer is to pass the right hints to the window manager, perhaps
using XSetWMNormalHints. Another approach comes from Shane Burgess
(shane@radionics.com) who writes:
By setting the XmNdefaultPosition resource (on XmBulletinBoard or its
subclasses, including the message dialogs) to False, I've found that all my
XmNx & XmNy requests gets set correctly.
Pete Sakalaukus (sakalauk@pelican.st.usm.edu) says that XmNdefaultPosition
only works with olwm, not mwm.
-----------------------------------------------------------------------------
Subject: 76) How can my application know when the user has quit Mwm?
[Last modified: Feb 95]
Answer: Looking for an answer to this one. ANY TAKERS? (Still looking.)
-----------------------------------------------------------------------------
Subject: 77) How can I tell if the user has selected "Close" from the system
menu? How do I catch the "Close"? I need to do some clean up before exiting.
[Last modified: Aug 95]
Answer: Catching the mwm Close involves using XmAddWMProtocolCallback and
possibly setting the XmNdeleteResponse resource. Note that whether your
application involves multiple applicationShells vs. a single applicationShell
and multiple toplevelShells is significant. Following the two older code
fragments is a complete test application which can be compiled with different
#defines to alter the behavior.
This works with R4 Intrinsics
#include <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:-)."
The following similar code fragment is from Dave Mink
(mink@cadcam.pms.ford.com):
void setupCloseCallback(Widget shell, XtCallbackProc closeProc)
{
/* get window manager delete protocol atom */
Atom deletewin_protocol = XmInternAtom(
XtDisplay(shell), "WM_DELETE_WINDOW", True
);
/* turn off default delete response */
XtVaSetValues( shell,
XmNdeleteResponse, XmDO_NOTHING,
NULL);
/* add callback for window manager delete protocol */
XmAddWMProtocolCallback(shell, deletewin_protocol, closeProc, NULL);
}
Here is a complete code example which can be compiled several different ways,
as per the comments in the code.
/*
* MWM Close test program.
*
* Creates 4 shells, testing each of 3 different values of XmNdeleteResponse.
* Compile will -DMULTIPLE_APP_SHELLS to make all 4 shells of type
* applicationShellWidgetClass. Otherwise, first shell created is
* applicationShellWidgetClass, but other 3 are topLevelShellWidgetClass.
* Results differ. You can also experiment with #defining POPUP_SHELL,
* BEFORE_CREATE, or AFTER_CREATE.
*
* Ken Sall (ksall@cen.com)
*/
#include <stdio.h>
#include <X11/IntrinsicP.h>
#include <X11/StringDefs.h>
#include <X11/Shell.h>
#include <Xm/Xm.h>
#include <Xm/XmP.h>
#include <Xm/RowColumn.h> /* for popup */
#include <Xm/Label.h>
#include <X11/Protocols.h>
#include <X11/AtomMgr.h>
#include <X11/MwmUtil.h>
void CloseCB();
void popup_handler();
#ifdef MULTIPLE_APP_SHELLS
#define P1_TITLE "P1: applicationShell: XmDO_NOTHING"
#define P2_TITLE "P2: applicationShell: XmDESTROY"
#define P3_TITLE "P3: applicationShell: XmUNMAP"
#define P4_TITLE "P4: applicationShell: default"
#else
#define P1_TITLE "P1: applicationShell: XmDO_NOTHING"
#define P2_TITLE "P2: topLevelShell: XmDESTROY"
#define P3_TITLE "P3: topLevelShell: XmUNMAP"
#define P4_TITLE "P4: topLevelShell: XmDO_NOTHING"
#endif
void CloseCB (w, client_data, call_data)
Widget w; /* widget id */
caddr_t client_data; /* data from application */
caddr_t call_data; /* data from widget class */
{
XmAnyCallbackStruct *cb = (XmAnyCallbackStruct *) call_data;
printf ("caught Close from: %s\n", (char *)client_data );
if (strcmp ( P1_TITLE, (char *)client_data ) == 0 )
{
/* do something */
}
else if (strcmp ( P2_TITLE, (char *)client_data ) == 0 )
{
/* do something else */
}
else if (strcmp ( P3_TITLE, (char *)client_data ) == 0 )
{
/* do something else */
}
else if (strcmp ( P4_TITLE, (char *)client_data ) == 0 )
{
/* do something else */
}
else /* unreachable */
{
printf ("oops\n");
}
}
void popup_handler()
{
printf ("popup handler\n");
}
int main (argc,argv, envp)
int argc;
char **argv;
char **envp;
{
XtAppContext app_context;
Display *theDisplay;
Widget shell1, shell2, shell3, shell4;
Widget label, DrawWindow, WindowPopupMenu;
Arg al[10];
int ac;
Atom delwinAtom1, delwinAtom2, delwinAtom3, delwinAtom4;
XmString xms;
#ifdef MULTIPLE_APP_SHELLS
printf ("This version will demonstrate a problem if you Close P2.\n");
printf ("Since there are multiple appshells, closing (destroying) P2 cause the app to exit.\n");
#else
#ifdef POPUP_SHELL
printf ("This version uses XtCreatePopupShell rather than XtAppCreateShell \n");
#else
printf ("Compile with '-DMULTIPLE_APP_SHELLS' to demonstrate a problem.\n");
#endif
#endif
#ifdef BEFORE_CREATE
printf ("This version adds the XmNdeleteResponse _before_ the shell is created.\n");
#else
printf ("This version adds the XmNdeleteResponse _after the shell is created.\n");
#endif
XtToolkitInitialize ();
app_context = XtCreateApplicationContext ();
theDisplay = XtOpenDisplay ( app_context, NULL,
"my_program", "ProgramClass",
NULL, 0, &argc, argv);
/* --------------------- BEGIN P1 -------------------- */
ac = 0;
XtSetArg(al[ac], XmNx, 0); ac++;
XtSetArg(al[ac], XmNy, 0); ac++;
XtSetArg(al[ac], XmNwidth, 350); ac++;
XtSetArg(al[ac], XmNheight, 200); ac++;
XtSetArg (al[ac], XmNtitle, P1_TITLE); ac++;
#ifdef BEFORE_CREATE
XtSetArg (al[ac], XmNdeleteResponse, XmDO_NOTHING); ac++;
#endif
/* The ONLY applicationShell unless MULTIPLE_APP_SHELLS is defined. */
shell1 = XtAppCreateShell ("shell1", "ProgramClass",
applicationShellWidgetClass, theDisplay, al, ac);
/* Tell mwm to exec CloseCB when close is detected. */
delwinAtom1 = XmInternAtom (XtDisplay(shell1),
"WM_DELETE_WINDOW", False);
XmAddWMProtocolCallback (shell1, delwinAtom1, CloseCB, P1_TITLE);
#ifndef BEFORE_CREATE
XtVaSetValues( shell1, XmNdeleteResponse, XmDO_NOTHING, NULL);
#endif
/* --------------------- BEGIN P2 -------------------- */
ac = 0;
XtSetArg(al[ac], XmNx, 375); ac++;
XtSetArg(al[ac], XmNy, 0); ac++;
XtSetArg(al[ac], XmNwidth, 350); ac++;
XtSetArg(al[ac], XmNheight, 200); ac++;
XtSetArg (al[ac], XmNtitle, P2_TITLE); ac++;
#ifdef BEFORE_CREATE
XtSetArg (al[ac], XmNdeleteResponse, XmDESTROY); ac++;
#endif
#ifdef MULTIPLE_APP_SHELLS
shell2 = XtAppCreateShell ("shell2", "ProgramClass",
applicationShellWidgetClass, theDisplay, al, ac);
#else
#ifdef POPUP_SHELL
/*
* NOTE use of XtCreatePopupShell (not XtCreateMAnagedWidget) and
* topLevelShellWidgetClass (not applicationShellWidgetClass).
* Parent of topLevelShell is applicationShell.
* Use XtPopup rather than XtRealize for topLevelShell.
*/
shell2 = XtCreatePopupShell ("shell2",
topLevelShellWidgetClass, shell1, al, ac);
#else
shell2 = XtAppCreateShell ("shell2", "ProgramClass",
topLevelShellWidgetClass, theDisplay, al, ac);
#endif
#endif
/* Tell mwm to exec CloseCB when close is detected. */
delwinAtom2 = XmInternAtom (XtDisplay(shell2),
"WM_DELETE_WINDOW", False);
XmAddWMProtocolCallback (shell2, delwinAtom2, CloseCB, P2_TITLE);
#ifndef BEFORE_CREATE
XtVaSetValues( shell2, XmNdeleteResponse, XmDESTROY, NULL);
#endif
/* --------------------- BEGIN P3 -------------------- */
ac = 0;
XtSetArg(al[ac], XmNx, 750); ac++;
XtSetArg(al[ac], XmNy, 0); ac++;
XtSetArg(al[ac], XmNwidth, 350); ac++;
XtSetArg(al[ac], XmNheight, 200); ac++;
XtSetArg (al[ac], XmNtitle, P3_TITLE); ac++;
#ifdef BEFORE_CREATE
XtSetArg (al[ac], XmNdeleteResponse, XmUNMAP); ac++;
#endif
#ifdef MULTIPLE_APP_SHELLS
shell3 = XtAppCreateShell ("shell3", "ProgramClass",
applicationShellWidgetClass, theDisplay, al, ac);
#else
#ifdef POPUP_SHELL
/* See comments for shell2 */
shell3 = XtCreatePopupShell ("shell3",
topLevelShellWidgetClass, shell1, al, ac);
#else
shell3 = XtAppCreateShell ("shell3", "ProgramClass",
topLevelShellWidgetClass, theDisplay, al, ac);
#endif
#endif
/* Tell mwm to exec CloseCB when close is detected. */
delwinAtom3 = XmInternAtom (XtDisplay(shell3),
"WM_DELETE_WINDOW", False);
XmAddWMProtocolCallback (shell3, delwinAtom3, CloseCB, P3_TITLE);
#ifndef BEFORE_CREATE
XtVaSetValues( shell3, XmNdeleteResponse, XmUNMAP, NULL);
#endif
/* --------------------- BEGIN P4 -------------------- */
ac = 0;
XtSetArg(al[ac], XmNx, 0); ac++;
XtSetArg(al[ac], XmNy, 250); ac++;
XtSetArg(al[ac], XmNwidth, 350); ac++;
XtSetArg(al[ac], XmNheight, 200); ac++;
XtSetArg (al[ac], XmNtitle, P4_TITLE); ac++;
#ifdef BEFORE_CREATE
XtSetArg (al[ac], XmNdeleteResponse, XmDO_NOTHING); ac++;
#endif
#ifdef MULTIPLE_APP_SHELLS
shell4 = XtAppCreateShell ("shell4", "ProgramClass",
applicationShellWidgetClass, theDisplay, al, ac);
#else
#ifdef POPUP_SHELL
/* See comments for shell2 */
shell4 = XtCreatePopupShell ("shell4",
topLevelShellWidgetClass, shell1, al, ac);
#else
shell4 = XtAppCreateShell ("shell4", "ProgramClass",
topLevelShellWidgetClass, theDisplay, al, ac);
#endif
#endif
/* Tell mwm to exec CloseCB when close is detected. */
delwinAtom4 = XmInternAtom (XtDisplay(shell4),
"WM_DELETE_WINDOW", False);
XmAddWMProtocolCallback (shell4, delwinAtom4, CloseCB, P4_TITLE);
#ifndef BEFORE_CREATE
XtVaSetValues( shell4, XmNdeleteResponse, XmDO_NOTHING, NULL);
#endif
/* just for fun */
ac = 0;
WindowPopupMenu = XmCreatePopupMenu(shell1, "PopupMenu", al, ac);
XtAddEventHandler( shell1, ButtonPressMask, FALSE, popup_handler,
WindowPopupMenu);
ac = 0;
xms = (XmString) XmStringCreateLocalized ( "Button3 = popup; Button2 = DnD.");
XtSetArg(al[ac], XmNlabelString, xms); ac++;
XtSetArg(al[ac], XmNshadowThickness, 2); ac++;
label = XmCreateLabel (shell1, "label", al, ac);
XtManageChild ( label );
XtRealizeWidget( shell1 );
/* NOTE use of XtPopup rather than XtRealizeWidget for topLevels */
#ifdef MULTIPLE_APP_SHELLS
XtRealizeWidget( shell2 );
XtRealizeWidget( shell3 );
XtRealizeWidget( shell4 );
#else
#ifdef POPUP_SHELL
XtPopup ( shell2, XtGrabNone );
XtPopup ( shell3, XtGrabNone );
XtPopup ( shell4, XtGrabNone );
#else
XtRealizeWidget( shell2 );
XtRealizeWidget( shell3 );
XtRealizeWidget( shell4 );
#endif
#endif
XtAppMainLoop (app_context);
}
-----------------------------------------------------------------------------
END OF PART THREE
----------------------------------------------------------------------------
Subject: 78) Is there an mwm virtual desktop manager?
[Last modified: Sep 97]
Answer: David Kaelbling (drk@x.org) reports: In OSF/Motif 2.0, mwm supports
both workspaces (see the f.cci function and the wsm demo for a sample
interface) and a virtual root window. To manipulate the virtual screen
f.goto, f.pan, and f.track_pan were added, as were iconPinned and clientPinned
client resources.
Peter E. Wagner (pwagner@panix.com): 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.
Tim Failes (tim@aus.oz.au) of Advanced User Systems Pty Ltd writes: IXI (now
SCO) has a fully supported product called Panorama which provides this
facility. Panorama allows the user to pan around the virtual work space,
dynamically change the size of the virtual workspace, and also access windows
via an icon box. Panorama also includes a point-and-click tool for setting
resources such as colours, focus policy, etc. [SCO contact information appears
in the "Where can I get Motif?" subject. -ed]
-----------------------------------------------------------------------------
Subject: 79) Why does mwm 1.2 crash on startup?
[Last modified: March 93]
Answer: David Brooks wrote: 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
-----------------------------------------------------------------------------
Subject: 80) 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: 81)* How can I create a shell widget with a non-default visual type?
[Last modified: Feb 00]
Answer: You must specify the colormap, visual type, and depth for the shell
before it is realized. If you don't specify all three resources (or specify
them incorrectly), you will probably get BadMatch protocol errors from your X
server.
Ken Lee, http://www.rahul.net/kenton/
Mike Stroyan, mike_stroyan@fc.hp.com, adds:
It is convenient to use XrmPutResource to cause all widgets to pick up a
consistent set of visual, depth, and colormap. It is just very difficult to
get at each and every shell including menushells created by functions like
XmVaCreateSimpleMenuBar and XmVaCreateSimpleOptionMenu.
This example uses the default visual for menus, but a non-default for the top
level shell:
if (!non_default_dialogs) {
/* Set default depth and colormap of shell widgets, especially menus */
Screen *default_screen;
int default_depth;
Colormap default_colormap;
XrmDatabase db = XtDatabase(display);
XrmValue v;
default_screen = DefaultScreenOfDisplay(display);
default_depth = DefaultDepthOfScreen(default_screen);
default_colormap = DefaultColormapOfScreen(default_screen);
v.size = sizeof(default_depth);
v.addr = (XtPointer) &default_depth;
XrmPutResource(&db,"*XmMenuShell.depth", XmRInt, &v);
XrmPutResource(&db,"*XmDialogShell.depth", XmRInt, &v);
v.size = sizeof(default_colormap);
v.addr = (XtPointer) &default_colormap;
XrmPutResource(&db,"*XmMenuShell.colormap", XmRColormap, &v);
XrmPutResource(&db,"*XmDialogShell.colormap", XmRColormap, &v);
}
/* Get visual information. */
template.screen = DefaultScreen(display);
template.class = TrueColor;
template.depth = 24;
mask = VisualScreenMask | VisualDepthMask | VisualClassMask;
vilist = XGetVisualInfo(display, mask, &template, &nvisual);
if (nvisual == 0) {
fprintf(stderr, "Cannot find an acceptable visual!0);
exit(1);
}
visual = vilist[0].visual;
depth = vilist[0].depth;
XFree((char *) vilist);
private_colormap = XCreateColormap(display, DefaultRootWindow(display),
visual, AllocNone);
{
XColor real, exact;
XAllocNamedColor(display, private_colormap, "Green", &real, &exact);
green = real.pixel;
}
XtVaSetValues(toplevel,
XmNdepth, depth,
XmNvisual, visual,
XmNcolormap, private_colormap,
NULL);
if (non_default_dialogs) {
/* Set non-default visual for all widgets. */
XrmDatabase db = XtDatabase(display);
XrmValue v;
v.size = sizeof(visual);
v.addr = (XtPointer) &visual;
XrmPutResource(&db,"*visual", XmRVisual, &v);
}
-----------------------------------------------------------------------------
Subject: 82) Can a non-shell Motif widget have a different visual type from
its parent?
[Last modified: May 97]
Answer: None of the standard Motif widgets support this. You can, however,
write your own subclasses that have different visual types. You'll have to
override the Realize method in your subclass. Becareful to set the colormap
and depth properly to match your visual type.
Ken Lee
-----------------------------------------------------------------------------
Subject: 83) Why do I get BadMatch errors from my menus when I use a non-
default visual type for my application shell?
[Last modified: Sept 95]
Answer: Unfortunately, the visual type and depth attributes are copied
differently from parent to child. To be safe you use non-default visuals on
any of your widgets and use these as parents for shell widgets (including
menus), you should set the visual type, depth, and colormap on the child
shells.
Ken Lee
-----------------------------------------------------------------------------
Subject: 84) How do I popup a scrolled list on top of other widgets?
[Last modified: Sept 95 ]
Put it in an override redirect shell and do a XMapRaise on the shell's window.
That will do it. If you're using Motif then just use a VendorShell with
XmNoverrideRedirect set to true.
Thanks to Doug Rand (drand@sgi.com)
-----------------------------------------------------------------------------
Subject: 85) How can I keep my application's window always on top of all
other applications' windows?
[Last modified: Sep 97]
Answer: Some window managers have features supporting this. Mwm does not.
The ICCCM does not specify a standard protocol for using the feature.
Note: some applications attempt to implement this by periodically popping
themselves to the top of the stack (perhaps in response to visibility change
events). This is very poor practice and should be avoided. If more than one
of a user's applications try this hack, the user will not be pleased.
Ken Lee
-----------------------------------------------------------------------------
Subject: 86) How can I maximize my top level shell?
[Last modified: Apr 98]
Answer: There is no explicit support for this. Maximizing makes sense in
single tasking operating systems where the user must choose one application to
be active. Motif usually runs in multi-tasking operating systems where
several applications may be active and having one take over the screen is
undesirable.
If you must make your application full screen, use the Xlib macros to compute
the root window size and set the width and height of your shell to this size.
You may want to leave a little space around the edges for the window manager
frame.
Ken Lee
-----------------------------------------------------------------------------
Subject: 87) TOPIC: MOTIF DEVELOPMENT TOOLS (GUI BUILDERS and UIMS's)
-----------------------------------------------------------------------------
Subject: 88) What GUI tools exist to assist in developing Motif applications?
[Last modified: Jun 98 ]
Answer: [Nov 96 update: added Loox and LXB info; revised MetaCard info.] [Jun
98 update: revised Winterp contact info.]
[A FAQ is not 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 concise and informative. See Subject 0 for contribution details.]
`Prototyping tools' and `code generation tools' come in two forms:
GUI (Graphical User Interface) builder -
those that can be used to design (and perhaps rehearse)
the interface only ; and
UIMS (User Interface Management Systems) -
those that are a system supporting the development and
execution of user interfaces.
However, this distinction can be somewhat arbitrary when specific tools are
categorized as either one or the other. (Therefore, the classification below
should be taken with a kilogram of salt. :-)
A number of commercial and non-commercial tools of both kinds that will
support Motif are listed below. [NOTE: Vendors or individuals wishing to add
their product or tool to this list, or to change their entry, should email to
the maintainer of this FAQ.]
GUI builders:
Builder Xcessory (bx)
Bx/Loox
Druid
ExoCODE/xm
iXBUILD (formerly X Build)
MOTIFATION
WKSH (Windowing Korn Shell)
X-Designer
UIMS:
ALEX
ezX User Interface Management System
Galaxy
MetaCard
Serpent
TAE Plus
TeleUse
UIMX
VXP (Visual X windows Programming Interface)
Widget Creation Library (Wcl)
WINTERP
XFaceMaker2
For users of the WWW, see also Brad A. Myers' `User Interface Software Tools'
list (which is not limited to Motif tools):
http://www.cs.cmu.edu/afs/cs/user/bam/www/toolnames.html
Thanks to Robin Schald (wald@tfh-berlin.de) for updating the above URL.
Some contact addresses, presented in alphabetical order (without regard to GUI
or UIMS categorization), follow:
o 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.
o Builder Xcessory (bx): is 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
http://www.ics.com/
o BxLoox is an integrated GUI development environment for Motif GUIs
containing dynamic screens. Containing the Builder Xcessory GUI builder from
Integrated Computer Solutions and the Loox dynamic graphics development tool,
BxLoox allows developers to interactively create every aspect of their
interface, including Motif widgets, structured graphics, animated graphics and
data visualization. Features include :
- object oriented design, based on the Doug Young method
- C and C++ code generation
- intelligent graphics primitives
- animation, blinking etc
- dynamic control objects (knobs, dials, sliders, digital readouts)
- LOOXMaker graphical editor for interactive primitive creation and animation
- 2D and 3D charting widgets
Contact:
Loox Software Inc.
4962 El Camino Real, # 206
Los Altos, CA 94022
voice : (415)903-0942
fax: (415)903-9824
url: http://www.loox.com
email: sales@loox.com
o 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
o ExoCODE/xm: By Expert Object Corp., 7250 Cicero Avenue, Lincolnwood, IL
60646 (708)676-5555. Also: ExoCODE, EXOC, 500 Hyacinth Place, Highland Park,
IL, 60035, (708) 926-8500, Motif or OpenLook or SunView.
o ezX: Contact information:
ezX User Interface Management System
Sunrise Software, International
170 Enterprise Center
Middletown, RI 02840
401-847-7868
email: support@sunrise.com
http://www.sunrise.com/
o Galaxy
Visix Software Inc. is no longer in business
Support for Galaxy is now provided by:
Ambiencia Information Systems
http://www.ambiencia.com/
o LXB: Linux X11/Motif GUI Builder is a sharware tool for Motif 1.2 or Motif
2.0 which you can obtain from:
http://www.tc.umn.edu/nlhome/g257/parki005/lxb/lxb.html
Thanks to Allen Fogleson (foggie@dtx.net) for mentioning LXB. The author,
bruce.parkin-1@umn.edu, writes:
Please note that lxb is a work in progress. Not all Motif
widgets are available, nor can all resources be edited.
There are many features of a good GUI builder yet to be done.
o MetaCard: MetaCard is a cross-platform multimedia authoring tool and GUI
development environment for Unix/X11 workstations and Microsoft Windows 95 and
NT. Using MetaCard is the easiest way to build Motif and Win32 applications,
Computer Based Training (CBT), on-line documentation, and a wide variety of
other products. Applications developed with MetaCard are portable to 13
UNIX/X11 workstations and Microsoft Win32 without recompiling or other
preprocessing and have native look and feel on all platforms. MetaCard
includes a complete GUI builder, GUI script debugger, and a powerful scripting
language with features and performance similar to Perl (which is up to 30
times the performance of Tcl/Tk), but which is much easier to learn and use.
MetaCard Corporation
4710 Shoup pl.
Boulder, CO 80303
303-447-3936
303-499-9855 (fax)
http://www.metacard.com
info@metacard.com
o 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, ...
o 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. NOTE: This is no longer
supported, and is apparently replaced by a commercial product called Alpha.
o TAE Plus: TAE Plus is a mature, portable software development environment
that supports rapid prototyping, tailoring, and management of Motif-based
graphical user interfaces. It particularly supports GUI development by non-
programmers and by programmers who are not well-versed in the details of X and
Motif. Its code generator can produce C, C++, and Ada code and allows for
automatic merging of regenerated code with previously modified parts of the
interface code. It supports generation of a UIL/Mrm representation of the
interface.
Scripting capabilities are provided to facilitate automatic testing, on-line
demos, and tutorials. A record and playback feature lets you build scripts
simply by interacting with your GUI. Dynamic Data Objects allow the developer
to create pictorial objects (e.g., a thermometer to show temperature), whose
dynamic portions (e.g., the mercury in the themometer) can change to reflect
changing data or be directly manipulated by the end-user. TAE Plus is
available on Sun, HP, IBM, SGI, and SCO Unix platforms. Evaluation software
is available via anonymous ftp.
TAE Plus contact information:
Century Computing, Inc.
8101 Sandy Spring Road
Laurel, MD 20707
1-800-823-3228
tae-info@cen.com
http://www.cen.com/tae/
o TeleUSE: (updated Sept. 95) 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:
Aonix
595 Market Street, 12th Floor
San Francisco, CA 94105
Phone: 415-543-0900
Toll Free 800-97Aonix
Fax: 415-543-0145
http://www.aonix.com/
o 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
o VXP (Visual X windows Programming Interface):
Yong Chen (stdyxc05@pip.shsu.edu) developed a Motif GUI builder called VXP --
Visual X windows Programming Interface. VXP has some UIMS capabilities. VXP is
now distributed as a freeware, and has been ported to SGI irix, HP hp-ux, Sun
OS4 and Solaris 2.x, DEC OSF/1, IBM AIX, Linux, SCO, NetBSD. For more
information, visit VXP's WWW home page at
http://www.shsu.edu/~stdyxc05/VXP/
or ftp at
ftp.shsu.edu /pub/VXP/
o Widget Creation Library (Wcl):
ftp://ftp.x.org/R5contrib/Wcl-2.5.tar.Z (X11R5 version)
o WINTERP: (Widget INTERPreter) An object-oriented rapid prototyping,
development and delivery environment for building extensible applications with
the OSF/Motif UI Toolkit and Xtango-based graphics/animation. By Niels Mayer
(mayer@netcom.com). Mailing list: winterp-request@netcom.com. The WINTERP
Home page containing the software sources, documentation, published papers,
binaries, examples, and screen shots is at:
http://www.cybertribe.com/mayer/winterp/
Key WINTERP Features:
* High-level, Object-oriented interface to OSF/Motif and Xtoolkit.
* High-level object-oriented 2.5D graphics&animation widget based
on Xtango path transition animation system.
* Ability to easily create new widget classes w/ complex graphical
behavior using Xtango animation/graphics.
* Automatic storeage management of all X/Xt/Motif data, Pixmaps,
animations. Automatic resource conversion and management.
* Asynchronous communications w/ other unix programs via
expect-based subprocess facility.
* Includes XmGraph to display graphs (both cyclic, acyclic,
directed, undirected); graph nodes can be arbitrary widgets
created by WINTERP; supports direct manipulation editing of graph.
* GIF image support.
* Lisp-eval server architecture supports inter-application
communication.
* Interactive programming via Gnu-Emacs or Motif-Text-widget interface.
* Portable, small, fast, and free.
o 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
o X-Designer: a GUI builder for both Motif and Microsoft Windows. From one
design C or C++ code can be generated for building with the X/Motif or the
Microsoft Foundation Class (MFC) libraries using only the native toolkits.
Imperial Software Technology
Berkshire House
252 Kings Road
Reading
RG1 4HP
UK
TEL: +44 118 958 7055
FAX: +44 118 958 9005
120 Hawthorne Avenue, Suite 101
Palo Alto, CA 94301 USA
(415) 688 0200
(415) 688 1054 (fax)
sales@ist.co.uk
URL: http://www.ist.co.uk
o 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
-----------------------------------------------------------------------------
Subject: 89) TOPIC: GEOMETRY MANAGEMENT
[NOTE: Send me your ideas for answered questions pertaining to this topic.]
-----------------------------------------------------------------------------
Subject: 90) Why is geometry management so important?
[Last modified: Sept 94]
Answer: Geometry management is a key element of Motif applications for reasons
which include, but are not limited to, the following:
The user should be able to re-size the shell and get
some reasonable geometry response (other than clipping).
The user should be able to tailor fonts and have the
widgets adjust accordingly. (Many people over 40 simply
can't read small fonts without serious eye strain.)
When the designers decide to change a label, the widgets
should re-adjust accordingly.
Some labels must be set dynamically and the widgets should
re-layout accordingly.
An internationalized application must work with several resource
files, one for each supported natural language. The labels in each
file have different lengths and the application should adjust
accordingly.
-----------------------------------------------------------------------------
Subject: 91) What are good references for reading about geometry management?
[Last modified: Oct 94]
Answer: See the BOOKS topics for detailed reference information. "X Toolkit
Intrinsics Programming Manual" (Nye & O'Reilly) contains an entire chapter on
geometry management, as does "X Window System Toolkit" (Asente & Swick) on
which the O'Reilly book is based. Another good reference is the discussion of
the "geometry_manager" and "query_geometry" methods in "X Toolkit Intrinsics
Reference Manual".
"Motif Programming Manual" (Heller & Ferguson) has a chapter devoted to Motif
Manager widgets. Finally, the widget documentation for each geometry manager
widget typically describes its policy in detail.
-----------------------------------------------------------------------------
Subject: 92) Why don't my labels resize in a RowColumn widget? I have a
RowColumn widget in my application, with several rows and columns of XmLabels.
When I update the text in the labels, the label's width does not get updated.
[Last modified: Oct 94]
Answer: Make sure all the ancestor widget resize mechanisms are enabled:
- on shells, set XmNallowShellResize
- on row column, set XmNresizeWidth and XmNresizeHeight
- on bulletin board and form, set XmNresizePolicy
Also, set XmNrecomputeSize on the label itself. The shell resource is off by
default; the others should be on by default.
Ken Lee
-----------------------------------------------------------------------------
Subject: 93) Does XmRowColumn support multiple columns with different column
widths?
[Last modified: Apr 98]
Answer: XmRowColumn was designed for simple layouts like menu panes and tool
bars. For more sophisticated layouts, you should use an XmForm widget
instead.
Ken Lee
-----------------------------------------------------------------------------
Subject: 94) Why do composite widgets (including dialogs) that were created
after their parents were realized appear smaller under 1.2.3 and later?
[Last modified: Dec 97]
A. Thanks to David Brooks (dbrooks@ics.com) for pointing me to Daniel
Dardailler (daniel@x.org) who wrote this scholarly treatise:
Application's Geometry Management Advanced Guidelines:
=====================================================
(or "How to properly manage children of already realized parent")
Xt Background:
-------------
XtCreateWidget: call Initialize ;
XtManageChild: if (parent realized)
call ChangeManaged ;
call Realize ;
XtRealizeWidget: postorder ChangeManaged loop ;
preorder Window-creation loop ;
Creating a widget only invokes its Initialize method (its parent's
InsertPosition method too, but that has nothing to do with GM).
Composite widgets, by opposition to Primitive, does
not usually get a correct size at initialization time, since their
correct size is based on their children sizes, which do not exist yet
at this time.
Applications usually create an entire tree of managed but
unrealized widgets and then realize their top level widget, which recursively
realize every widgets in the tree. During the creation process, the
managing of the unrealized widgets is a no-op (only mark them managed).
When XtRealizeWidget(toplevel) happens, the change_managed methods of
all the composite widgets in the tree are called in bottom-to-top
order, thus giving each of them a chance to determine their own size
based on their children *current* sizes (composite or not).
Using the current size of the children in this situation is fine,
since they should also be the children's preferred size, not
yet constrained by the parents layout (post-order traversal).
When one create a widget inside an already realized parent, this is
a different story and the order of management vs realization is important.
Consider a MessageBox created in a realized Frame.
The MessageBox itself creates a bunch of managed children
inside its Initialize method.
If you manage the MessageBox right after its creation, the Frame
ChangeManaged will be called (since it is realized), and its will use
the MessageBox current size as its base for its own size.
Unfortunately, the MessageBox ChangeManaged proc has never been called!
so its current size is whatever the default is, usually a non-settable
value (needed for tracking real initial size setting).
The MessageBox ChangeManaged has not been called because its children
were created and managed at a time where it wasn't realized.
What to do ?
The first solution would be to have all the ChangeManaged methods in
Motif call XtQueryGeometry instead of using the current size if it's
not the first time (i.e. if they're already realized).
But this is a lot of code to change and a kind of expensive run-time
process as it results in non-linear traversal order of the realized
tree (looks like an O(n!) but I'm not sure).
It's not even guaranteed that it will always work fine, since it relies on
the assumption that the geometry queried is the same that the geometry
asked for any manager (I mean, it might be the case, but if it's not,
it's just more code to fix in a very "bc-sensitive" part of Xm).
This other solution lies into the application, and is to realize a
manager first and then to manage it.
By realizing it, you are forcing its ChangeManaged proc to be
called (XtRealizeWidget does that), it will get a correct size and
this size will be used by its parent ChangeManaged when
you'll manage the manager. By explicitly realizing the branch
before managing its root, you are reproducing the ordering that
is typical of most applications at startup.
So the trick is:
XtCreateWidget(realize_parent, MessageBox);
XtRealizeWidget(MessageBox); /* needed */
XtManageChild(MessageBox);
and the model is:
"Always explicitly realize a composite widget child of an already
realized parent before managing it if all its children have been
already managed"
One can always realize every widget children of realized parents, that
won't hurt, but it's useless for Primitives and Composites that
get more children added later in the program.
Why? because Primitives get their correct size at initialization
time anyway and adding a child to a Composite will generate a geometry
request and a layout that will have the same effect as if the
ChangeManaged method had been called (well, nearly the same effect,
that a complication I will address later).
If we consider Motif, this trick is only useful for MessageBox,
SelectionBox and subclasses, and Scale, since those are the only
Composites that create managed children in their Initialize method and
don't usually get additional kids from the application.
However, any application that re-creates this order of actions will
need to apply the "realize<manage" method too.
For instance:
XtCreateWidget(realize_parent, DrawingArea);
XtRealizeWidget(DrawingArea); /* not needed */
XtManageChild(DrawingArea);
XtCreateWidget(DrawingArea, any_child) ;
XtManageChild(any_child);
but
XtCreateWidget(realize_parent, DrawingArea);
XtCreateWidget(DrawingArea, any_child) ;
XtManageChild(any_child);
XtRealizeWidget(DrawingArea); /* needed */
XtManageChild(DrawingArea);
Now this is becoming interesting: there are exceptions to the model :-)
The first one is the Xt Shell widget, which has what I consider to be a
bug, but what MIT has, until recently, always considered to be a specific
behavior overridable by a subclass (like our VendorShell):
the ChangeManaged method always resizes the child to its own size
when the Shell is realized.
A side effect of this behavior is that even the realized<managed trick
won't work for direct descendant of Shell widget:
XtCreateWidget(realize_shell, MessageBox);
XtRealizeWidget(MessageBox); /* needless */
XtManageChild(MessageBox); /* will get resized anyway */
To get rid of this problem, one needs to add a regular manager
between the Shell and the MessageBox in this case, for the sake
of having this manager doing a request to the Shell from its
ChangeManaged proc. This request will then be handled by the Shell
geometry manager, not its ChangeManaged proc, and it will take into
account the child size.
Note that we could also change our VendorShell ChangeManaged code to not
systematically envelop the Xt Shell ChangeManaged class method, and
check for the already realized case, but I would rather wait
for an Xt fix instead (I'm working on it).
If you broader the scope of the Xt Shell situation, you find that there are
also some resources in Xm that come into effect upon geometry request
reception but are not used in the ChangeManaged method.
Take the PanedWindow constraint resource XmNallowResize for instance,
which controls the validity of a geometry request made by a PW child.
If you do:
XtCreateWidget(realize_shell, PanedWindow);
XtManageChild(PanedWindow);
XtCreateWidget(PanedWindow, button);
XtManageChild(button);
that works fine since the ChangeManaged of the PanedWindow will
handle the insertion of the button and allowResize won't be used.
But if you add a manager in this hierarchy:
XtCreateWidget(realize_parent, PanedWindow);
XtManageChild(PanedWindow);
XtCreateWidget(PanedWindow, manager);
XtManageChild(manager);
XtCreateWidget(manager, button);
XtManageChild(button);
That doesn't work anymore since the button management results in
its parent manager's ChangeManaged being called, which in turn makes a
*request* to the PanedWindow, resulting in a No reply because
of allowResize (set to False by default).
The PanedWindow parent wouldn't have been realized that everything
would have worked fine, since no request would have been made.
It really depends on the early realization scheme.
I think XmNresizable in Form is the only other resource to present
this problem. There is not much to do in those cases except than
setting the corresponding resource to True, which makes sense.
- Daniel Dardailler (daniel@x.org)
In addition, John Michael Davison <davisonj@panix.com> sends this suggestion.
I think it's overkill for most people, but you may want to consider it if you
have problems in this area:
/* Workaround for motif 1.2.3-style geometry management */
void
smart_manage_child(Widget widget)
{
assert(widget != 0);
#if XmVersion >= 1002 && XmUPDATE_LEVEL >= 3
/* In Motif 1.2.3 and later:
/* "Always explicitly realize a composite widget child of an already
/* realized parent before managing it..."
/* Note that this is unnecessary for simple UI objects (i.e. wrappers for
/* Motif "Primitive" widgets.)
*/
if (XtIsManaged(widget))
return;
if (!XtIsRealized(widget) && XtIsComposite(widget))
{
Widget parent_widget = XtParent(widget);
if (parent_widget && XtIsRealized(parent_widget))
XtRealizeWidget(widget);
}
#endif /* XmVersion >= 1002 && XmUPDATE_LEVEL >= 3 */
XtManageChild(widget);
}
- John Michael Davison <davisonj@panix.com>
FYI - Asente & Swick (p. 207) says:
If the child's parent is realized, XtManageChild and XtManageChildren
automatically realize any widgets passed to them that are not currently
realized, causing the creation of their windows. However, you should
explicitly realize a composite child of a realized widget before managing the
child to ensure that the child appears with its correct size.
- Ken Lee, http://www.rahul.net/kenton/
-----------------------------------------------------------------------------
Subject: 95) How does the ScrolledWindow manage resizing?
[Last modified: June 95]
Answer: The scrolled window should resize its immediate child when it is
resized. The child is XmNworkWindow in the default application-defined
scrolling mode or XmNclipWindow in the automatic scrolling mode. In either
case, you can then resize your row column. If you set XmNadjustLast, the
children of a one column row column will be automatically resized.
Ken Lee
-----------------------------------------------------------------------------
Subject: 96) Does the XmPanedWindow widget support horizontal paning?
[Last modified: May 97]
Answer: In Motif 2.x it does, but not in Motif 1.x. There are, however, some
3rd party horizontal paned widgets listed in the Widget FAQ:
http://reality.sgi.com/widgetFAQ/
Ken Lee
-----------------------------------------------------------------------------
Subject: 97) TOPIC: TEXT WIDGET
-----------------------------------------------------------------------------
Subject: 98) How do XmTextField and a single line XmText widget differ?
[Last modified: Oct 94]
Answer: XmTextField is designed to be a lightweight, single line text editor.
It does not provide as much functionality as does XmText in order to achieve
better performance.
Thanks to Kevin Till, kev@osf.org
-----------------------------------------------------------------------------
Subject: 99) 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: 100) Can you reuse the return value from XtParseTranslationTable?
[Last modified: Nov 96]
Answer: The following is a conversation circa 30 Sep 1996 between Kaleb
Keithley (kaleb@x.org) and Tim Behrendsen (tim@a-sis.com, tim@airshields.com>.
The latter suggested this appear in the Motif FAQ.
B> Can the return value from XtParseTranslationTable be saved
TB> off and reused for the lifetime of the application?
KK> Yes.
TB> Ah! The answer. Thank you.
KK>
KK> XtVaSetValues(widget,
KK> XmNtranslations, XtParseTranslationTable(table), NULL);
TB> which implies it's a one-shot deal (otherwise, this would cause
TB> a memory leak).
KK> No, you can always retrieve them with Xt(Va)GetValues.
TB> You can, but if you don't and use the technique to wantonly
TB> create and destroy dialogs, it seems you will get a memory
TB> leak.
KK> That's correct.
TB> In fact, what's scary is this technique is used in the Motif
TB> FAQ list; I knew I saw it somewhere reasonably authoritative
TB> ([approx.] Question 133; code by Dan Heller, O'Reilly and Associates).
TB> He does the following:
TB> XtOverrideTranslations(bboard,
TB> XtParseTranslationTable("<Configure>: resize()"));
TB> This has to be unquestionably broken code, if the translation
TB> tables are never freed or never reused. Obviously, I can't
TB> extract out the table from overridden translations.
KK> You can't extract the original translations, that's correct.
TB> Come to think of it; how is this handled when translations are
TB> parsed in resource files? If I have lots of translation
TB> overrides, do they simply burn up space that can't be reused?
TB> Does it get burned up over and over as I create widgets that
TB> use those translation resources?
KK> Yup and yup.
-----------------------------------------------------------------------------
Subject: 101) When I add text to a scrolling text widget, how can I get the
new text to show?
[Last modified: Sept 94]
Answer: Use the (fully supported) function XmTextShowPosition:
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 XmTextGetLastPosition.
position = XmTextGetLastPosition(w)
-----------------------------------------------------------------------------
Subject: 102) How do I scroll text to display the most recently added
information?
[Last modified: Aug 95]
Answer: If you're using the XmScrolledText widget, use XmTextSetTopCharacter()
or XmTextScroll().
Ken Lee
-----------------------------------------------------------------------------
Subject: 103) 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: 104) How can I stop the text widget from echoing characters typed?
I need to turn off echo for password input.
Answer: Use the XmNmodifyVerifyCallback 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: 105) How can I replace characters typed with say a `*'? I want to
replace input for password entry.
[Last modified: Nov 96]
Answer: The solution involves the use of XmNmodifyVerifyCallback and then
examining the XmTextVerifyCallbackStruct. The following program from Dan
Heller and Paula Ferguson illustrates this:
/* Written by Dan Heller and Paula Ferguson.
* Copyright 1994, O'Reilly & Associates, Inc.
* Permission to use, copy, and modify this program without
* restriction is hereby granted, as long as this copyright
* notice appears in each copy of the program source code.
* 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.
*
* 9Sept1996 RAF -- this is a working version, at least under Sol2.4,
* using gcc. I only modified check_passwd().
*
*/
/* password.c -- prompt for a password. 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;
XtSetLanguageProc (NULL, NULL, NULL);
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);
}
/* check_passwd() -- handle the input of a password. */
void
check_passwd(text_w, client_data, call_data)
Widget text_w;
XtPointer client_data;
XtPointer call_data;
{
char *new;
char *oldpasswd;
int len;
XmTextVerifyCallbackStruct *cbs =
(XmTextVerifyCallbackStruct *) call_data;
if (cbs->reason == XmCR_ACTIVATE) {
printf ("4assword: %s0, passwd);
return;
}
if( cbs->text->length > 1 ) {
cbs->doit = False; /* don't allow paste operations; make the */
return; /* user type the password! */
}
if( cbs->startPos < cbs->endPos ) {
/* shrink the password by moving endPos... characters forward to
/* the point of deletion */
memmove( &(passwd[cbs->startPos]),
&(passwd[cbs->endPos]),
strlen(passwd) - cbs->endPos + 1 );
if( cbs->text->length == 0 ) /* then just a delete, not a replace */
return;
}
new = XtMalloc( cbs->text->length + 1 );
strncpy( new, cbs->text->ptr, cbs->text->length ); /* just the new chars */
new[cbs->text->length]=' ';
if( passwd ) {
/* open a hole for the new characters, and insert them
/* in the proper place */
passwd = XtRealloc( passwd, strlen(passwd) + cbs->text->length + 1 );
memmove( &(passwd[cbs->startPos + cbs->text->length]),
&(passwd[cbs->startPos]),
strlen(passwd) - cbs->startPos + 1 );
memcpy( &(passwd[cbs->startPos]), new, cbs->text->length );
} else {
passwd = new;
}
memset( cbs->text->ptr, '*', cbs->text->length ); /* makes it all stars */
}
Thanks to OM1_JDA@pki-nbg.philips.de (Joerg Danne) for alerting me to updating
this code sample. Thanks also to Russell Fink (rfink@polaris.umuc.edu) for
providing the Nov. 1996 code update.
-----------------------------------------------------------------------------
Subject: 106) How can I make a text widget insensitive without graying out
the text?
[Last modified: Dec 98]
This is mostly a problem in Motif 1.2 and later, since grayed-out text is
sometimes difficult to read.
Instead of making the widget insensitive, set XmNeditable to false.
Ken Lee
-----------------------------------------------------------------------------
Subject: 107) How can I best add a large piece of text to a scrolled text
widget?
[Last modified: Sept 94]
[NOTE: This problem is probably only relevant for Motif 1.0 which probably no
one is using anymore. If you know this to still be a problem, send mail to
kenton@nojunk.rahul.net. I'll probably remove this question otherwise.]
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: 108) How can I get the correct colors for scrolled text widget
scrollbars (Sun only)?
[Last modified: Nov 97]
Answer: Michael Hall <mhall@semy.com> writes:
I have found a fix to a bug which is common on SUN platforms. The problem is
that the scroll bars on scrolled text widgets are not colored or shaded
correctly.
scrolledWindowText2 = XtVaCreateManagedWidget("scrolledWindowText2",
xmScrolledWindowWidgetClass,
form1,
XmNscrollBarDisplayPolicy, XmSTATIC,
NULL );
runValuesText = XtVaCreateManagedWidget("runValuesText",
xmTextWidgetClass,
scrolledWindowText2,
XmNeditMode, XmMULTI_LINE_EDIT ,
XmNeditable, FALSE,
NULL );
/* workaround a Motif bug - text widget scroll bars are wrong color,
and not shaded. */
/* by Michael Hall */
/* just to get background */
junkScroll = XmCreateScrollBar(form1, "junkScroll", NULL, 0);
XtVaGetValues(junkScroll,
XmNbackground, &junkPixel,
NULL);
XtVaGetValues(XtParent(runValuesText),
XmNchildren, &kids,
XmNnumChildren, &numkids,
NULL);
for (n=0;n<numkids;n++)
{
if (XmIsScrollBar(kids[n]))
{
XtVaSetValues(kids[n],
XmNbackground, junkPixel,
XmNshadowThickness, 30,
XmNwidth, 200,
XmNheight, 200,
NULL);
XmChangeColor(kids[n], junkPixel);
}
}
-----------------------------------------------------------------------------
Subject: 109) How can I highlight text in the Text widget?
Answer: argv@zipcode.com (Dan Heller) wrote:
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: 110) How can I select all of the text in a widget programmatically?
So that some initial text is displayed, but anything typed replaces it.
[Last modified: July 95]
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.
Jon A. Christopher (jac8792@tam2000.tamu.edu) writes:
I have had difficulty getting this to work as described (even though it agrees
with the documentation). I believe that it may be because I usually change
the TextField to some value and then try to select it. I haven't looked at
the internals of the TextField widget, but it must only select the text if the
text hasn't changed since the time specified. Ususally the
"LastTimestampProcessed" will be be *before* you modify the text, and the
selection is therefore ignored. I'd suggest using the CurrentTime variable.
This is an X variable which, if used will make sure that your text is always
selected.
-----------------------------------------------------------------------------
Subject: 111) Can I customize the pointer cursor or insert position indicator
used by the text widget?
[Last modified: May 97]
Answer: No. These are hard coded.
Ken Lee
-----------------------------------------------------------------------------
Subject: 112) How can I change colours of text in the Text widget? I want
some of the text in one colour, some in another.
[Last modified: Feb 98]
Answer: In Motif 1.x, 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.
In the Motif 2.0 CSText widget, XmStrings may be different colors in the same
widget.
Note, however, that the CSText widget was dropped from Motif 2.1.
Ken Lee
-----------------------------------------------------------------------------
Subject: 113) How can I change the font of text in the Text widget? I want
some of the text in one font, some in another.
[Last modified: Feb 98]
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.
If you are using Motif 2.0, however, XmStrings are now permitted in CSText
widgets, which solves this particular problem.
Note, however, that the CSText widget was dropped from Motif 2.1.
Ken Lee
-----------------------------------------------------------------------------
Subject: 114) Is there an emacs binding for the text widget?
Answer: This set is due to Kee Hinckley:
*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()
! 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: 115) What if I have problems with the backspace/delete keys?
[Last modified: Dec 94]
Answer: mclarnon@maths.ox.ac.uk (Gerald.McLarnon) writes:
I am running a precompiled program based on motif and am having some problems
with the backspace/delete keys. Following the instructions of the faq I put th
e following lines in my .Xdefaults file
*XmText.translations: #override <Key>osfDelete: delete-previous-
character() *XmTextField.translations: #override <Key>osfDelete:
delete-previous-character() This meant that in dialogue boxes (such as 'Open
File') the delete key deleted to the left, but not in the main application
window.
Any hints for someone who isn't much of an X-pert?
David Kaelbling <drk@x.org> replied:
There are a couple possibilities. In addition to the precedence of loading
resource files (explained in section 2.3 of the X11R5 X Toolkit Intrinsics
manual), resource values in the database are chosen based on a "most explicit
match" algorithm (i.e. those with the most qualifiers on the left hand side
win -- see section 15.2 of the X11R5 Xlib - C Library manual). So if this
application's app-defaults file or fallback resources says
*Foo*XmText.translations:... that value will be used instead of yours.
Find the app-defaults file for your application and look to see if it
specifies translations for text widgets in the main application; if it does
you'll need to make yours at least as explicit.
If the app-defaults file isn't the problem then the application may be hard-
wiring the translations. If that's the case you'll probably have to change
your virtual key bindings so that the key you think of as osfDelete is really
osfBackSpace. You can do that for an individual application by setting its
defaultVirtualBindings resource, or for all Motif applications with a
$HOME/.motifbind file ("man xmbind" and "man VirtualBindings" give more detail
and alternatives). In either case you'll need to specify a complete list of
virtual key bindings; there is no equivalent to #override. To find out your
current virtual key bindings run "xprop -root | fgrep BINDINGS" and clean up
the result.
-----------------------------------------------------------------------------
Subject: 116) 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 file\n", 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!\n");
text[statb.st_size] = 0; /* be sure to NULL-terminate */
/* insert file contents in Text widget */
XmTextSetString(text_w, text);
-----------------------------------------------------------------------------
Subject: 117) How can put Text in overstrike mode instead of insert?
[Last modified: Mar 95]
Answer: (Be sure to read the update after the first answer. This is also a
second update which cautions against the approach.)
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.
An update was provided by Ingeborg (inca@osf.org):
In 1.2 and later releases, there is an action function toggle-overstrike()
which will toggle between overstrike and insert mode. Before 1.2.3, there is
no visual difference, and at most one character will get overstruck. In 1.2.3,
a block cursor was added as a visual cue to that the widget is in overstrike
mode, and the code was fixed to overstrike the actual number of characters
input (this makes a difference if you have preediting - for example in
japanese).
There is no default binding in 1.2, but the recommended key is osfInsert
without modifiers. No resource exists.
Ed Kaltenbach (kaltenba@ataway.aptec.com) wrote:
I was simulating overstrike mode in the Text Field widget by using
the delete_next_character solution listed in subject 71.
When the software is compiled with Motif 1.2.2, the modifyVerify
callback does not get called for the last character when XmNmaxLength
is specified. It seems that the check if maxLength has been reached
is done before the modifyVerify gets called and it keeps the modifyVerify
from being called. Is this a Motif bug? Does anybody have a solution that
will work with Versions 1.1 and 1.2 of Motif?
Phil Day <phil@cfmu.eurocontrol.be> responded to Ed (and apologized for only
sending pseudocode!):
I've had the same problem, and for my money it's a bug. My workaround is to
make all text widgets (I don't use textfield because of some other problems in
the past) have XmNmaxLength > XmNcolumns, so that the modifyVerify callback
gets a chance to do its stuff.
If you only want to support overstrike for typing, 1 extra charater is enough,
but if you want to support cut-and-paste for any length string you need
maxLength = 2*columns. In the modifyVerify you have to check the result is <
columns.
I've tried using the Motif 1.2 support for overstrike, but this just seems to
work on a kind of pending-delete and only works for the single charater
replacement caes (that's my main argument for calling it a bug).
I don't use delete-next-character (I can't remember why just now, but I know I
had some problem with it). Instead I have something like the following:
modifyVerify()
{
if (acceptable)
XmReplaceText(...)
cd->doit = False;
// we've just done it, we don't wnat Motif to !
XtVaSetValues (w,
XmNverifyBell, False,
NULL);
// Otherwise we'll get a beep.
}
valueChanged()
{
XtVaSetValues (w,
XmNverifyBell, True,
NULL);
// turned off in modifyVerify
}
Glenn Mandelkern <gmandel@Corp.Megatest.Com> writes about a problem with the
above solution.
We have been running our software on Sparc 20's, under Motif 1.1
and Motif 1.2, X11R5, Solaris 2.4.
Unfortunately, some colleagues and I have found a disturbing side effect
when following this suggestion. Calling XtVaSetValues() in the
modifyVerifyCallback causes the Text widget to flash.
The O'Reilly guides say not to call XtVaSetValues() during text
modification callbacks. Motif Volume 6 has this on page 511 and
Motif Volume 6A has it on page 496.
I myself thought it would be fairly trivial to just switch the bell
on and off. But since XtVaSetValues() calls XmText's set_values() method,
my guess is that its set_values() does something that causes this.
So when you enter characters, the Text widget flashes. It also slows
down the performance of the Text widget. You'll see this on a multi-line
Text widget, especially with it occupying a full screen with text.
If you want to see this, take the editor.c program in Volume 6 or 6A,
then add a modifyVerifyCallback to the text_output widget. Then inside
that callback, call XtVaSetValues with the XmNverifyBell like above.
This is a common "mistake", one which I've done more than once.
I remember also that when I did not have the XtVaSetValues() in place,
I got the beeps.
So now we've reworked the application as follows:
1. The Text widget is initially created with XmNverifyBell
set to False.
2. We ring the bell using XBell() when we detect a condition
for which we want to veto text modifications.
For our application, this provides the wanted feedback and gets rid
of the flashes.
-----------------------------------------------------------------------------
Subject: 118) How can I make the Delete key do a Backspace? Related
question: How can I swap Delete and Backspace?
[Last modified: Oct 94]
Answer: Put this in your .Xdefaults
*XmText.translations: #override <Key>osfDelete: delete-previous-character()
Additional information from David Kaelbling <drk@x.org>:
You can also supply an arbitrary file name to xmbind (so you can conditionally
run xmbind from your .xinitrc file based on the hostname, architecture,
xdpyinfo output, or whatever).
Some people prefer to use xmodmap to swap the keysyms for all applications,
but what you're doing will work fine if you specify all of the virtual key
bindings. The current bindings are stored on the root window -- use "xprop
-root" and look for a _MOTIF_BINDINGS or _MOTIF_DEFAULT_BINDINGS property.
OSF/Motif is also distributed with a "bindings" directory containing all the
fallback virtkey binding files.
There are several ways to do display-specific customization: make
-----------------------------------------------------------------------------
Subject: 119) Can I change the tab stops in the XmText widget?
[Last modified: May 95]
Answer: No.
Ken Lee
-----------------------------------------------------------------------------
END OF PART FOUR
-----------------------------------------------------------------------------
Subject: 120) TOPIC: LIST WIDGET
-----------------------------------------------------------------------------
Subject: 121) Should I create an XmList widget as a child of automatic
XmScrolledWindow or use the XmCreateScrolledList() convenience function?
Answer: With most implementations, the convenience function use internal hooks
to give somewhat better scrolling performance.
Ken Lee, http://www.rahul.net/kenton/
-----------------------------------------------------------------------------
Subject: 122) How do I best put a new set of items into a list?
Answer: Set the new list count and list by XtSetArgs and install them by
XtSetValues.
XmString list[SIZE];
int list_size;
XtSetArg (args[n], XmNitemCount, list_size); n++;
XtSetArg (args[n], XmNitems, list); n++;
XtSetValues (w, args, n);
or similarly with XtVaSetValues:
XtVaSetValues (w,
XmNitemCount, list_size,
XmNitems, list,
NULL);
Each time the list is reset by this the old contents are freed by the widget
and the new supplied list is copied. Do *not* free the old list of items
yourself as this would result in the space being freed twice. It is not
necessary to remove the items one at a time, nor to "zero" out the list first.
-----------------------------------------------------------------------------
Subject: 123) Can I have strings with different fonts in a list?
[Last modified: Sept 95]
Answer: Yes. The strings are XmStrings. Each one can be created using a
different character set using a different font.
However, arjav@caip.rutgers.edu (ARJAV PARIKH) wrote:
If a string is added to the listbox, the font in the listbox overrides the
font set using XmCreateString. The Command widget label retains the font set
using XmCreateString. I read in the MOTIF FAQ that it is possible to add
strings with multiple fonts to the listbox. I learned from one of the tech
support persons that internal code of the listbox overrides the font.
Madhusudan Poolu (madhu@corp.sgi.com) replied:
You need to create a fontlist for your font and add it to your listbox widget
using XtVaSetValues ( wList, XmNfontList, yourFontList, NULL). This technique
can also be used to display multi-font strings in a list box.
-----------------------------------------------------------------------------
Subject: 124)* Can I get a bitmap to show in a list item like I can in a
Label? I want to place a bitmap along with some normal text in my list items.
[Last modified: Jun 2000]
Answer: Andrew Lister (lister@bain.oz.au) writes: The XbaeMatrix widget allows
a bitmaps in a cell. There will be support for colour pixmaps to be displayed
in version 4.4 which should be available very soon. (The XbaeMatrix can be
made to look and behave like a list widget. The widget is compatible with
Motif 1.2 and Motif 2.0.)
Beginning with version 4.7, XbaeMatrix is being maintained by the Lesstif
project. The current version is version 4.8. Source code and a FAQ are
available from:
http://www.lesstif.org/Xbae.html
http://www.lesstif.org/Lessdox/XbaeFAQ.html
Alan Peery (peery@isc.tamu.edu) writes: Motif 2.0 introduced the "container"
widget, which offers 2-D icon and text layout similar to that found in many
file management programs. It could probably be used as a 1-D list widget
also.
A previous source wrote: In Motif 1.x, you cannot do this. The list contains
XmStrings, and these only allow text in various character sets. The workaround
is to define your font containing the icons you want. Then you can create a
fontlist containing your icon font and the font you want the text in, and then
make your items multi-segment XmStrings where the first segment contains the
code of the icon you want with a charset that matches the icon font in your
fontlist and the second segment with a charset matching the text font.
-----------------------------------------------------------------------------
Subject: 125)* Can I have items with different colors in a list widget?
[Last modified: Jun 2000]
Answer: Andrew Lister (lister@bain.oz.au) writes: The XbaeMatrix widget can
have a different foreground and background in each cell, row or column. (The
XbaeMatrix can be made to look and behave like a list widget. The widget is
compatible with Motif 1.2 and Motif 2.0.) You can get the latest version of
XbaeMatrix from:
http://www.lesstif.org/Xbae.html
Ken Lee wrote: Not in Motif 1.x. The list contains XmStrings, and these only
allow text in various character sets.
However, in Motif 2.0 you _can_ have multiple colors in the same list since
colored XmStrings are supported.
Thanks to Ken Lee, http://www.rahul.net/kenton/, for the update.
If you're using Motif 1.2, another possibility is to use SCO Premier Motif
(1.2) library has this extension built into the List widget, along with a few
others. See http://www.premier.sco.com/
Thanks to richardo@x.co.uk (Nhi Vanye)
-----------------------------------------------------------------------------
Subject: 126)* How can I line up columns in a list widget?
[Last modified: Jun 2000]
Answer: The simplest answer is to use fixed-width fonts and spaces to line up
columns. There are also some more general solutions follow.
David Kaelbling <drk@sgi.com> writes:
Motif 2.x supports tab components in XmStrings. Insert XmSTRING_COMPONENT_TAB
segments into your XmStrings, either with XmStringComponentCreate() and
XmStringConcatAndFree(), or with the XmStringParseText() api). Then use
XmStringTableProposeTabList() to get a default set of non-overlapping tabs.
Put that XmNtabList into a rendition in the list's render table.
Andrew Lister (lister@bain.oz.au) writes:
The XbaeMatrix can do this too, for both fixed and non fixed width fonts.
(The XbaeMatrix can be made to look and behave like a list widget. The widget
is compatible with Motif 1.2 and Motif 2.0.) You can get the latest version of
XbaeMatrix from: http://www.lesstif.org/Xbae.html
Ken Lee writes:
Other Motif-compatible and matrix grid and matrix widgets are available. See
the widgets FAQ for pointers.
-----------------------------------------------------------------------------
Subject: 127) Can I grey out an item in a list widget? I want to make
insensitive items in a list so that they cannot be selected.
[Last modified: Feb 98]
Answer: W. Scott Meeks of OSF wrote:
Unfortunately, you can't do it directly since the list items aren't individual
widgets. We've had other requests for this technology, but it didn't make the
cut for 1.2; it should be in some future release.
However, you can probably fake it in your application with some difficulty.
First, a list item is an XmString, so you can specify a different charset for
the item than for other items in the list and then specify a font in the
list's fontlist that matches the charset and gives you the visual you want.
The next problem is making the item unselectable. One idea would be to have
the application keep track of the insensitive items and the items currently
selected. Then you would set up a selection callback that when called would
check the item selected against the list of insensitive items and if the
selected item matched would deselect that item and reselect the previously
selected items. Otherwise it would just update the application's list of
selected items. The major drawback with this approach is that you'll get
flashing whenever the list selects an item and your application immediately
de-selects. Unfortunately I can't think of a way around this without mucking
with the list internals.
Another alternative suggested is to use instead a column of say read only text
widgets which you can make insensitive.
Ken Lee adds: Motif 2.0 allows you to create multi-color XmStrings. You can
use this feature to grey out specific list items.
-----------------------------------------------------------------------------
Subject: 128) 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: 129) How can I tell the position of selected items in a list?
[Last modified: Oct 92]
Answer: W. Scott Meeks wrote:
1) All XmList selection callbacks get an XmListCallbackStruct which includes
the item selected and its position. In addition, the multiple and extended
selection callbacks also get a list of the selected items. This approach
requires that your application saves this information if you need it outside
of the immediate callback.
2) At any time you can XtGetValues the XmNselectedItems and
XmNselectedItemCount resources. The problem with this approach is that
identical items may or may not show up in multiple times in this list and the
position in the selectedItems list may not relate directly to the position in
the items list.
3) You can call XmListGetSelectedPos on the list widget. This will return a
list of the positions of all selected items.
-----------------------------------------------------------------------------
Subject: 130) How can I configure a scrolled list widget to show a horizontal
scrollbar when some list items are wider than the window?
[Last modified: May 97]
Answer: Set *XmList.listSizePolicy: XmCONSTANT
Ken Lee
-----------------------------------------------------------------------------
Subject: 131) How can I programatically select all of the items in an XmList?
[Last modified: May 98]
Answer: Invoke the same action that "C-/" uses for selecting everything. Try
something like:
XtCallActionProc(list, "ListKbdSelectAll", event, NULL, 0);
If you don't have an event handy passing NULL for it will probably work too.
The lack of an XmListSelectAllItems() api was just an oversight.
David KAELBLING <drk@sgi.com>
-----------------------------------------------------------------------------
Subject: 132) TOPIC: FILE SELECTION BOX WIDGET
-----------------------------------------------------------------------------
Subject: 133) What is libPW.a and do I need it? My manual says I need to
link in libPW.a to use the File Selection Box. I can't find it on my system.
[Last modified: Sept 94]
Answer: The libPW.a is the Programmers Workbench library which is an ATT
product not included in Berkeley based systems, hence it is not found in SunOS
or Ultrix, but is found on HP-UX (a Berkeley/ATT hybrid which chose ATT in
this case). It contains the regex(3) routines (regcmp, regex). Some systems
which don't have these in the libc.a need to link with -lPW. Some systems
which have the regex(3) routines in there also have the libPW.a. If you have
regex(3) in libc, and it works, don't link with libPW. If you don't have
regex(3) in libc, and you don't have a libPW, then check some sites on the net
for public domain replacements (several exist), or call your vendor.
In most versions of Motif (see the doco), you can compile FileSB.c with
-DNO_REGEX if you don't have it.
Casper H.S. Dik (asper@fwi.uva.nl), Faculty of Mathematics & Computer Science,
University of Amsterdam, sent this update for Solaris 2.x users:
The regex and regcmp function are part of libgen in SVR4. Motif applications
should be linked with -lgen. (However, some SVR4 implementations, especially
those of vendors that once shipped SVR3 still contain libPW.)
On Solaris 2.x system, you'll need libgen which is located in /usr/ccs/lib.
-----------------------------------------------------------------------------
Subject: 134) What are these compile errors: Undefined symbol _regcmp and
_regex?
[Last modified: Sept 94]
Answer: You need to link in the libPW or libgen library - see previous
question.
-----------------------------------------------------------------------------
Subject: 135) What's wrong with the Motif 1.0 File Selection Box? I can't
set the directory, change the directory or get the file mask to work.
Answer: The 1.0 File Selection Box is broken, and these don't work. They
weren't fixed until Motif 1.04. Use these later versions of 1.0 or switch to
Motif 1.1 where it changed a lot.
Joe Hildebrand has a work-around for some of this: Before popping up an
XmFileSelectionDialog, change to the directory you want. When a file is
selected, check if it is a directory, so that we can change to it. i.e.
static void show_file_box_CB(w, client_data, call_data)
Widget w;
Widget client_data;
XmAnyCallbackStruct *call_data;
{
chdir("/users/hildjj/files");
XtManageChild(client_data);
}
static void val_save(w, client_data, call_data)
Widget w;
Widget client_data;
XmSelectionBoxCallbackStruct *call_data;
{
struct stat buf; /* struct stat is defined in stat.h */
char *filename;
/* get the file name from the FileSelectionBox */
filename = SmX(call_data->value);
/* get the status of the file named filename, and put it into buf */
if (!stat(filename, &buf))
{
/* if it's a directory */
/* if it's a directory */
if(S_ISDIR(buf.st_mode))
{
/* change to that directory, and update the FileSelectionBox */
chdir(filename);
XmFileSelectionDoSearch(w, NULL);
}
else
/* if it's a regular file */
if(S_ISREG(buf.st_mode))
/* ask if it should be overwritten */
XtManageChild(valbox);
else
/* it's another kind of file. What type, i can't think of,
but it might happen */
pop_up_error_box(client_data, "Error saving file");
}
else /* we couldn't get the file status */
{
/* if it's because the file doesn't exist, we're golden */
if (errno == ENOENT)
save_file();
else /* there is some other problem getting the status.
e.g. bad path */
pop_up_error_box(client_data, "Error saving file");
}
}
this still doesn't implement the file masking stuff.
-----------------------------------------------------------------------------
Subject: 136) How can I keep my file selection boxes from resizing when I
change directories or filters?
[Last modified: May 97]
Answer: Set XmNresizePolicy (XmFileSelectionDialog is a subclass of
XmBulletinBoard) to XmRESIZE_NONE.
-----------------------------------------------------------------------------
Subject: 137) What's wrong with the FileSelectionBox under Solaris?
[Last modified: May 97]
Answer: Jim Guyton (guyton@burton.cs.colorado.edu) writes:
While not strictly a Motif problem, this one had me confused for [awhile].
If under Solaris the entries in a FileSelectionBox look strange and seem to be
missing the first two characters of many filenames, then be sure you're
linking -lc before -lucb.
If on the other hand, the filenames look strange and seem to have two garbage
characters in front of every filename, be sure to link -lucb before -lc.
There are two versions of readdir(). The one in -lucb returns a structure
that has the filename at an offset of 8 bytes (which matches
/usr/ucbinclude/sys/dir.h).
But the version in -lc returns the filename at an offset of 10 bytes (which
matches /usr/include/dirent.h).
So depending on how Motif was built for your Solaris, vs. how you link your
application, your filenames could be two bytes off in either direction.
Harry Cohen (hbcohen@bell.tds-eagan.lmco.com) writes: I also had this problem
(the missing horizontal scroll bar with Solaris 2.5.1 and 2.4) and have talked
with Sun. This is a problem with the Sun Motif library in /usr/dt/lib.
You need to install the following Sun patches to correct this problem: For
Solaris 2.5.1: patch 103461-03 For Solaris 2.4: patch 102226-19
Note: For Solaris 2.4, the horizontal scroll problem existed in a previous
patch release, so most people haven't seen it.
Scott W. Sadler (sws@iti-oh.com) writes: We had this same problem, and it took
a while to figure it out. If you use the Motif libraries out of /usr/dt/lib,
the file selection box gives the problem you indicate. However, if you use
the Motif libraries out of /opt/SUNWspro/Motif_Solaris24/dt/lib, all is fine.
Make sure your LD_LIBRARY_PATH, is set correctly to pick up the right shared
libraries at run time. Also check out the "-R" option to the linker to encode
the library search paths. Finally use the "ldd" program to make sure that you
are picking up the correct libraries.
-----------------------------------------------------------------------------
Subject: 138) TOPIC: FORM WIDGET
-----------------------------------------------------------------------------
Subject: 139) Why don't labels in a Form resize when the label is changed?
I've got some labels in a form. The labels don't resize whenever the label
string resource is changed. As a result, the operator has to resize the window
to see the new label contents. I am using Motif 1.1.
Answer: This problem may happen to any widget inside a Form widget. The
problem was that the Form will resize itself when it gets geometry requests
from its children. If its preferred size is not allowed, the Form will
disallow all geometry requests from its children. The workaround is that you
should set any ancestor of the Form to be resizable. For the shell which
contains the Form you should set the shell resource XmNallowShellResize to be
True (by default, it is set to FALSE). There is currently an inconsistency on
how resizing is being done, and it may get fixed in Motif 1.2.
db@sunbim.be (Danny Backx) wrote:
Basically what you have to do is set the XmNresizePolicy on the Form to
XmRESIZE_NONE. The facts seem to be that XmRESIZE_NONE does NOT mean "do not
allow resizes". You may also have to set XmNresizable on the form to True.
-----------------------------------------------------------------------------
Subject: 140) How can I center a widget in a form?
[Last modified: Nov 96]
Answer: One of Motif's trickier questions. The problems are that: Form gives
no support for centering, only for edge attachments, and the widget must stay
in the center if the form or the widget is resized. Just looking at
horizontal centering (vertical is similar) some solutions are:
a. Use the table widget instead of Form. A hack free solution is from Dan
Heller:
/* Written by Dan Heller. Copyright 1991, O'Reilly && Associates.
* This program is freely distributable without licensing fees and
* is provided without guarantee or warranty expressed or implied.
* This program is -not- in the public domain. This program is
* taken from the Motif Programming Manual, O'Reilly Volume 6.
*/
/* corners.c -- demonstrate widget layout management for a
* BulletinBoard widget. There are four widgets each labeled
* top-left, top-right, bottom-left and bottom-right. Their
* positions in the bulletin board correspond to their names.
* Only when the widget is resized does the geometry management
* kick in and position the children in their correct locations.
*/
#include <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);
/******** WARNING! Next statement is questionable in 1996. See
******** "Can you reuse the return value from XtParseTranslationTable?"
******** If someone corrects this code, send it to kenton@nojunk.rahul.net
********/
XtOverrideTranslations(bboard,
XtParseTranslationTable("<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);
}
b. No uil solution has been suggested, because of the widget size problem.
c. Cameron Hayne (hayne@crim.ca) suggests another solution:
Attach the widget with XmATTACH_POSITION but offset it by half of its
width. You will likely have to create the widget first and then query it
to find out its width. Thus the following function is useful - you can
call it immediately after the widget is created.
void center_it(Widget wgt)
{
Dimension width;
XtVaGetValues(wgt, XmNwidth, &width, NULL);
XtVaSetValues(wgt, XmNleftAttachment, XmATTACH_POSITION,
XmNleftPosition, 50, /* assumes fractionBase is 100 */
XmNleftOffset, -width/2, NULL);
}
The idea is: get the size of the widget and then offset it by half that
much from position 50. The above function will likely only work for
primitive widgets if you call it immediately after the widget is created.
For manager widgets you will likely have to wait to call the center_it()
function until after the widget has been realized since it is only then
that a manager widget's size is finally determined. (Refer to discussion
by Daniel Dardailler "Application's Geometry Management Advanced
Guidelines" in this FAQ.)
-----------------------------------------------------------------------------
Subject: 141) 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: 142) TOPIC: PUSHBUTTON WIDGET
-----------------------------------------------------------------------------
Subject: 143) Why doesn't the enter or return key activate the button with
focus?
[Last modified: Sep 98]
Answer: Motif uses the return key to activate the default button on dialogs,
bulletin boards, and forms. You can use the space key to activate the focus
button. These are they same keyboard shortcuts as MS-Windows.
-----------------------------------------------------------------------------
Subject: 144) Why can't I use accelerators on buttons not in a menu?
[Last modified: Sept 94]
Answer: It is apparently a difficult feature to implement, but OSF are
considering this for the future. It is problematic trying to use the Xt
accelerators since the Motif method interferes with this. one workaround
suggested is to duplicate your non-menu button by a button in a menu
somewhere, which does have a menu-accelerator installed. When the user
invokes what they think is the accelerator for the button they can see Motif
actually invokes the button on the menu that they can't see at the time.
Another method is described below and was contributed by Harald Albrecht of
Institute of Geometry and Practical Mathematics Rhine Westphalia Technical
University Aachen (RWTH Aachen), Germany
albrecht@igpm.rwth-aachen.de wrote (Jul 8, 1993):
NOTE: Pointers to a more recent solution by the same author follow this code
sample.
My work-around of this problem looks like this: (I've written that code for a
Motif Object Library in C++ so please forgive me for being object orientated!)
The hack consists of a rewritten message loop which checks for keypresses
<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
NOTE: Harald Albrecht has re-designed his solution so that you can assign
hotkeys to *every* widget by placing a label near that widget. Get the code
from:
ftp.informatik.rwth-aachen.de (137.226.112.172) in:
/pub/packages/Mnemonic/Mnemonic.tar.gz
or from the WWW:
file://134.130.161.30/arc/pub/unix/html/motifcorner.html
-----------------------------------------------------------------------------
Subject: 145) TOPIC: TOGGLEBUTTON WIDGET
-----------------------------------------------------------------------------
Subject: 146) What widgets give the look of push buttons, but behavior of
toggle buttons?
Answer: Use the XmToggleButton widget, setting XmNindicatorOn to False and
XmNshadowThickness to 2. Also set XmNfillOnSelect to True. Otherwise, the
background color of the button will not stay in the "armed" state.
In Motif 1.2 (and later), if you specify a XmNselectColor and set
XmNindicatorOn to False, then you need to set XmNfillOnSelect to True.
XmNfillOnSelect is not necessary if you are not setting a XmNselectColor.
Glenn McMillen, mcmillen@meadow.mdso.vf.ge.com and Ken Lee
-----------------------------------------------------------------------------
Subject: 147) Can I customize XmToggleButton to use my own indicator graphic
(e.g., a check mark)?
[Last modified: Nov 96]
Answer: There is no direct resource for the graphic. One way to work around
this is to disable the indicator (XmNindicatorOn False) and then install
selected/unselected pixmaps containing both your graphic and your text
(XmNselectPixmap and XmNselectPixmap). Also disable the button shadows
(XmNshadowThickness 0) if you don't want those.
Ken Lee
-----------------------------------------------------------------------------
Subject: 148) TOPIC: ICON WIDGET and PIXMAPS
-----------------------------------------------------------------------------
Subject: 149) What is XPM?
[Last modified: Sept 98]
Answer: XPM is file format for color images. A programming libary is also
available. XPM is based on the standard XBM monochrome file format and Xlib
related convenience functions.
The XPM home page is: http://www.inria.fr/koala/lehors/xpm.html It has pointes
to the source code and detailed documentation.
Ken Lee
-----------------------------------------------------------------------------
Subject: 150) How do I convert my XPM file into a Pixmap?
[Last modified: Sept 98]
Answer: Motif 2.0 and later contain an XPM-to-pixmap resource converter, so
you can specify your pixmaps as resources.
In Motif 1.2, you have to use the XPM library to load the XPM files.
Ken Lee
-----------------------------------------------------------------------------
Subject: 151) How can I display a multi-color image in a widget?
[Last modified: Sept 95]
Answer: Get the XPM library and read the documentation. Get xpaint from
ftp.x.org, also get the jpeg and tiff libraries on the internet. From these
you can easily create the code to read in gif, jpeg, and tiff.
Read the images into and XpmImage format. Then use one of the Xpm conveneince
functions to create wither an XImage or a Pixmap from your data. The xpm lib
will take care of the color allocation and Pixmap/XImage creation, then you
can just use expose routines to copy the Pixmap into a dialog or any
window....
Thanks to Ramiro Estrugo (restrugo@fateware.com)
-----------------------------------------------------------------------------
Subject: 152) Can I use XmGetPixmap in Motif 1.2 to create colored images?
[Last modified: Oct 95]
Answer: Doug Rand (drand@sgi.com) writes:
XmGetPixmap only converts XBM [X bitmap] files in 1.2. In 2.0 it supports XPM
[X Pixmap] files. You can register a more capable converter and set the
pixmap via resources as a workaround. You can also use libXpm
directly...[Note that] even now there isn't a "standard" color pixmap file
format. There are several. It is relatively recently that many people have
settled on XPM. But even so not everyone has done this.
-----------------------------------------------------------------------------
Subject: 153) Why does XpmCreatePixmapFromData fail with a pixmap containing
a large number of colors? XpmCreatePixmapFromData gives me a -4 errno (which
is XpmColorFailed) when I try using a pixmap with 242 colors
[Last modified: Oct 95]
Answer: Ramiro Estrugo (restrugo@fateware.com) writes:
If you are allocating 242 colors in an 8 bit display, then you are likely to
run out of colors. If you carefully read the Xpm manual, you will notice that
one of the Xpm values that you can modify is the "closeness". This value will
control the actual closness of the colors allocated by the Xpm library.
According to the Xpm manual:
o The "closeness" field(s) (when set) control if and how colors
are found when they failed to be allocated. If the color cannot
be allocated, Xpm looks in the colormap for a color that matches
the desired closeness.
o The value is an integer in the range 0 (black) - 65535 (white)
o A closeness of less than 10000 will cause only "close" colors to
match.
o A cliseness of more than 50000 will allow quite disimilar colors
to match.
o A closeness of more than 65535 will allow any color to match.
o A value of 40000 seems reasonable for many situations requiring
reasonable but not perfect color matches.
Try it and your application is less likely to die or look "ugly" due to the
lack of colors. The worst that can happed is that the colors you get are not
100% what you wanted them to be. Most of the time, you might not even notice
the difference. This is usually due to badly designed icons or duplicate
color entries (close rgb values) in .xpm files.
NOTE: for even more control over Xpm color allocation, you can control the
closeness of each RGB color component individually.
For example:
XpmAttributes attrib;
int valuemask;
attrib.valuemask |= XpmCloseness;
attrib.closeness = 40000;
/* also */
attrib.valuemask |= XpmRGBCloseness;
attrib.red_closeness = RED_CLOSENESS;
attrib.green_closeness = GREEN_CLOSENESS;
attrib.blue_closeness = BLUE_CLOSENESS;
pix = XpmCreateXYZFromABC(...,&attrib);
Also, look in the Xpm documentation for more color control parameters.
-----------------------------------------------------------------------------
Subject: 154) How can I convert a Sun/GIF/TIFF image to a pixmap?
[Last modified: Oct 94]
Answer: An application called "xv" (interactive image display for the X Window
System) is useful for displaying and converting many image formats. From the
man page:
xv is an X11 program that displays images in the GIF, JPEG,
TIFF, PBM, PGM, PPM, X11 bitmap, PDS/VICAR, Sun Rasterfile,
and PM formats on 1-, 2-, 4-, 6-, 8-, 16-, 24-, and 32-bit X
displays. xv will also read compress-ed versions of these
files.
You can get "xv" (shareware by John Bradley et al) from:
ftp://ftp.cis.upenn.edu/pub/xv
or:
ftp://ftp.x.org/R5contrib/xv-3.01.tar.gz
Another useful conversion package is "pbm" (portable bitmap file format) by
Jef Poskanzer et al, available from:
ftp://ftp.x.org/R5contrib/netpbm-1mar1994.tar.gz
or:
ftp://ftp.x.org/R5contrib/pbmplus10dec91.tar.Z (much older :-)
You might also want to check the X11 FAQ for additional conversion options:
ftp://ftp.x.org/contrib/faqs/FAQ
-----------------------------------------------------------------------------
Subject: 155) How can I use Motif's pre-defined pixmaps?
[Last modified: May 97]
Answer: Motif 1.2 loads the following into its image cache: background,
25_foreground, 50_foreground, 75_foreground, horizontal, vertical,
slant_right, and slant_left. These are defined in "man XmInstallImage". You
can retrieve them with XmGetPixmap or XmGetPixmapByDepth.
Ken Lee
-----------------------------------------------------------------------------
Subject: 156) TOPIC: SCALE AND SCROLLBAR WIDGET
-----------------------------------------------------------------------------
Subject: 157) Can the XmScale widget have arrows or tick marks in Motif 2.0?
[Last modified: Sep 97]
Answer: Daniel Dardailler (danield@w3.org) writes:
In 2.0 and 2.1, Scale gets arrows (on both sides or same side), thermometer
look, thumb slider option, tick marks, and editable resource.
-----------------------------------------------------------------------------
Subject: 158) How can I set the color of a XmScale widget's trough?
[Last modified: May 95]
Answer: Ken Lee wrote: There is no direct API for setting this, but you can
set it through resource files with "*XmScale*troughColor: red".
Ken Sall, ksall@cen.com, adds: If you need to do this at runtime, you can use
XtGetValues to get the scale's children, find the scrollbar, and set the
XmNtroughColor:
#include <Xm/ScrollBar.h> // for XmIsScrollBar
Pixel selectColor; // assume this is set to the desired color
WidgetList *kids;
int nkids;
Arg argList[1], tmpargs[2];
int i, s, t ;
i = 0;
XtSetArg ( argList[i], XmNtroughColor, selectColor ); i++;
// Unfortunately, scale does not have a direct way
// to get its scrollbar widget, so use Composite resources
s = 0;
XtSetArg (tmpargs[s], XmNnumChildren, &nkids ); s++ ;
XtSetArg (tmpargs[s], XmNchildren, &kids ); s++ ;
XtGetValues ( widgetId, tmpargs, s );
for ( t = 0; t < nkids; t++ )
{
if ( XmIsScrollBar ( (Widget) kids[t]) ) // from ScrollBar.h
{
XtSetValues ( (Widget) kids[t], argList, i );
}
}
-----------------------------------------------------------------------------
Subject: 159) How does Motif implement mouse button auto-repeat on the
scrollbar's arrow buttons?
[Last modified: May 97]
Answer: It installs a timer and checks the button state at each timeout. If
the button is still down, it repeats the action. You can do this in your
application, too.
Ken Lee
-----------------------------------------------------------------------------
Subject: 160) TOPIC: LABEL WIDGET
-----------------------------------------------------------------------------
Subject: 161) How can I align the text in a label (button, etc) widget?
Answer: The alignment for the label widget is controlled by the resource
XmNalignment, and the default centers the text. Use this resource to change it
to left or right alignment. However, when the label (or any descendant) is in
a XmRowColumn, and XmNisAligned is True (the default), the XmRowColumn aligns
text using its resource XmNentryAlignment. If you want simultaneous control
over all widgets use this, but otherwise turn XmNisAligned off and do it
individually.
-----------------------------------------------------------------------------
Subject: 162) Why doesn't label alignment work in a XmRowColumn?
Answer: XmRowColumn has a resource XmNisAligned (default True) and and
XmNentryAlignment (default XmALIGNMENT_BEGINNING). These control alignment of
the labelString in Labels and descendants. Set XmNisAligned to False to turn
this off.
-----------------------------------------------------------------------------
Subject: 163) How can I set a multi-line label?
[Last modified: Mar 96]
Answer: In .Xdefaults
*XmLabel*labelString: Here\nis\nthe\nLabel
This method does not seem to work in some of the older Motif 1.0 versions.
In code,
char buf[128];
XmString msg;
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. Here's
another approach from Jean-Philippe Martin-Flatin <syj@ecmwf.int>
#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 XmStringCreateLtoR,
except it does not use non AES compliant charset
XmSTRING_DEFAULT_CHARSET
----------------------------------------------------*/
XmString xec_NewString(char *s)
{
XmString xms1;
XmString xms2;
XmString line;
XmString separator;
char *p;
char *t = XtNewString(s); /* Make a copy for strtok not to */
/* damage the original string */
separator = XmStringSeparatorCreate();
p = strtok(t,"\n");
xms1 = XmStringCreateLocalized(p);
while (p = strtok(NULL,"\n"))
{
line = XmStringCreateLocalized(p);
xms2 = XmStringConcat(xms1,separator);
XmStringFree(xms1);
xms1 = XmStringConcat(xms2,line);
XmStringFree(xms2);
XmStringFree(line);
}
XmStringFree(separator);
XtFree(t);
return xms1;
}
Do not use XmStringCreateLocalized() - it does not process the newline
character in the way you want. In Motif 1.x, XmStringCreateLocalized() does
NOT process newlines, but XmStringCreateLtoR() does.
Thanks to Paul Tomblin (ptomblin@xcski.com) for the newline clarification.
-----------------------------------------------------------------------------
Subject: 164) How can I have a vertical label?
Answer: Make a multi-line label with one character per line, as in the last
question. There is no way to make the text rotated by 90 degrees though.
-----------------------------------------------------------------------------
Subject: 165) How can I have a Pixmap in a Label?
Answer: Bob Hays (bobhays@spss.com) wrote:
Pixmap px_disarm, px_disarm_insens;
Widget Label1;
Pixel foreground, background;
Arg args[4];
Arg arg[] = {
{ XmNforeground, &foreground },
{ XmNbackground, &background }
};
Label1 = XmCreateLabel ( Shell1, "Label1",
(Arg *) NULL, (Cardinal) 0 );
XtGetValues ( Label1, arg, XtNumber ( arg ) );
px_disarm =
XCreatePixmapFromBitmapData(display,
DefaultRootWindow(display),
mtn_bits, mtn_width, mtn_height,
foreground,
background,
DefaultDepth(display,DefaultScreen(display)));
px_disarm_insens =
XCreatePixmapFromBitmapData(display,
DefaultRootWindow(display),
mtn_ins_bits, mtn_ins_width, mtn_ins_height,
foreground,
background,
DefaultDepth(display,DefaultScreen(display)));
n = 0;
XtSetArg(args[n], XmNlabelType, XmPIXMAP); n++;
XtSetArg(args[n], XmNlabelPixmap, px_disarm); n++;
XtSetArg(args[n], XmNlabelInsensitivePixmap, px_disarm_insens ); n++;
XtSetValues ( Label1, args, n );
XtManageChild(Label1);
That will cause the foreground and background of your pixmap to be inherited
from the one that would be used by OSF/Motif when the label is displayed. The
advantage is that this will utilize any resource values the user may have
requested without looking explicitly into the resource database. And, you
will have a pixmap handy if the application insensitizes the label (without an
XmNlabelInsensitivePixmap your label will go empty if made insensitive).
[Bob's original code was for a PushButton. Just change all Label to PushButton
for them.]
-----------------------------------------------------------------------------
Subject: 166) Why doesn't the XmLabel widget obey the XmNwith and XmNheight
that I give it?
[Last modified: May 95]
Answer: By default, XmLabel ignores these resources and instead computes a
size based on the size of the label string or pixmap. You can change this
behavior by setting XmNrecomputeSize to False. (Note that setting
XmNrecomputeSize to False can dramatically improve performance if you have
alot of labels or change them frequently.)
Ken Lee
-----------------------------------------------------------------------------
Subject: 167) How do you set the background color of a label widget using
XtVaTypedArg?
[Last modified: July 96]
Answer: Use the XmNbackground resource to control the background color, e.g.
strcpy(bgcolor, "yellow");
XtVaSetValues(widget,
XtVaTypedArg, XmNbackground, XtRString, bgcolor,
strlen(bgcolor)+1, NULL);
The length of the color string is plus one to include the null character.
XtRString is the type to be converted. The conversion is required because
XmNbackground expects a Pixel type.
Thanks to Martin Squicciarini (msquicci@resd.vf.ge.com).
-----------------------------------------------------------------------------
END OF PART FIVE
-----------------------------------------------------------------------------
Subject: 168) TOPIC: DRAWING AREA WIDGET
-----------------------------------------------------------------------------
Subject: 169) How can I send an expose event to a Drawing Area widget? (or
any other, come to that). I want to send an expose event so that it will
redraw itself.
[Last modified: Nov 97]
Answer: Use the Xlib call
XClearArea(XtDisplay(w), XtWindow(w), 0, 0, 0, 0, True)
This clears the widget's window and generates an expose event in doing so.
The widgets expose action will then redraw it. This uses a round trip
request. An alternative, without the round trip is
from orca!mesa!rthomson@uunet.uu.net (Rich Thomson):
Widget da;
XmDrawingAreaCallbackStruct da_struct;
da_struct.reason = XmCR_EXPOSE;
da_struct.event = (XEvent *) NULL;
da_struct.window = XtWindow(da);
XtCallCallbacks(da, XmNexposeCallback, (XtPointer) &da_struct);
Thanks to rand@ling.umu.se (Ola Andersson) for a correction to the above.
-----------------------------------------------------------------------------
Subject: 170) 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: 171) How can I create a drawing area widget with a visual type
different from its parent?
[Last modified: Sep 97]
Answer: The standard Motif drawing area does not support this. You can,
however, easily create a subclass with a new Realize class method. You may
want to create visual type, colormap, and depth resources so you can set these
values at initialization time.
In SGI's Motif, such a widget is called SgVisualDrawingArea. Other Motif
implementations may have similar widgets.
Ken Lee, http://www.rahul.net/kenton/
-----------------------------------------------------------------------------
Subject: 172) How can I display postscript in a Motif widget, such as
XmDrawingArea?
[Last modified: Sept 95]
Answer: Richard M. Goldstein (rickg@Eng.Sun.COM) writes: If your system
supports the Display PostScript extension (or NX agent), the newer revs of the
dpstkXm library contains a type of drawing area widget designed specifically
for use with DPS. Source for the latest DPS client-side is also ftp'able from
contrib.
Ramiro Estrugo (restrugo@fateware.com) writes: Have a look at ghostscript.
[With] a little editting, you can extract the Ghostview widget and use it in
your application...
-----------------------------------------------------------------------------
Subject: 173) TOPIC: MAIN WINDOW WIDGET
-----------------------------------------------------------------------------
Subject: 174) How can I create a message window in an XmMainWindow?
[Last modified: Nov 95]
Answer: XmMainWindow supports a message window, but you cannot specify it via
XmMainWindowSetAreas(). Instead, create the widget as a child of the
XmMainWindow, then specify to the XmMainWindow with XtSetValues() of
XmNmessageWindow.
Ken Lee
-----------------------------------------------------------------------------
Subject: 175) TOPIC: SCROLLED WINDOW WIDGET
-----------------------------------------------------------------------------
Subject: 176) How do I tell if a scrolled window's scrollbars are visible?
Answer: Use XtGetValues() to get the scrollbar widget ID's, then use
XtIsManaged() to see if they are managed (visible).
Ken Lee
-----------------------------------------------------------------------------
Subject: 177) How can I programatically scroll a XmScrolledWindow in
XmAUTOMATIC mode?
Answer: In Motif 1.2, use XmScrollVisible(). If you're using a scrolled text
or scrolled list combination widget, use XmTextScroll() or XmListSet*()
instead.
The Motif manuals specifically forbid manipulating the scrollbars directly,
but some people have reported success with XmScrollBarSetValues, with the
"notify" parameter set to "True".
Ken Lee
-----------------------------------------------------------------------------
Subject: 178) What widget does the XmScrolledWindow use for its clip window?
[Last modified: Apr 98]
Answer: In Motif 1.2, if the XmScrolledWindow is using the XmAUTOMATIC
scrolling policy, it automatically creates an XmDrawingArea widget as its clip
window. If you wish, you can retrieve the XmDrawingArea's widget ID by using
XtGetValues on the XmNclipWindow resource and then set resources on that
widget. Some useful resources are XmNbackground and XmNresizeCallback.
Note that Motif 2.X uses a new XmClipWindow widget instead of the
XmDrawingArea. Since XmClipWindow is subclassed from XmDrawingArea, the above
resources should still work.
Ken Lee
-----------------------------------------------------------------------------
Subject: 179) How do I create a scrolled window with only one scrollbar?
[Last modified: July 95]
Answer: If you're using the default application-defined scrolling mode, you
can just create one and specify NULL for the other. If, however, you're using
automatic scrolling, retrieve the ID of the unwanted scrollbar with
XmNhorizontalScrollBar or XmNverticalScrollBar and unmanage that widget:
Widget hScroll;
XtVaGetValues(scrollbar, XmNhorizontalScrollBar, &hScroll, NULL);
XtUnmanageChild(hScroll);
Thanks to Ken Lee, http://www.rahul.net/kenton/. Typo corrected by Paul
Tomblin, ptomblin@canoe.com.
-----------------------------------------------------------------------------
Subject: 180) TOPIC: MENUS
-----------------------------------------------------------------------------
Subject: 181) How can I change the cursor used in Motif menus?
[Last modified: Oct 95]
Answer: Set XmNmenuCursor on XmScreen (Motif 1.2) or XmRowColumn (Motif 1.1).
This should be set globally at start-up time, e.g., usually via an app-
defaults file.
Ken Lee
-----------------------------------------------------------------------------
Subject: 182) How do I put my help menu on the far right of my menubar?
[Last modified: Oct 95]
Answer: Set the XmNmenuHelpWidget resource of the menu bar to the help menu's
cascade button.
Ken Lee
-----------------------------------------------------------------------------
Subject: 183) Can I change or disable the menu bar accelerator from the
default (F10)?
[Last modified: May 97]
Answer: Changing it will confuse some of your users. If you must, this
accelerator is controlled by these resources on the menu bar's XmRowColumn:
XmNpopupEnabled (enables accelerators) and XmNmenuAccelerator (specifies the
accelerator key).
Ken Lee
-----------------------------------------------------------------------------
Subject: 184) How do I set the current choice in a radio box or an option
menu?
[Last modified: May 95]
Answer: Set the XmNmenuHistory resource on its XmRowColumn parent.
Ken Lee
buser@tartan.com (Mark) sent this code fragment:
Widget menu;
int num_buttons;
WidgetList buttons;
XtVaGetValues( simple_option_widget, XmNsubMenuId, &menu, NULL);
XtVaGetValues( menu, XmNnumChildren, &num_buttons,
XmNchildren, &buttons, NULL ) ;
and change current selection with:
XtVaSetValues( simple_option_widget, XmNmenuHistory, buttons[index], NULL ) ;
/* where index is between 0 and num_buttons */
Thanks to Phil Gehlich <pgehlich@hp7001.ecae.StorTek.COM> for a correction.
-----------------------------------------------------------------------------
Subject: 185) How can I determine the item selected in a a radio box or
option menu?
Answer: The value of the XmNmenuHistory resource of the XmRowColumn parent is
the widget ID of the last selected item. It works the same way for all menus
and radio boxes.
Ken Lee
-----------------------------------------------------------------------------
Subject: 186) How can I change the cascade indicator on an option menu?
[Last modified: Dec 97]
Answer: Set XmNcascadePixmap on the option menu's cascade button gadget.
Ken Lee
-----------------------------------------------------------------------------
Subject: 187) How do I unset an XmToggleButton in a radio box? If a radio-
mode toggle button is set and I XtSetValues XmNset a different toggle button,
the first radio button is not automatically unset. How do can I automatically
unset the first button?
[Last modified: Jun 98]
Answer: There are two easy ways to do this. First, you can set the toggle
with XmNmenuHistory on the radio box instead of XmNset on the toggle button.
Second, you can use XmToggleButtonSetState() with True for the notify
argument.
Note that some people have reported that XmNmenuHistory correctly sets the
toggle state but the toggle is not always redrawn to show the new state. This
is a bug in their implementation of Motif. If you cannot get a patch, you
should use the XmToggleButtonSetState() method.
Ken Lee
-----------------------------------------------------------------------------
Subject: 188) Can I place a radio box in a pulldown menu?
[Last modified: May 97]
Answer: You cannot place a XmRowColumn widget child in a menu pane. Since the
menu pane itself is a XmRowColumn widget, however, you can enable
XmNradioBehavior on it. This only works if all of the menu items are radio
buttons.
An alternative is to manage your radio behavior via your button callback
functions. This is more work, but much more flexible.
Ken Lee
-----------------------------------------------------------------------------
Subject: 189) How do I make a menu choice insensitive if it was created with
XmVaCreateSimplePulldownMenu?
[Last modified: Sept 94]
Answer: According to the Motif manual, the buttons are named "button_n", where
"n" is an integer starting from 0. You can use XtNameToWidget() to convert
these names to widget ID's.
Ken Lee
-----------------------------------------------------------------------------
Subject: 190) What widgets can I put inside a menubar?
[Last modified: Oct 95]
Answer: You can only put cascade buttons (widgets or gadgets) in the top level
of menubars. However, the children of these cascade buttons can be pushbuttons
with labels, pushbuttons with pixmaps, toggle buttons, separators, other
cascade buttons.
-----------------------------------------------------------------------------
Subject: 191) 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: 192) 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: 193) 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 %d\n", event->button);
if (event->button != Button3)
return;
XmMenuPosition(popup, event);
XtManageChild(popup);
}
-----------------------------------------------------------------------------
Subject: 194) How do popup menus work?
[Last modified: Feb 98]
Answer:
When a popup menu is created as the child of a widget the menu system installs
a translation on the parent of the popup and descendants with an action which:
(1) when 3-rd button (the default for the menuPost resource) is pressed the
cursor changes and the mouse is grabbed for 3 seconds; (2) disables event
handlers on the descendants and the handlers are never called; (3) an event
handler installed on the parent works fine.
It is done so that the correct event handler will (in fact) be called. There
is a grab with owner_events true. The grab is released by a timer, but
normally the posted menu shell puts up it's own grab.
If you only have widgets then you can use the subwindow field in the event to
identify the original widget. If you have gadgets or other data that you want
to change the menu for (or use a specific menu for) then you must do a walk of
the parent's children to find the best match.
One thing to beware of is that even with the grab, because the menu system
does a grab with owner events true, you must either have an event handler, or
nothing that will use the event on each widget in the hierarchy of the menu's
parent. If a child widget has another event handler for button down, it may
swallow the event and do something else.
-----------------------------------------------------------------------------
Subject: 195) How can I disable the button 3 grab if I am not using popup
menus?
[Last modified: Nov 98]
Answer: The menu system initiates the 3 second grab if XmNpopupEnabled is true
(the default), whether or not you will actually be popping up a menu. You can
avoid this grab by setting XmNpopupEnabled to False for widgets that do no
have popup menus.
-----------------------------------------------------------------------------
Subject: 196) 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: 197) 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: 198) Can I have multiple popup menus on the same widget?
[Last modified: July 96]
Answer: Ken Lee wrote that with Motif 1.2.*, you can have multiple popup menus
on a single widget as long as you set the menu's XmNmenuPost correctly.
The older answer for Motif 1.1.* was: If you want to have several popups
(activated by different mouse buttons) on the same widget..., well, that
doesn't work yet.
If you want to have several popups on different children... that works. But
don't put a popup on the parent (manager) widget, or it will rule!
-----------------------------------------------------------------------------
Subject: 199) How can I change the shell title of a tear-off menu?
[Last modified: Dec 97]
Answer: There is menu title resource to set this in Motif 2.0. In Motif 1.*,
explicitly set XmNtitle and XmNtitleEncoding on the menu shell, possibly in
your XmNtearOffMenuActivateCallback.
Note: The shell that is about to be mapped is the parent of the widget passed
to the XmNtearOffMenuActivateCallback.
Thanks to Ken Lee (http://www.rahul.net/kenton/), Fernando D. Mato Mira
(matomira@lig.di.epfl.ch), and Michael O'Keefe
(Michael.OKeefe@LMC.Ericsson.SE)
-----------------------------------------------------------------------------
Subject: 200) Can I programmatically tear-off a menu?
[Last modified: Dec 97]
Answer: As far as I know, there is no supported (or easy and unsupported) way
to do this.
Ken Lee
-----------------------------------------------------------------------------
Subject: 201) What widgets are valid within Motif menus?
[Last modified: July 96]
Answer: In Motif 1.*, menus may contain labels, push buttons, cascade buttons,
toggle buttons, and separators (widgets or gadgets). RowColumn will complain
if you use anything else within a menu. Note that drawn buttons and arrow
buttons are not allowed.
Ken Lee
-----------------------------------------------------------------------------
Subject: 202) Can I create multi-column popup or pulldown menus?
[Last modified: Nov 96]
Answer: Yes. Menu panes are just XmRowColumn widgets. Set XmNpacking to
XmPACK_COLUMN and XmNnumColumns to the number of columns you want.
Ken Lee
-----------------------------------------------------------------------------
Subject: 203) How can I keep my program from hanging if a user activates a
popup that is a child of an insensitive push button?
[Last modified: Nov 96]
Answer: There are two workarounds for this problem. You need only use one.
1. Set XmNancestorSensitive to False on the XmMenuShell when its parent is
insensitive.
2. Set XmNpopupEnabled on the menu pane (XmRowColumn widget) to False when
the menu is insensitive.
Reset the resource to True if you make your button sensitive again.
Ken Lee
-----------------------------------------------------------------------------
Subject: 204) TOPIC: DRAG AND DROP
-----------------------------------------------------------------------------
Subject: 205) Where can I find info and examples of the Motif drag and drop
protocol?
[Last modified: Jul 97]
Answer: A technical specification is available over the Internet:
OSF/Motif Drag and Drop Protocol
ftp://ftp.red-bean.com/pub/teak/
Thanks to Elliot Lee, sopwith@redhat.com
OSF's "Motif Programmers Guide" includes complete source code for several drag
and drop demos. Chapter 15 has simple examples demonstrating the basic
behaviour. Appendix B has a more complex example. (The source code for some
of the demos also appears on the OSF tape.)
Ken Lee
-----------------------------------------------------------------------------
Subject: 206) How can I disable Drag and Drop in my Motif 1.2 client ?
[Last modified: Oct 94]
Answer: Several people have reported that for complex hierarchies of widgets,
drag and drop can slow down an application considerably. If you do not need
drag and drop's significant power, you can disable it in your application.
Set the XmDisplay drag-protocol resources to XmDRAG_NONE. The following code
fragment demonstrates this:
#include <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)
Ken Lee and Christoph Widmer (widmer@einsteinium.SLCS.SLB.COM) describe how to
disable drag and drop from a resource file:
*dragInitiatorProtocolStyle: XmDRAG_NONE
*dragReceiverProtocolStyle: XmDRAG_NONE
Ken Lee also notes that as of Motif 1.2, the "Xm" prefix is required for all
token constants in resource files. (Which is why specifying "DRAG_NONE" won't
work but "XmDRAG_NONE" will.)
-----------------------------------------------------------------------------
Subject: 207) Can I register client data for the Motif XmDropSite drop
callback?
[Last modified: Mar 96]
Answer: Apparently not. You can, however, put your data in the drop site
widget's XmNuserData. Or, you can use the Xlib context manager.
Ken Lee
-----------------------------------------------------------------------------
Subject: 208) Can unmanged widgets be valid (drag-and-drop) drop sites?
[Last modified: Nov 96]
Answer: Yes, the drop site stacking order is independent of the window
stacking order. You can modify the active drop site order with
XmDropSiteConfigureStackingOrder() or by using XmDropSiteUpdate() to change
the drop site's XmNdropSiteActivity resource (to XmDROP_SITE_ACTIVE or
XmDROP_SITE_INACTIVE).
Ken Lee
-----------------------------------------------------------------------------
Subject: 209) TOPIC: INPUT FOCUS
-----------------------------------------------------------------------------
Subject: 210) How can I specify the widget that should have the keyboard
focus when my application starts up?
[Last modified: June 95]
Answer: In Motif 1.2 or later, use XmNinitialFocus on the manager widget.
Ken Lee
-----------------------------------------------------------------------------
Subject: 211) How can I specify my own keyboard traversal order?
[Last modified: May 97]
Answer: In Motif 1.2 or later, set the XmNnavigationType resource for the
widgets in your tab group. When any widget in a hierarchy has an
XmNnavigationType of XmEXCLUSIVE_TAB_GROUP, traversal of tab groups in the
hierarchy proceeds to widgets in the order in which their XmNnavigationType
resources were specified as XmEXCLUSIVE_TAB_GROUP or XmSTICKY_TAB_GROUP.
Earlier releases have a XmAddTabGroup(), but that is obsolete and has been
replaced by XmNnavigationType.
Ken Lee
-----------------------------------------------------------------------------
Subject: 212) How can I determine which widget has keyboard focus?
[Last modified: Sept 95]
Answer: In Motif 1.2 or later, use XmGetFocusWidget().
Ken Lee
--------------------------------------------------------------------------
Subject: 213) 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: 214) How can I have a modal dialog which has to be answered before
the application can continue?
[Last modified: Sep 97]
Answer: Warning: the following answer relies on nested event loops. Use these
with caution, as nested loops can affect the ordering of events and widget
destruction, leading to several undesirable side effects.
Ken Lee
Note: J.-N. Meurisse (uunet!rc4.vub.ac.be!jnmeuris) sent a correction to the
following code fragment. Change:
XtAddCallback(dialog, XmNpopdownCallback, ...)
to
XtAddCallback(XtParent(dialog), XmNpopdownCallback, ...)
The answer depends on whether you are using the Motif window manager mwm or
not. Test for this by XmIsMotifWMRunning.
The window manager mwm knows how to control event passing to dialog widgets
declared as modal. If the dialog is set to application modal, then no
interaction with the rest of the application can occur until the dialog is
destroyed or unmanaged.
Use the appropriate code in the following program. There is followup
discussion after the program.
/* Written by Dan Heller. Copyright 1991, O'Reilly && Associates.
* This program is freely distributable without licensing fees and
* is provided without guarantee or warranty expressed or implied.
* This program is -not- in the public domain. This program is
* taken from the Motif Programming Manual, O'Reilly Volume 6.
*/
/*
* ask_user.c -- create a pushbutton that posts a dialog box
* that asks the user a question that requires an immediate
* response. The function that asks the question actually
* posts the dialog that displays the question, waits for and
* returns the result.
*/
#include <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 = XmStringCreateLocalized("/bin/rm *");
button = XtVaCreateManagedWidget("button",
xmPushButtonWidgetClass, toplevel,
XmNlabelString, label,
NULL);
XtAddCallback(button, XmNactivateCallback,
pushed, "Remove Everything?");
XmStringFree(label);
XtRealizeWidget(toplevel);
XtAppMainLoop(app);
}
/* pushed() --the callback routine for the main app's pushbutton. */
void
pushed(w, question)
Widget w;
char *question;
{
if (AskUser(w, question) == YES)
puts("Yes");
else
puts("No");
}
/*
* AskUser() -- a generalized routine that asks the user a question
* and returns the response.
*/
AskUser(parent, question)
char *question;
{
static Widget dialog;
XmString text, yes, no;
static int answer;
extern void response();
answer = 0;
if (!dialog) {
dialog = XmCreateQuestionDialog(parent, "dialog", NULL, 0);
yes = XmStringCreateLocalized("Yes");
no = XmStringCreateLocalized("No");
XtVaSetValues(dialog,
XmNdialogStyle, XmDIALOG_APPLICATION_MODAL,
XmNokLabelString, yes,
XmNcancelLabelString, no,
NULL);
XtSetSensitive(
XmMessageBoxGetChild(dialog, XmDIALOG_HELP_BUTTON), False);
XtAddCallback(dialog, XmNokCallback, response, &answer);
XtAddCallback(dialog, XmNcancelCallback, response, &answer);
/* if the user interacts via the system menu: */
/* SEE CORRECTION ABOVE */
XtAddCallback(dialog, XmNpopdownCallback, response, &answer);
}
text = XmStringCreateLocalized(question);
XtVaSetValues(dialog,
XmNmessageString, text,
NULL);
XmStringFree(text);
XtManageChild(dialog);
XtPopup(XtParent(dialog), XtGrabNone);
/* while the user hasn't provided an answer, simulate XtMainLoop.
* The answer changes as soon as the user selects one of the
* buttons and the callback routine changes its value. Don't
* break loop until XtPending() also returns False to assure
* widget destruction.
*/
while (answer == 0 || XtAppPending(app))
XtAppProcessEvent(app, XtIMAll);
return answer;
}
/* response() --The user made some sort of response to the
* question posed in AskUser(). Set the answer (client_data)
* accordingly and destroy the dialog.
*/
void
response(w, answer, reason)
Widget w;
int *answer;
XmAnyCallbackStruct *reason;
{
switch (reason->reason) {
case XmCR_OK:
*answer = YES;
break;
case XmCR_CANCEL:
*answer = NO;
break;
default:
*answer = NO;
return;
}
}
If you aren't running a window manager that acknowledges this hint, then you
may have to grab the pointer (and keyboard) yourself to make sure the user
doesn't interact with any other widget. Change the grab flag in XtPopup to
XtGrabExclusive, and XtRemoveGrab(XtParent(w)) to the response() function.
-----------------------------------------------------------------------------
Subject: 215) TOPIC: MEMORY AND SPEED
-----------------------------------------------------------------------------
Subject: 216) When can I free data structures passed to or retrieved from
Motif?
Answer: In most cases, especially for XmStrings and XmFontLists, Motif copies
data passed to it or retrieved from it, so it may be freed immediately.
Server-side resources, such as pixmaps and color cells, however, are not
copied, so should not be freed. More recent versions of Motif are better than
earlier versions and exceptions should be documented.
Ken Lee
-----------------------------------------------------------------------------
Subject: 217) What memory leaks are known? Why does my application grow in
size?
[Last modified: Jun 98]
Answer: Detailed information about Motif-related memory leaks (and how you can
avoid them) can be found in two great articles by Kenton Lee:
http://www.rahul.net/kenton/txa/feb96.html
http://www.rahul.net/kenton/txa/mar96.html
Answer: Motif 1.0 has many memory leaks, particularly in XmString
manipulation. Switch to Motif 1.1. 1.2, or 2.0.
Answer: In Motif 1.2.x, if one is using XmStringGetNextSegment very often
(several 100 times) you'll get very big memory leaks, because one has to
XtFree() also the charset variable and not only the variable holding the text
value. Thanks to Ingo Schulz (ing@bb-data.de).
Answer: The Intrinsics have a memory leak in accelerator table management, and
Motif uses this heavily. Avoid this by mapping/unmapping widgets rather than
creating/destroying them, or get X11R4 fix-15/16/17.
Answer: The server may grow in size due to its own memory leaks. Switch to a
later server.
Answer: You are responsible for garbage collection in `C'. Some common cases
where a piece of memory becomes garbage are
a. Memory is allocated by Motif for XmStrings by the functions
XmStringConcat, XmStringCopy, XmStringCreate, XmStringCreateLtoR,
XmStringCreateLocalized, XmStringDirectionCreate, XmStringNConcat,
XmStringNCopy, XmStringSegmentCreate, and XmStringSeparatorCreate. The
values returned by these functions should be freed using XmStringFree
when they are no longer needed.
b. Memory is allocated by Motif for ordinary character strings (of type
String) by Motif in XmStringGetLtoR, XmStringGetNextComponent, and
XmStringGetNextSegment. After using the string, XtFree() it. [Note that
XmStrings and Strings are two different data types. XmStrings are
XmStringFree'd, Strings are XtFree'd.]
c. If you have set the label (an XmString) in a label, pushbutton, etc
widget, free it after calling XtSetValues() or the widget creation
routine by XmStringFree().
d. If you have set text in a text widget, the text widget makes its own
copy. Unless you have a use for it, there is no need to keep your own
copy.
e. If you have set the strings in a list widget the list widget makes its
own copy. Unless you have a use for it, there is no need to keep your
own copy.
f. When you get the value of a single compound string from a Widget e.g.
XmNlabelString, XmNmessageString, ... Motif gives you a copy of its
internal value. You should XmStringFree this when you have finished with
it.
g. On the other hand, when you get a value of a Table e.g. XmStringTable for
a List, you get a *pointer* to the internal Table, and should not free
it.
h. When you get the value of the text in a widget by XmTextGetString or from
the resource XmNvalue, you get a copy of the text. You should XtFree
this when you have finished with it.
Answer: Josef Nelissen wrote: at least in Motif 1.1.4, X11R4 on a HP 720, the
XmText/XmTextFieldSetString() functions have a memory leak. The old
value/contents of the Widget isn't freed correctly. To work around this bug,
one should use a XmText Widget (in single-line-mode) instead of a XmTextField
Widget (the solution fails with XmTextField Widgets !) and replace any
XmTextSetString(text_widget, str);
by
XmTextReplace(text_widget, (XmTextPosition) 0,
XmTextGetLastPosition(text_widget), str);
-----------------------------------------------------------------------------
Subject: 218) Why do I get so many uninitilized memory read (UMR) errors when
I run Purify[tm] on my Motif programs?
[Last modified: July 96]
Answer: Purify's reports are suggestions and do not always indicate real bugs.
The X libraries frequently allocate dynamic memory, e.g., for attribute or
event structures, but don't explicitly initialize all of the memory. X keeps
track of which structure fields are valid via a union type or a mask. When X
tries to copy or write the memory (part of which is uninitialized) as one
block, Purify reports a UMR. This is not a bug and you can safely supress or
ignore the report. Yes, X could initialize the unused field, but since this
happens alot, the needless operation could negatively affect your performance.
Ken Lee
-----------------------------------------------------------------------------
Subject: 219) 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: 220) My application is running too slowly. How can I speed it up?
Answer: Use the R4 rather than R3 server. It is much faster.
Answer: The standard memory allocator is not well tuned to Motif, and can
degrade performance. Use a better allocator. e.g. with SCO Unix, link with
libmalloc.a; use the allocator from GNU emacs; use the allocator from Perl.
Answer: Avoid lots of widget creation and destruction. It fragments memory
and slows everything down. Popup/popdown, manage/unmanage instead.
Answer: Set mappedWhenManaged to FALSE, and then call XtMapWidget()
XtUnmapWidget() rather than managing.
Answer: Get more memory - your application, the server and the Operating
System may be spending a lot of time being swapped.
Answer: If you are doing much XmString work yourself, such as heavy use of
XmStringCompare, speed may deteriorate due to the large amount of internal
conversions and malloc'ing. Try using XmStringByteCompare if appropriate or
ordinary Ascii strings if you can.
Answer: There are some more hints at http://www.rahul.net/kenton/perf.html
-----------------------------------------------------------------------------
Subject: 221) Why is my application so huge?
Answer: The typical size of a statically linked Motif app is in the megabytes.
This is often caused by the size of libXm.a. A large part of this gets linked
in to even trivial Motif programs. You can reduce the code size by linking
against shared libraries if they are available. Running "strip" on the
executable can often reduce size. Note that the size of the running program
should be measured by "ps", not by the code size.
-----------------------------------------------------------------------------
Subject: 222) How can I improve performance when creating and deleting
hundreds of text widgets?
[Last modified: June 95]
Answer: This is mostly a problem with Motif 1.2.0 through 1.2.2. Later
versions are much better. If you're stuck with an early version of Motif 1.2,
you may be able to greatly improve performance by batching the drop site
updates: surround the create or delete code with XmDropSiteStartUpdate and
XmDropSiteEndUpdate. Alternatively, you can completely disable drag-and-drop
for your application. See the subject: "How can I disable Drag and Drop in my
Motif 1.2 client?"
Ken Lee
-----------------------------------------------------------------------------
Subject: 223) After I call XtSetValues, when will I see the changes in my
GUI?
[Last modified: Nov 97]
Answer: For each change you make, the widget decides if it needs to redraw.
If so, Xt calls XtClearArea to generate an expose event. You main loop
dispatches the resulting expose event to your widget, causing a redisplay.
Note that the redisplay may be delayed somewhat if you do not immediately
return to the event loop after calling XtSetValues. You can often work around
this by calling XmUpdateDisplay().
Note also that you should try to make all your changes in one large
XtSetValues changing several values at once. If you call XtSetValues
individually for each change you need to make, you could generate several
expose events and redraw several times.
-----------------------------------------------------------------------------
Subject: 224) TOPIC: XMSTRING
-----------------------------------------------------------------------------
Subject: 225) What string functions differ in Motif 1.1 and 1.2? Is
XmStringCreateSimple obsolete? What should I use instead?
[Last modified: Feb 95]
Answer: XmStringCreateSimple is obsolete. Use XmStringCreateLocalized instead.
Matthew B. Evans (Evans@EDFUA6.ctis.af.mil) writes:
We just upgraded from Motif 1.1 to 1.2. When we went to compile, no problem,
but our XmStringCreateSimple() and XmStringGetLtoR() seemed to have problems.
As we found out, Motif 1.2 STRONGLY recommends to use the constant
XmFONTLIST_DEFAULT_TAG instead of XmSTRING_DEFAULT_CHARSET in all of the
XmStringXXX() functions, as XmSTRING_DEFAULT_CHARSET is maintained only for
compatibility (not a whole lot in my opinion). I got this information from
Book 6B from O'Reilly.
You may want to take a look at this book if you can. Some XmString functions
are outdated and maintained only for compatibility, whereas some don't
function correctly when using XmSTRING_DEFAULT_CHARSET (from our in-depth
tests).
We have changed all our XmStringCreateSimple() to XmStringCreateLocalized()
(as suggested in book 6B) and changed all XmSTRING_DEFAULT_CHARSET to
XmFONTLIST_DEFAULT_TAG.
[Thanks to John West (jwest@nas.nasa.gov) for fixing a typo in the above.]
NOTE: All string answers in this FAQ now use XmStringCreateLocalized rather
than XmStringCreateSimple. The documentaton makes it clear that
XmStringCreateSimple is obsolete and is only kept for compatibility with Motif
1.1. New applications should not use this function since XmStringCreateSimple
may disappear in a subsequent Motif release. (Thanks to Miguel Angel Chamochin
(mangel@tid.es) for reminding me to fix this mess.)....ksall@cen.com.
-----------------------------------------------------------------------------
Subject: 226) 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: 227) 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: 228) 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: 229) Why does using XmStringDraw cause a BadFont error?
[Last modified: Mar 96]
Answer: Thomas Berlage (berlage@gmdzi.gmd.de) wrote: You could call this a bug
in Motif. You pass a GC to XmStringDraw, however, Motif wants to use the fonts
from the font list to draw the string. Therefore it replaces the font of the
GC temporarily with some fonts of its own as specified in the font list. In
the end it tries to restore the old font of the GC. There comes the problem:
If a GC uses the default font, the client side GC structure does not have a
valid font id (that is the 0xffffffff you may see in the error message). Motif
tries to restore this invalid id at the end.
The workaround is: Before drawing with XmStringDraw, set the font id of the GC
to any valid font id, for example using
XSetFont (display, gc, XLoadFont (display, "fixed"));
Another solution is available from "Harry's Motif Programming Corner", Harald
Albrecht, albrecht@igpm.rwth-aachen.de, who writes:
"It's somewhat longer but doesn't rely on a font named "fixed" installed on
your platform. Instead it takes a fontlist and then uses the first font listed
there. You'll find this source together with a short demo program (which
creates a DrawingArea and then paints some text in it) on: ftp.igpm.rwth-
aachen.de (134.130.161.30) in: /arc/pub/unix/motif/RenderXmString.tar.gz
There's also a html page available: Harry's Motif Programming Corner
http://www.igpm.rwth-aachen.de/~albrecht/motifcorner.html
Thanks to Harald Albrecht (albrecht@igpm.rwth-aachen.de). URL corrected by
irca (irca@zip.cra.enel.it).
-----------------------------------------------------------------------------
Subject: 230) How can I control color of individual strings to show status,
etc.?
[Last modified: June 95]
Answer: This is difficult to do with Motif 1.X. If you can, upgrade to Motif
2.0, which supports colored XmStrings.
Ken Lee
-----------------------------------------------------------------------------
Subject: 231) TOPIC: DIALOGS
-----------------------------------------------------------------------------
Subject: 232) 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: 233) 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: 234) Why do dialog title bars have "_popup" or "<-popup"
concatenated onto the widget name?
Answer: Motif 1.0.3 (?) "fixed" things such that title bars without an
explicit dialogTitle setting use the widget name with "_popup" or whatever
added on. Set the dialogTitle resource explicitly if you don't want this new
default naming scheme.
-----------------------------------------------------------------------------
Subject: 235) How can I force a dialog window to display?
I manage a "working" dialog, and do some computing, but the dialog window
appears blank until the work has finished. How can I force it to be
displayed?
[Last modified: Dec '94]
Answer: David Brooks <dbrooks@ics.com> writes: The dialog window won't get
expose events until the window manager has fielded the map request, done the
reparenting with all that entails, and finally convinced the server that the
window is for real. The safe way of doing it is [below].
Use this. (David Brooks, Systems Engineering, Open Software Foundation)
/*
* This procedure will ensure that, if a dialog window is being mapped,
* its contents become visible before returning. It is intended to be
* used just before a bout of computing that doesn't service the display.
* You should still call XmUpdateDisplay() at intervals during this
* computing if possible.
*
* The monitoring of window states is necessary because attempts to map
* the dialog are redirected to the window manager (if there is one) and
* this introduces a significant delay before the window is actually mapped
* and exposed. This code works under mwm, twm, uwm, and no-wm. It
* doesn't work (but doesn't hang) with olwm if the mainwindow is iconified.
*
* The argument to ForceDialog is any widget in the dialog (often it
* will be the BulletinBoard child of a DialogShell).
*/
ForceDialog(w)
Widget w;
{
Widget diashell, topshell;
Window diawindow, topwindow;
Display *dpy;
XWindowAttributes xwa;
XEvent event;
XtAppContext cxt;
/* Locate the shell we are interested in. In a particular instance, you
* may know these shells already.
*/
for (diashell = w;
!XtIsShell(diashell);
diashell = XtParent(diashell))
;
/* Locate its primary window's shell (which may be the same) */
for (topshell = diashell;
!XtIsTopLevelShell(topshell);
topshell = XtParent(topshell))
;
if (XtIsRealized(diashell) && XtIsRealized(topshell)) {
dpy = XtDisplay(topshell);
diawindow = XtWindow(diashell);
topwindow = XtWindow(topshell);
cxt = XtWidgetToApplicationContext(diashell);
/* Wait for the dialog to be mapped. It's guaranteed to become so unless... */
while (XGetWindowAttributes(dpy, diawindow, &xwa),
xwa.map_state != IsViewable) {
/* ...if the primary is (or becomes) unviewable or unmapped, it's
probably iconified, and nothing will happen. */
if (XGetWindowAttributes(dpy, topwindow, &xwa),
xwa.map_state != IsViewable)
break;
/* At this stage, we are guaranteed there will be an event of some kind.
Beware; we are presumably in a callback, so this can recurse. */
XtAppNextEvent(cxt, &event);
XtDispatchEvent(&event);
}
}
/* The next XSync() will get an expose event if the dialog was unmapped. */
XmUpdateDisplay(topshell);
}
-----------------------------------------------------------------------------
Subject: 236) How can I control placement of a popup widget? Each time a
popup is created, it is placed in or over the middle of its parent. How can I
make it obey the XmNx and XmNy values?
[Last modified: Feb 95]
Answer: Set the resource XmNdefaultPosition for the popup to False. Set the
position of the popup by the resource values of XmNx and XmNy. Do not use
XtMoveWidget, as this is for widget writers only. Here's a demo program from
Dan Heller:
/* Written by Dan Heller. Copyright 1991, O'Reilly && Associates.
* This program is freely distributable without licensing fees and
* is provided without guarantee or warranty expressed or implied.
* This program is -not- in the public domain. This program is
* taken from the Motif Programming Manual, O'Reilly Volume 6.
*/
/* map_dlg.c -- Use the XmNmapCallback to automatically position
* a dialog on the screen. Each time the dialog is displayed, it
* is mapped down and to the right by 200 pixels in each direction.
*/
#include <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 = XmStringCreateLocalized(message);
extern void response();
XtSetArg(arg[0], XmNautoUnmanage, False);
XtSetArg(arg[1], XmNmessageString, t);
XtSetArg(arg[2], XmNdefaultPosition, False);
dialog = XmCreateMessageDialog(w, "notice", arg, 3);
XmStringFree(t);
XtAddCallback(dialog, XmNmapCallback, map_dialog, NULL);
XtManageChild(dialog);
XtPopup(XtParent(dialog), XtGrabNone);
}
-----------------------------------------------------------------------------
Subject: 237) How can I set the dialog's default button?
[Last modified: June 95]
Answer: Use XmNdefaultButton on the bulletin board widget.
Ken Lee
-----------------------------------------------------------------------------
Subject: 238) How can I create a dialog that behaves like, but looks a little
different from, XmMessageBox?
[Last modified: June 95]
Answer: Motif 1.2 provides a XmCreateTemplateDialog(), which allows you to
specify any combination of child widgets.
Ken Lee
-----------------------------------------------------------------------------
Subject: 239) How can I use Motif's message dialog bitmaps in my own dialogs?
[Last modified: Nov 95]
Answer: The bitmaps are normally stored in /usr/include/X11/bitmaps (or the
equivalent bitmaps directory, which is vendor specific) and are cached if you
create a XmMessageBox. You can retrieve them by name with XmGetPixmap() or
XmGetPixmapByDepth(). The names of the bitmap files are in the XmMessageBox
man page.
Ken Lee
-----------------------------------------------------------------------------
END OF PART SIX
-----------------------------------------------------------------------------
Subject: 240) TOPIC: LANGUAGE BINDINGS
-----------------------------------------------------------------------------
Subject: 241) What is ViewKit? Is there a free version?
[Last modified: Jun 98]
Answer: ViewKit is an enhanced version of the C++/Motif framework that Doug
Young describes in his book *Object-Oriented Programming with C++ and
OSF/Motif* (Prentice-Hall).
Viewkit is now available for a variety of platforms from ICS. The Linux
version is free. Their web site include free technical papers and ordering
information:
http://www.viewkit.com/
There is also a inexpensive ViewKit clone from the Hungry Programmers:
http://www.hungry.com/cgi-bin/unjava/products/viewkit/
ftp://ftp.hungry.com/pub/hungry/viewkit
Allen Fogleson (foggie@dtx.net) writes: I have compiled [the Hungry
Programmers' version] on my linux system using RedHat Motif 2.0, There is no
documentation, but the technical paper on the SGI site should be enough to get
most people going. There is very little in the way of documentation either, so
I should note that if you are using Motif2.0 you must either #define
USE_MOTIF20 in a header file, or add it to the CXXFLAGS, and CFLAGS line of
the makefile or you will get many errors when compiling the combo box
bindings. Also for some reason the viewkit did not install correctly for me
and I ended up hand installing it myself. I have compiled some simple
applications with it, and it seems to be working fine. It is intended to
follow the SGI API. They are working on a programmers guide and a reference
manual for the product. All in All this is a very affordable (spelled cheap)
answer to C++ development of OSF/Motif Apps.
-----------------------------------------------------------------------------
Subject: 242) Is there a C++ binding for Motif?
[Last modified: Nov 98]
Answer: This answer is out-of-date and will probably be dropped in the near
future. I recommend that you study other sources, such as trade magazines,
for more current information on products.
See also the previous answer concerning ViewKit (from Doug Young and the
Hungry Programmers.
(Added Oct. 95) YACL is a freely available C++ class library that includes GUI
classes based on the Model-View-Controller paradigm. The class protocols are
designed in a platform independent manner, and are implemented under Motif 1.2
as well as under Microsoft Windows and OS/2. This makes it possible to
maintain a single code base for an application that runs on all three
platforms. YACL also includes a suite of container and data storage classes
for general-purpose programming. YACL is available from ftp.cs.sc.edu in
pub/yacl. For more information, see the web page:
http://www.cs.sc.edu/~sridhar/yacl.html.
Thanks to M. A. Sridhar, sridhar@usceast.cs.sc.edu.
(Added Sept. 95; URL updated Jan. 96) Amulet User Interface Toolkit from Brad
A. Myers, Rich McDaniel, Andrew Mickish, Alex Klimovitski, Carnegie Mellon
University. Amulet is a user interface software environment for C++ to
support future user interface software research. This environment, which will
be portable across X/11, Microsoft Windows, and the Macintosh, is designed to
be very flexible: parts can be replaced and new technologies and widgets can
be easily created and evaluated. Built-in support will be provided for direct
manipulation, multi-font text editing, gesture recognition, speech
recognition, 2-D and 3-D animations, visualizations including maps and large
data sets, world-wide-web browsing and editing, and multiple people
interacting with the system at the same time (CSCW). Another goal is to be
useful for students, which means that Amulet must be easy to learn. Finally,
the system will provide sufficient performance, robustness and documentation
so it will be useful for general user interface developers. See:
http://www.cs.cmu.edu/Web/Groups/amulet/amulet-home.html
Answer: ObjectBuilder by Openware Technologies, Inc. is a complete C++
implementation of Motif. Kris Gottschalk (kris@boulder.openware.com) wrote
[I've condensed his features list and a few others details...ksall@cen.com]:
Since Solbourne began developing OI around 1988, it was purchased by ParcPlace
Systems (at which time ObjectBuilder was developed) and as of Oct. '94,
ObjectBuilder/OI was purchased by Openware Technologies, Inc from ParcPlace.
OI is now on release 4.6 and has a customer base of about 3,000 seats.
[ObjectBuilder's features include: Visual Subclassing, Dynamic Reparenting,
Customizable Main Window, Xt Kit, Resource Editors, Flexible Geometry
Management, Customizable palattes and attribute editors, 16 Bit
Internationalization, Mnemonics and Accelerator Editor, Motif or OPEN LOOK
look-and-feel switch, Help Editor.]
ObjectBuilder is currently available on Sun/Solaris, HP 9000/700 and IBM AIX
RS6000. We will also be supporting SGI, DEC Alpha, Sco UNIX, Unysis Unixware
and NCR SVR4 throughout the first half of 1995. And our anxiously awaited
Windows NT platform will be available in late 1995. In addition, Openware
will be launching a full array of C++ development tools including an Object
Repository, Debugger, OI Table Widget and Adapter. Also anticipate an
ObjectBuilder upgrade 2.6/4.6 in April and a new ObjectBuilder release 3.0/5.0
in the summer.
If you have any more interests or questions or would like to set up a
evaluation of ObjectBuilder, please contact:
Kris Gottschalk
Account Manager
Openware Technologies, Inc.
Object Technologies Business Unit
4909 East Pearl Circle Suite 200
Boulder, CO 80301
Phone: 303-440-9991 x4224
Fax: 303-440-9934
email: kris@boulder.openware.com
Answer: Wind/U implements MFC (Microsoft Foundation Classes) on Unix using
Motif. Bristol Technology, Inc. (203) 438-6969, info@bristol.com. Microsoft
Visual C++ together with Wind/U can be used to create Motif applications.
According to J. Daniel Smith <dan@bristol.com>, here's how it works: you
create the application on the PC using MSVC++ and then port it to Unix (or
VMS) using Wind/U. Since Wind/U uses X and Motif to implement the Windows
API, you end up with a true Motif application running native on the target
platform.
Answer: WWL is a library which defines C++ classes around X Toolkit Widgets.
It is intended to simplify the task of C++ code writers when using the Toolkit
by providing them with C++ objects, methods, type checking and several utility
functions and classes.
WWL has been tested under SunOs4.0.3 on sun3 and sun4, HPUX version 6.5 and
7.0 and Ultrix 4.0 on DECstation 3100 and 5000. It is expected to work on most
other UNIX systems without too many problems.
WWL is distributed as a tar file with all the source, documentation and
example. The file is available using anonymous ftp from
ftp.x.org /R5contrib/WWW-1.2.tar.Z
( ftp://ftp.x.org/R5contrib/WWW-1.2.tar.Z )
Answer: Rogue Wave Software has a C++ binding for Motif called View.h++.
"View.h++ is a complete C++ interface to OSF/Motif. It doesn't just
encapsulate it, but also includes a set of classes that provide a level of
abstraction above Motif, thus simplifying menu and dialog creation, XmStrings,
XmFontLists, etc. View.h++ supports a Model- View-Controller architecture,
allowing for an even more object-oriented interface design. Includes a copy
of Rogue Wave's Tools.h++ (foundation class library)" Rogue Wave also offers
full support for View.h++.
It is currently available for Sun Sparc, IBM RS/6000, HP 9000/700 series, SCO,
Intel SVR4 ESIX. Please call for Silicon Graphics and DEC Ultrix status.
For additional information, please contact:
Matt Steinauer
Rogue Wave Software, Inc.
P.O. Box 2328
Corvallis, OR 97339
Phone: (503)754-3010
Fax: (503)757-6650
email: matts@roguewave.com
Answer: Builder Xcessory 3.0, an interface builder from ICS, allows the user
to visually build C++ classes from Motif and user-written widgets. C++ code
is generated in the "Doug Young" fashion. (Doug actually worked on this
project with ICS.) C and UIL can also be generated.
Integrated Computer Solutions, Inc. (ICS) 201 Broadway, Cambridge, MA 02139
USA info@ics.com 617/621-0060
Answer: Andreas.Baecker@gmd.de wrote: The GINA++ application framework
contains an encapsulation of the OSF/Motif widg et classes and the Xt
functionality into C++ classes. Its functionality is comparab le to that of
the ULowell binding and the WWL. Additionally, it provides an easy-to -use
framework for modeling new composite and primitive widget classes, plus an
application framework similar to ET++ or MacApp build on top of it. The
binding may be used independently from the framework classes. GINA++ is
available through anonymous ftp from ftp.gmd.de in the directory
/gmd/ginaplus. Documentation about the Motif binding has been published in
the X Resource Journal, Number 2, 1992, Pages 106-130. The binding compiles
with AT&T C++ 2.1 and GNU G+ + 2.1 and has been tested on SunOS 4.1.[12],
X11R4 and Motif 1.1.3.
Answer: Motif++ is a library that defines C++ class "wrappers" for the widgets
defined in the X11R5 OSF/Motif-1.2 widget library. It also supports
X11R4/Motif-1.1 as well.
Motif++ is also an application toolkit that provides other tools in
conjunction with the widget wrapper classes. It has support for the Xbae
widget set, plus other widgets. It has Imake support, and lots of test files.
Motif++ also has alot of contributed software.
Motif++ is very similar to other public domain widget libraries such as The
Widget Wrapper Library (WWL) and the C++ Binding for OSF/Motif developed at
the University of Lowell. The two latter libraries are the result of much
larger efforts.
Available via anonymous ftp:
ftp://src.doc.ic.ac.uk/packages/motif++/motif++.30.jul.94.tar.gz
The /packages/motif++ also contains documentation. For more information,
contact Ronald van Loon (rvloon@motif.xs4all.nl). There is also mailing list
for Motif++:
motif++@motif.xs4all.nl
To join, send email to the administrative address:
motif++-request@motif.xs4all.nl
Answer: C++ Report, a magazine published by SIGS Publications, now regularly
publishes articles on X, Xt and Motif vs. C++ written by Ronald van Loon.
Answer: Xm++ is a user interface framework for the C++ language built upon X11
and the X-Toolkit. It is designed to be a simple and intuitive programming
interface to access the functionality of commonly used widgets. Xm++ was
initially created for the Motif widget set, now support for the Athena widgets
was added. Applications created with Xm++ run in both environments without
changes, although many nice features are only available when using Motif.
Xm++ is available on: ftp.x.org as: /R5contrib/Xm++.0.53.tar.Z (
ftp://ftp.x.org/R5contrib/Xm++.0.53.tar.Z ).
Answer: (updated November. 98) wxWindows is a toolkit for platform-independent
GUI programming in C++. It consists of several class libraries and tools.
wxWindows has been made freely available with no commercial restrictions. For
more information, see http://wxwin.home.ml.org
Answer: (updated Sept. 95) Intersolv now markets, maintains, and enhances
C++/Views (formerly from Liant). The C++/Views solution provides an
extensible object class library with visual development environment. See
http://www.intersolv.com/cpls.html. Thanks to Uwe Baemayr (uwe@liant.com) for
the correction.
Answer: Quest has ObjectViews.
Answer: Doug Young has written a book "Object Oriented Programming with C++
and Motif", Prentice-Hall ISBN 0-13-630252-1 about using C++ without requiring
one of these toolkits.
Unfortunately, this library (last released in 9/92) has the same name as the
one by Ronald van Loon (rvloon@motif.hacktic.nl). Motif++1.2 is a library
that defines C++ class "wrappers" for the widgets defined in the OSF/Motif-1.1
widget library. Motif++1.2 is also an application toolkit that provides other
tools in conjunction with the widget wrapper classes. One enhancement of
Motif++1.2 beyond its wrapper classes are the addition of an "application"
class which takes care of the low-level tasks including initializing X,
creating and managing one or more top-level shells, and entering the main
event loop. Another feature of Motif++1.2 is its integration with The Widget
Creation Library (Wcl). Motif++1.2 makes it easy to initialize Wcl and create
C++ wrappers for desired widgets in the widget tree. Availability: anonymous
FTP at ftp.arc.umn.edu (137.66.130.11), file pub/Motif++1.2.tar.Z. Contact
Paul Felix, felix@ahpcrc.umn.edu or pfelix@vx.cis.umn.edu.
submitted by: mvc!biggers@duke.cs.duke.edu ( Mark R. Biggers )
-----------------------------------------------------------------------------
Subject: 243) How can I avoid C++ String class and typedef char *String
conflicts? We're using the USL C++ Standard Components which has the String
class. This, however, conflicts with the typedef char *String found in
<X11/Intrinsic.h>
[Last modified: Oct 94]
Answer: This is very simple to workaround. I agree that it is "wrong" but all
you need to do is:
#define String XtStringType
#include "all the X files"
#undef String
This will translate the offending symbol.
Thanks to Doug Rand <drand@sgi.com>
-----------------------------------------------------------------------------
Subject: 244) How can I have a C++ member function in a callback?
[Last modified: Oct 94]
Answer: There are three common user problems with C++ callbacks. First, make
sure you use the correct function prototype for the function declarations.
Second, the callback function must be declared as a static member of the
class. Third, when registering it with XtAddCallback(), you must use its full
signature. For example: (from Ken Lee, http://www.rahul.net/kenton/)
class MyClass {
void createWidgets();
static void myButtonCB(Widget, XtPointer, XtPointer);
};
void MyClass::createWidgets() {
w = 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 summarizing mechanisms (Ronald van Loon,
rvloon@motif.xs4all.nl). See his articles in the September, 1994 and
Nov/December, 1994 issues of C++ Report.
Doug Young's book deals extensively with one of these. The problem is that you
don't get the object when you just use the function as a callback. You need
to pass the object as a pointer through as the client_data. (use "this" as
the client_data.) Then you can retrieve the object's address, and dereference
from there. For example (Leo O'Donnell, Email: leo@avs.com),
class MyButton {
public:
MyButton (Widget parent, const char *name) {
_button = XtVaCreateManagedWidget (
name, xmPushButtonWidgetClass, parent, NULL, 0);
XtAddCallback (
_button,
XmNactivateCallback,
&MyButton::activateCB,
(XtPointer) this);
}
~MyButton () { XtDestroyWidget (_button); }
private:
Widget _button;
static void activateCB (Widget, XtPointer, XtPointer);
};
void MyButton::activateCB (Widget, XtPointer thisBtn, XtPointer)
{
MyButton *btn = (MyButton *) thisBtn;
// OK you've got the button instance now. Do some stuff with it!
}
-----------------------------------------------------------------------------
Subject: 245) Is there a Common Lisp binding for Motif?
[Last modified: Oct 94]
Answer: Try CLM. This includes a toolkit demon (in C) that takes a widget
description (with callbacks), and forks a new process for each Motif
application (which can be just a single menu, or whatever). Lisp can then
continue running, with a separate lightweight lisp process handling the
connection & callbacks. In North America & net environs, CLM-2.3.tar.Z is
available from ftp.x.org.
There is also CLIM, the Common Lisp Interface Manager. It provides access to
motif and other toolkits and window systems. Here is some blurb: "Version 2.0
of the Common Lisp Interface Manager (CLIM) provides access to Motif. CLIM is
the emerging standard for GUI development in Common Lisp. It offers a set of
high-level facilities that enable rapid construction of user interfaces.
Applications written using CLIM are portable across a variety of window
systems and toolkits. For example, on the X window System, both Motif
(OSF/Motif) and Openlook (OLIT) are supported. CLIM accesses the toolkit
directly rather than emulating the look and feel."
CLIM is available from a variety of Common Lisp vendors including Symbolics
and Franz Inc. (info@franz.com).
-----------------------------------------------------------------------------
Subject: 246) Is there an Ada binding for Motif? (Part 1 of 2)
[Last modified: Jan 96]
Answer: Most of the information in this answer (parts 1 and 2) is probably
very dated by now. If anyone wants to provide updates, I'll include them. In
the meantime, Ada users are encouraged to visit the Ada Information
Clearinghouse (AdaIC) at:
http://sw-eng.falls-church.va.us/AdaIC/
(The Jan. 96 change updates the information provided by Thomson Software
Products.)
Answer: Integrated Computer Solutions, Inc. (ICS) supplies Ada bindings to
Motif for a number of platforms and Ada compilers. ICS also provides Builder
Xcessory, a Motif interface builder, which outputs Ada code usable with the
Ada bindings. The product family is known collectively as the Ada Xcessories.
Integrated Computer Solutions, Inc. (ICS) 201 Broadway, Cambridge, MA 02139
USA info@ics.com 617/621-0060
Information on Ada bindings to Motif and other services (such as SQL and
POSIX) can be found in a document maintained by the Ada Information
Clearinghouse. The report can be found at
host: ajpo.sei.cmu.edu
loc: /public/ada-info/bindings.hlp.*
access: anonymous ftp
The suffix to the file (indicated above with an asterix) is the date of the
latest update to the document. For example, the full name of the report
updated on 14 June 1993 would be
/public/ada-info/bindings.hlp.14Jun93.
The file is ASCII.
------ Included File
[...Excerpted from the AdaIC report bindings.hlp.14Jun93...]
[...Updates can be found on ajpo.sei.cmu.edu, in the ...]
[...file /public/ada-info/bindings.hlp.* The suffix ...]
[...is always the date of the lastest version to the ...]
[...report. ...]
SECTION 12
X-Window System:
OSF Motif and Open Look
Available Ada Bindings
12.1 Description and Standardization Efforts
The X-Window System is a network-transparent window system. It supports one
or more screens containing overlapping windows or subwindows. X display
servers distribute user input to and accept output requests from various
client programs located either on the same machine or elsewhere in the
network.
OSF Motif (Open Software Foundation/Motif) is a graphical user
interface from OSF that provides a Presentation Manager look and
feel for applications running on any system with X Window version
11. It conforms to POSIX, ANSI C and X/Open's XPG3 standards.
12.2 Resources Available from Software Reuse Libraries/Repositories
ASSET (Updated: November 1992)
The following information was taken in its entirety from the ASSET Library
Repository Catalog, October 9, 1992. For more information on ASSET, see
Appendix C.
INTERFACE TO THE X WINDOW SYSTEM
VERSION_NUMBER : 1.1
DEVELOPED_BY : SAIC
RELEASE_DATE : 29-SEP-88
UNIQUE_IDENTIFIER : ASSET_A_240
ALTERNATE_NAME : SAICX2
ASSET_TYPE : SOFTWARE CODE
FUNCTIONS : INTERFACE, BIND
OBJECTS : ADA, X WINDOWS
KEYWORDS : STANDARDS, BINDINGS
COLLECTION : STARS FOUNDATIONS
DISTRIBUTION : UNLIMITED
DESCRIPTION :
Interface to the X Window System An expression of the various concepts in Ada
that provides a full, working Ada specification of the X Window system.
Approved for public release; distribution is unlimited.
12.3 Products Available from Vendors
Advanced Technology Center (Updated: November 1992)
The Advanced Technology Center (ATC) has an Ada binding to OSF Motif for their
AXI~ product. AXI is currently available for most UNIX-based platforms, and
is supported by Verdix, Meridian, and TeleSoft compilers.
AXI is an Ada-to-X-Window System interface that provides the Ada programmer
access to the 500+ functions, libraries, and procedures contained in the X
library (Xlib), the X Toolkit (Xt), the X Extensible Library, the X
Miscellaneous Utilities, the Motif widget set and the Motif Resource Manager.
ATC is planning to develop an Ada binding to Open Look for AXI.
For more information, contact:
Larry Paulson, Advanced Technology Center, 22982
Mill Creek Drive, Laguna Hills, CA 92653, USA; Phone:
714-583-9119
Thomson Software Products (formerly Alsys) (Updated: Jan
1996)
Thomson Software Products markets the following Ada products: ObjectAda,
AdaWorld for Cross Development, ActivAda, ActivAda Real-Time, and perfoRMAx,
each described below. (Contact Thomson for pricing info.)
Product Name: ObjectAda Hardware SPARC-based systems OS Solaris
ObjectAda is a complete object-oriented environment which is based on the new
standard for the Ada language, Ada 95. ObjectAda gathers in a single
integrated environment all the tools needed for the development of Object
Oriented Ada applications and allows developers to increase productivity by
simplifying the repetitive tasks of the programming process. ObjectAda
includes an Ada compiler which emphasizes compile-time error checking to
reduce mistakes and fully optimized code for compact, high-performance
applications. A comprehensive, integrated toolset that is easy to use via an
OSF/Motif-based graphical user interface is included in the ObjectAda
environment, allowing programmers to reap the full power of all the tools with
minimum training. The environment also includes an Ada sensitive editor,
source-level symbolic debugger, profiler, and additional tools and bindings.
Product Name: AdaWorld for Cross Development Hardware Hosts: SPARC-
based systems, HP-RT, IBM,
Targets: 680x0, 80x86, MIPS, PowerPC OS Solaris, SunOS, UNIX, DOS,
LynxOS
For developing embedded, real-time applications, Thomson Software Products+
offers Ada development environments to assure maximum programmer productivity
while generating highly-optimized Ada applications. Hosted on a broad range
of platforms, each environment includes a powerful Ada compiler and runtime
system, as well as a comprehensive, integrated toolset that is easy to use via
an OSF/Motif-based graphical user interface. The environment also includes an
Ada sensitive editor, multi-library system, source-level symbolic debugger,
profiler, and additional tools and bindings. Ada development environments are
available for cross development targeting the Motorola 680x0, Intel 386/486,
MIPS, and PowerPC.
Product Name: ActivAda Hardware 386, 486, or Pentium system OS
Windows, Windows NT, Windows 95
ActivAda is an Ada Integrated Development Environment (IDE) delivering the
combined power of 32-bit architecture, the Windows operating system and Ada in
one comprehensive product. ActivAda+s robust functionality assures reliable,
high-quality code with dramatically reduced development time. ActivAda is
geared to the entire development cycle, providing a Windows Graphical User
Interface (GUI) with full point-and-click access to all development tools.
Development of Win32 applications is possible for both Windows, Windows NT
and Windows 95. In addition, a GUI Builder that generates Ada code, Ada
bindings to the Win32s API, a Win32s CodeView Debugger, and an interface to
Microsoft Visual C++ are all included. All of these features are bundled
together with a validated Ada compiler and comprehensive toolset, providing a
solid technology base that has been in use in major development projects for
over 10 years.
Product Name: ActivAda Real-Time Hardware Hosts: 386/486/Pentium
Targets: 386/486/Pentium OS Windows, Windows 95
Finally, developers can create tight, fast code for Intel targets from an
easy-to-use Windows environment, while enjoying the full benefits of the Ada
language. We+ve merged two powerful technologies: our award-winning ActivAda
development environment, and our highly-optimized Intel cross compilation
system to produce a uniquely powerful and economical real-time development
platform. ActivAda provides real-time and embedded developers with everything
they need to create cutting-edge, highly reliable Intel target code, all in
one package.
Product Name: perfoRMAx Hardware Hosts: PC OS Windows, Windows
95, Windows NT
perfoRMAx is a unique, easy-to-use graphical tool suite that applies the
mathematical principles of Rate Monotonic Analyst and other scheduling
techniques to your real-time system. Used during proposal, specification,
design, implementation, and maintenance phases, perfoRMAx can save months or
years of wasted effort, millions of wasted dollars, and can even save lives
and assets. perfoRMAx is an advanced engineering tool that enables real-time
developers and engineers to focus on the temporal aspects of real-time system
development and maintenance. Through its unique analysis process, perfoRMAx
provides a framework for analyzing system timing behavior.
For more information, contact: Marianne Worley Thomson Software Products
(formerly Alsys) 10251 Vista Sorrento Parkway Suite 300 San Diego, CA 92121
Tel: (619) 457-2700 x244 Toll Free: (800) 833-0085 x244 Fax: (619) 452-2117
Email: adainfo@thomsoft.com WWW: http://www.thomsoft.com/
Digital Equipment Corporation (Updated: November 1992)
Digital Equipment Corporation has bindings available for GKS, PHIGS, SQL, and
OSF Motif for VAX Ada/VMS. The Ada bindings are provided either as part of a
compiler product or the services/facilities that are provided by Digital and
its suppliers.
Host/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 1992)
IBM's AIX Ada/6000 product provides a binding to GPEF and IBM AIXWindows (X-
Windows ... not Motif). It runs on all models of the IBM RISC System/6000
under the IBM AIX Version 3.2 operating system. See also entries for Systems
Engineering Research Corporation (SERC) and Advanced Technology Center (ATC)
for Motif, GKS or PHIGS bindings for use with IBM AIX Ada/6000 products.
The AIX Ada/6000 licensed programs (5706-291 and 5706-294) consist of an
optimizing compiler, a run-time environment, a symbolic debugger, an Ada
"makefile" generator for use in automating and minimizing recompilation, Ada
library management tools and Ada language bindings to some key AIX subsystems.
With the exception of some system-specific aspects of the language, the Ada
language for the AIX operating system is source compatible with the Ada
language supported by IBM licensed programs in VM/CMS and MVS.
Host/Target:IBM RISC System/6000 under the IBM AIX Version 3.2 operating
system
This product conforms to the following standards: ANSI/MIL-STD-1815A - Ada at
current level (1.11) of the ACVC test suite.
For more information, contact:
Barry Lee, IBM Corporation, 844 Don Mills Road,
North York, Ontario, Canada M3C 1V7; Phone: (416)
448-3174; Fax: (416) 448-4810
Objective Interface Systems, Inc. (Updated: November 1992)
Objective Interface Systems, Inc., has an Ada binding to X-windows (OSF Motif)
for its Screen Machine~ product. The Screen Machine binding to Motif includes
a WYSIWYG drawing tool and an Ada code generator.
Host/Target:
Sun SPARC/SunOS Rational R1000/Delta HP 9000/7XX; 8X7 IBM RISC
System/6000/AIXPC 386/486/ISC UNIX HFSI WIS Workstation PC
286/386/486/MS-DOS PC 386/486/SCO UNIX DEC Ultrix; DEC VMS
For more information, contact:
Phil Carrasco, Object Interface Systems, Inc.
1895 Preston White Drive, Suite 250, Reston, VA
22091-5448, USA; Phone: (703) 264-1900; Fax:
703-264-1721; email info@ois.com (internet)
SL Corporation (Updated: November 1992)
SL Corporation's SL-GMS toolkit includes Ada bindings to GPEF, GPPF, POSIX,
SQL, TCP/IP, OSF/Motif, and Open Look.
SL-GMS is a toolkit for developing dynamic graphics screens for real-time or
highly interactive applications. Non-programmers can design application
screens in a standard drawing-tool mode, connect them to real-time data
sources and animate screen objects to visualize changing data values. SL-GMS
allows the design of custom "GISMOs" to input values or control the
application and supports MOTIF, OPEN LOOK and other X toolkit widgets.
SL-GMS is used extensively to provide real-time graphics for applications in
the fields of manufacturing, process control, network management, avionics and
financial tracking.
Host/Target:Validated Verdix and DEC compilers support SL-GMS for the
following machines as both host and target:
DEC-DECstation/ULTRIX 4.0DEC-VAXstation/ULTRIX 4.0
DEC-VAXstation/VMS 5.4 DEC-VAXstation/VMS 5.5
IBM-RS6000/AIX
HP-9000/300/UNIX HP-9000/400/UNIX
HP-9000/800/UNIX HP-9000/700/UNIX
PC-386/IX UNIX PC-386/SCO UNIX
PC-386/Lynx PC-386/0S2
PC-386/System 5.4
SGI-4D/IRIX 3.3
Sun-3/SunOS 4.1 SunSPARC/SunOS 4.1
88 Open/BCS Compliant
For more information, contact:
Mike Meagher, SL Corporation, 240 Tamal Vista
Boulevard, Corte Madera, CA 94926, USA Phone: (415)
927-1724; Fax: (415) 927-2931
Sunrise Software International (Updated: May 1992)
Sunrise Software International's product, ezx, is a rapid application
development tool that automates the creation of graphical user interfaces for
OSF/MOTIF and generates C, UIL, or Ada. ezx provides WYSIWYG screen layout;
color, font and pixmap editors; presentation tools and dialog management. A
prototype can be developed in hours and using a script language similar to
Hypertalk, demonstrated to end-users before the first line of code is written.
Then portable C, UIL or Ada can be generated automatically. Ada bindings are
provided. The total code required to develop a GUI is reduced by
approximately 75%. The appearance and behavior of the GUI is defined in an X
resource file which the application loads at run time. This provides explicit
separation between the GUI and the computational core of the application. Thus
the GUI can be revised without recompiling (and retesting) the application.
ezx provides cost savings throughout the software development cycle, from
requirements analysis through design, code, test and maintenance.
Host/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 1992)
-----------------------------------------------------------------------------
Subject: 247) Is there an Ada binding for Motif? (Part 2 of 2)
[Last modified: Apr 94 ]
Answer: (This answer hasn't changed since the date given, but I needed to
break it into 2 parts.)
SERC's Ada/MOTIF is a complete binding to X Window and OSF/Motif for the Ada
programming language that was based in part upon the SAIC/Unisys (STARS)
public domain bindings. That work was leveraged as a starting point for this
development; many of the bug fixes and additional capabilities beyond the
public domain releases in Ada/MOTIF have been incorporated. Most noteworthy
are the capabilities included in Ada/Motif for Ada tasking, callback
registration, memory leak detection/prevention and capabilities for developing
customized widgets. Paramax/STARS considers Ada/Motif to be the commercial
version of their STARS bindings, according to SERC.
Ada/MOTIF is supported by the ALSYS, VERDIX, SUNAda, IBM Ada, and SGI Ada
compilers.
Host/Target:SUN 4, HP 300/400, HP 700, IBM RS 6000, SGI, 386
SUN OS 4.1.1, SOLARIS 2.0 (coming), HPUX 8.0, SGI 3.2 & 4.0, IBM
ATX 3.2, SCO 3.2
For more information, contact:
Theo Kusiolek or Scott Cleveland, Systems Engineering Research Corporation
(SERC), 2555 Charleston Road, Mountain View, CA 94043, USA; Phone: 800-ADA-
SERC or 415/962-9092; Fax: 415/962-0330; E-mail: Well!sercmail@apple.com.
TeleSoft (Updated: November 1992)
TeleSoft's TeleUSE/Ada automates the creation of OSF/Motif graphical user
interfaces for Ada applications. It includes a special version of the TeleUse
User Interface Management System -- which generates Ada source code -- and Ada
bindings to the TeleUSE run-time routines.
TeleUse/Ada tools allow a GUI to be prototyped and designed using a WYSIWYG
editor and a PDL, and also includes tools for debugging, generating production
code and maintaining the GUI. TeleUse/Ada can save the developer up to 90
percent of the time required to hand code X Window System GUIs.
Host/Target:SPARC under UNIX, Sun-4 under UNIX
TeleSoft's TeleWindows is a set of Ada bindings to the X Window System and
OSF/Motif. This includes Xlib, XT, X extensions Library, XT+, X miscellaneous
utilities, Motif widget set, XM, MWM, Motif resource manager. It supports X-
11 R4 and is not based on the public domain version. It closely follows the C
Xlib syntax and allows Ada applications to co-exist with C applications.
Host/Target:IBM System/370 under VM/CMS
For more information, contact:
Karen Johnson, TeleSoft, 5959 Cornerstone Court
West, San Diego, CA 92121-9891, USA; Phone: (619) 457-2700
Verdix (Updated: May 1992)
The Verdix Ada Development System (VADS), is a complete Ada Compiler System
offering a fully validated Ada compiler with chapter 13 support. Verdix
supplies VADSself and VADScross. VADSself provides a complete toolset for
self-targeted applications. It easily interfaces to databases, windowing
systems and program management tools. VADScross provides real-time support
for host-to-target system development. VADScross produces small and fast
object code. VADS is hosted on the largest number of platforms and targets
the greatest number of microprocessors.
Host/Target:88000 BCS under UNIX, DEC VAX under VMS / ULTRIX / UNIX,
DECStation (RISC) under UNIX, DECSystem (RISC) under UNIX, HP 9000
Series 300 under HP-UX (UNIX), IBM PS/2 under AIX (UNIX), IBM
RISC System/6000 under AIX, SCO Systems V/386 (ABI) under UNIX,
Sun SPARC systems under UNIX, Sun-3 systems under UNIX
Verdix AXI provides an Ada binding to the full Motif, Xt, and Xlib libraries.
The product works with user-supplied Motif 1.1 and X11R4 libraries regardless
of source.
Host/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: 248) Is there a Poplog binding for Motif?
[Last modified: May 93]
Answer: A integrated programming environment consisting of the programming
languages Pop-11, Prolog, Standard ML, and Lisp which are compiled to machine
code via a common virtual machine. Pop-11 provides a rich interface to the X
Toolkit which can be accessed from all other Poplog languages. The OLIT,
Motif, and Athena widget sets are supported, in addition to the custom Poplog
(Xpw) widget set. XVed provides a sophisticated, customisable multi-window
editor. Under OPEN LOOK and Motif the Poplog User Interface (PUI) provides a
graphical interface to the Poplog system. High-level Pop-11 libraries allow
graph drawing, turtle graphics, and the simple creation of basic button/menu
based interfaces.
Contact:
UK EDUCATION SITES:
Poplog Sales. School of Cognitive and Computing Sciences.
Brighton. BN1 9QN. England.
Phone: +44 (0)273 678188
Email: popsales@cogs.susx.ac.uk
USA AND CANADIAN EDUCATION SITES:
Computable Functions Inc. 35 South Orchard Drive. Amherst.
MA 01002. USA.
Phone: (413) 253-7637
ALL OTHER SALES:
Integral Solutions Ltd. Unit 3, Campbell Court. Bramley.
Basingstoke. Hampshire. RG26 5EG. England.
Phone: +44 (0)256 882028
Fax: +44 (0)256 882182
Email: isl@integ.uucp
-----------------------------------------------------------------------------
Subject: 249) TOPIC: SPECIFIC PLATFORMS
-----------------------------------------------------------------------------
Subject: 250) 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: 251) How do I build Motif 1.2.2 on Solaris 2.1 with Sun C?
[Last modified: Oct 94]
Prepared by Ric Steinberger. ric@updike.sri.com 4/09/93
What follows is a description of the steps I used to build Motif 1.2.2 on a
SUN IPX running Solaris 2.1. Sun's C compiler (2.0.1) was used. Many thanks
go to Kaleb Keithley (kaleb@devvax.jpl.nasa.gov) for several useful
suggestions. Other people, including OSF staff, especially David Brooks
(dbrooks@osf.org), helped as well. My thanks to you all.
1. Build X11R5 from the mit distribution. You need to retrieve the sources
from ftp.x.org (in pub/R5) and patches 1 - 22 (or fixes 1-26) pub/R5/fixes).
There are several other sites that contain the X11R5 sources. After
installing patch 19, apply PEXlib.tar.Z, also available from ftp.x.org in
pub/R5/fixes. You can apply also R5.Xsun.multi-screen and R5.SunOS5.patch.
There are .README files that explain how to patch. Be SURE to read
R5.SunOS5.patch.README for details on how to BUILD X11. You probably want to
use the ProjectRoot feature in the site.def file in the mit/config directory.
You will NEED to edit that file to do that.
2. Obtain the Motif 1.2.2 distribution from OSF (617-621-7300). You may need
to first install the 1.2 tape, then the 1.2.1 and finally the 1.2.2 tape. You
might want to do a "chmod -R u+w ." after unloading each tape.
3. In the config directory, there are several changes. Some of the changes
are based on R5.SunOS5.patch files. A complete set of config files relevant
to Solaris have been placed in the anon-ftp account of updike.sri.com in
pub/motif/solaris21-motif122-config.tar.Z. They are also available from OSF
on their mail response server (available to support contract holders) and they
will send them directly to full support contract holders. Decompress and
untar this file in your Motif config subdirectory. Copy site.def.sample to
site.def, then edit site.def. You will probably want to uncomment the
ProjectRoot section and use the same value used in your X11R5 build. Also,
you will probably want to use /usr/ucb/install in you installed the UCB
compatibility suite. Otherwise you might want to use the install supplied at
the end of this memo. [I used the UCB version and can't swear that this
works. Bit it should. Put it someplace like /usr/local/bin and chmod +x it.]
There are two patches to consider. One fixes a cursor problem in
./lib/Xm/TextF.c. The other removes a Berkeleyism. These patches should
probably be consider unofficial at present. Failure to deal with the
Berkeleyism (bzero) means you will need to link with -lucb -lelf. This will
probably work, but why bother? Furthermore, if you move the Motif binaries to
a machine without the ucb compatability suite, you won't have the sharable
libs you need.
[The actual patches have been censored because they contain OSF source code]
Patch 1: In TextF.c there are several places _XmTextFieldDrawInsertionPoint is
called. These should be moved two or three lines further down *after* the "if
(!XtIsRealized(tf)) return True;" statement.
patch 2: The call to bzero in lib/Xm/Visual.c should be replaced by the
equivalent call to memset
Both these patches can be applied in the ./lib/Xm directory. If you don't
have the patch program (how did you build X11?), you can get it in the
vendor/cygnus directory of ftp.uu.net, or you can build it from source. Be
sure to get the latest version (2.0.12.u8).
4) Use the README-1.2.1 file as a guideline for building motif. I followed
directions in the section called, "Using X11R5 Installed Libraries and Header
Files." If you make a mistake after your first build attempt, copy
Makefile.ini to Makefile before retrying. You may need to do this in the
config subdirectory too, depending on what went wrong.
5) After make Makefiles, do make includes, make depend, then make (or as OSF
recommends, make -k). This gets as far as motifshell in the demos, which
fails to build because O_RDONLY and L_XTND are not defined. O_RDONLY is in
fcntl.h (actually <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: 252) 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: 253) 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: 254) 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: 255) Why does the OpenWindows server hangs when I popup a menu with
Button 3?
[Last modified: August 92]
Answer: This is an OpenWindows problem, but if you have Motif source you can
fix your own applications. From Steve Sistare of Thinking Machines Corp.:
"Change the 2 calls to XtGrabButton in RowColumn.c such that ButtonReleaseMask
| ButtonPressMask is passed for the event mask. Currently, only
ButtonReleaseMask is passed. Also, change the owner_event argument to FALSE.
" This has not been fixed in Motif as at 1.1.5.
-----------------------------------------------------------------------------
Subject: 256) Has anyone made shared libraries on an IBM RS/6000?
Answer: [NOTE: This may not a problem any longer; I believe that AIX is now
delivered with shared Xm libraries. If you know the status of this, email
kenton@nojunk.rahul.net.]
Sakari Jalovaara wrote: There is a problem: Xm redefines VendorShell and the
AIX linker put _both_ Xm's and Xt's VendorShell into programs. When an AIX
shared library is created as many references inside the library are resolved
as possible. If the symbol vendorShellClassRec is defined in libXt and
referenced, say, from a function XtFoo() also in libXt, the "ld" run that
creates the shared library resolves the reference:
XtFoo() -> vendorShellClassRec
Then I create the Motif library that has its own vendorShellClassRec and an
XmBar() function that uses it; libXm will also contain a resolved reference to
vendorShellClassRec:
XmBar() -> vendorShellClassRec
Finally, I link a program that uses both XtFoo() and XmBar() and the program
will end up with _two_ independent "vendorShellClassRec"s:
XtFoo() -> vendorShellClassRec [Xt version]
XmBar() -> vendorShellClassRec [Xm version]
Instant schizo zaphod mode. In reality, vendorShellClassRec is not referenced
from functions but from other widget class records.
I can't just pull Vendor.o out from the shared Xt (Vendor.o appears to define
the only external symbols redefined by libXm) because AIX shared libraries
apparently can't contain unresolved external references. If I take out
Vendor.o I have to take out every other file that uses symbols defined there -
and then files that need those files, etc. I tried it and ended up with three
or four object files in libXt and the res non-sharable.
I kludged around this by putting all of libXt (minus Vendor.o) into the shared
libXm. It isn't a pretty solution but it works - and beats having a
statically linked two-megabyte "periodic" demo...
-----------------------------------------------------------------------------
Subject: 257) What is the error "Unaligned access in XmString" under Ultrix?
Answer: Compile XmString.c with STRINGS_ALIGNED.
-----------------------------------------------------------------------------
Subject: 258) Can bugs in Sun's OpenWindows server cause Motif clients to
crash?
[Last modified: Oct 95]
Answer: Yes. Patch 100444-73 (or later) from Sun fixes most of these bugs.
Alternatively, you can compile and run the X11R6 sample server from MIT. See
the SunSolve web page:
http://sunsolve1.sun.com/pub-cgi/patchpage.pl
Ken Lee and Bob Cox, rwcox@mcw.edu.
-----------------------------------------------------------------------------
Subject: 259) Why does Motif on Linux crash when I open a file selection box?
[Last modified: Oct 98]
Answer: Make sure you use a libc that is compatible with your Motif.
Unfortunately, Linux libc is not binary compatible from release to release.
Older versions of Motif require libc 4.6.27. Some newer Motifs need libc5;
others need glibc.
Ken Lee, http://www.rahul.net/kenton/
-----------------------------------------------------------------------------
Subject: 260) Are there compatibility problems between some Linux Motif
libraries and libc5 or glibc?
[Last modified: Oct 98]
Answer: Yes. People have reported problems with the file selection box and
also with the OSF keysyms.
The problem is that some newer Linux packages (e.g., Red Hat 5.0) use glibc
(library and associated header files), which is not binary compatible with the
older libc5. Some newer Motif libraries use glibc, while older ones will use
libc5. Similarly the XFree and other libraries will be based on either libc5
or glibc. You must make sure you use one other the other consistently for all
your applications and libraries. The better Motif vendors should have an
upgrade strategy in place to help you with the transition.
This is a general problem that the Linux community is dealing with. If you
can't get the correct version information from your Motif vendor, the Linux
Usenet newgroups should be able to help you out.
Ken Lee, http://www.rahul.net/kenton/
-----------------------------------------------------------------------------
Subject: 261) How can I install Motif on my PC?
[Last modified: Jun 98]
Answer: There's a paper on this in the September, 1995 issue of *The X
Advisor*:
http://www.rahul.net/kenton/txa/sep95.html
A 1996 update to this article is available at:
http://www.rahul.net/kenton/xlinux_update.html
Ken Lee
-----------------------------------------------------------------------------
END OF PART SEVEN
-----------------------------------------------------------------------------
Subject: 262) TOPIC: KEYSYMS
-----------------------------------------------------------------------------
Subject: 263) What is causing the messages "unknown keysym name osfDown..."?
[Last modified: Oct 98]
Answer: There is an OSF supplied addition to the /usr/lib/X11/XKeysymDB file.
It is found on the release tape and should have been automatically installed
if the installation procedure was followed in the Release Notes.
You have to copy (or append) lib/Xm/XKeysymDB into /usr/lib/X11. This may
require root permission. It is not clear how to fix the problem if you can't
do this. The error comes from Xt translation table parsing and can't be fixed
in Motif, so if you can't get root permission you may be stuck. The file is
not copyrighted so you can install it on other systems.
If X has been built so that XKeysymDB is not in this directory, and you don't
know where it is looking, run 'strings libX11.a | grep XKeysymDB' to find the
path.
On a Sun running openwin with shared libraries, you may need to put the path
for the library containing XKeysymDB *first* in the path list in
LD_LIBRARY_PATH, or it may find the wrong XKeysymDB in the wrong directory.
XKeysymDB simply contains the registered keysym values for the OSF keysyms.
The OSF values are server-independent. And, all registered keysyms will be
included in an XKeysymDB file to be shipped with X11R5.
In the meantime (till all systems are X11R5+), a list of the registered
keysyms can be found in the X11R4 release in mit/doc/Registry/Xregistry.
Also note the XKEYSYMDB environment variable. Setting this to point to the
XKeysymDB file often helps, but not always...
Some people have also reported getting this error if their Motif libraries
were built with libc headers that are not compatible with those installed on
their system. For example, Linux has two incompatible libraries libc5 and
glibc. You may get keysym (and other) errors if your Motif was built with
libc5 but you run your Motif application with glibc. Contact your Motif
vendor for information on the required libc.
Ken Lee
-----------------------------------------------------------------------------
Subject: 264) What happens if I can't install Motif Keysyms?
tessi!george@nosun.West.Sun.COM (George Mitchell) wrote:
Here's what appears to happen if you don't have XKeysymDB in place to define
OSF's virtual keysyms:
1. At class initialize time, for a widget (such as XmText) that uses virtual
keysyms in its event translation table, all entries which refer to those
keysyms fail to parse correctly. In the case of XmText, instead of ending up
with a translation table with roughly 90 entries, you end up with one that has
29.
2. XKeysymDB doesn't exist, so you'd assume that KeyPress events will get
translated to plain vanilla keysyms, right? WRONG! All Motif widgets install
a virtual keysym translator ANYWAY! Consequently, the backspace key (for
example) gets translated to the keysym osfBackSpace.
3. Therefore, if you augment or override your widget's translations with
translations that refer to plain vanilla BackSpace, they will never be
triggered, because you will NEVER see plain vanilla BackSpace, only
osfBackSpace.
4. But you can't use osfBackSpace in an event translation entry, because you
don't have XKeysymDB installed!
Here's how I'm "dealing" with the problem right now: Motif installs its
virtual keysym translator by calling XtSetKeyTranslator every time a
VendorShell (or subclass) widget is created. So every time I create a shell,
I immediately call XtSetKeyTranslator (display, XtTranslateKey) to restore the
default translator. No more funny virtual keysyms! Now I can reinstall non-
osfKeySym translations and have them work the way I expect.
-----------------------------------------------------------------------------
Subject: 265) Why has OSF introduced Keysyms into Motif 1.1? They weren't
there in Motif 1.0.
Answer: ellis@osf.org wrote:
Virtual Keysyms are meant to provide a consistent keyboard model for Motif
applications running in a heterogeneous environment in which proprietary (i.e.
vendor specific) non-Motif applications may also be running.
First of all, for the sake of the rest of the readers, let's explain why this
is an issue:
It would be lovely if Motif's translation tables could just use the obvious
keysyms predefined by X. For example, there are keysyms for XK_BackSpace,
XK_Delete, XK_Left, XK_Right, etc. Shouldn't these be the ones that are used
in our translations? Unfortunately, the problem is not so simple. Some
specific examples:
While most vendors bind XK_BackSpace to the key at the top right
of the standard keyboard (often engraved with a leftwards
pointing arrow), not all do. In fact, some vendors (including DEC)
bind that key to XK_Delete.
While most vendors bind the arrow keys to XK_Up, etc, a number of
vendors (including Sun, on some servers) bind them to function key
keysyms.
A simplistic solution would require the use of xmodmap to change the offending
bindings. That would work swell in an all Motif environment. However, OSF's
goal (not always perfectly achieved) is interoperability. That is, we'd like
to make sure that both Motif and non-Motif programs can happily run in the
same environment.
It is expected that a vendor may have a wide variety of existing X-based
software that uses the keysyms as established by that vendor for specific
purposes. It is expected that these applications may run at the same time as
Motif-based software. Using xmodmap to change keysyms on the server side
could "break" the existing applications (or at the very least their
documentation) by making some keys unavailable, or by moving the location.
So, we chose not to use xmodmap. By the way, though OpenLook uses a different
implementation (they recompile their virtual translation tables into actual
translation tables), they basically adopted the same approach, presumably for
similar reasons.
To work properly, the virtual keysym model we implemented depends on Xlib
finding XKeysymDB installed appropriately (which standard Motif installation
does). This simply defines the keysyms (not the key they are bound to). This
unfortunate piece of stupidity is necessary because MIT only includes standard
keysyms in keysymdef.h. It should be said that our lives would be made easier
if MIT would also see fit to include registered keysyms in keysymdef.h as
well.
Motif applications determine how to bind virtual to actual keys by looking for
either a resource or a property on the root window which describes what to do.
Note that this information is on the server side, so that all applications use
the same virtual bindings regardless of where they are running. Mwm will
happily create the property if it finds a .motifbind file in your home
directory when it starts up. (Actually, things generally work even if none of
this is done, since if all else fails, the Motif toolkit chooses a virtual
bindings table to use based on the identification of the server).
The actual implementation of virtual keys is made possible by a hook in the
Intrinsics. Undoubtably, the implementation would be simpler and cleaner if
virtual key support was more directly supported by the Intrinsics. We will be
exploring this possibility in the future.
-- Ellis
-----------------------------------------------------------------------------
Subject: 266) Why do accented characters not work with Motif applications
linked with X11R6? What is the Compose file?
[Last modified: June 95]
Answer: Note: The list of codes below _should_ contain a backslash before
every numeric value. My FAQ maintainence tools have been stripping the
backslash. Sorry for the confusion...ksall@cen.com.
Roman Czyborra (czyborra@cs.tu-berlin.de) writes:
I've xmodmapped a few accented characters onto my keyboard. They've worked
fine in most every window, but were dead in the Motif applications linked with
X11R6. My LC_CTYPE has always been set to iso_8859_1, so that was not the
problem. It turns out that I can activate the keys by patching
$XLOCALEDIR/iso8859-1/Compose to also include the lines listed below.
<nobreakspace> : "240"
<exclamdown> : "241"
<cent> : "242"
<sterling> : "243"
<currency> : "244"
<yen> : "245"
<brokenbar> : "246"
<section> : "247"
<diaeresis> : "250"
<copyright> : "251"
<ordfeminine> : "252"
<guillemotleft> : "253"
<notsign> : "255"
<hyphen> : "255"
<registered> : "256"
<macron> : "257"
<degree> : "260"
<plusminus> : "261"
<twosuperior> : "262"
<threesuperior> : "263"
<acute> : "264
<mu> : "265"
<paragraph> : "266"
<periodcentered> : "267"
<cedilla> : "240"
<onesuperior> : "271"
<masculine> : "272"
<guillemotright> : "273"
<onequarter> : "274"
<onehalf> : "275"
<threequarters> : "276"
<questiondown> : "277"
<Agrave> : "300"
<Aacute> : "301"
<Acircumflex> : "302"
<Atilde> : "303"
<Adiaeresis> : "304"
<Aring> : "305"
<AE> : "306"
<Ccedilla> : "307"
<Egrave> : "310"
<Eacute> : "311"
<Ecircumflex> : "312"
<Ediaeresis> : "313"
<Igrave> : "314"
<Iacute> : "315"
<Icircumflex> : "316"
<Idiaeresis> : "317"
<ETH> : "320"
<Ntilde> : "321"
<Ograve> : "322"
<Oacute> : "323"
<Ocircumflex> : "324"
<Otilde> : "325"
<Odiaeresis> : "326"
<multiply> : "327"
<Ooblique> : "330"
<Ugrave> : "331"
<Uacute> : "332"
<Ucircumflex> : "333"
<Udiaeresis> : "334"
<Yacute> : "335"
<THORN> : "336"
<ssharp> : "337"
<agrave> : "340"
<aacute> : "341"
<acircumflex> : "342"
<atilde> : "343"
<adiaeresis> : "344"
<aring> : "345"
<ae> : "346"
<ccedilla> : "347"
<egrave> : "350"
<eacute> : "351"
<ecircumflex> : "352"
<ediaeresis> : "353"
<igrave> : "354"
<iacute> : "355"
<icircumflex> : "356"
<idiaeresis> : "357"
<eth> : "360"
<ntilde> : "361"
<ograve> : "362"
<oacute> : "363"
<ocircumflex> : "364"
<otilde> : "365"
<odiaeresis> : "366"
<division> : "367"
<oslash> : "370"
<ugrave> : "371"
<uacute> : "372"
<ucircumflex> : "373"
<udiaeresis> : "374"
<yacute> : "375"
<thorn> : "376"
<ydiaeresis> : "377"
-----------------------------------------------------------------------------
Subject: 267) TOPIC: UIL
[NOTE: As you can see, this is a new topic area. Send me your ideas for
answered questions pertaining to this topic.]
-----------------------------------------------------------------------------
Subject: 268) What is UIL and why is it so popular?
[Last modified: Sept 94]
Answer: UIL is the acronym for "User Interface Language", a Motif standard
which permits separation of the user interface from application code. UIL is
a textual description of the user interface which is compiled into binary form
called UID ("User Interface Definition") using the Motif-provided compiler
called "uil".
It is important to realize that UIL is a static description of the UI in that
connections between buttons and the dialogs they invoke, for example, is not
expressed here; dynamic UI behavior appears in C code.
The Period Table of Widgets, called "periodic" (delivered by many Motif
vendors) is an example of a UIL application.
There are many advantages and disadvantages of UIL applications. A few of the
advantages are:
UIL is a standard format which encourages separation of the user interface
from application code.
UIL can be read and/or written by many of the GUI builders and UIMS tools
mentioned elsewhere in this FAQ, making your interface portable (to a degree)
across builder tools.
UIL is a much better language than C for defining a widget hierarchy: in C,
the widget hierarchy is expressed "linearly" by referencing a previously-
created parent widget when creating a child widget; in UIL, widget trees are
defined more naturally using nesting.
With UIL, you separate the definition of the widget tree from the application.
You can make major changes to the look-and-feel without re-building the
application.
It is possible to write a "general-purpose" application that defines a library
of callbacks. The application may "execute" any UIL file that references
callbacks from the library.
For a good UIL reference, see "Motif Programming Manual", Volume 6A, published
by O'Reilly and Associates. [See "BOOKS" for details.]
-----------------------------------------------------------------------------
Subject: 269) What is Mrm?
[Last modified: Nov 94]
Answer: Mrm is the "Motif Resource Manager", a set of functions (whose names
begin with Mrm, such as MrmFetchWidget and MrmRegisterNames) in libMrm.a which
retrieve the widget hierarchy from the UID file, associate callbacks, and
create the widgets.
Mrm is usually discussed in books which cover UIL.
Motif Programming Manual, Volume 6A
OSF/Motif Programmers Guide
OSF/Motif Programmers Reference Manual
See the BOOKS section for detailed references.
-----------------------------------------------------------------------------
Subject: 270) 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: 271) Can I specify callback functions in resource files?
Answer: To specify callbacks, you must use UIL in addition to or in place of
resource files. You can, however, specify translations in resource files,
which give you most of the same functionality as callback functions.
Ken Lee, http://www.rahul.net/kenton/
-----------------------------------------------------------------------------
Subject: 272) How can I set a multi-line label in UIL?
[Last modified: Sept 94]
Answer: In UIL, you have to explicitly create a compound string with a
separator. Here's what W. Scott Meeks suggests:
value nl : compound_string('', seperate=true);
object my_label : XmLabel
{
arguments
{
XmNlabelString = 'Here' & nl & 'is' & nl & 'the' & nl & 'Label';
};
};
-----------------------------------------------------------------------------
Subject: 273) Is there a program that can convert a UIL file to tclMotif? I
have an old Motif program that I used on SCO unix. Now that I switched to
Linux, I would like to "reprogram" it without the Motif libraries under Linux.
[Last modified: Aug 95]
Answer: Jan Newmarch (jan@ise.canberra.edu.au) writes:
The latest version of tclMotif (v 1.3) will allow you to load uil files
(actually, the uid files output from the uil compiler) directly into tclMotif.
So you don't need to convert at all.
The source is available at ftp.x.org. This, plus a Linux binary are also at
ftp://ftp.canberra.edu.au/pub/motif/tclMotif (Thanks to Ben Elliston
(ben@ise.canberra.edu.au) for correcting this URL.)
-----------------------------------------------------------------------------
Subject: 274) Why does my SCO UIL application fail to open 60 UID files?
[Last modified: Sept 95]
Answer: Make sure that you call MrmCloseHierarchy. There is no need to keep
the file open after you fetch the widgets from it.
Thanks to Tom Schutter (tom@platte.com)
-----------------------------------------------------------------------------
Subject: 275) TOPIC: ICONIFICATION and DE-ICONIFICATION
Iconification/de-iconification is a co-operative process between a client and
a window manager. The relevant standards are set by ICCCM. Mwm is ICCCM
compliant. The toplevel (non-override-redirect) windows of an application may
be in three states: WithdrawnState (neither the window nor icon visible),
NormalState (the window visible) or IconicState (the icon window or pixmap
visible). This information is contained in the WM_STATE property but ordinary
clients are not supposed to look at that (its values have not yet been
standardised). Movement between the three states is standardised by ICCCM.
-----------------------------------------------------------------------------
Subject: 276) How can I keep track of changes to iconic/normal window state?
Answer: You can look at the WM_STATE property, but this breaks ICCCM
guidelines. ICCCM compliant window managers will map windows in changing them
to normal state and unmap them in changing them to iconic state. Look for
StructureNotify events and check the event type:
XtAddEventHandler (toplevel_widget,
StructureNotifyMask,
False,
StateWatcher,
(Opaque) NULL);
void StateWatcher (w, unused, event)
Widget w;
caddr_t unused;
XEvent *event;
{
if (event->type == MapNotify)
printf ("normal\n");
else if (event->type == UnmapNotify)
printf ("iconified\n");
else printf ("other event\n");
}
If you insist on looking at WM_STATE, here is some code (from Ken Sall) to do
it:
/*
------------------------------------------------------------------
Try a function such as CheckWinMgrState below which returns one of
IconicState | NormalState | WithdrawnState | NULL :
------------------------------------------------------------------
*/
#define WM_STATE_ELEMENTS 1
unsigned long *CheckWinMgrState (dpy, window)
Display *dpy;
Window window;
{
unsigned long *property = NULL;
unsigned long nitems;
unsigned long leftover;
Atom xa_WM_STATE, actual_type;
int actual_format;
int status;
xa_WM_STATE = XInternAtom (dpy, "WM_STATE", False);
status = XGetWindowProperty (dpy, window,
xa_WM_STATE, 0L, WM_STATE_ELEMENTS,
False, xa_WM_STATE, &actual_type, &actual_format,
&nitems, &leftover, (unsigned char **)&property);
if ( ! ((status == Success) &&
(actual_type == xa_WM_STATE) &&
(nitems == WM_STATE_ELEMENTS)))
{
if (property)
{
XFree ((char *)property);
property = NULL;
}
}
return (property);
} /* end CheckWinMgrState */
One problem with testing WM_STATE is that a race condition is possible;
immediately after testing it, it could change, and the logic proceeds to
behave as if it were in the old state.
-----------------------------------------------------------------------------
Subject: 277) How can I check if my application has come up iconic? I want
to delay initialization code and other processing.
Answer: Use XtGetValues and check for the XmNinitialState value of the
toplevel shell just before XtMainLoop. -- IconicState is iconic, NormalState
is not iconic.
-----------------------------------------------------------------------------
Subject: 278) How can I start my application in iconic state?
Answer: Try this from the command line:
application -iconic
Using the resource mechanism, set the resource XmNinitialState to IconicState
of the toplevel shell widget (the one returned from XtInitialise).
-----------------------------------------------------------------------------
Subject: 279) How can an application iconify itself?
Answer: In R4 and later, use the call XIconifyWindow. Ken Lee adds "Set
XmNiconic on your shell. This should work in X11R6 and later patch levels of
X11R5."
For R3, send an event to the root window with a type of WM_CHANGE_STATE and
data IconicState.
void
IconifyMe (dpy, win)
Display *dpy;
Window win; /* toplevel window to iconify */
{
Atom xa_WM_CHANGE_STATE;
XClientMessageEvent ev;
xa_WM_CHANGE_STATE = XInternAtom (dpy,
"WM_CHANGE_STATE", False);
ev.type = ClientMessage;
ev.display = dpy;
ev.message_type = xa_WM_CHANGE_STATE;
ev.format = 32;
ev.data.l[0] = IconicState;
ev.window = win;
XSendEvent (dpy,
RootWindow (dpy, DefaultScreen(dpy)),
True,
(SubstructureRedirectMask | SubstructureNotifyMask),
&ev);
XFlush (dpy);
}
-----------------------------------------------------------------------------
Subject: 280) How can an application de-iconify itself?
[Last modified: Aug 98]
Answer: Carolyn Allen writes:
if(XtIsRealized(shell_widget))
{
Display *dpy = XtDisplay(shell_widget);
Window win = XtWindow(shell_widget);
Window client = XmuClientWindow(dpy,win);
XMapRaised(dpy,client);
}
If all you want to do is pop the icon to the top, use XRaiseWindow(dpy,client)
instead.
-----------------------------------------------------------------------------
Subject: 281) Why doesn't MWM display an iconify button on my dialog windows?
[Last modified: May 95]
Answer: MWM (and some other window managers) does not allow transient windows
to be iconified. Transients are automatically unmapped when the main shell is
iconified and they are re-mapped when the main shell is restored. If you do
not want this transient behavior, you should use top a TopLevelShell widget
instead of a XmDialogShell widget for your windows.
Ken Lee
-----------------------------------------------------------------------------
Subject: 282) TOPIC: SPECIALIZED WIDGETS
[Last modified: Jan 95]
This section describes a few specialized widgets people have asked about. A
_far_ more comprehensive illustrated list is maintained by Richard Offer
(offer@sgi.com). His list covers these widget categories:
Complete Listing
Composite Widgets
Non-Composite Widgets
Motif 1.1 Compatible
Motif 1.2 Compatible
Athena Compatible
FWF Widget Set
By Author
Shareware Widgets
Commercial Widgets
For Richard Offer's Widget FAQ Home Page, WWW users should see:
http://reality.sgi.com/widgetFAQ/
The Widget FAQ is also available in ASCII as:
ftp://ftp.x.org/contrib/faqs/Widget.FAQ.Z
If you don't have access to the World Wide Web, the Widget FAQ (sans pictures)
can be obtained from ftp.x.org:
/contrib/faqs/Widget.FAQ.Z
-----------------------------------------------------------------------------
Subject: 283) Where can I get ComboBox, SpinBox, or Tree graph widgets?
[Last modified: Apr 98]
Motif 2.0 and later include an XmContainer widget which displays hierarchal
trees. Motif 2.0 also includes XmComboBox and XmSpinBox, which many users
requested.
For Motif 1.x versions of these widgets and listings of other types of
widgets, see the widgets FAQ mentioned in the previous subject.
-----------------------------------------------------------------------------
Subject: 284) Is there a help system or Motif hypertext system available?
[Last modified: Nov 96]
Answer: There are many hypertext-like help systems.
Computer Generation Incorporated's HView widget displays HTML 2.0 standard
text and images and HTML 3.0 tables. The widget was developed to provide an
imbedded on-line help facility. It offers a light weight, portable, and robust
browser for HTML documents without having to distribute a separate Web Browser
with your applications. A special feature allows links from HTML source files
into arbitrary text files.
http://www.compgen.com/widgets/
Computer Generation Incorporated
Building G, 4th Floor
5775 Peachtree Dunwoody Road
Atlanta, Georgia 30342 USA
+1 404 705 2800
Fax: +1 404 705 2805
Other help systems include:
Libhelp: http://www.informatik.uni-
stuttgart.de/ipvr/bv/personen/mache/libhelp/index.html
Libhelp is a comprehensive hypertext help system library for OSF/Motif(tm)
applications. It adds a help browser window to OSF/Motif(tm) applications
which can be accessed by a single interface function. It is suitable for menu
help and context sensitive help. Also it can run as a standalone application
(xmhelp).
Libhelp documents can be written in HTML (HyperText Markup Language) and can
have hypertext links, different fonts, inlined images and a lot of more
elements known from www (world wide web) browsers. Libhelp implements its own
history, index, caching and search path schemes.
Libhelp is a derivative work of NCSA Mosaic(tm) and not the original NCSA
Mosaic(tm) distributed by the University of Illinois and is available for
academic and individual use only. It is NOT available for commercial use.
Thanks to Matthew M. Freedman (mattf@cac.washington.edu) for the libhelp
pointer.
HTML Widget from NCSA:
The NCSA Mosaic for X package contains an 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. See
"Where can I get the HTML widget" above.
GWHIS:
There is a 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
Motif. HyperHelp 4.0 is available now and includes support for MIF, RTF (Word
6.0) and SGML. (The OpenLook look-and-feel is no longer supported).
Bristol Technology, Inc.
241 Ethan Allen Highway
Ridgefield, CT 06877
(203) 438-6969 (phone)
(203) 438-5013 (fax)
info@bristol.com
Demos are available by anonymous ftp from ftp.bristol.com (192.246.192.2) in
/pub/Demos/HyperHelp.
There was a posting of a motif hypertext-widget to comp.sources.x (Author:
B.Raoult ( mab@ecmwf.int ) ). It had the facility to read in helptext from a
file.
Francois Felix Ingrand (felix@idefix.laas.fr) wrote: 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. The corrected URL, thanks to
Hal DeVore (hdevore@erehwon.bmc.com), is:
ftp://ftp.laas.fr/pub/ria/felix/prs/xinfo-motif.tar.gz
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 )
Information about XpgHelp and a free demo version can be obtained via:
http://www.uni-paderborn.de/fachbereich/AG/szwillus/xpghelp/index.html
XpgHelp is distributed by:
Motifation GbR
Geroldstrasse 38
33098 Paderborn
Germany
+49 (0) 5251 25633 (phone)
email: griebel@uni-paderborn.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: 285) Is there a canvas widget or drawing widget for graphical
display?
[Last modified: Nov 96]
Answer: (Loox added Nov 96) The LOOX dynamic graphics development tool
includes a Drawing Manager widget for the display of dynamic graphics screens.
Features include
- display of intelligent graphics primitives (polylines, ellipses, pixmaps,
links)
- easy animation, blinking etc of primitives
- dynamic control objects (sliders, knobs, dials, toggles, multi-states,
digital display)
- C and C++ APIs
- LOOXMaker graphical editor for interactive primitive creation and animation
Contact:
Loox Software Inc.
4962 El Camino Real, # 206
Los Altos, CA 94022
voice : (415)903-0942
fax: (415)903-9824
url: http://www.loox.com
email: sales@loox.com
Groupe Bull - Koala Project has a Motif Canvas [Knvas] Widget. This widget is
intended to provide graphical display (lines, rectangles, icons,...) and
direct manipulation services (select, move, resize,...) for Xt based
applications. This widget is intended to be include in a MOTIF application,
but you can generate an Athena widget (though demos are only using MOTIF). The
widget is shipped with an objects library based on a C object oriented model
called KLONE (use of the Xt object model would dramaticaly increase
application load time and KLONE provides garbage collection). Features:
- uses an improved C small object-oriented model (garbage col. + polymorphism)
- multi-view: an object may be shared between two views (canvases)
- Multi-display: two views may be on different displays / screens
- double buffering for smooth animations
- easy to use "just know how to use widgets"
- small objects
- garbage collection
- Tag object to define graphical object appearance
- define tag's attributes with Xt resources
- dispatch mechanism uses Xt -> you can set Xt translations on a graphic obj
- Interactor objects to define a complete behavior
- unlimited Zoom / Unzoom
- classes: Line, Rect, Filled rect, Xpm Icon, Group, Ellipse, Anchor, Link
- mouse interactors: select, move, resize
More info available at:
http://www.inria.fr/koala/jml/widgets/knvas.html
ftp://avahi.inria.fr/pub/widgets/knvas-1.13.2.tar.gz
Requirements: MOTIF, XPM
Thanks to Jean-Michel.Leon@sophia.inria.fr. Thanks to Joachim Fabini
(jo@vmars.tuwien.ac.at) for updating me on the name change from "canvas" to
"knvas" and the version change.
-----------------------------------------------------------------------------
Subject: 286) How can I create a transparent widget?
[Last modified: Dec 98]
Answer: The simplest way is probably to use the SHAPE protocol extension. The
xeyes, xlogo, and oclock demo programs in X11R5 (and later) are good examples
of using SHAPE with widgets. You should be able to use the same techniques
with your Motif widget subclasses.
Ken Lee
Ken Sall (ksall@cen.com) adds: The official name for this extension is "X11
Nonrectangular Window Shape Extension". If you have X11R5 source, the Shape
extension document is $TOP/mit/hardcopy/extensions/shape.PS or
$TOP/mit/doc/extensions/shape.ms. In X11R6, see
$TOP/xc/doc/hardcopy/Xext/shape.PS or $TOP/xc/doc/specs/Xext/shape.ms. There
is also a terse man page: $TOP/mit/man/Xext/XShape.man (X11R5) and
$TOP/xc/doc/man/Xext/XShape.man (X11R6).
Ken Lee adds: Some graphics-oriented systems (e.g., SGI, HP) include hardware
overlay planes that support transparency directly. The APIs for accessing
these capabilities from Motif programs are non-standard. Read your system's
documentation or contact your vendor for more details.
-----------------------------------------------------------------------------
Subject: 287) TOPIC: CREATING WIDGETS
[This section is for widget writers.]
-----------------------------------------------------------------------------
Subject: 288) What are some good references for creating widgets (subclassing
widgets)?
[Last modified: May 99]
Answer: Ken Sall (ksall@cen.com) writes:
If you have Motif 2.0 or later, see the new document provided by OSF called
"OSF/Motif Widget Writer's Guide" in the directory:
doc/widgetGuide/Output/draft/ps.
If you have Motif 1.*, try these references (details in the BOOKS topic):
Paul Asente, Donna Converse, and Ralph Swick, X Window System Toolkit,
Second Edition, 1998.
Nye, Adrian & O'Reilly, Tim,
X Toolkit Intrinsics Programming Manual.Motif Edition, Volume 4M
Flanagan, David, Editor,
X Toolkit Intrinsics Reference Manual, Volume 5
joe shelby (jshelby@autometric.com) writes:
Alastair Gourlay, a former member of the Motif Development group at OSF, has
written 2 articles for _The X Resource_, published by O'Reilly and Associates.
The first, "Writing Motif Widgets : A Pragmatic Approach" can be found in
Issue 6. It covers writing a XmPrimitive-derived widget, deriving from that
widget, and writing a XmManager-derived widget. Also included are brief
summaries of several _Xm private functions for widget writers, how to use the
Motif 1.2 Representation Type functions, and adding the widgets to Mrm/Uil.
The second, "The One-Minute Manager : Custom Motif Layout Widgets Made Easy"
can be found in Issue 10. It expands and greatly simplifies creating
composite widgets for Motif. Gourlay has created and released a new widget,
the XmpGeometry widget that handles all of the geometry management issues for
you and provides convenience functions for determiningparent and child
widgets' perfered sizes. All the programmer has to do to derive from this
widget is create the new resources and constraints and implement 2 new class
methods to override the XmpGeometry's methods. Included with the XmpGeometry
class are 3 example derived widgets.
The code for these widgets is available at
ftp://ftp.uu.net/published/oreilly/xresource/issue6/Subclassing.tar.Z
ftp://ftp.uu.net/published/oreilly/xresource/issue10/OneMinuteManagers.tar.Z
Donald L. McMinds and Joseph P. Whitty have written a book, _Writing Your Own
OSF/Motif Widgets_, published by Prentice Hall for Hewlett-Packard
Professional Books. Both authors work at HP's Workstation Systems Division,
and have been involved with Motif developement since its beginnings. The book
(which is mostly code with explanations) gives details on writing
XmPrimitive-derived, XmManager-derived, and XmGadget-derived widgets, with one
example widget for each. In addition, the book provides "man-pages" for
several _Xm private functions for programmer convenience.
The code for these widgets is available at
ftp://hpcvaal.cv.hp.com/readonly/book_files/wr_widgets.tar.Z
-----------------------------------------------------------------------------
Subject: 289) How can I achieve binary compatibility using the
XmResolvePartOffset API?
[Last modified: July 96]
Answer: Daniel Dardailler (daniel@x.org) recently provided the following URL:
http://www.x.org/people/daniel/xmresolve
Achieving Binary Compatibility using the XmResolvePartOffset API
which addresses the problem caused by the fact that many widget writers "never
used the XmResolvePartOffsets API in their subclass code, therefore ensuring
it will break when dynamically relinked with newer version of libXm".
Unfortunately, this URL is no longer valid. Does anyone know of a new
location? Thanks.
-----------------------------------------------------------------------------
Subject: 290) TOPIC: MISCELLANEOUS
-----------------------------------------------------------------------------
Subject: 291) How can an application be informed of signals?
[Last modified: Jun 98]
Answer: The answer differs depending on whether you're using X11R5 or X11R6.
For those using X11R6, Ken Lee (http://www.rahul.net/kenton/) writes: In
X11R6, the Xt library has the new XtAppAddSignal() function. Ken Lee's
December, 1995 *The X Advisor* column has an example:
http://www.rahul.net/kenton/txa/dec95.html
For those using X11R5, these older responses apply:
blackman@hodgkin.med.upenn.edu (David Blackman) writes:
According to comp.windows.x FAQ, you shouldn't make Xt/Xlib calls from a Unix
signal handler:
"You can work around the problem by setting a flag in the interrupt handler
and later checking it with a work procedure or a timer event which has
previously been added."
Kaleb KEITHLEY (fedora.x.org!kaleb) adds:
Xt is not reentrant and it is not safe to call any Xt functions from a signal
handler... I think [the signaling] technique is covered in the [X] FAQ. On
most POSIX-type systems write(2) is guaranteed to be reentrant and atomic. If
you establish a simple pipe with the pipe(2) system call, and add it as an
XtInput with XtAppAddInput(), then you can write to the pipe in the signal
handler. Xt will notice that input is available and call the input-handler
proc. This technique is inherently better than setting the flag because the
write to the pipe will result in XtAppNextEvent returning immediately without
the latency you observe in using the flag technique. In R6 you can use the
XtAppAddSignal function.
Ken Sall (ksall@cen.com) adds: See the "Signal Handling" chapter of "Motif
Programming Manual" by Heller and Ferguson, listed in the BOOKS topic.
Paul Davey (pd@uit.co.uk) adds: The write and XtAppAddInput input method is
often the best - but be warned it does not work on some SVR3 based Unixes,
where a pipe may not be selected on. SCO Unix exhibits this behaviour so here
the external flag method should be used.
-----------------------------------------------------------------------------
Subject: 292) How do I control the repeat rate on a SUN keyboard?
Answer:
[...]
-ar1 milliseconds
This option specifies amount of time in milliseconds
before which a pressed key should begin to
autorepeat.
-ar2 milliseconds
This option specifies the interval in milliseconds
between autorepeats of pressed keys.
Of course this presumes you're using a server based on the MIT sample server.
Thanks to kaleb@x.org (Kaleb Keithley)
-----------------------------------------------------------------------------
Subject: 293) How can I identify the children of a manager widget?
Answer: Use XtGetValues() on XmNchildren (array of widget IDs) and
XmNnumChildren (number of widgets in array).
-----------------------------------------------------------------------------
Subject: 294) What functions can an application use to change the size or
position of a widget?
Answer: Applications should set the values of the XmNx, XmNy, XmNwidth, and
XmNheight resources.
Note that many manager widgets ignore the XmNx and XmNy resources of their
children, relying instead on their internal layout algorithms. If you really
want specific positions, you must use a manager widget that allows them, e.g.,
XmBulletinBoard.
Also note that some manager widgets reject size change requests from their
children when certain resources are set (e.g., XmNresizable on XmForm).
Others allow the the children to resize, but clip the results (e.g.,
XmNallowShellResize on shell widgets). Make sure you have these resources set
to the policy you want.
Due to bugs, some widgets (third party widgets) do not respond to changes in
their width and height. Sometimes, you can get them to respond correctly by
unmanaging them, setting the resources, then managing them again.
Under no circumstances should applications use routines like
XtConfigureWidget() or XtResizeWidget(). These routines are reserved for
widget internals and will seriously confuse many widgets.
Ken Lee
-----------------------------------------------------------------------------
Subject: 295) Can I use XtAddTimeOut, XtAddWorkProc, and XtAddInput with
XtAppMainLoop?
Answer: On many systems, the obsolete XtAdd*() functions are not compatible
with the XtAppMainLoop(). Instead, you should use newer XtAppAddTimeOut(),
XtAppAddWorkProc(), and XtAppAddInput() functions with XtAppMainLoop()
Ken Lee
-----------------------------------------------------------------------------
Subject: 296) Why does XtGetValues for XmNx and XmNwidth return extremely
large values?
Answer: You must use the 16 bit "Dimension" and "Position" data types for your
arguments. If you use 32 bit integers, some implementations will fill the
remaining 16 bits with invalid data, causing incorrect return values. The
*Motif Programmer's Manual* and the widget man pages specify the correct data
type for each resource.
Ken Lee
-----------------------------------------------------------------------------
Subject: 297) Can I use XmGetPixmap() with widgets that have non-default
visual types?
Answer: XmGetPixmap() assumes that you are using the default screen depth. If
you're using a different depth, use XmGetPixmapByDepth() instead.
Ken Lee
-----------------------------------------------------------------------------
Subject: 298) 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: 299) What is IMUG and how do I join it?
[Last modified: July 96]
Answer: CAUTION: As of March, 1996, IMUG could not be contacted. If anyone is
aware of the status of IMUG, please send mail to me (kenton@nojunk.rahul.net).
Thanks to Lou Farho (farho@harris.com) for this update.
IMUG is the International Motif User Group founded by Quest Windows
Corporation and co-sponsored by FedUNIX. IMUG is a non-profit organization
working to keep users informed on technical and standards issues, to
strengthen user groups on a local level, to increase communication among users
internationally, and to promote the use of an international conference as a
forum for sharing and learning more about Motif. You can join it by
1. Pay the annual membership fee of $20 USD directly to IMUG. Contact
IMUG
5200 Great America Parkway
Santa Clara, CA 95054
(408) 496-1900
imug@quest.com
2. Register at the International Motif User Conference, and automatically
become an IMUG member.
3. Donate a pd widget, widget tool or widget builder to the IMUG Widget
Depository and receive a free one year IMUG membership.
-----------------------------------------------------------------------------
Subject: 300) How do I set the title of a top level window?
[Last modified: September 92]
Answer: Set XmNtitle (and optionally XmNtitleEncoding) for TopLevelShells.
(Note that this is of type String rather than XmString.) You can also set
XmNiconName if you want its icon to show this title. For XmDialogShells, set
the XmNdialogTitle of its immediate child, assuming it's a BulletinBoard
subclass. These can also be set in resource files.
-----------------------------------------------------------------------------
Subject: 301) How can I disable the color scheme mechanism in CDE or HP VUE?
[Last modified: May 97]
Answer: Put this in your app-defaults file: *useColorObj: False
Ken Lee
-----------------------------------------------------------------------------
Subject: 302) Can I use editres with Motif? Is there an editres tutorial?
[Last modified: Mar 96]
Answer: Editres, part of the MIT delivery, is a powerful widget tree analysis
tool and is highly recommended. There's negligible overhead in making editres
available to an application and many projects keep the editres "hook" active
even for operational programs.
It isn't built in to Motif (at 1.2.*), but you can do this in your
application:
#include <X11/Xmu/Editres.h>
XtAddEventHandler(shell_widget, (EventMask) 0, True,
(XtEventHandler) _XEditResCheckMessages, NULL);
once for each shell widget that you want to react to the "click to select
client" protocol. Then link your client with the R5 libXmu.
Thanks to David Brooks, OSF, for the original answer. Jan Sandquist
(ehsjasa@ehs.ericsson.se) supplied the current code snipet above. Joachim
Fabini (jo@vmars.tuwien.ac.at) suggested that I remove the older use of
"extern void _XEditResCheckMessages()" which resulted in core dumps on some
platforms.
NOTE: Ken Lee has placed his November, 1994 editres tutorial on the Web:
http://www.rahul.net/kenton/editres.html
-----------------------------------------------------------------------------
Subject: 303) Where is the editres protocol documented?
[Last modified: Apr 95]
Answer: In /usr/include/X11/Xmu/EditresP.h.
Ken Lee
-----------------------------------------------------------------------------
Subject: 304) Why does an augment translation appear to act as replace for
some widgets? When I use either augment or override translations in
.Xdefaults it seems to act as replace in both Motif 1.0 and 1.1
Answer: By default, the translation table is NULL. If there is nothing
specified (either in resource file, or in args), the widget's Initialize
finds: Oh, there is NULL in translations, lets use our default ones. If,
however, the translations have become non-NULL, the default translations are
NOT used at all. Thus, using #augment, #override or a new table has identical
effect: defines the new translations. The only way you can augment/override
Motif's default translations is AFTER Initialize, using XtSetValues. Note,
however, that Motif managers do play with translation tables as well ... so
that results are not always easy to predict.
OSF wrote: A number of people have complained about not being able to
augment/override translations from the .Xdefaults. This is due to the
complexity of the menu system/keyboard traversal and the necessary
translations changes required to support the Motif Style Guide in menus. It
cannot be fixed in a simple way. Fixing it requires re-design of the
menus/buttons and it is planned to be fixed in 1.2.
-----------------------------------------------------------------------------
Subject: 305) 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: 306) Can I change the graphics drawn by insensitive widgets? Some
become very difficult to read.
[Last modified: Aug 97]
Answer: There is no general mechanism for this; each widget chooses its own
insensitive graphics. Some are customizable, however. Label and button
widgets have a XmNlabelInsensitivePixmap resource. Others, such as the text
widgets, have an XmNeditable resource; setting this to false is similar to
insensitive, except tha the graphics do not change.
Other possibilities would be to install an empty translation table to ignore
input or to create an occluding InputOnly window to block input.
-----------------------------------------------------------------------------
END OF PART EIGHT
-----------------------------------------------------------------------------
Subject: 307) Why doesn't the Help callback work on some widgets?
[Last modified: May 95]
Answer: If you press the help key the help callback of the widget with the
keyboard focus is called (not the one containing the mouse). You can't get
the help callback of a non-keyboard-selectable widget called. To get `context
sensitive' help on these, you have to find the mouse, associate its position
with a widget and then do the help.
The X Resource, Issue 6, has an article on implementing context help in Motif
in this manner, that is, using the mouse position to indicate the widget for
which context help is desired, as well as using resources to specify the help.
Example source code is available at
ftp://ftp.ora.com/pub/examples/xresource/issue6/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). Thanks to chen@adi.com (Franklin Chen) for correcting the
URL.
-----------------------------------------------------------------------------
Subject: 308) How can I implement "bubble help" or "tool tips" with Motif?
[Last modified: Sep 98]
Answer: Gary Aviv (gary@compgen.com) informed this maintainer about the free
LiteClue widget from Computer Generation, Inc. (http://www.compgen.com/).
LiteClue is a widget which pops a one line help message when the user passes
the pointer over another "watched" widget. This is known by various names in
the industry such as hints, clues, tips, bubble help and balloon help.
Technical documentation and source for the LiteClue widget are available from:
http://www.compgen.com/widgets/LiteClue.html
ftp://ftp.compgen.com/pub/widgets/LiteClue.tar.Z
Ken Lee (http://www.rahul.net/kenton/) writes: A simple technique is to popup
a shell containing your message whenever an enter event occurs (possibly
delayed by a timer) and pop it down again after a leave event.
Morris Hirsch (hirsch@cs.umass.edu) has another approach and contributed a
code example which is over 1000 lines, so I've put the code on our web site:
http://www.cen.com/mw3/bubbleHelp.txt
David Lewis (dbl@ics.com) writes: To those resources I should add that the
XmHTML sources (HTML parser, browser, etc) have this ToolTip/bubble-help/popup
feature, in readily-usable code. In addition, the ICS EnhancementPak widget
set (http://www.ics.com) has both a toolbar with built-in popups for its
entries and a small library which adds popup capabilities to any widget.
-----------------------------------------------------------------------------
Subject: 309) 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: 310) 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: 311) Can I have separate translations for shifted and unshifted
keys?
[Last modified: Jan 99]
Answer: Alec Flett <alecf@netscape.com> writes:
I've got an addition for the motif FAQ that just solved a problem I've been
wrestling with for a month - it's really an addition to #303 "Why are only
some of my translations being installed?"
On certain platforms you cannot use an upper-case key in combination with the
Shift modifier. For example,
Meta Shift <Key>F: find-in-list()
will not always work because the F is capitalized.
The reason for this is because some platforms (such as IRIX) distinguish upper
case and lowercase keysyms. Using Jamie Zawinski's xkeycaps program
(http://www.jwz.org/xkeycaps/), you will see that on Solaris the "F" key just
has one keysym: "F" On IRIX they same key has two: "f" and "F".
-----------------------------------------------------------------------------
Subject: 312) What are these "non-existant passive grab" warnings? When I
destroy certain widgets I get a stream of messages
Warning: Attempt to remove non-existant passive grab
Answer: They are meaningless, and you want to ignore them. Do this (from Kee
Hinckley) by installing an XtWarning handler that explicitly looks for them
and discards them:
static void xtWarnCB(String message) {
if (asi_strstr(message, "non-existant passive grab", TRUE)) return;
...
They come from Xt, and (W. Scott Meeks): "it's something that the designers of
Xt decided the toolkit should do. Unfortunately, Motif winds up putting
passive grabs all over the place for the menu system. On the one hand, we
want to remove all these grabs when menus get destroyed so that they don't
leak memory; on the other hand, it's almost impossible to keep track of all
the grabs, so we have a conservative strategy of ungrabbing any place where a
grab could have been made and we don't explicitly know that there is no grab.
The unfortunate side effect is the little passive grab warning messages.
We're trying to clean these up where possible, but there are some new places
where the warning is generated. Until we get this completely cleaned up (1.2
maybe), your best bet is probably to use a warning handler."
-----------------------------------------------------------------------------
Subject: 313) How do I have more buttons than three in a MessageBox? I want
to have something like a MessageBox (or other widget) with more than three
buttons, but with the same nice appearance.
[Last modified: Feb 95]
Answer: The Motif 1.2 MessageBox widget allows extra buttons to be added after
the OK button. Just create the extra buttons as children of the MessageBox.
Similarly with the SelectionBox.
Pre-Motif 1.2, you have to do one of the following methods.
A SelectionBox is created with four buttons, but the fourth (the Apply button)
is unmanaged. To manage it get its widget ID via
XmSelectionBoxGetChild(parent, XmDIALOG_APPLY_BUTTON) and then XtManage it.
Unmanage all of the other bits in the SelectionBox that you don't want. If
you want more than four buttons, try two SelectionBoxes (or similar) together
in a container, where all of the unwanted parts of the widgets are unmanaged.
Alternatively, build your own dialog:
/* Written by Dan Heller. Copyright 1991, O'Reilly && Associates.
* This program is freely distributable without licensing fees and
* is provided without guarantee or warranty expressed or implied.
* This program is -not- in the public domain. This program is
* taken from the Motif Programming Manual, O'Reilly Volume 6.
*/
/* action_area.c -- demonstrate how CreateActionArea() can be used
* in a real application. Create what would otherwise be identified
* as a PromptDialog, only this is of our own creation. As such,
* we provide a TextField widget for input. When the user presses
* Return, the Ok button is activated.
*/
#include <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 = XmStringCreateLocalized("Type Something:");
XtVaCreateManagedWidget("label", xmLabelGadgetClass, rc,
XmNlabelString, string,
XmNleftAttachment, XmATTACH_FORM,
XmNtopAttachment, XmATTACH_FORM,
NULL);
XmStringFree(string);
text_w = XtVaCreateManagedWidget("text-field",
xmTextFieldWidgetClass, rc, NULL);
/* RowColumn is full -- now manage */
XtManageChild(rc);
/* Set the client data "Ok" and "Cancel" button's callbacks. */
action_items[0].data = (caddr_t)text_w;
action_items[1].data = (caddr_t)text_w;
/* Create the action area -- we don't need the widget it returns. */
action_a = CreateActionArea(pane, action_items, XtNumber(action_items));
/* callback for Return in TextField. Use action_a as client data */
XtAddCallback(text_w, XmNactivateCallback, activate_cb, action_a);
XtManageChild(pane);
XtPopup(dialog, XtGrabNone);
}
/*--------------*/
/* The next four functions are the callback routines for the buttons
* in the action area for the dialog created above. Again, they are
* simple examples, yet they demonstrate the fundamental design approach.
*/
static void
close_dialog(w, shell)
Widget w, shell;
{
XtDestroyWidget(shell);
}
/* The "ok" button was pushed or the user pressed Return */
static void
ok_pushed(w, text_w, cbs)
Widget w, text_w; /* the text widget is the client data */
XmAnyCallbackStruct *cbs;
{
char *text = XmTextFieldGetString(text_w);
printf("String = %s0, text);
XtFree(text);
}
static void
cancel_pushed(w, text_w, cbs)
Widget w, text_w; /* the text field is the client data */
XmAnyCallbackStruct *cbs;
{
/* cancel the whole operation; reset to NULL. */
XmTextFieldSetString(text_w, "");
}
static void
help(w, string)
Widget w;
String string;
{
puts(string);
}
/*--------------*/
/* When Return is pressed in TextField widget, respond by getting
* the designated "default button" in the action area and activate
* it as if the user had selected it.
*/
static void
activate_cb(text_w, client_data, cbs)
Widget text_w; /* user pressed Return in this widget */
XtPointer client_data; /* action_area passed as client data */
XmAnyCallbackStruct *cbs; /* borrow the "event" field from this */
{
Widget dflt, action_area = (Widget)client_data;
XtVaGetValues(action_area, XmNdefaultButton, &dflt, NULL);
if (dflt) /* sanity check -- this better work */
/* make the default button think it got pushed. This causes
* "ok_pushed" to be called, but XtCallActionProc() causes
* the button appear to be activated as if the user selected it.
*/
XtCallActionProc(dflt, "ArmAndActivate", cbs->event, NULL, 0);
}
#define TIGHTNESS 20
Widget
CreateActionArea(parent, actions, num_actions)
Widget parent;
ActionAreaItem *actions;
int num_actions;
{
Widget action_area, widget;
int i;
action_area = XtVaCreateWidget("action_area", xmFormWidgetClass, parent,
XmNfractionBase, TIGHTNESS*num_actions - 1,
XmNleftOffset, 10,
XmNrightOffset, 10,
NULL);
for (i = 0; i < num_actions; i++) {
widget = XtVaCreateManagedWidget(actions[i].label,
xmPushButtonWidgetClass, action_area,
XmNleftAttachment, i? XmATTACH_POSITION : XmATTACH_FORM,
XmNleftPosition, TIGHTNESS*i,
XmNtopAttachment, XmATTACH_FORM,
XmNbottomAttachment, XmATTACH_FORM,
XmNrightAttachment,
i != num_actions-1? XmATTACH_POSITION : XmATTACH_FORM,
XmNrightPosition, TIGHTNESS*i + (TIGHTNESS-1),
XmNshowAsDefault, i == 0,
XmNdefaultButtonShadowThickness, 1,
NULL);
if (actions[i].callback)
XtAddCallback(widget, XmNactivateCallback,
actions[i].callback, actions[i].data);
if (i == 0) {
/* Set the action_area's default button to the first widget
* created (or, make the index a parameter to the function
* or have it be part of the data structure). Also, set the
* pane window constraint for max and min heights so this
* particular pane in the PanedWindow is not resizable.
*/
Dimension height, h;
XtVaGetValues(action_area, XmNmarginHeight, &h, NULL);
XtVaGetValues(widget, XmNheight, &height, NULL);
height += 2 * h;
XtVaSetValues(action_area,
XmNdefaultButton, widget,
XmNpaneMaximum, height,
XmNpaneMinimum, height,
NULL);
}
}
XtManageChild(action_area);
return action_area;
}
-----------------------------------------------------------------------------
Subject: 314) How do I create a "busy working cursor"?
[Last modified: Feb 95]
Answer: - in Baudouin's code (following), the idea is to keep in an array an
up-to-date list of all shells used in the application, and set for all of them
the cursor to a watch or to the default cursor, with the 2 functions provided.
- in Dan Heller's code (later), the idea is to turn on the watch cursor for
the top-level shell only, popup a working window to possibly abort the
callback, and manage some expose events during the callback.
- in the FAQ for comp.windows.x, the idea is to bring a large window on top of
the application, hide all windows below it, and turn on the watch cursor on
this large window. Unmapping the large window resets the default cursor,
mapping it turns on the watch cursor.
Baudouin Raoult (mab@ecmwf.int) wrote:
void my_SetWatchCursor(w)
Widget w;
{
static Cursor watch = NULL;
if(!watch)
watch = XCreateFontCursor(XtDisplay(w),XC_watch);
XDefineCursor(XtDisplay(w),XtWindow(w),watch);
XmUpdateDisplay(w);
}
void my_ResetCursor(w)
Widget w;
{
XUndefineCursor(XtDisplay(w),XtWindow(w));
XmUpdateDisplay(w);
}
Answer: A solution with lots of bells and whistles is
/* Written by Dan Heller. Copyright 1991, O'Reilly && Associates.
* This program is freely distributable without licensing fees and
* is provided without guarantee or warrantee expressed or implied.
* This program is -not- in the public domain.
*/
/* busy.c -- demonstrate how to use a WorkingDialog and to process
* only "important" events. e.g., those that may interrupt the
* task or to repaint widgets for exposure. Set up a simple shell
* and a widget that, when pressed, immediately goes into its own
* loop. First, "lock" the shell so that a timeout cursor is set on
* the shell and pop up a WorkingDialog. Then enter loop ... sleep
* for one second ten times, checking between each interval to see
* if the user clicked the Stop button or if any widgets need to be
* refreshed. Ignore all other events.
*
* main() and get_busy() are stubs that would be replaced by a real
* application; all other functions can be used "as is."
*/
#include <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 = XmStringCreateLocalized(
"Boy, is *this* going to take a long time.");
button = XtVaCreateManagedWidget("button",
xmPushButtonWidgetClass, shell,
XmNlabelString, label,
NULL);
XmStringFree(label);
XtAddCallback(button, XmNactivateCallback, get_busy, argv[1]);
XtRealizeWidget(shell);
XtAppMainLoop(app);
}
void
get_busy(widget)
Widget widget;
{
int n;
TimeoutCursors(True, True);
for (n = 0; n < 10; n++) {
sleep(1);
if (CheckForInterrupt()) {
puts("Interrupt!");
break;
}
}
if (n == 10)
puts("done.");
TimeoutCursors(False, NULL);
}
/* The interesting part of the program -- extract and use at will */
static Boolean stopped; /* True when user wants to stop processing */
static Widget dialog; /* WorkingDialog displayed when timed out */
/* timeout_cursors() turns on the "watch" cursor over the application
* to provide feedback for the user that he's going to be waiting
* a while before he can interact with the appliation again.
*/
void
TimeoutCursors(on, interruptable)
int on, interruptable;
{
static int locked;
static Cursor cursor;
extern Widget shell;
XSetWindowAttributes attrs;
Display *dpy = XtDisplay(shell);
XEvent event;
Arg args[1];
XmString str;
extern void stop();
/* "locked" keeps track if we've already called the function.
* This allows recursion and is necessary for most situations.
*/
on? locked++ : locked--;
if (locked > 1 || locked == 1 && on == 0)
return; /* already locked and we're not unlocking */
stopped = False; /* doesn't matter at this point; initialize */
if (!cursor) /* make sure the timeout cursor is initialized */
cursor = XCreateFontCursor(dpy, XC_watch);
/* if "on" is true, then turn on watch cursor, otherwise, return
* the shell's cursor to normal.
*/
attrs.cursor = on? cursor : None;
/* change the main application shell's cursor to be the timeout
* cursor (or to reset it to normal). If other shells exist in
* this application, they will have to be listed here in order
* for them to have timeout cursors too.
*/
XChangeWindowAttributes(dpy, XtWindow(shell), CWCursor, &attrs);
XFlush(dpy);
if (on) {
/* we're timing out, put up a WorkingDialog. If the process
* is interruptable, allow a "Stop" button. Otherwise, remove
* all actions so the user can't stop the processing.
*/
str = XmStringCreateLocalized("Busy. Please Wait.");
XtSetArg(args[0], XmNmessageString, str);
dialog = XmCreateWorkingDialog(shell, "Busy", args, 1);
XmStringFree(str);
XtUnmanageChild(
XmMessageBoxGetChild(dialog, XmDIALOG_OK_BUTTON));
if (interruptable) {
str = XmStringCreateLocalized("Stop");
XtVaSetValues(dialog, XmNcancelLabelString, str, NULL);
XmStringFree(str);
XtAddCallback(dialog, XmNcancelCallback, stop, NULL);
} else
XtUnmanageChild(
XmMessageBoxGetChild(dialog, XmDIALOG_CANCEL_BUTTON));
XtUnmanageChild(
XmMessageBoxGetChild(dialog, XmDIALOG_HELP_BUTTON));
XtManageChild(dialog);
} else {
/* get rid of all button and keyboard events that occured
* during the time out. The user shouldn't have done anything
* during this time, so flush for button and keypress events.
* KeyRelease events are not discarded because accelerators
* require the corresponding release event before normal input
* can continue.
*/
while (XCheckMaskEvent(dpy,
ButtonPressMask | ButtonReleaseMask | ButtonMotionMask
| PointerMotionMask | KeyPressMask, &event)) {
/* do nothing */;
}
XtDestroyWidget(dialog);
}
}
/* User Pressed the "Stop" button in dialog. */
void
stop(dialog)
Widget dialog;
{
stopped = True;
}
Boolean
CheckForInterrupt()
{
extern Widget shell;
Display *dpy = XtDisplay(shell);
Window win = XtWindow(dialog);
XEvent event;
/* Make sure all our requests get to the server */
XFlush(dpy);
/* Let motif process all pending exposure events for us. */
XmUpdateDisplay(shell);
/* Check the event loop for events in the dialog ("Stop"?) */
while (XCheckMaskEvent(dpy,
ButtonPressMask | ButtonReleaseMask | ButtonMotionMask |
PointerMotionMask | KeyPressMask | KeyReleaseMask,
&event)) {
/* got an "interesting" event. */
if (event.xany.window == win)
XtDispatchEvent(&event); /* it's in our dialog.. */
else /* uninteresting event--throw it away and sound bell */
XBell(dpy, 50);
}
return stopped;
}
-----------------------------------------------------------------------------
Subject: 315) 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: 316) 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: 317) How do I use xmkmf for Motif clients?
[Last modified: July 96]
Answer: This advice comes from dbrooks@osf.org. For another answer, see the
question immediately following this one ("How do I use imake with Motif
2.0?").
There are a number of intractable problems with using X configuration files
and xmkmf, while trying to make it easy to build Motif. Not the least of
these, but one I've never heard mentioned yet, is that the rules for
contructing the names of shared library macros are machine-dependent, and in
the various xxxLib.tmpl files. Do we edit all those files to add definitions
for XMLIB, DEPXMLIB, etc., or do we put a maze of #ifdefs into the Motif.tmpl
file?
Please note that, if you install Motif, it overwrites your installed
Imake.tmpl with one that includes Motif.tmpl and Motif.rules.
With those caveats, I think the following guidelines will help.
David Brooks OSF
Clients in the X11R5 release use the xmkmf command to build Makefiles. In
general, the xmkmf command cannot be used for Motif clients, because of the
need to consider the UseInstalledMotif flag separately. Since xmkmf is a
simple script that calls imake, it is easy to construct the proper call to
imake using the following rules.
In the following, replace {MTOP} by the toplevel directory with the Motif
source tree, and {XTOP} by the toplevel ("mit") directory with the X source.
It is assumed that the directory containing your installed imake is in your
PATH.
When needed, the imake variables XTop and MTop are normally set in your
site.def (to {XTOP} amd {MTOP} respectively); however they may also be set
with additional -D arguments to imake.
1. With both X and Motif in their source trees, ensure the imake variables
XTop and MTop are set, and use:
${XTOP}/config/imake -I{MTOP}/config
2. With Motif in its source tree, and X installed, ensure MTop is set, and
use:
imake -I{MTOP}/config -DUseInstalled
3. With both Motif and X installed, and a nonstandard ProjectRoot (see
site.def for an explanation of this), use:
imake -DUseInstalled -DUseInstalledMotif -I{ProjectRoot}/lib/X11/config
or, if the configuration files are in /usr/lib/X11/config:
imake -DUseInstalled -DUseInstalledMotif -I/usr/lib/X11/config
[Thanks to Paul DuBois (dubois@primate.wisc.edu) for correcting this.]
To build a simple Imakefile, remember to include lines like this:
LOCAL_LIBRARIES = XmClientLibs
DEPLIBS = XmClientDepLibs
Or, for a client that uses uil/mrm, replace these by MrmClientLibs and
MrmClientDepLibs, and also use:
MSimpleUilTarget(program)
to build the client and uid file. Look at the demos for more examples.
And Paul Howell <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: 318) How do I use imake with Motif 2.0?
[Last modified: July 96]
Answer: Paul DuBois (dubois@primate.wisc.edu), the author of the O'Reilly and
Associates book, Software Portability with imake, recently wrote some notes on
the use of imake to configure Motif (2.0). It has some discussion on the roles
of UseInstalled and UseInstalledMotif, for instance, which seem to be murky to
many people. The document is available at:
http://www.primate.wisc.edu/software/imake-stuff
-----------------------------------------------------------------------------
Subject: 319) How do I make context sensitive help? The Motif Style Guide
says that an application must initiate context-sensitive help by changing the
shape of the pointer to the question pointer. When the user moves the pointer
to the component help is wanted on and presses BSelect, any available context
sensitive help for the component must be presented, and the pointer reverts
from the question pointer.
[Last modified: August 92]
Answer: A widget that gives context sensitive help would place this help in
the XmNhelpCallback function. To trigger this function: (from Martin G C
Davies, mgcd@se.alcbel.be)
I use the following callback that is called when the "On Context" help
pulldown menu is selected. It does the arrow bit and calls the help callbacks
for the widget. It also zips up the widget tree looking for help if needs be.
I don't restrict the arrows motion so I can get help on dialog boxes. No
prizes for guessing what "popup_message" does.
static void ContextHelp(
Widget w ,
Opaque * tag ,
XmAnyCallbackStruct * callback_struct
)
{
static Cursor context_cursor = NULL ;
Widget context_widget ;
if ( context_cursor == NULL )
context_cursor = XCreateFontCursor( display, XC_question_arrow ) ;
context_widget = XmTrackingLocate( top_level_widget,
context_cursor, FALSE ) ;
if ( context_widget != NULL ) /* otherwise its not a widget */
{
XmAnyCallbackStruct cb ;
cb.reason = XmCR_HELP ;
cb.event = callback_struct->event ;
/*
* If there's no help at this widget we'll track back
up the hierarchy trying to find some.
*/
do
{
if ( ( XtHasCallbacks( context_widget, XmNhelpCallback ) ==
XtCallbackHasSome ) )
{
XtCallCallbacks( context_widget, XmNhelpCallback, & cb ) ;
return ;
}
else
context_widget = XtParent( context_widget ) ;
} while ( context_widget != NULL ) ;
}
popup_message( "No context-sensitive help found0or the selected object." ) ;
}
Dave Bonnett suggested, to use the following translations for XmText (and
XmTextField) widgets to get the same help with key strokes, and to provide an
accelerator label in the Context help menu entry.
MyApp*XmText*translations: #override\n\
<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: 320) 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: 321) Why can't I install my own colormap using XInstallColormap?
[Last modified: Nov 96]
Answer: You shouldn't install the colormap yourself using XInstallColormap.
See the ICCCM document for all the reasons. Instead put the colormap as an
argument on the Shell widget and the window manager will take care of this.
When the colormap is installed, unless you have a display with multiple
colormaps, the other windows will go "technicolor" and there is no way around
this problem.
Thanks to Doug Rand (drand@sgi.com)
Kenton Lee (http://www.rahul.net/kenton/) adds: Use XtSetWMColormapWindows()
to specify non-default colormaps.
-----------------------------------------------------------------------------
Subject: 322) How do I install a private colormap?
[Last modified: Jan 96]
Answer: Mark Buser (buser@tartan.com) writes: If you find that your
XAllocNamedColor is failing or XpmCreatePixmapFromData is dieing from
XpmColorFaileds, you may have exhausted the number of colormap entries. One
way to install a new colormap is the following:
Toplevel = XtVaAppInitialize ( &app, ...
dpy = XtDisplay (Toplevel);
cmap = DefaultColormapOfScreen ( XtScreen( Toplevel) );
/* Detect color errors due to colormap depletion */
if (colors_depleted) {
cmap = XCopyColormapAndFree ( dpy, cmap );
/* Run through color allocation again to see if ok now */
}
/* Install colormap into toplevel widget. This must be done
** before any child widgets are created.
*/
XtVaSetValues ( Toplevel, XmNcolormap, cmap, NULL);
/* Create any children of toplevel, they will inherit new colormap */
This is only one way to go, there are other possibilities, but this seems to
be the simplest.
-----------------------------------------------------------------------------
Subject: 323) How do I get correct shadow colors to match other color
changes?
[Last modified: Sept 95]
Answer: Thanks to Craig MacFarlane (craigm@chateau-rouge.ICS.UCI.EDU) for the
following explanation and code:
You have to make a call to calculate the new shadow colors. The trick is
actually getting a value of type Pixel when all you have is the string "Blue".
I use the XtConvertAndStore() function to convert from a char * to a Pixel.
For example:
char *color = "blue";
XrmValue color_value, pixel_value;
Pixel background;
color_value.size = strlen(color);
color_value.addr = (XtPointer) color;
pixel_value.size = sizeof(Pixel);
pixel_value.addr = (XtPointer) 0;
result = XtConvertAndStore(widget,
XtRString, &color_value,
XtRPixel, &pixel_value);
background = (*(Pixel *)pixel_value.addr);
You can then use the pixel value obtained by XtConvertAndStore() in the
XmGetColors call. XmGetColors calculates appropriate foreground, topshadow,
bottomshadow, and select colors for the given background. e.g.
XmGetColors(screen,
DefaultColormap(display_id, DefaultScreen(display_id)),
background,
&foreground, &topshadow, &bottomshadow, &select);
Then it's trivial to set the shadow colors at the same time you set the
foreground and background colors. For example:
XtVaSetValues(widget,
XmNforeground, foreground,
XmNbackground, background,
XmNarmColor, select,
XmNtopShadowColor, topshadow,
XmNbottomShadowColor, bottomshadow,
NULL);
You'll get asthetically pleasing colors every time. :)
Wolfram Gries <1gries@informatik.uni-hamburg.de> adds:
The function XmChangeColor() takes a Widget and a Pixel-value for the new
background-color and does the calculation of the new shadow-colors on its own.
But it seems to me that this function is rather slow, so if you often change
the color of your widgets, the XmGetColors()/XmSetColors() approach might be
better.
-----------------------------------------------------------------------------
Subject: 324) What color algorithm does Motif use? I am told that Motif uses
some sort of algorithm that will take a single color that is defined for the
"background" and scale it so that the widget remains discriminable from the
background, etc. What is the algorithm?
[Last modified: Oct 94]
Answer: Chris Flatters (cflatter@nrao.edu) writes: Shiz Kobara's book "Visual
Design with OSF/Motif", Addison Wesley, 1991, ISBN 0-201-56320-7) is a good
source for information of this sort. I haven't seen it in bookshops for a
while so it may have gone out of print (which would be a pity). In essence
each widget has 4 colours which, to first order, are
background
select (background * 85%)
top shadow (background * 150%)
bottom shadow (background * 50%)
An additional correction may be applied to the hues of the calculated colours
if any of the RGB values saturates. The algorithm works best if the brightest
of the RGB components lies in the range 155-175 (on a scale of 0-255). The
top shadow becomes darker than the background for light background colours
which does not lead to a particularly pleasing effect.
-----------------------------------------------------------------------------
Subject: 325) How can you access the superclass widget from which Motif
convenience dialogs are subclassed?
[Last modified: Oct 94]
Answer: Kim Frei (uunet!ask.uniras.dk!kimf) wrote: If you are using Motif 1.2,
read about XmTemplateDialog.
-----------------------------------------------------------------------------
Subject: 326) Can the Motif 2.0 Notebook widget display non-rectangular "file
tabs"? Is it possible to use the Shape extension to fiddle with the shape of
the major tabs (XmPushButtons right now) to get non-rectangular buttons, going
for that "file tab" look?
[Last modified: May 95]
Answer: Vania Joloboff <uunet!gr.osf.org!vania> wrote:
On the Motif 2.0* CD-ROM, in the demos directory, there is a library of
additional widgets lib/Exm. Among the widgets, there is a ExmTabButton
especially designed to fit within a Notebook. It has a smooth shape like real
tabs in folders.
It also a good example on how to use the new traits and the Xme API for widget
writers.
(Thanks to Ken Lee, http://www.rahul.net/kenton/, for a correction here.)
-----------------------------------------------------------------------------
Subject: 327) How does the clipboard mechanism work?
[Last modified: Dec 94]
A. Doug Rand <drand@sgi.com> writes:
Basically there are two selections CLIPBOARD_MANAGER and CLIPBOARD which are
used. The Motif clipboard is not a clipboard manager, but xclipboard, or a
more functional clipboard client would be. The newest ICCCM (2.0) spells this
out.
The basic process is that the clipboard manager:
1) Check to see if CLIPBOARD_MANAGER is owned by anyone, abort if it is.
2) Assert ownership of CLIPBOARD_MANAGER and CLIPBOARD
3) When the CLIPBOARD selection is lost, query new owner for data and then
retake ownership of CLIPBOARD
#3 is done until the application exists. What you do with the data is up to
the application.
-----------------------------------------------------------------------------
Subject: 328) Why does the xyz application core dump when I cut and paste?
Answer: Application crashes when text is cut and pasted into an XmText widget
may occur with statically linked executables linked with X11R5 libraries under
SunOS. For example, a Netscape README file says:
The SunOS 4.1 [Netscape 0.94] distribution also includes a directory called
"nls". This directory is a standard part of the MIT X11R5 distribution, but
is not included with OpenWindows 3.0 or earlier. We have linked Netscape
against the MIT R5 libraries because they are less buggy in general; however,
they have one rather serious bug, which is that if this "nls" directory does
not exist, the program will dump core any time you try to paste into a text
field!
So, if you don't have the "nls" directory on your system, you will need to
install it first. The usual place is /usr/lib/X11/nls, but you can put it
anywhere: just point the $XNLSPATH environment variable at it.
Some sites don't have their X libraries installed in /usr/lib/X11/. This
doesn't matter. You either need to put the nls directory in /usr/lib/X11/, or
every user will need to set this environment variable.
So, for example, we do:
setenv XNLSPATH /usr/local/x11r5/lib/X11/nls
since our X11R5 is not installed in the default location.
-----------------------------------------------------------------------------
Subject: 329) Why is XtWindow(widget) == 0?
[Last modified: Oct 95]
Answer: The window is not created (and is NULL) until the widget is realized.
In general, using XtWindow() is a bad idea. In most cases, you can create
more robust code by subclassing the widget and putting your window code in new
wiget class methods.
Ken Lee
-----------------------------------------------------------------------------
Subject: 330) How do I debug X protocol errors (e.g., BadWindow, BadMatch) in
Motif applications?
[Last modified: Jun 98]
Answer: For a general tutorial on X protocol errors, see:
http://www.rahul.net/kenton/perrors.html
Here are two common problems. First, if you get a BadWindow error showing a
0x0 window ID, you're probably calling XtWindow() on a widget that is not
realized. See the previous subject.
Second, a BadMatch error often indicates that the depth of a window or a
pixmap is not correct. You could be using a depth 1 pixmap when you should be
using a pixmap with the depth of the associated window. Or, you could be
creating a new shell with a depth that does not match its visual type or
colormap.
Ken Lee
-----------------------------------------------------------------------------
Subject: 331) Why doesn't XtNameToWidget (widget, "MyName") work?
[Last modified: Apr 95]
Answer: The second argument must be a qualified specification (like a resource
specification). In most cases, you'll use something like "*MyName". The
leading '*' is required.
Ken Lee
-----------------------------------------------------------------------------
Subject: 332) Why does my callback's client data structure contain incorrect
values when the callback is called? I created a structure and used a pointer
to it as callback client data.
[Last modified: Apr 95]
Answer: If your structure is declared as automatic, the callback will probably
not be executed within the structure's scope, so the pointer to the structure
will become invalid. You can avoid this problem by declaring your structure
external or by allocating with malloc or (in C++) new.
Ken Lee
-----------------------------------------------------------------------------
Subject: 333) How can an application manage events on multiple displays?
[Last modified: May 95]
Answer: Just put multiple display pointers into one application context. (You
normally specify which application context as an argument to XtOpenDisplay()).
XtAppNextEvent() and XtAppMainLoop() automatically poll all displays in the
application context.
Ken Lee
-----------------------------------------------------------------------------
Subject: 334) Can a Motif application create windows on mutiple screens (on a
multi-screen workstation)?
[Last modified: Sep 97]
Answer: Multiple screens is simpler than multiple displays, since one X server
controls all of the screens. Simply specify the XmNscreen resource when you
create your top level (or other) shell widget and the X Toolkit will create
the shell on that screen. You should generally also explicitly set your
XmNcolormap, XmNdepth, and XmNvisual resources for the new shell, since the
defaults may not be valid on the second screen.
Ken Lee
-----------------------------------------------------------------------------
Subject: 335) Why do I get "Error: attempt to add non-widget child "dsm" to
parent"?
[Last modified: May 95]
Answer: Most likely, you are linking your libraries in the wrong order. You
must link -lXm *before* -lXt.
Ken Lee
Ken Sall (ksall@cen.com) adds: This same error occurs if you combine Motif and
Athena widgets in the same application. If you link with "-lXaw" before "-
lXm", you get the runtime error. However, if you switch the order of the two
libraries, there is no problem. For example:
cc mothena.c -o mothena -lXm -lXaw -lXt -lXmu -lX11
-----------------------------------------------------------------------------
Subject: 336) Why do I get link errors about "XShape" symbols?
[Last modified: May 95]
Answer: You must link with the X extensions library, -lXext, after any widget
libraries. For example,
cc -o myapp myapp.o -lXm -lXt -lXext -lX11
Ken Lee
-----------------------------------------------------------------------------
Subject: 337) Why do I get link errors about "ICE" and "SM" symbols?
[Last modified: Sep 97]
Answer: You must link with the the X ICE and/or SM libraries. For example,
cc -o myapp myapp.o -lXm -lXt -lXext -lICE -lSM -lX11
Ken Lee
-----------------------------------------------------------------------------
Subject: 338) Why does my X11R6 program crash with undefined symbol
"LowerCase"?
[Last modified: May 95]
Answer: If you are using Motif version 1.1.[123], then the problem may be a
failure to set MotifBC to YES in your site.def.
Thanks to Geoffrey Leach, geoff@netcom.com
-----------------------------------------------------------------------------
Subject: 339) How do I programatically control xwd to dump a specific window?
I need a non-interactive way to tell xwd what X window to make an image of...
NOT by the traditional point-and-click method.
[Last modified: July 95]
Answer: Ken Sall (ksall@cen.com) wrote:
1. Get the window id of the toplevel shell widget using the "XtWindow"
function.
2. Invoke "xwd" from the program that has access to the window id, such as:
Window dumpId; /* returned from XtWindow */
sprintf (cmd_string, "xwd -frame -out tmp.xwd -id 0x%x", dumpId);
system (cmd_string);
-----------------------------------------------------------------------------
Subject: 340) How can I display an xwd in a window (without using xwud)?
[Last modified: Sept 95]
Answer:
1. read the xwd file into an XImage
2. create a pixmap and XPutImage the image into the pixmap
3. use the pixmap as the XmNlabelPixmap of a label widget
Ken Lee
-----------------------------------------------------------------------------
Subject: 341) Can I write a multi-threaded Motif application?
[Last modified: May 97]
Answer: Motif 2.1 can be compiled to be thread-safe (if libX11 and libXt are
also compiled to be thread-safe).
Motif releases prior to Motif 2.1 were not thread-safe. In these releases,
you can use Motif from one thread and do other things in other threads but you
cannot call Motif functions from more than one thread.
Try looking in the X FAQ for information on threads:
http://www.cis.ohio-state.edu/hypertext/faq/usenet/x-faq/top.html
ftp://ftp.x.org/contrib/faqs/FAQ
Ken Lee
-----------------------------------------------------------------------------
Subject: 342) How can I dump my widget instance tree in a way that reflects
the hierarchy?
[Last modified: July 97]
Answer: Jeremy Jameson (jameson@drmail.dr.att.com) posted this code to c.w.x.m
in 5/95.
[Note: this code does not consider popup children, which are not listed in
the XmNchildren array. To find those, you have to peek at the popup_list in
core widget record. - K.Lee 7/97]
/*******************************************************************************
* dumpWidgetTree( Widget w )
*
* This function will recursively descend throught the Widget tree
* and print the children and their pointer addresses.
*
* Jeremy Jameson 5/17/95
*
*******************************************************************************/
static void dumpWidgetTree( Widget w )
{
WidgetList list = NULL;
Cardinal num_children = 0;
int i;
static int n = 0;
Widget child;
static char* indent =
"-----------------------------------------------------------------------------";
char tmp[256];
*tmp = ' ';
if ( n >= strlen( indent ) +1 )
{
printf(
"ERROR:Widget tree is too deep, not enough indent string ( < %d )!\n",
n );
n = 0;
return;
}
strncpy( tmp, indent, n );
tmp[n] = ' ';
printf( "%s> Dumping widget tree of %s - %#x \n", tmp, XtName( w ), w );
if ( ! XtIsComposite( w ) )
{
printf(
"%s> %s is not a subclass of Composite and therefore has no children\n",
tmp, XtName( w ) );
return;
}
XtVaGetValues( w,
XmNchildren, &list,
XmNnumChildren, &num_children,
NULL );
printf( "%s> %s has %d %s\n", tmp, XtName( w ),
num_children, num_children == 1 ? "child" : "children" );
for ( i = 1; i <= num_children; i++ )
{
child = list[i-1];
printf( "%s> child %2d %20s \t (%#x)\n", tmp, i, XtName( child ), child );
}
printf( "\n" );
for ( i = 1; i <= num_children; i++ )
{
child = list[i-1];
n += 3;
dumpWidgetTree( child );
n -= 3;
}
printf( "\n" );
}
-----------------------------------------------------------------------------
Subject: 343) How do I get the events for gadgets? Or the name of the gadget?
[Last modified: July 96]
Answer: Get events from the gadget's parent. Ken Lee
A related question is "How the name of a gadget an event is directed to?"
Daniel Dardailler (daniel@x.org) writes:
Motif 2.0 provides a XmObjectAtPoint public function that support this
functionality. For earlier version, something like the undocumented
_XmInputInGadget( wid, x, y ) should do it.
_XmInputInGadget
Given a composite widget and an (x, y) coordinate, see if the
(x, y) lies within one of the gadgets contained within the
composite. Return the gadget if found, otherwise return NULL.
-----------------------------------------------------------------------------
Subject: 344) Can I set the foreground and background colors of gadgets
(e.g., convenience dialog buttons)?
[Last modified: Nov 96]
Answer: Not in Motif 1.x. Gadgets don't have their own colors, they use those
of their parents. Notice that Motif's convenience dialogs generally use label
gadgets, not widgets, so you cannot customize the colors of individual
buttons.
Beginning in Motif 2.0, gadgets do have their own color resources.
Ken Lee
-----------------------------------------------------------------------------
Subject: 345) Can I use a gadget as the parent of a dialog shell?
[Last modified: Dec 97]
Answer: No. The Core widget class contains the functionality for popup
children. Since the Gadget class is not a subclass of Core, gadgets cannot
have popup children (like dialogs).
-----------------------------------------------------------------------------
Subject: 346) Which other widget features do gadgets lack?
[Last modified: Dec 97]
Answer: Here's a list from Asente & Swick (p. 397). Note that many of these
restrictions are primarily of interest to widget (and gadget) writers, not to
application writers.
1. gadgets have no background or border colors or pixmaps
2. gadgets cannot have event handlers
3. gadgets have no translations, accelerators, or actions
4. gadgets cannot have pop-up children
5. gadgets cannot do grabs
6. gadgets cannot redirect the Intrincis keyboard focus or take the X focus
7. gadgets cannot own or request selections
8. gadgets do not need to be and cannot be realized
9. gadgets cannot have their window, display, or screen queried (but
there are separate functions for computing these)
10. gadgets have no stacking order
-----------------------------------------------------------------------------
Subject: 347) Where can I get the xmon or xscope programs to trace my X
protocol?
[Last modified: Mar 96]
Answer: Both are included in the contrib section of X11R5:
ftp://ftp.x.org/pub/R5/
Xmon is also available at: ftp://ftp.x.org/contrib/devel_tools/ and
ftp://ftp.crl.research.digital.com/pub/X11/contrib/devel_tools/
Ken Lee
-----------------------------------------------------------------------------
Subject: 348) What does the error "Couldn't find per display information"
mean?
[Last modified: Mar 96]
Answer: Xt often needs information about the current X display. It generates
this error when it couldn't find the display pointer. Common causes
applications accidentally destroying widgets twice or trying to generate fake,
incomplete events with XSendEvent().
Ken Lee
-----------------------------------------------------------------------------
Subject: 349) Can I set widget fallback resources after I've called
XtAppInitialize()?
[Last modified: Mar 96]
Answer: No. Fallbacks are only checked when displays are initialized.
Ken Lee
-----------------------------------------------------------------------------
Subject: 350) Can I use the newline character in widget names?
[Last modified: Mar 96]
Answer: No. Widget names are designed to be used in resource specifications.
The Xlib resource file syntax says the only alphanumeric characters (plus '-'
and '_') may be used in a resource component name. If you want more than one
line of text in a label widget, set the XmNlabelString resource.
Ken Lee
-----------------------------------------------------------------------------
Subject: 351) Is anybody out there selling Windows95 look-alike widgets? Why
isn't there a Widget builder for Motif/X yet? Something like OCX (I believe on
Windows95).
[Last modified: Mar 96]
Answer: David B. Lewis (dbl%craft@uunet.uu.net) writes:
None that I know of. There are similar widgets available in Motif 2.0. There
are similar widgets available in the ICS EnhancementPak.
[For the second part of the question...] Because it's very hard to do. I don't
know what OCX is, but I can't imagine that the technology is so much better
than that used in Xt that it's possible to write something to generate real
code. It's trivial, of course, to generate the framework for a widget given
only its name, superclass, and resources; but everything else is real code.
-----------------------------------------------------------------------------
Subject: 352) How can I convert my OLIT programs to the Motif look & feel?
[Last modified: July 96]
Answer: Mark Fresolone (mjf@mjm.com) writes: There are a number of translator
products on the market which translate OLIT source code or DevGuide builder
files into Motif source code and builder files.
In 1995, MJM Software (Melillo Consulting Inc.) released the MoOLIT 5.1
toolkit, which allows one to simply re-compile Sun or UnixWare OLIT programs,
and have them be switchable between the OPENLOOK and Motif look and feels.
MoOLIT 5.1 is available on most popular UNIX platforms. More information is
available at:
http://www.mjm.com/Products/MoOLIT
-----------------------------------------------------------------------------
Subject: 353) Where can I obtain X and Motif applications?
[Last modified: Sep 97]
Answer: Several product lists are available from "MW3: Motif on the World Wide
Web":
http://www.cen.com/mw3/commercial.html
MW3: Commercial Products and Vendors
http://www.cen.com/mw3/non-commercial.html
MW3: Non-Commercial Applications and Shareware
http://www.cen.com/mw3/vendors.html
MW3: Motif Vendor List
Brandon Harris has an impressive collection of apps (commercial and non-
commercial) in various categories:
http://www.gaijin.com/X/x.apps.html
X Applications:
DateBooks, Development, Editors, File Management, Games,
Graphics, Mail, Miscellaneous, Office and Finance, Utilities,
WebBrowsers, Window Managers.
The Open Group Open maintains a list of products at:
Open Software Registry
http://www.opensoftware.com/
Two other comp.windows.x.* FAQs have long lists of available tools:
http://www.ee.ryerson.ca:8080/~elf/xapps/faq.html
comp.windows.x.apps FAQ
and the topic "OBTAINING X AND RELATED SOFTWARE AND HARDWARE" in the X FAQ:
http://www.cs.ruu.nl/wais/html/na-dir/x-faq/part3.html
-----------------------------------------------------------------------------
Subject: 354) What does this mean: Warning: Cannot find callback list in
XtAddCallback?
[Last modified: July 96]
Answer: It means that you gave an invalid callback name to XtAddCallback,
e.g., using XmNactivateCallback when the widget does not have a callback with
that name.
Ken Lee
-----------------------------------------------------------------------------
Subject: 355) If a single widget has multiple callback functions, are they
all executed? If so, in what order?
[Last modified: Nov 96]
Answer: Yes, they are all executed. The order, however, is not defined by the
X Toolkit specifications. If you really want a certain order, you should
register a single callback function and have it call your other functions in
the order you want.
Ken Lee
-----------------------------------------------------------------------------
Subject: 356) Why are some widgets still visible after I call
XtDestroyWidget() on them?
[Last modified: Nov 96]
Answer: To avoid memory corruption problems, the X Toolkit uses a 2 phase
destroy process. When you call XtDestroyWidget(), the widgets are not really
destroyed until after you return to the Xt main loop. Until then, the widget
will behave (mostly) as if they were not destroyed. If this is a problem, you
should unmanage them as well (you can safely unmanage them after you destroy
them and before you return to the main loop).
Ken Lee
Note: The details of the two-phase destruction are described on the
XtCreateWidget(3Xt)/XtDestroyWidget(3Xt) man page. - ksall@cen.com
-----------------------------------------------------------------------------
Subject: 357) If I call XtGetValues on a resource that does not exist for a
given widget, what value is returned?
[Last modified: Nov 96]
Answer: No value is returned. Your return variable is not modified. If it
was uninitialized (i.e., garbage) before the call to XtGetValues, it will
remain uninitialized.
Ken Lee
-----------------------------------------------------------------------------
Subject: 358) Can I reparent a widget (change its parent)?
[Last modified: Aug 97]
Answer: Xt does not support reparenting of widgets within the widget
hierarchy. This would complicate the hierarchical resource model. You can
destroy the old hierarchy and create a new one. On most systems, this is
pretty fast for reasonably sized widget hierarchies.
Note, however, that X11R6.3 provides an "application group" extension that
allows one X client to act as the root of another X client's window hierarchy.
See the X11R6.3 documentation for more details.
Ken Lee
-----------------------------------------------------------------------------
Subject: 359) Are there any "year 2000" issues within Motif?
[Last modified: Jun 98]
Answer: According to
http://www.camb.opengroup.org/tech/desktop/faq/y2k.htm
Dear Customer:
The Open Group has completed a review of Motif (OSF/Motif) and the X Window
System with regard to Year 2000 issues, and has determined that Motif
(versions 1.0 through 2.1) and X Window System (X11 Releases 5 through 6.4)
source code, as provided directly by The Open Group (or, previously provided
by Open Software Foundation, Inc.; or X Consortium in the case of X Window
System) does not contain any date-dependent source code. The arrival of the
year 2000 should have no effect on the operation of Motif or X Window System
source code.
Please note, however, that Motif & X Window System object code or
applications, or derivative works thereof, which would have been provided to
you by a third party, are not covered by the above statement. You are hereby
referred to your supplier for statements regarding Year 2000 issues for such
third-party products.
Very truly yours,
The Open Group
-----------------------------------------------------------------------------
Subject: 360) Can I suppress or customize Motif warning and error messages?
[Last modified: Aug 97]
Answer: A better idea is usually to fix problems indicated by the messages.
If you must, Motif justs uses Xt's message system which can be customized with
XtAppSetWarningHandler and XtAppSetErrorHandler.
-----------------------------------------------------------------------------
Subject: 361) TOPIC: Motif FAQ HISTORY and ACKNOWLEDGEMENTS
[Last modified: April 97]
Answer:
History:
-------
November 89 to July 93: FAQ was maintained by Jan Newmarch
(jan@ise.canberra.edu.au)
July 93 to August 94: FAQ was maintained by Brian Dealy
(dealy@c3i.saic.com)
Sept. 94 to April 97: FAQ was maintained by Ken Sall
(ksall@cen.com)
beginning April 97: FAQ was maintained by Kenton Lee
(http://www.rahul.net/kenton/)
Acknowledgments:
----------------
This list was compiled using questions and answers posed to
comp.windows.x.motif and motif-talk. Some information was excerpted from the
comp.windows.x FAQ. To all who contributed one way or the other, thanks! We
try to give individual references, but you may recognize something uncredited
as your contribution. If we've mangled the words (or, heaven forbid, the code)
too much, let the current maintainer know.
NOTE: If you are a two-or-more-time contributor to this FAQ and you have a WWW
personal home page which you'd like to have listed, see the subject: "Which X
and Motif developers have their own home page URLs?"
Jan Newmarch, Information Science and Engineering,
University of Canberra, PO Box 1, Belconnen, Act 2616
Australia. Tel: (Aust) 6-2522422. Fax: (Aust) 6-2522999
ACSnet: jan@ise.canberra.edu.au
ARPA: jan%ise.canberra.edu.au@uunet.uu.net
UUCP: {uunet,ukc}!munnari!ise.canberra.edu.au!jan
JANET: jan%au.edu.canberra.ise@EAN-RELAY
Jan Newmarch maintained this FAQ for a long time and has really helped a great
many of us by providing this valuable service. He deserves a big round of
applause for his efforts. I use this resource all the time and it has saved
me countless hours with manuals and source code trying to relearn what others
have already discovered. Jan`s efforts are gratefully acknowledged here.
Brian Dealy, SAIC
dealy@c3i.saic.com
Likewise, Brian Dealy of SAIC did an admirable job taking over the Motif FAQ
from Jan. A considerable amount of information was added during his tenure and
we greatly appreciate Brian's work on the FAQ, as well as his efforts in
maintaining the comp.windows.x.motif newsgroup reflector, for the good of all
Motif-dom.
Ken Sall
ksall@cen.com
Tel: (301) 953-3330 FAX: (301) 953-2368
Century Computing, Inc.
http://www.cen.com/
And thanks to Ken Sall for maintaining the FAQ for the last 3 years. During
Ken's tenure the FAQ more than doubled in size. Ken was one of the first FAQ
maintainers to change all ftp references to URLs and to incorporate http URLs
thoroughout the FAQ. This effort motivated him to create the Motif on the
World Wide Web site (http://www.cen.com/mw3/) which contains hundreds of Motif
links.
Kenton Lee
X/Motif Consultant
kenton@nojunk.rahul.net
http://www.rahul.net/kenton/