Discussion:
Porting Qt to our RTOS
(too old to reply)
Kim Hartman
2018-09-27 00:09:47 UTC
Permalink
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?
Jason H
2018-09-27 03:33:52 UTC
Permalink
I think POSIX will make it very l vastly easier. But a graphical raster framebuffer should be doable. Look at QPA, the platform plugin architecture and see what you can adapt.

Warning: I've never tried to do it.
Sent: Thursday, September 27, 2018 at 2:09 AM
Subject: [Interest] Porting Qt to our RTOS
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?
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest
Tuukka Turunen
2018-09-27 06:53:17 UTC
Permalink
Hi Kim,

Even partial Posix will help you get going. It is possible to do without, but then more work will be needed.

When looking into QPA, perhaps the one for INTEGRITY is the one that you want to start with.

What kind of hardware and applications you are thinking about?

Yours,

Tuukka

On 27/09/2018, 6.34, "Interest on behalf of Jason H" <interest-bounces+tuukka.turunen=***@qt-project.org on behalf of ***@gmx.com> wrote:

I think POSIX will make it very l vastly easier. But a graphical raster framebuffer should be doable. Look at QPA, the platform plugin architecture and see what you can adapt.

Warning: I've never tried to do it.
Sent: Thursday, September 27, 2018 at 2:09 AM
Subject: [Interest] Porting Qt to our RTOS
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?
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest
_______________________________________________
Interest mailing list
***@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Thiago Macieira
2018-09-27 19:14:39 UTC
Permalink
Post by Tuukka Turunen
Hi Kim,
Even partial Posix will help you get going. It is possible to do without,
but then more work will be needed.
I echo the part about POSIX. If you don't have a POSIX layer, you're going to
have to port even things like filesystem support, so it's going to increase
your workload considerably.

We don't require full POSIX, much less POSIX certification. Just look at
Android: their C library (Bionic) is a very crappy implementation of the POSIX
specification, but it's sufficient for Qt needs. But the better your
implementation is, the less you'll see me complain.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Kim Hartman
2018-09-27 22:26:19 UTC
Permalink
Good reference. Thanks!

-----Original Message-----
From: Interest <interest-bounces+kim.hartman=***@qt-project.org> On Behalf Of Thiago Macieira
Sent: Thursday, September 27, 2018 12:15 PM
To: ***@qt-project.org
Subject: Re: [Interest] Porting Qt to our RTOS
Post by Tuukka Turunen
Hi Kim,
Even partial Posix will help you get going. It is possible to do
without, but then more work will be needed.
I echo the part about POSIX. If you don't have a POSIX layer, you're going to have to port even things like filesystem support, so it's going to increase your workload considerably.

We don't require full POSIX, much less POSIX certification. Just look at
Android: their C library (Bionic) is a very crappy implementation of the POSIX specification, but it's sufficient for Qt needs. But the better your implementation is, the less you'll see me complain.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Kim Hartman
2018-09-27 22:20:37 UTC
Permalink
Thanks Tuuka (and others),

We've ported much of the BOOST libraries, so pthreads are most possible. I've started an internal audit of the rest of POSIX services we would need in order to create an INtime QPA. Is there a more comprehensive list of POSIX calls needed for GUI functionality? Is there such a thing as a generic QPA?

Kim

-----Original Message-----
From: Tuukka Turunen <***@qt.io>
Sent: Wednesday, September 26, 2018 11:53 PM
To: Jason H <***@gmx.com>; Kim Hartman <***@tenasys.com>
Cc: ***@qt-project.org
Subject: Re: [Interest] Porting Qt to our RTOS


Hi Kim,

Even partial Posix will help you get going. It is possible to do without, but then more work will be needed.

When looking into QPA, perhaps the one for INTEGRITY is the one that you want to start with.

What kind of hardware and applications you are thinking about?

Yours,

Tuukka

On 27/09/2018, 6.34, "Interest on behalf of Jason H" <interest-bounces+tuukka.turunen=***@qt-project.org on behalf of ***@gmx.com> wrote:

