[Development] The place of QML

[Alan Alpert]

On Wed, 25 Apr 2012 15:03:21 ext Girish Ramakrishnan wrote:
> 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?

https://codereview.qt-project.org/#change,23617 would still require modifying 
QQuickTextEdit, it can't be done in a subclass without modifying the 
QQuickTextEdit API. So making qquicktextedit_p.h into qquicktextedit.h doesn't 
help, you'll still want access to qquicktextedit_p.h (which was 
qquicktextedit_p_p.h) and we have the same problem.

The alternate solution, as you point out next, is that we need to make the 
APIs extensible case by case. One class at a time. This is the real solution, 
simply making the C++ headers public gives us less than nothing. 
Unfortunately, making them public requires little work now (just tons of work 
later ;) ) and fixing all those individual cases requires tons of work now. 
Hopefully we can make some more incremental improvements in QtQuick 2.1 
though.
 
> 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).

-- 
Alan Alpert
Senior Engineer
Nokia, Qt Development Frameworks