Node-Qt: Build native apps using Node.js + Qt (Windows, Mac, Linux) | Hacker News Reader

Node-Qt: Build native apps using Node.js + Qt (Windows, Mac, Linux)

github.com

79 pointsarturadib26 comments

Hi, OP here. For folks who prefer HTML5 APIs, I'm also working on a layer that translates these Qt APIs into HTML5 primitives (like Canvas and AudioContext):

http://news.ycombinator.com/item?id=3816870

(There are some neat demos there :))

Wait, so what Node-Qt and Node-Five would both allow you to use exactly the same code?

Not the same, but sometimes similar. (For example the QPainter API is similar to the Canvas 2D API, etc).

Node-Five is for folks who are more familiar/prefer HTML5 APIs over Qt's proprietary API.

Hold on, I think I misinterpreted something. Is Node-Five a Web framework or a native application framework?

Think of Node-Five as a very small WebKit/Gecko engine for Node.js. It is written in JavaScript on top of Node-Qt, whereas Node-Qt itself is written in C++.

When I say "native apps" in this context I simply mean you don't need a traditional browser to run the apps, and the runtime interacts more closely with the OS (for example, Qt exposes native menu methods, native OpenGL, etc).

Ah, okay, awesome. I was thinking Node-Five was a Web framework which would take your Node-Qt code and run it server-side as a public Web application by translating the Qt API calls.

In the sample on that page, it says:

   // Prevent objects from being GC'd
   global.app = app;
   global.window = window;

Why do you need to do that? I thought that as long as there were still references to an object, it isn't GC'd.

Yeah it's just in case there are no surviving references to those vars. For example in the hello world code app gets GC'd unless it's in a callback in setTimeout().

From Qt5 "Lighthouse" would replace C++ as the main development method, and the Qt Quick language in Lighthouse is just a JavaScript extended language, IMHO, this project is just another re-invention of the wheel...

And on desktop, we already have state-of-the-art web browser Chrome, why bother using this to write HTML5 Canvas based app?

Nice. Last time I looked at Qt bindings for Node, it didn't support async and used the main node thread to run the UI on (OSX seems to require Qt use the main thread to draw UI on).

Care to elaborate how you got around this? I tired several different things and couldn't get it done.

Some Qt APIs are inherently asynchronous (like QHttp) but the graphics-related ones I'm binding to are not (like QPainter).

So the situation is analogous to the DOM in web browsers. The calls are synchronous and run in the main thread. As the web has taught us though, single-threads and blocking graphics calls can go a long way :)

True, but Qt specifically (as well as many OS such as Mac OSX) do not allow running of the GUI in anything but the main thread. This is due to the fact that (from what I've read) graphics drivers are not thread safe.

Just wondering how you got around this...I see you're using processEvents in QApplication.

from http://doc.qt.nokia.com/4.7-snapshot/thread-basics.html:

GUI Thread and Worker Thread As mentioned, each program has one thread when it is started. This thread is called the "main thread" (also known as the "GUI thread" in Qt applications). The Qt GUI must run in this thread. All widgets and several related classes, for example QPixmap, don't work in secondary threads. A secondary thread is commonly referred to as a "worker thread" because it is used to offload processing work from the main thread.

> do not allow running of the GUI in anything but the main thread

That's right. AFAIK everything is running in a single thread.

On X11 I actually have a bunch of patches so I wrote for Qt so I could do painting in another thread. It was useful for a project where I was injecting QtWebKit into a game where the main thread was the game and the Qt event loop and all its processing had to exists on a different thread sending a single opengl buffer across when rendered. I got some patches into Qt, but others were rejected for one reason or another (could no reproduce, not supported etc), but nonless it was a very cool project.

God job . Will definitely give a try , as I have some experience in both of them .. I always wanted to try qt php bindings, but even running the example apps was difficult .

Thanks to NPM :)

This seems to describe a large portion of javascript based frameworks:

This is a list of common errors when experimenting with Node addons, and their possible solutions: "Out of memory"

Hi, OP here. As explained that message happens when you mess something up in the C++ bindings, not because of JavaScript actually running out of memory.

So... this allows us to run webservers that call Qt methods? Why would anyone do that?

It allows you to call Qt methods from JavaScript. You don't need to run Node as a webserver.

Don't they have QtQuick or QtScript for that?

OT but regarding the current native app hype (especially in the mobile space): I still don't like native apps except my browser, my editor, the shell and some legacy software (Office and Adobe CS). I don't like updating 30 apps a week on my Android. But it's more than a trend I guess?

Node-Qt apps are really semi-native since the app itself is written in JavaScript. So you can easily make your app auto-updating, just like a web app. (iOS is an exception due to Apple's restrictions, unless they're OK with QtWebKit which I doubt).

Web apps are the hype. Native apps have always been the standard.

Your labeling of Office and Adobe CS as "legacy" is just wishful thinking.

Why the dependency for Python?

That comes from node-gyp (Node's addon build tool)

it's a build dependency not a runtime dependency

Reply on news.ycombinator.com