AW: HTML5 Deployment

[Paul Dupuis via use-livecode]

Found it. Thank you Mathias!


On 11/9/2021 7:06 PM, matthias rebbe via use-livecode wrote:

Paul, if you open the Livecode Dictionary, then you can see 2 tabs in the left upper corner. One is 
labeled "API" and one is labeled "Guide".

Click on "Guide" and then select "Deploying Your Application" and then "HTML5 
Deployment settings".
There you should find a bunch of information.

Hope this helps.

Matthias


Am 10.11.2021 um 00:41 schrieb Paul Dupuis via use-livecode 
:

I am trying to deploy and HTML app. Standalone building was straightforward and 
I now have a folder of stuff.

MyApp.html
standalone.zip
standalone-commercial-9.6.3.html.mem
standalone-commercial-9.6.3.js

The HTML5 panel in the Standalone Builder says to see the "HTML5 Deployment 
Guide in the Dictionary. In LC 9..6.3, there is no such guide in the dictionary. I 
have tried searching Livecode.com with no luck.

Where can the deployment guide be found?

___
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

[matthias rebbe via use-livecode]

Paul, if you open the Livecode Dictionary, then you can see 2 tabs in the left 
upper corner. One is labeled "API" and one is labeled "Guide".

Click on "Guide" and then select "Deploying Your Application" and then "HTML5 
Deployment settings". 
There you should find a bunch of information.

Hope this helps.

Matthias

> Am 10.11.2021 um 00:41 schrieb Paul Dupuis via use-livecode 
> :
> 
> I am trying to deploy and HTML app. Standalone building was straightforward 
> and I now have a folder of stuff.
> 
> MyApp.html
> standalone.zip
> standalone-commercial-9.6.3.html.mem
> standalone-commercial-9.6.3.js
> 
> The HTML5 panel in the Standalone Builder says to see the "HTML5 Deployment 
> Guide in the Dictionary. In LC 9..6.3, there is no such guide in the 
> dictionary. I have tried searching Livecode.com with no luck.
> 
> Where can the deployment guide be found?
> 
> ___
> 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

HTML5 Deployment

[Paul Dupuis via use-livecode]

I am trying to deploy and HTML app. Standalone building was 
straightforward and I now have a folder of stuff.


MyApp.html
standalone.zip
standalone-commercial-9.6.3.html.mem
standalone-commercial-9.6.3.js

The HTML5 panel in the Standalone Builder says to see the "HTML5 
Deployment Guide in the Dictionary. In LC 9..6.3, there is no such guide 
in the dictionary. I have tried searching Livecode.com with no luck.


Where can the deployment guide be found?

___
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

[hh via use-livecode]

> Sean wrote:
> 
> 4. As with 3 also, emscripten itself has capabilities built in that will
> allow for this so I will more likely utilise these rather than use JQuery.
> The idea will be to handle as much as possible within the emscripten code
> and have minimal stuff within the HTML output other than anything the user
> wants to add in.

[JQuery is only used for easier identifying DOM objects.]

When doing "windowing" also look at the current implementation of
"globalRect".
This is not correct as it doesn't respect the scroll of the browser window
what creates "jumping" stack windows.

> 5. Thinking ahead, a way to add in JS functions an LC developer would want
> included in the HTML output (from within LC) would be useful. Perhaps a
> stack custom property that can hold the whole JS code that gets inserted at
> deployment so that it builds as self contained. And/Or a way to access,
> manipulate and/or set parameters of the HTML from within LC before
> deployment (not at runtime). This could then include things like custom
> layouts, loading bars, screen size handlers, php/Ajax/jquery comms, etc. 

Please leave out such things. These are extensions.
But we could build a separate library of JS-extensions (updated with
actual things from JS/CSS) that can be loaded if needed.
And every beginner can insert JS from any LC container (do fld "JS1" as
"javascript").

Thinking ahead?
I'll extend my list not before 1.-4. is done: What I dislike most with LC
is that too much projects are only halfway finished.


___
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

[Pi Digital via use-livecode]

1&2 I am already implementing that way but thanks for the affirmation. 

3. Good idea regarding keeping them all on one predetermined layer. 

4. As with 3 also, emscripten itself has capabilities built in that will allow 
for this so I will more likely utilise these rather than use JQuery. The idea 
will be to handle as much as possible within the emscripten code and have 
minimal stuff within the HTML output other than anything the user wants to add 
in. 

5. Thinking ahead, a way to add in JS functions an LC developer would want 
included in the HTML output (from within LC) would be useful. Perhaps a stack 
custom property that can hold the whole JS code that gets inserted at 
deployment so that it builds as self contained. And/Or a way to access, 
manipulate and/or set parameters of the HTML from within LC before deployment 
(not at runtime). This could then include things like custom layouts, loading 
bars, screen size handlers, php/Ajax/jquery comms, etc. 

