[Interest] pyotherside is Awesome

[Charley Bay]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20140220/0f813887/attachment.html>