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@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 ~ 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 _______________________________________________ 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
