Glynn Clements <[email protected]> writes: > Tristan Schmelcher wrote: > >> Hello all. Sorry if this is not the right place to send this, but I'm >> developing a plugin for Firefox on Linux and I've run up against a >> roadblock. In my plugin I'm being passed a pointer to an X "Display" struct >> (in NPP_SetWindow, for those of you that know NPAPI) and I'm calling >> XtDisplayToApplicationContext on it to get an app context to use in various >> Xt calls. Now on most systems this works fine--e.g., Ubuntu Dapper 32-bit >> with FF2 and Intrepid 32-bit with FF3 both work flawlessly. However, when I >> build a 64-bit version and try it on Ubuntu Hardy 64-bit with FF3, it >> doesn't work. When it enters XtDisplayToApplicationContext, I get "Error: >> Couldn't find per display information" on the console and the program exits. >> >> Does anyone know what could be causing this function to fail? I searched the >> web but without luck. > > AFAIK, the display must have been "registered" with Xt via > XtDisplayInitialize(). With a conventional Xt-based application, this > is done by e.g. XtAppInitialize(). > > Firefox isn't an Xt application, so I'm a bit surprised that it works > at all. However, digging deeper I see that libxul.so uses Xt:
This is a requirement in the netscape plug-in api. It passes a window that is documented to be an XmDrawingArea to the plug-in. However, most browsers ignore that and uses a plain Xt window instead. Obviously, the plug-in itself needs some way of accessing the window and receiving events. Painting can be done with plain X, but in order to receive events, the plug-in must register with the browser's main loop. So the only reasonable thing to do is to use Xt. (Yes, the netscape plug-in api is broken by design. The windowless style is slightly less broken, though.) eirik _______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
