As older Xlib programs are ported to Xt it often makes sense to preserve
their Xlib-ness while still having Xt-based menus, scrollbars, and other
GUIisms of current Xt toolkits.  The basic problem in merging the two models
is in the event-delivery mechanism. In an Xt program, the application enters
an infinite loop in XtAppMainLoop() and Xt thereafter dispatches events to
widgets without the application's intervention; in contrast, Xlib programs
typically track the set of events they are interested in and the possible
windows on which those events can occur and hence call XNextEvent directly
and then determine what action to take on the event received.

One possible solution may be to widgetize the Xlib application. A faster
solution is probably to break XtAppMainLoop() into its components (R5 version
shown):

	void XtAppMainLoop(app)
		XtAppContext app;
	{
	    XEvent event;

	    for (;;) {
		XtAppNextEvent(app, &event);
		XtDispatchEvent(&event);
	    }
	}

and then change the dispatch call to be something like

	if (!XtDispatchEvent(&event))
		my_dispatch_xlib_event(&event);

That is, if Xt isn't interested in dispatching the event, it must be an event
on one of the windows created via the code incorporated from the Xlib program
and can be dispatched in the same way as in the original program.

You can also use this technique in Xt programs in order to handle events not
normally handled well by Xt; there is support in the translation/action
mechanism for being notified of PropertyNotify events, but it may be easier
to dispatch the event yourself, perhaps to receive a message from another
application on a window whose ID your application has made available.