Re: HTML5 deployment: progress comes into sight

[hh via use-livecode]

> k wrote:
> I'd like to be able to integrate LC's HTML5 output with regular web page 
> structures a little more flexibly. That's been one of the big things 
> that's really put me off trying out much with this form of output, so 
> far at least.

You can do that since November 2016 (LC 9.0.0-dp2)

function jsExecute str
  do str as "javascript"
  return the result
end jsExecute

This is hard to debug because it works in the standalone only (although one
can test the javascript in a browser widget).

Starting with LC9.0.0-dp7 it is even much more easier to do that, as you can
now use "callbacks" (javascriptHandlers), see 9.0.0-dp7 releaseNotes pp 9-10.

The 9.0.0-dp4 standalones
 Do as JS (Basic test), LCImageToolbox_Basic, Video-Fun, SVGtoPNG
of my HTML5-examples use javascript within the webpage.
It is explained in LC's HTML5 subforum thread "Succesfull tests" how to get
the source code of these examples.

___
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

Re: HTML5 deployment: progress comes into sight

[hh via use-livecode]

Hi k.

All special info I have is from here (and links there):

https://en.wikipedia.org/wiki/Same-origin_policy

And I know, from my own sad experience, that one has to try
to follow the most strict interpretation, as browsers differ
in their implemementation and even the same browser from one
major version to its next major version.

hh

> > hh wrote:

> > if the webpage starts with "hyperhh.de" then the images have to be
> > called explicitly from hyperhh.de while download from "hyperhh.org"
> > (which is simply another name for the same domain) fails.
> 
> k wrote:
> Thanks for the example! Re the domain thing, I'd regard [x].de and 
> [x].org as being different for anything sensitive to cross-domain use. 
> Do you know if it's fussy about subdomains, for example www.[x].de, 
> web.[x].de and [x].de?
> 
> I'd like to be able to integrate LC's HTML5 output with regular web page 
> structures a little more flexibly. That's been one of the big things 
> that's really put me off trying out much with this form of output, so 
> far at least.
> 
> k

___
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

Re: HTML5 deployment: progress comes into sight

[Keith Martin via use-livecode]

On 16 Jun 2017, at 5:15, hh via use-livecode wrote:


if the webpage starts with "hyperhh.de" then the images have to be
called explicitly from hyperhh.de while download from "hyperhh.org"
(which is simply another name for the same domain) fails.


Thanks for the example! Re the domain thing, I'd regard [x].de and 
[x].org as being different for anything sensitive to cross-domain use. 
Do you know if it's fussy about subdomains, for example www.[x].de, 
web.[x].de and [x].de?


I'd like to be able to integrate LC's HTML5 output with regular web page 
structures a little more flexibly. That's been one of the big things 
that's really put me off trying out much with this form of output, so 
far at least.


k


---

Keith Martin
Senior Lecturer, LCC (University of the Arts London)
Technical Editor, MacUser magazine (1997-2015)
http://PanoramaPhotographer.com
http://thatkeith.com
+44 (0)7909541365

---
___
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

Re: HTML5 deployment: progress comes into sight

[hh via use-livecode]

A basic test of the new feature "fetchURL" of the LC 9.0.0-dp7
HTML5 standalone builder: Load files (here images) from a server.
The load origin has to be on the same domain as the webpage that
loads the standalone.

(EU) http://hyperhh.de/html5/testFetch-9.0.0-dp-7X.html
(US) http://hh.on-rev.com/html5/testFetch-9.0.0-dp-7X.html

Note for your own trials:
Even different virtual adresses let the download fail. For example
if the webpage starts with "hyperhh.de" then the images have to be
called explicitly from hyperhh.de while download from "hyperhh.org"
(which is simply another name for the same domain) fails.
You may try that by your own with the first link above.

___
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

Re: HTML5 deployment: progress comes into sight

[hh via use-livecode]

Yet another creative contribution to this thread: SVGtoPNG_HTML5

This is a HTML5 standalone that is based on stacks that Jonathan and I made,
see livecodeshare.runrev.com or 'Sample stacks' (the stacks use a clever
conversion idea of Jonathan).

Launch SVGtoPNG_HTML5 from here:

(EU) http://hyperhh.org/html5/index-large.html#as
(US) http://hh.on-rev.com/html5/index-large.html#as

You can import your local SVGs (which will be forgotten as soon as the web
page is closed) and export to the web page, enabling the usual rightClick-
the-image-possibilities of your browser.
 
There are a few issues.
Latest Chrome and especially Opera do a very good job with even complicated
SVGs. Firefox just the same but resizes always to square shapes. Safari has
no problems with 'inkscape-style' SVGs but with some more complicated, else
it is very fast.

___
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

Re: HTML5 deployment: progress comes into sight

[hh via use-livecode]

Yet another creative contribution to this thread (beta version,
nowhere else linked for a few days).

http://hyperhh.org/html5/video-funHTML5-9.0.0-dp-4hhX.html

Video-Fun is a HTML5 standalone that communicates with the webpage
to take frames from a video and display them as image.
As we have an image and not a browser widget we can put everything
on top of it (here a digital clock) or even add some image effects
(blur, grayscale, posterize, rgb factors invert, duotone, flipH/V).

On a medium fast machine with a decent graphic card (for example
MacMini 2.5 GHz/IntelHD4000, Safari 10) we get _30 fps_ for the
display.

The sound is done by the video running in the webpage.

The timing display (for the overall actions) shouldn't go over
120 ms (if so try a faster/newer browser).



___
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

Re: HTML5 deployment: progress comes into sight

