[Interest] What don't you like about Qt?

Bo Thorsen bo at vikingsoft.eu
Thu Sep 22 08:18:26 CEST 2016


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_allan at 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



More information about the Interest mailing list