Danny Amor's Online Library

home *** CD-ROM | disk | FTP | other *** search

/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / html / faqs / faq / motif-faq / part4 < prev next >

Wrap

Text File | 1995-07-25 | 59.6 KB | 1,499 lines

Subject: Motif FAQ (Part 4 of 6) Newsgroups: comp.windows.x.motif,comp.answers,news.answers From: ksall@cen.com (Ken Sall) Date: 11 Oct 1994 07:52:04 GMT Archive-name: motif-faq/part4 Last-modified: OCT 10, 1994 Posting-Frequency: monthly Organization: Century Computing, Inc. Version: 3.8 ----------------------------------------------------------------------------- Subject: 107) How do popup menus work? [Last modified: August 92] Answer: When a popup menu is created as the child of a widget the menu system installs a translation on the parent of the popup and descendants with an action which: (1) when 3-rd button (the default for the menuPost resource) is pressed the cursor changes and the mouse is grabbed for 5 seconds; (2) disables event handlers on the descendants and the handlers are never called; (3) an event handler installed on the parent works fine. It is done so that the correct event handler will (in fact) be called. There is a grab with owner_events true. The grab is released by a timer, but normally the posted menu shell puts up it's own grab. If you only have widgets then you can use the subwindow field in the event to identify the original widget. If you have gadgets or other data that you want to change the menu for (or use a specific menu for) then you must do a walk of the parent's children to find the best match. One thing to beware of is that even with the grab, because the menu system does a grab with owner events true, you must either have an event handler, or nothing that will use the event on each widget in the hierarchy of the menu's parent. If a child widget has another event handler for button down, it may swallow the event and do something else. ----------------------------------------------------------------------------- Subject: 108) 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: 109) 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: 110) Can I have multiple popup menus on the same widget? [Last modified: August 92] Answer: If you want to have several popups (activated by different mouse buttons) on the same widget..., well, that doesn't work yet. If you want to have several popups on different children... that works. But don't put a popup on the parent (manager) widget, or it will rule! ----------------------------------------------------------------------------- Subject: 111) TOPIC: INPUT FOCUS ----------------------------------------------------------------------------- Subject: 112) How can I specify the widget that should have the keyboard focus when my application starts up? Answer: In Motif 1.2, use XmNinitialFocus on the manager widget. Thanks to Ken Lee, kenton@allegro.esd.sgi.com ----------------------------------------------------------------------------- Subject: 113) 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: 114) How can I have a modal dialog which has to be answered before the application can continue? [Last modified: Oct 94] Answer: 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 = XmStringCreateSimple("/bin/rm *"); button = XtVaCreateManagedWidget("button", xmPushButtonWidgetClass, toplevel, XmNlabelString, label, NULL); XtAddCallback(button, XmNactivateCallback, pushed, "Remove Everything?"); XmStringFree(label); XtRealizeWidget(toplevel); XtAppMainLoop(app); } /* pushed() --the callback routine for the main app's pushbutton. */ void pushed(w, question) Widget w; char *question; { if (AskUser(w, question) == YES) puts("Yes"); else puts("No"); } /* * AskUser() -- a generalized routine that asks the user a question * and returns the response. */ AskUser(parent, question) char *question; { static Widget dialog; XmString text, yes, no; static int answer; extern void response(); answer = 0; if (!dialog) { dialog = XmCreateQuestionDialog(parent, "dialog", NULL, 0); yes = XmStringCreateSimple("Yes"); no = XmStringCreateSimple("No"); XtVaSetValues(dialog, XmNdialogStyle, XmDIALOG_APPLICATION_MODAL, XmNokLabelString, yes, XmNcancelLabelString, no, NULL); XtSetSensitive( XmMessageBoxGetChild(dialog, XmDIALOG_HELP_BUTTON), False); XtAddCallback(dialog, XmNokCallback, response, &answer); XtAddCallback(dialog, XmNcancelCallback, response, &answer); /* if the user interacts via the system menu: */ /* SEE CORRECTION ABOVE */ XtAddCallback(dialog, XmNpopdownCallback, response, &answer); } text = XmStringCreateSimple(question); XtVaSetValues(dialog, XmNmessageString, text, NULL); XmStringFree(text); XtManageChild(dialog); XtPopup(XtParent(dialog), XtGrabNone); /* while the user hasn't provided an answer, simulate XtMainLoop. * The answer changes as soon as the user selects one of the * buttons and the callback routine changes its value. Don't * break loop until XtPending() also returns False to assure * widget destruction. */ while (answer == 0 || XtAppPending(app)) XtAppProcessEvent(app, XtIMAll); return answer; } /* response() --The user made some sort of response to the * question posed in AskUser(). Set the answer (client_data) * accordingly and destroy the dialog. */ void response(w, answer, reason) Widget w; int *answer; XmAnyCallbackStruct *reason; { switch (reason->reason) { case XmCR_OK: *answer = YES; break; case XmCR_CANCEL: *answer = NO; break; default: *answer = NO; return; } } If you aren't running a window manager that acknowledges this hint, then you may have to grab the pointer (and keyboard) yourself to make sure the user doesn't interact with any other widget. Change the grab flag in XtPopup to XtGrabExclusive, and XtRemoveGrab(XtParent(w)) to the response() function. ----------------------------------------------------------------------------- Subject: 115) TOPIC: MEMORY AND SPEED ----------------------------------------------------------------------------- Subject: 116) When can I free data structures passed to or retrieved from Motif? Answer: In most cases, especially for XmStrings and XmFontLists, Motif copies data passed to it or retrieved from it, so it may be freed immediately. Server- side resources, such as pixmaps and color cells, however, are not copied, so should not be freed. More recent versions of Motif are better than earlier versions and exceptions should be documented. Thanks to Ken Lee, kenton@allegro.esd.sgi.com ----------------------------------------------------------------------------- Subject: 117) Why does my application grow in size? Answer: Motif 1.0 has many memory leaks, particularly in XmString manipulation. Switch to Motif 1.1. Answer: The Intrinsics have a memory leak in accelerator table management, and Motif uses this heavily. Avoid this by mapping/unmapping widgets rather than creating/destroying them, or get X11R4 fix-15/16/17. Answer: The server may grow in size due to its own memory leaks. Switch to a later server. Answer: You are responsible for garbage collection in `C'. Some common cases where a piece of memory becomes garbage are a. Memory is allocated by Motif for XmStrings by the functions XmStringConcat, XmStringCopy, XmStringCreate, XmStringCreateLtoR, XmStringCreateSimple, XmStringDirectionCreate, XmStringNConcat, XmStringNCopy, XmStringSegmentCreate, and XmStringSeparatorCreate. The values returned by these functions should be freed using XmStringFree when they are no longer needed. b. Memory is allocated by Motif for ordinary character strings (of type String) by Motif in XmStringGetLtoR, XmStringGetNextComponent, and XmStringGetNextSegment. After using the string, XtFree() it. [Note that XmStrings and Strings are two different data types. XmStrings are XmStringFree'd, Strings are XtFree'd.] c. If you have set the label (an XmString) in a label, pushbutton, etc widget, free it after calling XtSetValues() or the widget creation routine by XmStringFree(). d. If you have set text in a text widget, the text widget makes its own copy. Unless you have a use for it, there is no need to keep your own copy. e. If you have set the strings in a list widget the list widget makes its own copy. Unless you have a use for it, there is no need to keep your own copy. f. When you get the value of a single compound string from a Widget e.g. XmNlabelString, XmNmessageString, ... Motif gives you a copy of its internal value. You should XmStringFree this when you have finished with it. g. On the other hand, when you get a value of a Table e.g. XmStringTable for a List, you get a *pointer* to the internal Table, and should not free it. h. When you get the value of the text in a widget by XmTextGetString or from the resource XmNvalue, you get a copy of the text. You should XtFree this when you have finished with it. Answer: From Josef Nelissen: at least in Motif 1.1.4, X11R4 on a HP 720, the XmText/XmTextFieldSetString() functions have a memory leak. The old value/contents of the Widget isn't freed correctly. To work around this bug, one should use a XmText Widget (in single-line-mode) instead of a XmTextField Widget (the solution fails with XmTextField Widgets !) and replace any XmTextSetString(text_widget, str); by XmTextReplace(text_widget, (XmTextPosition) 0, XmTextGetLastPosition(text_widget), str); ----------------------------------------------------------------------------- Subject: 118) 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: 119) My application is running too slowly. How can I speed it up? Answer: Use the R4 rather than R3 server. It is much faster. Answer: The standard memory allocator is not well tuned to Motif, and can degrade performance. Use a better allocator. e.g. with SCO Unix, link with libmalloc.a; use the allocator from GNU emacs; use the allocator from Perl. Answer: Avoid lots of widget creation and destruction. It fragments memory and slows everything down. Popup/popdown, manage/unmanage instead. Answer: Set mappedWhenManaged to FALSE, and then call XtMapWidget() XtUnmapWidget() rather than managing. Answer: Get more memory - your application, the server and the Operating System may be spending a lot of time being swapped. Answer: If you are doing much XmString work yourself, such as heavy use of XmStringCompare, speed may deteriorate due to the large amount of internal conversions and malloc'ing. Try using XmStringByteCompare if appropriate or ordinary Ascii strings if you can. ----------------------------------------------------------------------------- Subject: 120) 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: 121) TOPIC: XMSTRING ----------------------------------------------------------------------------- Subject: 122) What string functions differ in Motif 1.2? Answer: 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 XmDEFAULT_FONTLIST_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, and possibly update several of the Motif FAQs on XmStrings. 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 XmDEFAULT_FONTLIST_TAG. [TBD next month: I have not updated the following string questions based on the above...ksall@cen.com.] ----------------------------------------------------------------------------- Subject: 123) 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: 124) 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: 125) 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: 126) Why does using XmStringDraw cause a Bad Font error? [Last modified: Sept 94] 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")); 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 " From Harald Albrecht (albrecht@igpm.rwth-aachen.de) ----------------------------------------------------------------------------- Subject: 127) TOPIC: DIALOGS ----------------------------------------------------------------------------- Subject: 128) 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: 129) 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: 130) 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: 131) 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: 132) 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: 133) TOPIC: LANGUAGE BINDINGS ----------------------------------------------------------------------------- Subject: 134)* Is there a C++ binding for Motif? [Last modified: Oct 94] 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)" An object license is $795 "per seat" and a source code license is available for $2,995 "per seat." Rogue Wave also offers full support for View.h++. It is currently available for Sun Sparc, IBM RS/6000, HP 9000/700 series, SCO, Intel SVR4 ESIX. Please call for Silicon Graphics and DEC Ultrix status. For additional information, please contact: Matt Steinauer Rogue Wave Software, Inc. P.O. Box 2328 Corvallis, OR 97339 Phone: (503)754-3010 Fax: (503)757-6650 email: matts@roguewave.com Answer: Builder Xcessory 3.0, an interface builder from ICS, allows the user to visually build C++ classes from Motif and user-written widgets. C++ code is generated in the "Doug Young" fashion. (Doug actually worked on this project with ICS.) C and UIL can also be generated. Integrated Computer Solutions, Inc. (ICS) 201 Broadway, Cambridge, MA 02139 USA info@ics.com 617/621-0060 Answer: From Andreas.Baecker@gmd.de: The GINA++ application framework contains an encapsulation of the OSF/Motif widg et classes and the Xt functionality into C++ classes. Its functionality is comparab le to that of the ULowell binding and the WWL. Additionally, it provides an easy-to -use framework for modeling new composite and primitive widget classes, plus an application framework similar to ET++ or MacApp build on top of it. The binding may be used independently from the framework classes. GINA++ is available through anonymous ftp from ftp.gmd.de [129.26.8.90] in the directory /gmd/ginaplus. Documentation about the Motif binding has been published in the X Resource Journ al, Number 2, 1992, Pages 106-130. The binding compiles with AT&T C++ 2.1 and GNU G+ + 2.1 and has been tested on SunOS 4.1.[12], X11R4 and Motif 1.1.3. Answer: Motif++ is a library that defines C++ class "wrappers" for the widgets defined in the X11R5 OSF/Motif-1.2 widget library. It also supports X11R4/Motif-1.1 as well. Motif++ is also an application toolkit that provides other tools in conjunction with the widget wrapper classes. It has support for the Xbae widget set, plus other widgets. It has Imake support, and lots of test files. Motif++ also has alot of contributed software. Motif++ is very similar to other public domain widget libraries such as The Widget Wrapper Library (WWL) and the C++ Binding for OSF/Motif developed at the University of Lowell. The two latter libraries are the result of much larger efforts. 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: 135)+ 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@x.org> ----------------------------------------------------------------------------- Subject: 136)* 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@allegro.esd.sgi.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 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: 137)* 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: 138) Is there an Ada binding for Motif? [Last modified: Apr 94 ] Answer: Answer: Integrated Computer Solutions, Inc. (ICS) supplies Ada bindings to Motif for a number of platforms and Ada compilers. ICS also provides Builder Xcessory, a Motif interface builder, which outputs Ada code usable with the Ada bindings. The product family is known collectively as the Ada Xcessories. Integrated Computer Solutions, Inc. (ICS) 201 Broadway, Cambridge, MA 02139 USA info@ics.com 617/621-0060 Information on Ada bindings to Motif and other services (such as SQL and POSIX) can be found in a document maintained by the Ada Information Clearinghouse. The report can be found at host: ajpo.sei.cmu.edu loc: /public/ada-info/bindings.hlp.* access: anonymous ftp The suffix to the file (indicated above with an asterix) is the date of the latest update to the document. For example, the full name of the report updated on 14 June 1993 would be /public/ada-info/bindings.hlp.14Jun93. The file is ASCII. ------ Included File [...Excerpted from the AdaIC report bindings.hlp.14Jun93...] [...Updates can be found on ajpo.sei.cmu.edu, in the ...] [...file /public/ada-info/bindings.hlp.* The suffix ...] [...is always the date of the lastest version to the ...] [...report. ...] SECTION 12 X-Window System: OSF Motif and Open Look Available Ada Bindings 12.1 Description and Standardization Efforts The X-Window System is a network-transparent window system. It supports one or more screens containing overlapping windows or subwindows. X display servers distribute user input to and accept output requests from various client programs located either on the same machine or elsewhere in the network. OSF Motif (Open Software Foundation/Motif) is a graphical user interface from OSF that provides a Presentation Manager look and feel for applications running on any system with X Window version 11. It conforms to POSIX, ANSI C and X/Open's XPG3 standards. 12.2 Resources Available from Software Reuse Libraries/Repositories ASSET (Updated: November 1 992) The following information was taken in its entirety from the ASSET Library Repository Catalog, October 9, 1992. For more information on ASSET, see Appendix C. INTERFACE TO THE X WINDOW SYSTEM VERSION_NUMBER : 1.1 DEVELOPED_BY : SAIC RELEASE_DATE : 29-SEP-88 UNIQUE_IDENTIFIER : ASSET_A_240 ALTERNATE_NAME : SAICX2 ASSET_TYPE : SOFTWARE CODE FUNCTIONS : INTERFACE, BIND OBJECTS : ADA, X WINDOWS KEYWORDS : STANDARDS, BINDINGS COLLECTION : STARS FOUNDATIONS DISTRIBUTION : UNLIMITED DESCRIPTION : Interface to the X Window System An expression of the various concepts in Ada that provides a full, working Ada specification of the X Window system. Approved for public release; distribution is unlimited. 12.3 Products Available from Vendors Advanced Technology Center (Updated: November 1 992) The Advanced Technology Center (ATC) has an Ada binding to OSF Motif for their AXI~ product. AXI is currently available for most UNIX-based platforms, and is supported by Verdix, Meridian, and TeleSoft compilers. AXI is an Ada-to-X-Window System interface that provides the Ada programmer access to the 500+ functions, libraries, and procedures contained in the X library (Xlib), the X Toolkit (Xt), the X Extensible Library, the X Miscellaneous Utilities, the Motif widget set and the Motif Resource Manager. ATC is planning to develop an Ada binding to Open Look for AXI. For more information, contact:Larry Paulson, Advanced Technology Center, 22982 Mill Creek Drive, Laguna Hills, CA 92653, USA; Phone: 714-583-9119 Alsys, Inc. (Updated: May 1 992) The Alsys Ada Software Development Environment (Alsys's validated Ada compiler #901221W1.11103) for 386 UNIX is a production-quality Ada environment capable of handling very large Ada applications (over 500,000 lines of code). The product includes the Compiler; Multi-Library Environment, which provides a powerful and flexible way to manage Ada development effort and share program units; Binder, which supports unused subprograms elimination; High-and Low- Level Optimizers for improving code quality and performance; and Run-Time Executive for efficient support for executing Ada programs. Also included is the Developer's Toolset including: Ada Probe, a symbolic source level debugger and program viewer; AdaXref, a cross-reference generator; AdaMake, a recompilation aid; AdaReformat, a source reformatter. Alsys currently has Ada bindings to POSIX, X-Windows (OSF Motif), and the Generic Package of Elementary Functions for the Alsys Ada Software Development Environment, running on 386 UNIX 386/486-based machines supported as both host and target and running 386/ix or SCO UNIX. They are also planning a binding to SQL for 386/486 machines. Host/Target:386/486 PC under IX UNIX, 386/486 PC under SCO UNIX The Alsys Ada Software Development Environment for the IBM RS/6000 is a production-quality Ada environment capable of handling very large Ada applications. Hosted on and targeted to the IBM RS/6000 workstation under IBM's AIX operating system, the product includes the Compiler; Multi-Library Environment, which provides a powerful and flexible way to manage Ada development efforts and share program units; Binder; Run-Time Executive; and both a High and Low-Level Optimizer for improving code quality and performance. Also included is the Alsys Ada Toolset including Ada Probe, symbolic source level debugger and program viewer; AdaXref, cross-reference generator; AdaMake, recompilation aid; and AdaReformat, source reformatter. Alsys has bindings currently available to the Generic Package of Elementary Functions and to X-Windows (OSF Motif) for the Alsys Ada Development Environment for the IBM RS/6000 running on any RISC System/6000 machine as both host and target and running IBM's AIX operating system (Alsys's validated Ada compiler #910809W1.11195). Alsys also plans to develop a POSIX binding for the RS/6000. Host/Target:RISC System/6000 under AIX The Alsys Ada Software Development Environment for SPARC Workstations is a production-quality Ada environment capable of handling very large Ada applications. Hosted on any SPARC-based workstation under SunOS or SunView, the product helps you realize the full potential of Ada on SPARC machines. The product includes the Compiler (with High- and Low-Level Optimizers); Binder, which supports unused subprogram elimination; Multi-Library system (Family, Library, and Unit Managers) which provides a powerful and flexible way to manage Ada development efforts and share program units; AdaExec real-time executive, for complete and efficient support for executing Ada programs; and ISO-standard mathematical library. Also included is the Alsys Ada Toolset including AdaProbe, symbolic source level debugger and program viewer; AdaXref, cross-reference generator; AdaMake, recompilation aid; and AdaReformat, source reformatter. Bindings to the Generic Package of Elementary Functions and to OSF/Motif are currently available for the Alsys Ada Software Development Environment running on any SPARC-based Workstation as both host and target and running SunOS or SunView. Host/Target:SPARC under SUNOS For more information, contact:Scott Garren, Alsys, Inc., 67 South Bedford Street, Burlington, MA 01803-5152, USA; Phone: (617) 270-0030 Digital Equipment Corporation (Updated: November 1 992) Digital Equipment Corporation has bindings available for GKS, PHIGS, SQL, and OSF Motif for VAX Ada/VMS. The Ada bindings are provided either as part of a compiler product or the services/facilities that are provided by Digital and its suppliers. Host/Target:DEC VAX under VMS For more information, contact:Mary Anne Cacciola, Digital Equipment Corporation, 110 Spit Brook Road, Nashua, NH 03062, USA; Phone: (603) 881-1028 IBM (Updated: November 1 992) IBM's AIX Ada/6000 product provides a binding to GPEF and IBM AIXWindows (X- Windows ... not Motif). It runs on all models of the IBM RISC System/6000 under the IBM AIX Version 3.2 operating system. See also entries for Systems Engineering Research Corporation (SERC) and Advanced Technology Center (ATC) for Motif, GKS or PHIGS bindings for use with IBM AIX Ada/6000 products. The AIX Ada/6000 licensed programs (5706-291 and 5706-294) consist of an optimizing compiler, a run-time environment, a symbolic debugger, an Ada "makefile" generator for use in automating and minimizing recompilation, Ada library management tools and Ada language bindings to some key AIX subsystems. With the exception of some system-specific aspects of the language, the Ada language for the AIX operating system is source compatible with the Ada language supported by IBM licensed programs in VM/CMS and MVS. Host/Target:IBM RISC System/6000 under the IBM AIX Version 3.2 operating system This product conforms to the following standards: ANSI/MIL-STD-1815A - Ada at current level (1.11) of the ACVC test suite. For more information, contact:Barry Lee, IBM Corporation, 844 Don Mills Road, North York, Ontario, Canada M3C 1V7; Phone: (416) 448-3174; Fax: (416) 448-4810 Objective Interface Systems, Inc. (Updated: November 1 992) Objective Interface Systems, Inc., has an Ada binding to X-windows (OSF Motif) for its Screen Machine~ product. The Screen Machine binding to Motif includes a WYSIWYG drawing tool and an Ada code generator. Host/Target: Sun SPARC/SunOS Rational R1000/Delta HP 9000/7XX; 8X7 IBM RISC System/6000/AIXPC 386/486/ISC UNIX HFSI WIS Workstation PC 286/386/486/MS-DOS PC 386/486/SCO UNIX DEC Ultrix; DEC VMS For more information, contact:Phil Carrasco, Object Interface Systems, Inc. 1895 Preston White Drive, Suite 250, Reston, VA 22091-5448, USA; Phone: (703) 264-1900; Fax: 703-264-1721; email info@ois.com (internet) SL Corporation (Updated: November 1 992) SL Corporation's SL-GMS toolkit includes Ada bindings to GPEF, GPPF, POSIX, SQL, TCP/IP, OSF/Motif, and Open Look. SL-GMS is a toolkit for developing dynamic graphics screens for real-time or highly interactive applications. Non-programmers can design application screens in a standard drawing-tool mode, connect them to real-time data sources and animate screen objects to visualize changing data values. SL-GMS allows the design of custom "GISMOs" to input values or control the application and supports MOTIF, OPEN LOOK and other X toolkit widgets. SL-GMS is used extensively to provide real-time graphics for applications in the fields of manufacturing, process control, network management, avionics and financial tracking. Host/Target:Validated Verdix and DEC compilers support SL-GMS for the following machines as both host and target: DEC-DECstation/ULTRIX 4.0DEC-VAXstation/ULTRIX 4.0 DEC-VAXstation/VMS 5.4 DEC-VAXstation/VMS 5.5 IBM-RS6000/AIX HP-9000/300/UNIX HP-9000/400/UNIX HP-9000/800/UNIX HP-9000/700/UNIX PC-386/IX UNIX PC-386/SCO UNIX PC-386/Lynx PC-386/0S2 PC-386/System 5.4 SGI-4D/IRIX 3.3 Sun-3/SunOS 4.1 SunSPARC/SunOS 4.1 88 Open/BCS Compliant For more information, contact: Mike Meagher, SL Corporation, 240 Tamal Vista Boulevard, Corte Madera, CA 94926, USA Phone: (415) 927-1724; Fax: (415) 927-2931 Sunrise Software International (Updated: May 1 992) Sunrise Software International's product, ezx, is a rapid application development tool that automates the creation of graphical user interfaces for OSF/MOTIF and generates C, UIL, or Ada. ezx provides WYSIWYG screen layout; color, font and pixmap editors; presentation tools and dialog management. A prototype can be developed in hours and using a script language similar to Hypertalk, demonstrated to end-users before the first line of code is written. Then portable C, UIL or Ada can be generated automatically. Ada bindings are provided. The total code required to develop a GUI is reduced by approximately 75%. The appearance and behavior of the GUI is defined in an X resource file which the application loads at run time. This provides explicit separation between the GUI and the computational core of the application. Thus the GUI can be revised without recompiling (and retesting) the application. ezx provides cost savings throughout the software development cycle, from requirements analysis through design, code, test and maintenance. Host/Target:DEC RISC under ULTRIX, DEC VAX under VMS, IBM 386 under UNIX, IBM RS 6000 under AIX, SGI under , SUN SPARC under UNIX For more information, contact:Frederick Sells, Sunrise Software International, 170 Enterprise Center, Middletown, RI 02840, USA; Phone: 401-847-7868 Systems Engineering Research Corporation (SERC) (Updated: November 1 992) SERC's Ada/MOTIF is a complete binding to X Window and OSF/Motif for the Ada programming language that was based in part upon the SAIC/Unisys (STARS) public domain bindings. That work was leveraged as a starting point for this development; many of the bug fixes and additional capabilities beyond the public domain releases in Ada/MOTIF have been incorporated. Most noteworthy are the capabilities included in Ada/Motif for Ada tasking, callback registration, memory leak detection/prevention and capabilities for developing customized widgets. Paramax/STARS considers Ada/Motif to be the commercial version of their STARS bindings, according to SERC. Ada/MOTIF is supported by the ALSYS, VERDIX, SUNAda, IBM Ada, and SGI Ada compilers. Host/Target:SUN 4, HP 300/400, HP 700, IBM RS 6000, SGI, 386 SUN OS 4.1.1, SOLARIS 2.0 (coming), HPUX 8.0, SGI 3.2 & 4.0, IBM ATX 3.2, SCO 3.2 For more information, contact:Theo Kusiolek or Scott Cleveland, Systems Engineering Research Corporation (SERC), 2555 Charleston Road, Mountain View, CA 94043, USA; Phone: 800-ADA-SERC or 415/962-9092; Fax: 415/962-0330; E-mail: Well!sercmail@apple.com. TeleSoft (Updated: November 1 992) TeleSoft's TeleUSE/Ada automates the creation of OSF/Motif graphical user interfaces for Ada applications. It includes a special version of the TeleUse User Interface Management System -- which generates Ada source code -- and Ada bindings to the TeleUSE run-time routines. TeleUse/Ada tools allow a GUI to be prototyped and designed using a WYSIWYG editor and a PDL, and also includes tools for debugging, generating production code and maintaining the GUI. TeleUse/Ada can save the developer up to 90 percent of the time required to hand code X Window System GUIs. Host/Target:SPARC under UNIX, Sun-4 under UNIX TeleSoft's TeleWindows is a set of Ada bindings to the X Window System and OSF/Motif. This includes Xlib, XT, X extensions Library, XT+, X miscellaneous utilities, Motif widget set, XM, MWM, Motif resource manager. It supports X- 11 R4 and is not based on the public domain version. It closely follows the C Xlib syntax and allows Ada applications to co-exist with C applications. Host/Target:IBM System/370 under VM/CMS For more information, contact:Karen Johnson, TeleSoft, 5959 Cornerstone Court West, San Diego, CA 92121-9891, USA; Phone: (619) 457-2700 Verdix (Updated: May 1 992) The Verdix Ada Development System (VADS), is a complete Ada Compiler System offering a fully validated Ada compiler with chapter 13 support. Verdix supplies VADSself and VADScross. VADSself provides a complete toolset for self-targeted applications. It easily interfaces to databases, windowing systems and program management tools. VADScross provides real-time support for host-to-target system development. VADScross produces small and fast object code. VADS is hosted on the largest number of platforms and targets the greatest number of microprocessors. Host/Target:88000 BCS under UNIX, DEC VAX under VMS / ULTRIX / UNIX, DECStation (RISC) under UNIX, DECSystem (RISC) under UNIX, HP 9000 Series 300 under HP-UX (UNIX), IBM PS/2 under AIX (UNIX), IBM RISC System/6000 under AIX, SCO Systems V/386 (ABI) under UNIX, Sun SPARC systems under UNIX, Sun-3 systems under UNIX Verdix AXI provides an Ada binding to the full Motif, Xt, and Xlib libraries. The product works with user-supplied Motif 1.1 and X11R4 libraries regardless of source. Host/Target:DEC RISC under Ultrix, IBM RS6000 under AIX, MIPS under MIPSos, Sun-4 under SunOS, Sys V386 under ISC UNIX, Sys V386 under SCO UNIX For more information, contact:Tim Ruhe, Verdix Corporation, 205 Van Buren, Herndon, VA 22070, USA; Phone: (703) 318-5800 Answer: Integrated Computer Solutions, Inc. (ICS) supplies Ada bindings to Motif for a number of platforms and Ada compilers. ICS also provides Builder Xcessory, a Motif interface builder, which outputs Ada code usable with the Ada bindings. The product family is known collectively as the Ada Xcessories. Integrated Computer Solutions, Inc. (ICS) 201 Broadway, Cambridge, MA 02139 USA info@ics.com 617/621-0060 ----------------------------------------------------------------------------- END OF PART FOUR