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

[Konstantin Tokarev]

28.09.2016, 00:38, "Rob Allan" <rob_allan at trimble.com>:
> I tend to agree with André (not surprising as he largely agreed with me!). I'm not so sure about Bo's opinion that there would be lots of pain and complaint if the C++ classes provided a rich API to the Qt Quick object model. It seems like the object model is becoming more stable, and given that PIMPL hides most of the inner workings, it should be possible to continue to evolve the API with judicious use of "deprecated" pragmas, etc. Of course there will always be some "true" breaking changes that cause compile errors for Qt users, but would there really be such an outcry about that? Not sure.
>
> I quite like QML as a declarative markup language, but am less enthused about JavaScript. It seems like kind of a toy programming language. I'm a bit shocked that you can write "code" where you can happily call functions or access properties that don't even exist on the target object. 

Enter OOP. In classic OOP there are no function calls, you just send messages to object, and object dispatches them "somehow"

Qt metaobject system has same properties, e.g. you can assign or read non-existing properties, connect to missing slots, etc.

>It is so easy to introduce a typo, or to remove a function or property that is still needed somewhere else, and not realise it. You won't get a compile error, or even a runtime crash, just strange behavior and maybe something in the console log. And having functional code spread across C++ and JavaScript seems less than ideal. I'm kind of getting used it, and trying to do only layout-related stuff in the JavaScript, and anything that is more related to application logic in C++. So you can certainly make it work - but I still feel you could produce a more robust application if all of your coding could be done in C++ and none in JavaScript.

Don't you have unit tests?

>
> Rob
>
>> ---------- Forwarded message ----------
>> From: Bo Thorsen <bo at vikingsoft.eu>
>> To: interest at qt-project.org
>> Cc:
>> Date: Thu, 22 Sep 2016 08:18:26 +0200
>> Subject: Re: [Interest] What don't you like about Qt?
>> 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
> ,
>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest


-- 
Regards,
Konstantin