Players in HTML5 - ETA for Full Functionality?

[Mark Waddingham]

When it comes down to it, there is a direct parallel between wanting to use native html5 elements in a LiveCode html5 app and wanting to use native (system provided) controls on mobile.

There are still a couple of technical hurdles to overcome to make this possible in the html5 port, but for the most part it comes down to having a bridge between LCB and JavaScript when running in a browser. You can view the JS APIs as no different from system APIs on any other platform and in the same way as LCB can bridge (albeit in a very low-level way right now) to C APIs directly, the Html5 engine will eventually be able to bridge to JS APIs.

Mark.

Sent from my iPhone

> On 25 Feb 2016, at 18:23, Richard Gaskin <ambassador at fourthworld.com> wrote:
> 
> Sannyasin Brahmanathaswami wrote:
> 
> >  So if we can run Landstat Satellites and entire Universities
> > (vienna), I humbly submit that it's time to realize "you did it" when
> > it comes to data management...and to put media delivery at the
> > forefront of the agenda not at the end of the agenda.
> >
> > The current generation is all about audio and video. "expect... all
> > at once...." Many of us have been asking for audio/video improvements
> > for well over the past ten years. So it's not as if we are coming out
> > of the blue....
> 
> We still don't have point-and-click data binding with a built-in MVC framework.
> 
> But in all fairness those are things the community can do in script, whereas multimedia playback is very much an engine concern.
> 
> I bring up MVC only to suggest that your priorities may not be mine, and mine may not be others'.
> 
> As a Linux user I haven't been able to even just play a video at all in several years, while it's possible (with some codec/format limitations) on Windows and Mac users enjoy support for the latest OS media APIs.
> 
> Since most of my current work is in data-intensive productivity apps this hasn't held me back; I share the story only to point out that priorities are as broad and varied as this community.
> 
> 
> > "difficult port" ?? there are any number of media player frameworks
> > built on JS... Perhaps I'm very dense, but JS is use for media
> > deliver *everywhere*... It's not about a player exactly.. but just to
> > be able to stream audio and video.
> >
> > So back to my question: is there another way to play media using
> > other means beside a player?
> 
> Yes: let the browser do it.
> 
> But to do that, you'd need to let the browser do it all.
> 
> There are two very different worlds here:  the desktop, run with OS APIs on binary structures and machine code; and the web, run with browser specs on textual data and JavaScript.
> 
> These worlds do not collide.  They are fundamentally different, designed for very different tasks.
> 
> Before LC's HTML initiative, the two worlds were for the most part quite separate.  No one expects to use XCode to write C++ apps in Cocoa and somehow run them in a browser.
> 
> What LC is attempting here is a significant departure from a long history in which the two worlds, desktop and web, are very separate from one another.
> 
> Given that the only execution engine commonly available in browsers is JavaScript, to migrate applications made in LiveCode into the confines of a web browser requires either of two approaches:
> 
> a) Translate LC-native objects to browser-native HTML/CSS, and LC-native scripts to JavaScript.
> 
> b) Translate the LC engine to JavaScript so LC-native objects and scripts need no translation.
> 
> Either is a difficult task.
> 
> Option a) makes it relatively easy to get appearances, but for functionality requires translating every line of LiveCode script into JavaScript.
> 
> The appearance part isn't that hard:  with a few hours it's possible to translate native LC objects into their HTML/CSS equivalents rather satisfyingly, with the result being lean browser-native layouts.
> 
> But the functionality is not so easy. LiveCode and JavaScript are so very different in their syntax, logic, event and object models, that translation from one to the other is a mind-bendingly difficult task.
> 
> Option b) is where we're headed instead, moving the entire LC engine into the browser by translating roughly three quarters of a million lines of C++ into JavaScript.
> 
> This allows LiveCode scripts and objects to be handled more or less how they're handled in the desktop engine, without needing to translate LiveCode scripts.
> 
> But given that the desktop and the web are such fundamentally different platforms, neither approach can be expected to be a seamless move. These are very different worlds; there is no magic pony.
> 
> Option a) would allow us to export LC player controls as HTML5 player objects, but would require you to write any scripts you need in JavaScript.
> 
> Option b) lets all your LC objects scripts go along for the ride since the LC engine they depend on is now a JavaScript object, but it means you don't have access to browser-native objects like HTML5 media support.
> 
> If one were inclined to pursue option a), it could be possible to take the approach Toolbook and others have, in which functionality targeted for web deployment is limited to calls in LC libraries for which matching JavaScript libraries are provided.  I first suggested this as a solution here in 2003, but no one was interested enough to help see it through.  Could still be done, though, just not by myself.  And while the functionality such libraries provide would be limited, the intersection of things we need to do on both desktop and web is somewhat limited by nature anyway, so for some apps it may not be a bad option.
> 
> With option b), the one being pursued at the moment, there is the possibility that the LC engine code that handles media playback could be replaced post-translation with browser-native handling.  Given the complexity of the output Emscripten produces this would not be trivial, and with the differences in the object model it may not be practical, but it might be possible.
> 
> I don't know if any of this rambling post is helpful, but my aim here is just to point out the very difficult task being undertaken here.  And while we can expect Peter's excellent work to continue to make big strides, I think it may be helpful to keep expectations in check, since we're attempting to bridge two very different worlds. Not all life forms that thrive on one planet can survive at all on another.
> 
> -- 
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> ____________________________________________________________________
> Ambassador at FourthWorld.com                http://www.FourthWorld.com
> 
> 
> 
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode