Page 1 of 1
Posted: Wed Aug 16 2017 6:07 pm
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 ?
Posted: Thu Aug 17 2017 6:35 pm
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.
Does copperspice work together with QML based projects ?
Posted: Mon Oct 21 2019 9:41 pm
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).
Posted: Sun Sep 13 2020 11:03 am
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.
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?
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.