I am starting to work on a browser extension and because of the nature of the extension I need to develop it in C++. I am currently working with Firefox but would like my code to be portable across browsers. First of all is there a library or an interface (like the NPAPI) that I can use to ensure this for extensions? What are the things I need to worry about?
I am not using XPCOM and instead writing the functionality in C++ so that I can just compile the library for each platform and can bundle it with the extension for each browser. For Firefox, I am using XUL to develop the JS wrapper for my extension and an IDL file generates the c++ interface for me. Can I do something better? I just want to make sure I am not going down the wrong path.
EDIT: Please also suggest if there is a better forum for this type of question.
My background: a few years back, I worked on a cross-platform, cross-browser NPAPI plugin that used OpenGL to do image rendering. I've paid some attention to the space since then, but it's not what I do nowadays. I've written non-plugin extensions for Firefox but not Safari or Chrome.
A lot depends on exactly what you want your extension to do, and what sort of user interface you want to present. Different browsers have different ideas of what extensions may and may not do.
If you just wanted to display images or video in a custom format, NPAPI is probably your best bet. NPAPI is fundamentally a thin wrapper around native platform APIs. As such, cross-platform NPAPI code has to deal with individual platform quirks, as well as different levels of support for NPAPI from browsers. Google has a project called Pepper to fix some of NPAPI's issues, but Pepper doesn't yet have support from any browser besides Chrome.
Google's Native Client project provides an alternative to NPAPI for running native code, but it imposes restrictions on native code. For example, pthreads are allowed, but network access isn't. There is a NaCL subproject called c_salt which appears to address the sort of HTML/JS UI + native code integration you seek. Unfortunately it's still in the design phase, and thus isn't terribly helpful for writing extensions today.
My understanding is that, for now, a cross-browser extension which integrates with the browser UI and also integrates with native code is not feasible. Safari and Chrome both restrict extensions much more than Firefox does, and only allow extensions written in JavaScript. I don't know if it's possible to have an extension in Safari or Chrome interact with a browser plugin written in NPAPI. I'm guessing it's either impossible or incredibly painful.
Overall, you'll find life much, much easier if you carefully restrict which browsers and platforms to target. Exactly which browsers and platforms to choose is something that only you can decide.
Not many know about it, but yes, you can write cross browser plugins using Qt. :-)
You can use the QtBrowserPlugin just for that.
The QtBrowserPlugin solution makes it
easy to write browser plugins that can
be used in Mozilla FireFox, Safari,
Opera, Google Chrome, QtWebKit and any
other web browser that supports the
"Netscape Plugin API", NPAPI.
QtBrowserPlugin is part of the Qt Solutions packages.
Related
I am a C++ programmer, but for some reason, I have to develop a website by myself(My own commercial project). I don't want to take a lot of time to study JavaScript and something else. It is possible to just use QT and WebAssembly (instead of HTML + CSS + JavaScript) to develop a front-end web?
Yes, it's absolutely possible and I'm currently doing it for a project but you should do it carefully based on the project requirements, running environment and your own backgrounds.
Here are some problems you may encounter:
The output .wasm file may get too large. Generally, it won't be suitable for public domain applications.
In low-end devices, maybe you find it laggy if you don't do enough code level optimizations.
Threads are not officially supported yet (as of Dec. 2019) by major browsers but tech-preview is available. This is not a real big problem as it would be a standard feature soon.
Native virtual keyboard won't work on mobile devices but the work is in progress.
These were my own major problems with Qt for WebAssembly.
Despite this, I find it much more flexible than HTML+CSS. QML is really a nice language for UI development. Creating animated UIs is quite easy and straight-forward.
You can also use many JavaScript libraries in your QML code like Lodash and Moment or any other js library that does not refer or manipulate window DOM.
Yes, it is possible. But you should do not do it if only reason is reject for learning new technologies.
For now (I'am writing this answer when Qt 5.14 is present) Qt for webassembly is deployed as official platform. Unfortunately it is young platform support with a lot of problems and possible future changes. Qt team do really good job so next version will be better. 5.14 is much better than 5.13 in webassembly context but still need fixes.
You should know Qt for webassembly will support only a few Qt modules, excluding widget. Yes, you can only use QML for GUI.
Qt for webassembly was created for the purpose of port one code base in other platform (it it generally Qt develop way, please see Qt for MCU). With other technologies in this stack like QRemoteObject is very interesting technologies. It was not created for websites in normal network. Main Qt for webassembly target are internal network systems and remote control of devices. Pay attention about this.
Unfortunately, not all browser will support webassembly right. Please see Qt for weassembly support notes.
Additional, in Qt you can't find build-in rest-API handle or other standard web technologies to integrate with your existing backed.
Is there an easy way to port a C++ OpenGL app to a browser? It's already ported to PC, Mac and iOS. If there is some relatively easy way, would that be portable between computer browsers? I would have to use different binaries for different platforms, of course. I remember hearing something about some sandboxed environment for Chrome some time ago, but that would exclude the other browsers. How did they (id?) do with Quake in the browser?
If you're already targeting ES 2.0 for iOS your shaders should work as-is with WebGL. JavaScript ahoy!
id Software uses a giant plugin for Quake Live.
Try Google's Native Client or NaCl, if you want a lazy port.
But if you want to do a real port - refer to those two examples:
blog series about porting existing C++ game to html5 (sponsored by Opera)
short article about porting existing Objective-C game to html5 (sponsored by Microsoft).
sad example of porting popular copyrighted game from C to JavaScript (sponsored by Mozilla, with extra help of Zenimax)
If you was asking about QuakeLive - that is a custom plugin, made by Id Software. Similar functionality can be achieved with Flash or Unity plugins.
You can use Mandreel if you want the least amount of work. Another option is Emscripten but that only converts your C++, it doesn't provide all the APIs like Mandreel does.
Is there an easy way to port a C++ OpenGL app to a browser? It's already ported to PC, Mac and iOS. If there is some relatively easy way, would that be portable between computer browsers?
You could try to recompile it into JavaScript, that's what browsers execute. If you don't expect the user to install some browser plugin, you can't give them native code. Of course when in a JavaScript environment many of the things you're accustomed from native executables don't work. For examples you no longer can access a file system. You must use either DOM storage, cookies, download/upload resources from a server.
There is some libraries that lets you run C++. So, it is it possible to run a game that uses directx full mode screen?
Google is developing a tool to allow this kind of thing via Chrome. It is called Chrome Native Client, or NACL for short. http://blog.chromium.org/2010/05/sneak-peek-at-native-client-sdk.html
In general, no. Most online games are written with Javascript, Flash, the newly hatchedd HTML5 and similar technologies. Perhaps C++ integration is possible on some level, but you definitely cannot write a browser-hosted game purely and entirely in C++.
it could also be done with an ActiveX control. ActiveX only works in IE. there are Netscape plugins that work in other browsers. so make a solution that contains both. you need a book on ActiveX/COM/OLE. Better yet, take a class if you can find one, you will learn far more, because COM is not an easy subject to just read about and then really do - versioning is a big problem.
nope, not supported in firefox. but read this: http://www.google.com/chrome/intl/en/webmasters-faq.html#activex
some people may have activex controls disabled. if this is the case, your game will not run. you will have to tell the user that they will need to change their security settings in IE. you can get feedback from the object element in javascript as to whether or not the activex loaded. there is code out there for that.
http://msdn.microsoft.com/en-us/library/7sw4ddf8%28v=vs.85%29.aspx
examples are all over the internet.
This might be a naive question, but when using a python framework, what approaches are available to provide the kind of functionality that can be exposed using an ActiveX control as an embedded object. The specific example I have in mind is a third party ocx we are using in some ASP.NET pages to provide TWAIN interaction on the client side. I'd like to avoid browser and platform specific approaches, if possible.
Your question is a little confused. If you're talking client-side, it makes no difference whether you are using Python or ASP.NET on the server - you can still embed the object in the HTML and the client will run it, assuming they are using Internet Explorer. However, this already is a browser- and platform-specific approach.
The best alternatives are probably Flash and Silverlight - although the latter is from Microsoft, it is pretty well cross-platform now since all the main browsers and OSs have implementations of it. Flash is still more widespread for now, though.
Is there any browser I could embedd in C++ application on Windows?
I need all features typical browser has (HTTP client, cookies support, DOM style HTML parser, JavaScript engine) except rendering.
Because I don't need rendering capability (and that's rather big part of a browser) I would prefer a browser with non monolithic design so I wouldn't have to include rendering stuff into my project.
It would be nice if it had C++ rather than C API.
I need this embedded browser mainly because I have much trouble finding C++ HTML parser which could handle broken HTML like browsers do.
If you know any, please answer Library Recommendation: C++ HTML Parser SO question or at least vote on it to increase a chance someone will give a good answer.
Sounds like all you need is something like libcurl which is an HTTP library and will let you do GET/POST/etc.
When I think browser I generally think rendering/JavaScript and not HTTP library.
Edit
In that case I'd look at WebKit (which I think has a C++ API) and hope you don't have to pull too much in.
Edit Again
On second thought (since rendering is such a big part of what browsers do), you might be better off using a stand-alone JS engine like SpiderMonkey and a stand-alone XML parser like Xerces-C (plus maybe tidy to make your HTML into XML).
I'm a bit confused by your question regarding embedding a web browser for which you don't need rendering capabilities. A web browser is rendering web pages by definition, unless you just need HTTP and XML with JavaScript capabilities which is a subset of a browser functionalities?
If you need a web browser to embed in your C++ application, I would suggest to consider Qt that comes with the WebKit plugin. It is C++, LGPL and has a very nice IDE (Qt Creator). I tried Qt with Qt Creator on unix (Ubuntu) and it was very impressive. The debugger is a bit light but it is just the first version. The adapter of Qt into visual c++ 2008 is now free.
You might also want to check out Awesomium-- it's free for non-commercial use and has all of the features you're looking for (if you don't need rendering, simply don't use it).
There is a project called CEF = The Chromium Embedded Framework - it is:
a simple framework for
embedding Chromium-based browsers in other applications. It is a
BSD-licensed open source project founded by Marshall Greenblatt in
2008 and based on the Google Chromium project. Unlike the Chromium
project itself, which focuses mainly on Google Chrome application
development, CEF focuses on facilitating embedded browser use cases in
third-party applications.
and yes:
The base CEF framework includes support for the C and C++ programming
languages.
Including javascript support and html parsing makes this non-trivial task - you have to use one of the available browsers.
IE is usable through its COM model - you can create instance of it in your window be it invisible or not and call its javascript/html capabilities.
It has been designed to be used like that since the beginning and certainly it is working fine.
The other options are:
Gecko/Mozilla - a couple of years ago it wasn't usable like this, currently I think it is.
WebKit/V8 - no public API has been released for chrome yet, you could use webkit itself, but it doesn't have javascript engine. Another option is to take a look at the Chrome codebase and see if you could get out of it what you need.
I would probably go for IE, since it is maybe the easiest option and I have already used it. The other options seem to me more like building a browser instead of just using it.
How about Gecko ? You may not need the entire engine but you may find some its components useful like SpiderMonkey which is a JavaScript engine written in C.
I'd recommend picking up Qt for C++ programming. It has a built-in library that embeds Webkit with all the bells'n'whistles, and Qt is a great C++ library in general.
Old question, I know, but take a look on
http://msdn.microsoft.com/en-us/library/ky29ffxd%28v=vs.94%29.aspx
IActiveScript and family COM interfaces allows script execution (not only JS, any language that registers as script interpeter, for that matter) in-memory.