HTML5 deployment: progress comes into sight

classic Classic list List threaded Threaded
49 messages Options
123
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTML5 deployment: progress comes into sight

Klaus major-k via use-livecode
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 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. Let's walk before we try and run.
>
> Warmest Regards,
>
> Mark.
>

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTML5 deployment: progress comes into sight

Klaus major-k via use-livecode
In reply to this post by Klaus major-k via use-livecode
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 <handler> <to object>
   callHandler <handler> <of object>
   dispatchHandler <handler> <of object>
   doHandler <handler> <of object>?

We could still have

   do <script> <in object> [as language]

the default for a browser widget being "as javascript".
Could be used parallel to
   doHandler <handler> of <browser widget>
(where <handler> has to be a javascript function name).

> > hh wrote:
> > 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?
>
> Mark W. wrote:
> 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!).

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTML5 deployment: progress comes into sight

Klaus major-k via use-livecode
In reply to this post by Klaus major-k via use-livecode
"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 the price we have
to pay for speed (multi-threading).
It is even possible that callback2 arrives at LC _before_ one of
       instruction1; callback1; instruction2;
is finished.
That's what Jonathan tries to have (successfully in some scenarios)
by doing in the widget first
   instruction1; callback1;
then, after getting callback1:
   instruction2; callback2;

But even when going this way there is no guarantee that callback1/callback2)
arrives at the LC widget/card _after_ instruction1/instruction2 is done.
You have to work harder (in javascript) to reach at that point.

> > BR wrote: ... "What's very difficult, as you write in detail, are
> > "callbacks" for _synchronous_communication..."
>
> Roland H. wrote:
> 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 somehow the result is put into a variable while I am continuing
> processing other stuff. Maybe I am wrong? I am calling a server, waiting
> for the result, but I could wait forever and the result will possibly never
> come. So it would be blocking doing other things. A callback would free me
> from waiting for nothing. Is this a right definition for "callback"?
>
> What defines "callback"? I could understand though that I am calling a
> function in the browser widget (using the "callback" name of the function)
> which will be executed through Javascript and will be returning a value for
> further processing. What means "synchronous" or "asynchronous" in this
> context?
>
> Again, in my mind, a callback is when I send off a parcel to my friend with
> an instruction to tell me that it arrived and the confirmation of arrival.
> The confirmation is the callback. Then I know my friend received the
> parcel. Or in another analogy, I am calling someone by phone asking to call
> me back. The person may call immediately or may call never or in a couple
> of days. This is asynchronous.
>
> How would a callback become synchronous? Is it then still a "callback"?

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTML5 deployment: progress comes into sight

Klaus major-k via use-livecode
In reply to this post by Klaus major-k via use-livecode
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 to expose public handlers which can be called
from LiveCode Script (not just properties and events).

> Now why not use kind of a mnemonic naming in LCB e.g.
>
>    sendHandler <handler> <to object>
>    callHandler <handler> <of object>
>    dispatchHandler <handler> <of object>
>    doHandler <handler> <of object>?

The problem is that all the keywords (naturally) associated with
'calling' something in another context are already taken (i.e. send,
call, dispatch, do) and their context is the script of the object. So:

    call "foo" in widget 1

Means send the message 'foo' to the *LiveCode Script* side of the widget
- it is not entirely clear how that could work to mean 'call the handler
'foo' exported by the widget's implementation'.

I've pondered 'invoke' as a new keyword - but I'm not sure how much I
like that, but it would 'fill the gap'.

The other way to slice and dice things is to make it so that any
handlers you want to export to act on the widget internally are added as
'library handlers'. e.g.

   widget foo
     public handler CopySpecial() returns nothing
       ... do magic stuff ...
     end handler
   end widget

Would export fooCopySpecial() as a function accessible from LCS where
you can do:

    fooCopySpecial(the long id of widget 1, ...)

Or similar. This is closer to how the engine does syntax - which are all
non-object based functions in C++, which then dispatch to the object.
e.g.

    copy widget 1

Ends up calling a C++ function:

    MCInterfaceExecCopyControl(ctxt, ptr-to-widget-1)

