[Development] The place of QML

[Girish Ramakrishnan]

Hi Alan,

On Wed, Apr 25, 2012 at 6:16 AM,  <alan.alpert at nokia.com> wrote:
>>From: ext Girish Ramakrishnan [girish at forwardbias.in]
>>Sent: Tuesday, April 24, 2012 12:50 PM
>>To: Donald Carr
>>Cc: Alpert Alan (Nokia-MP/Brisbane); development at qt-project.org
>>Subject: Re: [Development] The place of QML
>>>> I do think we should evaluate exposing the QML implementations to C++ for 5.1.
>>>
>>> I think a better question would be; What existing evaluations exist?
>>> And outside of the people seeking a contractual C++ API to scenegraph,
>>> what evident extensibility/functionality issues exist in QML today?
>>>
>>
>>My point above is an extensibility issue with our current QML
>>offering. You cannot extend any existing QML element in C++. You have
>>to start from scratch. We basically mark all existing QML items as
>>'final' for C++ use.
>
> I get your point, but exposing the existing C++ APIs is not the answer. I recently tried to write my own QML code editor, which basically meant re-implementing TextEdit. It was not fun. That time I had the option to use private headers if I wanted too, but the current QQuickTextEdit API was just not helpful. I compared it to QTextEdit, which could be easily extended to do what I wanted (all I wanted was syntax highlighting), and the difference was some specific API which QTextEdit has and QQuickTextEdit doesn't. The point being, that the extensibility issue isn't really C++ vs QML. It's the subtly different question of extending the APIs (and thus the maintenance burden and implementation restrictions).
>
> Back to the QTextEdit example: I put a concept up on codereview to share with someone, https://codereview.qt-project.org/#change,23617 , which added the necessary API - but to QML. This allowed me to extend TextEdit in QML just fine, and I could have done it in C++ if I was so inclined. This was purely a question of what API was exposed. For those interested in the implications of how that patch would be used, in my case I created a custom QSyntaxHighlighter in C++ and then exposed it to QML so I could do syntaxHighlighter:MySyntaxHighlighter{}; . Doing something similar with the QTextDocument might be the solution for rich text editing in QML (but I don't think so - that's a separate discussion anyways ;) ).
>

Isn't exposing the C++ code for QQuickTextEdit the solution to this
problem? IOW, qquicktextedit_p.h should become qquicktextedit.h. For
an end user, who wants to add the synyaxHighlighter property, he/she
would have to a lot of work if they didn't want to modify Qt. What's
the alternate solution?

As you point out, I do understand that the current Quick items have
not been implemented with reuse in mind but that's something that can
be solved case by case (rather, let's do this one class at a time).

Girish