Sean Cole
Pi Digital Prod Ltd

> On 1 Feb 2020, at 14:38, hh via use-livecode  
> wrote:
> 
> * There are some things relating 1 & 2 one could think about:
> 
> Start with mouseEvents (incl. wheel) and modifier keys.
> 
> Then one could use native fields so that the browser does the keyboard job
> and executes all shortcuts for fields.
> To get/set field values is easy. A native styled field is also possible
> (see my demo at hyperhh.de/html5).
> 
> My technique is to use ordinary LC fields, hide these (and optionally use
> them as container). Then adjust the native field rects to these hidden field
> rects in the movestack/resizestack handlers.
> 
> * For 3 it would be enough to define ONE 'window'/canvas of id 'menu' for the
> menus with a z-level of say 23121950 and similarly define ONE 'window'/canvas
> for the tooltips of id 'tooltip' with a z-level of say 23121949.
> 
> That implies: do NOT create a new window for each menu/tooltip.
> Probably function createWindow in em-dc.js needs a switch for that (I could
> not find out where this method is called for menus/tooltips).
> 
> Then insert the two lines
> canvas.classList.add('lcStack');
> canvas.id('stack_'+tWindowID);
> after current line 128 of em-dc.js, so one has several methods to get stack
> objects.
> 
> * For 4 one could use the lib I use for htmlPlayer. This needs jQuery but it
> is the only one I've found that works with LC-menus. I added a short script
> to put stacks into a panel.
> 
>> Sean wrote:
>> em-event.js is the one for 1 & 2 causing the problem mainly because of its
>> use of now deprecated event handlers. That's what I am working on right
>> now.
>> 
>> em-dc, em-nativeLayer and em-surface are what is likely to do with 3 & 4.
>> Maybe also em-preamble-overlay.js.
>> 
>> em-clipboard obviously may have some relevance to the clipboard issue but
>> I'm working on the assumption first it is more likely just a keyboard/input
>> event issue.
>> 
>>> Hermann wrote:
>>> 1. *Full* keyboard and mouse (incl. wheel) support. 
>>> 
>>> 2. Support for usual field shortcuts (selectAll, copy, cut, paste, 
>>> undo) and rawkey handlers. 
>>> 
>>> 3. Improve the canvas generation: 
>>> 
>>> Currently LC generates canvases for stacks, tooltips and 
>>> menus that are without querying windowIDs for all stacks 
>>> undistinguishable. Often menus and tooltips are hidden by stacks: 
>>> 
>>> 3a. Menus need to have an own fixed (very high) z-level, 
>>> 3b. Tooltips need to have an own fixed (very high) z-level, 
>>> 3c. Stacks need an own class for easier access in DOM. 
>>> 
>>> 4. Add a draggable, resizable windowing system (adding titlebar, 
>>> decorations) with automatic layering (z-levels). 
> 
> ___
> 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

[hh via use-livecode]

* There are some things relating 1 & 2 one could think about:

Start with mouseEvents (incl. wheel) and modifier keys.

Then one could use native fields so that the browser does the keyboard job
and executes all shortcuts for fields.
To get/set field values is easy. A native styled field is also possible
(see my demo at hyperhh.de/html5).

My technique is to use ordinary LC fields, hide these (and optionally use
them as container). Then adjust the native field rects to these hidden field
rects in the movestack/resizestack handlers.

* For 3 it would be enough to define ONE 'window'/canvas of id 'menu' for the
menus with a z-level of say 23121950 and similarly define ONE 'window'/canvas
for the tooltips of id 'tooltip' with a z-level of say 23121949.

That implies: do NOT create a new window for each menu/tooltip.
Probably function createWindow in em-dc.js needs a switch for that (I could
not find out where this method is called for menus/tooltips).

Then insert the two lines
canvas.classList.add('lcStack');
canvas.id('stack_'+tWindowID);
after current line 128 of em-dc.js, so one has several methods to get stack
objects.

* For 4 one could use the lib I use for htmlPlayer. This needs jQuery but it
is the only one I've found that works with LC-menus. I added a short script
to put stacks into a panel.

> Sean wrote:
> em-event.js is the one for 1 & 2 causing the problem mainly because of its
> use of now deprecated event handlers. That's what I am working on right
> now.
> 
> em-dc, em-nativeLayer and em-surface are what is likely to do with 3 & 4.
> Maybe also em-preamble-overlay.js.
> 
> em-clipboard obviously may have some relevance to the clipboard issue but
> I'm working on the assumption first it is more likely just a keyboard/input
> event issue.
> 
> > Hermann wrote:
> > 1. *Full* keyboard and mouse (incl. wheel) support. 
> >
> > 2. Support for usual field shortcuts (selectAll, copy, cut, paste, 
> > undo) and rawkey handlers. 
> >
> > 3. Improve the canvas generation: 
> >
> > Currently LC generates canvases for stacks, tooltips and 
> > menus that are without querying windowIDs for all stacks 
> > undistinguishable. Often menus and tooltips are hidden by stacks: 
> >
> > 3a. Menus need to have an own fixed (very high) z-level, 
> > 3b. Tooltips need to have an own fixed (very high) z-level, 
> > 3c. Stacks need an own class for easier access in DOM. 
> >
> > 4. Add a draggable, resizable windowing system (adding titlebar, 
> > decorations) with automatic layering (z-levels). 

