home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Usenet 1994 October
/
usenetsourcesnewsgroupsinfomagicoctober1994disk1.iso
/
answers
/
motif-faq
/
part4
< prev
next >
Wrap
Text File
|
1993-10-25
|
61KB
|
1,425 lines
Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!medusa.hookup.net!news.kei.com!sol.ctr.columbia.edu!howland.reston.ans.net!pipex!uunet!haven.umd.edu!news.umbc.edu!cs.umd.edu!kong.gsfc.nasa.gov!vilya.gsfc.nasa.gov!not-for-mail
From: dealy@kong.gsfc.nasa.gov (Brian Dealy)
Newsgroups: news.answers,comp.answers
Subject: Motif FAQ (Part 4 of 5)
Followup-To: poster
Date: 25 Oct 1993 16:09:45 -0400
Organization: NASA/Goddard Space Flight Center
Lines: 1404
Sender: dealy@vilya.gsfc.nasa.gov
Approved: news-answers-request@MIT.Edu
Expires: +1 months
Message-ID: <2ahbq9$10n@vilya.gsfc.nasa.gov>
Reply-To: dealy@kong.gsfc.nasa.gov (Brian Dealy)
NNTP-Posting-Host: vilya.gsfc.nasa.gov
Keywords: FAQ question answer
Archive-name: motif-faq/part4
Last-modified: Oct 15 1993
Version: 3.6
Xref: senator-bedfellow.mit.edu news.answers:13925 comp.answers:2410
-----------------------------------------------------------------------------
Subject: 95) TOPIC: XMSTRING
-----------------------------------------------------------------------------
Subject: 96) 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: 97) 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: 98) 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: 99) Why does using XmStringDraw cause a Bad Font error?
[Last modified: May 93]
Answer: From Thomas Berlage (berlage@gmdzi.gmd.de): You could call this a bug
in Motif. You pass a GC to XmStringDraw, however, Motif wants to use the fonts
from the font list to draw the string. Therefore it replaces the font of the
GC temporarily with some fonts of its own as specified in the font list. In
the end it tries to restore the old font of the GC. There comes the problem:
If a GC uses the default font, the client side GC structure does not have a
valid font id (that is the 0xffffffff you may see in the error message). Motif
tries to restore this invalid id at the end.
The workaround is: Before drawing with XmStringDraw, set the font id of the GC
to any valid font id, for example using
XSetFont (display, gc, XLoadFont (display, "fixed"));
-----------------------------------------------------------------------------
Subject: 100) TOPIC: DIALOGS
-----------------------------------------------------------------------------
Subject: 101) 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: 102) 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);
-----------------------------------------------------------------------------
Subject: 103) How come the title bars for my dialogs now have "_popup" or
"<-popup" concatenated onto the widget name?
Answer: Motif 1.0.3 (?) "fixed" things such that title bars without an
explicit dialogTitle setting use the widget name with "_popup" or whatever
added on. Set the dialogTitle resource explicitly if you don't want this new
default naming scheme.
-----------------------------------------------------------------------------
Subject: 104) How can I force a dialog window to display? I manage a
"working" dialog, and do some computing, but the dialog window appears blank
until the work has finished. How can I force it to be displayed?
Answer: Use this. (David Brooks, Systems Engineering, Open Software
Foundation)
/*
* This procedure will ensure that, if a dialog window is being mapped,
* its contents become visible before returning. It is intended to be
* used just before a bout of computing that doesn't service the display.
* You should still call XmUpdateDisplay() at intervals during this
* computing if possible.
*
* The monitoring of window states is necessary because attempts to map
* the dialog are redirected to the window manager (if there is one) and
* this introduces a significant delay before the window is actually mapped
* and exposed. This code works under mwm, twm, uwm, and no-wm. It
* doesn't work (but doesn't hang) with olwm if the mainwindow is iconified.
*
* The argument to ForceDialog is any widget in the dialog (often it
* will be the BulletinBoard child of a DialogShell).
*/
ForceDialog(w)
Widget w;
{
Widget diashell, topshell;
Window diawindow, topwindow;
Display *dpy;
XWindowAttributes xwa;
XEvent event;
XtAppContext cxt;
/* Locate the shell we are interested in. In a particular instance, you
* may know these shells already.
*/
for (diashell = w;
!XtIsShell(diashell);
diashell = XtParent(diashell))
;
/* Locate its primary window's shell (which may be the same) */
for (topshell = diashell;
!XtIsTopLevelShell(topshell);
topshell = XtParent(topshell))
;
if (XtIsRealized(diashell) && XtIsRealized(topshell)) {
dpy = XtDisplay(topshell);
diawindow = XtWindow(diashell);
topwindow = XtWindow(topshell);
cxt = XtWidgetToApplicationContext(diashell);
/* Wait for the dialog to be mapped. It's guaranteed to become so unless... */
while (XGetWindowAttributes(dpy, diawindow, &xwa),
xwa.map_state != IsViewable) {
/* ...if the primary is (or becomes) unviewable or unmapped, it's
probably iconified, and nothing will happen. */
if (XGetWindowAttributes(dpy, topwindow, &xwa),
xwa.map_state != IsViewable)
break;
/* At this stage, we are guaranteed there will be an event of some kind.
Beware; we are presumably in a callback, so this can recurse. */
XtAppNextEvent(cxt, &event);
XtDispatchEvent(&event);
}
}
/* The next XSync() will get an expose event if the dialog was unmapped. */
XmUpdateDisplay(topshell);
}
-----------------------------------------------------------------------------
Subject: 105) How can I control placement of a popup widget? Each time a
popup is created, it is placed in or over the middle of its parent. How can I
make it obey the XmNx and XmNy values?
Answer: Set the resource XmNdefaultPosition for the popup to False. Set the
position of the popup by the resource values of XmNx and XmNy. Do not use
XtMoveWidget, as this is for widget writers only. Here's a demo program from
Dan Heller:
/* Written by Dan Heller. Copyright 1991, O'Reilly && Associates.
* This program is freely distributable without licensing fees and
* is provided without guarantee or warranty expressed or implied.
* This program is -not- in the public domain. This program is
* taken from the Motif Programming Manual, O'Reilly Volume 6.
*/
/* map_dlg.c -- Use the XmNmapCallback to automatically position
* a dialog on the screen. Each time the dialog is displayed, it
* is mapped down and to the right by 200 pixels in each direction.
*/
#include <Xm/MessageB.h>
#include <Xm/PushB.h>
/* main() --create a pushbutton whose callback pops up a dialog box */
main(argc, argv)
char *argv[];
{
Widget toplevel, button;
XtAppContext app;
void pushed();
toplevel = XtVaAppInitialize(&app, "Demos",
NULL, 0, &argc, argv, NULL, NULL);
button = XtCreateManagedWidget("button", xmPushButtonWidgetClass,
toplevel, NULL, 0);
XtAddCallback(button, XmNactivateCallback, pushed, "Hello World");
XtRealizeWidget(toplevel);
XtAppMainLoop(app);
}
/* callback function for XmNmapCallback. Position dialog in 200 pixel
* "steps". When the edge of the screen is hit, start over.
*/
static void
map_dialog(dialog, client_data, cbs)
Widget dialog;
XtPointer client_data;
XmAnyCallbackStruct *cbs;
{
static Position x, y;
Dimension w, h;
XtVaGetValues(dialog, XmNwidth, &w, XmNheight, &h, NULL);
if ((x + w) >= WidthOfScreen(XtScreen(dialog)))
x = 0;
if ((y + h) >= HeightOfScreen(XtScreen(dialog)))
y = 0;
XtVaSetValues(dialog, XmNx, x, XmNy, y, NULL);
x += 200, y += 200;
}
/* pushed() --the callback routine for the main app's pushbutton.
* Create and popup a dialog box that has callback functions for
* the Ok, Cancel and Help buttons.
*/
void
pushed(w, message)
Widget w;
char *message; /* The client_data parameter passed by XtAddCallback */
{
Widget dialog;
Arg arg[3];
XmString t = XmStringCreateSimple(message);
extern void response();
XtSetArg(arg[0], XmNautoUnmanage, False);
XtSetArg(arg[1], XmNmessageString, t);
XtSetArg(arg[2], XmNdefaultPosition, False);
dialog = XmCreateMessageDialog(w, "notice", arg, 3);
XmStringFree(t);
XtAddCallback(dialog, XmNmapCallback, map_dialog, NULL);
XtManageChild(dialog);
XtPopup(XtParent(dialog), XtGrabNone);
}
-----------------------------------------------------------------------------
Subject: 106) TOPIC: LANGUAGE BINDINGS
-----------------------------------------------------------------------------
Subject: 107) Is there a C++ binding for Motif?
[Last modified: May 93]
Answer: WWL is a library which defines C++ classes around X Toolkit Widgets.
It is intended to simplify the task of C++ code writers when using the Toolkit
by providing them with C++ objects, methods, type checking and several utility
functions and classes.
WWL has been tested under SunOs4.0.3 on sun3 and sun4, HPUX version 6.5 and
7.0 and Ultrix 4.0 on DECstation 3100 and 5000. It is expected to work on most
other UNIX systems without too many problems.
WWL is distributed as a tar file with all the source, documentation and
example. The file is available using anonymous ftp from
export.lcs.mit.edu (18.30.0.238 contrib/WWL-1.0.tar.Z
lri.lri.fr (129.175.15.1) pub/WWL-1.0.tar.Z
Answer: Rogue Wave Software has a C++ binding for Motif called View.h++.
"View.h++ is a complete C++ interface to OSF/Motif. It doesn't just
encapsulate it, but also includes a set of classes that provide a level of
abstraction above Motif, thus simplifying menu and dialog creation, XmStrings,
XmFontLists, etc. View.h++ supports a Model- View-Controller architecture,
allowing for an even more object-oriented interface design. Includes a copy
of Rogue Wave's Tools.h++ (foundation class library)"
An object license is $795 "per seat" and a source code license is available
for $2,995 "per seat." Rogue Wave also offers full support for View.h++.
It is currently available for Sun Sparc, IBM RS/6000, HP 9000/700 series, SCO,
Intel SVR4 ESIX. Please call for Silicon Graphics and DEC Ultrix status.
For additional information, please contact:
Matt Steinauer
Rogue Wave Software, Inc.
P.O. Box 2328
Corvallis, OR 97339
Phone: (503)754-3010
Fax: (503)757-6650
email: matts@roguewave.com
Answer: From Andreas.Baecker@gmd.de: The GINA++ application framework contains
an encapsulation of the OSF/Motif widg et classes and the Xt functionality
into C++ classes. Its functionality is comparab le to that of the ULowell
binding and the WWL. Additionally, it provides an easy-to -use framework for
modeling new composite and primitive widget classes, plus an application
framework similar to ET++ or MacApp build on top of it. The binding may be
used independently from the framework classes. GINA++ is available through
anonymous ftp from ftp.gmd.de [129.26.8.90] in the directory /gmd/ginaplus.
Documentation about the Motif binding has been published in the X Resource
Journ al, Number 2, 1992, Pages 106-130. The binding compiles with AT&T C++
2.1 and GNU G+ + 2.1 and has been tested on SunOS 4.1.[12], X11R4 and Motif
1.1.3.
Answer: Motif++ is a library that defines C++ class "wrappers" for the widgets
defined in the OSF/Motif-1.1 widget library. 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++ 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 Univeristy of Lowell. The two latter libraries are the result of much
larger efforts.
Availability:
Anonymous ftp at decuac.dec.com (192.5.214.1), directory /pub/X11,
file motif++.21.jul.92.tar.Z (855293 bytes).
For more information, contact Ronald van Loon (rvloon@cv.ruu.nl) There is also
mailing list for Motif++. Send e-mail to 'motif++-request@cv.ruu.nl' or
'rvloon@cv.ruu.nl'
Answer: From Christian Goeller (goeller@seufert.de): We have a C++-class-
library available. It's based on the Lowell-bindings and the work of Ronald
van Loon (rvloon@cv.ruu.nl) and has a lot of (i hope) useful enhancements like
containers, string-class (with Motif-support) and a graph-object. It should
build completely with imake. You could ftp it from:
Host: ftp.unibw-muenchen.de
File: /pub/Motif-C++/v2.0.tar.Z
Answer: Xm++ is a user interface framework for the C++ language built upon X11
and the X-Toolkit. It is designed to be a simple and intuitive programming
interface to access the functionality of commonly used widgets. Xm++ was
initially created for the Motif widget set, now support for the Athena widgets
was added. Applications created with Xm++ run in both environments without
changes, although many nice features are only available when using Motif.
Xm++ is available on: export.lcs.mit.edu as: /contrib/Xm++.0.5.tar.Z
Answer: The Solbourne OI toolkit (not Motif) also has a C++ binding.
Answer: Liant have C++/Views.
Answer: Quest have ObjectViews.
Answer: 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.
-----------------------------------------------------------------------------
Subject: 108) How can I have a C++ member function in a callback?
[Last modified: October 93]
Answer: There are three common user problems with C++ callbacks. First, make
sure you use the correct function prototype for the function declarations.
Second, the callback function must be declared as a static member of the
class. Third, when registering it with XtAddCallback(), you must use its full
signature. For example: (Ken Lee klee@synoptics.com)
class MyClass {
...
void createWidgets();
static void myButtonCB(Widget, XtPointer, XtPointer);
...
};
void MyClass::createWidgets() {
...
w = XtCreatePushButton(...);
XtAddCallback(w, XmNactivateCallback, &MyClass::myButtonCB,
(XtPointer) this);
...
}
void myButtonCB(Widget w, XtPointer clientData, XtPointer callData) {
MyClass *myclass = (MyClass *) clientData;
...
}
Note that the "this" pointer is used as the client data. This technique is
popular, but not required.
Motif++ has a nice tutorial summarising mechanisms (this is available
separately by email from Ronald van Loon (rvloon@cv.ruu.nl)). Doug Young's
book deals extensively with one of these. The problem is that you don't get
the object when you just use the function as a callback. You need to pass the
object as a pointer through as the client_data. (use "this" as the
client_data.) Then you can retrieve the object's address, and dereference from
there. For example (Leo O'Donnell, Email: leo@avs.com),
class MyButton {
public:
MyButton (Widget parent, const char *name) {
_button = XtVaCreateManagedWidget (
name, xmPushButtonWidgetClass, parent, NULL, 0);
XtAddCallback (
_button,
XmNactivateCallback,
&MyButton::activateCB,
(XtPointer) this);
}
~MyButton () { XtDestroyWidget (_button); }
private:
Widget _button;
static void activateCB (Widget, XtPointer, XtPointer);
};
void MyButton::activateCB (Widget, XtPointer thisBtn, XtPointer)
{
MyButton *btn = (MyButton *) thisBtn;
// OK you've got the button instance now. Do some stuff with it!
}
-----------------------------------------------------------------------------
Subject: 109) Is there a Common Lisp binding for Motif?
[Last modified: November 92]
Answer: Try CLM. This includes a toolkit demon (in C) that takes a widget
description (with callbacks), and forks a new process for each Motif
application (which can be just a single menu, or whatever). Lisp can then
continue running, with a separate lightweight lisp process handling the
connection & callbacks. In North America & net environs, CLM-2.0beta is
available from export.lcs.mit.edu.
There is also CLIM, the Common Lisp Interface Manager. It provides access to
motif and other toolkits and window systems. Here is some blurb: "Version 2.0
of the Common Lisp Interface Manager (CLIM) provides access to Motif. CLIM is
the emerging standard for GUI development in Common Lisp. It offers a set of
high-level facilities that enable rapid construction of user interfaces.
Applications written using CLIM are portable across a variety of window
systems and toolkits. For example, on the X window System, both Motif
(OSF/Motif) and Openlook (OLIT) are supported. CLIM accesses the toolkit
directly rather than emulating the look and feel."
CLIM is available from a variety of Common Lisp vendors including Symbolics
and Franz Inc. (info@franz.com).
-----------------------------------------------------------------------------
Subject: 110) Is there an Ada binding for Motif?
[Last modified: July 93]
Answer:
Information on Ada bindings to Motif and other services (such as SQL and
POSIX) can be found in a document maintained by the Ada Information
Clearinghouse. The report can be found at
host: ajpo.sei.cmu.edu
loc: /public/ada-info/bindings.hlp.*
access: anonymous ftp
The suffix to the file (indicated above with an asterix) is the date of the
latest update to the document. For example, the full name of the report
updated on 14 June 1993 would be
/public/ada-info/bindings.hlp.14Jun93.
The file is ASCII.
------ Included File
[...Excerpted from the AdaIC report bindings.hlp.14Jun93...]
[...Updates can be found on ajpo.sei.cmu.edu, in the ...]
[...file /public/ada-info/bindings.hlp.* The suffix ...]
[...is always the date of the lastest version to the ...]
[...report. ...]
SECTION 12
X-Window System:
OSF Motif and Open Look
Available Ada Bindings
12.1 Description and Standardization Efforts
The X-Window System is a network-transparent window system. It supports one
or more screens containing overlapping windows or subwindows. X display
servers distribute user input to and accept output requests from various
client programs located either on the same machine or elsewhere in the
network.
OSF Motif (Open Software Foundation/Motif) is a graphical user
interface from OSF that provides a Presentation Manager look and
feel for applications running on any system with X Window version
11. It conforms to POSIX, ANSI C and X/Open's XPG3 standards.
12.2 Resources Available from Software Reuse Libraries/Repositories
ASSET (Updated: November
1 992)
The following information was taken in its entirety from the ASSET Library
Repository Catalog, October 9, 1992. For more information on ASSET, see
Appendix C.
INTERFACE TO THE X WINDOW SYSTEM
VERSION_NUMBER : 1.1
DEVELOPED_BY : SAIC
RELEASE_DATE : 29-SEP-88
UNIQUE_IDENTIFIER : ASSET_A_240
ALTERNATE_NAME : SAICX2
ASSET_TYPE : SOFTWARE CODE
FUNCTIONS : INTERFACE, BIND
OBJECTS : ADA, X WINDOWS
KEYWORDS : STANDARDS, BINDINGS
COLLECTION : STARS FOUNDATIONS
DISTRIBUTION : UNLIMITED
DESCRIPTION :
Interface to the X Window System
An expression of the various concepts in Ada that provides a full,
working Ada specification of the X Window system.
Approved for public release; distribution is unlimited.
12.3 Products Available from Vendors
Advanced Technology Center (Updated: November
1 992)
The Advanced Technology Center (ATC) has an Ada binding to OSF Motif for their
AXI~ product. AXI is currently available for most UNIX-based platforms, and
is supported by Verdix, Meridian, and TeleSoft compilers.
AXI is an Ada-to-X-Window System interface that provides the Ada programmer
access to the 500+ functions, libraries, and procedures contained in the X
library (Xlib), the X Toolkit (Xt), the X Extensible Library, the X
Miscellaneous Utilities, the Motif widget set and the Motif Resource Manager.
ATC is planning to develop an Ada binding to Open Look for AXI.
For more information, contact:Larry Paulson, Advanced Technology Center, 22982
Mill Creek Drive, Laguna Hills, CA 92653, USA; Phone:
714-583-9119
Alsys, Inc. (Updated: May
1 992)
The Alsys Ada Software Development Environment (Alsys's validated Ada compiler
#901221W1.11103) for 386 UNIX is a production-quality Ada environment capable
of handling very large Ada applications (over 500,000 lines of code). The
product includes the Compiler; Multi-Library Environment, which provides a
powerful and flexible way to manage Ada development effort and share program
units; Binder, which supports unused subprograms elimination; High-and Low-
Level Optimizers for improving code quality and performance; and Run-Time
Executive for efficient support for executing Ada programs. Also included is
the Developer's Toolset including: Ada Probe, a symbolic source level
debugger and program viewer; AdaXref, a cross-reference generator; AdaMake, a
recompilation aid; AdaReformat, a source reformatter.
Alsys currently has Ada bindings to POSIX, X-Windows (OSF Motif), and the
Generic Package of Elementary Functions for the Alsys Ada Software Development
Environment, running on 386 UNIX 386/486-based machines supported as both host
and target and running 386/ix or SCO UNIX. They are also planning a binding
to SQL for 386/486 machines.
Host/Target:386/486 PC under IX UNIX, 386/486 PC under SCO UNIX
The Alsys Ada Software Development Environment for the IBM RS/6000 is a
production-quality Ada environment capable of handling very large Ada
applications. Hosted on and targeted to the IBM RS/6000 workstation under
IBM's AIX operating system, the product includes the Compiler; Multi-Library
Environment, which provides a powerful and flexible way to manage Ada
development efforts and share program units; Binder; Run-Time Executive; and
both a High and Low-Level Optimizer for improving code quality and
performance. Also included is the Alsys Ada Toolset including Ada Probe,
symbolic source level debugger and program viewer; AdaXref, cross-reference
generator; AdaMake, recompilation aid; and AdaReformat, source reformatter.
Alsys has bindings currently available to the Generic Package of Elementary
Functions and to X-Windows (OSF Motif) for the Alsys Ada Development
Environment for the IBM RS/6000 running on any RISC System/6000 machine as
both host and target and running IBM's AIX operating system (Alsys's validated
Ada compiler #910809W1.11195). Alsys also plans to develop a POSIX binding
for the RS/6000.
Host/Target:RISC System/6000 under AIX
The Alsys Ada Software Development Environment for SPARC Workstations is a
production-quality Ada environment capable of handling very large Ada
applications. Hosted on any SPARC-based workstation under SunOS or SunView,
the product helps you realize the full potential of Ada on SPARC machines. The
product includes the Compiler (with High- and Low-Level Optimizers); Binder,
which supports unused subprogram elimination; Multi-Library system (Family,
Library, and Unit Managers) which provides a powerful and flexible way to
manage Ada development efforts and share program units; AdaExec real-time
executive, for complete and efficient support for executing Ada programs; and
ISO-standard mathematical library. Also included is the Alsys Ada Toolset
including AdaProbe, symbolic source level debugger and program viewer;
AdaXref, cross-reference generator; AdaMake, recompilation aid; and
AdaReformat, source reformatter.
Bindings to the Generic Package of Elementary Functions and to OSF/Motif are
currently available for the Alsys Ada Software Development Environment running
on any SPARC-based Workstation as both host and target and running SunOS or
SunView.
Host/Target:SPARC under SUNOS
For more information, contact:Scott Garren, Alsys, Inc., 67 South Bedford
Street, Burlington, MA 01803-5152, USA; Phone:
(617) 270-0030
Digital Equipment Corporation (Updated: November
1 992)
Digital Equipment Corporation has bindings available for GKS, PHIGS, SQL, and
OSF Motif for VAX Ada/VMS. The Ada bindings are provided either as part of a
compiler product or the services/facilities that are provided by Digital and
its suppliers.
Host/Target:DEC VAX under VMS
For more information, contact:Mary Anne Cacciola, Digital Equipment
Corporation, 110 Spit Brook Road, Nashua, NH 03062,
USA; Phone: (603) 881-1028
IBM (Updated: November
1 992)
IBM's AIX Ada/6000 product provides a binding to GPEF and IBM AIXWindows (X-
Windows ... not Motif). It runs on all models of the IBM RISC System/6000
under the IBM AIX Version 3.2 operating system. See also entries for Systems
Engineering Research Corporation (SERC) and Advanced Technology Center (ATC)
for Motif, GKS or PHIGS bindings for use with IBM AIX Ada/6000 products.
The AIX Ada/6000 licensed programs (5706-291 and 5706-294) consist of an
optimizing compiler, a run-time environment, a symbolic debugger, an Ada
"makefile" generator for use in automating and minimizing recompilation, Ada
library management tools and Ada language bindings to some key AIX subsystems.
With the exception of some system-specific aspects of the language, the Ada
language for the AIX operating system is source compatible with the Ada
language supported by IBM licensed programs in VM/CMS and MVS.
Host/Target:IBM RISC System/6000 under the IBM AIX Version 3.2 operating
system
This product conforms to the following standards: ANSI/MIL-STD-1815A - Ada at
current level (1.11) of the ACVC test suite.
For more information, contact:Barry Lee, IBM Corporation, 844 Don Mills Road,
North York, Ontario, Canada M3C 1V7; Phone: (416)
448-3174; Fax: (416) 448-4810
Objective Interface Systems, Inc. (Updated: November
1 992)
Objective Interface Systems, Inc., has an Ada binding to X-windows (OSF Motif)
for its Screen Machine~ product. The Screen Machine binding to Motif includes
a WYSIWYG drawing tool and an Ada code generator.
Host/Target:
Sun SPARC/SunOS Rational R1000/Delta HP 9000/7XX; 8X7
IBM RISC System/6000/AIXPC 386/486/ISC UNIX HFSI WIS Workstation
PC 286/386/486/MS-DOS PC 386/486/SCO UNIX DEC Ultrix; DEC VMS
For more information, contact:Phil Carrasco, Object Interface Systems, Inc.
1895 Preston White Drive, Suite 250, Reston, VA
22091-5448, USA; Phone: (703) 264-1900; Fax:
703-264-1721; email info@ois.com (internet)
SL Corporation (Updated: November
1 992)
SL Corporation's SL-GMS toolkit includes Ada bindings to GPEF, GPPF, POSIX,
SQL, TCP/IP, OSF/Motif, and Open Look.
SL-GMS is a toolkit for developing dynamic graphics screens for real-time or
highly interactive applications. Non-programmers can design application
screens in a standard drawing-tool mode, connect them to real-time data
sources and animate screen objects to visualize changing data values. SL-GMS
allows the design of custom "GISMOs" to input values or control the
application and supports MOTIF, OPEN LOOK and other X toolkit widgets.
SL-GMS is used extensively to provide real-time graphics for applications in
the fields of manufacturing, process control, network management, avionics and
financial tracking.
Host/Target:Validated Verdix and DEC compilers support SL-GMS for the
following machines as both host and target:
DEC-DECstation/ULTRIX 4.0DEC-VAXstation/ULTRIX 4.0
DEC-VAXstation/VMS 5.4 DEC-VAXstation/VMS 5.5
IBM-RS6000/AIX
HP-9000/300/UNIX HP-9000/400/UNIX
HP-9000/800/UNIX HP-9000/700/UNIX
PC-386/IX UNIX PC-386/SCO UNIX
PC-386/Lynx PC-386/0S2
PC-386/System 5.4
SGI-4D/IRIX 3.3
Sun-3/SunOS 4.1 SunSPARC/SunOS 4.1
88 Open/BCS Compliant
For more information, contact: Mike Meagher, SL Corporation, 240 Tamal Vista
Boulevard, Corte Madera, CA 94926, USA Phone: (415)
927-1724; Fax: (415) 927-2931
Sunrise Software International (Updated: May
1 992)
Sunrise Software International's product, ezx, is a rapid application
development tool that automates the creation of graphical user interfaces for
OSF/MOTIF and generates C, UIL, or Ada. ezx provides WYSIWYG screen layout;
color, font and pixmap editors; presentation tools and dialog management. A
prototype can be developed in hours and using a script language similar to
Hypertalk, demonstrated to end-users before the first line of code is written.
Then portable C, UIL or Ada can be generated automatically. Ada bindings are
provided. The total code required to develop a GUI is reduced by
approximately 75%. The appearance and behavior of the GUI is defined in an X
resource file which the application loads at run time. This provides explicit
separation between the GUI and the computational core of the application. Thus
the GUI can be revised without recompiling (and retesting) the application.
ezx provides cost savings throughout the software development cycle, from
requirements analysis through design, code, test and maintenance.
Host/Target:DEC RISC under ULTRIX, DEC VAX under VMS, IBM 386 under UNIX, IBM
RS 6000 under AIX, SGI under , SUN SPARC under UNIX
For more information, contact:Frederick Sells, Sunrise Software International,
170 Enterprise Center, Middletown, RI 02840, USA;
Phone: 401-847-7868
Systems Engineering Research Corporation (SERC) (Updated: November
1 992)
SERC's Ada/MOTIF is a complete binding to X Window and OSF/Motif for the Ada
programming language that was based in part upon the SAIC/Unisys (STARS)
public domain bindings. That work was leveraged as a starting point for this
development; many of the bug fixes and additional capabilities beyond the
public domain releases in Ada/MOTIF have been incorporated. Most noteworthy
are the capabilities included in Ada/Motif for Ada tasking, callback
registration, memory leak detection/prevention and capabilities for developing
customized widgets. Paramax/STARS considers Ada/Motif to be the commercial
version of their STARS bindings, according to SERC.
Ada/MOTIF is supported by the ALSYS, VERDIX, SUNAda, IBM Ada, and SGI Ada
compilers.
Host/Target:SUN 4, HP 300/400, HP 700, IBM RS 6000, SGI, 386
SUN OS 4.1.1, SOLARIS 2.0 (coming), HPUX 8.0, SGI 3.2 & 4.0, IBM
ATX 3.2, SCO 3.2
For more information, contact:Theo Kusiolek or Scott Cleveland, Systems
Engineering Research Corporation (SERC), 2555
Charleston Road, Mountain View, CA 94043, USA; Phone:
800-ADA-SERC or 415/962-9092; Fax: 415/962-0330;
E-mail: Well!sercmail@apple.com.
TeleSoft (Updated: November
1 992)
TeleSoft's TeleUSE/Ada automates the creation of OSF/Motif graphical user
interfaces for Ada applications. It includes a special version of the TeleUse
User Interface Management System -- which generates Ada source code -- and Ada
bindings to the TeleUSE run-time routines.
TeleUse/Ada tools allow a GUI to be prototyped and designed using a WYSIWYG
editor and a PDL, and also includes tools for debugging, generating production
code and maintaining the GUI. TeleUse/Ada can save the developer up to 90
percent of the time required to hand code X Window System GUIs.
Host/Target:SPARC under UNIX, Sun-4 under UNIX
TeleSoft's TeleWindows is a set of Ada bindings to the X Window System and
OSF/Motif. This includes Xlib, XT, X extensions Library, XT+, X miscellaneous
utilities, Motif widget set, XM, MWM, Motif resource manager. It supports X-
11 R4 and is not based on the public domain version. It closely follows the C
Xlib syntax and allows Ada applications to co-exist with C applications.
Host/Target:IBM System/370 under VM/CMS
For more information, contact:Karen Johnson, TeleSoft, 5959 Cornerstone Court
West, San Diego, CA 92121-9891, USA; Phone: (619)
457-2700
Verdix (Updated: May
1 992)
The Verdix Ada Development System (VADS), is a complete Ada Compiler System
offering a fully validated Ada compiler with chapter 13 support. Verdix
supplies VADSself and VADScross. VADSself provides a complete toolset for
self-targeted applications. It easily interfaces to databases, windowing
systems and program management tools. VADScross provides real-time support
for host-to-target system development. VADScross produces small and fast
object code. VADS is hosted on the largest number of platforms and targets
the greatest number of microprocessors.
Host/Target:88000 BCS under UNIX, DEC VAX under VMS / ULTRIX / UNIX,
DECStation (RISC) under UNIX, DECSystem (RISC) under UNIX, HP 9000
Series 300 under HP-UX (UNIX), IBM PS/2 under AIX (UNIX), IBM
RISC System/6000 under AIX, SCO Systems V/386 (ABI) under UNIX,
Sun SPARC systems under UNIX, Sun-3 systems under UNIX
Verdix AXI provides an Ada binding to the full Motif, Xt, and Xlib libraries.
The product works with user-supplied Motif 1.1 and X11R4 libraries regardless
of source.
Host/Target:DEC RISC under Ultrix, IBM RS6000 under AIX, MIPS under MIPSos,
Sun-4 under SunOS, Sys V386 under ISC UNIX, Sys V386 under SCO
UNIX
For more information, contact:Tim Ruhe, Verdix Corporation, 205 Van Buren,
Herndon, VA 22070, USA; Phone: (703) 318-5800
-----------------------------------------------------------------------------
Subject: 111) Is there a Poplog binding for Motif?
[Last modified: May]
Answer:
A integrated programming environment consisting of the programming
languages Pop-11, Prolog, Standard ML, and Lisp which are compiled
to machine code via a common virtual machine. Pop-11 provides a rich
interface to the X Toolkit which can be accessed from all other
Poplog languages. The OLIT, Motif, and Athena widget sets are
supported, in addition to the custom Poplog (Xpw) widget set. XVed
provides a sophisticated, customisable multi-window editor. Under
OPEN LOOK and Motif the Poplog User Interface (PUI) provides a
graphical interface to the Poplog system. High-level Pop-11
libraries allow graph drawing, turtle graphics, and the simple
creation of basic button/menu based interfaces.
Contact:
UK EDUCATION SITES:
Poplog Sales. School of Cognitive and Computing Sciences.
Brighton. BN1 9QN. England.
Phone: +44 (0)273 678188
Email: popsales@cogs.susx.ac.uk
USA AND CANADIAN EDUCATION SITES:
Computable Functions Inc. 35 South Orchard Drive. Amherst.
MA 01002. USA.
Phone: (413) 253-7637
ALL OTHER SALES:
Integral Solutions Ltd. Unit 3, Campbell Court. Bramley.
Basingstoke. Hampshire. RG26 5EG. England.
Phone: +44 (0)256 882028
Fax: +44 (0)256 882182
Email: isl@integ.uucp
-----------------------------------------------------------------------------
Subject: 112) TOPIC: SPECIFIC PLATFORMS
-----------------------------------------------------------------------------
Subject: 113) 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: 114) How do I build Motif 1.2.2 on Solaris 2.1 with Sun C?
[Last modified: May 93]
Prepared by Ric Steinberger. ric@updike.sri.com 4/09/93
What follows is a description of the steps I used to build Motif 1.2.2 on a
SUN IPX running Solaris 2.1. Sun's C compiler (2.0.1) was used. Many thanks
go to Kaleb Keithley (kaleb@devvax.jpl.nasa.gov) for several useful
suggestions. Other people, including OSF staff, especially David Brooks
(dbrooks@osf.org), helped as well. My thanks to you all.
1. Build X11R5 from the mit distribution. You need to retrieve the sources
from export.lcs.mit.edu (in pub/R5) and patches 1 - 22 (or 23) (in
pub/R5/fixes). There are several other sites that contain the X11R5
sources. After installing patch 19, apply PEXlib.tar.Z, also available
from export.lcs.mit.edu in pub/R5/fixes. You can apply also
R5.Xsun.multi-screen and R5.SunOS5.patch. There are .README files
that explain how to patch. Be SURE to read
R5.SunOS5.patch.README for details on how to BUILD X11. You probably
want to use the ProjectRoot feature in the site.def file in the
mit/config directory. You will NEED to edit that file to do that.
2. Obtain the Motif 1.2.2 distribution from OSF (617-621-7300). You may
need to first install the 1.2 tape, then the 1.2.1 and finally the
1.2.2 tape. You might want to do a "chmod -R u+w ." after unloading
each tape.
3. In the config directory, there are several changes. Some of the changes
are based on R5.SunOS5.patch files. A complete set of config files
relevant to Solaris have been placed in the anon-ftp account of
updike.sri.com in pub/motif/solaris21-motif122-config.tar.Z. They are
also available from OSF on their mail response server (available to
support contract holders) and they will send them directly to full
support contract holders. Decompress and untar this file in your Motif
config subdirectory. Copy site.def.sample to site.def, then edit
site.def. You will probably want to uncomment the ProjectRoot section
and use the same value used in your X11R5 build. Also, you will probably
want to use /usr/ucb/install in you installed the UCB compatibility
suite. Otherwise you might want to use the install supplied at the end
of this memo. [I used the UCB version and can't swear that this works.
Bit it should. Put it someplace like /usr/local/bin and chmod +x it.]
There are two patches to consider. One fixes a cursor problem
in ./lib/Xm/TextF.c. The other removes a Berkeleyism. These
patches should probably be consider unofficial at present.
Failure to deal with the Berkeleyism (bzero) means you will need to
link with -lucb -lelf. This will probably work, but why bother?
Furthermore, if you move the Motif binaries to a machine without
the ucb compatability suite, you won't have the sharable libs you need.
[The actual patches have been censored because they contain OSF source code]
Patch 1: In TextF.c there are several places _XmTextFieldDrawInsertionPoint
is called. These should be moved two or three lines further down *after* the
"if (!XtIsRealized(tf)) return True;" statement.
patch 2: The call to bzero in lib/Xm/Visual.c should be replaced by the
equivalent call to memset
Both these patches can be applied in the ./lib/Xm directory.
If you don't have the patch program (how did you build X11?),
you can get it in the vendor/cygnus directory of ftp.uu.net,
or you can build it from source. Be sure to get the latest
version (2.0.12.u8).
4) Use the README-1.2.1 file as a guideline for building motif. I followed
directions in the section called, "Using X11R5 Installed Libraries
and Header Files." If you make a mistake after your first build
attempt, copy Makefile.ini to Makefile before retrying. You may
need to do this in the config subdirectory too, depending on what
went wrong.
5) After make Makefiles, do make includes, make depend, then make (or
as OSF recommends, make -k). This gets as far as motifshell in the
demos, which fails to build because O_RDONLY and L_XTND are
not defined. O_RDONLY is in fcntl.h (actually <sys/fcntl.h>, but
fcntl.h includes this.) L_XTND can be replaced by SEEK_END.
SEEK_END is in stdio.h. These two fixes will allow motifshell to build.
Note: many MANY compiler warning messages will be generated during
the build process.
6) You can go to the demos/xmsamplers directory and do a make there.
Other demos may build, or not depending on whatever. . . .
7) make install will do the install. [It will fail at motifshell
if you don't fix it, as mentioned above.] You can do a make install
in demos/xmsamplers if you want these.
8) If running on a SUN (as opposed to an X term), you will (probably) need
to start openwin with something like:
openwin -server /usr/X11R5/bin/Xsun
[You might want to use an alias for this.]
This fixes an annoying problem: The mouse keys stop working after you
click on an icon to get the icon menu (on SUNs only, not X terms).
The ALT keys still work, if you get stuck. I don't know whether this
is a bug in SUN's server or whether it is Motif related.
Here is a copy of my .xinitrc: It's not elegant. Sun's default
openwin startup file is in: /usr/openwin/lib/Xinitrc. You can
copy this to ~/.xinitrc and customize as desired. Obviously, the
default behavior is to start the OpenLook environment (boo!).
#!/bin/sh
#
# .xinitrc - OpenWindows startup script.
#
if [ -f $HOME/.Xdefaults ]; then
xrdb $HOME/.Xdefaults # Load Users X11 resource database
fi
if [ -f $HOME/.Xdefaults.sun ]; then
xrdb -merge $HOME/.Xdefaults.sun
fi
DISPLAY=`hostname`:0.0
export DISPLAY
xhost + > /dev/null
#xterm -sb -sl 512 -T `hostname` -ls -n `hostname` &
xterm -sb -sl 512 -T `hostname` -n `hostname` &
mwm &
xclock -geometry +1010+0 &
xload -geometry +710+5 -fg red &
xsetroot -solid salmon &
xterm -sb -sl 100 -T CONSOLE_DO_NOT_LOGOUT -C -n console -iconic
#wait
Here's .Xdefaults.sun, which gives me a more readable font for use with
motif on Sun monitors:
!Some additional .Xdefaults values specifically for SUN
!
! After loading .Xdefaults, xrdb -merge .Xdefaults.sun
!
Mwm*fontList: 8x16
!Mwm*fontList: vtbold
!Change as desired.
You will probably want to maintain LD_LIBRARY_PATH to something like:
/opt/SUNWspro/lib:/usr/ccs/lib:/usr/ucblib:/usr/X11R5/lib:/usr/lib:
/usr/openwin/lib. If you use emacs, you will need to leave /usr/openwin/lib
there. [This is because you probably, like me, used the distributed version
of s-sol2.h, which explicitly refers to windowing libraries as being in the
/usr/openwin locations. Yes, I know that emacs/Solaris ought to allow
LibXt.so.N.M to be "picked up" from elsewhere, like /usr/X11R5/lib, but the
one emacs links with is LibXt.so.4.something, and the mit one is
LibXt.so.5.something. So it seems to want the .4 one. Any comments? I'd
prefer not to rebuild emacs based on the X11R5 libs because I occassionally
need to move the emacs binaries to machines without the mit files.]
-----------------------------------------------------------------------------
Subject: 115) 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: 116) 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: 117) 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: 118) 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: 119) Has anyone made shared libraries on an IBM RS/6000?
Answer: From Sakari Jalovaara: There is a problem: Xm redefines VendorShell
and the AIX linker put _both_ Xm's and Xt's VendorShell into programs. When
an AIX shared library is created as many references inside the library are
resolved as possible. If the symbol vendorShellClassRec is defined in libXt
and referenced, say, from a function XtFoo() also in libXt, the "ld" run that
creates the shared library resolves the reference:
XtFoo() -> vendorShellClassRec
Then I create the Motif library that has its own vendorShellClassRec and an
XmBar() function that uses it; libXm will also contain a resolved reference to
vendorShellClassRec:
XmBar() -> vendorShellClassRec
Finally, I link a program that uses both XtFoo() and XmBar() and the program
will end up with _two_ independent "vendorShellClassRec"s:
XtFoo() -> vendorShellClassRec [Xt version]
XmBar() -> vendorShellClassRec [Xm version]
Instant schizo zaphod mode. In reality, vendorShellClassRec is not referenced
from functions but from other widget class records.
I can't just pull Vendor.o out from the shared Xt (Vendor.o appears to define
the only external symbols redefined by libXm) because AIX shared libraries
apparently can't contain unresolved external references. If I take out
Vendor.o I have to take out every other file that uses symbols defined there -
and then files that need those files, etc. I tried it and ended up with three
or four object files in libXt and the res non-sharable.
I kludged around this by putting all of libXt (minus Vendor.o) into the shared
libXm. It isn't a pretty solution but it works - and beats having a
statically linked two-megabyte "periodic" demo...
-----------------------------------------------------------------------------
Subject: 120) What is the error "Unaligned access in XmString" under Ultrix?
Answer: Compile XmString.c with STRINGS_ALIGNED.
-----------------------------------------------------------------------------
Subject: 121) TOPIC: KEYSYMS
-----------------------------------------------------------------------------
Subject: 122) What is causing the messages "unknown keysym osfDown..."? It
happens when I run an application under Motif 1.1
Answer: There is an OSF supplied addition to the /usr/lib/X11/XKeysymDB file.
It is found on the release tape and should have been automatically installed
if the installation procedure was followed in the Release Notes.
You have to copy (or append) lib/Xm/XKeysymDB into /usr/lib/X11. This may
require root permission. It is not clear how to fix the problem if you can't
do this. The error comes from Xt translation table parsing and can't be fixed
in Motif, so if you can't get root permission you may be stuck. The file is
not copyrighted so you can install it on other systems.
If X has been built so that XKeysymDB is not in this directory, and you don't
know where it is looking, run 'strings libX11.a | grep XKeysymDB' to find the
path.
On a Sun running openwin with shared libraries, you may need to put the path
for the library containing XKeysymDB *first* in the path list in
LD_LIBRARY_PATH, or it may find the wrong XKeysymDB in the wrong directory.
XKeysymDB simply contains the registered keysym values for the OSF keysyms.
The OSF values are server-independent. And, all registered keysyms will be
included in an XKeysymDB file to be shipped with X11R5.
In the meantime (till all systems are X11R5+), a list of the registered
keysyms can be found in the X11R4 release in mit/doc/Registry/Xregistry.
Also note the XKEYSYMDB environment variable. Setting this to point to the
XKeysymDB file often helps, but not always...
-----------------------------------------------------------------------------
Subject: 123) What happens if I can't install Motif Keysyms?
From: tessi!george@nosun.West.Sun.COM (George Mitchell)
Here's what appears to happen if you don't have XKeysymDB in place to define
OSF's virtual keysyms:
1. At class initialize time, for a widget (such as XmText) that uses virtual
keysyms in its event translation table, all entries which refer to those
keysyms fail to parse correctly. In the case of XmText, instead of ending up
with a translation table with roughly 90 entries, you end up with one that has
29.
2. XKeysymDB doesn't exist, so you'd assume that KeyPress events will get
translated to plain vanilla keysyms, right? WRONG! All Motif widgets install
a virtual keysym translator ANYWAY! Consequently, the backspace key (for
example) gets translated to the keysym osfBackSpace.
3. Therefore, if you augment or override your widget's translations with
translations that refer to plain vanilla BackSpace, they will never be
triggered, because you will NEVER see plain vanilla BackSpace, only
osfBackSpace.
4. But you can't use osfBackSpace in an event translation entry, because you
don't have XKeysymDB installed!
Here's how I'm "dealing" with the problem right now: Motif installs its
virtual keysym translator by calling XtSetKeyTranslator every time a
VendorShell (or subclass) widget is created. So every time I create a shell,
I immediately call XtSetKeyTranslator (display, XtTranslateKey) to restore the
default translator. No more funny virtual keysyms! Now I can reinstall non-
osfKeySym translations and have them work the way I expect.
-----------------------------------------------------------------------------
Subject: 124) Why has OSF introduced Keysyms into Motif 1.1? They weren't
there in Motif 1.0.
Answer: From: ellis@osf.org
Virtual Keysyms are meant to provide a consistent keyboard model for Motif
applications running in a heterogeneous environment in which proprietary (i.e.
vendor specific) non-Motif applications may also be running.
First of all, for the sake of the rest of the readers, let's explain why this
is an issue:
It would be lovely if Motif's translation tables could just use the obvious
keysyms predefined by X. For example, there are keysyms for XK_BackSpace,
XK_Delete, XK_Left, XK_Right, etc. Shouldn't these be the ones that are used
in our translations? Unfortunately, the problem is not so simple. Some
specific examples:
While most vendors bind XK_BackSpace to the key at the top right
of the standard keyboard (often engraved with a leftwards
pointing arrow), not all do. In fact, some vendors (including DEC)
bind that key to XK_Delete.
While most vendors bind the arrow keys to XK_Up, etc, a number of
vendors (including Sun, on some servers) bind them to function key
keysyms.
A simplistic solution would require the use of xmodmap to change the offending
bindings. That would work swell in an all Motif environment. However, OSF's
goal (not always perfectly achieved) is interoperability. That is, we'd like
to make sure that both Motif and non-Motif programs can happily run in the
same environment.
It is expected that a vendor may have a wide variety of existing X-based
software that uses the keysyms as established by that vendor for specific
purposes. It is expected that these applications may run at the same time as
Motif-based software. Using xmodmap to change keysyms on the server side
could "break" the existing applications (or at the very least their
documentation) by making some keys unavailable, or by moving the location.
So, we chose not to use xmodmap. By the way, though OpenLook uses a different
implementation (they recompile their virtual translation tables into actual
translation tables), they basically adopted the same approach, presumably for
similar reasons.
To work properly, the virtual keysym model we implemented depends on Xlib
finding XKeysymDB installed appropriately (which standard Motif installation
does). This simply defines the keysyms (not the key they are bound to). This
unfortunate piece of stupidity is necessary because MIT only includes standard
keysyms in keysymdef.h. It should be said that our lives would be made easier
if MIT would also see fit to include registered keysyms in keysymdef.h as
well.
Motif applications determine how to bind virtual to actual keys by looking for
either a resource or a property on the root window which describes what to do.
Note that this information is on the server side, so that all applications use
the same virtual bindings regardless of where they are running. Mwm will
happily create the property if it finds a .motifbind file in your home
directory when it starts up. (Actually, things generally work even if none of
this is done, since if all else fails, the Motif toolkit chooses a virtual
bindings table to use based on the identification of the server).
The actual implementation of virtual keys is made possible by a hook in the
Intrinsics. Undoubtably, the implementation would be simpler and cleaner if
virtual key support was more directly supported by the Intrinsics. We will be
exploring this possibility in the future.
-- Ellis
-----------------------------------------------------------------------------
END OF PART FOUR
--
..........................