I think POSIX will make it very l vastly easier. But a graphical raster framebuffer should be doable. Look at QPA, the platform plugin architecture and see what you can adapt.

Warning: I've never tried to do it.
Sent: Thursday, September 27, 2018 at 2:09 AM
Subject: [Interest] Porting Qt to our RTOS
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?
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest
_______________________________________________
Interest mailing list
***@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Thiago Macieira
2018-09-28 04:04:31 UTC
Permalink
Post by Kim Hartman
We've ported much of the BOOST libraries, so pthreads are most possible.
I've started an internal audit of the rest of POSIX services we would need
in order to create an INtime QPA. Is there a more comprehensive list of
POSIX calls needed for GUI functionality? Is there such a thing as a
generic QPA?
POSIX is not needed for GUI. You need it for QtNetwork and QtCore.

For GUI, we expect the framebuffer access to be OS-specific.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Allan Sandfeld Jensen
2018-09-28 07:24:50 UTC
Permalink
Post by Kim Hartman
Thanks Tuuka (and others),
We've ported much of the BOOST libraries, so pthreads are most possible.
I've started an internal audit of the rest of POSIX services we would need
in order to create an INtime QPA. Is there a more comprehensive list of
POSIX calls needed for GUI functionality? Is there such a thing as a
generic QPA?
As Thiago said Posix is for the core stuff not for the GUI, though it is more
than filesystem and network, the core eventloop needs a unix poll(), or a port
of glib. For a gui you just need some way of reading input and for rendering
output. If you support libinput for instance the first part is covered, but
you can also do your own thing, and the second just means we need a API for
opening and writing to a framebuffer and perhaps tell the system when it
should flip/sync the buffer. Getting the graphics working is almost the
simplest part.

Allan
Roland Hughes
2018-09-27 15:14:50 UTC
Permalink
Post by Kim Hartman
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 means that a lot of shortcuts
get taken and are allowed as long as the test-nothing automated test
clears Jenkins. 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.


http://www.logikalsolutions.com/wordpress/information-technology/how-canonical-fixes-most-major-ubuntu-bugs/

http://www.logikalsolutions.com/wordpress/information-technology/2411/

You should instead look into OpenZinc.

http://openzinc.org/

This is a lightweight set of C++ wrapper classes for GUI. It was a
commercial product back in the days of DOS, OS/2, Win 3.x and some MAC
OS which no longer exists. WindRiver consumed the product to make it the
standard GUI library for their RTOS. I stopped following it after that.
Now it appears to be both a spun-off OpenSource and an independent
commercial cross platform product again.

They didn't release the 5.x stuff, but you can start with 4.2 and see
how things go.

http://openzinc.org/Downloads.html

Odd that they support gcc on linux and OpenWatcom on all other
platforms. I only find that odd because OpenWatcom (well, commercial
Watcom) had an IDE which wasn't bad. Talk was that was to be ported to
Zinc. Be nice if it was one package again.

At any rate Qt isn't going to be RTOS friendly. At least not as RTOS
friendly as something which is just a wrapper around services already
provided by the RTOS.

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.

For the Journey you're on little Hobbit, I humbly recommend you try
OpenZinc first.

If that just doesn't work for some reason, see if you can find C-Scape.
It didn't do a lot and was mostly only for DOS so should be easy to port.

http://www.drdobbs.com/c-scape-and-look-feel/184402269

There also seems to be some commercial thing with a similar name.

https://www.omega.com/manuals/manualpdf/M_CSCAPE_PROGRAM.pdf


If you really want to make me smile, find a copy of Greenleaf Data
Windows. I loved the Greenleaf products back in the DOS days.

http://www.edm2.com/index.php/Greenleaf_Data_Windows

http://www.logikalsolutions.com/wordpress/information-technology/how-far-weve-come-pt-1/

http://www.logikalsolutions.com/wordpress/information-technology/expires-faster-than-milk/

KEWL!!

This place may have some!

http://emsps.com/oldtools/misc-g.htm

