Looks nice - Meteor natively speaks DDP so it makes most sense to use when talking to Meteor, but for other back-ends I will certainly consider WAMP! (no reason why this principle could not be applied to other back-ends hooking into the same WS powered Qt front-end)
AFAIK The reactive part is not that easy to with Mysql et al - sure, you can hack around stored procedures, UDF and such, but it's far from being elegant. If you "think in SQL", then of course nosql seems to make everything difficult, but in reality, you're just taking back some of the logic and heavy lifting from the DB server in exchange for more freedom/scalability, which may or may not be something you want.
I 'think SQL' all day, or at least a simple subset of it, and I need to learn more. It's paying my bills as a .NET/JavaScipt dev, you know? I'd like to integrate it into my hobby projects. But I'm gonna watch that video linked above and see what it sells me. I certainly don't have any innate resistance to thinking of data as (basically) JSON arrays. I love that. We use that sorta stuff all the time at work, passing data back and forth, to and from the core client JavaScript functions.
I just can't shake the notion that NoSQL is so popular because SQL just is NOT. And I get that: SQL is freaking complicated once you get to the parts that make it so powerful. But maybe that's all a misunderstanding on my part.
Performance-wise Qt is quite good, but still comes up a bit short on the Widget quality and consistency side - this is where project like my native component-wrappers come in to the story (shameless plug - http://achipa.blogspot.com/2014/11/qml-wrappers-for-native-a...). The good news is that you can still keep on the JSON/Javascript side for all of this, regardless of whether you use custom UIs, use Qt Quick Controls or something else.
Long story short - it's not quite an Appcelerator replacement just yet, but certainly keep an eye on it! :)
Yes, I'm using Asteroid to talk DDP/JSON with the rest of the Qt app.
In the example, I'm using models (think MVC) and updating that model, which then automagically updates the UI.
I'm not (yet) pushing the QML via Meteor, but that is the next logical step. Should the UI change (say, radioboxes instead of checkboxes), the plan is to do a diff and change altered components (this should be doable as QML's format is still close enough to JSON).
Of course, you could write a C++ DDP lib (and on the long run, probably should, merely for the performance boost), but asteroid and JS just made a proof-of-concept that much easier to build.
QML is not just a layout descriptor - you can embed javascript in it. Think about QML as HTML written in JSON, but without the HTML implied semantics.
Still, JS could also be shuttled accross the DDP connection, and could be run or changed client-side, there is no difference between those and QML as I mentioned above, though this is also something planned-but-not-implemented-yet.
In all honesty, Qt has come a long way since 2012 - QML is reasonably well documented nowadays. Controls (the widget library), while not a silver bullet, are good enough (at least on Android, haven't used iOS all that much) so normally you don't need to go as low as your own QPainter or even Rect-s.
True - even for DDP there are already a number of client libraries not strictly related to Meteor front-ends, as seen from http://meteorpedia.com/read/DDP_Clients
There were some concerns as to how native this is - I'm not rendering any HTML. The client side does use the JSON-style QML, but that's just the declarative UI language of Qt - your high-performance code can be C++, Java, or whatever is the native language of the platform. If you wish, though, you can write your whole app in JavaScript, too, but that's an option, not a requirement.
This is a more full-stack approach - Qt and Xamarin are geared more towards creating standalone apps. What you get here is the reactive back-end (plus web-site for free). This setup can be used for both data and UI - you could for example publish a new UI (not just content), and all native apps would automatically be updated on the fly.
If you take a look at the video - if you do this with Xamarin (or Qt) you would need to manually connect to a database or poll a RESTful service to see current data.
It's worth noting that if you wanted to create this kind of real-time app with a Xamarin frontend, you could do it quite easily with ASP.NET on the backend and SignalR.
That's certainly possible for the data part - but a lot harder for UI/code. With the method I'm using, you can actually push code AND UI to the client on the fly. As far as I know, that's a lot more difficult with Xamarin.
Also, the licensing is a lot more flexible than with Xamarin and Qt does provide support for more platforms.
It looks attractive, but at these times, the client application can be easily be auto-updated, that's how all applications work, including those made by Google.
This is not the same thing by a long shot - you cannot force a Google Play update, and that update will take hours or days to trickle down to the users. What we're talking about is that the application updates itself instantly, even WHILE RUNNING. The user needs to nothing, no "update your app" or "newer version available". I can literally add an option in the settings menu or change something in the app and it will immediately be reflected on ALL clients connected without touching the appstore.
Hi, I'm Attila, the developer of Qondrite - the interface between Meteor and Qt in the article. If you have any questions, feel free to ask, I'm always looking for new perspectives, comments and will be happy to answer!
Really impressive work, thank you. I intend taking an in-depth look later, but just at the moment I hope you'll indulge a more-or-less off topic question; What tool did you use to create the youtube demo on your blog ?
