Web vs Native (was Re: HTML5 limitations?)

[jonathandlynch at gmail.com]

I thought that JS/HTML5 did not have a wait function? One can loop the engine, which is horrible, or one can set timeouts for functions. What functionality do you access to induce a wait?

Sent from my iPhone

> On Jul 28, 2017, at 8:29 PM, Mark Waddingham via use-livecode <use-livecode at lists.runrev.com> wrote:
> 
> Hi Hermann,
> 
> First of all please don't take any offence at my email as none was intended.
> 
> I was mainly trying to explain that whilst there are many things the HTML5 engine does not do, which means many stacks will not work without changes/workarounds (indeed, somewhat significant ones) - there are increasing numbers of those which do work and this is set to continue and expand as we have more time to spend on the 'surface' features as opposed to the core.
> 
>> On 2017-07-28 22:22, hh via use-livecode wrote:
>> Probably the "one" (=checking if the mouse is "down") pledged and bought a HTML5
>> license, the "at least other 2" (=never using it) didn't pledge nor
>> buy a license.
> 
> To be honest, this really is probably not true.
> 
> The thing is that 'the mouse' has long reported the event-asynchronous mouse state, which is almost never what you actually want on modern purely event-driven OSes - so over time its use has diminished as if you use it to do certain things (not all - admittedly), you will end up noticing 'interaction faults' which can be fixed by tracking mouseDown / mouseUp using the event loop. Also, it is generally used alongside 'wait' - which of course does not currently work.
> 
> Obviously you do use it, as do others, so it isn't that it is not important, just that there are lots of other things that we have been working on in the HTML5 engine first which *are* used much more widely.
> 
> It isn't actually possible to get the async mouse state on HTML5, so it will not be 100% the same (although to be fair, the approximation we can use there is probably more correct anyway). It is just a matter of time before we get it to work, not if.
> 
>> I reported to quality center in Dec 2015/Jan 2016, that the state of the mouse
>> and modifier keys aren't recognized and that all menu buttons crash
>> the standalone.
> 
> Similarly, the modifierKeys. Text entry and keyboard states for the LiveCode engine in HTML5 is another what is a seemingly 'simple' thing from the outside, but is actually not that simple at all under the hood.
> 
> We are still working on solving some issues with text entry - we will solve the problem in time, but again as with other facets of this endeavour some things are taking a lot longer than we had originally anticipated.
> 
>> Since the start of this *395 thousand dollars* project in July 2014 I made at
>> about 60 "successful tests" to show 'oh the HTML5 engine does this' and
>> 'oh it does that'. This wasn't easy at all, needed a _lot_ of workarounds ...
> 
> You've mentioned the amount of money raised several times; however, one thing which everyone has to appreciate is that every project we have crowd-funded has had the value raised matched at least by a factor of 2 from other sources (in some cases significantly more). My point here is not to undervalue the contribution that a good number of you have made, but to illustrate that the scale of the projects we have crowd-funded have been significantly larger than the dollar value we went out to the community to raise would suggest.
> 
> Indeed, we have already spent far in excess of $400k on the HTML5 project when taking into account all work that we have undertake to do it (it isn't just each line of code which is written, but also infrastructure, maintenance, systems and a huge variety of other factors almost all entirely not user/publicly visible).
> 
> There is no problem here (I assure you) - we expected it - we knew it was going to be a large, difficult project. However it is one which was, is, and remains a vital project to finish for our ecosystem as a whole and finish it will shall.
> 
>> So I'll better stop now and wait for the suitable percentage of 'unchanged'
>> LiveCode demos (although "wait" is not allowed in HTML5 deployment).
> 
> I would hope that you will continue to do as you have been - because it has been great to see many of the things you have achieved with the HTML5 engine despite its various obvious omissions in functionality. It also helps us, the engineering team, to see visible progress by users on a project which is large, long and complex (and somewhat frustrating at times!) - particularly when much of the work we are doing, and have been doing is entirely non-user visible!
> 
>> What the team made in HTML deployment until now is *very* good, especially the
>> "do as javascript" part is excellent. Just put more of the funds (and by that
>> 'bandwidth') into it, so that also basic things (e.g. typing UTF-8 into a field)
>> do work.
> 
> Getting two way communication working in the HTML5 engine has been a significant step forward. Particularly as it means we can now do the absolute minimum in JavaScript and much more in LiveCode Script (what's the point of engineering a language, if one does not use it oneself, after all!).
> 
> Indeed, I envisage a good deal of the engine functionality we need to still implement relative to JavaScript should start being able to be done in LiveCode Script - the networking stuff Michael has been working on, is an implementation of libUrl in LiveCode Script and uses the JavaScript interoperation features we have to provide its services.
> 
>> p.s. HTML5 standalones can talk to each other, several of them, in one browser
>> window. I just successfully tested that --- and trashed the demo.
> 
> This sounds very interesting in-and-of itself (perhaps not the trashing part - please file a bug report if you can / have time to isolate the issue!).
> 
> Warmest Regards,
> 
> Mark.
> 
> P.S. At some point I'll write at length about the 'wait' problem in HTML5. Whilst I try not to let myself be kept awake at night by engineering problems related to work - if ever there was one which did, it would be that one!
> 
> -- 
> Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
> 
> _______________________________________________
> 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