Which then does:

    ptr-to-widget-1->copy()

> We could still have
>
>    do <script> <in object> [as language]
>
> the default for a browser widget being "as javascript".
> Could be used parallel to
>    doHandler <handler> of <browser widget>
> (where <handler> has to be a javascript function name).

This would almost fix the 'overloading' problem of 'do in <browser
widget>'. If we require you to do:

    do X in <browser widget> as javascript

If you want to execute the code fragment *inside* the browser widget;
then that means:

   do X in <control>

Could be taken to mean execute X as LCS in the context of <control>.

Anyway, a bit more to think on here :)

Warmest Regards,

Mark.

--
Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTML5 deployment: progress comes into sight

Klaus major-k via use-livecode
LOL @ invoke!  You need to rename Widgets to Spells.  #widgetcraft

~Roger

On Jun 1, 2017 6:28 AM, "Mark Waddingham via use-livecode" <
[hidden email]> wrote:

> 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 to expose public handlers which can be called from
> LiveCode Script (not just properties and events).
>
> Now why not use kind of a mnemonic naming in LCB e.g.
>>
>>    sendHandler <handler> <to object>
>>    callHandler <handler> <of object>
>>    dispatchHandler <handler> <of object>
>>    doHandler <handler> <of object>?
>>
>
> The problem is that all the keywords (naturally) associated with 'calling'
> something in another context are already taken (i.e. send, call, dispatch,
> do) and their context is the script of the object. So:
>
>    call "foo" in widget 1
>
> Means send the message 'foo' to the *LiveCode Script* side of the widget -
> it is not entirely clear how that could work to mean 'call the handler
> 'foo' exported by the widget's implementation'.
>
> I've pondered 'invoke' as a new keyword - but I'm not sure how much I like
> that, but it would 'fill the gap'.
>
> The other way to slice and dice things is to make it so that any handlers
> you want to export to act on the widget internally are added as 'library
> handlers'. e.g.
>
>   widget foo
>     public handler CopySpecial() returns nothing
>       ... do magic stuff ...
>     end handler
>   end widget
>
> Would export fooCopySpecial() as a function accessible from LCS where you
> can do:
>
>    fooCopySpecial(the long id of widget 1, ...)
>
> Or similar. This is closer to how the engine does syntax - which are all
> non-object based functions in C++, which then dispatch to the object. e.g.
>
>    copy widget 1
>
> Ends up calling a C++ function:
>
>    MCInterfaceExecCopyControl(ctxt, ptr-to-widget-1)
>
> Which then does:
>
>    ptr-to-widget-1->copy()
>
> We could still have
>>
>>    do <script> <in object> [as language]
>>
>> the default for a browser widget being "as javascript".
>> Could be used parallel to
>>    doHandler <handler> of <browser widget>
>> (where <handler> has to be a javascript function name).
>>
>
> This would almost fix the 'overloading' problem of 'do in <browser
> widget>'. If we require you to do:
>
>    do X in <browser widget> as javascript
>
> If you want to execute the code fragment *inside* the browser widget; then
> that means:
>
>   do X in <control>
>
> Could be taken to mean execute X as LCS in the context of <control>.
>
> Anyway, a bit more to think on here :)
>
> Warmest Regards,
>
> Mark.
>
> --
> Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTML5 deployment: progress comes into sight

Klaus major-k via use-livecode
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, invoking a
handler. I didn't want to use 'call' or 'send' as they have a somewhat
different meaning in LCS - which involves the message path.

Warmest Regards,

Mark.

--
Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTML5 deployment: progress comes into sight

Klaus major-k via use-livecode
In reply to this post by Klaus major-k via use-livecode
Yes, I agree. Thanks a lot. ) Roland

