Den 21-09-2016 kl. 23:53 skrev André Pönitz:
On Wed, Sep 21, 2016 at 05:42:44AM +0000, Shawn Rutledge wrote:
On Sep 20, 2016, at 22:52, Rob Allan <rob_al...@trimble.com> wrote:
My biggest gripe is that the Qt Quick object model seems to be much
more poorly supported in C++ than it is in QML. For example, in C++
you really only have access to QQuickItem - none of its derived
classes are documented, and their interfaces are private - so the
only way to manipulate items is using a generic "setProperty"
syntax. This is in stark contrast to QML where all the QML types,
methods and properties are available to you. When you have an app
that builds most of its UI dynamically from C++ code (as ours
does), this makes life pretty difficult. I guess this is one area
where widgets would score better than Qt Quick (but we still prefer
Qt Quick for a number of reasons).
It’s intentional though: we don’t have to worry about binary
compatibility that way, or even source compatibility to an extent -
it’s only the QML API that we have to keep compatible.
I believe quite a few of the people asking for C++ access to Qt Quick
are perfectly aware of the state of the current implementation, at
least to a degree to understand the desire to not set access to it in
stone. But, after weighing pros and cons, they came to the conclusion
that having *any* "official" access, even one that does not come with
any binary or even source compatibility guarantees is more valuable
than being restricted to QML.
It is beyond me how one can hide behind the "we can't/do not want to
guarantee compatibility" argument when people explicitly declared *for
years* that they don't care about such for that particular scenario.
We don’t strictly even need PIMPLs (and I wonder if we could get any
speedup or memory savings if we didn’t have them), but most of the
classes have them anyway. I guess maybe the original authors were
anticipating that the C++ API might become public some day, so they
have private objects just in case. But making more of them public is
the same as locking the API and reducing flexibility.
If there are any API warts, they become difficult to fix after that.
(E.g. the restriction that we can neither add nor remove virtual
functions is downright crippling sometimes.)
There is no API lock if there is no compatibility promise. People ask
for the API, not the promise. Making it accessible with the usual _p.h
No guarantees/"We mean it." would not restrict any development,
and make a few people happier.
André, while I actually agree with pretty much everything you write, I
also think you're a bit naïve in thinking it would work. I can already
imagine all the angry emails about how difficult it is to upgrade to new
versions because people have to rewrite the C++ code behind the QML
stuff. This would lead to a lot of "Qt sucks" zealots in companies out
there. Especially from those who have been forced by others to use a
framework they weren't interested in in the first place. Introducing
anything that will intentionally break source compatibility between
releases is IMHO a complete no-go.
What I would like to see that mostly fixes this would be:
- a factory class so you actually can instantiate QML objects from C++
without eval'ing strings
- a way for the property setting and getting to fail, if the property
isn't declared. Dynamic property setting always works at the moment
- a C++ and JS way to set up bindings
Yes, the code looks different than normal instantiate and call methods
on C++ objects. But it's a way to do support C++ code behind QML without
binary compatibility issues.
Bo Thorsen,
Director, Viking Software.
--
Viking Software
Qt and C++ experts for hire
http://www.vikingsoft.eu
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
