Hello as you might now NPAPI is deprecated.
What are the alternatives to this? I see skype released now the web version where you need to install a web plugin to make voice and video calls. Looking over what I installed I arrived to the conclusion that on chrome they are using Google Native Client: https://developer.chrome.com/native-client
But this one is not supported on firefox/safari (only chrome).
On Firefox/Safary I'm not sure what they are using.
So what are now the best alternatives for this kind of job where using c++ is mandatory (to extend an existing app and make it available as web plugin)
Silviu
After Chrome drop the NPAPI support, there is no-common technology support by Firefox/Chrome/Safari. You can consider about Firebreath 2.0. It allow you use one C++ implement to support different browser.
It's not released yet... If you like to try version 2.0, you can get source code from https://github.org/firebreath/firebreath (the "refactor" branch)
Note: version 2.0 make huge change, because the call between plugin and javascript are asynchronous! Upgrade from older version required lots of javascript change.
Related
We are looking for an easy way for our users to download and install a small client widget (it is a windows app) used with our (much larger) web app.
Our web app is currently only supported in Chrome.
Our concern is that the clickonce support piece may be missing from most Chrome installs.
The questions:
-- Is clickonce really going to be useful in this situation?
-- What is the best option for "one click" download-and-install for Chrome on windows?
ClickOnce uses NPAPI which is being removed from Chrome. You will need to look at NaCl, Native Messaging or PPAPI instead of ClickOnce. There used to be browser extensions that you could use, however they have been removed from the store (or no longer work).
Using Chrome should not matter, so yes Click once will be useful in this situation.
The only thing you need to worry about is your clients using Windows and the appropriate version of the .net framework. I hope this helps.
Is there a way to make a leaner HTML/Javascript -oriented build/package of the Mozilla XulRunner components, excluding some of the heavier XUL-platform features?
Background:
We are building a cross-platform application with a HTML/JavaScript GUI. The host app is running on .NET/Mono, and the GUI is rendered using Mozilla XulRunner via the GeckoFx wrapper. Everything is working great.
We have one issue: the XulRunner (9.0.x) components weighing at 28MB make the application installer a bit larger than we'd like. The XulRunner does not need to be deployed separately if the user already has Firefox installed, but we would want to reduce the footprint for the users who don't.
We've already excluded all XulRunner executables from the official release build to get the package down to its current size.
It occurs to me that we are only using a small subset of the XulRunner platform. We do not require any of the XUL features, only HTML, JavaScript and CSS. This leads me to think that we might be able to make a custom build which excludes some of the parts we don't need, but I'm not well-versed in the Mozilla build arcana.
Any help would be greatly appreciated!
You will typically use build options like --disable-tests (don't build those test executables) and --enable-optimize/--disable-debug. Also, you should be able to use --disable-xul option. However, you need to be aware that options like --disable-xul create builds that aren't quite as well tested as the official XULRunner. Other options that should be ok in a simple application:
--disable-jsd Disable JavaScript debug library
--disable-plugins Disable plugins support
--disable-view-source Disable view source support
--disable-accessibility Disable accessibility support
--disable-printing Disable printing support
--disable-crashreporter Disable breakpad crash reporting
--disable-mathml Disable MathML support
--disable-installer Disable building of installer
--disable-updater Disable building of updater
--disable-activex Disable building of ActiveX control
--disable-activex-scripting Disable building of ActiveX scripting support (win32)
--disable-feeds Disable feed handling and processing components
You can find other options by searching for MOZ_ARG_DISABLE_BOOL in configure.in.
I know that if I write a C++ plugin, then I need to have Linux, Mac, Windows versions at least but what's the full list of combinations? NPAPI is supported by many browsers so does that mean the exact same compiled NPAPI plugin binary/installer/whatever for Windows is ready for use in all those browsers on Windows which support NPAPI? Or do you have to 'compile' the same plugin code separately for each browser in some way?
Yes, a single NPAPI plugin runs in every NPAPI-supporting browser on a given platform, as long as you don't do anything to specifically undermine that (e.g., some people make NPAPI plugins but then add XPCOM code to them, making them Firefox-specific).
Additionally, as you probably saw in the answer to your other question, FireBreath can be used to create a single plugin that can be made to work cross platform on pretty much all browsers, including IE on windows.
FireBreath strongly discourages using things like XPCOM for exactly the reason that smorgan mentioned.
I need to write a browser plugin to communicate with another process, and it seems I have to use NPAPI plugins. Is there any example or open source NPAPI plugin I can refer to?
Many thanks for your reply.
Summary of answers
http://mxr.mozilla.org/seamonkey/source/modules/plugin/samples/
http://www.firebreath.org/
http://code.google.com/p/nixysa/
http://code.google.com/p/npapi-file-io/
2 and 3 are both frameworks to make plugin development easier.
I found one example at
http://mxr.mozilla.org/seamonkey/source/modules/plugin/samples/
you could also use the open source FireBreath plugin framework; they are nearing a 1.0 release for windows only, but it would not be hard to port it to linux; mac os shouldn't be bad either, but it will take a little work to get CMake to generate the correct bundle type =]
Yes, I am one of the primary maintainers, so I'm a bit biased. You can also find some good general information on how NPAPI works on my blog, starting here:
http://colonelpanic.net/2009/03/building-a-firefox-plugin-part-one/
Is it possible to create a complete client side application using HTML 5 (it will embed chat clients, stock ticker) + JavaScript, and then bundle is with underlining Firefox 3.5 engine, so that user can install it as a desktop app on Linux, and then it runs in its own window using firefox 3.5 engine. The app will store everything in local storage - like url, usernames etc, and will not interact with any local server.
It would pure HTML5 + JavaScript based client web app which would be packaged, and can be installed or launched from startup scripts.
Or instead of using firefox 3.5 engine, we can use Mozilla Prism to convert it to web app, and then bundle it.
Well, you should take a look at xulrunner (https://developer.mozilla.org/En/XULRunner). This is an engine to build portable applications... like firefox. You are getting full Gecko engine + full access to the environment, like a plain application. (XUL is something similar to HTML -- it is still XML-based UI description -- but it is better suited to develop desktop applications -- using native/almost native UI).
It sounds like what you're trying to do can be done with Adobe AIR (though there is no HTML5 support yet). Adobe AIR apps can be written with just HTML and JavaScript, though AIR uses the WebKit engine, not FireFox's.
The app part is surely doable (and will work just about everywhere, not just Linux), the bundling appears to be the more problematic part -- not every distro of Linux will like the specific way you built the bundled Firefox, not to mention that you're cutting yourself off from just about any non-Linux box on the planet (and every linux box with a non-x86 compatible processor, etc, etc)... all for the sake of that bundling. Can't you stop at the prism aka webrunner part, without bundling?
I'm almost sure I've seen something like this done with Qt Webkit. It was only a few lines of C++ to create the window with the web browser control and load a local page. The page created the UI of the application. I can't find the link though.
I second what liori said about using XULRunner. You can deploy your HTML application easily, and, more importantly, when you run into limitations of HTML 5 or its level of support in Gecko, you can work around it by using XUL APIs.
(AFAIK, Firefox 3.5 doesn't support any socket APIs in HTML content, and it doesn't support offline storage in web apps, only the localStorage part).