On May 31, 2017 19:07, <[hidden email]> 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 there is a universal way to do that,
> just because some things in JavaScript, like rendering an image or using a
> webworker, are inherently asynchronous.
>
> Sent from my iPhone
>
> > On May 31, 2017, at 12:36 PM, Roland Huettmann via use-livecode <
> [hidden email]> wrote:
> >
> > @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 somehow the result is put into a variable while I am continuing
> > processing other stuff. Maybe I am wrong? I am calling a server, waiting
> > for the result, but I could wait forever and the result will possibly
> never
> > come. So it would be blocking doing other things. A callback would free
> me
> > from waiting for nothing. Is this a right definition for "callback"?
> >
> > What defines "callback"? I could understand though that I am calling a
> > function in the browser widget (using the "callback" name of the
> function)
> > which will be executed through Javascript and will be returning a value
> for
> > further processing. What means "synchronous" or "asynchronous" in this
> > context?
> >
> > Again, in my mind, a callback is when I send off a parcel to my friend
> with
> > an instruction to tell me that it arrived and the confirmation of
> arrival.
> > The confirmation is the callback. Then I know my friend received the
> > parcel. Or in another analogy, I am calling someone by phone asking to
> call
> > me back. The person may call immediately or may call never or in a couple
> > of days. This is asynchronous.
> >
> > How would a callback become synchronous? Is it then still a "callback"?
> > _______________________________________________
> > use-livecode mailing list
> > [hidden email]
> > Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTML5 deployment: progress comes into sight

Klaus major-k via use-livecode
In reply to this post by Klaus major-k via use-livecode
> 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 <widget>
useHandler "drawImage" of <widget> with parameter <listOfStrings>
-- stop using <widget>


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTML5 deployment: progress comes into sight

Klaus major-k via use-livecode
In reply to this post by Klaus major-k via use-livecode
@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 HTML5 version of my "LCImageToolbox89"
from "Sample Stacks".
Bugs are hard to search/ find because we can't debug "do as javascript" in
LC Script (yes, of course we can do basic "testing" in a browser widget).
So first fly blind and then have eventually the real run-test with the
standalone. Very tedious.

At any rate the new features we will get for HTML5 will be a big step forward.

-------

The standalone is now running here. It is _very_ fast. I'll post it
tomorrow at http://hyperhh.org/html5/ and http://hh.on-rev.com/html5/ .

We can look at such standalones to have by LC a nice GUI to canvas2d-features.

*** And there is more available in canvas2d: Graphics, Video, Audio ...
*** So these are also available _via_ HTML5 standalones, we have to work
*** hard, do some (slightly advanced) javascript but it's possible.
*** I already know the "how to".

[These is on my 'vague' list for the next few demos:
basic graphics/text (also svg-features), more image processing, using
video/audio _via_ HTML5 deployment.]

> Mark W. 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
> > loop.
> >
> > If you can show or give us a solution for that, then we can have in
> > some scenarios even more by using the latest versions of the main
> > browsers than we get by using an embedded browser widget.
> >
> > In sum:
> > Can the HTML5 standalone become a property "javascriptHandlers" that
> > works as in the browser widget?
>
> Yes it can - I'll look into getting that (or something similar) done
> asap.



_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTML5 deployment: progress comes into sight

Klaus major-k via use-livecode
In reply to this post by Klaus major-k via use-livecode

> On 1 Jun 2017, at 8:27 pm, Mark Waddingham via use-livecode <[hidden email]> 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 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 instance can overload/override it if they want necessary.

Cheers

Monte
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTML5 deployment: progress comes into sight

Klaus major-k via use-livecode
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 instance can overload/override it if they want necessary.

+1. I like the way you think.

--
  Mark Wieder
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTML5 deployment: progress comes into sight

Klaus major-k via use-livecode
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 a browser widget not only would trigger the function but also return the
results.

Right now, we need to play musical chairs where JS calls a liveCode.*
handler, which doesn't return anything but executes, then the said handler
execute something in the JS context which is essentially a callback thus
forcing every call into an async call. I know pretty well how async JS
world is but even if we could simply have synchronous functional calls
there it would be awesome and open a whole new world to customized
experiences.

On Thu, Jun 1, 2017 at 9:50 PM, Mark Wieder via use-livecode <
[hidden email]> wrote:

> 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 instance can overload/override it if they want necessary.
>>
>
> +1. I like the way you think.
>
> --
>  Mark Wieder
>  [hidden email]
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



