[Interest] Guide me through the Qt offerings for GUIs

[Giuseppe D'Angelo]

On 20/04/2021 15:10, Roland Hughes wrote:
> 
> On 4/20/2021 5:00 AM, Giuseppe D'Angelo wrote:
>> On 18/04/2021 14:50, Roland Hughes wrote:
>>> I guess QML is more present in embedded? Or maybe some entreprise stuff
>>> we don't know about...
>>> Just phones and John Deere.
>> This is false, as a quick walk through the customer showcase on TQC's
>> website will show.
> It's completely true. That tiny subset on the Web site doesn't scratch 
> the surface.

So there's even *MORE* QML used in embedded than what's advertised on 
TQC's website? That's great news!


> It certainly doesn't encompass my customer base and I 
> haven't heard anyone pipe up on here using QML for anything 
> non-significant that wasn't phones or John Deere. 

Ah ok, since *you* never saw QML used on embedded projects, then it 
doesn't exist. How silly of me assuming otherwise.


>>> 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
>> This is also false. SXs have never been defective CPUs.
> 
> You need to actually learn processor history or at least do some 
> research before you speak.

You need to learn to use Google before you speak.

Or actually, better not: last time you used Google you fell for *two* 
April fools' blog posts, claiming they were true. For that, we haven't 
received apologies yet. So who tells us that it's different this time?

> https://lists.qt-project.org/pipermail/interest/2019-December/034255.html



> The 486SX was a marketing quirk. Intel had a high failure rate (low 
> yield) on the FPU. When a CPU passed DX testing it was sold as a 486DX. 
> When it failed testing it went down another line where they "cut some 
> pins" so the chip couldn't communicate with the bad FPU, put an SX on it 
> and sold scrap at a discount.

This has widely been debunked.

The SXs were introduced to the market _years_ after the introduction of 
the DXs. Intel didn't start to have massive production problems all of a 
sudden and thus decided to pull this stunt. The SXs were _designed_ to 
have the FPU disabled, and their FPU was for this reason ever tested. 
The only reason for the introduction of the SX was market segmentation 
to compete against AMD.

Here's some links for you, given you seem to able to Google "486 sx 
defective" (and leave it in the URLs that you link), but somehow 
conveniently IGNORING the first couple of results, even if they include 
first-hand accounts of Intel engineers who worked on the 486 that 
disprove the whole defective story:

http://www.os2museum.com/wp/lies-damn-lies-and-wikipedia/

By the way, did you notice that the Wikipedia page that YOU linked 
doesn't talk about those chips being "defective" DXs?
Because that's a lie, as discussed in the talk page:

https://en.wikipedia.org/wiki/Talk:Intel_80486SX



>>> 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.
>> Are you aware that Qt has had Vulkan integration classes since 5.12 (?),
>> and Vulkan can be used as a Qt Quick backend in Qt 6?
>>
>> The ability of painting from multiple threads (or better, to build
>> command buffers from multiple threads) doesn't magically solve the
>> problem of manipulating data structures safely from multiple threads.
>> The single threaded CPU-based_painting_  of the syntax highlighting has
>> hardly ever been an issue; its_generation_  has, as it involves
>> modifying a shared data structure (while also the user is modifying it)
>> without races and without locking against the GUI thread. QTextDocument
>> design is unlikely to fit the bill here; a different design sounds
>> anything but easy, but the underlying graphics API has very little to do
>> with this.
> 
> The API has a ___lot___ to do with this as the dude putting out 
> featherpad is learning the hard way and every editor developer 
> attempting to use Qt and only Qt before them. The single-thread-i-ness 
> hits a hard wall. That's the biggest issue.
> 
> That is followed by all of the "why would anyone have done __that__" issues:
> 
> like burying the selection active inside a private internal class and 
> basing it on the difference of cursor position thus making it physically 
> impossible to follow numerous time honored editor traditions of <Begin 
> Mark> <End Mark>. Unless you gut the class and redevelop from scratch 
> you can't have an N-key key sequence for begin mark and have the editor 
> class understand a selection has been enabled even though there is zero 
> cursor difference.
> 
> Close on the heels of that "Why are they highlighting the whole thing?" 
> when you only need the currently visible lines and possibly a screen 
> up/down. Open up a 10,000 line source file in editors using Scintilla or 
> the Electron JavaScript based things, or even GUI Emacs even on an 
> i5-gen3 and you are almost instantly taken to the line you were on with 
> perfect syntax highlighting. Because QPlainTextEdit has to do everything 
> in the main event loop and appears not to understand scope of 
> visibility, it starts at the top and works its way down. Bad enough with 
> one file, but try having three tabs open all with large files all using 
> regular expressions for highlighting in the main event loop.

This is just random technical jargon without any factual information. It 
doesn't even deal with graphical APIs, or with what I exposed.

I can open a 10k lines C file in Qt Creator, which uses QPlainTextEdit, 
and it gets syntax highlighted *immediately*. That even includes 
*parsing*, which isn't clearly done via regular expressions.

This doesn't prove or disprove anything. (Well, it proves that 
single-threaded CPU painting isn't the problem.)


> Even economists know the story of the 486SX.
> 
> https://www.google.com/books/edition/The_American_Economic_Review/iP6yAAAAIAAJ?hl=en&gbpv=1&bsq=486sx+defective+fpu&dq=486sx+defective+fpu&printsec=frontcover
>   
> Even Byte Magazine told the 486SX story.
> https://www.google.com/books/edition/Byte/bTxVAAAAMAAJ?hl=en&gbpv=1&bsq=486sx+defective+fpu&dq=486sx+defective+fpu&printsec=frontcover
> 
> You will find it is also one of the many case studies used by good management schools about turning failure into profits.

And they all fell for a urban legend.

We like celebrating champions, clever thinking, success stories (in 
business, science, sports).

We don't really like to know that it's a perfectly accepted business 
practice for a company to deliberately "sabotage" its own products (in 
order to undercut competition; segment the market; increase profits; and 
what not). Maybe because it's just cheaper to mass-produce the very same 
die and shut down the FPUs via a shorted pin rather than design a brand 
new die; or, maybe because it's acceptable to sell products at zero 
margins or even at a loss if that means kicking the competition out 
(because then you can raise prices and squeeze.)

Not only performing such an evaluation would require *a lot* of 
familiarity with the economical, financial, marketing aspects of it 
(aspects which are everything but trivial); but if you put this story on 
a "popular" magazine, and say "Isn't this clever? And everyone does it! 
 From airlines to the 53 editions of Windows." -- Oh my, it might make 
capitalism look BAD! And capitalism can't look bad, can it?

> The error propagates itself, grows, and ultimately survives only on one condition—that it finds a *favorable cultural broth* in the society where it is spreading. Through it, people unconsciously express all their prejudices, hatreds, fears, all their *strong emotions*.

(From "Réflexions d'un historien sur les fausses nouvelles de la 
guerre", Marc Bloch; emph. mine.)


Besides: I've read on the New York Times about this website that puts 
kittens in square bottles! That's terrible! And what about all those 
alligators in the sewers, why doesn't the government do something about 
them?


-- 
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4329 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20210420/c4d3bc9d/attachment.bin>