[Interest] Porting Qt to our RTOS

[Roland Hughes]

On 9/28/18 9:26 AM, Giuseppe D'Angelo wrote:
>>> I am investigating how to bring Qt to our INtime RTOS. The INtime Distributed RTOS runs on standard PC hardware as a multicore AMP OS (no SMP and not POSIX compliant). Currently the RTOS has only a text console output based on INT10 services. The RTOS is fully preemptive, with strict priority based scheduling, managed process services with rich IPC services. The development environment is tightly coupled with MS VC (2008 and on) with ANSI C and C++11 language support. The RTOS is very stable and been commercially deployed for decades. It lacks a means for graphical programming, mostly for industrial controls application. What is the means to port Qt to this RTOS? We're not intending on building out OpenGL ES 2.0 unless absolutely necessary. I've read some marketing materials about Qt on MCU, however the details seem very thin. It's not Windows, Linux, OSX, Android, QNX, Integrity, or VxWorks... how to go about getting this done?
>> The short answer is that you shouldn't.
>>
>> The AGILE processes behind Qt development
> 1) This is an unproven and unwarranted assertion about whatever way Qt
> is developed. Since most of upstream development happens behind close
> doors at TQC, please refrain from making such statements, unless you
> happen to be working at TQC and can comment on the matter. And, even so,
> other development (e.g. the one*I personally*  do on Qt) does not happen
> to be using agile processes.
>
>
> 2) This is a loaded sentence. Not only it's off-topic regarding the
> matter at hand ("how do I get Qt to run on another OS"); not only it's
> written to be provocative; but the_unwritten_  major premise of the
> syllogism is that agile processes are "bad" (for whatever reason). This
> major premise has not been established in this community.
>
> And no, I don't care at all if agile development is better or worse than
> some other model; so do not bother me with 300 links about how agile has
> failed in the last 30 years of software development.
>
> What I care about is not having loaded and off-topic sentences, with
> unwarranted claims, on this mailing list. I'm arguing about the logical
> fallacy, not the truth of the statement. Using that fallacy is
> disrespectful.

Syllogism, nice word. For those who did not wish to look it up

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.

True software engineering requires creation of The Four Holy Documents 
up front.

     1) Business Requirements Document (BRD)
     2) System Requirements Document (SRD)
     3) System Architecture Document (SAD a.k.a. System Architecture 
Specification SAS)
     4) System Specification Document (SSD a.k.a. Functional Specification)

These are required for EVERY release. The only thing which does not 
require it is a patch which fixes one or more bugs WITHOUT ANY NEW 
FEATURES OR ENHANCEMENTS THROWN IN.

Anything which does not create The Four Holy Documents up front is one 
of the 32767 flavors of AGILE trying to call itself something other than 
AGILE.

The System Architecture Document takes a long time. It also requires a 
heavy hitter to create. In here you will find specified memory sharing 
rules and the one technique allowed as well as messaging mandates and 
many other things.

The SSD for an API like Qt specifies the classes, parameters of each 
method and return values. Basically, everything you see here:

https://doc.qt.io/qt-5/qstring.html

gets written before the first line of code. It is not generated from 
Doxygen comments or some other means later.

Why?

Because code reviews aren't silly little check-in things. Code reviews 
under true software engineering require a formal process with an 
external secretary completing a formal document. MOST IMPORTANTLY you 
review the code not for coding standards or some little check-in before 
continuous integration build, YOU REVIEW THE CODE FOR VIOLATIONS OF THE 
SAD OR THE SSD.

I need to point out a recent statement from Alex

===

and last but not least there are things which are too risky to fix 
because they have an extremely high potential to break other things

===

The type of bug Alex describes here requires one of two things to be true.

1) It violated the SAD

2) It violated the SSD

It cannot happen when true software engineering principals are used and 
The Four Holy Documents are created up front.

It does happen with AGILE and the 32767 flavors of AGILE, many of which 
choosing not to be called AGILE.

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. 
Launching a mechanical probe somewhere isn't anywhere near as difficult 
as launching a tin can full of humans at a rock, making it land, 
launching it and have the humans land back on earth alive, even if the 
"landing" happens to be a splash down in the ocean.

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.

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, but, those types of "forget 
about them until that release is unsupported" bugs can't happen with 
true software engineering and The Four Holy Documents. Regressions like 
that must violate either the SAD or the SSD so they never pass review.

Even if ALL of the reviewers were drinking at a bar instead of reviewing 
code, true software engineering requires a QA team which works 
__completely__ from The Four Holy Documents creating a test plan. (For 
those who don't work in FDA regulated environments, this is _exactly_ 
what is required. Reports differ about whether it involves prison time 
or just a huge fine and banning from the medical device world, but, they 
all agree violating it isn't trifled with.

>> 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.

> 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. 
That's a completely different story.
>> 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.

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?

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.
2) Started adding things to a developers "favorite" platform then never 
porting them to other platforms.


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? They used Borland's C++ 
compiler which had tons of "extensions" for development and added new 
features to Windows first. By version 5 it had become almost exclusively 
a Windows development tool set with all other platforms treated like 
orphans. It was the best at the time so WindRiver bought it and threw 
management out on their back sides. Then the product focused exclusively 
(almost) on WindRiver RTOS.

Zinc let bugs rot forever too. Sales wanted newer and greater features 
for better platforms to sell more licenses and training, etc. ***There 
was no profit to be had in fixing bugs***. Most of those were left to 
the people who bought the product. We had to create a source patch, dial 
into the BBS (yes, I said dial in), log on, answer all of the required 
questions and upload the required files. At some point someone at the 
company "might" choose to roll it in. One thing was certain, you had to 
back your patch out before you could apply any patch files they sent 
you. Lots of commercial package vendors used the same (or very similar) 
patch tools back then.

Yeah, this letting bugs rot thing really honks me off. I have watched 
company after company do this with commercial product after commercial 
product. In the past couple of years I was at a client site which paid 
for commercial licenses and for the company to setup their Boot-2-Cute 
target. The developers encountered a bug. They contacted support.

"Yes, we know about that issue. It's been around for a few years now. 
All of our development team is focused on new stuff. If you want to pay 
us N-thousand dollars we will fix your bug. Otherwise you have to fix it 
yourself or hope a volunteer does."

I wasn't on the phone call. That is what both the owner and head of 
software development told me. N wasn't a single digit value either. 
After having spent all of that time and money they came ___this___ close 
to using a different framework and platform. They may have finally 
bailed now. I haven't been there for a while and haven't kept in touch. 
They were getting really tired of always being asked for money.

Were you paying attention when this list had a serious discussion about 
how impossible it is for someone from the outside to submit a fix? Yes, 
there was something in the digest about being able to post one's fix 
here, but, I have yet to see an announcement of a fix for a bug being 
posted in here and actually making it into a release. I don't read each 
and every post though, so, might have missed it.

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

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.


-- 
Roland Hughes, President
Logikal Solutions
(630) 205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us