java plugin in nspluginviewer

[George Staikos]

On October 20, 2002 18:05, Till Krech wrote:
> There are several problems:
> 1) I do not get any debug output from nspluginviewer. It is started from a
> KProcess within the plugin_part in konqueror. My workaround: use
> receivedStderr signal and a slotStderr wich does a kdDebug. Not very nice.

  Does it not go to .xsession-errors?

> 2) Width and height of a plugin are set to 1600 x 1200 by default.
> Applets are then really that big (behind the scenes) and the embedded
> widget only shows a small part of most applets.
> The width and height attributes of an <object> tag are not passed to the
> plugin which only understands parameters such as
> <param name="width" value="400">
> I found a workaround by 'converting' the attributes to pseudo params
> __KHTML__WIDTH and __KHTML_HEIGHT in khtml/rendering/render_frames.cpp as
> it is already done with other attributes like this:
>       params.append( QString::fromLatin1("__KHTML__WIDTH=\"%1\"").arg(
> o->getAttribute(ATTR_WIDTH).string() ) );
>       params.append( QString::fromLatin1("__KHTML__HEIGHT=\"%1\"").arg(
> o->getAttribute(ATTR_HEIGHT).string() ) );

  I'm not sure about all of this stuff, but I do know that the 1600x1200 size 
was done on purpose to fix problems with other plugins.  If they were started 
too small, then resizing them up to the required size didn't work.

> 3) The java plugin does not work with user agent strings other than
> Netscape 4.7. It is possible to define a pseudo domain 'nspluginviewer' and
> to set the user agent string for this domain. But this makes not much
> sense. Why should a user be able/obligated to configure this ? Netscape
> plugins are for Netscape browsers. nspluginviewer can only handle ns4
> plugins.

   Yes I guess we could hardcode this to a NS user agent.  I dont' see why 
not...

> 4) there are crashes in the nspluginviewer because of memory corruption. I
> tried to run konqueror with valgrind --trace-children but it stops when
> loading the netscape plugin shared object file.

    This could be related to #5 maybe?  I fixed a lot of these memory problems 
in the past, but then again, maybe I missed some.

> 5) I found a (in my eyes) weird problem. Look at this (kdebase/nsplugins):
> In nsplugin.h:
> class NSPluginStreamBase : public QObject
> {
> Q_OBJECT
> ...
> private:
> ----->   QByteArray _queue;
> ...
> }
>
> and in nsplugin.cpp:
> NSPluginStreamBase::~NSPluginStreamBase()
> {
>    if (_stream) {
>       _instance->NPDestroyStream( _stream, NPRES_USER_BREAK );
>       delete _stream;
>    }
>
>    delete _tempFile;
> ----->   delete _queue;
> }
>
> _queue is not a pointer. What happens upon delete ? Isn't _queue deleted
> automatically when NSPluginStreamBase is deleted?

   Yes this looks rather bad to me.  Please fix that one.  Just remove the 
delete.


-- 

George Staikos