I'm pretty certain I've thrown out all my 5 1/4 floppies and a goodly
number of 3.5" as well. Data Windows came with full source and was DOS
INT based for mouse. This would be text based graphics so it would have
a 1980s GUI look which is not all bad, especially for industrial
control. You would have to hack your own touch screen pinch zoom support
if you wanted it.

Btw, this product's non-existence is a DIRECT RESULT of Janet Reno (at
the behest of the Clintons) committing treason against the human race.
Greenleaf Data Windows existed long before Microsoft started committing
wire and mail fraud with wanton abandon calling Windows an operating
system. As a result of Janet Reno not putting Bill Gates in prison and
even granting him/Microsoft domain over everything called Window or
Windows, little bitty Greenleaf got weekly threatening letters from
criminal attorneys at Microsoft and after about a year they discontinued
the product.

I have seen Greenleaf Data Windows pop up on various Abandonware sites.

If you cannot find the source for Data Windows via safe legitimate means
on your own you can try back channeling through Mark Nelson.

https://marknelson.us/posts/2006/08/25/don-killen-rip.html

If he doesn't have it he might be able to put you in touch with one of
the other developers (Ruby, Danny?) or the last people to legally own
Data Windows.

I'm spending so much time on Data Windows because you were mentioning
INT10 and a DOS only GUI library would be your best bet. You will have
the advantage of having only one memory model (vs. Compact, Small,
Medium and Large before we even got into DOS extenders and overlay linkers).
--
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
Thiago Macieira
2018-09-27 19:23:38 UTC
Permalink
On Thursday, 27 September 2018 09:03:55 PDT Giuseppe D'Angelo via Interest
Post by Roland Hughes
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.
Nor mine.

And I did work for Trolltech and Nokia, and back then we did not use agile. I
doubt the team is using it now.
Post by Roland Hughes
means that a lot of shortcuts
get taken and are allowed as long as the test-nothing automated test
clears Jenkins.
This is simply FUD, and it's offensive to whoever (like me) develops Qt
as an external contributor and still cares about its quality.
And we don't use Jenkins. This is a completely FALSE assertion, no basis in
truth, intended to do harm. It's very easily proven wrong, since the testing
is open, clearly tests and failures cause changes to be rejected. In other
words, this sentence is defamation.

Roland, consider yourself on notice. Your comment about OpenZinc was fine --
even if it is a competitor, telling people about their options is the right
thing to do. You can relate your experience with Qt and where things did not
satisfy you. But you cannot make false assertions and stupid generalisations.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Uwe Rathmann
2018-09-28 08:55:15 UTC
Permalink
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.

Have a look at https://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.

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
Uwe Rathmann
2018-10-01 07:56:44 UTC
Permalink
Hi Guiseppe,
(The topic is still "how to port Qt to another platform".)
It is in the nature of discussions, that they might change direction -
like it happened with the AGILE side track.
(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.
A good summary of my point of view - even if the last one was not on my
list so far and I would add "being more careful with resources".
But I don't want to start this conversation in this thread, let's have
it in the right places.).
You might have access to these "right places", public forums is all what
I have.

Actually we already made a presentation at the QtCon 2016 ( https://
conf.qtcon.org/en/qtcon/public/events/428.html ) without seeing much of
an effect. Showing an implementation is probably my best option to fuel
the discussion.

If you are trying to improve things from the inside and you are
interested in experiences on our journey - don't hesitate to contact me.

ciao,
Uwe
Roland Hughes
2018-09-29 21:35:10 UTC
Permalink
Post by Roland Hughes
Post by Kim Hartman
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.
Post by Roland Hughes
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.
Post by Roland Hughes
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
Bernhard Lindner
2018-10-01 09:42:55 UTC
Permalink
Hi!

Forgive me for butting into this off-topic discussion about "true software egnineering"
(which is a horrible wording).

AFAI understand that discussion is about quality.

Well, if you want to know how to develop quality software, you need to look into safety
(not security!) industry. People which are responsible for other peoples life and health
tend to start *really* caring about quality. So if you want to learn about methods to
increase software quality, go checking what safety engineers do.

Of course safety is a different and expensive world by its own and you can not copy their
methods for conventional software since the effort is too big, but still it shows you
which methods are suited to increase quality.

