I would like to build a Chrome multimedia extension.
I would like this extension to communicate with another process (using a "memory-mapped file" (https://msdn.microsoft.com/en-us/library/ms810613.aspx). Is it possible?
From the NaCl FAQ:
If I want direct access to the OS, should I use Native Client?
No—Native Client does not provide direct access to the OS or devices,
or otherwise bypass the JavaScript security model. For more
information, see later sections of this FAQ.
If it is not possible to use memory-mapped files in NaCl's sandbox, is there any other way to build such plugin?
My extension would be used only by me, so I can accept security flaws.
Short answer: No. The sandbox is designed to prevent that kind of thing. The only way to use APIs other than the Pepper APIs (or of course those available in JavaScript) would be to install a native app in the OS, and communicate with it from a web app or extension using Native Messaging:
https://developer.chrome.com/extensions/nativeMessaging (that might be a good solution for you since it sounds like communicating with another process is what you want to do anyway).
Is possible to use QT QWebChannel without websockets, but using WebKit ICP?
I only found examples using webSockets.
Unfortunately, the documentation states that:
It works on all browsers that support Qt WebSockets, [...]. Additionally, a custom transport mechanism can also be implemented using Qt WebSockets to support Qt WebChannel-based communication.
It seems that you cannot use it without WebSockets, and it would explain why all the examples you find actually use them.
Anyway, it also states that:
The transport mechanism is supported out of the box by the two popular web engines, Qt WebKit 2 and Qt WebEngine (experimental).
Despite the fact that it is experimental, it looks like an alternative to the WebSockets.
Actually, while digging into the linked documentation, I've found that page where it is said about WebKit that it implements internally the required interface and it can be used in place of the WebSockets, but no example is provided.
You can find spare information all throughout the linked page, as an example it is said that:
For HTML clients run inside Qt WebKit, you can load the file via qrc:///qtwebchannel/qwebchannel.js. For external clients you will need to copy the file to your webserver.
Then, it follows a brief description of the steps to be done to achieve the same on those clients, as far as I understand by using no WebSockets in this case.
That said, It seems to me that the solution based on the WebSockets is the suggested one, so probably you should reconsider you architecture and use them. Otherwise, be ready to deal with experimental and poor documented features.
I am completely new to mobile development and i interested to hybrid apps and of course Intel XDK. When i reading Intel XDK's documentations i faced to "runtime" word.
What is mean of this phrase and actually what is it's mean when they saying
Crosswalk is a HTML5 runtime, ...
in their blog post.
Apologize me if I asking one of stackoverflow's stupid questions.
"Runtime" generally refers to the time a program runs, as opposed to other times in the programs life cycle like compile time. Software is typically written, then compiled, then deployed or installed, then run. These different phases are often referred to as "compile time", "install time" and "runtime". E.g. "at compile time, the compiler will ...".
"A runtime" is a software package that is necessary at, well, runtime. E.g. a library, interpreter, virtual machine or other such supporting packages. Crosswalk is a system that takes in HTML 5 "apps" (including HTML, Javascript etc.) and, well, makes them work. Executes them. Runs them. It's essentially a browser engine, but not packaged as a browser, just as a system that can interpret and run HTML 5, which you can embed into whatever other software you want.
So you could write your application in HTML 5; then to make that work like a native desktop application which can be downloaded and installed, you write a tiny Windows application and an OS X application which basically just contains Crosswalk, which runs your actual application inside it, cross-platform.
Run-time - the length of time it takes to execute a software program
The Intel XDK includes the Crosswalk runtime as a supported target of the cloud-based build service.
Crosswalk runtime can be used for creating HTML5 application with a dedicated runtime that can be run on multiple platforms without any dependency for webview. It can be used for creating application that uses HTML5 features like WebRTC, hardware-accelerated WebGL support and bleeding edge HTML5 features.
For more information please follow this resources..
crosswalk-runtime
more resources : Using the Intel XDK “Crosswalk for Android”
I have to write a google chrome extension/plugin that has to send out events to a win32 service when certain websites are accessed.
1. Is Pepper API/Native Client the right approach to do this?
2. If I can use Pepper API, is it possible to access the Win32 named pipes to send information to the win32 process? If not, is there an alternate approach available to achieve this goal?
Pepper is by the very definition a sandbox, and supposed to be cross-platform. Without knowing anything about it, I would guess that the answer is "no".
Native Client is a sandbox for running compiled C and C++ code in the browser efficiently and securely, independent of the user’s operating system.
From within an extension, the right approach would be Native Messaging.
The idea is to have a native application ("host") that Chrome can invoke on demand and communicate with. It can serve as a proxy for your calls.
For more information, look around the linked documentation and chrome-native-messaging here on SO.
Now that TideSDK is effectively dead, I've been looking into alternative 'wrappers' to run HTML/CSS/JS applications as stand-alone desktop applications. The three viable options I have run across so far, are NW.js (formerly node-webkit), brackets-shell, and Electron (formerly atom-shell).
The problem is that there does not appear to be a sufficiently complete comparison between the three in terms of feature set, compatibility, etc. I'm hoping to turn this into a more-or-less canonical thread on the (objective) differences between the three, in particular regarding:
Platform support; operating systems, dependencies, etc.
Language feature support, as far as HTML5, CSS3 and JavaScript are concerned. Think things like "does HTML5 video work, and if yes, what codecs are available?"
Non-standard extra features, such as tray icons, popup notifications, and OS-rendered menu bars.
Extensibility; eg. ability to 'plug in' native code, talk to Node.js, and so on.
Architecture; in particular the architectural differences that affect daily usage as a developer.
Debugging; included development tools, compatibility with commonly used tools like node-inspector, etc.
... and so on.
What are the objective, technical differences that matter when making a choice between them as an application developer?
I did similar research about two months ago, and in the end I went with node-webkit. The biggest upside on node-webkit is node.js and npm. The package management of npm is really nice, and node has well done filesystem access.
Brackets-shell looked interesting, but other than a nice IDE I didn't really get what made this one as good or better than the rest. They are very clear that "The brackets-shell is only maintained for use by the Brackets project ", that screams run away to me.
https://github.com/adobe/brackets-shell#overview
Atom-shell seems to be recently active, but it seems much like brackets in that they are really writing and editor/IDE that just happens to be attached to a webkit runtime. It also is built on top of node.js. This one has the downside of being difficult to search for stuff online without being reminded of your middle school chemistry.
I really don't want an new editor, and most programmers have their favorite already. For the actual application development, they pretty much work the same, and should, since they all use webkit. You basically write 90-95% of it like a website, and then deal with the native parts, and some config.
These things are true for all three of them
platforms - runs on Windows, Mac, and Linux
language support - HTML5, CSS3 and Javascript : since they run javascript you can download and run nearly any library/framework that you want.
The big caveat on webkit is codec support. Typically you will have problems with non-free video codecs, unless you rebuild the dll/so to support them. For example the shipped node-webkit won't play mp4 video.
I've been playing with Atom-Shell over the last few days, and I am loving it so far.
The best part about it is that it's backed by GitHub.. which should allow you to settle into the platform for the long term, especially if it gains a large following. It's also made possible by direct Node.js improvements courtesy of a contract with StrongLoop, who is a major Node.js contributor (they claim to employ more Node.js core developers than any other company, even Joyent).
I've also found it rather comfortable to get started. It took me about a day to learn the structure and get my first proof of concept running. Very cool.
Bullet Points:
Platform support: Windows, Linux, Mac OSX (More Info Here)
Language feature support: HTML5, CSS3, JS via Chromium - so far, zero issues, but I have not tested video specifically.
Native Features: Native App Menus, Task Tray Support, Global Hotkeys, Protocol Handler Support (that I've seen so far)
Extensibility: Excellent Node.js integration, both the client and server can "require" Node.js modules and natives. I've also successfully tested Bower libraries (incl jQuery) without issue.
Architecture: Covered in the other points, but in general its very smooth.
Update (11/25/14): I've not yet found use case for Atom-Shell in any official capacity, but I have used it to build a few small apps for my own use, the most complex being an app that pulls my time logs from my PM software and creates Paypal invoices.
My opinion of the platform remains positive. It's pretty awesome.
On my time invoicing app I successfully brought in Bootstrap 3's Dashboard Example Template and a few node modules (bluebird, Paypal SDK, Teamwork PM Client) to create a mildly complex app. It took me a few days and does its job well.
I really cannot think of anything negative to say about Atom-Shell, its solid, stable, fast, and easy to code for. I hope this helps someone.
Besides fully support Web standards, NW.js supports a list of non-standard features for native app development including:
Protect JS source code by compiling them into machine code: https://github.com/nwjs/nw.js/wiki/Protect-JavaScript-source-code-with-v8-snapshot
Jailed devtools: https://github.com/nwjs/nw.js/wiki/Devtools-jail-feature
Additional security model with which you can do more in DOM: https://github.com/nwjs/nw.js/wiki/Security https://github.com/nwjs/nw.js/wiki/Changes-to-DOM
enhanced file dialog: https://github.com/nwjs/nw.js/wiki/File-dialogs
kiosk mode: https://github.com/nwjs/nw.js/wiki/The-Kiosk-mode
supports for a growing list of chrome.* API, include chrome.webRequest so you can intercept HTTP requests from DOM: https://github.com/nwjs/nw.js/issues/518
support for rich notifications, print preview, many more chrome.* APIs, Chrome Apps and other Chromium features starting from 0.13.0-alpha0
There is much more to see in the wiki including Menu, Tray, etc.
I've been working with brackets-shell for some time now, here are some of my findings:
brackets-shell is primarily developed as a shell under the brackets IDE project, but the project can run any web application. You just need to point it to your own html page. Clint Berry wrote an excellent tutorial about doing just this: http://clintberry.com/2013/html5-desktop-apps-with-brackets-shell/
The project is backed by Adobe and has a lot of activity
Documentation could be better
platform support They support Windows, Mac and Linux. An installer package can also be created. I only tested it on Win and Mac, it works great.
feature support html5, css3, js. Html5 video does not work out of the box, but is very easy to enable (by default the ffmpegsumo.dll is not copied into the installer, if you change the script to copy it it will work).
native features menu bar, 'open file with', file system access. I am not using any of these, as all I need is the communication with the node process.
extensibility a nodejs is built in, and you can communicate with node from your web application. In this way, you can use node to access the filesystem etc.
architecture The project is well set up, keeping a nice separation between the shell project and your own web app running inside it. In your own application, a global appshell object is available which gives you access to the brackets functionality (filesystem access, communication with node process, ...).
One thing to note (if you care), is that the Electron officially does not support Windows Vista. Vista's market share is about halfway between OSX 10.9 and 10.10 (both of which are fully supported by Electron). Vista is also still supported by Microsoft until 2017.
NW.js works fine in Vista, as well as OSX 10.9+. NW.js works on Ubuntu, Debian, Zorin, Manjaro, Arch, and most other Debian based Linux OS's. Electron has refused PR's to fix Ubuntu specific bugs on their platform which is concerning.
NW.js works in XP too. Currently 18% of the market is still on XP. So if you're desktop application is more general purpose or wants to have access to the late adopters still on XP, you're probably better off with NW.js (0.14.7) as Electron only supports Win 7 and up.
If you use NW.js 0.12.3 you can also support OSX 10.6+ and very old versions of Debian based Linux OS's like Ubuntu, and Win XP+. It is recommended that you do special builds just for those legacy systems though and use the newer versions of NW.js for newer OS's.