Get rid of QT dependency

[Gamadril]

I've noticed the development of a new version is in progress here. But I wonder why hyperion still depends on QT? hyperion is intended to be a lightweight solution - I got it even running on my OpenWRT router, but had to make some modifications to "heal" it from QT.

I cannot see any reasonable cause to use QT in hyperion...

P.S.: I had to replace Python with LUA as well. Can't see any reason to embed a full Python stack just for some simple scripts either...

[brindosch]

Hello @Gamadril

I've noticed the development of a new version is in progress here.

Yeah! More or less active (currently less)

But I wonder why hyperion still depends on QT?

I think no one wanted to change this, as Hyperion was already a qt project. I need to note that development interest for Hyperion is all-time low (If you count serious the contributors who want's to move something forward you get - @redPanther (prof programmer) and myself (useable C++ experience since some months) - and if time available @Paulchen-Panther) So the removal of qt was no discussion back in mid 2016 At the meantime effects got a image based api which uses the qt image capabilities

Can't see any reason to embed a full Python stack

Also historical, tvdzwan and poljvd started with it and it was kept.

Conclusion Everything is possible, but it's up the individual contributor to decide what he wants to integrate or revamp. Without @redPanther this repository won't exist and since i hooked into C++ i am focused on the last core reworks to bring this out of the door. Contributors are always welcome **

** but ususally it ends in good purposes and zero code :)

Albeit, i am here for questions.

[Gamadril]

I started a new port of hyperion. Actually it's a completely new project written from scratch in Rust. Rust is known to be fast, memory safe and thread safe. There are a lot of already exiting libraries (crates) that can be used for common tasks. Cross compiling is also possible. However I'm new to Rust and have absolutely no experience in it, so any help would be great. I also have some ideas about the new architecture. From my point of view the program itself should only be some kind of "small core" handling only data exchange and configuration handling. Everything else like video grabber or effect engine should be implemented as input plugins. All LED types are implemented as output plugins. "transform" plugins should make some transformation on data like black border detection. I also think output should not be restricted only to a stripe around a screen. I think it should also support LED matrices to realize LED screens for example. For Scripting LUA is my first choice - it's easy to learn and cheap to integrate. Remote Control communication and eventually configuration will be done with WebSockets only. So far I have a small proof of concept running with one input plugin reading data from a file and one output plugin sending data to a serial port. Any input is welcome to be considered for the architecture during the planing stage.

[penfold42]

Hyperion has always supported arbitrary led layouts - each physical led has a corresponding rectangle location on the screen.

More generally, how does rust perform on low cpu and low memory devices like a Pi zero ?

[Gamadril]

More generally, how does rust perform on low cpu and low memory devices like a Pi zero ?

I don't have any benchmarks, but I expect it to be at least as fast as C++. I would not call a RPi a "low memory device". Memory consumption is not related to Rust itself since it's a compiled language.

[penfold42]

Compared to all the kids writing bloatware code on their desktop with 16GB it is !

[brindosch]

@penfold42 Are you talking about Electron desktop applications? Where a tiny clock widget reaches 100MB in size because of the browser engine behind? Not mentioned the RAM usage :) @penfold42 speed excerpt http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=rust&lang2=gpp (well, it shows at least the direction)

@Gamadril I had a quick read through the concept of Rust, the syntax and semantic. I like the idea behind, and unfragmented syntax. Well, you need strong maintained dependencies to prevent headaches. (As Qt is a strong maintained depedency the risk of breakage is minimal - besides of the point that Qt is a UI framework which is mostly unrelated to Hyperion). I've seen crates are available for the basic stuff like json handling, schema validation, sqlite interface, webserver. So far so good.

As you said, a complete rewrite is required. I've also never used Rust so i am no huge help at the moment. I also invested to much time into this repository that i can't stop now, it's too late for this round (v2). The problem is also that Hyperion 1 is primarily unmainted since 1 1/2 years because of the horrible code. The break day will come sooner or later, if not Hyperion 1, probably HyperCon which i already just hack fixed to keep it running.

I prepare currently a last PR which implements network client origin checks, user/token login, settings apply during runtime, specific event based data updates for clients, a own python interface for plugins that can be installed from a repository and - the master piece - multiple instances with different led devices within the same daemon.

I can provide you a repository here where we can work together towards the Rust rewrite. Probably more people are interested and can contribute too.

Happy new Year! :)

[funnym0nk3y]

@Gamadril Is there a possibility to have a look into?

[Gamadril]

@funnym0nk3y: sure, I just have to find the project and check if it's still working. I didn't touch it for a long time...

[Gamadril]

@funnym0nk3y: did some code cleanup, updated to rust 2018 and commited here: https://github.com/Gamadril/lightoros At the moment it's not doing much - just a proof of concept and a way to learn rust. One input plugin reading a file and one output plugin sending data to a serial port. Core module acts as a dispatcher getting data from input plugins and routing it to output plugins.

[tpmodding]

@Paulchen-Panther @brindosch

wie sehr ist das möglich .ng von qt loszuwerden? ich habe leider absolut keine ahnung...ich denke mal man müsste wirklich alles umschreiben oder?

[Paulchen-Panther]

@tpmodding Ohne vergleichbare Dependencies müsstest du alles umschreiben.

[brindosch]

Qt ist wohl Segen und Fluch gleichzeitig. Zum einen abstrahiert es einiges weg, entweder man schreibt dann vieles von Hand selber neu oder greift mehr auf andere libs zurück. In jedem Fall ist es cross-platform ready (Windows), da fällt mir spontan threading, network und filesystem ein, die man spezifisch programmieren müsste. Natürlich gibts dafür genug andere libs, da wird keiner das Rad neu erfinden.

Was wir noch im speziellen verwenden ist in der EffectEngine die image basierten Effekte. Qt kommt eigentlich mehr aus der cross-platform UI Ecke. Das ist die eigentliche Stärke, die wir überhaupt nicht benötigen/nutzen. Jedenfalls bauen wir so Layout unabhängige Effekte, da gibts aber bestimmt auch etwas für.

Wenn ich heute Hyperion neu schreiben müsste, würde ich wohl in Richtung Rust schielen. Hab das "Buch" mal durchgearbeitet. Finde es ganz angenehm zu schreiben, ein paar Konzepte erfordern aber Umstellung der Denkweise. Vieles wird aber angenehmer gehandhabt, bessere Fehlermeldungen und Tipps (Einstatz von gdb kaum nötig), Speicherfehler praktisch nicht vorhanden, Verwaltung für Abhängigkeiten über ein repo (Wie NPM für JS), viele libs auch cross-platform kompatibel und so weiter.

Man könnte allerdings Rust stückweise einführen, weil man eine C API bauen kann und so den code fortschreitend migrieren

[tpmodding]

@Gamadril can i close this issue?

[Gamadril]

yes, I moved to lightoros