Three days ago (February 1), Roger Wang
announced the release of a new version of
the node-webkit engine - a powerful combination of WebKit and Node.js, created in the depths of the Intel Open Source Technology Center, which allows creating web-design graphical applications in HTML, CSS and Javascript
The new version has the
number 0.4.1 ; on its basis, it is easy to create and launch, for example, the following window:
![[screenshot]](https://habrastorage.org/storage2/ba3/f71/2a7/ba3f712a75a501b27ad40cbb773e9541.png)
')
Almost seven weeks have passed since that day (December 18), when
I was reviewing one of the previous versions
(0.3.6) of this engine. You can easily notice that during this time not only the last but also the penultimate digit of the version has changed. Now I will tell you what changes
in the node-webkit occurred, reflecting this change.
First of all, mention should be made of the
node-webkit release plan for 2013 published on January 18. It is planned that a new large version of
node-webkit (with the change of the penultimate digit of the version) will appear every two months (for example, 0.5.0 will be released two months after
0.4.0), and with each such release new major improvements will appear ( for example,
0.5.0 is expected to support page printing); In addition, each such version will be based on the latest (at the time of its release) versions of Node.js and Chromium. Smaller versions (such
as 0.4.1) will appear somewhat more often, but contain only minor improvements and bug fixes.
At once I will say that the transition
from 0.4.0 to 0.4.1 was accompanied by the correction of more than half a dozen rather unpleasant bugs, one of which is serious (the program crashes when you try to connect and use the plugin). Unwittingly, I even wondered if I should be cautiously refrained (as from unstable) from the use of those versions whose numbers end
in “.0”.Here is a list of the remaining innovations of
version 0.4.1 (compared to 0.3.6):- An application running on the node-webkit engine can now specify any value for the User-Agent header in an HTTP request to remote sites. For this purpose, it suffices to change the value of the " user-agent " field in the application manifest . Inside this value, you can use some keywords that will be automatically replaced with the version or application name, the node-webkit version or WebKit version, the information about the operating system and the processor capacity (similar to those found in popular browsers). If the value of the User-Agent header is not changed, then it indicates the version of Chromium on which the node-webkit is built.
- The means of remote control of a computer have been significantly expanded: trusted remote pages opened in node-webkit, access to the Node engine is provided in accordance with some white list. This list of trusted sites is specified in the application manifest as the value of the field with the name " node-remote ", which I invented. The list is compiled entirely according to the same rules as the list of local sites (which the browser can access directly without a proxy) —in other words, it contains, separated by a comma (or a semicolon), a series of patterns that can be site names (for example, “Example.com”, “* example.com”, “* .example.com”, “* example.com: 99”, “https: //x.*.example.com: 99”), or domain suffixes (".Example.com", ".com", "http: //.example.com"), or IP addresses ("127.0.1", "[0: 0 :: 1]", "[: : 1] "," http: // [:: 1]: 99 "), or IP ranges (" 192.168.1.1/16 "," fefe: 13 :: abc / 33 "), or simply the keyword" <local> "(corresponding to the list" 127.0.0.1, :: 1, localhost "). Now you can keep some of the application source code on your site (both scripts and interfaces), and it will work for the user on the computer through the Node API. One possible solution to a software update problem.
- An HTTP authentication dialog appeared in case a remote site asks for a username and password.
- The document.cookie API is supported for local pages.
- In the application manifest , the " chromium-args " field appeared (to simulate Chromium command line arguments: for example, "--enable-webaudio-input" for experiments with getUserMedia API) and the " js-flags " field (for setting V8 parameters: for example, "--harmony_proxies --harmony_collections" for access to some of the features of JavaScript Harmony).
- The “ require (" nw.gui "). Window.open () " API has been supplemented with a new field "new-instance" , through which a new instance of the Node process and WebKit can be launched in a new window.
- The same Window object has the zoom property (and the event of the same name), reflecting the intra-browser zoom of the site. In some cases, this is easier than changing the font-size for the body .
- You can follow hyperlinks with non-browser protocol names (for example, “ mailto: ” or “ area: // ”), and they will be fed to handlers written in the operating system.
- The process.mainModule property will point to the main script specified in the "node-main" field in the application manifest .
As you can see, there are almost a dozen useful innovations - and each of them will please someone , because it simplifies the life of developers.