Re: JavaScript + LC HTML5 = LiveCode.js

[Peter TB Brett]

On 28/11/2016 16:19, Bob Sneidar wrote:

It was a joke Peter. Buggy? Licecode? Ticksperience??


Apparently I missed it.  Sorry!

Peter :-)

--
Dr Peter Brett 
LiveCode Technical Project Manager

lcb-mode for Emacs: https://github.com/peter-b/lcb-mode

___
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: JavaScript + LC HTML5 = LiveCode.js

[Bob Sneidar]

It was a joke Peter. Buggy? Licecode? Ticksperience??

Bob S


> On Nov 28, 2016, at 08:16 , Peter TB Brett  wrote:
> 
> 
> 
> On 28/11/2016 16:00, Bob Sneidar wrote:
>> I personally have founf the current version of Licecode to be too
>> buggy for my needs. You may have a different ticksperience. :-)
> 
> Hi Bob,
> 
> Please can you let me know which bugs are causing you particular
> trouble?  I could take a look and see whether they're something we can
> get fixed sooner rather than later.
> 
> Peter
> 
> -- 
> Dr Peter Brett 
> LiveCode Technical Project Manager
> 
> lcb-mode for Emacs: https://github.com/peter-b/lcb-mode
> 
> ___
> 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: JavaScript + LC HTML5 = LiveCode.js

[Peter TB Brett]

On 28/11/2016 16:00, Bob Sneidar wrote:

I personally have founf the current version of Licecode to be too
buggy for my needs. You may have a different ticksperience. :-)


Hi Bob,

Please can you let me know which bugs are causing you particular
trouble?  I could take a look and see whether they're something we can
get fixed sooner rather than later.

 Peter

--
Dr Peter Brett 
LiveCode Technical Project Manager

lcb-mode for Emacs: https://github.com/peter-b/lcb-mode

___
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: JavaScript + LC HTML5 = LiveCode.js

[Bob Sneidar]

I personally have founf the current version of Licecode to be too buggy for my 
needs. You may have a different ticksperience. :-)

Bob S


On Nov 24, 2016, at 07:49 , Todd Fabacher 
> wrote:

Our thinking is it would have 5+ core functionalities that woul dbe shared
by most HTML5 apps.  I think this would be a great community project and
help people who may not be so familiar with Javascript and can stay focused
on LiceCode.

___
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: JavaScript + LC HTML5 = LiveCode.js

[Roger Eller]

On Nov 25, 2016 11:03 AM, "Richard Gaskin" 
wrote:
>
> Roger Eller wrote:
>
> > Back when we had the RevWeb plugin, my browser based apps just worked.
>
> That's exactly where a standalone is every bit as valuable as Mark was
suggesting...
>
> I can't say enough good things about LC's ability to run downloaded
stacks.  It's one of the most powerful features in the engine, and perhaps
the most under-appreciated.
>
> It's nearly everything you want with browser-based delivery, but able to
handle app designs that go far beyond the browser, with richer features and
optionally greater security as well.
>
> --
>  Richard Gaskin

So, since the days shortly following the death of our dear plugin, I have
re-factored all of my stacks to be delivered to a custom client exe.  I
even utilize LiveCode server.  It's a little symphony of code and
communication between standalone, stacks, and server scripts.

~Roger
___
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: JavaScript + LC HTML5 = LiveCode.js

[Richard Gaskin]

Matt Maier wrote:

> On Fri, Nov 25, 2016 at 8:02 AM, Richard Gaskin wrote:
[a bunch of stuff too long to quote but available at:
]

> Richard,
> Thanks for that explanation. I've heard you mention this setup several
> times before but this is the most detail I've seen you put in one
> place.

Thanks for the feedback.  Glad it was helpful.

> Clarification question: do you cache the last stacks downloaded in
> case the user isn't connected to a network?

Not currently, at least not for stacks.

Where I use "streaming apps" the requirements are often very similar to 
what we need from web apps, involving lots of data communication with 
the server.  If we don't have a connection there's little meaningful 
work that these apps can do, so I haven't bothered with an offline mode 
for them.


I do, however, have a data cache for one of these apps.  That one's a 
CMS for specialized medical content, and the time our editors can spend 
on a document can be long, often spanning many days.  To ensure the 
content isn't lost between sessions we use a check-out/check-in system 
in which the checked-out document is stored in a local cache until it's 
checked back in and safely confirmed on the server.


I could extend the cache subsystem to handle stacks as well, but thus 
far I haven't needed it.



Tip:  if you need to cache stacks you can make that super-easy by 
accompanying each stack file on the server with a small manifest-like 
text file that contains the build number of the most recently-posted 
stack.  So on the server you might have something like:


  somestack.livecode
  somestack.info

...where the *.info file contains essential metadata.

With that you can quickly compare the version/build number of a local 
stack file (stored in a custom property; I tend to use "ufwVersion" but 
the key could be any memorable string) with what's on the server with a 
super-fast download of that small text file.


I use a simple metadata file for the auto-update feature in my 
devolution plugin and some of my apps:



