Motif, Java, and Threading on X
Followup and discussion on netscape.public.mozilla.unix
The ProblemJapanese 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 ReasonThe 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 ProblemsIn 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 SolutionBasically, 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 SolutionJava 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
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.