Lightpack
Lightpack copied to clipboard
psieg
Scriptable moodlamps
As a test for #335 I swapped cpp lamps for js with QJSEngine and it works pretty well.
Here's the readme.
Also qml module needs qtdeclarative5-dev package to build on ubuntu.
~What I'm not sure about is how to bundle and deploy the scripts to the user folder on all platforms, so if you have some ideas...~ Actually baking script into resources (and copying on launch) works well. So it's now ok to merge for me...just kidding, this needs Qt 5.12 ;-;
hmmm.... Not a huge fan. Looks like bringing a gun to a knife fight to me (adding a js engine for something as small as custom moodlights, which one person asked for and didn't reply to).
It's limited API wize and does not have everything you'd have in a browser or nodejs, if that's your concern. It's pretty much the bare language with basic stuff like Math, Regex... (you can expose your own things to it from cpp side though)
When I added the lamps originally I knew it wasn't a permanent thing, to me it always made more sense to have them configurable from outside, I just did not know how yet.
I wasn't aware of JSEngine, so I was thinking about the ini route (which is already used for configs), but that would've involved inventing some kind of animation protocol, maybe writing frames one by one plus basic config like name and speed, than parsing and interpolating frames, managing persistant variables... that seemed like too much work for too much limitations.
Then I remembered Lua is used for that kind of stuff in games and what not, but now I have to look for a library that works everywhere, learn it, re-learn Lua itself, so I did not jump on that right away.
Then I found QJSEngine and it looked like the best of both worlds:
- it's part of Qt so we don't have to deal with 3rd party integration (just like ini)
- it has all of the scripting capability of a 3rd party library for the job (while probably being just as heavy/light)
- JS is simple and (alas) extremely popular nowadays, so a lot of people can use this with minimal effort
So while it wasn't specifically in response to that ticket, it (and couple of other people I saw on reddit) motivated me for sure. And I don't take the dud(ett)e's no answer as a lack of interest, just put yourself in that person's shoes: you have this program for your LEDs and you wish you could light them up with the colors of your favorite sports team or whatever and to do so all you need is learn basics of git, install the whole toolchain, learn how those work, learn some cpp, re-read what that guy on github told you about the files of interest, ask more questions because it was too vague, do your lamp, learn how to do a pull request, fuck up your branches, clean up, do a pull request, wait couple of weeks for a feedback, things would need to be changed because it's the first time you touched cpp, wait more for final approval, wait more til your lamp makes to a release, ???, profit! I would abandon my lamp dreams too 😁
The next logical steps with this to me would be:
- soundviz
- maybe custom last second filters applied right before sending colors to the device
- or even better, new plugin system
The complexity of the latter will go beyond small lamp math (should be easier to convince people to use a documented set of JS functions than to make them find a language that can talk to a socket and then find a way to run it, would solve all the tickets about timed profile switching etc), and even lamps and soundviz depend on user's imagination so... I'm more scared that it won't be complete enough (like plugin that polls some JSON weather API and sets colors accordingly... I don't think HTTP is available out of the box)
This is why I think it's an ok investment.
Hm Okay, fine with me.
What's the point of rgb cycle (vs the existing change color with rate + static)?
What's the point of rgb cycle (vs the existing change color with rate + static)?
I'd say it's the other way around: programability of the lamps makes the built-in cycling a bit redundant, but it's a (free) way to seed a semi-random base color if one is needed, so I left it in
as for the difference, the built-in cycles between predefined Qt colors, and rgb stuff goes around the hue circle
which is what you see in keyboards/fans etc these days
and it's another example script
and it's fun to mess with
but maybe the built-in should be changed into rgb as it has "better" colors (soundviz would be affected too)
I'm not sure if the built-in color list was curated to be "moodlight-ier" than the hue cycling, so my first reaction would be "keep the old one".
I just found the user experience confusing because when the cycle is active, the "change color with rate" field does not affect the cycle speed. Not a big thing.