Re: HTML5 deployment: progress comes into sight

> k wrote: > I'd like to be able to integrate LC's HTML5 output with regular web page > structures a little more flexibly. That's been one of the big things > that's really put me off trying out much with this form of output, so > far at least. You can do that since November 2016 (LC

Re: HTML5 deployment: progress comes into sight

Hi k. All special info I have is from here (and links there): https://en.wikipedia.org/wiki/Same-origin_policy And I know, from my own sad experience, that one has to try to follow the most strict interpretation, as browsers differ in their implemementation and even the same browser from one

Re: HTML5 deployment: progress comes into sight

On 16 Jun 2017, at 5:15, hh via use-livecode wrote: if the webpage starts with "hyperhh.de" then the images have to be called explicitly from hyperhh.de while download from "hyperhh.org" (which is simply another name for the same domain) fails. Thanks for the example! Re the domain thing, I'd

Re: HTML5 deployment: progress comes into sight

A basic test of the new feature "fetchURL" of the LC 9.0.0-dp7 HTML5 standalone builder: Load files (here images) from a server. The load origin has to be on the same domain as the webpage that loads the standalone. (EU) http://hyperhh.de/html5/testFetch-9.0.0-dp-7X.html (US)

Re: HTML5 deployment: progress comes into sight

Yet another creative contribution to this thread: SVGtoPNG_HTML5 This is a HTML5 standalone that is based on stacks that Jonathan and I made, see livecodeshare.runrev.com or 'Sample stacks' (the stacks use a clever conversion idea of Jonathan). Launch SVGtoPNG_HTML5 from here: (EU)

Re: HTML5 deployment: progress comes into sight

Yet another creative contribution to this thread (beta version, nowhere else linked for a few days). http://hyperhh.org/html5/video-funHTML5-9.0.0-dp-4hhX.html Video-Fun is a HTML5 standalone that communicates with the webpage to take frames from a video and display them as image. As we have an

Re: HTML5 deployment: progress comes into sight

On 06/04/2017 02:53 AM, Jonathan Lynch via use-livecode wrote: No need to loop. Set three flags to false. After each callback comes in and the flag gets switched, check all three flags. After the last ones comes in, all three flag variables will be switched and can trigger the next action.

Re: HTML5 deployment: progress comes into sight

No need to loop. Set three flags to false. After each callback comes in and the flag gets switched, check all three flags. After the last ones comes in, all three flag variables will be switched and can trigger the next action. Sent from my iPhone > On Jun 3, 2017, at 9:04 PM, Mark Wieder via

Re: HTML5 deployment: progress comes into sight

On 06/03/2017 06:38 PM, Sannyasin Brahmanathaswami via use-livecode wrote: Fascinating solution for X no of use cases, where you don't really need *now* , but where what you really only need is to know "exactly when and what" happened, even if slightly (typically, milliseconds) after the

Re: HTML5 deployment: progress comes into sight

Mark Wieder wrote: Requests are sent asynchronously and trigger a callback message when they're done. The callback message payload contains a reference to the message that called it. That way a callback handler can associate the returned message with the calling handler, and if

Re: HTML5 deployment: progress comes into sight

On 05/31/2017 02:35 PM, hh via use-livecode wrote: "Synchronous" means here that the callback is done in the order it appears in the list of js instructions, i.e. "synchronous to the instruction order". If you say in your js function instruction1; callback1; instruction2;

Re: HTML5 deployment: progress comes into sight

Just getting back here after a week away on another project where they are moving the Hinduism Today app to an HTML 5 platform (shameless promotion) check it out… pretty cool release (free) on the App store… Android version is buggy. @ Roland: Right.. my use of "Syncronous" was a bit off,

Re: HTML5 deployment: progress comes into sight

> On Jun 2, 2017, at 3:02 PM, hh via use-livecode > wrote: > > Simply a creative contribution to this thread: > > Here are direct links. Worth waiting for loading, it's faster than you > expect. (Also loading times has been essentially improved with my tests). >

Re: HTML5 deployment: progress comes into sight

Simply a creative contribution to this thread: Here are direct links. Worth waiting for loading, it's faster than you expect. (Also loading times has been essentially improved with my tests). [EU] http://hyperhh.org/html5/LCImageToolboxHTML5-9.0.0-dp-4hhX.html [US]

Re: HTML5 deployment: progress comes into sight

Anyway, I really appreciate how easy it is to get at any of you and how much you're paying attention to the pulse out here. The sharing of thinking/philosophy is really important because that flavor matters when we are planning to build something. On Fri, Jun 2, 2017 at 10:30 AM, Mike Kerner

Re: HTML5 deployment: progress comes into sight

Clearly you need The Talk from The Unbearded One, because The Customer Is Always Right. On Fri, Jun 2, 2017 at 9:29 AM, Mark Waddingham via use-livecode < use-livecode@lists.runrev.com> wrote: > Hehe - that works both ways Mike ;) > > Sent from my iPhone > > > On 2 Jun 2017, at 14:22, Mike

Re: HTML5 deployment: progress comes into sight

Hehe - that works both ways Mike ;) Sent from my iPhone > On 2 Jun 2017, at 14:22, Mike Kerner via use-livecode > wrote: > > Mark, and the rest of the team, having come from other development tools, > where the team is not part of the community, it's nice that

Re: HTML5 deployment: progress comes into sight

Mark, and the rest of the team, having come from other development tools, where the team is not part of the community, it's nice that you guys are so actively engaged with the community, even when you're completely wrong because you disagree with me. On Fri, Jun 2, 2017 at 7:46 AM, hh via

Re: HTML5 deployment: progress comes into sight

We really should start to split this thread into branches, for example [A] HTML5 deployment and "do as javascript" as already implemented [B] HTML5 deployment and using widgets (not the browser widget) [C] HTML5 in LC Builder (and the browser widget, javascript via FFI) [D] LC Builder:

Re: HTML5 deployment: progress comes into sight

It has substantial and wide ranging implications - all to the good. At the very least 'WASM' is more compact than asm.js and eliminates the compiling overhead which you have when you load a text based representation of the language. We've got a fair bit of housekeeping to do (particularly in

Re: HTML5 deployment: progress comes into sight

The thought did occur to me - whilst it 'sounds' like a good idea at first glance there's a lot of i's to dot and t's to cross especially as the goal of widgets is they should be indistinguishable from controls written in C++ direct in the engine. As it stands many of the implications of that

Re: HTML5 deployment: progress comes into sight

A bit OT but there's an interesting discussion here https://news.ycombinator.com/item?id=14458648 on the merits of WebAssembly vs JavaScript for in browser applications. As WebAssembly matures it will be interesting to see what implications (if any) it has for livecode html5 i.e. will it

Re: HTML5 deployment: progress comes into sight

What I believe BR was referring to is that we can expose LC handlers to the local JS context of a browser widget thus enabling liveCode.* calls. What would be good, was to have functions (synchronous ones for the sake of complexity) exposed as well so that calling a liveCode.* function from JS on

Re: HTML5 deployment: progress comes into sight

On 06/01/2017 04:59 PM, Monte Goulding via use-livecode wrote: Why not check for CopySpecial() if the object is a widget before passing to the owner? It makes more sense that the library handler a widget exports is part of the message path. That way we can dispatch to the instance and the

Re: HTML5 deployment: progress comes into sight

> On 1 Jun 2017, at 8:27 pm, Mark Waddingham via use-livecode > wrote: > > Would export fooCopySpecial() as a function accessible from LCS where you can > do: > > fooCopySpecial(the long id of widget 1, ...) Why not check for CopySpecial() if the object is a

Re: HTML5 deployment: progress comes into sight

@Mark Waddingham: I was partially wrong. There is already more possible than I thought with HTML5 deployment when using "do as javascript". One can work around missing javascriptHandlers because there is "the result" available for evaluating in LC Script. I tried again and found a bug in the

Re: HTML5 deployment: progress comes into sight

> Mark W. wrote: > I've pondered 'invoke' as a new keyword - but I'm not sure how much I > like that, but it would 'fill the gap'. For 'foreign speakers' a synonym like "useHandler" may be easy to remember. Would fit into LC Script: -- start using useHandler "drawImage" of with parameter --

