[Interest] Guide me through the Qt offerings for GUIs
roland at logikalsolutions.com
Sun Apr 18 14:50:39 CEST 2021
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.
Actually quite a few text editors taking either Electron or pure
> I've also been monitoring:
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.
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 -
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
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
paint in the main event loop".
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.
"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.
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
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.
Roland Hughes, President
More information about the Interest