Hi, On 28/09/18 10:55, Uwe Rathmann wrote:
This is another blatant false statement, because you can port just the parts of Qt that you need, and even those can be further trimmed down using the feature system. (That's actually how you would do a port in the first place.)While I agree with almost everything of your posting I don't do with this one:Qt/Quick has gone into the direction of Web technologies and you can't change this by simply disabling some features. This goes much deeper and has to do with the philosophy/mindset behind the product.
Sorry, but I don't see how this possibly contradicts my statement which is about _how_ one does a port (port a subset of the Qt modules, possibly trimming them down via the feature system).
What you're talking about here is a combination of whether Qt is a "good fit" for developing UIs, as well as some other considerations about the overall direction of the project. This combination of opinions (which you are perfectly entitled to have, and I do happen to share some of these feelings) is, however, off-topic here. (The topic is still "how to port Qt to another platform".)
An *on topic* objection would be something like "although Qt is modularized, and you can port only what you need, lots of new development in terms of UI features these days happens for QtQuick, so consider carefully _if_ you need it, because that means porting the QML engine and that might be challenging" (*) (**)
(*) The "_if_ you need it" part is of course necessary; widgets or raster-panted UIs could be just fine, depending on the use case.
(**) At the moment I also have no idea about whether it's _actually_ challenging; in other words, what are the platform requirements of the QtQml / QtDeclarative modules. It could just be that they don't require anything special.
Have a look athttps://www.qt.io/qt-vs-html-5-strengths-and-weaknesses. There is nothing wrong with these articles, but "four to eight times lower RAM requirements" than a beast like HTML5 does not put Qt into a different category.
This is again off-topic (and in particular I beg to disagree with both the benchmarks shown there and thus the conclusions).
Actually we were so disappointed ( learning it the hard way with a project using QML ) about the direction Qt has taken, that we finally started our own framework on top of ~ QuickItem/QQuickWindow (https:// github.com/uwerat/qskinny ). Uwe PS: would be nice to have a feature to get rid of all QML related members/ interfaces of QQuickItem/QQuickWindow
And once more off-topic, I'm afraid...(Yes, I 100% agree that QtQuick could be modularized much further, e.g. drop its dependency from QtQml altogether, expose C++ APIs for the QtQuick items, offer ready-made "rich" scene graph items, have clear and explicit support for more than just OpenGL. Unfortunately in Qt 5 it's the way it is; Qt 6 should be the right time to fix all of these shortcomings.
But I don't want to start this conversation in this thread, let's have it in the right places.).
My 2 cents, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