Re: HTML5 deployment: progress comes into sight

Yes, I agree. Thanks a lot. ) Roland On May 31, 2017 19:07, wrote: > A callback is not synchronous, his point was that it would be nice to > communicate synchronously between LC and JS, rather than use complex > callback chains. > > I agree with him, but I don't think

Re: HTML5 deployment: progress comes into sight

On 2017-06-01 12:34, Roger Eller via use-livecode wrote: LOL @ invoke! You need to rename Widgets to Spells. #widgetcraft Heh - I hadn't thought of that connotation :) Perhaps that means we have #widgetseers or #widgetmages too! FWIW, 'invoke' is the name of the LCB VM's opcode for, well,

Re: HTML5 deployment: progress comes into sight

LOL @ invoke! You need to rename Widgets to Spells. #widgetcraft ~Roger On Jun 1, 2017 6:28 AM, "Mark Waddingham via use-livecode" < use-livecode@lists.runrev.com> wrote: > On 2017-05-31 23:13, hh via use-livecode wrote: > >> Call, send , dispatch, do script ... >> It is very impressive how

Re: HTML5 deployment: progress comes into sight

On 2017-05-31 23:13, hh via use-livecode wrote: Call, send , dispatch, do script ... It is very impressive how the core team can still have all that messaging in mind while developing LC Builder. The problem here is what syntax to use in LCS to 'call into a widget' - widget's need to be able

Re: HTML5 deployment: progress comes into sight

"Synchronous" means here that the callback is done in the order it appears in the list of js instructions, i.e. "synchronous to the instruction order". If you say in your js function instruction1; callback1; instruction2; callback2; then you can't control what's done first. This is

Re: HTML5 deployment: progress comes into sight

Call, send , dispatch, do script ... It is very impressive how the core team can still have all that messaging in mind while developing LC Builder. Now why not use kind of a mnemonic naming in LCB e.g. sendHandler callHandler dispatchHandler doHandler ? We could still have

Re: HTML5 deployment: progress comes into sight

I have a feeling that Alejandro's stack was running a while back. Richmond. On 5/31/17 4:03 pm, Mark Waddingham via use-livecode wrote: On 2017-05-31 13:18, Richmond Mathewson via use-livecode wrote: Weel you could start with ALL SVG images made in Inkscape: monochromatic "thingies" have

Re: HTML5 deployment: progress comes into sight

On 2017-05-31 15:43, hh via use-livecode wrote: The problem is the "one-way"-only: I can't see any way to go back, from the page to the standalone. That is a very good point. = The browser widget has jsHandlers available. = The standalone has to get the data from the page by guesses, in a

Re: HTML5 deployment: progress comes into sight

A callback is not synchronous, his point was that it would be nice to communicate synchronously between LC and JS, rather than use complex callback chains. I agree with him, but I don't think there is a universal way to do that, just because some things in JavaScript, like rendering an image

Re: HTML5 deployment: progress comes into sight

@BR wrote: ... "What's very difficult, as you write in detail, are "callbacks" for _synchronous_communication..." Callback functions? In my mind, a "callback" is always asynchronous -? Let us say in Javascript - passing the function name and parameters of Javascript through LCS/LCB and then

Re: HTML5 deployment: progress comes into sight

> > hh wrote: > > Part [1], the current thread, will hopefully allow for example to have > > the "sample > > stacks" imageToolKit or the recent SVGplay-stacks in a HTML5 > > standalone. The speed > > results will be very interesting. > > Mark W. wrote: > If you have pure JS libraries you want to

Re: HTML5 deployment: progress comes into sight

On 2017-05-31 14:30, Jonathan Lynch via use-livecode wrote: Would it be possible to create a widget that links to an Inkscape library that processes svg data and sends it back to the widget to be displayed the way PNG is displayed? No - two issues: 1) Inkscape is an application - not a C

Re: HTML5 deployment: progress comes into sight

On 2017-05-31 13:18, Richmond Mathewson via use-livecode wrote: Weel you could start with ALL SVG images made in Inkscape: monochromatic "thingies" have limited use. Or how about we start with the *standard* profiles for SVG and work up from there: https://www.w3.org/TR/SVGTiny12/ i.e.

