You are currently viewing a snapshot of www.mozilla.org taken on April 21, 2008. Most of this content is highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If there are any pages on this archive site that you think should be added back to www.mozilla.org, please file a bug.

Skip to main content

Motif, Java, and Threading on X

By Erik van der Poel, Radha Kulkarni, and Kin Blas
Followup and discussion on netscape.public.mozilla.unix
Updated: 2-Nov-1998

The Problem

Japanese input does not work properly in the Motif text widgets used in AWT for Unix. It seems to work somewhat on Solaris, but very badly on IRIX and DEC.

The Reason

The Java AWT widgets are created separately in a separate shell widget, and then this shell widget is reparented at the Xlib level to a widget inside the Mozilla window. Since there is then no Xt parent relationship between the Java widgets and the Mozilla shell widget, the Japanese input method status bar cannot work properly.

Other Problems

In addition, the Java AWT widgets are created in a second XtAppContext (and a second X Display). And the events for this display are handled by a 2nd event loop, running in a separate thread called the AWT thread. Since the main
Mozilla thread does not do the timeout select for any AWT timer callbacks, the AWT widgets' carets do not blink properly. Also, there are color problems since the 2nd Display connection effectively means that Java is a separate X client.

Possible Solution

Basically, the Java widgets need to be created directly under the Mozilla widgets using normal Xt calls. This way, there is an Xt parent relationship between AWT widgets and Mozilla's shell widget.

Also, the 2 app contexts, the 2 displays and the 2 event loops should be merged into one, all in one thread. This solves the blinking caret problem, color problem, and probably several others.

Problems with this Solution

Java code currently expects things like class file fetches across the net to happen synchronously. The way it is currenly implemented, an X event triggers an AWT callback, which calls Java, which loads classes across the net, which blocks that thread. So if the X event is handled on the same thread as the thread that gets the network input, then there will be deadlock.

So I tried handling Java's X events on a separate thread, but then we had a different problem with XtDestroyWidget. The layout code recycles layout elements every now and then, so when it was handling some new network input, it
recycled an old Java element, which caused XFE to call XtDestroyWidget. However, this happened at a time when the X event thread was in XtDispatchEvent, which sets a variable called dispatch_level in the app context to 1. XtDestroyWidget does not actually destroy the widget if the dispatch level is non-zero.