[Interest] Porting Qt to our RTOS

[Giuseppe D'Angelo]

On 29/09/18 23:35, Roland Hughes wrote:
> 
> Syllogism, nice word. For those who did not wish to look it up
[snip]

Thank you, but I assume that people reading this mailing list are smart 
enough to look up the words that they don't know, or ask me directly for 
an explanation.


> Logic A form of deductive reasoning consisting of a major premise, a
> minor premise, and a conclusion; for example, All humans are mortal, the
> major premise, I am a human, the minor premise, therefore, I am mortal,
> the conclusion.
> 
> Well, you may not care about such a discussion nor wish to have it, but,
> since your ENTIRE second point is based on:
> 
> This major premise has not been established in this community.
> 
> We will be doing a bit of that in a moment. As to point one.
[snip]

It doesn't work like this. You are *now* trying to establish the 
premises of the syllogism, despite multiple people telling you that the 
minor premise was false and that the major premise is questionable and 
argumentative.

As I have already announced, I won't even consider reading the argument. 
The logical fallacy of using an unproven premise to derive a consequence 
was already there.

The point stays, however: going off-topic; resorting to false 
statements; and posting logical fallacies are all not acceptable on this 
mailing list.


However, this is so blatant I can't just let it go:

> True software engineering 

Leave "true" and "false" to philosophy and to hard sciences; software 
engineering is neither. If you're describing specific engineering 
models, have the courtesy of saying which ones you're talking about.



> I need to point out a recent statement from Alex

Alex has a last name, by the way.



> True software engineering put a man on the moon and returned him safely
> to earth when the only programming languages we had to work with were
> Assembler and FORTRAN. We haven't done that in a post OOP - AGILE world.

Oh, I get it, so Agile is why we don't go to the Moon any more...



> As Alex stated in that same message "Qt is huge."
> 
> It has loooooong since passed the size and complexity of anything which
> an reliably be developed and maintained without true software
> engineering. The 32767 flavors of AGILE cannot keep it stable.

This is your opinion. You're entitled to have it, and I will defend your 
right to have it. But don't try arguing that this opinion is actually a 
fact.


> Did you not listen/read krzysiek.kawa's post?
> 
> ===
> 
> I really hate to be "that guy" again, but I'd just like to know what's
> going on.
> 
> Some time ago I complained about bugs not being resolved for many
> major releases. I was then told my reports were P2 or lower and I
> can't expect them to be taken care of. That sucks for me but I can
> understand to some degree.
> But now a new release is out and I still have three P1:Critical
> issues, reported 3 or 4 releases ago, all being regressions btw, and
> nothing is fixed. There's a next major release around the corner and
> it doesn't seem to fix these either.
> 
> ===
> 
> I have not looked at those specific bugs, 

Neither have I, but at least I extend the common courtesy of not talking 
about things I don't know.


>>> You should read up on the many discussions (one even
>>> within the past week) about critical bugs which rot until they are
>>> closed in typical OpenSource manner.
>> 1) There's no such thing as "typical OpenSource manner". Would you
>> kindly stop generalizing?
> 
> Of course there is. One need only look as far as GitHub.

Of course there is NOT. Stop generalizing.


>> 2) Qt is also a commercial product, with commercial support, and bugs
>> fixed and prioritized (also) according to the commercial needs; so this
>> statement is factually false.
> No, it's not. It's factually correct. You just don't wish to believe it.

It's factually INCORRECT. Bugs *are* fixed. Maybe not the ones that you 
care about, but the ones that other paying customers care about 
(because, as I said, Qt is also a commercial product, where people 
paying get a nice priority ticket).

Hence you can't _generalize_ that bugs "rot" in the tracker, nor that 
they're "closed in an opensource manner".

