Behind the scenes

A place where updates of QLC+ activities and technical articles are posted as if it was a blog
Post Reply
User avatar
mcallegari
Posts: 1895
Joined: Sun Apr 12, 2015 9:09 am
Location: Italy
Real Name: Massimo Callegari
Contact:

Behind the scenes

Post by mcallegari » Sun Aug 20, 2017 1:56 pm

Hi, today I'd like to write a (very lenghty!) article about what happens behind the scenes in the QLC+ project.

QLC+ is not just about processing issue reports and fix them. Much more happens in the background which is not visible to the end users.

My personal spare time is split between many activities and I try to dedicate efforts by constantly switching from one to another.

Qt Framework

As probably most of you already knows, QLC+ is entirely based on the Qt framework.
Qt has a very long history and it's a constantly evolving project. It started as a toolkit focusing on UI widgets, and ended up being a monster. Today Qt covers almost everything you need from a framework. From widgets to 3D, from network protocols to IoT, from multimedia to bluetooth.
Most importantly, Qt is cross platform ! As of today it runs on Linux, Windows, MacOS, Android, iOS and Windows mobile.

Everything great, but relying on a framework also means that if the framework is buggy, your software is buggy too.

So, one of my activities is constantly monitoring what is happening on Qt. It moves so rapidly that it's quite difficult to follow every aspect of it. Also, they have the habit of dropping older OS versions on every new Qt version (for example Windows XP/Vista, MacOS 10.7, 10.8, 10.9 are long gone now) and this affects QLC+ quite badly...since there are users keeping they're old "super stable" OS tight.

Sometimes there are also regressions or things that are not working as expected. In fact I personally have 26 open reports in the Qt bug tracking system. Mostly in the multimedia part, which unfortunately doesn't have the same quality standards of other Qt modules.

The bright side though is that the rapid changes happening in Qt are usually towards goodness. The QLC+ 5 idea started exactly from this fact. 5 years ago it wasn't absolutely possible to do what you can do with the today's Qt.
However, new things mean also you need to study them and experiment if what you have in mind is actually possible.
QLC+ 5 will leverage most of the latest Qt technologies, to be a modern application, aligned with the today's devices.
Using the latest stuff unfortunately means also stumbling into bugs, incomplete features and scarse documentation. You can understand how difficult it is to move every step on such ground. In fact, I have already rewritten some parts of the QLC+ 5 UI when I felt like a new Qt module was mature enough to bring in some advantages.

I also follow the Qt development mailing list, where from time to time, I jump in with sharp emails ending most of the times with an astonishing "we don't care".
Another place I check almost daily is the changes proposed to be mainlined in Qt. A place called Gerrit.

Deployment

Deploying QLC+ 4 on 3 different OSes is no piece of cake. And it will get "worse" with QLC+ 5 which will run on Android and iOS too.
Deploying QLC+ is not just a matter of making a zip file of the compiled sources.
Every OS has its peculiarities. On Windows you want a self installing exe file, on MacOS a DMG image, and on Linux...well, a package suitable for your favourite distribution.

So, to offer all those flavours, I had to learn a lot of things.
On Windows, I had to find a proper way to build and make a package, and thanks to the efforts, I've been able to set up an automated mechanism called AppVeyor that builds every single change done on the QLC+ sources and gives a feedback if the change is good for Windows. To make things even better, AppVeyor can deploy the built package into another service called BinTray. That's where TEST builds are stored.

On MacOS, I had to learn how bundles work (which is ridicolous let me say). Qt is not really good at it, but with the proper scripting magic, you can get what an Apple user expects....mostly. In fact, QLC+ on macOS needs that annoying launcher, and I really want to get rid of it. This is because the MacOS bundle includes 2 applications (QLC+ and fixture editor), not just one like every MacOS bundle on earth. One of my goals is to separate QLC+ from the Fixture Editor on MacOS, and here's where the word "ridicolous" comes from.
QLC+ and the Fixture Editor shares a lot of libraries (several MB of Qt in the first place), but no, Apple doesn't allow you to seriously share libraries on their OS, like what Linux does. You will need to download 2 times the same things and waste space on your hard disk for no reason. On a 1TB hard disk, who cares, but consider that the same happens on the iPhone and the iPad. That's why apps in the Apple world are so large...for nothing. Again: ridicolous.

Linux is supposed to be my favourite OS, but deploying QLC+ there is a nightmare. It takes less time for you to build QLC+ from sources on your own !
The Linux "issue" is that when you create a DEB file, you don't actually have any idea where it will end up. Might be Ubuntu 12.04, Ubuntu 16.04, Debian 7.0, Debian 8.0, Mint 17, and so on.
Each distribution has a different set of installed packages and there is no guarantee to be compatible with all of them. Same story for RedHat/Fedora RPM packages.
So I had to decide to keep the "profile low" by offering a 32bit version targeting Ubuntu 12.04, and a 64bit version targeting Ubuntu 14.04. But soon I realized this was not enough.
Luckily, another interesting tool came up, courtesy of the OpenSUSE folks: the OpenSUSE Build Service.
It allows to take a sources snapshot (either released or in development) and build it for the Linux distributions you configured.
In this way I've been able to offer consistent builds also for up-to-date Linux distros, like Arch, Fedora, openSUSE and Ubuntu.
It took an awful amount of time to find all the flags and bits to build QLC+ on so many different distros, and still there are issues with some combinations between the Qt version and the packages base.

