Request : Retire QT3 and link your work to QT5

[mistergibson]

QT3 is impossible to get working - the source code has bugs that don't allow it to build and it is no longer supported. I'm on LInux Mint and have tried the 3rd party repos - no go half the packages won't install.

[splrk]

Iwoul also love to see this. Willing to help make the codes switch as well

[elmuz]

It has been a well discussed topic. I think Fred for the moment isn't going to consider it...

[edglazer]

I know a number of community folk are interested in keeping Rivendell moving forward with a more modern codebase, and I also know a qt4 version was underway for a time. Perhaps it would be possible to get the old qt4 branch included in this repo as a branch & use that as a base to start a qt5 branch?

Alternatively, could we start a qt5 branch that aims at backwards compatibility, but getting the smallest possible functionality working first? Such as a qt5 branch of caed that would function as a standalone module, but would also be able to be called by the mature branch within the same system?

[elmuz]

Instead of moving to more recent Qt frameworks, I would also consider the option of moving to a 100% web-based interface, even though - I think - it could mean in throwing away 90% of the code.

[waynemerricks]

I was thinking along the same lines (web interfaces). Not for the bits of Rivendell that require low latency audio and all the other direct hardware access (airplay, ripcd, caed etc) but a lot of Riv is simple MySQL manipulation which lends itself to web quite nicely.

I have some very basic javascript/php/html proof of concept work on github already https://github.com/waynemerricks/rivendell-html. I don't have any pictures or video yet as I was trying to finish up clocks and events but hopefully will have something to show by the weekend. Its all plain php/javascript with drag and drop support as you'd expect. I'm not a CSS master so don't expect anything pretty.

I've only worked on rdlogmanager -> edit grids / edit clocks so far.

[elmuz]

Regarding low latency. I'd leave the three daemons run in background as they are now and let them be piloted by TCP (UDP ?) commands coming from php and not from QTapps. I bet the latency would be the more or less the same. I imagine it like this: you separate the application server (where caed/ripcd/rdcatchd run) from the GUI-client. The app server can be local (you need a linux box) or remote (you just need a browser, regardless the OS). Afaik you can virtually do it at the moment with one Riv host hadnling an other's CAEngine.
I don't know Riv design in details so it can be 50% doable, 50% fantasy :-)

[waynemerricks]

I'm not sure how practical re-implementing caed & ripcd would be. As far as I remember caed talks straight to JACK/ALSA and does things like updating audio meters to the rest of Riv. You then have ripcd that talks to caed, responds to RML macros and other bits and bobs.

Having said that, at a rough guess 90% of all the tools you use in Rivendell just change database entries without any audio interaction (rdadmin, rdlogmanager, most of rdlibrary, rdlogedit and more). If we could move those to HTML or something other than QT3 I imagine it would drastically cut down on the amount of work that is left to migrate to QT5.

At the moment I'm just happy that the tryphon repos exist as last time I tried to install QT3 and Riv from source without these repos, it didn't go well.

[dklann]

Not trying to encourage the life-span of the QT3 code base, but just chiming in that I have an adequate build environment set up on Gentoo Linux (x86_64 Testing: ~amd64). The QT3 libraries from the archives at http://download.qt.io/archive/qt/3/qt-x11-free-3.3.8b.tar.gz with the following environment variables set before build:
export QTDIR=/usr/src/qt PATH=${QTDIR}:/bin/${PATH} MANPATH=${QTDIR}/doc/man:${MANPATH} LD_LIBRARY_PATH=${QTDIR}/lib:${LD_LIBRARY_PATH}
And I never run "make install" I just use the libraries and binaries as built, in place.

In general, I concur with @waynemerricks and support (at least emotionally!) his effort with rivendell-html!

[at0mikk]

It is encouraging that someone is still able to build and run riven dell.
However, I im not able to build rpm for rivendell on centos 7 as the following error occurs:
**make[1]: lupdate: Command not found
make[1]: * [all] Error 127

please help

[ElvishArtisan]

We will be revisiting this whole issue in the coming weeks. Be aware that it's not a trivial change though! It basically means reimplementing large swaths of Rivendell's code and will likely take several months.

[at0mikk]

Thanks for a quick response
I think I got rivendell working despite rpm build errors

[edglazer]

Since this is still open, I wanted to throw out another idea that is sort of a hybrid of the QT5 vs. web/html/js/css/php approach. Electron is a framework developed originally by Github for their atom.io text editor, and it leverages node.js and chrome engines (I think, I've not actually messed around much with it yet) to create cross-platform apps. There are some pretty cool apps available to show off its capabilities if anyone is interested in checking it out more:
http://electron.atom.io/apps/

Its very actively developed... They hit 1.0 May 11th, I think and current version is 1.2.3 (which could be a good thing or a bad thing, depending on your stance).

[SwissLaptop]

Migrating to web-based interfaces is IMHO a bad idea, not only but also because of cross-site attacks and lots of GUI overhead: You can run many QT5 applications just fine on 10yo to 15yo or Raspi-like machines, but any common web browser (engine) is likely to run out of memory or freeze the machine with excessive swapping.