Well,
About the automotive industry, the Qt website itself presents some use
cases:
https://resources.qt.io/customer-stories-automotive
On the old bugs, I've come across this one while writing some code:
https://bugreports.qt.io/browse/QTBUG-6864
P2 importance! And 11 years old...
If the TQtC decided to spend 18 months doing nothing else than cleaning
up the bugreports backlog, I'd 100% support it!
About threading techniques, I don't have much to say, I think it's one
of those historical things...
Rui
Em 18/04/2021 13:50, Roland Hughes escreveu:
On 4/18/21 5:00 AM, Rui Oliveira wrote:
If you want to talk about "like" QQC... Do electron apps count? I do use
VSCode a lot. But I guess those are a league of their own.
No, Electron doesn't count. Electron is what replaces Qt in many many
former Qt environments. There are a lot of text editors and other
desktop apps written under Electron.
https://atom.io/
Actually quite a few text editors taking either Electron or pure
JavaScript approach, assuming Wikipedia could be trusted
https://en.wikipedia.org/wiki/Comparison_of_JavaScript-based_source_code_editors
I've also been monitoring:
https://bugreports.qt.io/browse/QTBUG-78634
https://bugreports.qt.io/browse/QTBUG-74407
Well, client of mine that using a commercial license that tipped the
scales north of $600K emailed me off-list to rag about this decade old
bug.
https://bugreports.qt.io/browse/QTBUG-12055
They lost half a staff day on this. Not one person lost half a day,
the project team. I think they have north of twenty people on the
project still. You can't have a medical device with random crashes so
when one turns up, it's all hands on deck.
See this line -
https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/serialization/qtextstream_p.h#n72
<https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/serialization/qtextstream_p.h#n72>
=====
Issue is that it doesn't properly unregister the signal from QFile
when you tell it to, so you think it would be done with it but nope,
signal fires when QFile is closed and now you have a race if you
continue to use that QFile object. You can see in the code they
_thought_ they were, but actually they were removing all connections
to QTextStream private class signals... Of which there are none.
Probably works "fine" if you are largely single threaded, but not for
multiple threads. As pointed out in that report, a mutex should have
been ok for synchronization, save for this bug.
=====
The fix has been known for a long time. Almost as long as the bug has
been in the database.
I guess QML is more present in embedded? Or maybe some entreprise stuff
we don't know about...
Just phones and John Deere. I haven't spoken with anyone working on
Ford projects in a while but last I heard QML was on its way out there
too.
QML was a bad idea trying to get around a legacy problem without
actually fixing the legacy problem. The legacy problem is the single
thread-i-ness of Qt. Back when Intel was selling 486 chips with a
manufacturing defect as SX
https://en.wikipedia.org/wiki/Intel_80486SX
We didn't have high end graphics. We were lucky to have 33Mhz and
threading libraries were not robust. Many would only yield the single
core when an I/O operation happened. That thread calculating Pi to
2000 decimal places locked up your machine. Keep in mind that an 80
MEG hard drive was just massive. Corporate desktops still tended to
have 20 MEG drives and managers who didn't really need it had 40 MEG.
Most people pull down stupid cat videos larger than that today. You
need to understand that so you understand just how little I/O was
really happening. There was nothing you could cobble together in the
little computer world to store a Terabyte. You couldn't even really
get to a Gig on a network of shared drives.
Single thread-i-ness design decisions weren't horrible then.
* You can only paint in the main event loop
* Data models used by Widgets have to exist in the main event loop
* Not everything is tested across threads (see above bug)
These short sighted decisions weren't unique to Qt. Poke around in
Google books for PC Magazine and other programming magazine articles
of the day and you will find things written about the 1,000 line
switch statements that were the center of most every Windows program.
Zinc and every other GUI library had a similar problem. Zinc didn't
even have a hook in their event loop so you could give time to things
like serial communications or other devices. You had to roll your own
event loop to do that.
The world of JavaScript has done a lot of work solving "You can only
paint in the main event loop".
https://stackoverflow.com/questions/36942555/does-the-electron-framework-allow-multi-threading-through-web-workers
https://mozillagfx.wordpress.com/2017/12/05/off-main-thread-painting/
I haven't kept up on the whole "worker" thing JavaScript and browsers
have going on. I just know that is why you see themes and syntax
highlighting in things like VSCodium, Atom, etc. that look great and
are really fast. If you try to do them in the C++/Qt world you pay a
heavy coding price or you watch machines grind to a halt when you open
a 5000 line source file. That's one bad trait that made it over to
CopperSpice too.
The dude coding FeatherPad seems to be slowly learning the reality as
well.
https://github.com/tsujan/FeatherPad
"Refactored the code of syntax highlighting 15 days ago "
The QPlainTextEdit and use of regular expressions all having to run in
the main event loop to implement syntax highlighting, brace matching,
etc. duth take a toll. Signals out from other threads to tell the
Widget to paint something tend to not work well either.
It's been a while since I looked at the KATE code base to see how they
are handling syntax highlighting.
https://github.com/KDE/kate/tree/master/kate
The developers of Juffed punted and used Scintilla_qt. You will find
many many editors using one of the Scintilla libraries under the hood
because they mostly solved this problem. I think they even solved the
problem of only highlighting the visible lines plus a few on either
side as well. This dramatically improves performance because you are
only highlighting 80-100 lines instead of all 10,000 when you load a
huge source file.
All of this is why I'm so excited to read about the Vulkan stuff going
on with the CsPaint library and the Vulkan links I sent you earlier.
On the surface it seems like someone talked to people who write
software on big computers before work started. Need to dig deeper to
be really certain, but you communicate with a "loader" that can
support many revs of the API.
Hopefully they did it under the hood like big computers.
Small API to negotiate common API version.
Identify a series of shared memory regions used for communication.
Your program builds things per the agreed upon API version in the
shared/accessible region then swats the loader with a "load that"
command.
If they did that, we can paint from anywhere. Instead of low level
manipulation of the screen(s) the screens become a service.
Applications just communicate with the service.
_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
