A major roadblock to community involvement is the lack of a good specification for XMDS and the XLF. This should be a starting point for any development.
We are also flirting with JavaFX as we believe it offers us a great “shot” at a Windows/Linux player.
Resuming this thread from github, Closed #29,
I’d just like to say that
DanGarner replied:
“Please don’t take my short replies in the wrong way - I just have a lot to read though it will be great to discuss with you on the forums.”
We have looked at:
Air
Python-QT
C++
WPF
First question, is working with Lib_Browsernode/berkelium
fully out of the question? There was mention of Jian (sp?) having some success with it.
Second question, is linux CEF the current direction preferred for development?
Last question in general, is the language choice decided or still open?
We have been working with the pyclient and libbrowser node for quite some time now without any real quantifiable progress towards a stable cross platform solution. I think it is fair to say that despite a sterling effort by @alex we are light years away from making it work in a reliable fashion with the more advanced content that Xibo is now able to display.
The underlying libavg library used in pyclient is also a bit of a difficult beastie to get running on different platforms, as well as to install and package.
What we really want is an end to supporting different players - instead we want a player than can:
Run on Windows
Run on Ubuntu + other Linux variants
Run embedded in a web page (a very popular request)
Act as a live preview in the CMS
We do accept that it will be necessary to support the current dotnetclient for some time to come, until we can somehow address the needs of users that embed
IE only content
PowerPoint
CEF is not necessarily the direction of development - it was implemented into the .NET player to try and bring further stability improvements to that platform, but it may have actually had the opposite effect.
I think there is an opportunity for the community to continue developing pyclient and even other purpose built players for particular scenarios. The move to github has brought about a movement in this direction and when you think about it, why shouldn’t there be some niche, bespoke player for certain situations. There could even be opportunities to leverage the CMS in other applications (people writing embedded players for example).
The single biggest block to this is the lack of documentation for the XMDS and XLF formats.
JavaFX
We originally wrote the basics of a player in Java (a long time ago, before pyclient), so when someone suggested JavaFX it was an obvious choice. After some research it seems to have good support for Video and Web content in a cross platform environment, and it can be embedded as a Java applet. It ticks all the boxes so far.
Chrome Packaged Apps
This was our second choice and hasn’t been entirely ruled out.
My question is: why did you stop the Java player a long time ago?
In my experience, Java still contains memory leaks, the latest Oracle update made it even worse (Eclipse on windows).
Just curious: why not using javascript (framework) and a browser?
We stopped it due to lack of support for web content (we are talking a LONG time ago) when the FX web panel didn’t exist.
I’m not sure it could be reliable enough in a standard browser (or chrome packaged apps) - 24/7 operation is tough to manage when you don’t have control over the native process hosting the code.
The very first Xibo player was native HTML wrapped in a HTA
In short Berkelium is dead. Libavg is awesome but is too picky about which hardware it will and won’t run on.
Java may not be ideal either. Unfortunately we know from bitter experience with these things the only way to know is to build something and see. JavaFX on paper ticks all the boxes for the things we need to do, as well as being supported by someone large enough that we know they aren’t going to abandon work on the project on a whim.
Direct Javascript isn’t really workable as you need threading and background processes to handle the interaction with the web services, downloading files in the background etc.
As it stands, I’ll be writing the core of something new to check feasibility and stability and then we’ll turn that over for contribution once there’s something for others to work off of.
LUA sounds good ! It should be a great scripting solution. The scenario could be c++/java for the client/server comunication and LUA for the front-end automation.
I must be missing something. What would LUA give us that a single language solution wouldn’t (apart from another dependency and another language to learn!)?
Eclipse is broadly used and still contains leaks. That’s the only point I wanted to make: Java still contains leaks and sometimes even more after the necessary updates to keep it secure.
The only way we’re going to find out is to try something and see how it works out. Unfortunately the issues Xibo clients tend to bring out in platforms aren’t the kind you can reasonably research.
We know from Xibo for Android it is possible to write a client in Java that works reliably so that’s where I’m positioned at present.
I suggest QT Framework as a good option for the cross plataform client. It’s very reliable and it’s WebView library would help to show HTML content.
Hope you get a veredict soon…I’m ansious for a stable linux client version
JavaFX seems really interesting. Perhaps it would eventually give you the ability to have a cross-platform client (Linux/Windows/Mac) on one main codebase.
Unfortunately it looks like we will need to knock that idea on the head - we got a decent way down the track before we realised that the WebView provided in FX does not support Flash (or any plugin).
We’ve started exploring some other options to see where we get.
it will be great to discuss with you on the forums.”