Page 1 of 1

Qt QML or Quick or Quick Controls 2?

Posted: Mon Aug 28 2017 8:35 am
by grant
Any support for Qt Quick or QML or Quick Controls 2? Does it still work or did you remove it?

Re: Qt QML or Quick or Quick Controls 2?

Posted: Sat Sep 02 2017 1:34 am
by ansel
Hi Grant,

We did not remove any of the existing functionality, but this area has not been heavily tested. As we develop Android support this area of CopperSpice will be redesigned to support modern graphics hardware.

Thanks,
Ansel

Re: Qt QML or Quick or Quick Controls 2?

Posted: Mon Jun 22 2020 9:42 pm
by seasoned_geek
I was hoping they completely removed QML and JavaScript as that was one of the worst decisions Qt ever made.

Re: Qt QML or Quick or Quick Controls 2?

Posted: Mon Jun 22 2020 10:10 pm
by ansel
seasoned_geek wrote: Mon Jun 22 2020 9:42 pm I was hoping they completely removed QML and JavaScript as that was one of the worst decisions Qt ever made.
I'd like to clarify and expand on the answer we gave. Qt Quick and QML have not been brought into CopperSpice and we have no intention of porting them to CopperSpice verbatim. The truth is, QML is not a declarative language and we believe there is a better solution. Several developers on the CopperSpice team are researching what it would take to provide a CsDeclarative user interface library.

Re: Qt QML or Quick or Quick Controls 2?

Posted: Tue Jun 23 2020 4:46 pm
by seasoned_geek
I haven't put pencil to paper on any details.

When Nokia first proposed QML it was supposed to be a 4GL/script that was compiled by a MOC like process generating all of the C++ classes/headers. The concept was proposed at a time when the Designer was trashing XML for .ui files on a regular basis. Everybody had to use a second editor to fix them.

Having to hand write XML for a .ui file duth well and truly sucketh. I've had to do that with editors that could neither syntax highlight nor help.

The concept of some form of pre-compile was fine. Adding not one, but two virtual machines to battery powered embedded systems was never really thought through. Besides forcing system developers to "throw hardware at it" you now have binary code and two different VMs that absolutely know they own and control the lifespan of an object that was created in C++ then passed to QML which couldn't do the job so it passed it to JavaScript. I watched one system crash and burn because they used C++ SmartPointers. It appears that QML/JavaScript kept either a pointer to the SmartPointer or a reference of it. Great fun happened when the SmartPointer nulled itself and JavaScript/QML was still trying to use it.

I am very very glad that QML was not brought over.

Thank You