___
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

[Sean Cole (Pi) via use-livecode]

That's perfect, thank you. 1&2 were already at the top of my high priority
list. 3 & 4 I fully appreciate. Certainly, 3a and 3b should be relatively
easy to achieve. 3c and 4 slightly less so although I would be happy to
hear your guidance on this. I'm assuming you already know where to find the
current emscripten code base.
https://github.com/livecode/livecode/tree/develop/engine/src and everything
starting with 'em-'.

em-event.js is the one for 1 & 2 causing the problem mainly because of its
use of now deprecated event handlers. That's what I am working on right
now.

em-dc, em-nativeLayer and em-surface are what is likely to do with 3 & 4.
Maybe also em-preamble-overlay.js.

em-clipboard obviously may have some relevance to the clipboard issue but
I'm working on the assumption first it is more likely just a keyboard/input
event issue.

Let me know if you see anything in there that stands out to you. Ian at LC
Mothership helped me get set up for building and editing in Linux so I can
test anything I change. So far its very promising. It would be great to
have it ready for and included in LC9.7/10.0

Sean Cole
*Pi Digital *


On Fri, 31 Jan 2020 at 22:14, hh via use-livecode <
use-livecode@lists.runrev.com> wrote:

> > Sean C. wrote (in thread 'Brave'):
> > ... can you put together a priority list of items that need to
> > be fixed in HTML5 deployment as I am currently adjusting the code.
> > I mean things that should just work without running external
> > JS workarounds like most of the key commands not working in a
> > simple text field, etc.
>
> [Adjusting which code? If this is some part of the standalone
> builder I would like to see it.]
>
> My list is long. To avoid that minor things are solved instead of
> the major ones here the most important only (ordered by importance):
>
> 1. *Full* keyboard and mouse (incl. wheel) support.
>
> 2. Support for usual field shortcuts (selectAll, copy, cut, paste,
> undo) and rawkey handlers.
>
> 3. Improve the canvas generation:
>
> Currently LC generates canvases for stacks, tooltips and
> menus that are without querying windowIDs for all stacks
> undistinguishable. Often menus and tooltips are hidden by stacks:
>
> 3a. Menus need to have an own fixed (very high) z-level,
> 3b. Tooltips need to have an own fixed (very high) z-level,
> 3c. Stacks need an own class for easier access in DOM.
>
> 4. Add a draggable, resizable windowing system (adding titlebar,
> decorations) with automatic layering (z-levels).
>
> Using js workarounds I got 1.+2. by using native fields and 3.+4.
> by adjusting a panel-script of 350 lines (I tried 5 libs, only
> one worked with the LC-menu-canvases, see htmlPlayer).
>
>
> ___
> 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

HTML5 deployment

[hh via use-livecode]

> Sean C. wrote (in thread 'Brave'):
> ... can you put together a priority list of items that need to
> be fixed in HTML5 deployment as I am currently adjusting the code.
> I mean things that should just work without running external 
> JS workarounds like most of the key commands not working in a
> simple text field, etc.

[Adjusting which code? If this is some part of the standalone
builder I would like to see it.]

My list is long. To avoid that minor things are solved instead of
the major ones here the most important only (ordered by importance):

1. *Full* keyboard and mouse (incl. wheel) support.

2. Support for usual field shortcuts (selectAll, copy, cut, paste,
undo) and rawkey handlers. 

3. Improve the canvas generation:

Currently LC generates canvases for stacks, tooltips and
menus that are without querying windowIDs for all stacks
undistinguishable. Often menus and tooltips are hidden by stacks:

3a. Menus need to have an own fixed (very high) z-level,
3b. Tooltips need to have an own fixed (very high) z-level,
3c. Stacks need an own class for easier access in DOM.

4. Add a draggable, resizable windowing system (adding titlebar,
decorations) with automatic layering (z-levels).

Using js workarounds I got 1.+2. by using native fields and 3.+4.
by adjusting a panel-script of 350 lines (I tried 5 libs, only
one worked with the LC-menu-canvases, see htmlPlayer).


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

> 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 
> <use-livecode@lists.runrev.com> 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 <http://livecloud.io/>
nursenotes.net <http://nursenotes.net/>
canelasoftware.com <http://www.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 <mikeker...@roadrunner.com>
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 
> <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

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

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
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: Not able to use the clipboard with HTML5 deployment

[Terry Judd]

