HTML5 deployment: progress comes into sight

[Mark Waddingham]

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 already create a 
suitable element in the host page to allow this - although, admittedly, 
it would be quite cool if libbrowser had a 'html5' implementation which 
made it 'do the right thing'. (Pre-requisite for this is getting 'native 
layers' working in HTML5).

> [2] using via FFI javascript or (part of) libbrowser _within_ LC 
> Builder.

Yes - this was what I was mainly referring to. With 'do as javascript' 
(in HTML5 engine) you can already evaluate anything javascripty, but 
(again) it would be nice if LCB had a more 'native' way to do it without 
indirecting through it (also it would save a per-call JavaScript compile 
step)

> 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.

If you have pure JS libraries you want to use, then you can already load 
these and access them (do as javascript, again) - you wouldn't 
necessarily need an 'embedded browser in HTML5' to do so.

> Part [2] will allow the use of javascript libs _within_ our widgets
> (not by talking
> _via LC Script_ forth to and back from a browser widget).

Yes.

> Using or not using another widget from LC Builder via LC Script arises 
> the next
> new question:
> [3] How can widgets easily communicate amongst themselves?

At the moment widgets can communicate with each other via properties - 
there is a missing 'feature' at present in terms of allowing public 
(non-event) handlers to be called from 'outside the widget' (i.e. from 
script)... Although this is more a matter of finding the right syntax 
than anything else.

e.g.

A widget might have a 'Copy' handler - which does what you would expect 
'copy tObject' to do - so you might want to invoke this handler at 
certain points:

    call "Copy" of widget "Foo"

However, 'call' already has a meaning - it means 'send message to script 
object without changing context' (note I use the term 'script object' 
here to distinguish between the object as you see it in LCS, i.e. its 
script, and the object which backs it, i.e. the widget).

Basically, we can't use 'dispatch', 'call' or 'send' as their behavior 
is already taken for interaction at the script level (i.e. LCS handlers 
in the scripts of the objects) and *not* invoking a method on the 
'thing' behind the script (whether that be an engine control, or 
widget).

Indeed, we already made a slight mistake with 'do in <widget>' which we 
do need to rectify (somehow) at somepoint - for a similar reason so that 
we can actually have 'do in <object>' to mean 'do the fragment of script 
in the context of the target object' (at the moment you can use it on a 
browser widget, but then the script is JavaScript and not LCS!).

Warmest Regards,

Mark.

-- 
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps