sebadorn

Profilbild Seba Über mich

Using NW.js to communicate with a DS4 controller

Informatik
0

DS4 green light

NW.js still provides the Chrome Apps API which has been removed from Chrome, but not ChromeOS. This will allow us to access in a platform-independant manner devices which are connected with the PC per USB.

Without this API, a 3rd party Node.js module like node-hid could be used. This will however come with platform-dependant libraries and will have to be updated or rebuild each time the Node.js version changes.

This article concentrates on sending data to the controller. However it is also possible to retrieve data like pressed buttons using the established connection. Aside from using chrome.hid there is also the Gamepad API for read-only access.

Identifying the controller

First we need a way to identify the DS4. Devices come with a vendor Id and product Id. According to the Gentoo Wiki they are as follows:

Device Vendor Id Product Id
DS4 (1st gen) hex 054C / dec 1356 hex 05C4 / dec 1476
DS4 (2nd gen) hex 054C / dec 1356 hex 09CC / dec 2508

Having tested with both devices, I can also confirm the Ids.

Get the device

For all communication with the device, we will use the chrome.hid API. First we define a filter using the vendor and product Id, and then query the available devices:

var filter = {
    filter: [
        { vendorId: 1356, productId: 1476 },
        { vendorId: 1356, productId: 2508 }
    ]
};

chrome.hid.getDevices( filter, ( devices ) => {
    // Error handling.
    if( chrome.runtime.lastError ) {
        console.error( chrome.runtime.lastError );
        return;
    }
    if( !devices ) {
        return;
    }

    var device = devices[0];
    // Next: Connect to the device.
};
weiterlesen

Standalone-Anwendungen mit node-webkit

Informatik
4

node-webkit demo window

Gestern habe ich ein wenig in node-webkit reingeschnuppert. Damit sollen sich ganz einfach Desktop-Anwendungen auf Basis von HTML, JavaScript und Node.js erstellen lassen. Die erstellte Anwendung lässt sich dann relativ einfach für verschiedene Betriebs­systeme verpacken. Für nicht allzu rechen-intensive Spiele scheint mir das recht interessant. Tatsächlich verwendet auch das kürzlich erschiene A Wizard's Lizard node-webkit [1].

Für eine kleine Demo habe ich das Beispiel von three.js genommen und als Anwendung verpackt. Das HTML und JavaScript lasse ich hier mal aus. Mein package.json für ein Fenster ohne Toolbar sieht wie folgt aus:

{
	"main": "index.html",
	"name": "nw-demo",
	"window": {
		"frame": true,
		"height": 600,
		"kiosk": false,
		"toolbar": false,
		"width": 900
	}
}
weiterlesen

Opera Extensions und JavaScript-Whitelisting

Informatik
1

JavaScript-Whitelisting

Gemeint ist, wenn man JavaScript erst im Browser deaktiviert und dann nur für jede gewünschte Seite gesondert aktiviert. Man führt also eine Whitelist für Seiten, die JavaScript ausführen dürfen. Warum kann das eine gute Idee sein?

  • Sicherheit und geschützte Privatsphäre: Böse Dinge wie dynamisches Nachladen von schädlichen Inhalten von Fremd-Servern wird erschwert. Das allgegenwärtige Tracking durch hauptsächlich Werbefirmen (das beinhaltet auch und gerade Google) wird nahezu unmöglich.
  • Internet im Light-Modus: Kein Popup, das nach Facebook-Likes oder Twitter-Gefollowere bettelt; keine nervige Bottom-Menubar, die aufklappt, und überhaupt: 99% weniger Werbung.

Das Problem mit Opera

Deaktiviert man global JavaScript, funktionieren Extensions nicht mehr, selbst wenn die besuchte Seite auf der Whitelist steht. Konkret ist das Problem, dass keine Content-Skripte mehr in die besuchte Seite injiziert werden – ein elementärer Bestandteil der meisten Extensions.

Der Witz an der Sache ist, dass Userscripts – diese einzelnen JavaScript-Dateien, die auf .user.js enden – weiterhin funktionieren, denn dafür gibt es sogar eine extra Einstellung. Auch die Opera Developer Toolbar „Dragonfly“ funktioniert weiterhin.

Also: Warum nicht auch Extensions?

Workaround

  1. Aktiviere JavaScript global.
  2. Füge eine Site Preference hinzu für die Adresse „*“ und deaktiviere für diese JavaScript. Dabei handelt es sich um eine Wildcard, die alle Seiten betrifft – besucht und unbesucht.
  3. Füge eine Site Preference hinzu für die Adresse „wuid-*“ und aktiviere für diese JavaScript. Dies ist für die Extensions, damit z.B. das Background-Skript und die Optionen-Seite funktionieren.

Ab sofort laufen auf jeder Seite, die auf der Whitelist steht, auch die Extensions.

Browser-Addons: Nachrichten-Broadcast an alle Tabs

Informatik
0

Browser: Chrome, Firefox, Opera

Situation

Meine Extension injiziert auf bestimmten Seiten ein Content Script. Man kann dann auf dieser veränderten Seite auch Einstellungen ändern, die im der Extension zugewiesenen Storage gespeichert wird. Dafür wird wie üblich eine Nachricht mit den Änderungen an den Hintergrundsprozess geschickt.

Problem

Angenommen, ich habe zwei oder mehr Tabs offen. Nun verändere ich die Einstellung A in einem dieser Tabs. Die Änderung wird gespeichert, aber alle anderen Tabs zeigen nach wie vor den alten Zustand an. Erst nach einem Neuladen der Seite wird die Änderung sichtbar.

Was wir wollen, ist eine Synchronisation der Tabs, was bedeutet, wir müssen alle im Hintergrund eintreffenden Änderungen allen anderen Tabs ebenfalls mitteilen. Und das geht so …

weiterlesen

Add-ons für Chrome, Firefox und Opera selbst hosten

Informatik
0

3 Browser

Ich habe eine Browser-Extension für Chrome, Firefox und Opera erstellt. Alle Dateien liegen bei mir lokal, ich habe also z.B. nicht Firefoxs Add-on Builder verwendet, sondern nur das SDK. Als die Extension fertig war, wollte ich sie auch selbst hosten. Ich meine, wie schwer kann das schon sein? Ja, nun …

In diesem Artikel gehen wir davon aus, dass sich die Browser-spezifischen Extension-Dateien in den Unterverzeichnissen Chrome/, Firefox/ und Opera/ befinden.

weiterlesen