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? 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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