Linux and MacOS deployment also involved the OLA plugin. Sometimes I have to dedicate time to understand what they're changing, report issues and so on.

Raspberry Pi

I haven't mention this in the deployment paragraph because deploying on the RPi is a story on its own, and it's tough !
Considering all the issues in deploying QLC+ on Linux, I decided I needed control (and moreover consistency) between the Qt version and the QLC+ version.
That's why I decided to come up with a dedicated image, which not also automatically starts QLC+ at boot, but also is not entirely related to what the Raspbian (Debian derivate) image provides.
Providing a DEB package for any Raspbian version would have been a nightmare, with most likely a ton of complains.
So, every time a new QLC+ version is ready to be released, I need to check at what point Qt and Raspbian are, and decide what to do.
Being a geek, I normally opt for the "bleeding edge" solution :)
So I have to build the latest Qt version for Raspbian (takes hours !) and then package QLC+ accordingly (another hour or so)

So before releasing a new RPi image, I think about it twice, cause the effort is quite high.

Code that checks code

Thanks to the original author of the QLC project (Heikki Junnila), QLC+ can count on a mountain of code called "test units".
Over the QLC+ years, more test units have been written, but the effort of writing test units is almost the effort of writing QLC+ itself...if not even more !
These test units are invoked every time QLC+ is trying to be packaged on Linux. There are hundreds of test units, and their role is to check if the latest changes have introduced regressions in the code.
They check as much as possible the C++ classes methods, even with absurd values, and check if the result is the one expected or not.
If just one of those hundreds units fails, QLC+ can't be packaged, meaning it is somehow broken.
Now, doing this manually would be a total waste of time, and that's why there's another online service called Travis that does it for us.
Every time we change the QLC+ code, Travis test the change by building QLC+ and running test units. This gives us immediate feedback if we broke something or if the change is good.
Travis builds QLC+ on Qt4, Qt5 and then does another interesting thing called "coverage".
Coverage is a value expressed in percentage, that reports how much of your code is self tested with test units.
Guess what...there's an online serivice also for that ! This time it's called Coveralls
As you can see, the current code coverage is 31%. You might say: is that so ?
Considering that QLC+ consists in almost 200,000 lines of code, I'd say it's not that bad as it seems.
Moreover, most of the coverage is on the QLC+ engine, which is the vital part of the software.
Let's say a good project with a high quality code standard is between 50% and 60% of coverage.

Setting up Travis and various online services requires to study how they work and quite often trial and errors until they work.

Code quality

Another tool recently introduced to give some more information about the QLC+ code quality is Codacy.
It gathers together various code conformancy tools (otherwise called Lint) and run them all at each change in the QLC+ code.
It checks C/C++ code for malformed contructions, JavaScript conformancy, potential security risks, suggests code simplifications, and so on.
In the end, it says if your code is written according to standards or if you are inventing things.
Being QLC+ based on Qt, Codacy is not always good at resolving C++ macros, but still it is giving us a rough indication of how good the QLC+ code base is.

Keeping the code quality as higher as possible, is another of those activities requiring extra time.

Plus, there's me on GitHub, reviewing code of developers attempting to propose changes to QLC+.
Who submitted a Pull Request on GitHub knows how picky I am, and I hope this post clarifies why I have to be like that.

Documentation, forum and website

These are maintenance activities requiring time as well.

Conclusions

Once again: QLC+ is a free and cross platform open source software, developed in the spare time.
There is no company behind it, and we are not paid to do it, nor the doctor told us to do it.

Now that I have revealed how I spend most of my spare time, I hope there will be no longer people asking for a QLC+ 5 release date, or doing the math for me (e.g. 6 months have passed. You should release)

QLC+ is released when it makes sense to release it. Either version 4 or 5. End of story.

bluescreen25
Posts: 3
Joined: Fri Jul 21, 2017 4:52 pm
Real Name: Ralf Janssen

Re: Behind the scenes

Post by bluescreen25 » Sun Aug 20, 2017 5:44 pm

I feel with you. In the past i coded 5 years in Delphi a freeware project (Car-PC-Software).
It is heavy to understand for enduser how many time is to spend for all coding and workaround .

The quality of your software is professional .
Very thanks for that.

I hope that very much user donate some money for the project. I will also hope that you have fun to do for a long time.

@all: Help the project to be good instead of forcing "versions".

(sorry for my bad english,i come from germany)

best regards, ralf

edogawa
Posts: 24
Joined: Thu May 07, 2015 10:34 am
Real Name: Edgar Aichinger

Re: Behind the scenes

Post by edogawa » Wed Nov 08, 2017 10:01 pm

Hey Massimo,

regarding deployment and opensuse build service:

OBS now supports (in an early state) creating AppImage bundles, and I've managed to build one, though only for x86_64 so far.
See https://build.opensuse.org/package/show ... s-AppImage
Download URL: https://download.opensuse.org/repositor ... /AppImage/

If you're interested to add this to your OBS project, I'll be happy to help setting that up. This is just a first test result, from my novice attempts using the "binpatch" method and repackaging binary rpms, while it's also possible to build from source. And it won't be easy to supply all the build variants that OBS offers now (you provide Qt4/Qt5/release/git packages with different names where the appimage expects a package name that matches the binary name that will be run). x86 seems to be difficult as unresolvables show up but i haven't looked deeper at that yet, nor at the arm arch targets...

Cheers, Edgar

Post Reply