Yeah, I already tried that but it only accepts plain text :(

Terry...

On 22/02/2016 4:37 pm, "use-livecode on behalf of [-hh]"
 wrote:

>> Terry J. wrote:
>> OK, thanks hh. It¹s probably a little too clunky for my purpose
>> (I don¹t think I can expect users to manually replace placeholder
>> characters with returns) but nice to know that there is a
>> workaround of sorts.
>
>If the webpage that receives the text (page) accepts 'styled' text
>you could -- before delivering the text -- juggle with
>   case RTFtext: \par, \line or \softline
>   case HTMLtext: ,  or space
>so that the copied text (if it's not too long) becomes one line
>for using the Ask dialog??
>
>hh
>___
>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: Not able to use the clipboard with HTML5 deployment

[Sannyasin Brahmanathaswami]

"Over to another web page"

Ok well that's a different game for sure and would require clipboard

BR

( from my mobile )




On Sun, Feb 21, 2016 at 7:25 PM -0800, "Terry Judd" 
> wrote:

So, I want to copy the formatted text from my LC HTML5 app to a text field
in another webpage that is independent of my HTML5 app and over which I
have no control. I don¹t think that¹s possible without using the clipboard
as an intermediary - is it?

Regards,

Terry...

On 22/02/2016 2:10 pm, "use-livecode on behalf of Sannyasin
Brahmanathaswami"  wrote:

>Until that is working, why not just set a local (or possibly you will
>need a global)  variable and as the selections are made, append to the
>global variable, then when ready they user clicks a button and the global
>variable containing the data is inserted into the comments?  You can
>emulate a "copy" by just save the selectedText... and passing this to
>your global...
>
>Why is the clipboard mission critical to the architecture? Especially if
>the series of statements can each be contained in a single line, then you
>can really do this easily with a locked field and clicks on the lines...
>I can think of about 8 different ways to accomplish this without the
>clipboard (depends on how the assessment rubric data is
>formated/presented, of course)
>
>BR
>
>
>On February 21, 2016 at 3:05:03 PM, Terry Judd
>(terry.j...@unimelb.edu.au) wrote:
>
>I¹m trying to create a relatively simple HTML5 Œapplet' that allows the
>user to select from a series of statements (an assessment rubric) to
>generate a basic feedback report that they can paste into an existing
>comments box within one of the bits of our learning management system.
>Seemed like a relatively straightforward test for LC¹s new HTML5 export
>feature except that despite what the dictionary says setting the
>clipboardData doesn¹t work. This seems to be confirmed by a search of the
>quality control centre (unresolved bug 16251 from October last year).
>Does anyone have any information on if and when clipboard support will be
>added? I¹m pretty much stuck without it.
>
>Regards,
>
>TerryŠ
>___
>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: Not able to use the clipboard with HTML5 deployment

[[-hh]]

> Terry J. wrote:
> OK, thanks hh. It’s probably a little too clunky for my purpose
> (I don’t think I can expect users to manually replace placeholder
> characters with returns) but nice to know that there is a
> workaround of sorts.

If the webpage that receives the text (page) accepts 'styled' text
you could -- before delivering the text -- juggle with
   case RTFtext: \par, \line or \softline
   case HTMLtext: ,  or space
so that the copied text (if it's not too long) becomes one line
for using the Ask dialog??

hh
___
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: Not able to use the clipboard with HTML5 deployment

[Terry Judd]

OK, thanks hh. It’s probably a little too clunky for my purpose (I don’t
think I can expect users to manually replace placeholder characters with
returns) but nice to know that there is a workaround of sorts.

Great set of LC HTML5 demos BTW!

Terry…

On 22/02/2016 2:59 pm, "use-livecode on behalf of [-hh]"
 wrote:

>> So, I want to copy the formatted text from my LC HTML5 app to a
>> text field in another webpage that is independent of my HTML5
>> app and over which I have no control. I don¹t think that¹s
>> possible without using the clipboard as an intermediary - is it?
>> Regards, Terry...
>
>Hi Terry (and BR)
>this is currently the one and only way available for communication
>with a HTML5 standalone: The Ask dialog.
>
>I made a demo, available at hh.on-rev-com/html5/ (= overview)
>called 'Copy/Paste Text'-Test
>
>It's made with dp9 in November, nothing related to that changed
>in dp10-14, stack is downloadable.
>[Use Chrome, Opera or Safari.
>Firefox: yes < v44, NO v44, yes > v44 (coming soon)]
>
>hh
>___
>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: Not able to use the clipboard with HTML5 deployment

[[-hh]]

> So, I want to copy the formatted text from my LC HTML5 app to a
> text field in another webpage that is independent of my HTML5
> app and over which I have no control. I don¹t think that¹s
> possible without using the clipboard as an intermediary - is it? 
> Regards, Terry...

Hi Terry (and BR)
this is currently the one and only way available for communication
with a HTML5 standalone: The Ask dialog.

I made a demo, available at hh.on-rev-com/html5/ (= overview)
called 'Copy/Paste Text'-Test

It's made with dp9 in November, nothing related to that changed
in dp10-14, stack is downloadable.
[Use Chrome, Opera or Safari.
Firefox: yes < v44, NO v44, yes > v44 (coming soon)]

hh
___
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: Not able to use the clipboard with HTML5 deployment

[Terry Judd]

So, I want to copy the formatted text from my LC HTML5 app to a text field
in another webpage that is independent of my HTML5 app and over which I
have no control. I don¹t think that¹s possible without using the clipboard
as an intermediary - is it?

Regards,

Terry...

On 22/02/2016 2:10 pm, "use-livecode on behalf of Sannyasin
Brahmanathaswami"  wrote:

>Until that is working, why not just set a local (or possibly you will
>need a global)  variable and as the selections are made, append to the
>global variable, then when ready they user clicks a button and the global
>variable containing the data is inserted into the comments?  You can
>emulate a "copy" by just save the selectedText... and passing this to
>your global...
>
>Why is the clipboard mission critical to the architecture? Especially if
>the series of statements can each be contained in a single line, then you
>can really do this easily with a locked field and clicks on the lines...
>I can think of about 8 different ways to accomplish this without the
>clipboard (depends on how the assessment rubric data is
>formated/presented, of course)
>
>BR
>
>
>On February 21, 2016 at 3:05:03 PM, Terry Judd
>(terry.j...@unimelb.edu.au) wrote:
>
>I¹m trying to create a relatively simple HTML5 Œapplet' that allows the
>user to select from a series of statements (an assessment rubric) to
>generate a basic feedback report that they can paste into an existing
>comments box within one of the bits of our learning management system.
>Seemed like a relatively straightforward test for LC¹s new HTML5 export
>feature except that despite what the dictionary says setting the
>clipboardData doesn¹t work. This seems to be confirmed by a search of the
>quality control centre (unresolved bug 16251 from October last year).
>Does anyone have any information on if and when clipboard support will be
>added? I¹m pretty much stuck without it.
>
>Regards,
>
>TerryŠ
>___
>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: Not able to use the clipboard with HTML5 deployment

[Sannyasin Brahmanathaswami]

Until that is working, why not just set a local (or possibly you will need a 
global)  variable and as the selections are made, append to the global 
variable, then when ready they user clicks a button and the global variable 
containing the data is inserted into the comments?  You can emulate a "copy" by 
just save the selectedText... and passing this to your global...

Why is the clipboard mission critical to the architecture? Especially if the 
series of statements can each be contained in a single line, then you can 
really do this easily with a locked field and clicks on the lines... I can 
think of about 8 different ways to accomplish this without the clipboard 
(depends on how the assessment rubric data is formated/presented, of course)

BR


On February 21, 2016 at 3:05:03 PM, Terry Judd 
(terry.j...@unimelb.edu.au) wrote:

I’m trying to create a relatively simple HTML5 ‘applet' that allows the user to 
select from a series of statements (an assessment rubric) to generate a basic 
feedback report that they can paste into an existing comments box within one of 
the bits of our learning management system. Seemed like a relatively 
straightforward test for LC’s new HTML5 export feature except that despite what 
the dictionary says setting the clipboardData doesn’t work. This seems to be 
confirmed by a search of the quality control centre (unresolved bug 16251 from 
October last year). Does anyone have any information on if and when clipboard 
support will be added? I’m pretty much stuck without it.

Regards,

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

Not able to use the clipboard with HTML5 deployment

[Terry Judd]

I’m trying to create a relatively simple HTML5 ‘applet' that allows the user to 
select from a series of statements (an assessment rubric) to generate a basic 
feedback report that they can paste into an existing comments box within one of 
the bits of our learning management system. Seemed like a relatively 
straightforward test for LC’s new HTML5 export feature except that despite what 
the dictionary says setting the clipboardData doesn’t work. This seems to be 
confirmed by a search of the quality control centre (unresolved bug 16251 from 
October last year). Does anyone have any information on if and when clipboard 
support will be added? I’m pretty much stuck without it.

Regards,

Terry…
___
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 is still in the far future.

[Pyyhtiä Christer]

Thank you for the comments.

The way i set the questions might have been confusing.

First, trying to search a good HTML5  style sheet editor was not the point. 
The point was to find out tools to simplify the creation process by having some 
functions available, not to have an ultimate end product (created with LC).  
Tools, which one could have access to, to be able to massage parameters, as we 
all want to have the end result as close as possible to what we want.

Example 1.  If there is a function to help to put in place page header and 
body, use one single change to change the font or style.

Example 2. To automatically pick out key phrases from the different pages and 
see how Google predicts search clicks and impressions.

Example 3. To embed code to do object manipulation.

Btw, how do you embed .lc code in web page?

thx

Christer Pyyhtiä
Skype:  christerp1
chris...@mindcrea.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 is still in the far future.

[Peter W A Wood]

There are two different approaches to use LiveCode with webpages. Here are two 
very simple examples.

The first is by embedding LiveCode inside the HTML in the same way that you 
embed PHP:

html
head
titleMy LiveCode Server Test Page/title
/head
body
h1My LiveCode Server Test Page/h1
?lc
put pHello World! from LiveCode Server/p
put pThe date is   the date  /p
?
/body
/html

The second way is to run a script that generates all the html for the page:

?lc
if $_POST[name]   then
put $_POST[name] into tName
else
put World into tName
end if
put header Content-Type: text/html
put html
put head
put titleLiveCode Server Test Page/title
put /head
put body
put h1My LiveCode Server Test Page/h1
put pHello  tName  from LiveCode Server/p
put pThe date is  the internet date  /p
put p The version is  the Version  /p
put /body
put /html
?

Regards

Peter

 On 12 May 2015, at 14:28, Pyyhtiä Christer chris...@mindcrea.com wrote:
 
 Thank you for the comments.
 
 The way i set the questions might have been confusing.
 
 First, trying to search a good HTML5  style sheet editor was not the point. 
 The point was to find out tools to simplify the creation process by having 
 some functions available, not to have an ultimate end product (created with 
 LC).  Tools, which one could have access to, to be able to massage 
 parameters, as we all want to have the end result as close as possible to 
 what we want.
 
 Example 1.  If there is a function to help to put in place page header and 
 body, use one single change to change the font or style.
 
 Example 2. To automatically pick out key phrases from the different pages and 
 see how Google predicts search clicks and impressions.
 
 Example 3. To embed code to do object manipulation.
 
 Btw, how do you embed .lc code in web page?
 
 thx
 
 Christer Pyyhtiä
 Skype:  christerp1
 chris...@mindcrea.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: Posted here: HTML5 deployment is still in the far future.

[Richmond]

On 12/05/15 20:55, Richard Gaskin wrote:

Mike Kerner wrote:

 Why not just use any of the word processors?  They all do HTML.

Make a web site once with a word processor and you'll never try it again.

Worst. Html. Ever.  ;)



That's why, as I posted earlier, I use KompoZer.

Richmond.

___
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: Posted here: HTML5 deployment is still in the far future.

[Richard Gaskin]

Mike Kerner wrote:

 Why not just use any of the word processors?  They all do HTML.

Make a web site once with a word processor and you'll never try it again.

Worst. Html. Ever.  ;)

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.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: Posted here: HTML5 deployment is still in the far future.

[Mike Kerner]

Why not just use any of the word processors?  They all do HTML.

On Tue, May 12, 2015 at 11:39 AM, Bob Warren bobwar...@howsoft.com wrote:

 Mark Rauterkus wrote:

 I have never found an easy HTML editor that was written on LiveCode.

 --
 Some hopefully useful links:

 http://www.howsoft.com/webed2/  (Windows web page editor)

 http://www.howsoft.com/linux/webed2/  (Linux web page editor)

 http://www.howsoft.com/browserapps/

 for:

 webEd4 - a web page editor for all platforms
 webProg - a semi-IDE for the production of web browser apps written in
 JQuery and Javascript



 ___
 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: Posted here: HTML5 deployment is still in the far future.

[Mike Bonner]

For a while I had a very very simple stack set up.  It had a text box, and
a revbrowser. I was running apache on the same box, so it was easy enough
to have a refresh button that would dump the contents of the text field
into a file, and reload revbrowser.  It was ugly and undeveloped, but for
the extremely quick and dirty pages I was working on it did very well. I
like all my html in plain text anyway so it worked well for me.

On Tue, May 12, 2015 at 12:22 PM, Richmond richmondmathew...@gmail.com
wrote:

 On 12/05/15 20:55, Richard Gaskin wrote:

 Mike Kerner wrote:

  Why not just use any of the word processors?  They all do HTML.

 Make a web site once with a word processor and you'll never try it again.

 Worst. Html. Ever.  ;)


 That's why, as I posted earlier, I use KompoZer.

 Richmond.


 ___
 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: Posted here: HTML5 deployment is still in the far future.

