TOPIC: Running applications with LessTif
TOPIC: LessTif Development Progress
TOPIC: Compiling Applications With LessTif
TOPIC: Platform-specific Issues
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 favorite application does work, please tell us so we add it to the list of apps known to work.
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?
Meanwhile we also have to make a similar statement as in the answer for
question
Will LessTif be Motif2.0 Compliant?:
Our main focus is meanwhile Motif 2.1 compliance!
uil while the other executable is named
newuil. The latter uses libUil as opposed to
the older one which uses it's own code base.
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 (at least for major releases).
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. For several platforms there are also third-party binary packages available. Further information can be found in INSTALL and on our download pages.
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. http://www.opengroup.org/onlinepubs/7908799/xsh/limits.h.htmlA link to libtool homepage is on our
links page.
./configure make
For more information on this topic check out the INSTALL document.
configure: error: You must have X11 Revision 5 or higher to compile LessTifwhile the system actually has X11R6.
Another possibility is that you simply forgot to install the X11 development package (e.g. X11-devel RPM) so that the related headers are not yet installed on your system.
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/* .
CC, CFLAGS, LIBS, ...
Error: PANIC: no realize procedure specified for this widget.or
Error: attempt to add non-widget child "DropSiteManager" to parent
"xmfoo" which supports only widgets
We'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()
and _LtXmFixupVendorShell() in lib/Xm/Vendor.c.
A suitable test is in /test/Xm/Vendor/test4.c.
Also related messages should be in the
mailinglist archive.
The following explanation was a submission from
Martin Simmons:
The linking order problems are caused by these two symbols:vendorShellClassRec vendorShellWidgetClasswhich are defined *AND* referenced in both -lXm and -lXt. Somehow you have to convince the linker to use the -lXm definitions to satisfy the references in both -lXm and -lXt. The -lXt definitions should not be used. For typical elf-based dynamic loaders (Linux, Solaris etc), this is done by passing '-lXm -lXt' to the linker, which adds them both as SO_NEEDED sections to the executable. At runtime, the dynamic loader collects symbols from each SO_NEEDED section in the order it finds them, discarding symbols it already knows, and then fixes the references in all the loaded libraries using that combined symbol table. For typical static linkers, it is also done by specifying '-lXm -lXt' to the linker. In this case, the linker extracts some .o's from -lXm which contain user-referenced symbols and eventually ends up extracting -lXm:Vendor.o due to internal references in -lXm. It then does the same for -lXt, but doesn't need to extract -lXt:Vendor.o because it doesn't define anything that is still undefined.
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, send us an email 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.
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.
tests/ tree help tracking some leaks
as well.
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
dmalloc.com .
You can compile LessTif itself with dmalloc, check out the
Installation docs.
Dmalloc is freely available software, but please note the license
which is different from most other free software licenses.
Also similar tools may easily be used instead, e.g. we already
support dbmalloc.
If it's not a bug within the application it probably has to do with your compiler options. If it's indeed that, there are several possibilities.
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 which are shown below.
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
-lXm -lXt -lX11to know which libraries to use.
-L/usr/X11R6/lib -L/usr/lesstif/lib -lXm -lXt -lX11
We didn't list additional libraries which are often required.
e.g. our Motif® 2.1 compatible libXm requires an additional
-lXp -lXext. Therefore we list some prefixes and the related library,
so you can check which library you are missing.
| Prefix | Linker Command |
|---|---|
| Xt | -lXt |
| Xmu | -lXmu |
| Sm | -lSM |
| Ice | -lICE |
| Xp | -lXp |
| Xdbe, Xext, XShape | -lXext |
| Xm | -lXm |
| Mrm | -lMrm |
| Dt | -lDtPrint |
The order in which you should specify these options is
-lDtPrint -lMrm -lXm -lXt -lXmu -lXp -lXext -lX11 -lSM -lICEOf course not all of these libraries are always necessary, but in some cases even 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.
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.
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++ is one of the C++ wrappers for Motif/LessTif. It has a nice tutorial summarizing mechanisms. (used to be available from ftp://src.doc.ic.ac.uk/packages/motif++/, but this link is dead nowadyays. Try ftp-search on it!)
_LtXmFixupVendorShell() at the beginning
of main(), or at least before accessing the LessTif library
somehow. Note that this call was not always exported from earlier
versions of the Xm*.dlls. It does and will always exist from
version 0.92.26 and above.
Xm.dll while
all recent ones should be linked against the libraries following the
new naming scheme,
i.e. Xm_12.dll, Mrm_20.dll, etc.
Xm.dll
being made available as of LessTif version 0.91.8 (August 2000). This is
obviously quite outdated nowadays.
Xm.dll
either try the quick approach of renaming the dll or patching the executable
(both approahces are not really recommended) or built one from scratch.
In fact you just need to simply tweak the linker definition file
(Xm.def here) and the according Makefile.
NumLock.
Feedback