Porting QML to JS/HTML5
-
-
Good morning! Nice to hear you will finalize the paper: I would be glad if could you send me a copy of it.
As to the project, are you going to open it to external contributions when the paper deadline is over? Since I am interested in the matter, I would like to know if I have to keep writing my own solution, or if I can help you on your code base. Obviously I would prefer the second option: I think it is stupid not to join our efforts. -
The paper is now done, I hope the reviewers like it.
Some other project news:
-
The project will soon be open to contributions. I'm still figuring out what is the right license for this. GPLv3 perhaps.
-
Firefox is now supported. There is still minor issue with calculating text height, which is approximated in FF.
-
New QML Viewer page, which simply runs the QML given to it. Essentially it is Testpad with cleaned up UI. The neat thing about web implementation is that you can stretch the render surface to fit your screen without affecting the QML app, making it easier to deploy QML apps to different resolutions on web.
-
I also made a presentation about the project. The slideset is actually a QML application (who needs powerpoint anyway), and as we now have QML Viewer, you can view the presentation with it at http://lauri.paimen.info/pub/dev/qmlweb/test/testpad/viewer.html#../presentation.qml . If you want, you can download the qml (and two images it uses) and run it in native Qt QML Viewer, too.
-
Most of development tests/examples are now converted to QML (from parse tree). The examples are listed on (redesigned) testpad at http://lauri.paimen.info/pub/dev/qmlweb/test/testpad/testpad.html
-
-
True.
Drawing, timing and animations were using independent timers resulting to rather undeterministic behavior. Now those all use tick from the engine, currently set to 25fps. AFAIK this is the approach of native QML engine, too. Animations now run "better" -- not faster as in fps, but faster as in real time/impression, as they now animate against the actual time elapsed and thus follow the duration given to them. Implementation also simplified a bit.
Syncronizing Timer with the 25fps (40ms) ticker may break "high-frequency" Timers expecting 60fps (16ms) resolution, but that is really an issue of QML Timer specification. And well, there's nothing stopping to make the ticker 60fps, just sed "s/fps=25;/fps=60;/" qtcore.js
-
The weather in Finland has been so excellent that not much has happened to my effort lately.
Anyways, I created a gitorious project so feel free to check the code out at https://gitorious.org/qmlweb (we discussed with zanettea and decided not to use his repository).
-
I wonder if this could be combined with QtGui in html5?
You can see a demo of it at
http://www.philipashmore.com/html5/timeline/
It's part "v3c-storyboard" (I couldn't call it "storyboard"
because of a name clash) in Sourceforge.Comments welcome.
-
Depends. This far I've managed without, as the elements have been rather simple. However, if/as it gets more complicated in the future, middle layer may pay off. And more Qt-like, the better.
I took a quick glance to the sources, and there was also Qt's signal-slot and event systems implemented. That's something I had on todo-list before rewriting binding code...
-
Well, then sooner or later we're going to have to take this to the next level and get a bit more organized, so the following issues have to be addressed.
- Where to host (I guess gitorious is the logical choice)
This should also include showcase and doc web pages. - What to call it/them: QtHtml5Qml, QtHtml5QtCore, QtHtml5QtGui
seem over the top - any better names? - I've namespaced everything under Qt, is that too much?
- (eventually) enable QtWebkit/Qml to step in with "real" c++
implementations, even avoiding downloading the .js files whose
functionality it replaces. - Collaborators! I for one would love to hand over chunks of work
(like the layout classes for starters) for willing participants. - Implementation coverage charts / progress
Thinking of "Uno", it's nice to see what features are done,
todo, and tested as percentages. This means project planning,
tools and an interface. - Qt5 - should we aim for that exclusively?
And of course anything else you can think of, insert/replace above.
I've created a thread called "QtHtml5Script anyone?"
http://developer.qt.nokia.com/forums/viewthread/8726as QtGui is something that might be of interest in its own right.
I think following the Qt hierarchy/model is the most sensible
approach.Philip
- Where to host (I guess gitorious is the logical choice)
-
Sorry, when I said "uno", I really meant "mono" - see
http://go-mono.com/status/status.aspx?reference=4.0&profile=4.0&assembly=System
for some ideas.
-
I created a project in sourceForge called "qtjs".
http://sourceforge.net/projects/qtjs/
I also created a thread with the same name here.
-
Hmm.
I think that QtJs would be useful in it's own right.
I would suggest keeping them separate, just like they are (will be?) in Qt5 for that very reason.
Also, the code available will change a lot until I get the fakery^W implementation layer into a better state.
I'm working on that now, so borrowing and then modifying the code would not be a once-off.
I thought that if I wanted to include the QtScript generator examples then it would have to be GPL as well.
http://code.google.com/p/qtscriptgenerator/
I sent an email about this issue to Nokia and am awaiting feedback.
Yep, I just realized that I've got to change all those LGPL lines to GPL in the source, thanks.
Finally, do give me profs when you embed a copy of the software in your project, like you should for any GPL project.
Oh, and did I mention, collaborators welcome?
-
QtJs is useful on its own, but it also is useful for qml project. I've already forked UglifyJS code to the project to gain a Javascript parser. The preference (for bug fixes etc) is the original code/project, and keeping files borrowed to qml project somewhat up-to-date with the original.
I am not a lawyer, but I don't see the GPL of qtscriptgenerator examples forcing you to use GPL on QtJs, as the examples can also be ran on qtscriptgenerator environment. Again, IANAL.
I'm all for GPL. If you wish to enforce principles of RM Stallman, I guess the right license would be AGPLv3 with "any later version" and http://www.gnu.org/philosophy/javascript-trap.html clauses.
-
-
Yeah, it's about packaging. Assuming QtJs works without the examples, you can deliver two packages with different licenses. I guess these can be even served from same svn repository as long as the file clearly indicates to which package/license it belongs. For qml project, I've BSD-licensed all the core parts (files in src directory) and the rest of the files (test files in test directory) are, well, unlicensed. I think those could be also licensed to some other license, though in the end, it may also be court/lawyers to decide.
Now stopping the off-topic license speculation from my part.
-
That JavaScript trap link you posted got me to thinking.
If I'm going to write a facility that can substitute native code for a JavaScript url (or several) then it could be put to use to allow arbitrary substitutions, as the link describes.
Maybe this could be a general purpose plugin that can have wider applications.
I'll start a thread called "JavaScript override" to discuss it.
-
While taking a break I read up on the SVG specification.
I'm not QML savvy, but does it have anything in common with SMIL?
Would "porting" it there make sense?
I'm thinking of porting QtJs there too.
-
Have you looked at emscripten? http://emscripten.org/
It's a c++ to JavaScript converter!
I posted a message to the blog site about QtJs http://syntensity.blogspot.com/2011/07/emscripten-15.html
I hope this helps.