[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