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.
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):
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.
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 .
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).
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.
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.
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.
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?
27 comments
[ 3.4 ms ] story [ 69.1 ms ] threadThis is a list of common errors when experimenting with Node addons, and their possible solutions: "Out of memory"
http://news.ycombinator.com/item?id=3816870
(There are some neat demos there :))
Node-Five is for folks who are more familiar/prefer HTML5 APIs over Qt's proprietary API.
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).
Thanks to NPM :)
Your labeling of Office and Adobe CS as "legacy" is just wishful thinking.
Care to elaborate how you got around this? I tired several different things and couldn't get it done.
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 :)
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.
That's right. AFAIK everything is running in a single thread.
And on desktop, we already have state-of-the-art web browser Chrome, why bother using this to write HTML5 Canvas based app?