[Mark Wieder via use-livecode]

On 06/04/2017 02:53 AM, Jonathan Lynch via use-livecode wrote:

No need to loop.

Set three flags to false. After each callback comes in and the flag gets 
switched, check all three flags. After the last ones comes in, all three flag 
variables will be switched and can trigger the next action.


Nice. That's probably a better way to do that.

--
 Mark Wieder
 ahsoftw...@gmail.com

___
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

Re: HTML5 deployment: progress comes into sight

[Jonathan Lynch via use-livecode]

No need to loop.

Set three flags to false. After each callback comes in and the flag gets 
switched, check all three flags. After the last ones comes in, all three flag 
variables will be switched and can trigger the next action.

Sent from my iPhone

> On Jun 3, 2017, at 9:04 PM, Mark Wieder via use-livecode 
>  wrote:
> 
>> On 06/03/2017 06:38 PM, Sannyasin Brahmanathaswami via use-livecode wrote:
>> 
>> Fascinating solution for X no of use cases, where you don't really need 
>> *now* , but where what you really only need is to know "exactly when and 
>> what" happened, even if slightly (typically, milliseconds) after the whole 
>> series events/statements finish
> 
> Also for pseudo-parallel processing:
> 
> if you have three asynchronous processes that need to finish before you can 
> move past a certain point in a script, you can set three flag variables to 
> false, then set each individually to true in its callback handler, and loop 
> on those three variables until they're all true or you reach a timeout.
> 
> -- 
> Mark Wieder
> ahsoftw...@gmail.com
> 
> ___
> 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

Re: HTML5 deployment: progress comes into sight

[Mark Wieder via use-livecode]

On 06/03/2017 06:38 PM, Sannyasin Brahmanathaswami via use-livecode wrote:


Fascinating solution for X no of use cases, where you don't really need *now* , but where 
what you really only need is to know "exactly when and what" happened, even if 
slightly (typically, milliseconds) after the whole series events/statements finish


Also for pseudo-parallel processing:

if you have three asynchronous processes that need to finish before you 
can move past a certain point in a script, you can set three flag 
variables to false, then set each individually to true in its callback 
handler, and loop on those three variables until they're all true or you 
reach a timeout.


--
 Mark Wieder
 ahsoftw...@gmail.com

___
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

Re: HTML5 deployment: progress comes into sight

[Sannyasin Brahmanathaswami via use-livecode]

Mark Wieder wrote:

Requests are sent asynchronously and trigger a callback message when 
they're done. The callback message payload contains a reference to the 
message that called it. That way a callback handler can associate the 
returned message with the calling handler, and if needed a wait loop can 
implement a procedural pseudo-synchronous call.

Fascinating solution for X no of use cases, where you don't really need *now* , 
but where what you really only need is to know "exactly when and what" 
happened, even if slightly (typically, milliseconds) after the whole series 
events/statements finish 

BR


___
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

Re: HTML5 deployment: progress comes into sight

[Mark Wieder via use-livecode]

On 05/31/2017 02:35 PM, hh via use-livecode wrote:

"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.


I had a similar need in PowerDebug in order to handle asynchronous 
events over socket connections for remote debugging. And dealt with it 
thusly:


Requests are sent asynchronously and trigger a callback message when 
they're done. The callback message payload contains a reference to the 
message that called it. That way a callback handler can associate the 
returned message with the calling handler, and if needed a wait loop can 
implement a procedural pseudo-synchronous call.


It's kind of the way session cookies work in a browser. It probably 
won't work for every use case, but when I need to define a statement 
order from asynchronous events it does the trick.


--
 Mark Wieder
 ahsoftw...@gmail.com

___
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

Re: HTML5 deployment: progress comes into sight

[Sannyasin Brahmanathaswami via use-livecode]

Just getting back here after  a week away on another project where they are 
moving the Hinduism Today app to an HTML 5 platform

(shameless promotion) check it out… pretty cool  release (free) on the App 
store… Android version is buggy.

@ Roland: Right.. my use of "Syncronous" was  a bit off, more like asynchronous 
w/ wait  (see below)

@ HH Thank you. Your clarification is perfect, exactly our challenge, well 
defined.

I think the use cases are obvious: Assuming we want to

a)  "encapsulate" all the heavy lifting to "*models*.livecode" scripts that do 
the hard work
b) we use the browser widget as a canvas for views  small triggers.

you would want to be able to, for example have a user enter some year  (say 
date of birth) in a little browser widget form thing.

submit to the "model.livecode" script  and if they entered something stupid like

2620  instead of 2062

your data input validator would reply to the brower widget (which must somehow 
know to halt processing) and reply to the user

"Hey, No way you were born in 2620!"
---
AND During development… let's say the user did enter 2062, it pass validation, 
but the model.livecode attempt to store it in the sqllite database fails 
because some error in your LC code… we need a feedback loop that can tell us 
exactly at one point in the JS execution the failure occurred.  because, who 
knows… maybe you passed a bad param in the JS.. 

Mark: check out my earlier business request… at the risk of starting a flame 
war over LC's attempts for revenues from the existing paid user base, "you all" 
might consider taken that dollar value quoted to me and posting is as a "reach 
goal"  You might find support.

BR: 

FWIW  I will copy here : this is the distillation requirements  as sent back to 
me, since they detail some of the difficulty faced. 

minus the $ value attached to quotation

--
Requirements

Enhance the current browser handler feature, allowing LiveCode handlers called 
from JavaScript to return a value immediately to the calling code. This 
requires the LC handlers to be executed synchronously - the calling code will 
block until the LC handler completes and its value is returned.


Platforms

