Bug#443600: konqueror-nsplugins: I think this was marked done prematurely

[Shai Berger <shai@platonix.com>]

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, so I 
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), and if that includes having an initialized GTK, 
then it is nspluginviewer's job to do so.

> 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.

GTK is also perfectly within their turf when they decide the meaning of their 
own API.

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).

> (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.

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.

And finally, you've ignored my point about konqueror hanging when this bug is 
triggered.

Hope this helps,

	Shai.