Let me explain my reasonning as the upstream developper.
The plugin api implicitely mandates that one uses some basic Xt calls to capture gui events from the browser event loop. With some browsers, one can also set a flag to use the xembed protocol: it is then recommended to capture events using glib calls. In both cases, these are very basic calls that are unlikely to be ever removed or changed from either Xt or GLib. Too many programs depend on them. However it is most important that these calls affect the data structures of the browser event loop. In other words, one should be *certain* to use the same Xt or GLib version as the browser itself. Using a different version of libX11 would not be nearly as bad... In my experience, the danger of linking with a different version of Xt is greater than the danger of seeing a change in a few Xt functions that haven't changed in the last 20 years... This reasonning makes sense for the upstream distribution. In Debian, if you can be certain that all Debian browsers use the same Xt version, you can link with that one. Then change is quite trivial since 'configure.ac' contains code to explicitely remove -lXt and -lXext. I think this is slightly unwise, but without hard feelings. I also would like to point out that the current djvulibre plugin code, unmodified, produces binaries that have been shown to work with a large number of browsers including the original netscape, gecko based browsers, khtml based browsers and some versions of opera. I believe I have solid experience in that aspect of plugin programming... Happy new year to all of you and thanks for the precious help... - L. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
