From: ksall@cen.com (Ken Sall)
Newsgroups: comp.windows.x.motif,comp.answers,news.answers
Subject: Motif FAQ (Part 6 of 9)
Date: 7 May 1995 12:28:48 GMT
Organization: none
Approved: news-answers-request@MIT.EDU
Expires: 20 Jun 1995 12:27:35 GMT
Message-ID: <motif-faq/part6_799849655@rtfm.mit.edu>
Reply-To: ksall@cen.com (Ken Sall)
Keywords: FAQ question answer

Archive-name: motif-faq/part6
Last-modified: MAY 05, 1995
Posting-Frequency: monthly
Organization: Century Computing, Inc. <URL:http://www.cen.com/>
Version: 4.4




-----------------------------------------------------------------------------
Subject: 151)  TOPIC: XMSTRING

-----------------------------------------------------------------------------
Subject: 152)  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: 153)  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: 154)  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: 155)  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: 156)  Why does using XmStringDraw cause a Bad Font error?

[Last modified: Sept 94]

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:
  file://ftp.igpm.rwth-aachen.de/arc/pub/unix/html/renderxmstrings.html "

Thanks to Harald Albrecht (albrecht@igpm.rwth-aachen.de).

-----------------------------------------------------------------------------
Subject: 157)  TOPIC: DIALOGS

-----------------------------------------------------------------------------
Subject: 158)  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: 159)  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: 160)  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: 161)  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: 162)  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: 163)  TOPIC: LANGUAGE BINDINGS

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

[Last modified: Dec 94]


Answer: Wind/U implements MFC (Microsoft Foundation Classes) on Unix using
Motif.  Bristol Technology, Inc. (203) 438-6969, info@bristol.com.

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

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

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

For additional information, please contact:

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

email:   matts@roguewave.com


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

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


Answer: 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 [129.26.8.90] 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

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: 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. As well as undergoing
further development at AIAI ( http://www.aiai.ed.ac.uk/ ), outside
contributors are helping to extend its abilities and range of platforms.  See
http://www.aiai.ed.ac.uk/~jacs/wxwin.html .


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

Answer: Liant have C++/Views.

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

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


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

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

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

-----------------------------------------------------------------------------
Subject: 165)  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: 166)  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, kenton@rahul.net)


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

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