A while back I wrote about the Qt/Lighthouse prototype port for for NaCl. Since then some progress has been made, but most importantly Native Client is now available in the Chrome Dev channel:
If you’re feeling brave and you want to try for yourself, here’s how:
1) Subscribe to the Google Chrome Dev channel (Edit: looks like Standard Chrome 5 is sufficient.)
2) Start Chrome with the “–enable-nacl” command line flag
3) Navigate to http://chaos.troll.no/~msorvig/qtnacl/animatedtiles/
Source code is available at gitorious.
Possibly related posts:
29 comments
Does it mean, i might expect a Google Chrome browser with native Qt UI?
Now thats awesome! I have just tried the sample with latest Chromium nightly on Kubuntu and it worked flawlessly without any problem.
http://dl.dropbox.com/u/3473245/nacl-qt-kubuntu.jpeg
Wow, does this mean that the Qt will be supporting native/hybrid applications for the future Chrome OS as well?
If yes, the implications will be enormous. One toolkit to rule them all! The same code (with minor GUI, I/O, etc changes) to reach Windows, Linux, Mac OS X, Symbian, MeeGo, embedded and now… Chrome OS?!
Please tell me I’m not dreaming!
Unfortunatly it does not work here with Chrome 6.0.447 under Windows 7 64Bit. I see only a yellow box saying “No plugin available to display content”.
Is this only working on linux?
Isn’t it a netscape-plugin available for any browser?
@fusion44 Cool! I’ve been wanting to test the dropbox image sharing myself
@Kensai: As far as I can see anything that works in the Crome browser will work in Chrome OS as well, so there is certainly potential there if we can get most of the Qt modules ported. I’m thinking about setting up an open source project once I get most of the “ground work” done on QtCore and QtGui.
Google recently published some great overview documentation if you’re interested in Native Client:
http://www.chromium.org/nativeclient/sdk-design-documents/nacl-sdk-overview
http://www.chromium.org/nativeclient/sdk-design-documents/c_salt-design
While thinking a little more about this, I run a Qt based Desktop environment with a GTK based browser to run a Qt based application in the browser, isn’t that great?
This got me thinking about using NaCl without any browser as a standalone application executable that runs on many operating systems natively. Afaik with the current NaCl it isn’t possible.
@Shyru: It’s x86 (32-bit) only but works on windows, mac and linux. (The NaCl devs are working on support for x86_64 and ARM, but I haven’t tested it with Qt)
@The User: The Qt port is tied to Chrome at this point. While Native Client is available as a browser plugin, Qt also uses the Pepper API for system integration (event handling, 2D drawing contexts, etc). Pepper is currently only implemented in Chrome – write to your browser vendor today and ask for support
@fusion44 Using NaCl for the security and ease of deployment is tempting, yes. One could remove most of the ui from the Chromium browser and turn in into an cross-platform app launcher.
This is so cool, it works fine here on XP with Chrome. He, Qt apps in the browser, looks like an interesting future…
@Shyru:
I too had problems with the Chrome 6.0.447 Win32 to get the example running. After using
chrome.exe –internal-nacl –no-sandbox
it worked!
I wonder if, once NaclQt is fully independent of Chrome, this could be used to sandbox binary Plasmoids for KDE’s Plasma?
Qt on Chrome O/S? The implications of this are HUGE!
I hope this a precursor to a generic browser plugin that we can use QtScript (all of Qt but especially QML) in. Imagine having a fully opensource replacement for flash!
How much work would it be to get QtWebkit up and running? I know it works on the testlite Lighthouse backend? It would be cool to run Qt’s demo browser inside Chrome, though admitedly the use cases for such nesting are fairly minimal.
It runs like a charm on my standard Google Chrome 5.something on WinXP 32-bit. (I omitted Step 1)
This really rocks.
@Morten: Thumbs up!
Works on Windows XP with Google Chrome 5.
An ELF binary running on Windows, interesting.
Animatedtiles.txt is 11.2 MB, which is something, compressing it with upx (–best –lzma –force-execve) produced a 3.04MB file, but I couldn’t test it (Chrome complained while trying to run the html file from hard disc), and I don’t think it’s working with a upxed image file.
If one day we could run our Qt apps in *any* HTML5/JavaScript supporting browser, that would be the end of every other toolkit out there.
But I guess that would be too much stuff to work out.
@TomCooksey: I look forward to your patch! I think porting webkit would be very hard
Rendering the Qt UI using the DOM in the embedding browser is another interesting approach.
@scorp1us : I think porting QtScript is possible. Fast QtScript (with JIT compilation) is harder.
@Alessandro: Thanks! Looks like you don’t need to venture into the dev channel.
@drac: upx probably produces a code stream that fails the NaCl security validation. No i386-nacl.elf support yet i suppose
@RealNC: That’s the dream! So far it looks like NaCl/Pepper is the best option.
Combined with QtDeclarative, this can be a truly revolutionary way to develop web applications. The Qt-NACL project was kind of slow at the end of last year so I had stopped following it. It seems like it is picking up speed again. Great job.
11.26 MB is a lot for a simple demo, but keep up the great work.
The single most important Qt port IMO. Great work!
Great thing and it works!
I realised, that there is some time until a reorder
command is processed (about 1s)… why is it?
I’d love this as a replacement for .Net or Java, as in write once and run/debug every were using C++. A powerfull idea would be to use Qt-NaCl on the client and a Qt server framework using client-server classes between the two, at which point I can write my HD video editor or 3D seismic interpretation applications in a web browser. I know a dream or do I have to wait for Qt5?
I am very impressed. Thanks for sharing this.
For our work, this could solve the problem of reaching users who are unable to do installs (no admin access, locked down), while allowing us to continue to build with QT/C++ for our core users, who will likely do full installs.
To me, this presents an architectural challenge/opportunity. Qt needs a good cross-platform RPC mechanism. I have recently discovered the QRemoteSignal library, which looks promising:
http://qt-apps.org/content/show.php/QRemoteSignal?content=112061
I have used various CORBA tools, and more recently Zeroc’s ICE (beautiful). I am wondering what the right blend would be–between Qt’s rich object model and the coherent network programming model of ICE. All of this, served up by this nifty NaCL thing would rock.
I recognize that Qt has some significant network facilities that provide a higher level of abstraction than straight sockets–and that this is woven into the signals/slots mechanism. And DBus is interesting, but there is no Windows support (my mind cannot compile the DBus/NaCL equation yet).
Still, I want to declare an interface (.idl, .ice, etc) and be able to implement the server side using Java. Not sure where this is going–just wanted to share my thoughts.
Thanks very much for this great work.
@Morten Johan Sørvig
I’ve opened a feature request for UPX – Google Native Client Support – ID: 3021683 (http://bit.ly/9hOOCx)
We should help John F. Reiser with all the help he requires.
Since you have all the dev tools in place, can you create a small NaCl Qt “Hello World” example, and host both
compressed and uncompressed versions, so that he can fix UPX?
This will propel Qt apps to the web and is paramount to adoption. Great work.
Does this not work anymore? I tried it with Google’s Beta channel as well as the new Canary channel. I get two dialogs that pop up telling me:
The page at chaos.troll.no says: failed to send nexe
The page at chaos.troll.no says: Load: FAILED to start service runtime
For historical context see 21:25-25:45 of this memorable talk from 1997 (transcript). Remember also Marc Andreesen’s comment about Windows as “a poorly debugged set of device drivers” – and the Microsoft email evidence from its antitrust case.
Comments on this entry are closed.