LiveCode Forums

working well on my Windows desktop using Google Chrome browser

but, extremely slowly on MacOS 10.15.2 with Waterfox.

AND, pardon my ignorance, but what is this?
-

Richmond wrote:... AND, pardon my ignorance, but what is this?

This is a demo for at least medium advanced developers. (Honestly, I expect you to have such a level.)
Read more about the demo here: viewtopic.php?p=185726#p185726

Honestly, I expect you to have such a level.

Why?

The last time I touched ANYTHING outside LiveCode in any sort of serious way was Visual BASIC 5 in 2003.

I develop within an extremely limited field for desktop machines only, using only LiveCode.

I would also be interested to find out where I have ever claimed to be a "Medium Advanced" developer.

I have developed Devawriter Pro, and it does what it is supposed to do relatively well; but,
give the ease of use of LiveCode and my reasonable grasp of both logic and dead Indian
languages that doesn't actually say much about my level as a developer at all.

In fact, if truth be known, quite a few people have over-estimated my capabilities, then
when they have been disappointed by work that I have done, have turned around and got stroppy
with me. This says something odd about human nature.

Don't you read before you click on a link?

Don't you read before you click on a link?

Is that aimed at me?

Yes, it is.

I did:

I am really impressed by your online stacks.

and

http://hyperhh.de/html5/html5IDE.html

did NOT look like a LiveCode stack!

@Richmond.

Of course a "playground" (will become soon a primitive IDE) doesn't look like a LiveCode stack.

The purpose of my HTML5 examples is to show some aspects of what is possible to have in HTML5 standalones.
All examples were made parallel to the evolving features of HTML5 deployment since 2015, so some could meanwhile be done more elegant.
The last few "native" examples combine LCScript with HTML5 tools coming from the browser. By that we can have, for example, native fields in a HTML5 standalone, needs elementary javaScript only.

The "playground" is meanwhile, here in my next version, moreover in a state, that we can save and load local "ordinary" stack files. That is, you don't have to compile such stacks: It is kind of a primitive IDE running in the browser. After loading the resources from the server, everything is done client side.

Of course such stacks can't contain features that don't work in a HTML5 standalone, for example some widgets. Also "wait" doesn't work and writing to local files is limited (due to security reasons). And the stacks should run "correctly", there is no debugger in the "playground".

Of course a "playground" (will become soon a primitive IDE) doesn't look like a LiveCode stack.

Thanks for taking the time to explain that.

Of course such stacks can't contain features that don't work in a HTML5 standalone, for example some widgets.

Maybe I'm being a bit picky, but I have never thought of LiveCode widgets as being a part of the LiveCode language,
more as 'cherries' (as in 'cherries on a cake') one can add on top of a stack.

When I teach introductory LiveCode lessons to children (and in my current effort for pensioners) I do NOT make
use of widgets at all.

I feel that widgets tend to detract from the claims that are made that LiveCode is a complete language within itself
that does not need add-ons.

I would expect an HTML standalone to function as a stack did in LiveCode pre the widget era.

-----

This explains (if you noticed) my push a few years ago for SVG images to be imported into LiveCode as scaleable
graphic objects rather than as SVG widgets.