Hey2,
I've been playing with this myself a bit, but have not gotten too far,
summer weather, travels and all. What Ville is suggesting is exactly
what I'm after - not a full binding set, but just a UI bridge. In API
rich environments like python/.net/etc the "application framework" API
parts of Qt don't mean much (and their existence/quality varies
depending on platform anyway). Mono (and even Xamarin) falls a bit short
on the UI side, and a good QML/QtQuick bridge would help a whole lot.
And before someone gets the wrong idea - this is still not about having
a single QML codebase, but rather having a "common language" for UIs
powered by whatever is the best tech choice on the given platform
(QtQuick, Silica, QML components wrapping native APIs, you name it).
Best regards
Attila Csipa
On 8/22/2014 11:12 AM, Ville M. Vainio wrote:
Hey,
We discussed this on twitter already, but here we go in >140
characters as well ;-).
Making it possible to create QML applications with Mono would be
interesting on every platform, not merely Sailfish. Think Android,
iOS, desktop. Xamarin costs nontrivial amount of money, so QML + Mono
would be a free alternative to that (with somewhat limited
capabilities of course).,
Better path than QtSharp would be just creating a QML bridge to Mono,
i.e. instantiate a QML runtime and make Mono talk with it. Example for
this architecture is PyOtherside (http://thp.io/2011/pyotherside/)
Sufficient api would be:
- register Mono functions to be callable from QML javascript
Analogue: http://pyotherside.readthedocs.org/en/latest/#call
- receive "signals" (free form objects) from Mono side
Analogue: http://pyotherside.readthedocs.org/en/latest/#received
Another example (though a lot larger) is golang-qml binding:
http://godoc.org/gopkg.in/qml.v1
Mechanically exposing large parts of Qt's C++ api (including QML
engine) like sip, pyside et al are doing is probably going to yield
lots of unuseful code, where developers only need 2% subset, but you
will pay the price of the bloat and complexity anyway (troubles with
PySide are a good example of this). Therefore I think QtSharp is
suboptimal approach.
Obviously I don't want to act as stop energy, but "look before you
leap" so to say.
On Fri, Aug 22, 2014 at 12:13 AM, Bob Summerwill <b...@summerwill.net
<mailto:b...@summerwill.net>> wrote:
See
http://www.mobilelinuxnews.com/2014/08/introduction-mono-sailfish-os-jolla/.
I'm happy to announce that development on Mono for Sailfish is
underway (http://monoforsailfish.com). This is a continuation
of MonoTizen (http://monotizen.com), on which development has been
suspended because the Tizen project is broken (see
http://kitsilanosoftware.wordpress.com/2014/08/13/the-tizen-project-is-broken-we-will-be-spending-some-time-apart-3/).
Dimitar Dobrev, the author of https://github.com/ddobrev/QtSharp
has been upstreaming bug-fixes (and addressing newly discovered
issues in) to http://github.com/mono/CppSharp. He'll be
building the bindings, and will probably end up doing the Mono
Runtime port as well, based on the fantastic job which Damien
Diederen did for the Tizen Mono Runtime.
Cheers,
Bob Summerwill, Kitsilano Software
http://twitter.com/bobsummerwill
http://bobsummerwill.com | http://kitsilanosoftware.com |
http://monoforsailfish.com
--
b...@summerwill.net <mailto:b...@summerwill.net>
_______________________________________________
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to
devel-unsubscr...@lists.sailfishos.org
<mailto:devel-unsubscr...@lists.sailfishos.org>
_______________________________________________
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
_______________________________________________
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
