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 <ambassa...@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 > ____________________________________________________________________ > ambassa...@fourthworld.com http://www.FourthWorld.com > > > > > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