1)   Android
JavaScript calls are executed on a separate thread owned by the WebView - 
getting a return value requires posting the handler execution request to the 
event queue, yielding to the engine thread, which must execute the handler and 
store the result in such a way that it is accessible once control is returned 
to the waiting WebView thread.


2)   iOS & MacOS
May be the simplest to deal with - the handler callback is either executed on 
the engine thread, or may call a function to run code blocks on the engine 
thread. What will be required though is to modify the current scheme of posting 
a handler execution message on the event queue to execute the handler directly 
so the return value can be obtained

3)   CEF
JavaScript calls are executed within the CEF render process, so calling LC 
handlers requires communicating with the main engine process. CEF provides an 
inter-process communication (IPC) mechanism, however it is designed only for 
asynchronous message sending so waiting for a return value or reply is not 
supported.

In order to provide synchronous execution of LC handlers, an alternative IPC 
mechanism will be needed that should not interfere with the existing CEF 
scheme. Named pipes are a good implementation candidate on both Windows and 
Linux, however they would need to be integrated into the event handling loops 
on both platforms.

4)   Execution Restrictions (Optional)
Depending on the implementation, there may be some operations that are unsafe 
to call from within the executing handler. For the CEF implementation, this 
will almost certainly include access to browser properties that require 
communication with the render process. There are several other areas in the 
engine where certain classes of operation are prohibited, for example within a 
widget’s OnPaint handler any operations that use “wait” should be avoided. It 
may be useful then to implement a general purpose execution restrictions 
mechanism to throw an error in these situations rather than allow these risky 
operations to occur.

 
To implement items 1 to 3 the time estimate is about 14 days of work at a cost 
of $ For the optional item 4 it would require another 8 days of work at …..$
 
--

 

On 5/31/17, 11:35 AM, "use-livecode on behalf of hh via use-livecode" 
 wrote:

"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 

Re: HTML5 deployment: progress comes into sight

[Mark Talluto via use-livecode]

> On Jun 2, 2017, at 3:02 PM, hh via use-livecode 
>  wrote:
> 
> Simply a creative contribution to this thread:
> 
> Here are direct links. Worth waiting for loading, it's faster than you
> expect. (Also loading times has been essentially improved with my tests).
> 
> [EU] http://hyperhh.org/html5/LCImageToolboxHTML5-9.0.0-dp-4hhX.html
> [US] http://hh.on-rev.com/html5/LCImageToolboxHTML5-9.0.0-dp-4hhX.html
> 
> The timing you see are the LC-times, not the screen update of the browsers
> which is of course slower while a browser is caching large imageData.
> 
> Latest Safari and Chrome Canary (but not yet Chrome) are fastest with
> the screen updates. Also tested to be OK here with latest Firefox and
> latest Opera. As always: doesn't run in IE/Edge.
> 
> (It was tedious to work around the missing javascriptHandler in HTML5
> deployment, we look forward to that feature Mark!)

Very inspirational work. 


Best regards,

Mark Talluto
livecloud.io 
nursenotes.net 
canelasoftware.com 

___
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

Re: HTML5 deployment: progress comes into sight

[hh via use-livecode]

Simply a creative contribution to this thread:

Here are direct links. Worth waiting for loading, it's faster than you
expect. (Also loading times has been essentially improved with my tests).

[EU] http://hyperhh.org/html5/LCImageToolboxHTML5-9.0.0-dp-4hhX.html
[US] http://hh.on-rev.com/html5/LCImageToolboxHTML5-9.0.0-dp-4hhX.html

The timing you see are the LC-times, not the screen update of the browsers
which is of course slower while a browser is caching large imageData.

Latest Safari and Chrome Canary (but not yet Chrome) are fastest with
the screen updates. Also tested to be OK here with latest Firefox and
latest Opera. As always: doesn't run in IE/Edge.

(It was tedious to work around the missing javascriptHandler in HTML5
deployment, we look forward to that feature Mark!)

___
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

Re: HTML5 deployment: progress comes into sight

[Mike Kerner 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 
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 <
> use-livecode@lists.runrev.com> wrote:
>
>> Hehe - that works both ways Mike ;)
>>
>> Sent from my iPhone
>>
>> > On 2 Jun 2017, at 14:22, Mike Kerner via use-livecode <
>> use-livecode@lists.runrev.com> 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 <
>> > use-livecode@lists.runrev.com> 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
>> >> 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
>> >>
>> >
>> >
>> >
>> > --
>> > 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
>> > 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
>>
>
>
>
> --
> 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
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

Re: HTML5 deployment: progress comes into sight

[Mike Kerner 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 <
use-livecode@lists.runrev.com> wrote:

> Hehe - that works both ways Mike ;)
>
> Sent from my iPhone
>
> > On 2 Jun 2017, at 14:22, Mike Kerner via use-livecode <
> use-livecode@lists.runrev.com> 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 <
> > use-livecode@lists.runrev.com> 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
> >> 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
> >>
> >
> >
> >
> > --
> > 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
> > 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
>



-- 
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
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

Re: HTML5 deployment: progress comes into sight

