XtDisplayToApplicationContext fails with "Error: Couldn't find per display information"

[Tristan Schmelcher]

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!

2009/2/4 Eirik Byrkjeflot Anonsen <eirik at opera.com>

> Glynn Clements <glynn at gclements.plus.com> 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
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg/attachments/20090220/1d38ad20/attachment.html>