On Saturday 06 October 2007, Shai Berger wrote: > Hi Sune, > > Thanks for your clarification about the reason for the 100% CPU. For the > rest, however, > > On Saturday 06 October 2007, Sune Vuorela wrote: > > nspluginviewer can't initialize any kind of environment that a plugin > > might or might not use. remember that this is plugins. If a plugin needs > > something special, then that something needs to do it. > > Well, "ns" in nspluginviewer stands for NetScape, as far as I'm aware Correct. > doubt that GTK can be regarded as "something special". My understanding is > that it should strive to make the plugin feel as if it is being run by > netscape (or at least Gecko), Actually no, the plugin API does not specify any particual rendering engine or browser technology. > > either the bug could be fixud at it roots (=in adobe) or worked around > > where "special things" are needed (=gtk). > > I beg to differ twice. Adobe wrote a library to work in GTK applications, > so not initializing GTK in the library cannot be called a bug. From their > point of view, the plugin works perfectly in all environments where it was > designed to work. Adobe wrote a plugin for an application supporting the Netscape Plugin API. Since this API does not in any way specify that GTK is used for the APIs implementation, they can not assume this. Based on the API they can assume that the host application is having a Motif compatible event loop. Any plugin implementor therefore has to make sure other internal requirements are setup correctly in their code. > GTK is also perfectly within their turf when they decide the meaning of > their own API. No argument about that. Especially since gtk_init() is specified to be allowed to be called multiple times, where the first call will perform the initialization and every other call will basically be a no-op. There is no reason for the Adobe plugin not to call it. > The only problem is when a non-gtk application insists it can call gtk > libraries without initialization. Essentially, nspluginviewer has broken > the API's contract, and is now paying the consequences (or rather, the > users are). nspluginviewer doesn't use GTK, therefore can hardly have broken that API's contract. It fully implements the requirements of the NS Plugin API, thus not breaking this contract either. Adobe's QA has probably failed to detect the missing initialization, thus making the plugin break the GTK API contract > > (And firefox and other gtk browsers works because they *tada* are gtk > > browsers - making konqueror a gtk browser isn't a choice we want to take) > > While I understand and praise this desire for purity, I think it makes > little sense when loading plugins designed for a GTK browser -- which is, > after all, the whole point of nspluginviewer's existence, and more so, its > existence as a separate entity. In essence, by choosing to use the plugin, > the user has already told you they aren't interested in such purity. Well, as I wrote above, the plugin is not designed for a GTK browser. Even if it were designed for Firefox, which it isn', it wouldn't be designed for one. Firefox, including Gecko, does not depend on GTK but rather uses a kind of abstraction toolkit made by Mozilla so they can implement it differently depending on platform. > I also understand the reluctance to include a dependency on GTK at the > heart of KDE -- perhaps this means nspluginviewer should be taken out of > kdebase. However, what you're doing now is try to tell the writers of > plugins for Gecko-based browsers that there's a special, added requirement > for their plug-in to work in konqueror. I think this won't fly. While it would be nice to have different plugin runners for plugins with different toolkit requirements, there is currently no way a browser can ask a plugin which toolkit it requires. This might be changed in a newer version of the plugin API, e.g. like it can decide which MIME type a plugin is capable of handling. Until then a plugin's toolkit requirements is an implementation detail the plugin itself has to take care of, since neither the browser nor its plugin runner can. It's not a good idea for plugin hosts to work around bugs in plugins, because it will likely end up in a situation where a workaround for one plugin breaks another. Especially in cases where the bug is trivial to fix for the plugin creator. Cheers, Kevin
Attachment:
signature.asc
Description: This is a digitally signed message part.