[Interest] Guide me through the Qt offerings for GUIs

[Roland Hughes]

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.


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