Qt QML or Quick or Quick Controls 2?

Post Reply
grant
Posts: 9
Joined: Mon Aug 28 2017 6:34 am

Qt QML or Quick or Quick Controls 2?

Post by grant »

Any support for Qt Quick or QML or Quick Controls 2? Does it still work or did you remove it?
ansel
Posts: 152
Joined: Fri Apr 10 2015 8:23 am

Re: Qt QML or Quick or Quick Controls 2?

Post 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
Ansel Sermersheim
CopperSpice Cofounder
seasoned_geek
Posts: 254
Joined: Thu Jun 11 2020 12:18 pm

Re: Qt QML or Quick or Quick Controls 2?

Post by seasoned_geek »

I was hoping they completely removed QML and JavaScript as that was one of the worst decisions Qt ever made.
ansel
Posts: 152
Joined: Fri Apr 10 2015 8:23 am

Re: Qt QML or Quick or Quick Controls 2?

Post 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.
Ansel Sermersheim
CopperSpice Cofounder
seasoned_geek
Posts: 254
Joined: Thu Jun 11 2020 12:18 pm

Re: Qt QML or Quick or Quick Controls 2?

Post 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
Post Reply