![]() |
Compatibility can have several degrees, the ultimate one being binary compatibility. This is the one we're aiming for. This can be tested even today on most platforms on which shared libraries are supported : if you also have Motif® shared libraries, you can choose which library to use by setting an environment variable such as LD_LIBRARY_PATH prior to executing an application.
The primary objectives have been to develop the widget code of the LessTif Toolkit. Intermittently, the window manager (mwm) and the combination of UIL compiler and libMrm are being worked on.
Volunteers to advance one or more parts of LessTif development, or for writing documentation without an OSF, X/Open or The Open Group copyright on it, are always welcome.
The same web pages can point you to quite a few CD-ROM manufacturers which put a version of LessTif on some of their products. Many free Unix (RedHat, Debian, SuSE, Walnut Creek FreeBSD, ...) are among them.
Keeping a list of developers for each widget is not really possible mainly because the we're not fanatic about ownership of a widget. We do keep in touch enough to know who's messing with what so we don't overlap too much.
You should be able to compile and run your code, how well it works is another matter... If it doesn't, then we're very interested in hearing about what doesn't work and why (we can't fix bugs that we don't know about), and we're even more interested in a fix.
If your favourite application does work, please tell us so we add it to the list of apps known to work.
Up to now we are very close, all interfaces are in place, we might only have to fight against some remaining bugs ...
In early 1997 however, someone asked whether submissions for 2.0 or CDE widgets would be accepted.
Of course !
Therefore, we expanded the source directory tree to make it easy to add new stuff, and to build several versions of the library (and the corresponding tools). So if anybody has a widget, or an application, to offer which can advance us in the 2.x or CDE areas, please E-mail us.
Somewhere along 1997 we actually started building 2.0 compliant widgets. More of them are needed though.
See also in Will LessTif be Motif1.2 Compliant?.
We did talk to them. They basically don't want to use too much of the 2.* stuff (some of it is rather buggy in OSF releases); also they really want the core of eXode to run on top of LessTif.
Meanhwile we also have to make a similar statement as in the asnwer for question Will LessTif be Motif2.0 Compliant?. Our main focus is and will be Motif 2.1 compliance.
Nothing has happened to LessDox in a long time, we would love some people to write free documentation describing the LessTif widget set.
Note we'll only refresh these binary distributions at release time, which is about once a month.
The INSTALL file found in the source distribution and on the web explains how to install it.
Make sure that you do get a binary version, if that's what you're interested in; not the source distribution.
We also have a list of CD-ROMs which include LessTif distributions.
Around December 1997 we also started to work with libtool and automake, two more free tools. They should solve the portability problems with building shared libraries on multiple platforms for us. You'll find this in distributions of LessTif starting with release 0.85.
We use libtool for keeping the complexities of building and installing shared libraries out of LessTif. Therefore, if LessTif doesn't build a working shared library on some platform, you may want to check whether libtool already supports this platform. Contact the libtool mailing list if you're interested in details about the platforms supported by libtool. A link to libtool homepage is on our links page.
./configure make
That's all!
For more information on this topic check out the INSTALL document.
On some systems the configure script stops, saying
configure: error: You must have X11 Revision 5 or higher to compile LessTifwhile the system actually has X11r6.
Apparently this has to do with installations of Linux, in which the include files (under /usr/include) often contain symbolic links to the source directories (either on disk or on CD-ROM).
In such a situation, if one either removes the CD-ROM, or cleans up /usr/src, the effect will be dangling symbolic links under /usr/include which confuse our configure script.
The solution is obvious : make sure that your include files don't contain symbolic links to nonexistent files.
On the other hand, please make sure that you've built the entire distribution with the same configuration.
Not clear ? After running the "configure" command with its options, you should ideally run "make clean". Otherwise e.g. clients/Motif-1.2/mwm/Makefile may be configured such that it looks for stuff that isn't there in lib/Xm/* .
Your application fails to start and a "sophisticated" error message like the following is given:
Error: PANIC: no realize procedure specified for this widget.or
Error: attempt to add non-widget child "DropSiteManager" to parent "xmfoo" which supports only widgetsWe've seen this happen when the order of libraries upon linking was incorrect. The correct order is :
-lXm -lXt -lX11(see also Question 5.1)
Check out _LtCheckClassOfVendorShell()
in lib/Xm/Vendor.c.
A related message should be in the
mailinglist archive.
foo: error in loading shared libraries libXm.so.1: cannot open shared object file: No such file or directorythen you did not tell your system where to look for the shared libraries you have (hopefully) installed. The INSTALL file describes how to this.
Actually most LessTif widgets work somewhat. Many work fairly well. Things like traversal and focus handling have been worked on, but probably aren't really all that functional yet.
The menu system is quickly losing its child diseases (occasionally freezing the X server with grabs). If you're not in a rush when working the menus, the odds are low that you'll get in much trouble. Also dragging in the menus will get you in trouble faster than clicking.
In short, if something does not work quite right, tell us at lesstif@hungry.com and we'll try to help you as soon as we possibly can. In fact telling us about your problem is the fastest way to get your app to work with LessTif. Recommended !
In between releases, you can always grab get our latest development sources from our CVS repository.
The web site and all distributions contain a write-up on how to submit bug fixes or reports.
Look at the web site for a more accurate and timely list.
This was not easy though. The _Xm* functions seem to be undocumented in Motif 1.2 therefore we will make every effort to implement the functions as best we can.
One of our sources of information was "Writing Your Own OSF/MOTIF Widgets" by McMinds and Whitty, kindly donated to us by Linux International.
Many of the _Xm*
functions are exposed in
OSF/Motif® 2.0/2.1 where they changed names into Xme*
.
This means you can use sequences such as Multi_key+c+o to get ©, Multi_key+n+~ to get the ñ, etc.. These work because they're part of the ISO Latin 1 character set, which is based on one-byte representations.
The XmText and XmTextField widgets can handle input methods, as described above, but they don't have multibyte support. This means that Asian input methods which work with a multi-byte representation of a character will not work (yet).
The XmIm*() API is work in progress, this is probably not a problem for you as we have yet to discover an application that uses it.
We believe we're not doing really bad. In fact we did run some simple comparisons with official Motif 1.2.4 implementations which showed LessTif was even leaking less memory!
One package which can help you (and us) in tracking memory problems both in your application and in LessTif, is dmalloc, a library which can be obtained from www.dmalloc.com .
You can compile LessTif itself with dmalloc by using the --with-dmalloc option to the "configure" command.
Dmalloc is freely available software, but please note the license which is different from most other free software licenses.
In the examples we'll give now, we'll be using some installation directories that may differ from your installation. Please adjust your compilation parameters accordingly, don't try to fix your installation so it matches our examples. In our examples, X has been installed in /usr/X11R6 and LessTif has been installed in /usr/lesstif.
Compilation of applications is really a two-step process :
The compilation phase needs to know where to find include files. These are files that are referenced in the C (or C++) sources of your programs as
#include <Xm/Xm.h>and you should find them on your system in a couple of directories under /usr/lesstif/Motif1.2/include or /usr/lesstif/Motif2.0/include. Specifically the file mentioned above should show up as /usr/lesstif/Motif1.2/include/Xm/Xm.h or /usr/lesstif/Motif2.0/include/Xm/Xm.h .
For your compiler to find these files, it needs to be told where to look. Using the examples above, the flag needed would be -I/usr/lesstif/include . Note that you need to tell the compiler the same thing about the X Window System include files, you need to do that by using the -I/usr/X11R6/include flag. So together this gives
-I/usr/X11R6/include -I/usr/lesstif/include
The second step, linking all the source files together, requires similar flags. The linker needs to know where the libraries are, and additionally you need to tell it which libraries to include in the link process.
Again, using the example outlined above, we'd need to use the flags
-L/usr/X11R6/lib -L/usr/lesstif/libfor the linker to know where to look, and
-lMrm -lXm -lXt -lXext -lX11 -lSM -lICEto know which libraries to use. Note that the -lMrm library, as well as the -lXext library, aren't always needed, so you might get away with using flags like
-L/usr/X11R6/lib -L/usr/lesstif/lib -lXm -lXt -lX11 -lSM -lICENote that the order of the libraries is important on some systems, and less important on others. This means that an application writer better uses the right order, or his application won't build on some systems.
If the linking process fails, this probably means you didn't specify some library, or the required libraries aren't present on your system. Error messages indicating this are a long list of undefined symbols most of which have a name with an identical prefix, such as Xm.
In the following we list some prefixes and the related library.
prefix | linker command |
---|---|
Xt | -lXt |
Xmu | -lXmu |
Sm | -lSM |
Ice | -lICE |
Xp | -lXp |
Xdbe, Xext, XShape | -lXext |
Xm | -lXm |
Mrm | -lMrm |
The order in which you should specify these options is
-lMrm -lXm -lXt -lXmu -lXp -lXext -lX11 -lSM -lICEOf course not all of these libraries are always necessary, but in some cases more libraries may be required (-lsocket is another candidate here). Also make sure the linker is able to find the libs, e.g. it may be necessary to add an
-L/usr/lesstif/lib
or similar.
Once more, the compilation and installation guidelines for the application probably tell you which libraries to link with.
Finally, please make sure that you have the X development packages installed on your system, not only the X user stuff. Forgetting to install the development system could result in messages like Xm/Xm.h : cannot open file, or -lXt: library not found.
Nowadays more and more applications use GNU autoconf and GNU automake for the same purpose.
The imake program process an Imakefile and turns it into a Makefile. Often the Imakefile uses some template file that comes with the application, to specify additional options.
If you use imake directly to create the Makefile, then this will probably not work right, because you need to tell imake to read the LessTif configuration files. The mxmkmf program calls imake with the right parameters, so just using this should help.
It is also possible that the Imakefile file or some file used by it overrides some of LessTif's parameters. Please check whether EXTRA_INCLUDES, XMLIB, or XmClientLibs are overruled in these files. If they are, then this is probably the cause of the problem.
Using LessTif directly with C++ prompts the question on how to use class member functions as callbacks. Here's part of Ken's answer :
There are three common user problems with C++ callbacks.
Here's an example :
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.
Motif++ is one of the C++ wrappers for Motif/LessTif.