--
http://www.andregarzia.com -- All We Do Is Code.
http://fon.nu -- minimalist url shortening service.
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTML5 deployment: progress comes into sight

Klaus major-k via use-livecode
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 ultimately become a better fit


On 2 Jun 2017 3:08 am, "Andre Garzia via use-livecode" <
[hidden email]> wrote:

> 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 a browser widget not only would trigger the function but also return the
> results.
>
> Right now, we need to play musical chairs where JS calls a liveCode.*
> handler, which doesn't return anything but executes, then the said handler
> execute something in the JS context which is essentially a callback thus
> forcing every call into an async call. I know pretty well how async JS
> world is but even if we could simply have synchronous functional calls
> there it would be awesome and open a whole new world to customized
> experiences.
>
> On Thu, Jun 1, 2017 at 9:50 PM, Mark Wieder via use-livecode <
> [hidden email]> wrote:
>
> > 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 instance can overload/override it if they want necessary.
> >>
> >
> > +1. I like the way you think.
> >
> > --
> >  Mark Wieder
> >  [hidden email]
> >
> >
> > _______________________________________________
> > use-livecode mailing list
> > [hidden email]
> > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> >
>
>
>
> --
> http://www.andregarzia.com -- All We Do Is Code.
> http://fon.nu -- minimalist url shortening service.
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTML5 deployment: progress comes into sight

Klaus major-k via use-livecode
In reply to this post by Klaus major-k via use-livecode
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 approach are hard to assess because the current message path behaviour is more a result of iterative additions over the years (the code is spread all over the place in the engine) rather than something which has been explicitly designed ahead of time.

For example - we added behaviours, then we added before/after, then we added chained behaviours. However the latter don't take into account before/after explicitly which means there are somewhat murky interactions there (it is actually quite difficult to see how those two features should interact as it stands).

We need to rework the message path is implemented for html5 as part of solving the 'wait' problem (we can't use the same trick as on mobile because web worker threads are not fully featured enough - and the unknown number of years before they will likely be is not something we can depend on) so that will help shake out all the skeletons and make deeper changes much easier to assess.

[ the wait problem is that android, iOS and emscripten don't allow nested dispatch of the system event loop - control has to return to system (i.e. Empty c stack) for them to be dispatched ]

TL;DR - it might well be the way to go, but some prep work is needed first. Or at the very least, some time spent pondering it in a dark room to make sure we don't back ourselves into a corner.

Mark.

Sent from my iPhone

> On 2 Jun 2017, at 00:59, Monte Goulding via use-livecode <[hidden email]> wrote:
>
>
>> On 1 Jun 2017, at 8:27 pm, Mark Waddingham via use-livecode <[hidden email]> 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 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 instance can overload/override it if they want necessary.
>
> Cheers
>
> Monte
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTML5 deployment: progress comes into sight

Klaus major-k via use-livecode
In reply to this post by Klaus major-k via use-livecode
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 our build system) to be able to start leveraging it, but it is a case of when and not if.

Warmest Regards,

Mark.

Sent from my iPhone

> On 2 Jun 2017, at 07:53, Dan Brown via use-livecode <[hidden email]> wrote:
>
> 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 ultimately become a better fit
>
>
> On 2 Jun 2017 3:08 am, "Andre Garzia via use-livecode" <
> [hidden email]> wrote:
>
>> 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 a browser widget not only would trigger the function but also return the
>> results.
>>
>> Right now, we need to play musical chairs where JS calls a liveCode.*
>> handler, which doesn't return anything but executes, then the said handler
>> execute something in the JS context which is essentially a callback thus
>> forcing every call into an async call. I know pretty well how async JS
>> world is but even if we could simply have synchronous functional calls
>> there it would be awesome and open a whole new world to customized
>> experiences.
>>
>> On Thu, Jun 1, 2017 at 9:50 PM, Mark Wieder via use-livecode <
>> [hidden email]> wrote:
>>
>>> 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 instance can overload/override it if they want necessary.
>>>>
>>>
>>> +1. I like the way you think.
>>>
>>> --
>>> Mark Wieder
>>> [hidden email]
>>>
>>>
>>> _______________________________________________
>>> use-livecode mailing list
>>> [hidden email]
>>> Please visit this url to subscribe, unsubscribe and manage your
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>>
>>
>>
>>
>> --
>> http://www.andregarzia.com -- All We Do Is Code.
>> http://fon.nu -- minimalist url shortening service.
>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTML5 deployment: progress comes into sight

Klaus major-k via use-livecode
In reply to this post by Klaus major-k via use-livecode
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: Communication between widgets

Yes, there are intersections. Just an idea to have more 'structure'.


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTML5 deployment: progress comes into sight

Klaus major-k via use-livecode
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 use-livecode <
[hidden email]> wrote:

> 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: Communication between widgets
>
> Yes, there are intersections. Just an idea to have more 'structure'.
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



--
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTML5 deployment: progress comes into sight

Klaus major-k via use-livecode
Hehe - that works both ways Mike ;)

