HTML5 deployment: progress comes into sight
mark at livecode.com
Wed May 31 10:14:14 CEST 2017
On 2017-05-31 09:02, hh via use-livecode wrote:
> If I understand correctly Mark speaks currently about
>  using a browser widget within the _HTML5 deployment_ (emscripten).
Heh - not in this case - however, it is an interesting idea. With the
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).
(again) it would be nice if LCB had a more 'native' way to do it without
> Part , 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
necessarily need an 'embedded browser in HTML5' to do so.
> (not by talking
> _via LC Script_ forth to and back from a browser widget).
> Using or not using another widget from LC Builder via LC Script arises
> the next
> new question:
>  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.
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
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
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
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
More information about the use-livecode