Attila spaketh: <snip, pyotherside seems "different"> > IIRC (from ~2011, SF MeeGo Summit when I believe the) idea was pitched to > thp, it started as something a bit different. We already had PyQt and > PySide, but they were on the heavyweight side. What I (would have liked :) > to see was "forget the bindings, I just want a QML UI in my Python app". > Since Python comes with (non-UI) batteries included, most Qt modules with > their bindings in there felt largely just cruft taking up space and memory. > I see that thp has taken the idea further :) > <snip>,
I'm not as enthusiastic about python within QML, despite toying with the > idea myself a while back, mostly because of the syntax discrepancies > (welcome to indentation/escape-hell). If I was mixing Python and QML, I'd, > instead of the JSON base, use YAML ( see http://en.wikipedia.org/wiki/YAML). > That would IMHO feel *way* more python-y. At that point, though, I'm not > sure how much Qt/QML the whole thing is :) > > import my.python.stuff > > Rectangle: > anchors: [ a.left, a.right ] > onComplete: > my.this() > for i in range(0,3): > my.that() > > Too far out there? :) > Agreed -- these are interesting thought-experiments, but I agree with Attila that I really do *not* want my QML looking more "imperative" (whether through Python syntax or other). It seems like "best practice" in QML for programs to have very little imperative code (Javascript, Python, whatever). When QML was first launched, it took me a while to "get it". I'm still working on that. However, I think I *mostly* "get-it" now: (1) QML is for declarative programming: Use bindings, don't use imperative "update" and "do-this-now" logic because: (a) It's less code; (b) It's less error-prone (e.g., You won't end up with "stale" interfaces needing imperative refreshes). (2) If you MUST do something imperative (for example, to "hook-into" some system or operation), we gave you a Javascript function to call. But, don't do that if you can avoid it. You can avoid it most of the time, even when you think you can't. (If you think you can't avoid it, then you need to, "get your mind right".) My impression is that many people (including me) didn't really understand (1). So, we took (2) and drove a tanker-truck through it, writing our imperative programs with a little bit of bindings to pretend we did (1). IMHO, that is most definitely, "not-best-practice", and I need to rewrite/refactor my code to "get-it-right" So, that's one of my non-trivial concerns about extending QML to allow Python as a "first-class-citizen": I don't want people doing more of (2). The most "ideal" scenario would be if "Python properties" could be "bound" to QML object properties, but I don't know the technical effort required for that. However, the previous example use cases mentioned in this thread are real: IMHO pyotherside is very clever for putting a QML interface on long-lived Python applications (such as a GUI over an existing Python command-line-application), or if your QML application requires long-lived objects-and-logic, you can push those to Python (because it seems harder for long-lived objects and non-trivial logic to be maintained by the programmer in Javascript; but, of course, IMHO the best solution would be to go C++ if these were a big deal.) Anybody else here using pyotherside? I'm curious, as I'm in the process of "pitching" the QML/Python approach as a replacement for Labview for internal utilities/applications at our site for a bunch of non-C++ scientists. --charley
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
