On Wed, 25 Apr 2012 15:03:21 ext Girish Ramakrishnan wrote: > Hi Alan, > > On Wed, Apr 25, 2012 at 6:16 AM, <alan.alp...@nokia.com> wrote: > >>From: ext Girish Ramakrishnan [gir...@forwardbias.in] > >>Sent: Tuesday, April 24, 2012 12:50 PM > >>To: Donald Carr > >>Cc: Alpert Alan (Nokia-MP/Brisbane); development@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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
