HTML5 deployment: progress comes into sight

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

HTML5 deployment: progress comes into sight

hh via use-livecode
[Excerpt from thread 'LC core team', now with a more approriate title.]

> > Mark Waddingham wrote on May 18, 2017:
> > What are the consequences of that [team] change for the HTML5 deployment?
> > There was no progress with that for half a year. Is it now 'stopped'?
>
> No - it never stopped. Admittedly the last *feature* to be added to the
> HTML5 engine was 'do as javascript' (which is actually a feature which
> enables anyone who knows javascript to get the HTML5 engine to do a
> whole
> lot), but remember that the HTML5 engine is just another platform like
> any other, so work on the platform as a whole benefits HTML5 too.
>
> 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
>
> (Yes, the name of the PR sounds unrelated to HTML5, but the purpose of
> doing what it said was to get widgets working *in* HTML5 - but it has
> a couple of other fringe benefits as well - a slight performance bump
> for LCB execution in general)
>
> 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).

That sounds so great, not only all HTML5-license owners look forward to
these improvements.
Especially a javascript FFI would allow to 'connect' the HTML5 canvas
element and the LC Builder canvas object.

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

Re: HTML5 deployment: progress comes into sight

hh 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 ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

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

Re: HTML5 deployment: progress comes into sight

hh 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 <
[hidden email]> 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 ~ [hidden email] ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



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

Re: HTML5 deployment: progress comes into sight

hh via use-livecode
In reply to this post by hh 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTML5 deployment: progress comes into sight

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

Re: HTML5 deployment: progress comes into sight

hh via use-livecode
In reply to this post by 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 <svg> 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTML5 deployment: progress comes into sight

hh via use-livecode
In reply to this post by hh 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" <[hidden email]> 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" <
> [hidden email]> 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
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTML5 deployment: progress comes into sight

hh via use-livecode
In reply to this post by hh 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 <widget>' which we
do need to rectify (somehow) at somepoint - for a similar reason so that
we can actually have 'do in <object>' to mean 'do the fragment of script
in the context of the target object' (at the moment you can use it on a
browser widget, but then the script is JavaScript and not LCS!).

Warmest Regards,

Mark.

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

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

Re: HTML5 deployment: progress comes into sight

hh via use-livecode
In reply to this post by hh 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 ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

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

Re: HTML5 deployment: progress comes into sight

hh via use-livecode
In reply to this post by hh 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 ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

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

Re: HTML5 deployment: progress comes into sight

hh via use-livecode
In reply to this post by hh 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 <[hidden email]> 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 ~ [hidden email] ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

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

Re: HTML5 deployment: progress comes into sight

hh 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 ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

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

Re: HTML5 deployment: progress comes into sight

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

Re: HTML5 deployment: progress comes into sight

hh 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 <[hidden email]> 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
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

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

Re: HTML5 deployment: progress comes into sight

hh via use-livecode
In reply to this post by hh 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 ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

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

Re: HTML5 deployment: progress comes into sight

hh via use-livecode
In reply to this post by hh 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 ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

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

Re: HTML5 deployment: progress comes into sight

hh via use-livecode
In reply to this post by 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTML5 deployment: progress comes into sight

hh via use-livecode
In reply to this post by hh 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTML5 deployment: progress comes into sight

hh 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 <[hidden email]> wrote:
>
> @BR wrote: ... "What's very difficult, as you write in detail, are
> "callbacks" for _synchronous_communication..."
>
> Callback functions?
>
> In my mind, a "callback" is always asynchronous -? Let us say in Javascript
> - passing the function name and parameters of Javascript through LCS/LCB
> and then somehow the result is put into a variable while I am continuing
> processing other stuff. Maybe I am wrong? I am calling a server, waiting
> for the result, but I could wait forever and the result will possibly never
> come. So it would be blocking doing other things. A callback would free me
> from waiting for nothing. Is this a right definition for "callback"?
>
> What defines "callback"? I could understand though that I am calling a
> function in the browser widget (using the "callback" name of the function)
> which will be executed through Javascript and will be returning a value for
> further processing. What means "synchronous" or "asynchronous" in this
> context?
>
> Again, in my mind, a callback is when I send off a parcel to my friend with
> an instruction to tell me that it arrived and the confirmation of arrival.
> The confirmation is the callback. Then I know my friend received the
> parcel. Or in another analogy, I am calling someone by phone asking to call
> me back. The person may call immediately or may call never or in a couple
> of days. This is asynchronous.
>
> How would a callback become synchronous? Is it then still a "callback"?
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

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

Re: HTML5 deployment: progress comes into sight

hh via use-livecode
In reply to this post by hh 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 ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
123
Loading...