[Bob Warren]

Mark Rauterkus wrote:

I have never found an easy HTML editor that was written on LiveCode.

--
Some hopefully useful links:

http://www.howsoft.com/webed2/  (Windows web page editor)

http://www.howsoft.com/linux/webed2/  (Linux web page editor)

http://www.howsoft.com/browserapps/

for:

webEd4 - a web page editor for all platforms
webProg - a semi-IDE for the production of web browser apps written in JQuery 
and Javascript


___
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: Posted here: HTML5 deployment is still in the far future.

[Richmond]

On 11/05/15 22:15, Mark Rauterkus wrote:

Hi,

Okay, ... If
HTML5 deployment is still in the far future.

Then,
What LC tools are people using NOW to help with their most simple web pages?

I have never found an easy HTML editor that was written on LiveCode.


I wouldn't hold your breath to be honest.

I use KompoZer: http://www.kompozer.net/

Richmond.



Thanks.

Mark Rauterkus
m...@rauterkus.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: Posted here: HTML5 deployment is still in the far future.

[Pierre Sahores]

My own habit : LC-Server+RevIgniter+native JS/JQuery

 Le 11 mai 2015 à 21:15, Mark Rauterkus mark.rauter...@gmail.com a écrit :
 
 Hi,
 
 Okay, ... If
 HTML5 deployment is still in the far future.
 
 Then,
 What LC tools are people using NOW to help with their most simple web pages?
 
 I have never found an easy HTML editor that was written on LiveCode.
 
 Thanks.
 
 Mark Rauterkus
 m...@rauterkus.com
 
 
 
 -- 
 --
 Ta.
 
 
 Mark Rauterkus   mark.rauter...@gmail.com
 PPS Summer Dreamers' Swim and Water Polo Camp Head Coach
 Varsity Boys Swim Coach, Pittsburgh Obama Academy
 Head Water Polo Coach, Carnegie Mellon University Women's Club Team
 Pittsburgh Combined Water Polo Team
 
 http://Rauterkus.blogspot.com
 http://FixPA.wikia.com
 http://CLOH.wikia.com
 412 298 3432 = cell
 ___
 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

