[Interest] Guide me through the Qt offerings for GUIs

[Rui Oliveira]

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