[Interest] Guide me through the Qt offerings for GUIs
roland at logikalsolutions.com
Tue Apr 20 15:10:11 CEST 2021
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. 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. Even the one medical
device we have been told about on this list has said you can't do
anything in QML, only painting.
>> 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.
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.
The 386SX was a different design. The 486SX was simply unloading 486DX junk.
>> 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
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
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.
The underlying graphics API contributes to the single-thread-i-ness
which really drops the 6-bottom plow in behind the lawn mower.
Integration isn't service. During the era of the 286 and OS/2 Integration made sense. Today you need a stand alone service having a limited physical communication API that can handle hundreds of different logical API versions. This is how you do things in the world of large applications so you can support things for 30+ years.
Even economists know the story of the 486SX.
Even Byte Magazine told the 486SX story.
You will find it is also one of the many case studies used by good management schools about turning failure into profits.
The other case studies they will cover are:
the Sony Walkman. A shiny new VP combined a failed portable tape recorder that couldn't record with an earbud/headphone set that had no market. Both R&D failures that, when combined became a highly profitable niche market.
3M Post-It Notes: Engineers and scientists set out to create a glue so strong it made Crazy glue look like Elmer's School Glue. They took the path of exponentially increasing the length of time to dry. The end result was it never really dries and bonds. It was a complete failure until someone used it to glue little yellow pieces of paper together in the form of note pads. People found you could stick them to anything and they would come right off.
Gasoline: This was largely a byproduct of making heating and lamp oil. It was dumped into rivers and burned off . . . Until Henry Ford came along.
Vulcanization: Mr. Goodyear meeting investors in a shed that had a wood stove for heat was raging that they wouldn't give him more money. Rubber tires were so flimsy and blew out so often that "can I kick the tires" became a line in American culture. Flinging his new hunk of rubber around while hollering and gesturing with his arms, it landed on the hot wood stove. After scraping it off the stove they found the result was still flexible and far more impervious to cuts. He got his money.
Roland Hughes, President
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Interest