Post by Roland HughesPost by Kim HartmanI 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.
Post by Roland HughesYou 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.
Post by Roland HughesQt 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