[Mark Waddingham 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 
>  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 <
> use-livecode@lists.runrev.com> 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
>> 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
>> 
> 
> 
> 
> -- 
> 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
> 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

Re: HTML5 deployment: progress comes into sight

[Mike Kerner 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 <
use-livecode@lists.runrev.com> 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
> 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
>



-- 
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
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

Re: HTML5 deployment: progress comes into sight

[hh 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
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

Re: HTML5 deployment: progress comes into sight

[Mark Waddingham 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 
>  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" <
> use-livecode@lists.runrev.com> 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 <
>> use-livecode@lists.runrev.com> 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
>>> ahsoftw...@gmail.com
>>> 
>>> 
>>> ___
>>> 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
>>> 
>> 
>> 
>> 
>> --
>> http://www.andregarzia.com -- All We Do Is Code.
>> http://fon.nu -- minimalist url shortening service.
>> ___
>> 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


___
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

Re: HTML5 deployment: progress comes into sight

[Mark Waddingham 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 
>  wrote:
> 
> 
>> On 1 Jun 2017, at 8:27 pm, Mark Waddingham via use-livecode 
>>  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@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

Re: HTML5 deployment: progress comes into sight

[Dan Brown 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" <
use-livecode@lists.runrev.com> 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 <
> use-livecode@lists.runrev.com> 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
> >  ahsoftw...@gmail.com
> >
> >
> > ___
> > 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
> >
>
>
>
> --
> http://www.andregarzia.com -- All We Do Is Code.
> http://fon.nu -- minimalist url shortening service.
> ___
> 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

Re: HTML5 deployment: progress comes into sight

[Andre Garzia 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 <
use-livecode@lists.runrev.com> 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
>  ahsoftw...@gmail.com
>
>
> ___
> 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
>



-- 
http://www.andregarzia.com -- All We Do Is Code.
http://fon.nu -- minimalist url shortening service.
___
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

Re: HTML5 deployment: progress comes into sight

[Mark Wieder 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
 ahsoftw...@gmail.com

___
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

Re: HTML5 deployment: progress comes into sight

[Monte Goulding via use-livecode]

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

Re: HTML5 deployment: progress comes into sight

[hh 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
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

Re: HTML5 deployment: progress comes into sight

[hh 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 
useHandler "drawImage" of  with parameter 
-- stop using 


___
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

Re: HTML5 deployment: progress comes into sight

[Roland Huettmann via use-livecode]

Yes, I agree. Thanks a lot. ) Roland

On May 31, 2017 19:07,  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 <
> use-livecode@lists.runrev.com> 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
> > 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

Re: HTML5 deployment: progress comes into sight

[Mark Waddingham 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 ~ 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

Re: HTML5 deployment: progress comes into sight

[Roger Eller 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" <
use-livecode@lists.runrev.com> 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  
>>callHandler  
>>dispatchHandler  
>>doHandler  ?
>>
>
> 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 

Re: HTML5 deployment: progress comes into sight

[Mark Waddingham 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  
   callHandler  
   dispatchHandler  
   doHandler  ?


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 

Re: HTML5 deployment: progress comes into sight

[hh 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
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

Re: HTML5 deployment: progress comes into sight

[hh 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  
   callHandler  
   dispatchHandler  
   doHandler  ?

We could still have

   do 

Re: HTML5 deployment: progress comes into sight

[Richmond Mathewson 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
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

Re: HTML5 deployment: progress comes into sight

[Mark Waddingham via use-livecode]

On 2017-05-31 15:43, hh via use-livecode 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.


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

Re: HTML5 deployment: progress comes into sight

[Jonathan Lynch via use-livecode]

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 
>  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
> 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

Re: HTML5 deployment: progress comes into sight

[Roland Huettmann via use-livecode]

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

Re: HTML5 deployment: progress comes into sight

[hh via use-livecode]

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

Yes and No. I tried that extensively several weeks ago. Of course I can "do"
the js I need in the webpage that 'surrounds the standalone-canvas as we have
full control on that page. This is close to what we can do in a browser widget.

The problem is the "one-way"-only:
I can't see any way to go back, from the page to the standalone.

= 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?


___
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

Re: HTML5 deployment: progress comes into sight

[Mark Waddingham via use-livecode]

On 2017-05-31 14:30, Jonathan Lynch via use-livecode wrote:

Would it be possible to create a widget that links to an Inkscape
library that processes svg data and sends it back to the widget to be
displayed the way PNG is displayed?


No - two issues:

  1) Inkscape is an application - not a C library.

  2) Inkscape is GPL - therefore any solution involving it would be 
unusable in commercial.


FWIW I don't believe there are any complete open-source SVG C/C++ 
library implementations which are not GPL - but would be happy to be 
proved wrong.


Obviously WebKit has an implementation, but it is part of WebKit and not 
exposed as an independent component as far as I'm aware.


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

Re: HTML5 deployment: progress comes into sight

[Mark Waddingham via use-livecode]

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.

--
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

Re: HTML5 deployment: progress comes into sight

[Jonathan Lynch via use-livecode]

Would it be possible to create a widget that links to an Inkscape library that 
processes svg data and sends it back to the widget to be displayed the way PNG 
is displayed?

Sent from my iPhone

> On May 31, 2017, at 7:18 AM, Richmond Mathewson via use-livecode 
>  wrote:
> 
> Weel you could start with ALL SVG images made in Inkscape: monochromatic 
> "thingies" have limited use.
> 
> Richmond.
> 
>> On 5/31/17 11:48 am, Mark Waddingham via use-livecode wrote:
>>> On 2017-05-31 10:38, Jonathan Lynch via use-livecode wrote:
>>> A native svg object that accurately displays all svg files is
>>> essential. I strongly support Mark's point on that issue. This is not
>>> reinventing the wheel - it's attaching the already invented wheel to
>>> the wagon.
>> 
>> Heh - well more accurately - attaching a LiveCode-compatible instance of the 
>> already invented wheel pattern to the LiveCode wagon ;)
>> 
>> Accurately displaying *all* SVG files might take quite a while (SVG is quite 
>> a large standard) - however, there are smaller subsets (Basic/Tiny) which 
>> cover the 'icon' use-case sufficiently. So they are a good place to start.
>> 
>> Warmest Regards,
>> 
>> Mark.
>> 
> 
> ___
> 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

Re: HTML5 deployment: progress comes into sight

[Richmond Mathewson via use-livecode]

Weel you could start with ALL SVG images made in Inkscape: monochromatic 
"thingies" have limited use.


Richmond.

On 5/31/17 11:48 am, Mark Waddingham via use-livecode wrote:

On 2017-05-31 10:38, Jonathan Lynch via use-livecode wrote:

A native svg object that accurately displays all svg files is
essential. I strongly support Mark's point on that issue. This is not
reinventing the wheel - it's attaching the already invented wheel to
the wagon.


Heh - well more accurately - attaching a LiveCode-compatible instance 
of the already invented wheel pattern to the LiveCode wagon ;)


Accurately displaying *all* SVG files might take quite a while (SVG is 
quite a large standard) - however, there are smaller subsets 
(Basic/Tiny) which cover the 'icon' use-case sufficiently. So they are 
a good place to start.


Warmest Regards,

Mark.



___
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

Re: HTML5 deployment: progress comes into sight

[Mark Waddingham via use-livecode]

On 2017-05-31 10:38, Jonathan Lynch via use-livecode wrote:

A native svg object that accurately displays all svg files is
essential. I strongly support Mark's point on that issue. This is not
reinventing the wheel - it's attaching the already invented wheel to
the wagon.


Heh - well more accurately - attaching a LiveCode-compatible instance of 
the already invented wheel pattern to the LiveCode wagon ;)


Accurately displaying *all* SVG files might take quite a while (SVG is 
quite a large standard) - however, there are smaller subsets 
(Basic/Tiny) which cover the 'icon' use-case sufficiently. So they are a 
good place to start.


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

Re: HTML5 deployment: progress comes into sight

[Jonathan Lynch via use-livecode]

A native svg object that accurately displays all svg files is essential. I 
strongly support Mark's point on that issue. This is not reinventing the wheel 
- it's attaching the already invented wheel to the wagon.

Sent from my iPhone

> On May 31, 2017, at 4:26 AM, Mark Waddingham via use-livecode 
>  wrote:
> 
>> On 2017-05-31 09:01, Dan Brown via use-livecode wrote:
>> I'll also add that for all the wonderful possibilities that LCB brings
>> there is a very real danger that countless hours will be spent using it to
>> re-invent the wheel.
> 
> That is true of every language ever implemented ;)
> 
> However, one of the goals of LCB is to allow it to be used as the 'glue' 
> language allowing LiveCode Script to access 'things written in other 
> languages' with (eventually) as much syntactic fidelity as you get with 
> builtin-in engine functionality. Hopefully, reducing the need to re-invent 
> the wheel to the minimum required to make other-world libraries look more 
> LiveCode like.
> 
> i.e. One of its main goals is to rid ourselves of the need to 're-invent the 
> wheel'.
> 
>> Take for instance the displaying of svg's. This is a solved problem in the
>> browser and has been for a long time but in native livecode it's still in
>> the infant stages of implementation (to put it mildly). The best solutions
>> for user interface "widgets" are arguably being created in the form of
>> javascript libraries. To me it makes total sense to integrate with that
>> ecosystem and free up LCB / livecode developer hours for solving other
>> problems
> 
> True - but then if I want SVG icons in my app, and I don't need the browser 
> widget at all then I might balk at the 70-100Mb bloat I have to add to 
> Windows / Linux apps to get it. Furthermore, I might balk at the start up 
> time of my app on mobile devices, whilst I use the browser widget to load all 
> my SVGs and render them into PNGs at various sizes (unless you instantiate a 
> browser widget for every SVG icon you want to use and want to put up with the 
> restrictions that places on you, and the overhead in terms of use).
> 
> Certainly we need to be careful about 're-inventing the wheel' but that just 
> means making good choices. In this case, the case for 'native' SVG support in 
> LiveCode is overwhelming - the more lightweight it is, the faster it is, the 
> more utility it has. (Also, the main problem here is 'SVG as a replacement 
> for PNG icons' which is a much smaller problem to solve than an editable SVG 
> canvas - which is what you get if you go the via-browser route).
> 
> In terms of JavaScript 'widgets' in general, then we already have a 
> reasonable strategy for using them now - you use a browser widget and load it 
> in there. For example, FileMaker has a BrowserView element and there is a 
> plugin 'React' which allows you to defined JavaScript controls and have them 
> rendered in the browser. Admittedly using such things is a little trickier 
> than we'd like at present - due to the lack of synchronous 'do as javascript'.
> 
> Anyway, I agree that using existing libraries and code as much as possible is 
> probably the best way to expand LiveCode's capabilities - hence LCB :)
> 
> 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

___
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

Re: HTML5 deployment: progress comes into sight

[Mark Waddingham via use-livecode]

On 2017-05-31 04:31, Sannyasin Brahmanathaswami via use-livecode wrote:

Does this relate at all to " LCB to bind to  JavaScript APIs" ?


Directly? No - they are two distinct things.

However, running JavaScript (via LCB) in the HTML5 engine is equivalent 
to running JavaScript (via LCB) in a browser widget... The only 
'difference' being in the latter it happens in the browser widget you 
say, as opposed to the browser running the (HTML5) engine. Of course, 
making good use of LCB JavaScript bindings is contingent on having 
synchronous JS execution - which we have in the HTML5 engine (due to how 
it is implemented), but we don't with the browser widget (due to how the 
embedded browsers we use work).


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

Re: HTML5 deployment: progress comes into sight

[Mark Waddingham via use-livecode]

On 2017-05-31 09:01, Dan Brown via use-livecode wrote:

I'll also add that for all the wonderful possibilities that LCB brings
there is a very real danger that countless hours will be spent using it 
to

re-invent the wheel.


That is true of every language ever implemented ;)

However, one of the goals of LCB is to allow it to be used as the 'glue' 
language allowing LiveCode Script to access 'things written in other 
languages' with (eventually) as much syntactic fidelity as you get with 
builtin-in engine functionality. Hopefully, reducing the need to 
re-invent the wheel to the minimum required to make other-world 
libraries look more LiveCode like.


i.e. One of its main goals is to rid ourselves of the need to 're-invent 
the wheel'.


Take for instance the displaying of svg's. This is a solved problem in 
the
browser and has been for a long time but in native livecode it's still 
in
the infant stages of implementation (to put it mildly). The best 
solutions

for user interface "widgets" are arguably being created in the form of
javascript libraries. To me it makes total sense to integrate with that
ecosystem and free up LCB / livecode developer hours for solving other
problems


True - but then if I want SVG icons in my app, and I don't need the 
browser widget at all then I might balk at the 70-100Mb bloat I have to 
add to Windows / Linux apps to get it. Furthermore, I might balk at the 
start up time of my app on mobile devices, whilst I use the browser 
widget to load all my SVGs and render them into PNGs at various sizes 
(unless you instantiate a browser widget for every SVG icon you want to 
use and want to put up with the restrictions that places on you, and the 
overhead in terms of use).


Certainly we need to be careful about 're-inventing the wheel' but that 
just means making good choices. In this case, the case for 'native' SVG 
support in LiveCode is overwhelming - the more lightweight it is, the 
faster it is, the more utility it has. (Also, the main problem here is 
'SVG as a replacement for PNG icons' which is a much smaller problem to 
solve than an editable SVG canvas - which is what you get if you go the 
via-browser route).


In terms of JavaScript 'widgets' in general, then we already have a 
reasonable strategy for using them now - you use a browser widget and 
load it in there. For example, FileMaker has a BrowserView element and 
there is a plugin 'React' which allows you to defined JavaScript 
controls and have them rendered in the browser. Admittedly using such 
things is a little trickier than we'd like at present - due to the lack 
of synchronous 'do as javascript'.


Anyway, I agree that using existing libraries and code as much as 
possible is probably the best way to expand LiveCode's capabilities - 
hence LCB :)


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

Re: HTML5 deployment: progress comes into sight

[Mark Waddingham via use-livecode]

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 ' which we 
do need to rectify (somehow) at somepoint - for a similar reason so that 
we can actually have 'do in ' 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

Re: HTML5 deployment: progress comes into sight

[hh via use-livecode]

The browser widget is essentially kind of a GUI to libbrowser, cleverly made.

@Dan
Using all these js libraries is already possible (where the inherent HTML5 of
the widget allows that -- different by platform), just do it.
Examples of going that way are among the most recent 10 of "Sample stacks".

@BR
If you write the HTML5 by yourself you can send messages to LC or events like 
the
clickLoc or the mouseLoc when "hovering" the browser, also when clicking 
"buttons"
of an  element. I'll give a demo of that soon in the LC Builder forum.

What's very difficult, as you write in detail, are "callbacks" for _synchronous_
communication. You can have that also but have to code a lot (in javascript).
That's not a problem of the LC side. But it could be made much more easy to 
handle
by building such things into libbrowser, then usable directly from LC Script. 
And
it would make a lot of js synchronous (and by that very slow ...).

---

If I understand correctly Mark speaks currently about
[1] using a browser widget within the _HTML5 deployment_ (emscripten).
[2] using via FFI javascript or (part of) libbrowser _within_ LC Builder.

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.

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).

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?


___
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

Re: HTML5 deployment: progress comes into sight

[Dan Brown via use-livecode]

I'll also add that for all the wonderful possibilities that LCB brings
there is a very real danger that countless hours will be spent using it to
re-invent the wheel.

Take for instance the displaying of svg's. This is a solved problem in the
browser and has been for a long time but in native livecode it's still in
the infant stages of implementation (to put it mildly). The best solutions
for user interface "widgets" are arguably being created in the form of
javascript libraries. To me it makes total sense to integrate with that
ecosystem and free up LCB / livecode developer hours for solving other
problems

Hopefully soon I'll see this in my inbox

"Livecode brings the power of javascript to native mobile and desktop
apps"



On 31 May 2017 5:35 am, "Dan Brown"  wrote:

> JavaScript via the browser would be huge. There are tens of thousands of
> JavaScript libraries that could be used by livecoders to add bleeding edge
> UI elements  & websockets to their applications via lc script. It would
> allow livecode to communicate with the real-time web  without lcb ( which
> only a small percentage of the community are able to utilise)
>
> On 31 May 2017 3:32 am, "Sannyasin Brahmanathaswami via use-livecode" <
> use-livecode@lists.runrev.com> wrote:
>
>> mark Waddington wrote:
>>
>> We've also been looking at how to abstract the FFI work we've done as
>> part of the Infinite LiveCode campaign to allow LCB to bind to
>> JavaScript
>> APIs (which will allow greater type fidelity than is possible using
>> 'do as javascript' from LCS).
>>
>> BR:
>>
>> I don't understand the above well enough to know if this is even related…
>> but the need has not gone away. At the risk of "going on and on again"
>> about this again.
>>
>> What I would find much more useful (may it is just me) is to get the
>> javascript of the html5 code running in a browser widget to be a "member in
>> good standing" of LC message hierarchy inside an LC build (not the other
>> way around)
>>
>> I can get any number of developers from around the planet to build any
>> kind of "HTML5" thing for our web site and it would run faster (no
>> emscripten download required), be better designed in the long run than some
>> "transform" of a Livecode stack to HTML5.
>>
>> At least in my universe, use cases for pushing LC apps to HTML5 in the
>> browser are very few. For us here, and I would think for a "legion" of
>> developers who are vested first in the LC app platform and html5 second,
>> what we need is for the run time, synchronous communications between the JS
>> in the browser widget and the LS message path.
>>
>> What I *really* want is to leverage the web kit graphics engine so that
>> we look at the HTML5 Canvas/JS like some kind of "media toolbox" for
>> building content. So, like Photoshop just offered today tutorials on
>> building animated gifs, which we can then obviously use in LC. Similarly I
>> want HTML5 "kids" working for me to build content that I can turn around
>> and then running inside Livecode with the LC scripts and the JS "talking to
>> each other" intelligently and in a timely way. (javascript calls a
>> function, LC hears this and returns the data, JS proceeds… even simple
>> things like someone does something in the browser widget… data is then
>> saved by the LC back end script to SqlLite Dbase and returns a "success"
>>  like a kind of "dispatch" call from the JS to the LC scripts that wrap the
>> widget.
>>
>> Jonathan runs Google earth "for God sake" in a browser widget.  Another
>> man on our team created an app using ionic/angular that is now on the
>> stores. Just for "kicks" I extract the core and it ran perfectly inside a
>> LC stack/Browser Widget. But… I can't get that to talk to LC… except with
>> the primitive calls we now have.
>>
>> then, for $35.00 someone who is a JS jockey can write some cool animation
>> in HYPE and and I can drop this into
>>
>> myapp
>>   mainstack.livecode
>>/animations
>> /hype-html5-animation
>>
>> and run the latter inside the mainstack.
>>
>> We have discussed this at length before and HH and Jonathan are way ahead
>> of me on these initiatives. My query on the business channel resulted in
>> $7,000.00 price tag to get that job done, $13,000.00 if we wanted robust
>> error checking included.  I realize to some of us here that may seem like a
>> lot, but I can respect the hours-to-get-it-done-must-be-covered
>> requirements. I had hope we might get a "kick starter" going with a number
>> of us kicking in some $  for this… I could probably get permission to spend
>> from our shoe string budgets:  $1,500 at least… but no one else here
>> responded. So I guess My idea that others could use this was a "fantasy" ??
>>
>> Does this relate at all to " LCB to bind to  JavaScript APIs" ?
>>
>> Brahmanathaswami
>>
>>
>>
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please 

Re: HTML5 deployment: progress comes into sight

[Dan Brown via use-livecode]

JavaScript via the browser would be huge. There are tens of thousands of
JavaScript libraries that could be used by livecoders to add bleeding edge
UI elements  & websockets to their applications via lc script. It would
allow livecode to communicate with the real-time web  without lcb ( which
only a small percentage of the community are able to utilise)

On 31 May 2017 3:32 am, "Sannyasin Brahmanathaswami via use-livecode" <
use-livecode@lists.runrev.com> wrote:

> mark Waddington wrote:
>
> We've also been looking at how to abstract the FFI work we've done as
> part of the Infinite LiveCode campaign to allow LCB to bind to
> JavaScript
> APIs (which will allow greater type fidelity than is possible using
> 'do as javascript' from LCS).
>
> BR:
>
> I don't understand the above well enough to know if this is even related…
> but the need has not gone away. At the risk of "going on and on again"
> about this again.
>
> What I would find much more useful (may it is just me) is to get the
> javascript of the html5 code running in a browser widget to be a "member in
> good standing" of LC message hierarchy inside an LC build (not the other
> way around)
>
> I can get any number of developers from around the planet to build any
> kind of "HTML5" thing for our web site and it would run faster (no
> emscripten download required), be better designed in the long run than some
> "transform" of a Livecode stack to HTML5.
>
> At least in my universe, use cases for pushing LC apps to HTML5 in the
> browser are very few. For us here, and I would think for a "legion" of
> developers who are vested first in the LC app platform and html5 second,
> what we need is for the run time, synchronous communications between the JS
> in the browser widget and the LS message path.
>
> What I *really* want is to leverage the web kit graphics engine so that we
> look at the HTML5 Canvas/JS like some kind of "media toolbox" for building
> content. So, like Photoshop just offered today tutorials on building
> animated gifs, which we can then obviously use in LC. Similarly I want
> HTML5 "kids" working for me to build content that I can turn around and
> then running inside Livecode with the LC scripts and the JS "talking to
> each other" intelligently and in a timely way. (javascript calls a
> function, LC hears this and returns the data, JS proceeds… even simple
> things like someone does something in the browser widget… data is then
> saved by the LC back end script to SqlLite Dbase and returns a "success"
>  like a kind of "dispatch" call from the JS to the LC scripts that wrap the
> widget.
>
> Jonathan runs Google earth "for God sake" in a browser widget.  Another
> man on our team created an app using ionic/angular that is now on the
> stores. Just for "kicks" I extract the core and it ran perfectly inside a
> LC stack/Browser Widget. But… I can't get that to talk to LC… except with
> the primitive calls we now have.
>
> then, for $35.00 someone who is a JS jockey can write some cool animation
> in HYPE and and I can drop this into
>
> myapp
>   mainstack.livecode
>/animations
> /hype-html5-animation
>
> and run the latter inside the mainstack.
>
> We have discussed this at length before and HH and Jonathan are way ahead
> of me on these initiatives. My query on the business channel resulted in
> $7,000.00 price tag to get that job done, $13,000.00 if we wanted robust
> error checking included.  I realize to some of us here that may seem like a
> lot, but I can respect the hours-to-get-it-done-must-be-covered
> requirements. I had hope we might get a "kick starter" going with a number
> of us kicking in some $  for this… I could probably get permission to spend
> from our shoe string budgets:  $1,500 at least… but no one else here
> responded. So I guess My idea that others could use this was a "fantasy" ??
>
> Does this relate at all to " LCB to bind to  JavaScript APIs" ?
>
> Brahmanathaswami
>
>
>
> ___
> 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

Re: HTML5 deployment: progress comes into sight

[Sannyasin Brahmanathaswami via use-livecode]

mark Waddington wrote:

We've also been looking at how to abstract the FFI work we've done as
part of the Infinite LiveCode campaign to allow LCB to bind to 
JavaScript
APIs (which will allow greater type fidelity than is possible using
'do as javascript' from LCS).

BR:

I don't understand the above well enough to know if this is even related… but 
the need has not gone away. At the risk of "going on and on again" about this 
again.

What I would find much more useful (may it is just me) is to get the javascript 
of the html5 code running in a browser widget to be a "member in good standing" 
of LC message hierarchy inside an LC build (not the other way around) 

I can get any number of developers from around the planet to build any kind of 
"HTML5" thing for our web site and it would run faster (no emscripten download 
required), be better designed in the long run than some "transform" of a 
Livecode stack to HTML5.

At least in my universe, use cases for pushing LC apps to HTML5 in the browser 
are very few. For us here, and I would think for a "legion" of developers who 
are vested first in the LC app platform and html5 second, what we need is for 
the run time, synchronous communications between the JS in the browser widget 
and the LS message path.

What I *really* want is to leverage the web kit graphics engine so that we look 
at the HTML5 Canvas/JS like some kind of "media toolbox" for building content. 
So, like Photoshop just offered today tutorials on building animated gifs, 
which we can then obviously use in LC. Similarly I want HTML5 "kids" working 
for me to build content that I can turn around and then running inside Livecode 
with the LC scripts and the JS "talking to each other" intelligently and in a 
timely way. (javascript calls a function, LC hears this and returns the data, 
JS proceeds… even simple things like someone does something in the browser 
widget… data is then saved by the LC back end script to SqlLite Dbase and 
returns a "success"   like a kind of "dispatch" call from the JS to the LC 
scripts that wrap the widget.

Jonathan runs Google earth "for God sake" in a browser widget.  Another man on 
our team created an app using ionic/angular that is now on the stores. Just for 
"kicks" I extract the core and it ran perfectly inside a LC stack/Browser 
Widget. But… I can't get that to talk to LC… except with the primitive calls we 
now have.

then, for $35.00 someone who is a JS jockey can write some cool animation in 
HYPE and and I can drop this into

myapp
  mainstack.livecode
   /animations
/hype-html5-animation

and run the latter inside the mainstack.

We have discussed this at length before and HH and Jonathan are way ahead of me 
on these initiatives. My query on the business channel resulted in $7,000.00 
price tag to get that job done, $13,000.00 if we wanted robust error checking 
included.  I realize to some of us here that may seem like a lot, but I can 
respect the hours-to-get-it-done-must-be-covered requirements. I had hope we 
might get a "kick starter" going with a number of us kicking in some $  for 
this… I could probably get permission to spend from our shoe string budgets:  
$1,500 at least… but no one else here responded. So I guess My idea that others 
could use this was a "fantasy" ??

Does this relate at all to " LCB to bind to  JavaScript APIs" ?

Brahmanathaswami



___
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

Re: HTML5 deployment: progress comes into sight

[Mike Kerner via use-livecode]

Any ETA on dp-7?  I have a sort-of urgent need that I hope is addressed in
7.

On Tue, May 30, 2017 at 1:25 PM, Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 2017-05-18 16:09, hh via use-livecode wrote:
>
>> [Excerpt from thread 'LC core team', now with a more approriate title.]
>>
>>> That being said, recently we are a hair's breadth away from getting
>>> widgets working in HTML5 (hopefully running a little quicker than they
>>> did before too):
>>>
>>>  https://github.com/livecode/livecode/pull/5428
>>>
>>
> I got this out of 'work-in-progress' state today - there still seem to be
> a couple of odd issues with specific widgets (the clock widget only renders
> 1 to 11, for example - not 12), however they are probably due to issues
> elsewhere
> rather than the general approach.
>
> Anyway, widgets should be coming (back?) to the HTML5 engine in 9-dp7 :)
>
> 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
>



-- 
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
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

Re: HTML5 deployment: progress comes into sight

[Mark Waddingham via use-livecode]

On 2017-05-18 16:09, hh via use-livecode wrote:

[Excerpt from thread 'LC core team', now with a more approriate title.]

That being said, recently we are a hair's breadth away from getting
widgets working in HTML5 (hopefully running a little quicker than they
did before too):

 https://github.com/livecode/livecode/pull/5428


I got this out of 'work-in-progress' state today - there still seem to 
be
a couple of odd issues with specific widgets (the clock widget only 
renders
1 to 11, for example - not 12), however they are probably due to issues 
elsewhere

rather than the general approach.

Anyway, widgets should be coming (back?) to the HTML5 engine in 9-dp7 :)

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