[Interest] Porting Qt to our RTOS
Giuseppe D'Angelo
giuseppe.dangelo at kdab.com
Sun Sep 30 21:55:56 CEST 2018
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.dangelo at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4007 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20180930/eca39cb7/attachment.bin>
More information about the Interest
mailing list