Eirik's take on things is how I recall hearing it is designed. The Firefox source in gtk2xtbin.c seems to be related to this. It's sounding from this discussion like this must be a bug in how Firefox pretends to be an Xt app, so I probably can't do much about it. I've worked around the problem for now by using dlopen() to use gtk instead in browsers that have it loaded, since they are probably gtk apps pretending to be Xt apps rather than real Xt apps. Thanks for the help! <div class="gmail_quote">2009/2/4 Eirik Byrkjeflot Anonsen <<a href="mailto:eirik@opera.com" target="_blank">eirik@opera.com</a>> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>Glynn Clements <<a href="mailto:glynn@gclements.plus.com" target="_blank">glynn@gclements.plus.com</a>> 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: </div>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 <a href="mailto:xorg@lists.freedesktop.org" target="_blank">xorg@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/xorg" target="_blank">http://lists.freedesktop.org/mailman/listinfo/xorg</a> </blockquote></div>