how to implement a plugin?? NPAPI ??? XPCOM???
g
which is the best way to implement a plugin? At the moment I have a
basic understanding of how XPCOM works and how to make my C++ code
able to run as a plugin in firefox.
in http://developer.mozilla.org/en/docs/Plugins page there is a
recommentation to use NPAPI instead of (the old(??)) XPCOM...
the problem is that there isn't any example of how to use NPAPI with C+
+, there is only bla...bla...bla in this page...
are there examples??
Eric Shepherd
> in http://developer.mozilla.org/en/docs/Plugins page there is a
> recommentation to use NPAPI instead of (the old(??)) XPCOM...
You definitely want to use NPAPI instead of XPCOM for plugins.
The NPAPI Reference can be found here:
http://developer.mozilla.org/en/docs/Gecko_Plugin_API_Reference
I don't know offhand if we have sample code or not, but if we don't, we
should get some. Anyone?
--
Eric Shepherd
Developer Documentation Lead
Mozilla Corporation
http://www.bitstampede.com
Braden McDaniel
> g wrote:
>
> > in http://developer.mozilla.org/en/docs/Plugins page there is a
> > recommentation to use NPAPI instead of (the old(??)) XPCOM...
>
> You definitely want to use NPAPI instead of XPCOM for plugins.
>
> The NPAPI Reference can be found here:
> http://developer.mozilla.org/en/docs/Gecko_Plugin_API_Reference
>
> I don't know offhand if we have sample code or not, but if we don't, we
> should get some. Anyone?
I've been doing this for a while now; and I'm not sure what a Good
example would look like.
My impression is that NP_Initialize is under-documented. That impression
is based on this one: the NPP* and NPN* symbols are simply notational at
this point--they don't correspond to symbols that are used to establish
entry points; rather, all that matters are what gets set in the
NPNetscapeFuncs and NPPluginFuncs structs in NP_Initialize.
And then there is the Plug-in SDK code, which basically provides
machinery to wire NPP* and NPN* facades to the aforementioned structs.
My opinion of this code is that it introduces more complexity than it
manages to hide. Should a Good example use it? The plug-in API docs
observe that you don't *have* to use it; however, they don't do a very
good job of explaining to users how they'd replace it.
--
Braden McDaniel e-mail: <bra...@endoframe.com>
<http://endoframe.com> Jabber: <bra...@jabber.org>
g
> My impression is that NP_Initialize is under-documented. That impression
> is based on this one: the NPP* and NPN* symbols are simply notational at
> this point--they don't correspond to symbols that are used to establish
> entry points; rather, all that matters are what gets set in the
> NPNetscapeFuncs and NPPluginFuncs structs in NP_Initialize.
>
> And then there is the Plug-in SDK code, which basically provides
> machinery to wire NPP* and NPN* facades to the aforementioned structs.
> My opinion of this code is that it introduces more complexity than it
> manages to hide. Should a Good example use it? The plug-in API docs
> observe that you don't *have* to use it; however, they don't do a very
> good job of explaining to users how they'd replace it.
>
I don't understand why not XPCOM???
it's very easy to use it....just an interface, xpdl and just implement
the interface....
on the other hand with NPAPI I don't know from where to start....it's
a mess and I will have to do by hand things XPCOM already does...
thanks in advance
Martin Husemann
> I don't understand why not XPCOM???
Look at nsIPlugin.idl and search for @status.
That is putting it politely - it does not completely work, and probably noone
will fix any issues with it.
> it's very easy to use it....just an interface, xpdl and just implement
> the interface....
That is the same for NPAPI plugins. Just the way that the app gets the
pointer to your interface is different. Have a look at
modules/plugin/samples/4x-scriptable for a start.
Martin
aprisoft GmbH
http://www.aprisoft.de/?page=plugins.html
g
> That is the same for NPAPI plugins. Just the way that the app gets the
> pointer to your interface is different.
can you please explain more here? an example?
> Have a look at
> modules/plugin/samples/4x-scriptable for a start.
I do work with this!!
nsScriptablePeer.h
nsIScriptablePluginSample.idl
etc...
I haven't realise the diff between NPAPI / XPCOM
thanks in advance
bip...@gmail.com
> Hello,
>
> which is the best way to implement a plugin? At the moment I have a
> basic understanding of how XPCOM works and how to make my C++ code
> able to run as a plugin in firefox.
>
> recommentation to use NPAPI instead of (the old(??)) XPCOM...
>
> the problem is that there isn't any example of how to use NPAPI with C+
> +, there is only bla...bla...bla in this page...
> are there examples??
Have you tried these links -
http://www.mozilla.org/projects/plugins/npruntime.html - for npruntime
API specs
For sample npruntime plugin - http://www.mozilla.org/projects/plugins/
Martin Husemann
> I haven't realise the diff between NPAPI / XPCOM
>
plug ins vs. NPAPI ones.
See modules/plugin/samples/testevents - the RegisterSelf() call will
fail with all current browsers, so you have to jump through various
hoops to get your plug in loaded. And the difference I meant was the
nsIPluginInstance::GetPeer() method vs. the NPAPI GetValue() hack.
Really sorry for the confusion!
g
>
there is nothing in npruntime.html, it's just an API reference....
what I want is an example( there are in sdk) + the rational behind,
how it works and why so I will be able to create...
not just copy paste from the examples and fix and try
again...again...again...until I finally create the plugin...
thanks...
P.S. I have found a webpage : http://www.iosart.com/firefox/xpcom/
which is very good for XPCOM plugins, is there a similar page for
NPAPI?
Braden McDaniel
>> My impression is that NP_Initialize is under-documented. That impression
>> is based on this one: the NPP* and NPN* symbols are simply notational at
>> this point--they don't correspond to symbols that are used to establish
>> entry points; rather, all that matters are what gets set in the
>> NPNetscapeFuncs and NPPluginFuncs structs in NP_Initialize.
>>
>> And then there is the Plug-in SDK code, which basically provides
>> machinery to wire NPP* and NPN* facades to the aforementioned structs.
>> My opinion of this code is that it introduces more complexity than it
>> manages to hide. Should a Good example use it? The plug-in API docs
>> observe that you don't *have* to use it; however, they don't do a very
>> good job of explaining to users how they'd replace it.
>>
>
> I don't understand why not XPCOM???
Because it's deprecated. Which means it's not inconceivable that these
interfaces could go away in some future version of the runtime.
(It's also awkward and unfinished--kind of like the rest of XPCOM, only
to a greater degree.)
> it's very easy to use it....just an interface, xpdl and just implement
> the interface....
Scripting is a little more difficult to set up using npruntime than it
was using XPCOM; on the other hand, npruntime is more flexible. Aside
from that, NPAPI is no more difficult; it is in some respects easier,
since it's basically a C interface.
> on the other hand with NPAPI I don't know from where to start....it's
> a mess and I will have to do by hand things XPCOM already does...
Having written to the plug-in API back when the XPCOM plug-in API was
current, then to the hybrid NPAPI+XPCOM-for-scripting, and now to the
NPAPI+npruntime API, I can say that XPCOM does relatively little for you
as far as writing a plug-in is concerned. npruntime might be a little
more verbose than the ScriptablePeer stuff on the C++ side; on the other
hand, you don't have to maintain an IDL file in parallel with npruntime.
Feel free to have a look at OpenVRML's plug-in:
Note that it does not use the plug-in SDK. It does relatively little in
terms of scripting; however, the set-up machinery is there.
Braden
Shadow2531
> g wrote:
Can someone create example Win32 npruntime plugin code like this:
Mime type + extension:
application/x-npruntime-test .nrt
methods:
print(): When called, prints "Hello, world!" in the plugin area.
(Plugin area would have white background. Text would be black.)
attributes:
Has hardcoded size of 200 x 200;
Then, how *exactly* (step-by-step) to build it, including direct links
to any dependencies needed for the build process.
I'd really like to just be able to download some includes and libs and
build the dll with Mingw. Is there a libnpruntime that you an just
download. Is the Gecko sdk the only place to get the includes?
Or, how bout a zip file that contains the example like about and
everything that's needed to build it?
Thanks
--
Mike
Braden McDaniel
> > Have you tried these links -
> >
> > http://www.mozilla.org/projects/plugins/npruntime.html- for npruntime
> > API specs
> >
> > For sample npruntime plugin -http://www.mozilla.org/projects/plugins/
>
> there is nothing in npruntime.html, it's just an API reference....
The npruntime example is at the second URL you were given.
Unfortunately that example is a bit buggy; but it's not totally useless.
> P.S. I have found a webpage : http://www.iosart.com/firefox/xpcom/
> which is very good for XPCOM plugins, is there a similar page for
> NPAPI?
As far as I can tell, that page has nothing to do with XPCOM plug-ins.
It seems to be about writing XPCOM components.
g
> Having written to the plug-in API back when the XPCOM plug-in API was
> current, then to the hybrid NPAPI+XPCOM-for-scripting, and now to the
> NPAPI+npruntime API, I can say that XPCOM does relatively little for you
> as far as writing a plug-in is concerned. npruntime might be a little
> more verbose than the ScriptablePeer stuff on the C++ side; on the other
> hand, you don't have to maintain an IDL file in parallel with npruntime.
>
I don't have to use IDL with NPAPI?? if yes, why in the examples there
is a use of IDL??
I am lost:-(
> Feel free to have a look at OpenVRML's plug-in:
>
> <http://openvrml.cvs.sourceforge.net/openvrml/openvrml/mozilla-plugin/...>
>
> Note that it does not use the plug-in SDK. It does relatively little in
> terms of scripting; however, the set-up machinery is there.
I had a look, you used to have IDL scipts but you remove them...
could you please explain me here, I think the major diff between XPCOM
and NPAPI is IDL...
am I correct??
thanks in advance
g
> As far as I can tell, that page has nothing to do with XPCOM plug-ins.
> It seems to be about writing XPCOM components.
>
Braden McDaniel
Er... Where? Certainly not the MyComponent example.
Braden McDaniel
> > Having written to the plug-in API back when the XPCOM plug-in API was
> > current, then to the hybrid NPAPI+XPCOM-for-scripting, and now to the
> > NPAPI+npruntime API, I can say that XPCOM does relatively little for you
> > as far as writing a plug-in is concerned. npruntime might be a little
> > more verbose than the ScriptablePeer stuff on the C++ side; on the other
> > hand, you don't have to maintain an IDL file in parallel with npruntime.
> >
>
> I don't have to use IDL with NPAPI?? if yes, why in the examples there
> is a use of IDL??
> I am lost:-(
Because that example is obsolete.
> > Feel free to have a look at OpenVRML's plug-in:
> >
> > <http://openvrml.cvs.sourceforge.net/openvrml/openvrml/mozilla-plugin/...>
> >
> > Note that it does not use the plug-in SDK. It does relatively little in
> > terms of scripting; however, the set-up machinery is there.
>
> I had a look, you used to have IDL scipts but you remove them...
> could you please explain me here, I think the major diff between XPCOM
> and NPAPI is IDL...
> am I correct??
Prior to the introduction of the npruntime extensions to NPAPI, XPCOM
was the only avenue by which a plug-in could be made scriptable. This
was the hybrid NPAPI+XPCOM-for-scripting iteration of the plug-in API
that I alluded to earlier. Prior to that API (and now we're reaching
back to relatively early in Mozilla development), a 100% XPCOM plug-in
API was promoted as a replacement for NPAPI. It is plug-ins using this
API that are typically called "XPCOM plug-ins".
Martin Husemann
based api a lot more - IMHO it is way easier to create a plugin with
that if you already have a working ActiveX version (and that is what my
clients usually ask for first).
Maybe a xpidl option to generate the necessary mappings from an IDL file
for a npruntime plugin would be usefull?
My other big wish for an improvement would be for nsIDOMPlugin to
provide a version string (compatible with javascript InstallVersion), so
that sites could easily check not only for a supported mime type, but
also for a minimal version of the installed plugin.
Thanks for listening ;-)
Martin
--
aprisoft GmbH
http://www.aprisoft.de/?page=plugins.html
Shadow2531
> Can someone create example Win32 npruntime plugin code ...
There's this npruntime example
<http://my.opera.com/Diniska/homes/files/test.zip> from
<http://my.opera.com/community/forums/topic.dml?id=103184>.
I was able to build that with vc++ express and the Windows SDK.
I installed the windows sdk and visual c++ express. I loaded
npruntime_test.sln and after setting user32.lib as a dependency and
adding
"F:\Program Files\Microsoft Platform SDK for Windows Server 2003
R2\Include\mfc" to the vc++ directories in options, I was able to build
the dll.
The build process installs the dll to "C:\Program
Files\opera9\program\plugins".
(in the zip file is a test.html so you can test the plugin.)
Maybe someone can use that example to make a better and easier example?
--
Mike
WooJin Chung
I've compiled it and it shows me whole bunch of warnings, mainly about
type castings. For instance, the compiler says type casting from size_t
to uint32_t might cause a loss of data. Does it happen to you too?
I didn't set user32.lib as a dependency, nor did add the mfc directory
to the vc++ directories in options. But I don't think this is the
critical factor, since it has nothing to do with type casting.
The other warnings occur in npruntime.h. They say on line 949 there's a
character that can't be showed properly. The compliers tells me to set
the source code type to unicode. Well I guess it's simple to do this so
it doesn't seem to be a big problem.
So, did you get the warnings I got?
Shadow2531
I really only know Mingw (which won't compile this without editing the
source to swap all the vc++-specific security-enhanced _s C functions
with the regular ones + a few other mods), but here's exactly what I
get in vc++ express + the windows sdk:
(describing extra steps and info just in case it helps someone)
Just loading up the project (npruntime_test.sln) and selecting "Build
solution", this is what I get:
------ Build started: Project: nprttest, Configuration: Debug Win32 ------
Compiling...
np_entry.cpp
npn_gate.cpp
npp_gate.cpp
plugin.cpp
plugin.cpp(252) : warning C4267: 'initializing' : conversion from
'size_t' to 'uint32_t', possible loss of data
plugin.cpp(289) : warning C4244: 'argument' : conversion from 'LPARAM'
to 'LONG', possible loss of data
plugin.cpp(289) : warning C4312: 'type cast' : conversion from 'LONG'
to 'WNDPROC' of greater size
plugin.cpp(293) : warning C4311: 'type cast' : pointer truncation from
'CPlugin *const ' to 'LONG'
plugin.cpp(298) : warning C4312: 'type cast' : conversion from 'LONG'
to 'HINSTANCE' of greater size
plugin.cpp(307) : warning C4244: 'argument' : conversion from 'LPARAM'
to 'LONG', possible loss of data
plugin.cpp(307) : warning C4312: 'type cast' : conversion from 'LONG'
to 'WNDPROC' of greater size
plugin.cpp(425) : warning C4267: 'initializing' : conversion from
'size_t' to 'uint32_t', possible loss of data
plugin.cpp(479) : warning C4267: 'initializing' : conversion from
'size_t' to 'uint32_t', possible loss of data
plugin.cpp(492) : warning C4312: 'type cast' : conversion from 'LONG'
to 'CPlugin *' of greater size
Generating Code...
Compiling resources...
Compiling manifest to resources...
Linking...
Creating library Debug/nprttest.lib and object Debug/nprttest.exp
plugin.obj : error LNK2019: unresolved external symbol
__imp__CreateWindowExA@48 referenced in function "public: unsigned
char __thiscall CPlugin::init(struct _NPWindow *)"
(?init@CPlugin@@QAEEPAU_NPWindow@@@Z)
plugin.obj : error LNK2019: unresolved external symbol
__imp__GetWindowLongA@8 referenced in function "public: unsigned char
__thiscall CPlugin::init(struct _NPWindow *)"
(?init@CPlugin@@QAEEPAU_NPWindow@@@Z)
plugin.obj : error LNK2019: unresolved external symbol
__imp__SetWindowLongA@12 referenced in function "public: unsigned char
__thiscall CPlugin::init(struct _NPWindow *)"
(?init@CPlugin@@QAEEPAU_NPWindow@@@Z)
plugin.obj : error LNK2019: unresolved external symbol
__imp__MessageBoxA@16 referenced in function "private: void __thiscall
CPlugin::_GetNodes(struct _NPVariant)"
(?_GetNodes@CPlugin@@AAEXU_NPVariant@@@Z)
plugin.obj : error LNK2019: unresolved external symbol
__imp__DefWindowProcA@16 referenced in function "long __stdcall
PluginWinProc(struct HWND__ *,unsigned int,unsigned int,long)"
(?PluginWinProc@@YGJPAUHWND__@@IIJ@Z)
nprttest.dll : fatal error LNK1120: 5 unresolved externals
Build log was saved at "BuildLog.htm"
nprttest - 6 error(s), 10 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
As you can see, I need to link to user32.lib. (I mentioned in the
previous mail that I had to set up the WinSDK directory, but only
because it wasn't set up before.)
So, just like with the debug build, I go to project -> properties ->
linker -> input -> and add user32.lib
Then, I choose to build the solution again (without cleaning) and I get this:
------ Build started: Project: nprttest, Configuration: Debug Win32 ------
Linking...
Creating library Debug/nprttest.lib and object Debug/nprttest.exp
Embedding manifest...
Build log was saved at "BuildLog.htm"
nprttest - 0 error(s), 0 warning(s)
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
Which shows that it works.
Project -> properties -> general btw, is where the output is set to
"c:\Program Files\Opera9\program\plugins\nprttest.dll".
Anyway, once I rebuild the solution, I get the following, which shows
you the exact warnings I get:
------ Build started: Project: nprttest, Configuration: Debug Win32 ------
Compiling...
np_entry.cpp
npn_gate.cpp
npp_gate.cpp
plugin.cpp
plugin.cpp(252) : warning C4267: 'initializing' : conversion from
'size_t' to 'uint32_t', possible loss of data
plugin.cpp(289) : warning C4244: 'argument' : conversion from 'LPARAM'
to 'LONG', possible loss of data
plugin.cpp(289) : warning C4312: 'type cast' : conversion from 'LONG'
to 'WNDPROC' of greater size
plugin.cpp(293) : warning C4311: 'type cast' : pointer truncation from
'CPlugin *const ' to 'LONG'
plugin.cpp(298) : warning C4312: 'type cast' : conversion from 'LONG'
to 'HINSTANCE' of greater size
plugin.cpp(307) : warning C4244: 'argument' : conversion from 'LPARAM'
to 'LONG', possible loss of data
plugin.cpp(307) : warning C4312: 'type cast' : conversion from 'LONG'
to 'WNDPROC' of greater size
plugin.cpp(425) : warning C4267: 'initializing' : conversion from
'size_t' to 'uint32_t', possible loss of data
plugin.cpp(479) : warning C4267: 'initializing' : conversion from
'size_t' to 'uint32_t', possible loss of data
plugin.cpp(492) : warning C4312: 'type cast' : conversion from 'LONG'
to 'CPlugin *' of greater size
Generating Code...
Compiling resources...
Compiling manifest to resources...
Linking...
LINK : nprttest.dll not found or not built by the last incremental
link; performing full link
Creating library Debug/nprttest.lib and object Debug/nprttest.exp
Embedding manifest...
Build log was saved at "BuildLog.htm"
nprttest - 0 error(s), 10 warning(s)
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
As you can see, it works. (That's all at the default Warning level of
3 under probject -> properties c/c++. (Wp64 is also enabled.)
Anyway, after switching to release build (and adding user32.lib as a
dependency), I get this output:
------ Build started: Project: nprttest, Configuration: Release Win32 ------
Compiling...
plugin.cpp
plugin.cpp(252) : warning C4267: 'initializing' : conversion from
'size_t' to 'uint32_t', possible loss of data
plugin.cpp(289) : warning C4244: 'argument' : conversion from 'LPARAM'
to 'LONG', possible loss of data
plugin.cpp(289) : warning C4312: 'type cast' : conversion from 'LONG'
to 'WNDPROC' of greater size
plugin.cpp(293) : warning C4311: 'type cast' : pointer truncation from
'CPlugin *const ' to 'LONG'
plugin.cpp(298) : warning C4312: 'type cast' : conversion from 'LONG'
to 'HINSTANCE' of greater size
plugin.cpp(307) : warning C4244: 'argument' : conversion from 'LPARAM'
to 'LONG', possible loss of data
plugin.cpp(307) : warning C4312: 'type cast' : conversion from 'LONG'
to 'WNDPROC' of greater size
plugin.cpp(425) : warning C4267: 'initializing' : conversion from
'size_t' to 'uint32_t', possible loss of data
plugin.cpp(479) : warning C4267: 'initializing' : conversion from
'size_t' to 'uint32_t', possible loss of data
plugin.cpp(492) : warning C4312: 'type cast' : conversion from 'LONG'
to 'CPlugin *' of greater size
npp_gate.cpp
npn_gate.cpp
np_entry.cpp
Generating Code...
Compiling resources...
Linking...
Creating library Release/nprttest.lib and object Release/nprttest.exp
Embedding manifest...
Build log was saved at "BuildLog.htm"
nprttest - 0 error(s), 10 warning(s)
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
So, to sum it up, I get 10 warnings.
Hope that helps.
--
Mike