CopperSpice Experiments Pt. 1
CopperSpice is a fork of Qt 4.8 sans the icky nasty bug infested (and infesting) QML. Lots of bad things have been cleaned up, like replacing UTF-8 under the hood with QChar32 so every character requires same amount of space. Yes, it wastes a bit of RAM, but there is a lot less overhead.
Qt Company has offended the bulk of the Qt developer community with its new licensing stance. Not to mention its attitude about things to be released back to the OpenSource community which provides much of the Qt Application Framework in the first place. From the emails I’ve seen it appears many in the KDE community want to kick Qt Company to the curb without so much as a “horse you rode in on.”
QML – The Hand Polished Turd
Years ago when the current owners of the commercial version of Qt released QML into the universe I declared it a hand polished turd that should be cut from the product. When this idea was originally pitched to me, we were going to get a scripting language that would run through a MOC-like process and generate all of the widget code. That would have been good and righteous.
We already had XML files with .ui extensions created via the Designer. During that time the Designer had some severe issues. It would hose up your XML file so you had to use some other editor to edit the XML and make the Designer happy. It only seemed to do this when it was something you had been really working on. Never seemed to happen on simple screens you didn’t care about. Most of us had gotten pretty good at editing the XML by the time QML came out.
The problem is you now have burdened your embedded system with running two virtual machines along with native compiled binary. All three of them are absolutely certain they are in charge of the lifespan of objects. Can you say “random crash?” Knew you could.
One of the big appeals of Qt was the fact it provided garbage collection. One of the big detriments of Qt is the fact it provides garbage collection. One of the big reasons Rust is getting noticed is that it doesn’t have any garbage collection. When you have two different VMs, at least one of which providing garbage collection, combined with a compiled binary language API that provides garbage collection and you pass objects between the three, you have a &^%(*&^ing catastrophe on your hands.
I have seen code run just fine on under powered machines only to die a horrible death as soon as it is loaded on a better machine. All of those ->deleteLater() calls never happened on the box wheezing hard just to run the application. “Idle” never came around. On the properly sized machine your program didn’t even keep one core busy. ->deleteLater() happened almost instantaneously. That’s when you found out the hard way about some shallow copy or reference one the VMs was holding onto.
Those of you who are really lucky will have this happen with your very first demo to upper management using the production hardware.
Birth of CopperSpice
What really got me interested in CopperSpice was the fact they used it to create the Diamond editor. Is the Diamond editor some fabulous everything to everyone editor like so many try to be? No. It is modeled after Crimson and Emerald. Both of these editors were Windows only. Back when I used to allow the virus known as Microsoft Windows to infect computers I owned I used to really like these editors. They weren’t full blown IDEs, just handy and nice looking.