Sent from my iPhone

> On 2 Jun 2017, at 14:22, Mike Kerner via use-livecode <[hidden email]> 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 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 use-livecode <
> [hidden email]> wrote:
>
>> 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: Communication between widgets
>>
>> Yes, there are intersections. Just an idea to have more 'structure'.
>>
>>
>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>
>
>
> --
> On the first day, God created the heavens and the Earth
> On the second day, God created the oceans.
> On the third day, God put the animals on hold for a few hours,
>   and did a little diving.
> And God said, "This is good."
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTML5 deployment: progress comes into sight

Klaus major-k via use-livecode
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 <
[hidden email]> wrote:

> Hehe - that works both ways Mike ;)
>
> Sent from my iPhone
>
> > On 2 Jun 2017, at 14:22, Mike Kerner via use-livecode <
> [hidden email]> 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 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 use-livecode <
> > [hidden email]> wrote:
> >
> >> 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: Communication between widgets
> >>
> >> Yes, there are intersections. Just an idea to have more 'structure'.
> >>
> >>
> >> _______________________________________________
> >> use-livecode mailing list
> >> [hidden email]
> >> Please visit this url to subscribe, unsubscribe and manage your
> >> subscription preferences:
> >> http://lists.runrev.com/mailman/listinfo/use-livecode
> >>
> >
> >
> >
> > --
> > On the first day, God created the heavens and the Earth
> > On the second day, God created the oceans.
> > On the third day, God put the animals on hold for a few hours,
> >   and did a little diving.
> > And God said, "This is good."
> > _______________________________________________
> > use-livecode mailing list
> > [hidden email]
> > Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



--
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTML5 deployment: progress comes into sight

Klaus major-k via use-livecode
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 <[hidden email]>
wrote:

> 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 <
> [hidden email]> wrote:
>
>> Hehe - that works both ways Mike ;)
>>
>> Sent from my iPhone
>>
>> > On 2 Jun 2017, at 14:22, Mike Kerner via use-livecode <
>> [hidden email]> 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 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 use-livecode <
>> > [hidden email]> wrote:
>> >
>> >> 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: Communication between widgets
>> >>
>> >> Yes, there are intersections. Just an idea to have more 'structure'.
>> >>
>> >>
>> >> _______________________________________________
>> >> use-livecode mailing list
>> >> [hidden email]
>> >> Please visit this url to subscribe, unsubscribe and manage your
>> >> subscription preferences:
>> >> http://lists.runrev.com/mailman/listinfo/use-livecode
>> >>
>> >
>> >
>> >
>> > --
>> > On the first day, God created the heavens and the Earth
>> > On the second day, God created the oceans.
>> > On the third day, God put the animals on hold for a few hours,
>> >   and did a little diving.
>> > And God said, "This is good."
>> > _______________________________________________
>> > use-livecode mailing list
>> > [hidden email]
>> > Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> > http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>>
>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>
>
>
> --
> On the first day, God created the heavens and the Earth
> On the second day, God created the oceans.
> On the third day, God put the animals on hold for a few hours,
>    and did a little diving.
> And God said, "This is good."
>



--
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
123
Loading...