--
Pierre Sahores
mobile : 06 03 95 77 70
www.sahores-conseil.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

Posted here: HTML5 deployment is still in the far future.

[Mark Rauterkus]

Hi,

Okay, ... If
HTML5 deployment is still in the far future.

Then,
What LC tools are people using NOW to help with their most simple web pages?

I have never found an easy HTML editor that was written on LiveCode.

Thanks.

Mark Rauterkus
m...@rauterkus.com



-- 
--
Ta.


Mark Rauterkus   mark.rauter...@gmail.com
PPS Summer Dreamers' Swim and Water Polo Camp Head Coach
Varsity Boys Swim Coach, Pittsburgh Obama Academy
Head Water Polo Coach, Carnegie Mellon University Women's Club Team
Pittsburgh Combined Water Polo Team

http://Rauterkus.blogspot.com
http://FixPA.wikia.com
http://CLOH.wikia.com
412 298 3432 = cell
___
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: Posted here: HTML5 deployment is still in the far future.

[Mark Wieder]

Mark Rauterkus mark.rauterkus@... writes:

 What LC tools are people using NOW to help with their most simple web pages?

Again not LC, but I use Sublime Text.
I believe other text editors also exist.

-- 
 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: Posted here: HTML5 deployment is still in the far future.

[Mark Schonewille]

