Hi all, I'd like to add a small comment to the last post from Leon.
I agree that libXt is not changing often. And that many browser would have loaded it already. So the plugin should "bid" that it's available... But that's dangerous, and I'll dig into Netscape / Mozilla specs to assert that it's recommended or not ... If the plugin is built on the debian machine that it targets (certainly :)...) it should use the default libXt provided on this distribution. So I see no problem for all debian built browsers. If a different browser is used (i.e. not built by debian), then, one solution could be to test them and mark them "supported" or "not supported" by this debian-distributed plugin. This clearly out-pass the debian work, and should be considered a "smart gift" from the maintainer ;). But I'd suggest another approach. The plugin could be a split between a very simple wrapper and a distinct application. The plugin would swallow the X window of the "real" plugin : the separate application. That's the design of FreeWRL's plugin and it works. Even with this design we can receive X events from the browser (passthrough). The separate application could have any dependency you can imagine. I'd recommend to adopt this easier approach. But it has the drawback to require a new plugin design / implementation from upstream. It also out-pass the Debian context ;). Hoping that this make sense. Best regards, Michel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