While most of my stuff includes a human-optimmized version number for 
the About box, I generally maintain an integer build numbers so version 
comparisons are dirt simple.


Even simpler:  you can have your uploading or standalone manager 
auto-increment your build number whenever you post, so you set it up 
once and never need to think about it again.


--
 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: JavaScript + LC HTML5 = LiveCode.js

[Sannyasin Brahmanathaswami]

Actually I have two long running apps (15 years) working exactly has Richard 
describes. Indeed is has so many advantages. I love being on SKYPE with one of 
our volunteers who may have a small complaint about the UX or wants to added 
something to the back end database… I quicklyl fix it and just tell them 

"OK, close that window and click the button again" 

It fetches a fresh stack/data from dbase on the server, and what they wanted is 
suddenly there without any upgrade process.

Initially I always get this "wow, that is so cool!" response from them… 

It would be awesome if we could do this on mobile.  We talked about the 
before.. I think you can do this on Android.

  BR
 

On 11/25/16, 6:02 AM, "use-livecode on behalf of Richard Gaskin" 
 
wrote:

I can't say enough good things about LC's ability to run downloaded 
stacks.  It's one of the most powerful features in the engine, and 
perhaps the most under-appreciated.

It's nearly everything you want with browser-based delivery, but able to 
handle app designs that go far beyond the browser, with richer features 
and optionally greater security as well.

___
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: JavaScript + LC HTML5 = LiveCode.js

[Matt Maier]

Richard,
Thanks for that explanation. I've heard you mention this setup several
times before but this is the most detail I've seen you put in one place.

Clarification question: do you cache the last stacks downloaded in case the
user isn't connected to a network?

On Fri, Nov 25, 2016 at 8:02 AM, Richard Gaskin 
wrote:

> Roger Eller wrote:
>
> > I disagree that you might as well be running a desktop app.  The
> > download of the helper would only be necessary once (like the old
> > RevWeb plugin). Back when we had the RevWeb plugin, my browser based
> > apps just worked.
> > Being in a position where localized automation is primarily what I
> > create for in-house users, this would allow me to update/maintain to
> > a single code-source, but without having my hands tied
> > capability-wise by the browser.
>
> That's exactly where a standalone is every bit as valuable as Mark was
> suggesting.
>
> We need not make every stack file into a standalone for our users to run
> it.
>
> All they need is one copy of the LiveCode engine, with just enough code so
> it knows where to download more stack files.
>
> Just as a version of the LC engine as a browser plugin can download and
> run stack files, any standalone already installed on the user's machine can
> do the same.
>
> But like you say, a standalone engine isn't limited to the confines of the
> browser, and devs deploying with a standalone never need to think about how
> to handle UI elements never intended for their app, like how to handle the
> browser's Back button.
>
> In addition to providing a better user experience through a UI dedicated
> to the tasks your app supports, "streaming stacks" can be safer too: with
> the relatively recent addition of the securityPermissions global property,
> it's possible to deliver standalones that download and run stacks that are
> safer than nearly any browser.
>
> Most of my work these days is with "streaming apps" - here's my setup:
>
>
> Client
> --
> - Standalone
>   Contains only enough code to download one stack file from
>   our server.
>
>   This is only a little more than:
>
>  go stack "https://somedomain.com/path/to/mainstackfile.livecode;
>
>   ...with some error-checking and one dialog to report errors if
>   encountered.
>
>   This standalone is downloaded and installed this only once.  We may
>   update it once every year or two when we truly need to update the
>   LC engine version we're using, but those times are rare.
>
>
> Server - Downloads
> --
> - Main Library
>   This is the stack file that gets downloaded first.  It contains all
>   other code and URLs the app will need to download and run other stack
>   files.
>
>   We can completely change all aspects of the app by changing this one
>   stack file on our server at any time.
>
> - Other stack files, downloaded as needed:
>
>   - login.livecode -- provides a UI for tasks requiring authentication
>
>   - admin.livecode -- UI for admin tasks for those users who've
>   authenticated with admin privileges.
>
>   - logs.livecode  -- Viewer for server logs to monitor usage and
>   provide diagnostics for errors (see below),
>
>   - other stacks   -- We can create and upload any task-specific UI
>   and/or code as needed, and download-n-run it
>   from any other.
>
> Server - Processing
> ---
> - LC standalone or LC Server running as CGI under Apache, providing:
>
>- data store access through REST API with CRUD operations
>
>- authentication and other user services
>
>- logging
>
>- anything else we need on the server to support user-specific data
>  management and sharing of data for collaborative workflows.
>
>
>
> Development
> ---
> - Upload Tool - automatically saves stack files I'm working on,
> compresses them, and uploads them to their respective
> locations on the server where the client standalone
> will find them.
>
> Many stack files are so small that the compression
> isn't really necessary, but I'm picky about performance
> and it never hurts to reduce transfer times where that
> can be done as easily as using LC's built-in compress
> and decompress functions.
>
>
>
> This setup lets us enhance and refine all aspects of the system at any
> time, and the user never needs to update the standalone they've installed.
> They just launch the app and since everything we write comes from the
> server they always have the latest build.
>
> I've had more than a few times when I've been in teleconferences with
> clients where we're discussing new features, and before the meeting is over
> I've already written the code and posted it to the server, and let them
> know that all they have to do to get the new feature is restart the app -
> as close 