Hi,

HyperStudio used to be quite similar to HyperCard. Nowadays it doesn't 
have a scripting language anymore, but it does allow you to do 
HyperCard-like things and export it to HTML5. It has some limitations, 
but the interface is great and the HTML5 export mostly works.

http://www.hyperstudio.com

Xojo (formerly RealStudio) has an option to build CGI standalones, which 
display HTML5 in the web browser. It feel like you're running a real 
app, but the app actually sits on the server and the browser display the 
HTML5 output.


--
Best regards,

Mark Schonewille

Economy-x-Talk Consulting and Software Engineering
Homepage: http://economy-x-talk.com
Twitter: http://twitter.com/xtalkprogrammer
KvK: 50277553

Installer Maker for LiveCode:
http://qery.us/468

Buy my new book Programming LiveCode for the Real Beginner 
http://qery.us/3fi


LiveCode on Facebook:
https://www.facebook.com/groups/runrev/

On 5/11/2015 21:15, Mark Rauterkus wrote:

Hi,

Okay, ... If
HTML5 deployment is still in the far future.

Then,
What LC tools are people using NOW to help with their most simple web pages?

I have never found an easy HTML editor that was written on LiveCode.

Thanks.

Mark Rauterkus
m...@rauterkus.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: Posted here: HTML5 deployment is still in the far future.

[Colin Holgate]

It exports to HTML5 WebGL 3D. So, good for running Unity 3D like apps without 
needing the plugin (though you do need a WebGL capable browser).

I think that Hype is good for CSS based HTML5 pages, and Edge Animate would 
also be good for that. If you’re comfortable writing in Javascript you could 
use Flash Pro, which can export to HTML5 Canvas and HTML5 WebGL2D.


 On May 11, 2015, at 5:18 PM, Mark Schonewille 
 m.schonewi...@economy-x-talk.com wrote:
 
 I think that Unity has an HTML5 export feature too, now.

___
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: Posted here: HTML5 deployment is still in the far future.

[Matthias Rebbe | M-R-D]

