[PyQt] Qt Contributors Summit

[Henning Schröder]

On Wed, Jun 8, 2011 at 9:37 PM, Phil Thompson
<phil at riverbankcomputing.com> wrote:
> On Thu, 9 Jun 2011 00:18:09 +0300, Attila Csipa <pyqt at csipa.in.rs> wrote:
>> On Wednesday 08 June 2011 23:08:36 you wrote:
>>>   form_display = ['first_name', 'last_name', 'birthdate']
>>>
>>>   this single line will generate me a form with all the fields
>>>   bound to the underlying data model.
>>
>>>   will I be able to do the same with QDeclarativeComponents without
>>>   going through javascript translations and QML files.
>>>   maybe my understanding of Qt Quick is still lagging, all
>>>   clarifications are more then welcome ?
>>
>> Yes, but then you'd be doing it wrong (in fact, if you have a beef with
>> QML,
>> personally I'd rather suggest you stick with QWidgets, that's less
>> backwards
>> than using QDeclarativeComponents in an imperative manner). I encourage
>> everyone to put prejudice and the natural aversion of Python folks to JS
>> aside
>> :), and try out QML for a bit. Is it really worth doing complex dynamic
>> widget
>> and layout generators in python when you can have the same thing done
>> literally in minutes and just a few lines of QML (is QML syntax *that*
>> scary)
>> ? Of course people want to stick to tools and paradigms they are
> familiar
>> with
>> (what does it matter if you have that line in a .py file or a Form {
>> fields:
>> ['first_name', 'last_name', 'birthdate'] } in a QML file ?). The bottom
>> line is
>> QDeclarativeComponents are NOT QWidgets, and QML files are NOT
> equivalents
>> of
>> .UI files. And no, you don't have to touch the QML designer ever.
>
> I think you are missing the point.
>
> I don't think there is much argument about the benefits of a declarative
> approach over traditional widgets. Erik's framework uses a declarative
> approach. dip uses a declarative approach. ETS uses a declarative approach.
> While it may seem a novelty in the C++ world its been around Python for
> years. The problem is whether or not people are forced to use a particular
> implementation, ie. QML. What I certainly want is a public C++ API to the
> underlying code that QML sits on top of so that alternative declarative
> solutions can be implemented.
>

I thought about building a QML preprocessor using PyJS (the Python to
Javascript translator of the PyJamas project).
But a public C++ API probably looks to be the more sane approach ;)

Unfortunately besides the hype around these cool new technologies I
see no real progress on existing widgets (advanced widgets like
QTextEdit lack features, QMainWindow/QDockWidget behaviour could be
improved, QtWebKit still has no full DOM support etc).

Regards
Henning