(No, I won't go further offtopic with a discussion about bugfixing in Qt.)


>>> Qt is an incredibly heavy massive footprint. It gets heavier and more
>>> massive every day. You won't be porting "just a GUI." CAN-BUS, Serial
>>> I/O, SQL database, timers, yet another thread class, the absolutely
>>> worthless QML (which pretty much means you will need to port JavaScript
>>> as well.) Ah yes! In order to claim you have "ported Qt" you will also
>>> need to port WebEngine and all of the other Web stuff.
>> 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.)
>>
>> There are already many parts of Qt that run only on a subset of all the
>> platforms Qt has been ported upon, and there is no such thing as a
>> "minimum set of things to support to say that Qt runs on a given platform".
>>
>> My 2 c,
> 
> Here we walk smack dab into one of the many many many many reasons a SAD
> (or SAS if you prefer) is required for true software engineering. It is
> also one of the reasons Qt is starting to get such a bad reputation with
> developers.
> 
> A System Architecture Document specifies the minimum system requirements
> and minimal installation for a system or framework. This is one of the
> many reasons I believe there is no SAD for this product. I've certainly
> never found on. If you really honestly believe there is no definition of
> a minimum system allowed to call itself Qt that is like saying Microsoft
> can call Windows Linux if the port the ls command.

No, they cannot, because Linux is a registered trademark in the US.

For Qt, it's the Qt Project that sanctions your platform as a supported 
one ("supported" by the Qt Project, of course). You can say you've 
ported QtCore / QtGui/ Widgets / whatever on your new platform, you 
cannot say "Qt supports my platform" without the approval of the 
project, nor you can take a random GUI library or a random subset of Qt 
libraries and call it Qt (because Qt is also a registered trademark).


> Picture yourself as a shiny new developer. You've just been hired to do
> development for the Wizzy-Puffle OS. Don't worry there is a port of Qt
> for this platform. You will use that to develop all of your
> applications. Having never heard of Qt, you quickly do a Web search and
> find the on-line documentation for the API. You see all of these
> wonderful API calls and read and read. You go into your first planning
> meeting with stars in your eyes. You must commit to developing a contact
> manager for the OS which uses a database and has a nice GUI. They would
> like it done in a week.
> 
> NO PROBLEM!
> 
> You commit to it.
> 
> No you go back and find that the only thing "ported" was QObject. This
> is the entire "port" of Qt.
> 
> How do you feel?

This is an absolutely nonsensical example. The documentation clearly 
states which platforms are supported by Qt and exactly which parts of Qt 
are supported on that platform:

> https://doc.qt.io/qt-5/supported-platforms.html

> https://doc.qt.io/qt-5/qtmodules.html

And congratulations on "committing" on a project without using True 
Software Engineering methods that would've immediately showed the flaw 
in the required tooling.


> Every cross platform tool set I have encountered in my 30+ years in IT
> has made two horrific mistakes before disappearing from the marketplace.
> 
> 1) Not specifying and enforcing a minimum set of features/functionality
> before it could be claimed the tool set existed on a platform.

Which is not the case for Qt; those are called the Essential modules and 
are supported by every platform, as clearly stated in the links above.


> 2) Started adding things to a developers "favorite" platform then never
> porting them to other platforms.

Which is not the case for Qt. Qt has some minimal platform specific 
bits, whose job is fill in the final gaps in order to make what's 
otherwise a cross-platform app more integrated with the target OS. 
There's no "favorite" platform amongst the Qt developers.

Stop generalizing!


> The software battlefield is strewn with the corpses of products which
> made these two mistakes. The same mistakes you appear to be championing.
> 
> You want to know why Zinc went under/got eaten?

[snip]

No, I don't want to know why. This is not the mailing list for "let's 
share our software development stories". It's off-topic.


> You think the QObject example too extreme? How about no WebEngine or
> perhaps no database or insert-major-component-here.

WebEngine is NOT an essential module, as clearly listed in the 
documentation page. Specifically, it does not work on the iOS or Android 
ports of Qt, and likely also on other architectures (e.g. Qt on Linux/MIPS).


> As to "just the parts of Qt you need" I will let the P.S. from Uwe
> Rathmann answer that.
> 
> ===
> 
> PS: would be nice to have a feature to get rid of all QML related members/
> interfaces of QQuickItem/QQuickWindow
> 
> ===
> 
> It's almost impossible to port "just the parts you need" in a post QML
> world. It's certainly not economically viable.

It's more than possible because you may be totally good living without 
QML/QtQuick. And the "not economically viable" is another unwarranted, 
unproven statement. Stop going offtopic, and stop making false or 
unproven statements.


-- 
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/20181001/b2e1850a/attachment.bin>