I need to compile a Firebreath plugin for our ARM linux-based device. I don't see any section on the docs that mention how to specify what toolchain and compiler to use.
Anyone can give a tip on that?
Thanks!
The reason there is no section in the docs is because as far as I know nobody has ever done it =] (and I wrote FireBreath, so it's not unlikely that I would have heard about it)
This would be a cmake problem -- look at what the prep scripts are doing, particularly prepcommon.sh, and how they use cmake. You'd need to figure out how to tell cmake to use an arm-targetting toolchain. You also need to find out if there is anything different about the NPAPI implementation on your platform. Keep in mind as well that NPAPI in Firefox is going away in the release planned for early March.
FireBreath2 will support FireFox and Chrome via native messaging but I have no idea what may or may not be different on ARM for that. To do what you want to do you'll need to learn a bit more about both FireBreath and cmake.
Related
I've been trying to run a TCL/TK script in a browser so people with minimal computer knowledge can run it (my script) on all devices.
I've come across the TCL/TK plugin from 2006 but I can't get it to work. Even if I could, it doesn't contain the user friendliness I am looking for.
I also came across a website that runs TCL scripts in-browser but doesn't seem to recognise TK commands....
So far to distribute it to people I wrapped it into a .exe but people are requesting it to be used on mobile devices (with more mobility than a windows laptop).
Any one got some information to do this without rewriting all of my code?
Or an easy way to port a TCL/TK script to iPhone/iPad or Android (I don't think there will be any easy solution for this, that is why the browser concept made most sense to me)
Unfortunately, the browser plugin depends on the browser supporting the NPAPI specification, and that's now been largely removed from browsers (and was never supported on mobile devices). This has irritated quite a few other people too, and I don't think there's much you can do to fix it directly. So instead, let's look at some workarounds…
You might be able to use the NaCl support in Chrome on desktop systems, or you could package things up in a starpack (ActiveState's TDK is a commercial version of that, among other things) and for deployment to Android you can use Androwish (which I personally recommend). I'm nothing like as certain about solutions for iOS.
For plain Tcl try EmTcl, Tcl compiled with emscripten.
I am new to PPAPI development and have downloaded the already examples from here
However, even after coming across the documentation,
I am not able to build the project.
I have Microsoft Visual Studio 2010, Windows OS and Chrome:30.0.1599.65
I understand that once a dll is created, using the regsvr32 command will register the plugin, although getting the dll, even with available code, seems tough for me. Any help for building the dll is appreciated.
You will want to start here to download the and set up the SDK: https://developers.google.com/native-client/sdk/download
This page will take you through how to build and run the examples: https://developer.chrome.com/native-client/sdk/examples
This page goes over how to actually create your own plugin: https://developer.chrome.com/native-client/devguide/tutorial/tutorial-part1
And then you should read this entire section to code and structure your application: https://developer.chrome.com/native-client/devguide/coding/application-structure
If you need any third party libraries be sure to check here: https://chromium.googlesource.com/webports
Edit: Forgot to mention that you will want to use the same version of the pepper api as the version of chrome you're running (in this case pepper_30). Also, you have to use the NaCl toolchain (one of either glibc, newlib, or pnacl); you can't use the Visual C/C++ toolchains. I recommend trying pnacl now that it is available, as that is by far the most cross platform version, but if you run into trouble, you'll probably want to use the newlib toolchain as it has better support.
I have an idea of studying user behavior on the browser, for which I intend to make a Chrome/Firefox extension to study the behavior dynamically. I have some predefined libraries in Java and Python to analyze the results, which will be impossible to program in plain JavaScript.
Now for my question: is it possible to use third party libraries, especially those of Python or Java like plain function calls?
I have a vague idea about something like Java XPCOM or PyXPCOM for Firefox. However, for a beginner, it all looks so scary. I started making Add-On for Firefox, but got lost somewhere in the huge API.
I found Programming Chrome extensions easier than Firefox, but I couldn't come across something similar to XPCOM in Chrome.
How can I decide which one to go for?
Chrome - seems easy but I am not sure of its power.
Firefox - Seems powerful, but is it really possible to use any Java/Python Library?
Additionally, I came across this link that may be useful: How does someone use thirdparty libraries to be included in Firefox addons/extensions?
But seems like it mostly talks about C++ and XPCOM.
I have a vague idea about something like Java XPCOM or PyXPCOM for Firefox. But for a beginner, it all looks so scary.
I am not a beginner and JavaXPCOM/PyXPCOM are very scary (in addition to being barely maintained). As Firefox goes, it should be much easier to wrap your Java/Python library in an application and run it as an external process: https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsIProcess. Note that you cannot get data back (other than an exit code) so the application should write it to a file that you can then read in your Firefox extension. Not very elegant but it has the advantage of being doable.
As to Chrome, its extensions run in a sandbox and using Java or Python isn't possible. Only option is adding an NPAPI plugin to your extension. It is binary code meaning that it could do anything.
When writing Chrome extensions, you're limited to JavaScript unless you choose to use an NPAPI plugin, which lets you do pretty much anything, but is not recommended.
The other approach you could take is to implement your Java or Python code on the server and make requests from the chrome extension's JavaScript.
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/
I need to define a runtime environment for my development. The first idea is of course not to reinvent the wheel. I downloaded macports, used easy_install, tried fink. I always had problems. Right now, for example, I am not able to compile scipy because the MacPorts installer wants to download and install gcc43, but this does not compile on Snow Leopard. A bug is open for this issue, but I am basically tied to them for my runtime to be usable.
A technique I learned some time ago, was to write a makefile to download and build the runtime/libs with clearly specified versions of libraries and utilities. This predates the MacPorts/fink/apt approach, but you have much more control on it, although you have to do everything by hand. Of course, this can become a nightmare on its own if the runtime grows, but if you find a problem, you can use patch and fix the issue on the downloaded package, then build it.
I have multiple questions:
What is your technique to prepare a well-defined runtime/library collection for your development?
Does MacPorts/fink/whatever allows me the same flexibility of rehacking if something goes wrong ?
Considering my makefile solution, when my software is finally out for download, what are your suggestions about solving the potential troubles between my development environment and the actual platform on my user's machines ?
Edit: What I don't understand in particular is that other projects don't give me hints. For example, I just downloaded scipy, a complex library with lots of dependencies. Developers must have all the deps setup before working on it. Despite this, there's nothing in the svn that creates this environment.
Edit: Added a bounty to the question. I think this is an important issue and it deserves to get more answers. I will consider best those answers with real world examples with particular attention towards any arisen issues and their solution.
Additional questions to inspire for the Bounty:
Do you perform testing on your environment (to check proper installation, e.g. on an integration machine) ?
How do you include your environment at shipping time ? If it's C, do you statically link it, or ship the dynamic library, tinkering the LD_LIBRARY_PATH before running the executable? What about the same issue for python, perl, and other ?
Do you stick to the runtime, or update it as time passes? Do you download "trunk" packages of your dependency libraries or a fixed version?
How do you deal with situations like: library foo needs python 2.5, but you need to develop in python 2.4 because library bar does not work with python 2.5 ?
We use a CMake script that generates Makefiles that download (mainly through SVN)/configure/build all our dependencies. Why CMake? Multiplatform. This works quite well, and we support invocation of scons/autopain/cmake. As we build on several platforms (Windows, MacOSX, a bunch of Linux variants) we also support different compile flags etc based on the operating system. Typically a library has a default configuration, and if we encounter a system that needs special configuration the configuration is replaced with a specialized configuration. This works quite well. We did not really find any ready solution that would fit our purpose.
That being said, it is a PITA to get it up and running - there's a lot of knobs to turn when you need to support several operating systems. I don't think it will become a maintainance-nightmare as the dependencies are quite fixed (libraries are upgraded regularly, but we rarely introduce new one).
virtualenv is good, but it can't do magic - e.g. if you want use a library that just MUST have Python 2.4 and another one that absolutely NEEDS 2.5 instead, you're out of luck. Nor can virtualenv (or any other tool) help when there's a brand new release of an OS and half the tools &c just don't support it yet, as you mentioned for Snow Leopard: some problems are just impossible to solve (two libraries with absolutely conflicting needs within the same build), others just require patience (until all tools you need are ported to the new OS's release, you just need to stick with the previous OS release).