Re: JavaScript + LC HTML5 = LiveCode.js

[Richard Gaskin]

Roger Eller wrote:

> I disagree that you might as well be running a desktop app.  The
> download of the helper would only be necessary once (like the old
> RevWeb plugin). Back when we had the RevWeb plugin, my browser based
> apps just worked.
> Being in a position where localized automation is primarily what I
> create for in-house users, this would allow me to update/maintain to
> a single code-source, but without having my hands tied
> capability-wise by the browser.

That's exactly where a standalone is every bit as valuable as Mark was 
suggesting.


We need not make every stack file into a standalone for our users to run it.

All they need is one copy of the LiveCode engine, with just enough code 
so it knows where to download more stack files.


Just as a version of the LC engine as a browser plugin can download and 
run stack files, any standalone already installed on the user's machine 
can do the same.


But like you say, a standalone engine isn't limited to the confines of 
the browser, and devs deploying with a standalone never need to think 
about how to handle UI elements never intended for their app, like how 
to handle the browser's Back button.


In addition to providing a better user experience through a UI dedicated 
to the tasks your app supports, "streaming stacks" can be safer too: 
with the relatively recent addition of the securityPermissions global 
property, it's possible to deliver standalones that download and run 
stacks that are safer than nearly any browser.


Most of my work these days is with "streaming apps" - here's my setup:


Client
--
- Standalone
  Contains only enough code to download one stack file from
  our server.

  This is only a little more than:

 go stack "https://somedomain.com/path/to/mainstackfile.livecode;

  ...with some error-checking and one dialog to report errors if
  encountered.

  This standalone is downloaded and installed this only once.  We may
  update it once every year or two when we truly need to update the
  LC engine version we're using, but those times are rare.


Server - Downloads
--
- Main Library
  This is the stack file that gets downloaded first.  It contains all
  other code and URLs the app will need to download and run other stack
  files.

  We can completely change all aspects of the app by changing this one
  stack file on our server at any time.

- Other stack files, downloaded as needed:

  - login.livecode -- provides a UI for tasks requiring authentication

  - admin.livecode -- UI for admin tasks for those users who've
  authenticated with admin privileges.

  - logs.livecode  -- Viewer for server logs to monitor usage and
  provide diagnostics for errors (see below),

  - other stacks   -- We can create and upload any task-specific UI
  and/or code as needed, and download-n-run it
  from any other.

Server - Processing
---
- LC standalone or LC Server running as CGI under Apache, providing:

   - data store access through REST API with CRUD operations

   - authentication and other user services

   - logging

   - anything else we need on the server to support user-specific data
 management and sharing of data for collaborative workflows.



Development
---
- Upload Tool - automatically saves stack files I'm working on,
compresses them, and uploads them to their respective
locations on the server where the client standalone
will find them.

Many stack files are so small that the compression
isn't really necessary, but I'm picky about performance
and it never hurts to reduce transfer times where that
can be done as easily as using LC's built-in compress
and decompress functions.



This setup lets us enhance and refine all aspects of the system at any 
time, and the user never needs to update the standalone they've 
installed.  They just launch the app and since everything we write comes 
from the server they always have the latest build.


I've had more than a few times when I've been in teleconferences with 
clients where we're discussing new features, and before the meeting is 
over I've already written the code and posted it to the server, and let 
them know that all they have to do to get the new feature is restart the 
app - as close to real-time updates as one could hope for.


Getting started doesn't require all these parts; I started out with just 
one standalone downloading one stack file, and added other capabilities 
as I went along.


In fact, as things progress I'm making more use of substacks within the 
main downloaded stack file.  This makes things easier for me to build 
and keep track of, and since we don't use a lot of heavy media files 
like full-screeen raster images, the most complex UI I manage (which has 
dozens of substacks) 

Re: JavaScript + LC HTML5 = LiveCode.js

[Peter TB Brett]

On 25/11/2016 04:38, Todd Fabacher wrote:


Mark, One question I had that was NOT answered is..Can a JavaScript
function call a LiveCode function? I know this was added in the LC8 browser.


Hi Todd,

Mark and Kevin are on holiday today, but I'll try and address this for you.

At the moment, JavaScript functions cannot call LiveCode functions.  Our 
current plan is to make this work in December or January.


It will be more difficult to implement than the new "do script as 
JavaScript" feature, but much easier than making the "url" chunk work 
the same way as on other platforms.


The latest idea we've had to make this happen is to let you set the 
"javaScriptHandlers" property on a stack.  This will be a list of 
message names that the web page is allowed to send to the stack.


We'll then add a JavaScript function to the standalone, that lets you 
send a message to the current "defaultStack".  For example:


Module.LiveCodeSendMessage("", ["", ""])

If  is not among the lines of the "javaScriptHandlers" of the 
defaultStack, then it'll be ignored.  Otherwise, it'll be sent to the 
current card of the defaultStack, just like "backKey" message on mobile 
platforms, for example.


