current LC API first. No idea if it's workable w/o doing the other direction
the way Koos did, but I figure it's better than trying to get a few thousand
of untested LoC with completely new APIs working (and may be perhaps backportable),
especially since I did a lot of the work before and can adapt it.
This commit does:
- Update the SDK headers for some of the new functions/enums
- Handle the LC requests in the part, and forward them via DBus to the viewer
- Similarly, have the viewer properly unpack and pass to the scripting engine
- The scripting code for now merely does some API initialization, no actual work.
svn path=/trunk/KDE/kdebase/apps/; revision=1116993
Workaround a certain popular plugin's version 10 beta's inability
to figure out that 13 < 16.
(AKA, stub out some ABI r16 methods that get called despite us claiming only ABI r13 support.
I could perhaps do more than stubs, but I can't find any docs!)
BUG:164706
svn path=/trunk/KDE/kdebase/apps/; revision=825888
are two enum values of 13:
NPPVpluginKeepLibraryInMemory = 13, /* available in Mozilla 1.0 */
NPNVToolkit = (13 | NP_ABI_MASK),
and they are both used in certain switch statements; that's fine
as long as NP_ABI_MASK is non-zero, but for non-gcc compilers
it was, leading to compile errors in nsplugin.cpp (where it's weird
to have a switch on NPP* in a function that takes an NPN).
svn path=/trunk/KDE/kdebase/apps/; revision=790775
has the viewer <-> part interface mostly fixed, and
has beginnings of an XEmbed host for the plugin.
Unfortunately, that works part of the time at best
with r115, (probably none of the time on sites other than
youtube), and is quite crashy, partly because XEmbed flash
uses Xt anyway(!). I may have to go back to Xt only, not sure.
(Of course, Xt plugins don't work at all ATM). I need to consult
with some people on the best course of action, since this is getting very tricky,
and somewhat outside my area of expertise.
======================================================
Update headers some more; this will make compat with things like swfdec a tiny bit easier;
though we'll likely have to work with them to get things working anyway
svn path=/trunk/KDE/kdebase/apps/; revision=748159
has the viewer <-> part interface mostly fixed, and
has beginnings of an XEmbed host for the plugin.
Unfortunately, that works part of the time at best
with r115, (probably none of the time on sites other than
youtube), and is quite crashy, partly because XEmbed flash
uses Xt anyway(!). I may have to go back to Xt only, not sure.
(Of course, Xt plugins don't work at all ATM). I need to consult
with some people on the best course of action, since this is getting very tricky,
and somewhat outside my area of expertise.
======================================================
Update API header to provide the XEmbed variable names
svn path=/trunk/KDE/kdebase/apps/; revision=748155
I know that having a lower one is fine --- it implies potentially
smaller function structures, and higher version may require implementing
more stuff. The reason I asked is that I did something similar internally
when working on npruntime support, and I know flash 7 would crash with
some value of NP_VERSION_MINOR, but I am not sure whether it was 13 or 14.
svn path=/trunk/KDE/kdebase/apps/; revision=665308
Don't use long for 32 bit types on LP64 platforms.
Now Konqueror can use e.g. flashplugin on x86_64 with nspluginwrapper :-)
svn path=/trunk/KDE/kdebase/nsplugins/; revision=655588