No LC tools and not just simple html editors, but

Rapidweaver on Mac OS X form http://www.realmacsoftware.com

or

Responsive Layout Maker Pro for Windows or Mac OS X
from http://www.coffeecup.com

are easy tools for such tasks.

Regards,

Matthias



 Am 11.05.2015 um 21:15 schrieb Mark Rauterkus mark.rauter...@gmail.com:
 
 Hi,
 
 Okay, ... If
 HTML5 deployment is still in the far future.
 
 Then,
 What LC tools are people using NOW to help with their most simple web pages?
 
 I have never found an easy HTML editor that was written on LiveCode.
 
 Thanks.
 
 Mark Rauterkus
 m...@rauterkus.com
 
 
 
 -- 
 --
 Ta.
 
 
 Mark Rauterkus   mark.rauter...@gmail.com
 PPS Summer Dreamers' Swim and Water Polo Camp Head Coach
 Varsity Boys Swim Coach, Pittsburgh Obama Academy
 Head Water Polo Coach, Carnegie Mellon University Women's Club Team
 Pittsburgh Combined Water Polo Team
 
 http://Rauterkus.blogspot.com
 http://FixPA.wikia.com
 http://CLOH.wikia.com
 412 298 3432 = cell
 ___
 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: Posted here: HTML5 deployment is still in the far future.

[Ben Rubinstein]

On 11/05/2015 20:15, Mark Rauterkus wrote:

Okay, ... If
HTML5 deployment is still in the far future.

Then,
What LC tools are people using NOW to help with their most simple web pages?


I wouldn't think LC would be the tool to use for simple web pages even if 
HTML5 deployment arrived tomorrow.  From what RunRev have said about it, that 
facility will be useful for web apps - or web deployed apps - with fantastic 
speed/ease of development, especially for those who are already skilled in the 
language and especially for apps which are also to be deployed in other ways; 
but with some overheads for the end user.


If you're looking for an easy way to do simple web *apps* now, I'd look at 
Hype (tumult.com/hype/).  But if you're looking for assistance with simple web 
pages - depending on your definition of simple, of course! - I'd look first at 
the hosted services (Squarespace, Tumblr et al); and then at some of the tools 
like Dreamweaver.


HTH,

Ben

___
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: Posted here: HTML5 deployment is still in the far future.

[Mark Schonewille]

I think that Unity has an HTML5 export feature too, now.

--
Best regards,

Mark Schonewille

Economy-x-Talk Consulting and Software Engineering
Homepage: http://economy-x-talk.com
Twitter: http://twitter.com/xtalkprogrammer
KvK: 50277553

Installer Maker for LiveCode:
http://qery.us/468

Buy my new book Programming LiveCode for the Real Beginner 
http://qery.us/3fi


LiveCode on Facebook:
https://www.facebook.com/groups/runrev/

On 5/11/2015 23:15, Mark Schonewille wrote:

Hi,

HyperStudio used to be quite similar to HyperCard. Nowadays it doesn't
have a scripting language anymore, but it does allow you to do
HyperCard-like things and export it to HTML5. It has some limitations,
but the interface is great and the HTML5 export mostly works.
http://www.hyperstudio.com

Xojo (formerly RealStudio) has an option to build CGI standalones, which
display HTML5 in the web browser. It feel like you're running a real
app, but the app actually sits on the server and the browser display the
HTML5 output.

--
Best regards,

Mark Schonewille

Economy-x-Talk Consulting and Software Engineering
Homepage: http://economy-x-talk.com
Twitter: http://twitter.com/xtalkprogrammer
KvK: 50277553

Installer Maker for LiveCode:
http://qery.us/468

Buy my new book Programming LiveCode for the Real Beginner
http://qery.us/3fi

LiveCode on Facebook:
https://www.facebook.com/groups/runrev/

On 5/11/2015 21:15, Mark Rauterkus wrote:

Hi,

Okay, ... If
HTML5 deployment is still in the far future.

Then,
What LC tools are people using NOW to help with their most simple web
pages?

I have never found an easy HTML editor that was written on LiveCode.

Thanks.

Mark Rauterkus
m...@rauterkus.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: Posted here: HTML5 deployment is still in the far future.

[Alex Shaw]

Tumult Hype +1

regards
alex
On 12/05/2015 7:27 am, Colin Holgate wrote:

It exports to HTML5 WebGL 3D. So, good for running Unity 3D like apps without 
needing the plugin (though you do need a WebGL capable browser).

I think that Hype is good for CSS based HTML5 pages, and Edge Animate would 
also be good for that. If you’re comfortable writing in Javascript you could 
use Flash Pro, which can export to HTML5 Canvas and HTML5 WebGL2D.



On May 11, 2015, at 5:18 PM, Mark Schonewille 
m.schonewi...@economy-x-talk.com wrote:


I think that Unity has an HTML5 export feature too, now.





___
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