That's the current plan, anyway.  No doubt it will change a bit once we 
start working on it.  Does that broadly answer your question?


Best regards,

   Peter

--
Dr Peter Brett 
LiveCode Technical Project Manager

lcb-mode for Emacs: https://github.com/peter-b/lcb-mode

___
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: JavaScript + LC HTML5 = LiveCode.js

[Todd Fabacher]

Hello Roger, you need to remember almost 50% of web users are on a
non-desktop OS, and almost none of them support plugins like you are
describing. LC HTML5 is what it is...It is an App running in an HTML5
canvas. We will be limited that those restrictions. But I understand where
you are coming from.

What I would like to focus on is what are the current possibilities that we
can capitalize on with the JavaScript integration - NOW. I need a
functioning HTML5 data entry clint for several Apps we are developing.

Mark, One question I had that was NOT answered is..Can a JavaScript
function call a LiveCode function? I know this was added in the LC8 browser.

How do we get started and have the community involved? We can do it and
give it to everyone like we have been doing, but I would like to see if we
can get several people involved who are passionate about making LC HTML5
easier and  more successful. We code just want to do it our way, but the
middle ground so more people will use it, and improve it. Richard, Any
ideas?

--Todd


>I disagree that you might as well be running a desktop app.  The download
>of the helper would only be necessary once (like the old RevWeb plugin).
>Back when we had the RevWeb plugin, my browser based apps just worked.
>Being in a position where localized automation is primarily what I create
>for in-house users, this would allow me to update/maintain to a single
>code-source, but without having my hands tied capability-wise by the
>browser.

>~Roger
___
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: JavaScript + LC HTML5 = LiveCode.js

[Sannyasin Brahmanathaswami]

I too never quite understood why the RevWeb Plugin was abandoned. The old issue 
that users resist such downloads, never, IMHO, really materialized… just look 
at the kJillion extensions for FireFox or Chrome, there is no end in sight.

So the plugin was abandoned, but in the end, hasn't  the team has built the 
same thing?

 Enscripten with a wrapper for LC?

But instead of being able to deliver that as a "player"  … now the user is 
forced to download that entire source code with each and every Html5 app built 
with LC. 

I get of course that the framework of the RevWeb Plugin was a completely 
different architecture… and moving to JS means the browser as an "OS" will be 
more "at peace with the code,"  so to speak, but yet, why could it not be 
externalized as a plug-in/helper/player?

I must be very naïve and missing something….perhaps security issues require us 
to bundle the code with each app, so that 3rd parties can't hack the player for 
nefarious ends… as Mark says: legions are trying to find ways to break through 
to your HD… 

BR
 

On 11/24/16, 10:42 AM, "use-livecode on behalf of Roger Eller" 
 wrote:

I disagree that you might as well be running a desktop app.  The download
of the helper would only be necessary once (like the old RevWeb plugin).
Back when we had the RevWeb plugin, my browser based apps just worked.
Being in a position where localized automation is primarily what I create
for in-house users, this would allow me to update/maintain to a single
code-source, but without having my hands tied capability-wise by the
browser.

~Roger

___
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: JavaScript + LC HTML5 = LiveCode.js

[Roger Eller]

I disagree that you might as well be running a desktop app.  The download
of the helper would only be necessary once (like the old RevWeb plugin).
Back when we had the RevWeb plugin, my browser based apps just worked.
Being in a position where localized automation is primarily what I create
for in-house users, this would allow me to update/maintain to a single
code-source, but without having my hands tied capability-wise by the
browser.

~Roger


On Thu, Nov 24, 2016 at 3:08 PM, Mark Waddingham  wrote:

