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 ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
_______________________________________________
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