Re: HTML5 deployment: progress comes into sight

Would it be possible to create a widget that links to an Inkscape library that processes svg data and sends it back to the widget to be displayed the way PNG is displayed? Sent from my iPhone > On May 31, 2017, at 7:18 AM, Richmond Mathewson via use-livecode >

Re: HTML5 deployment: progress comes into sight

Weel you could start with ALL SVG images made in Inkscape: monochromatic "thingies" have limited use. Richmond. On 5/31/17 11:48 am, Mark Waddingham via use-livecode wrote: On 2017-05-31 10:38, Jonathan Lynch via use-livecode wrote: A native svg object that accurately displays all svg files

Re: HTML5 deployment: progress comes into sight

On 2017-05-31 10:38, Jonathan Lynch via use-livecode wrote: A native svg object that accurately displays all svg files is essential. I strongly support Mark's point on that issue. This is not reinventing the wheel - it's attaching the already invented wheel to the wagon. Heh - well more

Re: HTML5 deployment: progress comes into sight

A native svg object that accurately displays all svg files is essential. I strongly support Mark's point on that issue. This is not reinventing the wheel - it's attaching the already invented wheel to the wagon. Sent from my iPhone > On May 31, 2017, at 4:26 AM, Mark Waddingham via

Re: HTML5 deployment: progress comes into sight

On 2017-05-31 04:31, Sannyasin Brahmanathaswami via use-livecode wrote: Does this relate at all to " LCB to bind to JavaScript APIs" ? Directly? No - they are two distinct things. However, running JavaScript (via LCB) in the HTML5 engine is equivalent to running JavaScript (via LCB) in a

Re: HTML5 deployment: progress comes into sight

On 2017-05-31 09:01, Dan Brown via use-livecode wrote: I'll also add that for all the wonderful possibilities that LCB brings there is a very real danger that countless hours will be spent using it to re-invent the wheel. That is true of every language ever implemented ;) However, one of

Re: HTML5 deployment: progress comes into sight

On 2017-05-31 09:02, hh via use-livecode wrote: If I understand correctly Mark speaks currently about [1] using a browser widget within the _HTML5 deployment_ (emscripten). Heh - not in this case - however, it is an interesting idea. With the 'do as javascript' functionality, scripts could

Re: HTML5 deployment: progress comes into sight

The browser widget is essentially kind of a GUI to libbrowser, cleverly made. @Dan Using all these js libraries is already possible (where the inherent HTML5 of the widget allows that -- different by platform), just do it. Examples of going that way are among the most recent 10 of "Sample

Re: HTML5 deployment: progress comes into sight

I'll also add that for all the wonderful possibilities that LCB brings there is a very real danger that countless hours will be spent using it to re-invent the wheel. Take for instance the displaying of svg's. This is a solved problem in the browser and has been for a long time but in native

Re: HTML5 deployment: progress comes into sight

JavaScript via the browser would be huge. There are tens of thousands of JavaScript libraries that could be used by livecoders to add bleeding edge UI elements & websockets to their applications via lc script. It would allow livecode to communicate with the real-time web without lcb ( which only

Re: HTML5 deployment: progress comes into sight

mark Waddington wrote: We've also been looking at how to abstract the FFI work we've done as part of the Infinite LiveCode campaign to allow LCB to bind to JavaScript APIs (which will allow greater type fidelity than is possible using 'do as javascript' from LCS). BR: I

Re: HTML5 deployment: progress comes into sight

Any ETA on dp-7? I have a sort-of urgent need that I hope is addressed in 7. On Tue, May 30, 2017 at 1:25 PM, Mark Waddingham via use-livecode < use-livecode@lists.runrev.com> wrote: > On 2017-05-18 16:09, hh via use-livecode wrote: > >> [Excerpt from thread 'LC core team', now with a more

Re: HTML5 deployment: progress comes into sight

On 2017-05-18 16:09, hh via use-livecode wrote: [Excerpt from thread 'LC core team', now with a more approriate title.] That being said, recently we are a hair's breadth away from getting widgets working in HTML5 (hopefully running a little quicker than they did before too):