HTML5 deployment: progress comes into sight

[Mark Waddingham]

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 <use-livecode at lists.runrev.com> wrote:
> 
> 
>> On 1 Jun 2017, at 8:27 pm, Mark Waddingham via use-livecode <use-livecode at lists.runrev.com> 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
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode