Getting into QLC+ development

Post Reply
User avatar
02JanDal
Posts: 13
Joined: Tue Nov 02, 2021 9:13 pm
Real Name: Jan Dalheimer

I figured my feature request thread already got enough off-topic as it is, so I'll pose this question here.

A short introduction about myself, in case anyone can be bothered to read it: I'm a mostly self-taught (though I have in recent years been filling some gaps in my theoretical knowledge through university courses) software developer and been developing with Qt/C++ for over 10 years, though recently I've mostly been doing webdev and systems engineering. Lighting wise I started of in my teens with an introductory course held by the local youth arts center and since then fallen into becoming "the sound and lighting" guy in several non-profits, in one of which QLC+ is these days "permanently installed" (the others are limited by the DMX interface, old Stairville DMX Jokers, and no budget to upgrade). A couple years ago I also started DJing and have slowly gotten into becoming a mobile DJ, where I also put a large emphasis on the lighting (I can't stand all the "we have awesome sound-activated lighting"-DJs, because in the end you just get an epileptic colorful mess...).

I haven't really been doing any open source work the last 2-3 years (mostly because of free time spent on other things) but would not mind getting more involved with some project again. I've been looking through the QLC+ code and infrastructure the last couple of days and seen a couple areas where I think I could be of help (other than working on bugs and features, in no particular order):
  1. Porting to Qt 6 (should be mostly straightforward, since Qt 6.2 all required modules are available, though some minor backwards incompatibilities exist), of course while keeping compatibility with Qt 5
  2. Porting the build system from qmake to CMake (while qmake will probably still be around for a few years its days are probably numbered, especially since Qt itself is moving away from it)
  3. Work on Android support (there seems to have been some initial attempt 5 years ago, but especially with the client/server architecture available to QLC+5 being able to remote control via smartphone/tablet will of course be really awesome)
  4. Setup Github Actions for CI (to begin with to run in parallel with Travis & Appveyor, but might eventually replace them)
  5. Setup a semi-automated release pipeline based on Github Actions (create tag -> automatically builds for all platforms, puts together a changelog and creates a release)
  6. Extract the Tardis from qmlui so that it can be used by both qmlui and the widgets-based UI
  7. Begin "backporting" other new features from the qmlui
  8. Improve types in Q_PROPERTYs (for example replacing raw ints by the actual enumerations) and associated methods
  9. Some QoL updates in the widgets-UI, for example dragging of edges in the EFX-editor (instead of having to use the spinboxes)
Now for the question (mostly for Massimo); are there any points here you feel are more important, or which you oppose (I can imagine that 2. and 4. might be somewhat controversial for example)? Which ones would you accept PRs for (provided they are probably implemented of course)?
janosvitok
Posts: 1274
Joined: Mon Apr 13, 2015 7:05 am
Location: Bratislava, Slovakia
Real Name: Jano Svitok
Contact:

I'm not Massimo and I'm not involved with the project, nevertheless here are my comments:
02JanDal wrote: Sat Nov 06, 2021 8:33 pm Porting to Qt 6 (should be mostly straightforward, since Qt 6.2 all required modules are available, though some minor backwards incompatibilities exist), of course while keeping compatibility with Qt 5
There is a controversy regarding QT6 licence - it's more closed than QT5's one. Nevertheless, the move to QT6 is inevitable, so it would help for sure.
02JanDal wrote: Sat Nov 06, 2021 8:33 pm Porting the build system from qmake to CMake (while qmake will probably still be around for a few years its days are probably numbered, especially since Qt itself is moving away from it)
In my daily job we used cmake and I really prefer it to qmake. For example, with cmake it should be easy to compile with msvc if needed.

For cmake (but also for other libs) it would be great if Massimo somewhere explicitly states desired compatibility (i.e. windows 7+/gcc ??, ubuntu 16.4+, macos ?+, etc.
That determines available library versions (i.e. only versions present in distributions are ok to use).

Another great cmake feature is that build files are separate from sources. Current qmake does not support "shadow builds", since the paths are coded as such.

If you need help with cmake let me know.

Jano
User avatar
02JanDal
Posts: 13
Joined: Tue Nov 02, 2021 9:13 pm
Real Name: Jan Dalheimer

janosvitok wrote: Sat Nov 06, 2021 9:15 pm There is a controversy regarding QT6 licence - it's more closed than QT5's one. Nevertheless, the move to QT6 is inevitable, so it would help for sure.
This is actually a bit of a misconception (albeit a common one); there were actually no changes to the license going into Qt 6. The licensing change introduced was that LTS binaries now require a commercial license (but you can still compile them yourself), see more here.

Now, there is definitely a pull away from open source from the The Qt Company, however, so far all modules used by QLC+ are still available under the LGPLv3, just as in Qt 5 (see here and here. An interesting read is also this (basically; Qt can't be made more closed source).
User avatar
mcallegari
Posts: 4482
Joined: Sun Apr 12, 2015 9:09 am
Location: Italy
Real Name: Massimo Callegari
Contact:

Hello Jan, thanks for your offer even though I have already understood from the feature request topic that we have quite different views about QLC+.
QLC+ 4 took 10+ years to become the stable and reliable product it is and it is used by thousands of people with usages not even I can imagine.
Every change I make on it is very cautious and I don't want/plan to add big changes to it.
QLC+ 5 on the other hand is the current "playground" where I can experiment new features and improve workflows. Everything is done to improve the productivity. It's not just a UI with different icons and colors.

Having said that, here's your answers:
1. Qt6 is inevitable and I'm waiting for 6.2+ to stabilize. Usually the first release is crap. So I'm just waiting...and I'm scared because they break things like hell. They surely broke QtMultimedia and possibly Qt3D.
2. see this PR: https://github.com/mcallegari/qlcplus/pull/1214
I asked the guy to send separate PRs and he disappeared. I'm not saying no right now. I'm just saying "we can wait some more"
3. It's already there. I haven't checked it in the last year or so, but the last time I checked it was working. QLC+ 5 only of course. v4 doesn't even make sense on Android.
4. might be a good idea, especially if macOS gets included in CD
5. let's see if GH actions achieve all that this project needs
6. and 7. are a no on my end. This is where our views differ.
8. can you please give an example? Some of them might be very old, where Qt data types were not exactly working on QML
9. could work for me

If I can express my ultimate wish...I need a hand with the 3D preview. Problem there is that Qt3D has almost been abandoned because of stupid change of policy in the Qt company. Unfortunately QtQuick3D is very basic and doesn't expose everything QLC+ needs to render multiple lights in real time.
I'm really tempted to explore different ways (e.g. Unreal) but I don't have enough time to follow every topic.
User avatar
02JanDal
Posts: 13
Joined: Tue Nov 02, 2021 9:13 pm
Real Name: Jan Dalheimer

mcallegari wrote: Sun Nov 07, 2021 10:52 am Hello Jan, thanks for your offer even though I have already understood from the feature request topic that we have quite different views about QLC+.
QLC+ 4 took 10+ years to become the stable and reliable product it is and it is used by thousands of people with usages not even I can imagine.
Every change I make on it is very cautious and I don't want/plan to add big changes to it.
QLC+ 5 on the other hand is the current "playground" where I can experiment new features and improve workflows. Everything is done to improve the productivity. It's not just a UI with different icons and colors.
I'm going to refrain from continuing that argument here. As I see it right now it's still very likely that I will have to create my own fork once the widget-based UI is removed from the main codebase, however, until that point, it makes more sense for me to contribute to the main source so that it can be of benefit to others rather than just myself.

And who knows, in the end I might be okay with the new UI, I just see that as extremely unlikely at the present moment (and again, that has nothing really to do with your work, but just the difference in technology).
Having said that, here's your answers:
1. Qt6 is inevitable and I'm waiting for 6.2+ to stabilize. Usually the first release is crap. So I'm just waiting...and I'm scared because they break things like hell. They surely broke QtMultimedia and possibly Qt3D.
2. see this PR: https://github.com/mcallegari/qlcplus/pull/1214
I asked the guy to send separate PRs and he disappeared. I'm not saying no right now. I'm just saying "we can wait some more"
3. It's already there. I haven't checked it in the last year or so, but the last time I checked it was working. QLC+ 5 only of course. v4 doesn't even make sense on Android.
4. might be a good idea, especially if macOS gets included in CD
5. let's see if GH actions achieve all that this project needs
6. and 7. are a no on my end. This is where our views differ.
8. can you please give an example? Some of them might be very old, where Qt data types were not exactly working on QML
9. could work for me
1. Yeah, I wouldn't do a release with it a x.x.0 version of Qt either, though I doubt anything will change that would affect the source compatibility though.
2. Not quite sure how to interpret this; that PR was definitely a textbook example of a bad PR (a new feature oh and a new build system...), but would you today accept a new PR just doing the build system change?
3. Just saw that the files haven't been touched for 5 years though I guess they don't really need to
4. Will work on that
5. Understandable
6. and 7. Not to surprised about the response to 7., but wouldn't 6. make sense to do even for your plans? Decoupling it from the UI? Even ruling out widgets I could imagine a headless variant that basically just runs the tardis in server mode, the engine, and any inputs/outputs.
8. https://github.com/mcallegari/qlcplus/b ... .h#L35-L36, stepsList should be either ListModel* or one of its superclasses, and tempoType should be Function::TempoType (which already has Q_ENUM, as seems to be the case with most enums).
9. Yay!
If I can express my ultimate wish...I need a hand with the 3D preview. Problem there is that Qt3D has almost been abandoned because of stupid change of policy in the Qt company. Unfortunately QtQuick3D is very basic and doesn't expose everything QLC+ needs to render multiple lights in real time.
I'm really tempted to explore different ways (e.g. Unreal) but I don't have enough time to follow every topic.
Sadly 3D graphics aren't really my strong suit, though I might at least take a look (the 3D preview is definitely something I'd want to pull into the widget UI at some point, so something I'm also interested in). Is there a todo list or similar anywhere? (there's also a more general question in this; there're a few bugs in Github Issues, the somewhat coarse spreadsheet for QLC+5, and some parts of this forum, all of which makes it a bit hard for a new developer to this project to know what needs to be done)

There definitely has been quite some turbulence in the Qt & 3D space and by now there exist way too many ways (Qt 3D, Qt Quick 3D, Qt 3D Studio, Qt Canvas 3D, etc.) of doing similar things. However, saying that Qt 3D is abandoned is not quite true, TQC are definitely looking the other way, but it's still being actively used and maintained by at least KDAB (who wrote the current Qt 3D module), see https://code.qt.io/cgit/qt/qt3d.git/ and https://www.qt.io/blog/the-future-of-qt-3d (note that the author of that post is not from TQC).

Based on all this I think I would prioritize as such:
1. CMake
2. Github Actions CI
3. Qt 6
4. Verify Android support (hopefully no change needed)
5. Extract Tardis (if ok)
6. Take a look at 3D preview
7. QoL updates of widget UI

Sound good?
hansjuergen
Posts: 20
Joined: Fri May 08, 2020 6:45 pm
Real Name:

Just a thought from my side:
While working on the RGB Scripts, it came to me to think that using a headless webview with a HTML5 canvas (2D) could save a lot computing power rather than the pixelwise calculations within JS for the scripts.
Seeing your comments on the 3D implementation - could a HTML5 canvas also serve as a preview or calculation base which would be cross-platform compatible?
Im am unfortunately not in the position to judge on possible pros and cons on that solution (performance, complexity), but it sounds like it should be cross-platform compatible and "standard" to be extended.
User avatar
02JanDal
Posts: 13
Joined: Tue Nov 02, 2021 9:13 pm
Real Name: Jan Dalheimer

hansjuergen wrote: Sun Nov 07, 2021 8:02 pm Just a thought from my side:
While working on the RGB Scripts, it came to me to think that using a headless webview with a HTML5 canvas (2D) could save a lot computing power rather than the pixelwise calculations within JS for the scripts.
Seeing your comments on the 3D implementation - could a HTML5 canvas also serve as a preview or calculation base which would be cross-platform compatible?
Im am unfortunately not in the position to judge on possible pros and cons on that solution (performance, complexity), but it sounds like it should be cross-platform compatible and "standard" to be extended.
So rendering the RGB script to a HTML5 canvas and then using the resulting canvas for pixel values? I'm not too familiar with the RGB scripts (don't really have the fixtures for that) and what they provide, however, I think the overhead (both from using a heavyweight webview and then copying back from the GPU) would overshadow any potential gains. Would be necessary to profile to get a certain answer though.

Another alternative might be to expose a QPainter-backed (which is quite well optimized) helper interface, though getting that backwards compatible with existing scripts would be non-trivial.
User avatar
mcallegari
Posts: 4482
Joined: Sun Apr 12, 2015 9:09 am
Location: Italy
Real Name: Massimo Callegari
Contact:

I'm going to refrain from continuing that argument here. As I see it right now it's still very likely that I will have to create my own fork once the widget-based UI is removed from the main codebase, however, until that point, it makes more sense for me to contribute to the main source so that it can be of benefit to others rather than just myself.
Nobody said the widget ui will be removed from the codebase. I said it's going to phase out, which means at some point I won't release any new version of QLC+ 4.
So at some point you will spend your time and energies on an outdated software. I'd rather prefer you helping out with v5.

BTW https://codereview.qt-project.org/q/sta ... ct:qt/qt3d Looks like an abandoned module to me
User avatar
02JanDal
Posts: 13
Joined: Tue Nov 02, 2021 9:13 pm
Real Name: Jan Dalheimer

mcallegari wrote: Mon Nov 08, 2021 9:45 am BTW https://codereview.qt-project.org/q/sta ... ct:qt/qt3d Looks like an abandoned module to me
Still several commits per week, not really sure what you're expecting? Are there many major outstanding bugs?

(https://codereview.qt-project.org/q/sta ... k+Bot%2522 for a list without the bot-generated stuff)
Post Reply