You will see that what Roland states is a part of these methods.

PS: I have more or less given up reporting Qt bugs and suggestions for years. Judge
yourself if this a reasonable and/or desired effect of your way of handling issues or not.
I miss Qt 4.0.0 times a lot. It was fun back then.
--
Best Regards
Bernhard Lindner
Tuukka Turunen
2018-11-26 10:24:01 UTC
Permalink
Hi,

About fixing bugs, according to bugreports.qt.io we have:
- Over 2000 bugs fixed in Qt 5.12 LTS since Qt 5.9.7
- Over 3000 bugs fixed in Qt 5.9 LTS since Qt 5.6.3
- Over 2000 bugs fixed in Qt 5.6 LTS since Qt 5.5.1

That sums up to about 7000 bugs fixed in the past 3 years. In addition there are always bugs fixed that did not have a report.

Yours,

Tuukka

On 01/10/2018, 12.43, "Interest on behalf of Bernhard Lindner" <interest-bounces+tuukka.turunen=***@qt-project.org on behalf of ***@bernhard-lindner.de> wrote:

PS: I have more or less given up reporting Qt bugs and suggestions for years. Judge
yourself if this a reasonable and/or desired effect of your way of handling issues or not.
I miss Qt 4.0.0 times a lot. It was fun back then.
Uwe Rathmann
2018-11-26 13:32:12 UTC
Permalink
Post by Tuukka Turunen
That sums up to about 7000 bugs fixed in the past 3 years.
Fixed or closed ?

As you started doing bulk closing by robots recently, those type of
statistics might have become somehow meaningless.

Uwe
Tuukka Turunen
2018-11-27 11:04:48 UTC
Permalink
Hi,

Those were ones closed with resolutions fixed and done. So the ones closed doe to need more info not provided or won't fix are not counted.

Yours,

Tuukka
Post by Tuukka Turunen
That sums up to about 7000 bugs fixed in the past 3 years.
Fixed or closed ?

As you started doing bulk closing by robots recently, those type of
statistics might have become somehow meaningless.

Uwe

_______________________________________________
Interest mailing list
***@lists.qt-project.org
https://lists.qt-project.org/listinfo/interest

Roland Hughes
2018-09-29 21:45:58 UTC
Permalink
Post by Thiago Macieira
And we don't use Jenkins. This is a completely FALSE assertion, no basis in
truth, intended to do harm. It's very easily proven wrong, since the testing
is open, clearly tests and failures cause changes to be rejected. In other
words, this sentence is defamation.
Roland, consider yourself on notice. Your comment about OpenZinc was fine --
even if it is a competitor, telling people about their options is the right
thing to do. You can relate your experience with Qt and where things did not
satisfy you. But you cannot make false assertions and stupid generalisations.
I should have said Jenkins like process. You prefer Coin.

https://blog.qt.io/blog/2016/08/08/coin-continuous-integration-for-qt/

SSDD

There were no stupid generalizations.

Btw, I'm prepping a machine to take to a client site tomorrow. They have
a really widely distributed package I wrote in Qt some years ago. Anyone
who has walked into a big box or office supply store has seen it. No,
I'm not allowed to name it.

I'm returning there for a few months to participate in a re-evaluation
process. They are considering ditching Qt for Electron. Doing side by
side development on all platforms to see which works best for them. When
we stumble into one of those features we need which doesn't exist on all
platforms, there won't be any way I can continue making a case for Qt.
--
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
Vlad Stelmahovsky
2018-09-30 08:26:33 UTC
Permalink
Post by Roland Hughes
I'm returning there for a few months to participate in a re-evaluation
process. They are considering ditching Qt for Electron. Doing side by
side development on all platforms to see which works best for them.
When we stumble into one of those features we need which doesn't exist
on all platforms, there won't be any way I can continue making a case
for Qt.
Qt is far more superior over Electron in any sense except only one:
developer in Qt must be more skilled than common html/css/js developer
due to tight links to C++

So, your customer does not choose between "good" and "bad" tech. It's
just a question of HR and TTM
Continue reading on narkive:
Loading...