> The connection could possibly be made by using web sockets I guess
> (someone correct me if I'm wrong).
>
> However, the user would have to download, install and run the helper
> process... At which point you might as well be running a desktop
> app I'd think.
>
> Browsers do not and will almost certainly never allow execution of
> (native) subprocesses via JavaScript. (Nor any kind of native code which is
> not part of the browser executable - well, outside the browsers very tight
> sandbox).
>
> Mark.
>
>
>
> Sent from my iPhone
>
> > On 24 Nov 2016, at 20:00, Roger Eller 
> wrote:
> >
> > Mark,
> >
> > Would it be possible to have a LC executable (something resembling LC
> > Server) on a Desktop, allowing the browser to access the local machine by
> > way of that backgrounded process?  Could it be an out of the box
> capability
> > only turned on by the machine's primary user, via the html5 application
> > before it fully launches?  Similar to how Android tells the user what
> > permissions are needed is how I imagine it would present itself.
> >
> > ~Roger
>
___
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: JavaScript + LC HTML5 = LiveCode.js

[Mark Waddingham]

I should perhaps say that whilst what I'm saying above sounds somewhat doom and 
gloom, it isn't.

Browsers have a huge responsibility to keep your computer safe from malicious 
attack (there are people who spend all their time trying to find holes to 
wriggle through and then exploit).

Browser JS APIs are rich and diverse, and become more so each year.

For most things it will be a case of 'when', and not 'if'.

Sent from my iPhone

> On 24 Nov 2016, at 20:08, Mark Waddingham  wrote:
> 
> The connection could possibly be made by using web sockets I guess (someone 
> correct me if I'm wrong).
> 
> However, the user would have to download, install and run the helper 
> process... At which point you might as well be running a desktop
> app I'd think.
> 
> Browsers do not and will almost certainly never allow execution of (native) 
> subprocesses via JavaScript. (Nor any kind of native code which is not part 
> of the browser executable - well, outside the browsers very tight sandbox).
> 
> Mark.
> 
> 
> 
> Sent from my iPhone
> 
>> On 24 Nov 2016, at 20:00, Roger Eller  wrote:
>> 
>> Mark,
>> 
>> Would it be possible to have a LC executable (something resembling LC
>> Server) on a Desktop, allowing the browser to access the local machine by
>> way of that backgrounded process?  Could it be an out of the box capability
>> only turned on by the machine's primary user, via the html5 application
>> before it fully launches?  Similar to how Android tells the user what
>> permissions are needed is how I imagine it would present itself.
>> 
>> ~Roger
>> 
>> 
>> 
>> Roger Eller
>> Graphics Systems Analyst
>> 
>> 803 North Maple Street P: 864.967.1625
>> Simpsonville, SC 29681 C: 864.908.0337
>> SealedAir.com  roger.e.el...@sealedair.com
>> 
>> 
>> 
>> 
>>> On Thu, Nov 24, 2016 at 2:40 PM, Mark Waddingham  wrote:
>>> 
>>> Indeed.
>>> 
>>> Once we have JS which 'does a similar thing' to answer file (or any other
>>> OS related piece of syntax) - hooking it up to that command is relatively
>>> straightforward.
>>> 
>>> The hard part is writing the JavaScript implementations of the various OS
>>> services we are so used to using directly in LC.
>>> 
>>> It is important to remember that browsers give no direct access to OS
>>> APIs, they are sandboxed and attempt to mitigate security issues as much as
>>> they can.
>>> 
>>> The only system type functionality you get is that exposed by supported JS
>>> APIs a given browser has.
>>> 
>>> Mark.
>>> 
>>> Sent from my iPhone
>>> 
> On 24 Nov 2016, at 18:41, Roger Eller 
 wrote:
 
 File picker should not have to be built in another language, in my
 opinion.  Ask or Answer file SHOULD just work.  Again, my opinion.  This
>>> is
 LiveCode after all.
 
 ~Roger
 
> On Nov 24, 2016 10:49 AM, "Todd Fabacher"  wrote:
> 
> Hello LiveCode community,
> 
> At Digital Pomegranate we are very excited about the update to LiveCode
> HTML5. We already have several projects that we plan on using the
>>> platform
> for. Since our LiveCode team has only a little experience in
>>> JavaScript, we
> are thinking of creating a LiveCode.js. This will be both a LC substack
> that wraps a Javascript function library which would be in a file named
> LiveCode.js.
> 
> Our thinking is it would have 5+ core functionalities that woul dbe
>>> shared
> by most HTML5 apps.  I think this would be a great community project and
> help people who may not be so familiar with Javascript and can stay
>>> focused
> on LiceCode.
> 
> Communications
> tsNet has given LiveCode async server communications, the good news is
> Javascript has had this functionality for quite some time. We would
>>> need a
> simple wrapper of the XMLHttpRequest functionality in LiveCode.js, so it
> seems seamless in Livecode.
> 
> I know LC can call the browser's javascript, but can the JS do a
>>> callback
> to LiveCode? It would be great if we could do sockets in JS and create a
> two way communications system.
> 
> RestAPI services
> I have seen recent notes about using revIgniter as a REST server, and
>>> there
> are many other options available. We use mostly WP and the WP RestAPI.
> 
> Remote Storage
> Mark's LiveCloud is a great option and there are several different
>>> options.
> As I said, we mostly use WP, but we also use Node.js w/ mongodb. The
> LiveCode.js  will just need a simple way of taking XML. JSON or an
>>> encoded
> array and sending it to the remote storage of choice and returning the
> values.
> 
> Local Storage
> The ability to create and use a local DB within the local browser. My
> understanding is that LC HTML5 will not because to utilize the database

Re: JavaScript + LC HTML5 = LiveCode.js

[Mark Waddingham]

The connection could possibly be made by using web sockets I guess (someone 
correct me if I'm wrong).

However, the user would have to download, install and run the helper process... 
At which point you might as well be running a desktop
app I'd think.

Browsers do not and will almost certainly never allow execution of (native) 
subprocesses via JavaScript. (Nor any kind of native code which is not part of 
the browser executable - well, outside the browsers very tight sandbox).

Mark.



Sent from my iPhone

> On 24 Nov 2016, at 20:00, Roger Eller  wrote:
> 
> Mark,
> 
> Would it be possible to have a LC executable (something resembling LC
> Server) on a Desktop, allowing the browser to access the local machine by
> way of that backgrounded process?  Could it be an out of the box capability
> only turned on by the machine's primary user, via the html5 application
> before it fully launches?  Similar to how Android tells the user what
> permissions are needed is how I imagine it would present itself.
> 
> ~Roger
> 
> 
> 
> Roger Eller
> Graphics Systems Analyst
> 
> 803 North Maple Street P: 864.967.1625
> Simpsonville, SC 29681 C: 864.908.0337
> SealedAir.com  roger.e.el...@sealedair.com
> 
> 
> 
> 
>> On Thu, Nov 24, 2016 at 2:40 PM, Mark Waddingham  wrote:
>> 
>> Indeed.
>> 
>> Once we have JS which 'does a similar thing' to answer file (or any other
>> OS related piece of syntax) - hooking it up to that command is relatively
>> straightforward.
>> 
>> The hard part is writing the JavaScript implementations of the various OS
>> services we are so used to using directly in LC.
>> 
>> It is important to remember that browsers give no direct access to OS
>> APIs, they are sandboxed and attempt to mitigate security issues as much as
>> they can.
>> 
>> The only system type functionality you get is that exposed by supported JS
>> APIs a given browser has.
>> 
>> Mark.
>> 
>> Sent from my iPhone
>> 
 On 24 Nov 2016, at 18:41, Roger Eller 
>>> wrote:
>>> 
>>> File picker should not have to be built in another language, in my
>>> opinion.  Ask or Answer file SHOULD just work.  Again, my opinion.  This
>> is
>>> LiveCode after all.
>>> 
>>> ~Roger
>>> 
 On Nov 24, 2016 10:49 AM, "Todd Fabacher"  wrote:
 
 Hello LiveCode community,
 
 At Digital Pomegranate we are very excited about the update to LiveCode
 HTML5. We already have several projects that we plan on using the
>> platform
 for. Since our LiveCode team has only a little experience in
>> JavaScript, we
 are thinking of creating a LiveCode.js. This will be both a LC substack
 that wraps a Javascript function library which would be in a file named
 LiveCode.js.
 
 Our thinking is it would have 5+ core functionalities that woul dbe
>> shared
 by most HTML5 apps.  I think this would be a great community project and
 help people who may not be so familiar with Javascript and can stay
>> focused
 on LiceCode.
 
 Communications
 tsNet has given LiveCode async server communications, the good news is
 Javascript has had this functionality for quite some time. We would
>> need a
 simple wrapper of the XMLHttpRequest functionality in LiveCode.js, so it
 seems seamless in Livecode.
 
 I know LC can call the browser's javascript, but can the JS do a
>> callback
 to LiveCode? It would be great if we could do sockets in JS and create a
 two way communications system.
 
 RestAPI services
 I have seen recent notes about using revIgniter as a REST server, and
>> there
 are many other options available. We use mostly WP and the WP RestAPI.
 
 Remote Storage
 Mark's LiveCloud is a great option and there are several different
>> options.
 As I said, we mostly use WP, but we also use Node.js w/ mongodb. The
 LiveCode.js  will just need a simple way of taking XML. JSON or an
>> encoded
 array and sending it to the remote storage of choice and returning the
 values.
 
 Local Storage
 The ability to create and use a local DB within the local browser. My
 understanding is that LC HTML5 will not because to utilize the database
 library, so we will have to use Javascript localStorage. We just need to
 create a controller that will connect LC to create, read and write to
>> the
 local DB. Javascript even has a way to store the DB and can be accessed
>> for
 the next session.
 
 http://www.w3schools.com/html/html5_webstorage.asp
 
 File Picker & Uploaded
 Not use how to do this in HTML5, but we will need a way to select a file
 and upload it to a server. We could use an HTML+JS dialog box to do it.
 
 Best,
 
 Todd
 ___
 use-livecode mailing list
 

Re: JavaScript + LC HTML5 = LiveCode.js

[Roger Eller]

Mark,

Would it be possible to have a LC executable (something resembling LC
Server) on a Desktop, allowing the browser to access the local machine by
way of that backgrounded process?  Could it be an out of the box capability
only turned on by the machine's primary user, via the html5 application
before it fully launches?  Similar to how Android tells the user what
permissions are needed is how I imagine it would present itself.

~Roger



Roger Eller
Graphics Systems Analyst

803 North Maple Street P: 864.967.1625
Simpsonville, SC 29681 C: 864.908.0337
SealedAir.com  roger.e.el...@sealedair.com




On Thu, Nov 24, 2016 at 2:40 PM, Mark Waddingham  wrote:

> Indeed.
>
> Once we have JS which 'does a similar thing' to answer file (or any other
> OS related piece of syntax) - hooking it up to that command is relatively
> straightforward.
>
> The hard part is writing the JavaScript implementations of the various OS
> services we are so used to using directly in LC.
>
> It is important to remember that browsers give no direct access to OS
> APIs, they are sandboxed and attempt to mitigate security issues as much as
> they can.
>
> The only system type functionality you get is that exposed by supported JS
> APIs a given browser has.
>
> Mark.
>
> Sent from my iPhone
>
> > On 24 Nov 2016, at 18:41, Roger Eller 
> wrote:
> >
> > File picker should not have to be built in another language, in my
> > opinion.  Ask or Answer file SHOULD just work.  Again, my opinion.  This
> is
> > LiveCode after all.
> >
> > ~Roger
> >
> >> On Nov 24, 2016 10:49 AM, "Todd Fabacher"  wrote:
> >>
> >> Hello LiveCode community,
> >>
> >> At Digital Pomegranate we are very excited about the update to LiveCode
> >> HTML5. We already have several projects that we plan on using the
> platform
> >> for. Since our LiveCode team has only a little experience in
> JavaScript, we
> >> are thinking of creating a LiveCode.js. This will be both a LC substack
> >> that wraps a Javascript function library which would be in a file named
> >> LiveCode.js.
> >>
> >> Our thinking is it would have 5+ core functionalities that woul dbe
> shared
> >> by most HTML5 apps.  I think this would be a great community project and
> >> help people who may not be so familiar with Javascript and can stay
> focused
> >> on LiceCode.
> >>
> >> Communications
> >> tsNet has given LiveCode async server communications, the good news is
> >> Javascript has had this functionality for quite some time. We would
> need a
> >> simple wrapper of the XMLHttpRequest functionality in LiveCode.js, so it
> >> seems seamless in Livecode.
> >>
> >> I know LC can call the browser's javascript, but can the JS do a
> callback
> >> to LiveCode? It would be great if we could do sockets in JS and create a
> >> two way communications system.
> >>
> >> RestAPI services
> >> I have seen recent notes about using revIgniter as a REST server, and
> there
> >> are many other options available. We use mostly WP and the WP RestAPI.
> >>
> >> Remote Storage
> >> Mark's LiveCloud is a great option and there are several different
> options.
> >> As I said, we mostly use WP, but we also use Node.js w/ mongodb. The
> >> LiveCode.js  will just need a simple way of taking XML. JSON or an
> encoded
> >> array and sending it to the remote storage of choice and returning the
> >> values.
> >>
> >> Local Storage
> >> The ability to create and use a local DB within the local browser. My
> >> understanding is that LC HTML5 will not because to utilize the database
> >> library, so we will have to use Javascript localStorage. We just need to
> >> create a controller that will connect LC to create, read and write to
> the
> >> local DB. Javascript even has a way to store the DB and can be accessed
> for
> >> the next session.
> >>
> >> http://www.w3schools.com/html/html5_webstorage.asp
> >>
> >> File Picker & Uploaded
> >> Not use how to do this in HTML5, but we will need a way to select a file
> >> and upload it to a server. We could use an HTML+JS dialog box to do it.
> >>
> >> Best,
> >>
> >> Todd
> >> ___
> >> 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:
> 

Re: JavaScript + LC HTML5 = LiveCode.js

[Mark Waddingham]

Indeed.

Once we have JS which 'does a similar thing' to answer file (or any other OS 
related piece of syntax) - hooking it up to that command is relatively 
straightforward.

The hard part is writing the JavaScript implementations of the various OS 
services we are so used to using directly in LC.

It is important to remember that browsers give no direct access to OS APIs, 
they are sandboxed and attempt to mitigate security issues as much as they can.

The only system type functionality you get is that exposed by supported JS APIs 
a given browser has.

Mark.

Sent from my iPhone

> On 24 Nov 2016, at 18:41, Roger Eller  wrote:
> 
> File picker should not have to be built in another language, in my
> opinion.  Ask or Answer file SHOULD just work.  Again, my opinion.  This is
> LiveCode after all.
> 
> ~Roger
> 
>> On Nov 24, 2016 10:49 AM, "Todd Fabacher"  wrote:
>> 
>> Hello LiveCode community,
>> 
>> At Digital Pomegranate we are very excited about the update to LiveCode
>> HTML5. We already have several projects that we plan on using the platform
>> for. Since our LiveCode team has only a little experience in JavaScript, we
>> are thinking of creating a LiveCode.js. This will be both a LC substack
>> that wraps a Javascript function library which would be in a file named
>> LiveCode.js.
>> 
>> Our thinking is it would have 5+ core functionalities that woul dbe shared
>> by most HTML5 apps.  I think this would be a great community project and
>> help people who may not be so familiar with Javascript and can stay focused
>> on LiceCode.
>> 
>> Communications
>> tsNet has given LiveCode async server communications, the good news is
>> Javascript has had this functionality for quite some time. We would need a
>> simple wrapper of the XMLHttpRequest functionality in LiveCode.js, so it
>> seems seamless in Livecode.
>> 
>> I know LC can call the browser's javascript, but can the JS do a callback
>> to LiveCode? It would be great if we could do sockets in JS and create a
>> two way communications system.
>> 
>> RestAPI services
>> I have seen recent notes about using revIgniter as a REST server, and there
>> are many other options available. We use mostly WP and the WP RestAPI.
>> 
>> Remote Storage
>> Mark's LiveCloud is a great option and there are several different options.
>> As I said, we mostly use WP, but we also use Node.js w/ mongodb. The
>> LiveCode.js  will just need a simple way of taking XML. JSON or an encoded
>> array and sending it to the remote storage of choice and returning the
>> values.
>> 
>> Local Storage
>> The ability to create and use a local DB within the local browser. My
>> understanding is that LC HTML5 will not because to utilize the database
>> library, so we will have to use Javascript localStorage. We just need to
>> create a controller that will connect LC to create, read and write to the
>> local DB. Javascript even has a way to store the DB and can be accessed for
>> the next session.
>> 
>> http://www.w3schools.com/html/html5_webstorage.asp
>> 
>> File Picker & Uploaded
>> Not use how to do this in HTML5, but we will need a way to select a file
>> and upload it to a server. We could use an HTML+JS dialog box to do it.
>> 
>> Best,
>> 
>> Todd
>> ___
>> 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: JavaScript + LC HTML5 = LiveCode.js

[Roger Eller]

File picker should not have to be built in another language, in my
opinion.  Ask or Answer file SHOULD just work.  Again, my opinion.  This is
LiveCode after all.

~Roger

On Nov 24, 2016 10:49 AM, "Todd Fabacher"  wrote:

> Hello LiveCode community,
>
> At Digital Pomegranate we are very excited about the update to LiveCode
> HTML5. We already have several projects that we plan on using the platform
> for. Since our LiveCode team has only a little experience in JavaScript, we
> are thinking of creating a LiveCode.js. This will be both a LC substack
> that wraps a Javascript function library which would be in a file named
> LiveCode.js.
>
> Our thinking is it would have 5+ core functionalities that woul dbe shared
> by most HTML5 apps.  I think this would be a great community project and
> help people who may not be so familiar with Javascript and can stay focused
> on LiceCode.
>
> Communications
> tsNet has given LiveCode async server communications, the good news is
> Javascript has had this functionality for quite some time. We would need a
> simple wrapper of the XMLHttpRequest functionality in LiveCode.js, so it
> seems seamless in Livecode.
>
> I know LC can call the browser's javascript, but can the JS do a callback
> to LiveCode? It would be great if we could do sockets in JS and create a
> two way communications system.
>
> RestAPI services
> I have seen recent notes about using revIgniter as a REST server, and there
> are many other options available. We use mostly WP and the WP RestAPI.
>
> Remote Storage
> Mark's LiveCloud is a great option and there are several different options.
> As I said, we mostly use WP, but we also use Node.js w/ mongodb. The
> LiveCode.js  will just need a simple way of taking XML. JSON or an encoded
> array and sending it to the remote storage of choice and returning the
> values.
>
> Local Storage
> The ability to create and use a local DB within the local browser. My
> understanding is that LC HTML5 will not because to utilize the database
> library, so we will have to use Javascript localStorage. We just need to
> create a controller that will connect LC to create, read and write to the
> local DB. Javascript even has a way to store the DB and can be accessed for
> the next session.
>
> http://www.w3schools.com/html/html5_webstorage.asp
>
> File Picker & Uploaded
> Not use how to do this in HTML5, but we will need a way to select a file
> and upload it to a server. We could use an HTML+JS dialog box to do it.
>
> Best,
>
> Todd
> ___
> 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

JavaScript + LC HTML5 = LiveCode.js

[Todd Fabacher]

Hello LiveCode community,

At Digital Pomegranate we are very excited about the update to LiveCode
HTML5. We already have several projects that we plan on using the platform
for. Since our LiveCode team has only a little experience in JavaScript, we
are thinking of creating a LiveCode.js. This will be both a LC substack
that wraps a Javascript function library which would be in a file named
LiveCode.js.

Our thinking is it would have 5+ core functionalities that woul dbe shared
by most HTML5 apps.  I think this would be a great community project and
help people who may not be so familiar with Javascript and can stay focused
on LiceCode.

Communications
tsNet has given LiveCode async server communications, the good news is
Javascript has had this functionality for quite some time. We would need a
simple wrapper of the XMLHttpRequest functionality in LiveCode.js, so it
seems seamless in Livecode.

I know LC can call the browser's javascript, but can the JS do a callback
to LiveCode? It would be great if we could do sockets in JS and create a
two way communications system.

RestAPI services
I have seen recent notes about using revIgniter as a REST server, and there
are many other options available. We use mostly WP and the WP RestAPI.

Remote Storage
Mark's LiveCloud is a great option and there are several different options.
As I said, we mostly use WP, but we also use Node.js w/ mongodb. The
LiveCode.js  will just need a simple way of taking XML. JSON or an encoded
array and sending it to the remote storage of choice and returning the
values.

Local Storage
The ability to create and use a local DB within the local browser. My
understanding is that LC HTML5 will not because to utilize the database
library, so we will have to use Javascript localStorage. We just need to
create a controller that will connect LC to create, read and write to the
local DB. Javascript even has a way to store the DB and can be accessed for
the next session.

http://www.w3schools.com/html/html5_webstorage.asp

File Picker & Uploaded
Not use how to do this in HTML5, but we will need a way to select a file
and upload it to a server. We could use an HTML+JS dialog box to do it.

Best,

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