QML

Post Reply
Zitrax
Posts: 1
Joined: Wed Aug 16 2017 6:00 pm

QML

Post by Zitrax »

Hi,

just a question since I have not yet actually tried it out (but failed to find any info after googling a bit). Does copperspice work together with QML based projects ?
barbara
Posts: 443
Joined: Sat Apr 04 2015 2:32 am
Contact:

Re: QML

Post by barbara »

At this time we have the QML module disabled in CopperSpice. There are several pieces of this system which need to be enhanced to work properly with the meta object system. One of the other issues is which Java Script engine should be used.

If this is something you are interested in helping us work on please let us know as we would like some help in this area.

Barbara
Zitrax wrote:Hi,

Does copperspice work together with QML based projects ?
charley
Posts: 2
Joined: Tue Oct 15 2019 8:05 pm

Re: QML

Post by charley »

After some offline conversations with some of the CopperSpice developers (in the past):

*- QML is not currently part of CopperSpice
*- there is interest in something declarative like QML
*- there is some concern that the current implementation and design of QML in the current Qt-distros is lacking (my words and assessment)
*- some prototyping and discussion of a declarative-like-thing has been kicked around, but not to a reviewable design

I'm a fan of the declarative QML-type idea (and have used QML extensively); but also see the place for the traditional composable widgets that interface more easily and directly with C++. I think there is definitely room for a QML-like-thing, but IMHO it probably won't be QML (because specific design and behavior changes would be necessary, IMHO).
seasoned_geek
Posts: 246
Joined: Thu Jun 11 2020 12:18 pm

Re: QML

Post by seasoned_geek »

No QML is one of the reasons I'm seriously looking at CopperSpice for several clients.

Putting it bluntly, QML is a hand polished turd.

Besides the massive security issues, you have not saddled a battery powered device with a native compiled event system, QML "engine" and JavaScript "engine." Highly resource consumptive.

Now we have ownership issues too. C++ creates an object and exposes it to QML. QML keeps a pointer or something like that to the object, but is too neutered of a system to actually use said object so it hands it off to JavaScrip. Now you have three entities that know with absolute certainty they "own" said object, controlling its life and death. Guess what happens?

People were using "smart pointers" in C++ on my last project. They exposed these to QML. Eventually C++ killed off the object but QML/JavaScript didn't bother to honor the death. Random crashes where happening in a medical device because someone thought using QML was cool.

The OpenSource version of Qt doesn't even compress or encode QML. When you open up the deployed binary in a decent text editor, there is all the JavaScript. All of your super secret patented algorithms and trade secret logic that you just had to code in JavaScript is right there for God and everybody to take. With a decent text editor and a tiny bit of practice people can directly change that binary by editing the JavaScript inside it. Not a huge change possibly, just enough to add loading a nefarious URL from a Web site that will provide a virus/trojan/malware package for the system to do whatever evil the creators wanted. Ransom your photos, thieve all of your personal/bank information/password file/etc.

Now, years ago, during my heavy drinking and darting days, Tweedle-Dee and Tweedle-Dum (don't remember their nicknames, just their darting nicknames) who worked at Nokia at the time, were working on a replacement/different path. A scripted type language that would generate C++ widget code. They were doing this because Designer had huge bugs. It would regularly corrupt XML (ui) files to the point it could no longer open them. You had to open them with a real editor and fix the raw XML so Designer could use it again. There were other bugs (one of which I see has returned) where UI files that made use of many layouts with spacers would fail to delete objects. They would just be placed in a hidden layout and randomly at run-time they would re-appear. All of this was due to the fact XML was not the tool for the job. It was shiny and new. People wanted to play with the XML classes that were new, but XML was not the tool for the job when it came to UI.

I haven't been playing close attention due to life, but according to comments I've seen on the mailing list, despite running me down, Qt 6 is now trying to do something kinda like what Tweedle-Dee and Tweedle-Dum were doing. I haven't read the doc. I don' see myself or my clients moving to Qt6. Either CopperSpice will come into its own or Rust will be where everybody goes. Possibly both. Given the new licensing, Qt be dead it be dead it be dead dead dead. No serious company is going to pay royalties, especially not the lifetime-support-in-a-manner-they-would-like-to-become-accustommed-to income stream Qt wants.

QML was and always is a bad idea.

Something transpilered, like GNU COBOL transpiles into C, is well and good; especially if it always kills off the output of the transpiler so there never is any dead files laying around. One of the valid concerns with MOC is that it left stuff lying around. I've been on projects where people got burned by that.
Post Reply