Replacement Player for the discontinued Ubuntu Python Client

This is a continuation of the discussion on GitHub.

Suggestions so far:

Next Steps

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.

1 Like

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 :smile: 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 :smile:

Yet another language to learn… but could be a good candidate.

LUA : http://www.lua.org/about.html

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.

With regards to Eclipse I won’t be using it.

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.

I know this is a difficult decision to take.

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.

These newly announced devices could be excellent if chrome packaged apps were picked…

Alas, that seems doubtful!

This, however, will be perfect for Xibo :); since the windows client should work fine on it.

real case cross-platform implementation of xibo client: Lazurus RAD. Take a look !

i’ve got it !
It works well for just 100 euros !

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 :smile:

At the moment we are exploring Java as the option of choice - we did look at Qt but we weren’t sure if the WebView would be good enough.

We appreciate everyone is keen for a Linux player - what can I say, we will do our best :smile:

Dan,

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.

Kevin

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.