On 20/04/2021 15:10, Roland Hughes wrote:
On 4/20/2021 5:00 AM, Giuseppe D'Angelo wrote:It's completely true. That tiny subset on the Web site doesn't scratch the surface.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.
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 SXThis 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=frontcoverEven 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.dang...@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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
