Re: Web vs Native (was Re: HTML5 limitations?)

[Sannyasin Brahmanathaswami via use-livecode]

Wow! 

Quite the discussion! and here I was away from the list adding one last (hehe 
maybe not) feature to V1 of the SivaSiva app (hope to release by Aug 15) which 
was to create a "news channel" of course the obvious way to do this is have an 
HTML page on line, that you call into a browser widget. So easy! parse a date 
string, if the on lline version is > then "You have news!"  

So for the first time I mapped four buttons  in the html to 4 js handlers  to 
navigation handlers in our LC app framework and "Oh… My…. it works!"

So, the "pragmatic" way to go is to get the widget into to msg path… when you 
can digest that. 

Thanks Mark for letting us know are listening and for all the detail on the 
issues. It's very encouragagin.

Suggest we split the HTML5 Deployment discussion  from the 
browser-widget-in-the-message-path.

for others list: you may recall that we did ask for an estimate on the cost of 
this. You can find the response on the QA, I think the business response was 
"We need $14,000.00" to implement.  So, when you *do* finish digesting all the 
buffet in front of you, please *do* put this up 
"browser-widget-in-the-message-path" for crowd funding. I am in… 

the HTML5 thing IMHO is a completely different animal. 

a) looks great for building small experiences, but then the download time for 
the engine is wy too long.
b) using it for a really robust, complex application… looks so very difficult 
to implement (as Mark has explained)

so, frankly, I must be dense, but I don't yet see why this is so important… if 
you or you company wants to do "web" why not just do web? (php, js, html5, 
livecode-server-rev-igniter)

As have mentioned to HQ off list: While Andre's depth/breadth of experience 
makes it easy for him to talk about "web is the way"  there is a whole new 
"market" coming online: Print business is dying. "kajillion" graphics arts 
designers are in the position of having meetings where, instead of discussing 
the next ink-on-paper book project, they publishing/media team is talking about 
the "digital coloring book"   And this is Adobe's big, HUGE focus right now… 
(which just proves my point)

Meanwhile the expertise to actually get that done is not present in the team 
(this is happening here.) So there is a lot or pressure for very smart people 
who want to build apps, to get on this digital revolution/train… 

THEY WILL NEVER LEARN JS, PYTHON, REACT (whatever flavor of the month js 
frameowrk is the current fad…) OR PHP! Period! And Adobe's offereings to this 
market  are 
a) expensive and 
b) not so great  (some reallly horrible UX by a company that should know 
better…. they are fishing! When I see some stuff they do I think "sheesh I 
could build this in LC in a week and it would be so much better")

And this "media staff" market   *all* have money… IMHO LC needs to get back to 
a low priced entry point/over full set of features for basic app delivery MINUS 
key business/enterprise add ons.   Then target the *same* market that adobe is 
now…

And there is also a secondary market among experienced JS coders… I have met a 
least 3 in the past few month (lots of hi-tech IT visitors here)  who are very, 
very jaded "been doing Javascript since I was 17… getting sick of it every few 
months a new framework. Another snakepit of libraries….spend all my time 
migrating, debugging, no fun any more… no time to really build content, just 
wallowing in code all day long… very little output. at the end of the week I 
got 4-5 screens working "

 and having "fun again" programming… LC wrapping a widget with just enough JS 
for the eye candy will be a very, very cool part of their toolbox. 

So, *after* you do get "browser-widget-in-the-message-path"  + a low buy in 
entry point  IMHO you can "market this thing to the moon."   to both the entire 
publishing industry AND the current legions of JS coders.  They wll just have 
so much fun with it… will be like cotton candy…

disclaimer: predictions about the future of IT is close to predicting the 
weather on Kauai 

BR

  
On 7/28/17, 5:57 AM, "use-livecode on behalf of Mark Waddingham via 
use-livecode"  wrote:

I can assure you your 'prayer' has been heard - however, there is a 
slight chasm between hearing a prayer and being able to act on it 
(especially for mere mortals, like ourselves ;)).

There is a whole (reasonably sized) 'new market' for LiveCode in the 
space of providing the shell into which HTML5/JS webapps can be placed. 
i.e. The creation of a native app which wraps a HTML5/JS web-app which 
then has direct access to all the platform features LiveCode gives you 
access to (a bit like PhoneGap or Cordova or ... - the fact there are so 
many of these things suggests that it is a very useful thing that people 
actually want to do). Now, this works quite well right now - although I 
do appreciate 

Re: Web vs Native (was Re: HTML5 limitations?)

[Mark Waddingham via use-livecode]

On 2017-07-29 13:10, Jonathan Lynch via use-livecode wrote:

So... if we use the wait command, and deploy to HTML5, the engine
converts it to JavaScript with extra functions because the engine
added in asynchronous timeouts? And you preserve all the variable
values of the source LC script across these multiple functions?


Yes - that is essentially the 'asyncify' transformation as pertains to 
'leaf' functions (those which call no other wait calling functions).



This was the easy solution?


Easy is always a comparative assertion (there's a reason I always say: 
'easy', for some definition of 'easy').



Either I am misunderstanding, or the concept of what is difficult in
Scotland is shedloads harder than what we puny Americans think.


Heh - I must confess first thing this morning (6am, after 4 hours sleep 
- I perhaps shouldn't have stayed up until 2am writing that lengthy 
email on this topic to here last night) I honestly couldn't 'parse' that 
sentence. I know get it completely - I must make a mental note to 
perhaps not read and reply to mailing lists until I've been awake for at 
least an hour, and had a suitable amount of coffee :)


Anyway, this thread has now spiralled into a behemoth - so I'm going to 
start a new one on this topic to stop it getting lost in a sea of 
not-quite-related things.


[ Also it gives me something to do whilst flying over the USA - 
currently somewhere between Kansas City and Springfield looking at our 
trajectory (this brings up all kinds of images in my mind - Simpsons and 
Wizard-of-Oz crossover anyone?) ]


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: Web vs Native (was Re: HTML5 limitations?)

[Jonathan Lynch via use-livecode]

Hi Jim,

One can have interruptible animations by using a handler that progresses the 
movement a single step, then calls itself using a send-in-time construction to 
initiate the next step.

I recently posted a momentum scrolling script on this list that uses this 
technique. Does that help?

Sent from my iPhone

> On Jul 29, 2017, at 2:51 PM, Jim Lambert via use-livecode 
>  wrote:
> 
>> On 7/28/17 1:14 PM, Mark Waddingham via use-livecode wrote:
>> 
>> I think the first thing we would need would be builtin 
>> gesture support. In this case, this isn't even 'a gesture has happened' 
>> but 'it looks like a swipe is just starting' (I think at least). e.g. 
>> swipeBegin / swipeContinue / swipeEnd / swipeCancel.
>> 
>> We'd probably also want a 'swipe' message at the end - i.e. there are 
>> cases where it is the fact that 'swipe' has happened that you want, and 
>> not the details of the process it went through (perhaps swipeEnd would 
>> be fine here, though).
>> 
>> I do like the idea of having the animation of a gesture in the UI being 
>> tied to the event - its a nice low-code approach for a very common 
>> problem.
> 
> How might LC support interactive and interruptible animations as shown in 
> this video on Advanced Animations with UIKit?
> https://developer.apple.com/videos/play/wwdc2017/230/ 
> 
> 
> This capability is generally applicable to any animation using UIKit. Even 
> non-moving transitions, such as blurring, are supported in an interactive way.
> If supported by LC, it would be useable beyond just moving from card to card 
> or swiping out a sidebar.
> 
> But of course, the particular capability shown in the video is OS-specific. 
> Whereas LC strives to be platform agnostic.
> 
> Jim Lambert
> ___
> 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: Web vs Native (was Re: HTML5 limitations?)

[Jim Lambert via use-livecode]

On 7/28/17 1:14 PM, Mark Waddingham via use-livecode wrote:
> 
> I think the first thing we would need would be builtin 
> gesture support. In this case, this isn't even 'a gesture has happened' 
> but 'it looks like a swipe is just starting' (I think at least). e.g. 
> swipeBegin / swipeContinue / swipeEnd / swipeCancel.
> 
> We'd probably also want a 'swipe' message at the end - i.e. there are 
> cases where it is the fact that 'swipe' has happened that you want, and 
> not the details of the process it went through (perhaps swipeEnd would 
> be fine here, though).
> 
> I do like the idea of having the animation of a gesture in the UI being 
> tied to the event - its a nice low-code approach for a very common 
> problem.

How might LC support interactive and interruptible animations as shown in this 
video on Advanced Animations with UIKit?
https://developer.apple.com/videos/play/wwdc2017/230/ 


This capability is generally applicable to any animation using UIKit. Even 
non-moving transitions, such as blurring, are supported in an interactive way.
If supported by LC, it would be useable beyond just moving from card to card or 
swiping out a sidebar.

But of course, the particular capability shown in the video is OS-specific. 
Whereas LC strives to be platform agnostic.

Jim Lambert
___
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: Web vs Native (was Re: HTML5 limitations?)

[Andre Garzia via use-livecode]

Hey,

Mixed answer below:


> - when the app needs access to the phone's functions (notifications, GPS,
> screen dimming, text messages, etc)
>

There are Web APIs for:
* Geolocation https://developer.mozilla.org/en-US/docs/Web/API/Geolocation

* Notification (both local and push):
  - Local: https://developer.mozilla.org/en-US/docs/Web/API/notification
  - Push: https://developer.mozilla.org/en-US/docs/Web/API/Push_API

* screen dimming: I don't know if you want to dim the screen or detect when
the screen was dimmed.
  - Page visibility API:
https://developer.mozilla.org/en-US/docs/Web/API/Page_Visibility_API

* Text messages: considered a high risk of privacy invasion and not allowed.


> - when it's important that at least some of the app's features work in
> degraded/denied signal environments (no/low data)
>

* Service workers can make your app work offline:
https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorker
* Online/Offline events:
https://developer.mozilla.org/en-US/docs/Online_and_offline_events


> - when your users don't understand what they're doing and insist that they
> can't find your web app in the app store
>

* No solution there but you can always wrap it in phonegap and place it
there if you need.


> - when you want to ensure that you control the experience; a web app is
> accessed through the browser which means the browser's navigation and
> settings take priority
>
>
* PWAs once installed can hide the browser navigation controls.
  - more about them https://developer.mozilla.org/en-US/Apps/Progressive

Now, if we could get LC HTML deployment to generate PWAs, thing would be
awesome.
-- 
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: Web vs Native (was Re: HTML5 limitations?)

[Andre Garzia via use-livecode]

Hey,

I think I am on a special position to talk about this as I have been on the
bleeding edge of the Web trenches for a while. Instead of boring everyone
here to death, I will do a quick TL;DR first with the actual info and then
digress a bit about the current situation.

=

WEB:
* The web has less friction, it is easier to get a user to open a page than
to install your software.
* The web has links, where you can change from one site/webapp to another.
Apps tend to prefer siloed approaches.

APPS:
* It is harder to monetize web apps. Apps have the online stores/walled
gardens in their favor.
* Apps have access to APIs that are native to the devices.

==

The web is not controlled by any entity. It is an agreement or compromise
between (too) many stakeholders that goes from browser vendors, to policy
makers, to everyone in between. As it is not tied to a single company such
as iOS or Android, it evolves in multiple directions and every step needs
to be discussed and standardized before it can be truly used, this is its
weakness and strength at the same time. While apps can evolve at the whim
of their vendors.

Still the apps market is in decline, money wise, specially for small ISVs.
Most of the money made on the online stores (iTunes and Google Play) goes
for a dozen companies while thousands upon thousands of ISV don't sell any
license. The average mobile app install rate is ZERO. Most apps have zero
installs. But the lure of the "become a millionaire by selling apps" is too
strong and thousands upon thousands of new apps flood the online stores
every day. Just think about it, couple years go there were HUNDREDS of new
games every day on Google Play. The challenge of app making is not a
technological one but a business/marketing one. The hardest thing is
getting noticed in a market that has thousands alternatives and a customer
prejudice on anything costing more than 0.99.

Web apps are again on the rise with the new PWA paradigm (progressive web
apps, not to mix with progressive enhancement of couple years ago). The
PWAs behave mostly like a native mobile app. They can be installed as in
they will appear with their own icon and their own window on a mobile
phone. They can work offline. They can receive push notifications. They
really look like native because you don't see browser controls or need to
be online. Many popular apps are poised to migrate to PWAs soon. It will
probably begin with content producers such as newspapers. It is much easier
for them to ship a PWA that will work the same on mobile and desktop than
to ship apps, and also evade the 30% fee on the online stores.

Don't look at the web as that thing that displays HTML pages. That is no
longer what it is. The web (browsers) are complex virtual machines, almost
like mini operating systems there days. A Web App can work offline, get rid
of browser controls, send and receive push notifications, have access to
sensor data from the device, use complex OpenGL and Virtual Reality APIs,
use bluetooth, use the camera, connect in realtime with P2P protocols. It
is a very capable and complex platform.

Now, where that leads us LiveCode Developers? We're in the app camp but
with the new HTML export, we might soon be on the web camp as well. The new
"Web Assembly" technology can lead to a very compact and performant LC
engine on the web. Which could lead to very good and flexible deployment
options for everyone here. If RunRev could make the standalone generation
process generate a PWA by default, then, things could get really
interesting.

It is faster and easier to develop with LC than with the Web, I think the
trick is how can we deploy good software made with LC to the Web platform.
If LC can hope on the PWA hypewagon, then, the future is quite bright.

I am more than happy to talk for ages about the Web, heck, I was
contracting for Mozilla not long ago. I have been in and out of standard
meetings, spoke to engine engineers for almost all browser vendors. The Web
is not going away. I believe we need to join it.

On Wed, Jul 26, 2017 at 11:17 AM, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I believe Rick's "Why" here is key to much of what we may be doing over
> the next couple years.
>
> We developers currently find ourselves in a very strange place:
>
> On desktop, the requests are "Web! Web! Web!"
>
> On mobile, they're "Apps! Apps! Apps!"
>
> If the web offers advantages that can't be matched with native apps, why
> is this perceived as true for the desktop but not for mobile?
>
> If native apps offer advantages that can't be matched with the web, why is
> this perceived as true for mobile but not for the desktop?
>
> --
>  Richard Gaskin
>  Fourth World Systems
>  Software Design and Development for the Desktop, Mobile, and the Web
>  
>  ambassa...@fourthworld.comhttp://www.FourthWorld.com
>
>
> Rick Harrison 

Re: Web vs Native (was Re: HTML5 limitations?)

[Jonathan Lynch via use-livecode]

Here is an example of using wait in my app...

It seems to work better if I first load the map, then add markers from my 
database, rather than doing both at once.

There is not a good trigger to detect when the map is fully loaded and 
displayed.

So, I set an event listener for the page load, to trigger loading the markers 
from my server. Page load catches the process about halfway through-the map 
tile images are still loading from Bing.

I added a wait command in LC at this point, to give the widget a bit more time 
to process the map tile images.

Sometimes, webglearth JavaScript can get hung up if the data connection is 
slow. So, at the end of the wait period, I have LC trigger a moveback() 
function to nudge the widget and get the widget to keep loading tiles.

Wait helped because of imperfections in code outside of my control.

I also think wait can be useful inside of a loop that animates a movement, 
where you want to slow it down. However, this could easily be overcome with 
send-in-time handlers.

Sent from my iPhone

> On Jul 29, 2017, at 9:06 AM, jonathandly...@gmail.com wrote:
> 
> You are right, Hermann - did not mean that to be mean-spirited to my home 
> country, which I actually rather love. 
> 
> My apologies.
> 
> I do think that "wait" can be useful sometimes, but not often.
> 
> I was just surprised at the effort they are taking to reproduce "wait" in 
> HTML deployment.
> 
> Sent from my iPhone
> 
>> On Jul 29, 2017, at 8:51 AM, hh via use-livecode 
>>  wrote:
>> 
>> #wait
>> I don't miss the "wait" handler in HTML5 and I wouldn't miss it in LC Script.
>> I even don't know of any use case where "send in " (which works 
>> perfectly
>> in HTML5) isn't superior to "wait". Especially when connected to 
>> move/animation.
>> 
>> Also I don't miss "wait" in LC Builder. There OnTimer() is the superior
>> 'substitute'.
>> 
>> @Jonathan
>> And your 'syncing' skills, demonstrated several times, show that you dont 
>> need
>> it. It's sometimes comfortable to write "wait 1 millisec with messages", but
>> nothing more, it is not an essential command.
>> 
>>> Jonathan wrote:
>>> Either I am misunderstanding, or the concept of what is difficult in 
>>> Scotland
>>> is shedloads harder than what we puny Americans think.
>> 
>> Jonathan, please think about such nasty national statements. There's no need
>> for that.
>> 
>> 
>> ___
>> 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: Web vs Native (was Re: HTML5 limitations?)

[Jonathan Lynch via use-livecode]

You are right, Hermann - did not mean that to be mean-spirited to my home 
country, which I actually rather love. 

My apologies.

I do think that "wait" can be useful sometimes, but not often.

I was just surprised at the effort they are taking to reproduce "wait" in HTML 
deployment.

Sent from my iPhone

> On Jul 29, 2017, at 8:51 AM, hh via use-livecode 
>  wrote:
> 
> #wait
> I don't miss the "wait" handler in HTML5 and I wouldn't miss it in LC Script.
> I even don't know of any use case where "send in " (which works 
> perfectly
> in HTML5) isn't superior to "wait". Especially when connected to 
> move/animation.
> 
> Also I don't miss "wait" in LC Builder. There OnTimer() is the superior
> 'substitute'.
> 
> @Jonathan
> And your 'syncing' skills, demonstrated several times, show that you dont need
> it. It's sometimes comfortable to write "wait 1 millisec with messages", but
> nothing more, it is not an essential command.
> 
>> Jonathan wrote:
>> Either I am misunderstanding, or the concept of what is difficult in Scotland
>> is shedloads harder than what we puny Americans think.
> 
> Jonathan, please think about such nasty national statements. There's no need
> for that.
> 
> 
> ___
> 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: Web vs Native (was Re: HTML5 limitations?)

[Lagi Pittas via use-livecode]

Hi

I took that to be a self-deprecating comment and not anything to be
offended by unless your comment hermann is supposed to be ironic in some
sense?

Regards Lagi

On 29 July 2017 at 13:51, hh via use-livecode  wrote:

> #wait
> I don't miss the "wait" handler in HTML5 and I wouldn't miss it in LC
> Script.
> I even don't know of any use case where "send in " (which works
> perfectly
> in HTML5) isn't superior to "wait". Especially when connected to
> move/animation.
>
> Also I don't miss "wait" in LC Builder. There OnTimer() is the superior
> 'substitute'.
>
> @Jonathan
> And your 'syncing' skills, demonstrated several times, show that you dont
> need
> it. It's sometimes comfortable to write "wait 1 millisec with messages",
> but
> nothing more, it is not an essential command.
>
> > Jonathan wrote:
> > Either I am misunderstanding, or the concept of what is difficult in
> Scotland
> > is shedloads harder than what we puny Americans think.
>
> Jonathan, please think about such nasty national statements. There's no
> need
> for that.
>
>
> ___
> 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: Web vs Native (was Re: HTML5 limitations?)

[hh via use-livecode]

#wait
I don't miss the "wait" handler in HTML5 and I wouldn't miss it in LC Script.
I even don't know of any use case where "send in " (which works perfectly
in HTML5) isn't superior to "wait". Especially when connected to move/animation.

Also I don't miss "wait" in LC Builder. There OnTimer() is the superior
'substitute'.

@Jonathan
And your 'syncing' skills, demonstrated several times, show that you dont need
it. It's sometimes comfortable to write "wait 1 millisec with messages", but
nothing more, it is not an essential command.

> Jonathan wrote:
> Either I am misunderstanding, or the concept of what is difficult in Scotland
> is shedloads harder than what we puny Americans think.

Jonathan, please think about such nasty national statements. There's no need
for that.


___
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: Web vs Native (was Re: HTML5 limitations?)

[Jonathan Lynch via use-livecode]

So... if we use the wait command, and deploy to HTML5, the engine converts it 
to JavaScript with extra functions because the engine added in asynchronous 
timeouts? And you preserve all the variable values of the source LC script 
across these multiple functions?

This was the easy solution?

Either I am misunderstanding, or the concept of what is difficult in Scotland 
is shedloads harder than what we puny Americans think.

Sent from my iPhone

> On Jul 29, 2017, at 4:22 AM, Mark Waddingham via use-livecode 
>  wrote:
> 
>> On 2017-07-29 07:11, J. Landman Gay via use-livecode wrote:
>>> On 7/28/17 7:29 PM, Mark Waddingham via use-livecode wrote:
>>> P.S. At some point I'll write at length about the 'wait' problem in HTML5. 
>>> Whilst I try not to let myself be kept awake at night by engineering 
>>> problems related to work - if ever there was one which did, it would be 
>>> that one!
>> When you recover from sunstroke I'd be interested to hear about that.
> 
> I figured many people would so check the email I just posted - whilst my 
> general irascibility and tendency to 'tilt at windmills' (again, sorry 
> Hermann, and Bob) might go up slightly when suffering from sunstroke, 
> hopefully my technically acuity isn't affected too much!
> 
> 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: Web vs Native (was Re: HTML5 limitations?)

[Mark Waddingham via use-livecode]

On 2017-07-29 07:11, J. Landman Gay via use-livecode wrote:

On 7/28/17 7:29 PM, Mark Waddingham via use-livecode wrote:
P.S. At some point I'll write at length about the 'wait' problem in 
HTML5. Whilst I try not to let myself be kept awake at night by 
engineering problems related to work - if ever there was one which 
did, it would be that one!


When you recover from sunstroke I'd be interested to hear about that.


I figured many people would so check the email I just posted - whilst my 
general irascibility and tendency to 'tilt at windmills' (again, sorry 
Hermann, and Bob) might go up slightly when suffering from sunstroke, 
hopefully my technically acuity isn't affected too much!


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: Web vs Native (was Re: HTML5 limitations?)

[Mark Waddingham via use-livecode]

Indeed! That is the crux of the problem.

Neither Android nor iOS have 'wait' (or the underlying OS feature you need to 
implement it) either. However those platforms have general threads so you can 
emulate it.

HTML5 does not have general threads (although it probably will in about 2-3 
years - assuming none of the big players in effect veto the proposal at some 
point by choosing never to implement the spec currently being worked on) so 
that option is not available in (what is for us) a reasonable timescale (you 
all have already been waiting long enough for us to deliver it, after all!).

As has been discussed about the 'async' problem with the browser widget - the 
wait command (and indirect forms of it - which do in browser is) actually makes 
many kinds of code easier to write and maintain - so it is really important in 
a language which professes to be 'easier' (for some definition of 'easy'). Ergo 
it is really important to be able to support it - however imperfect its 
implementation in LiveCode may be (and it is really quite imperfect - but it 
works!).

Now the situation we are in is purely down to the current implementation of the 
engine and not a problem with the idea. It is the recursive nature of the 
engine's 'vm' implementation and UI framework code (in C++) that is causing us 
the headache.

When I evaluated the HTML5 project I did factor in a significant amount of time 
(and we are talking in man years here - there's a good reason we set out to 
raise what we did) to solve the problem in a worst case scenario - which was 
(in good part) based upon the assumption that the 7 refactor would actually go 
a great deal further than we actually managed with the eventual budget and time 
constraints we were under. (What can I say - we live in an imperfect world - 
events often transpire to bite you in places you really wish they wouldn't!).

Even with hindsight I don't think I could have done any better (not that I'm an 
introspective sort, at all...) Particularly as I had already noticed that some 
things which were being done in emscripten itself could help mitigate the 
problem (there's always risk in estimation of anything, always error - and 
there's only so much time you can spend analysing to mitigate these risks as 
otherwise you would end up never doing anything).

Wind forward a bit - the low-level thing in emscripten which I had hoped would 
play a significant part became a dead end - asyncify. They have essentially 
abandoned it as an unviable solution - and it is at the *C++* code level - 
particularly at the scale of our codebase - the cyclomatic complexity is too 
high. The alternative - emterpreter - works perfectly but (as anyone who used 
the early wait-supporting versions will know) is wy too slow to be 
viable. Not an ideal situation, to say the least.

So I go back to doing the detailed planning of the worst case scenario - 
refactoring (or should I say a vigorous Moomin) of the C++ code in what is 
called 'continuation passing style'. This can be done - however it comes at a 
greater cost than my original estimates -  the churn in the source it requires 
is far more than I am comfortable with (I have the 7 refactor over my shoulder 
lurking as a reminder of the cascade effects of what such large stop-the-world 
projects can cause) and whilst we might have a much better development and 
quality process now, and an ever growing test suite - it is simply not yet good 
enough to support this endeavour.

So I am sorry to say that the first 'stable' version of the HTML5 engine is 
very unlikely to support wait - there are enough projects out there which do 
not use wait to make this perfectly reasonable. Instead we will be focusing 
most of our (html5 focused) energies on ensuring that as much of the rest of 
LiveCode as we can possibly make work in HTML5 will work as close to the other 
platforms as we possibly can. That includes text entry, native layers (which 
are actual HTML elements in this world), the clipboard, the slightly quirky (in 
the modern OS world) async input state features, in fact the majority of things 
which make LiveCode a diverse platform (in terms of the way people use it).

Now, I did say 'most' of the html5 energy. The wait problem WILL be solved. I 
have evaluated countless other strategies in recent months (I did mention about 
the fact that a lot of the work we have done as not being user visible - 
writing code is one thing, but figuring out what code to write often takes just 
as long, if not longer) and after a lot of what seems like going round in 
circles I find myself returning to my original hope - asyncify.

The asyncify idea essentially relies upon the fact you can rewrite any code 
which uses wait in a 'threaded style' - i.e. using callbacks (we saw that in a 
previous post). At the C++ level this cannot work for us - it would produce an 
explosion in code paths which would render the engine (and its 1.25million+ 
lines of 

Re: Web vs Native (was Re: HTML5 limitations?)

[J. Landman Gay via use-livecode]

On 7/28/17 1:14 PM, Mark Waddingham via use-livecode wrote:
What specific problem do we really need to solve... i.e. Is card-level 
swiping generally important enough to warrant an approach which isn't 
quite so general (very specific, one might say!)?


The thing here is that we could well consider adding a mechanism which 
is *card* specific (rather than in full generality). e.g. We add a card 
property which states in which directions a card could be swiped, and it 
uses the standard delays, actions of swiping in the various directions. 
Perhaps you get a swipeBegin message when the swipe starts (where you go 
card or whatever - and a snapshot is taken after - i.e. an implicit lock 
for visual effect); and then a swipeEnd / swipeCancel when it is done.


This would be a very high-level bit of functionality, not that 
configurable.


Thinking about this some more...I'll take whatever we can get. But 
thinking about real-world usage, on Android swiping is very commonly 
used to pull out the sidebar, something almost every Android app has. 
While iOS doesn't indulge in sidebars officially, they are so handy that 
I understand the hamburger menu is being used by iOS developers too 
(Apple frowns on it but looks the other way.)


Since it's possible to get a snapshot of a group that isn't currently 
visible, and since sidebars are commonly LC groups, would that be 
something also easily implemented?


In terms of yak-shaving, I wonder if same-card swipes might even be 
easier to implement than navigation? This type of swipe could be used to 
swipe away lines in lists (provided each line was its own control as per 
datagrids,) or expose controls "under" list items, and so forth. Right 
now there are no visual effects that accurately display this kind of 
animation. I've been struggling to fake an Android toast and have sort 
of made it work by animating within a rectangle, but it isn't perfect 
and requires a very specific card layout to maintain the illusion.


But since I don't know what has to happen under the hood, I'll be happy 
with card navigation if that's a better place to begin.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.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: Web vs Native (was Re: HTML5 limitations?)

[J. Landman Gay via use-livecode]

On 7/28/17 7:29 PM, Mark Waddingham via use-livecode wrote:
P.S. At some point I'll write at length about the 'wait' problem in 
HTML5. Whilst I try not to let myself be kept awake at night by 
engineering problems related to work - if ever there was one which did, 
it would be that one!


When you recover from sunstroke I'd be interested to hear about that.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.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: Web vs Native (was Re: HTML5 limitations?)

[Jonathan Lynch via use-livecode]

I thought that JS/HTML5 did not have a wait function? One can loop the engine, 
which is horrible, or one can set timeouts for functions. What functionality do 
you access to induce a wait?

Sent from my iPhone

> On Jul 28, 2017, at 8:29 PM, Mark Waddingham via use-livecode 
>  wrote:
> 
> Hi Hermann,
> 
> First of all please don't take any offence at my email as none was intended.
> 
> I was mainly trying to explain that whilst there are many things the HTML5 
> engine does not do, which means many stacks will not work without 
> changes/workarounds (indeed, somewhat significant ones) - there are 
> increasing numbers of those which do work and this is set to continue and 
> expand as we have more time to spend on the 'surface' features as opposed to 
> the core.
> 
>> On 2017-07-28 22:22, hh via use-livecode wrote:
>> Probably the "one" (=checking if the mouse is "down") pledged and bought a 
>> HTML5
>> license, the "at least other 2" (=never using it) didn't pledge nor
>> buy a license.
> 
> To be honest, this really is probably not true.
> 
> The thing is that 'the mouse' has long reported the event-asynchronous mouse 
> state, which is almost never what you actually want on modern purely 
> event-driven OSes - so over time its use has diminished as if you use it to 
> do certain things (not all - admittedly), you will end up noticing 
> 'interaction faults' which can be fixed by tracking mouseDown / mouseUp using 
> the event loop. Also, it is generally used alongside 'wait' - which of course 
> does not currently work.
> 
> Obviously you do use it, as do others, so it isn't that it is not important, 
> just that there are lots of other things that we have been working on in the 
> HTML5 engine first which *are* used much more widely.
> 
> It isn't actually possible to get the async mouse state on HTML5, so it will 
> not be 100% the same (although to be fair, the approximation we can use there 
> is probably more correct anyway). It is just a matter of time before we get 
> it to work, not if.
> 
>> I reported to quality center in Dec 2015/Jan 2016, that the state of the 
>> mouse
>> and modifier keys aren't recognized and that all menu buttons crash
>> the standalone.
> 
> Similarly, the modifierKeys. Text entry and keyboard states for the LiveCode 
> engine in HTML5 is another what is a seemingly 'simple' thing from the 
> outside, but is actually not that simple at all under the hood.
> 
> We are still working on solving some issues with text entry - we will solve 
> the problem in time, but again as with other facets of this endeavour some 
> things are taking a lot longer than we had originally anticipated.
> 
>> Since the start of this *395 thousand dollars* project in July 2014 I made at
>> about 60 "successful tests" to show 'oh the HTML5 engine does this' and
>> 'oh it does that'. This wasn't easy at all, needed a _lot_ of workarounds ...
> 
> You've mentioned the amount of money raised several times; however, one thing 
> which everyone has to appreciate is that every project we have crowd-funded 
> has had the value raised matched at least by a factor of 2 from other sources 
> (in some cases significantly more). My point here is not to undervalue the 
> contribution that a good number of you have made, but to illustrate that the 
> scale of the projects we have crowd-funded have been significantly larger 
> than the dollar value we went out to the community to raise would suggest.
> 
> Indeed, we have already spent far in excess of $400k on the HTML5 project 
> when taking into account all work that we have undertake to do it (it isn't 
> just each line of code which is written, but also infrastructure, 
> maintenance, systems and a huge variety of other factors almost all entirely 
> not user/publicly visible).
> 
> There is no problem here (I assure you) - we expected it - we knew it was 
> going to be a large, difficult project. However it is one which was, is, and 
> remains a vital project to finish for our ecosystem as a whole and finish it 
> will shall.
> 
>> So I'll better stop now and wait for the suitable percentage of 'unchanged'
>> LiveCode demos (although "wait" is not allowed in HTML5 deployment).
> 
> I would hope that you will continue to do as you have been - because it has 
> been great to see many of the things you have achieved with the HTML5 engine 
> despite its various obvious omissions in functionality. It also helps us, the 
> engineering team, to see visible progress by users on a project which is 
> large, long and complex (and somewhat frustrating at times!) - particularly 
> when much of the work we are doing, and have been doing is entirely non-user 
> visible!
> 
>> What the team made in HTML deployment until now is *very* good, especially 
>> the
>> "do as javascript" part is excellent. Just put more of the funds (and by that
>> 'bandwidth') into it, so that also basic things (e.g. typing UTF-8 into a 
>> field)
>> do 

Re: Web vs Native (was Re: HTML5 limitations?)

[Mark Waddingham via use-livecode]

Hi Hermann,

First of all please don't take any offence at my email as none was 
intended.


I was mainly trying to explain that whilst there are many things the 
HTML5 engine does not do, which means many stacks will not work without 
changes/workarounds (indeed, somewhat significant ones) - there are 
increasing numbers of those which do work and this is set to continue 
and expand as we have more time to spend on the 'surface' features as 
opposed to the core.


On 2017-07-28 22:22, hh via use-livecode wrote:
Probably the "one" (=checking if the mouse is "down") pledged and 
bought a HTML5

license, the "at least other 2" (=never using it) didn't pledge nor
buy a license.


To be honest, this really is probably not true.

The thing is that 'the mouse' has long reported the event-asynchronous 
mouse state, which is almost never what you actually want on modern 
purely event-driven OSes - so over time its use has diminished as if you 
use it to do certain things (not all - admittedly), you will end up 
noticing 'interaction faults' which can be fixed by tracking mouseDown / 
mouseUp using the event loop. Also, it is generally used alongside 
'wait' - which of course does not currently work.


Obviously you do use it, as do others, so it isn't that it is not 
important, just that there are lots of other things that we have been 
working on in the HTML5 engine first which *are* used much more widely.


It isn't actually possible to get the async mouse state on HTML5, so it 
will not be 100% the same (although to be fair, the approximation we can 
use there is probably more correct anyway). It is just a matter of time 
before we get it to work, not if.


I reported to quality center in Dec 2015/Jan 2016, that the state of 
the mouse

and modifier keys aren't recognized and that all menu buttons crash
the standalone.


Similarly, the modifierKeys. Text entry and keyboard states for the 
LiveCode engine in HTML5 is another what is a seemingly 'simple' thing 
from the outside, but is actually not that simple at all under the hood.


We are still working on solving some issues with text entry - we will 
solve the problem in time, but again as with other facets of this 
endeavour some things are taking a lot longer than we had originally 
anticipated.


Since the start of this *395 thousand dollars* project in July 2014 I 
made at

about 60 "successful tests" to show 'oh the HTML5 engine does this' and
'oh it does that'. This wasn't easy at all, needed a _lot_ of 
workarounds ...


You've mentioned the amount of money raised several times; however, one 
thing which everyone has to appreciate is that every project we have 
crowd-funded has had the value raised matched at least by a factor of 2 
from other sources (in some cases significantly more). My point here is 
not to undervalue the contribution that a good number of you have made, 
but to illustrate that the scale of the projects we have crowd-funded 
have been significantly larger than the dollar value we went out to the 
community to raise would suggest.


Indeed, we have already spent far in excess of $400k on the HTML5 
project when taking into account all work that we have undertake to do 
it (it isn't just each line of code which is written, but also 
infrastructure, maintenance, systems and a huge variety of other factors 
almost all entirely not user/publicly visible).


There is no problem here (I assure you) - we expected it - we knew it 
was going to be a large, difficult project. However it is one which was, 
is, and remains a vital project to finish for our ecosystem as a whole 
and finish it will shall.


So I'll better stop now and wait for the suitable percentage of 
'unchanged'

LiveCode demos (although "wait" is not allowed in HTML5 deployment).


I would hope that you will continue to do as you have been - because it 
has been great to see many of the things you have achieved with the 
HTML5 engine despite its various obvious omissions in functionality. It 
also helps us, the engineering team, to see visible progress by users on 
a project which is large, long and complex (and somewhat frustrating at 
times!) - particularly when much of the work we are doing, and have been 
doing is entirely non-user visible!


What the team made in HTML deployment until now is *very* good, 
especially the
"do as javascript" part is excellent. Just put more of the funds (and 
by that
'bandwidth') into it, so that also basic things (e.g. typing UTF-8 into 
a field)

do work.


Getting two way communication working in the HTML5 engine has been a 
significant step forward. Particularly as it means we can now do the 
absolute minimum in JavaScript and much more in LiveCode Script (what's 
the point of engineering a language, if one does not use it oneself, 
after all!).


Indeed, I envisage a good deal of the engine functionality we need to 
still implement relative to JavaScript should start being able to be 
done in LiveCode Script - the networking stuff 

Re: Web vs Native (was Re: HTML5 limitations?)

[Mark Wieder via use-livecode]

On 07/28/2017 11:41 AM, Mark Waddingham via use-livecode wrote:

This is, of course, why I sometimes take 1000 words to say things which 
could have been said in 10 ;)


Wouldn't have it any other way 

--
 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: Web vs Native (was Re: HTML5 limitations?)

[Richard Gaskin via use-livecode]

Mark Waddingham wrote:

> On 2017-07-28 20:17, Richard Gaskin via use-livecode wrote:
>> I think we're closer on this than might have originally seemed:
>
> Indeed - on this and most things I think.
>
> I've always assumed that you tend to ask certain questions, or phrase
> things in a certain in way to give us (well, me, generally) a chance
> to explain various aspects more widely and to a greater audience.

I wish I were so clever.  But the simple truth is I have so little 
contact with folks in the company that I honestly don't know the answers 
to questions like these.  And I do learn a lot from your replies.


> This is, of course, why I sometimes take 1000 words to say things
> which could have been said in 10 ;)

We vie for post length now and then, but you write far less repetitively 
than I do so at least yours are worth reading. :)


--
 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: Web vs Native (was Re: HTML5 limitations?)

[hh via use-livecode]

> Mark wrote:
> However, there is one VERY important point I do need to make. It is easy 
> to get hang up on saying 'oh the HTML5 engine doesn't do this, and oh it 
> doesn't do that' - and this might well be true. *However* the only important
> metric in this regard is - does it allow a suitable percentage  of LiveCode
> stacks which exist *right now* to run in the browser unchanged.
> 
> The problem here is that this is quite subjective - it largely depends on HOW
> you code and use LiveCode (remember my analogy of LiveCode and the elephant 
> and
> the blind men). One thing you have pointed out is that  'the mouse' function 
> does
> not work. It does not, this is true - however, for every person who ever uses
> 'the mouse' function I can be absolutely sure there are probably AT LEAST 2 
> who
> do not. This is true of all LiveCode features to a greater or lesser degree.

Probably the "one" (=checking if the mouse is "down") pledged and bought a HTML5
license, the "at least other 2" (=never using it) didn't pledge nor buy a 
license.

I reported to quality center in Dec 2015/Jan 2016, that the state of the mouse
and modifier keys aren't recognized and that all menu buttons crash the 
standalone.
To have at least two of these three working is for me a basic requirement for
interaction. If I repeat this 'feature request' 20 months later this is 
certainly
no "getting hang up".

And I really didn't take, for nearly three years, this 'negative' easy path as
you decribe, to the contrary:

Since the start of this *395 thousand dollars* project in July 2014 I made at
about 60 "successful tests" to show 'oh the HTML5 engine does this' and
'oh it does that'. This wasn't easy at all, needed a _lot_ of workarounds ...

So I'll better stop now and wait for the suitable percentage of 'unchanged'
LiveCode demos (although "wait" is not allowed in HTML5 deployment).

What the team made in HTML deployment until now is *very* good, especially the
"do as javascript" part is excellent. Just put more of the funds (and by that
'bandwidth') into it, so that also basic things (e.g. typing UTF-8 into a field)
do work. 

p.s. HTML5 standalones can talk to each other, several of them, in one browser
window. I just successfully tested that --- and trashed the demo.


___
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: Web vs Native (was Re: HTML5 limitations?)

[Mark Waddingham via use-livecode]

On 2017-07-28 20:17, Richard Gaskin via use-livecode wrote:

I think we're closer on this than might have originally seemed:


Indeed - on this and most things I think.

I've always assumed that you tend to ask certain questions, or phrase 
things in a certain in way to give us (well, me, generally) a chance to 
explain various aspects more widely and to a greater audience.


This is, of course, why I sometimes take 1000 words to say things which 
could have been said in 10 ;)


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: Web vs Native (was Re: HTML5 limitations?)

[J. Landman Gay via use-livecode]

On 7/28/17 12:53 PM, J. Landman Gay via use-livecode wrote:
I think we could discuss here on the list how it might work and then add 
to the feature request if we come up with something.


After writing my response, I see that Richard has provided a nice 
description in the bug report that covers what we need.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.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: Web vs Native (was Re: HTML5 limitations?)

[Richard Gaskin via use-livecode]

Mark Waddingham wrote:

> On 2017-07-28 18:34, Richard Gaskin via use-livecode wrote:
>> A sense of smooth liquid flow is the hallmark of modern UI.  If
>> support for this were limited to one widget that requires JavaScript,
>> we might as well use the other tools you mentioned above.
>
> This is simply not true. All tools have their limitations, all tools
> have things they are good at and things that they are bad

I think we're closer on this than might have originally seemed:

> Right now JS/HTML5/CSS etc. has the edge over LiveCode in creating
> these rich UIs.
...
> So Swami's approach is the pragmatic one. Use the browser for the
> things it is (currently) SUPERIOR for...

It seems we're both thinking long-term, and in a consistent direction.


>> Related, Jacque's request for swipe transitions was well received,
>> but oddly its status was changed to "Hibernated":
>> http://quality.livecode.com/show_bug.cgi?id=20141
>
> That is the standard process for all enhancement requests.

My apologies, I've only very rarely seen that.  Most of the time 
requests I've submitted or monitored get flagged "Confirmed"; I've only 
seen "Hibernated" a few times, and usually for things we now use "Expert 
Review" for.  If this is the current process no worries.



> Also, that particular request really doesn't in anyway explain how it
> might work ( sorry Jacque :( ) or, indeed, what that syntax is meant
> to  do - so that one has an extra step before moving forward. Actually
> understanding what it is actually about and, indeed, if it even makes
> sense.

Thanks for the interest - I just submitted a first draft spec as comment 
#2 there:

http://quality.livecode.com/show_bug.cgi?id=20141#c2


> There's a huge chasm (I'm mentioning a lot of those lately) between
> an idea, and an actionable idea, and then a huge chasm again between
> an actionable notion and an implementation. (Btw, chasms generally
> require either money or time to cross - or both - it isn't ever that
> they cannot be crossed).
>
> Whilst it might seem that LiveCode's evolution moves at a glacial pace
> at times; it is important to note that when compared to other 4GL
> tools (one mentioned above is a good one) out there (and indeed other
> dev tools in general) we are actually moving at tachyonic pace.

You've known me long enough to know how well that echoes many of my own 
posts here.  Perhaps the only difference is that when I write it some 
call me an "apologist" (I prefer to think of it as "pragmatist"), but as 
with so many things words from the mother ship carry much more weight 
than even the same words posted by anyone else.



> Part of me thinks that we should perhaps slow down a bit (even if just
> a little).

Maybe not a bad idea.  Burning the candle at both ends can result in 
burnout, and burnout can be hard to recover from.  And from time to time 
we see that request from some of the folks here, a desire for a 
maintenance-focused cycle with few of any new features.


Personally, I think v9 is striking a very excellent balance between 
features and fixes, but if you felt slowing down a bit would be 
beneficial I would support that.


--
 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: Web vs Native (was Re: HTML5 limitations?)

[J. Landman Gay via use-livecode]

On 7/28/17 12:01 PM, Mark Waddingham via use-livecode wrote:
That is the standard process for all enhancement requests. They are 
HIBERNATED until we have the time to evaluate and prioritise - if we 
were to do anything else, we would end up never getting any work done - 
and work we are doing right now is, quite frankly, always more important 
that work that we might do in the future.


Also, that particular request really doesn't in anyway explain how it 
might work ( sorry Jacque :( ) or, indeed, what that syntax is meant to 
do - so that one has an extra step before moving forward. Actually 
understanding what it is actually about and, indeed, if it even makes 
sense.


I thought you would figure it out. :) Actually, Richard's request here 
on the list was for sample syntax so that's all I suggested. I think we 
could discuss here on the list how it might work and then add to the 
feature request if we come up with something.


One thought: locking the screen "for swipe effect" might lock the screen 
while any navigation or card changes are made, and then the unlock 
command would track the gesture until mouseUp (or touchEnd.) While the 
tracking is taking place, a fast swipe would do a normal visual effect 
swipe, but a slow drag would draw and redraw the effect repeatedly. That 
would allow both regular swipes and also partial swipes that display 
various degrees of the updated display.


I guess we'd also need a message that tells the script whether the swipe 
actually completed fully. If the user changes their mind and doesn't 
complete the gesture (the display snaps back,) the script would have to 
restore the card or navigation to its original state.


Anyone else have a better idea?

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.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: Web vs Native (was Re: HTML5 limitations?)

[Mark Waddingham via use-livecode]

On 2017-07-28 19:01, Mark Waddingham via use-livecode wrote:

Right now JS/HTML5/CSS etc. has the edge over LiveCode in creating
these rich UIs. Now, to be honest, the acceleratedRendering mode of
LiveCode (which has been around for years) is no different from the
underlying tech in browsers which allows such UIs to be done. The
problem is that is merely the lowest-level piece. No-one (including
us) has every leveraged it to build a framework like that which we see
in the standard browser stack - they could, it is perfectly possible -
it just has not happened. (Admittedly some of the low-level features
we are adding to AR mode in due course will make this easier but not
really something which could not be achieved before if you worked hard
enough).


Just to clarify this (answering myself again - I know ;)).

This was in no way an 'attack' to say 'oh you guys haven't done it so 
its your own fault' because at the end of the day the fact this hasn't 
happened is OUR (well MY fault).


AcceleratedRendering has been there a very long time - but we've never 
documented it very well, nor really explained how it works. Without 
that, it has languished as a really quite cool thing that no-one has 
ever been given the ability to really learn how to use effectively, and 
more generally (nor be able to tell us that - hmmm it really needs to be 
able to do this and that as well).


Another example of where 'build it and they will come' is a fallacious 
sentiment ;)


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: Web vs Native (was Re: HTML5 limitations?)

[Trevor DeVore via use-livecode]

On Fri, Jul 28, 2017 at 11:43 AM, Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
> At the end of the day, it might not be that making it synchronous *is* the
> solution, but instead tweaking engine syntax and semantics to make it
> easier to deal with this asynchronicity.
>
> e.g.
>
> on mouseUp
>   async do "..." as javascript into tVar
>   -- implicit wait until tVar has been set
>   put tVar into field 1
> end mouseUp
>
> Note, this is just pseudo-code for the idea. The hardest part about doing
> the callback thing is that it splits up the critical sequence of actions
> you are trying to code into lots of bits separated by cruft (the handler
> definitions). This reduces readability, and maintainability which is
> something we really don't want. i.e. The problem you are trying to solve is
> obfuscated by the technical baggage needed to solve it.
>

To me this is the crux of the issue. Callbacks make the logic more
difficult to follow. Imagine a ui that requires three calls to a web
service before it can display part of the UI. There are three callbacks
that occur. Being able to keep all of the logic in one handler and have the
engine deal with the necessary wait until the async response is received
(or the operation is canceled) would be wonderful.

-- 
Trevor DeVore
ScreenSteps
www.screensteps.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: Web vs Native (was Re: HTML5 limitations?)

[Mark Waddingham via use-livecode]

On 2017-07-28 18:34, Richard Gaskin via use-livecode wrote:

A sense of smooth liquid flow is the hallmark of modern UI.  If
support for this were limited to one widget that requires JavaScript,
we might as well use the other tools you mentioned above.


This is simply not true. All tools have their limitations, all tools 
have things they are good at and things that they are bad. All tools 
have things they can do, but make it so hard to do so that you can't 
really consider using them for it. In most other endeavours in life we 
don't use a single tool to achieve a goal (to be slightly glib - you can 
only get so far with DIY on your home with JUST a hammer) - so why do we 
absolutely expect this of software development?


Right now JS/HTML5/CSS etc. has the edge over LiveCode in creating these 
rich UIs. Now, to be honest, the acceleratedRendering mode of LiveCode 
(which has been around for years) is no different from the underlying 
tech in browsers which allows such UIs to be done. The problem is that 
is merely the lowest-level piece. No-one (including us) has every 
leveraged it to build a framework like that which we see in the standard 
browser stack - they could, it is perfectly possible - it just has not 
happened. (Admittedly some of the low-level features we are adding to AR 
mode in due course will make this easier but not really something which 
could not be achieved before if you worked hard enough).


So Swami's approach is the pragmatic one. Use the browser for the things 
it is (currently) SUPERIOR for, but use LiveCode for everything else. 
Each tool on its own is good, but when joined together they become 
great.


This is exactly the angle we have taken with LiveCodeForFM. For 20 
years, FileMaker has been focused on making an easy to use tool which 
makes building database apps (particularly focused around solving 
BUSINESS problems); in contrast we have been focused on making an easy 
to use programming language and app building environment. We've tried to 
solve slightly different problems, so what each tool can do intersects a 
good deal, but mostly does not.


Overall: In isolation, either are good. However, when you put them 
together they complement each other very very well and the combination 
becomes great.



Fortunately it seems some of the work needed for the DG update will
help with some of this.

Related, Jacque's request for swipe transitions was well received, but
oddly its status was changed to "Hibernated":
http://quality.livecode.com/show_bug.cgi?id=20141


That is the standard process for all enhancement requests. They are 
HIBERNATED until we have the time to evaluate and prioritise - if we 
were to do anything else, we would end up never getting any work done - 
and work we are doing right now is, quite frankly, always more important 
that work that we might do in the future.


Also, that particular request really doesn't in anyway explain how it 
might work ( sorry Jacque :( ) or, indeed, what that syntax is meant to 
do - so that one has an extra step before moving forward. Actually 
understanding what it is actually about and, indeed, if it even makes 
sense.


There's a huge chasm (I'm mentioning a lot of those lately) between an 
idea, and an actionable idea, and then a huge chasm again between an 
actionable notion and an implementation. (Btw, chasms generally require 
either money or time to cross - or both - it isn't ever that they cannot 
be crossed).


Whilst it might seem that LiveCode's evolution moves at a glacial pace 
at times; it is important to note that when compared to other 4GL tools 
(one mentioned above is a good one) out there (and indeed other dev 
tools in general) we are actually moving at tachyonic pace. Part of me 
thinks that we should perhaps slow down a bit (even if just a little).


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: Web vs Native (was Re: HTML5 limitations?)

[Mark Waddingham via use-livecode]

On 2017-07-28 18:28, William Prothero via use-livecode wrote:

on myRequest
   —send a POST or GET request, whatever, with a callback handler 
specified.

   —display a mask that inhibits new mouse clicks and sets a busy icon.
end myRequest
on myCallbackHander myReturnData
  —do whatever you want with myReturnData
end myCallbackHander

But then again, I’m not a master of javascript, so there may be other 
issues.


I think it is mainly the thought process which goes with having to do 
things in this 'threaded style' - for simple things it is fine, but it 
can get unwieldy pretty quickly for long running sequences of stuff. 
From an abstract perspective, at the very least, it *should* be possible 
to make this more natural (e.g. C# has an 'async' concept - which is 
basically a bit like out wait but more focused) so that is one angle 
here.


Although I am one of the people calling for more browser widget 
development...


I have my doubts about the ability to make it synchronous with LC.


It is definitely possible - the fact it is not is related to a technical 
detail in the way the engine interoperates with CEF (and the other 
browsers). However, being possible says nothing about the difficulty of 
getting it to work or ensuring it continues to work!


The HTML5 engine IS synchronous so that gives at least a suggestion that 
is should be possible (although, admittedly, the HTML5 engine IS 
JavaScript so there's no 'world-boundary' to be concerned about in that 
instance).


At the end of the day, it might not be that making it synchronous *is* 
the solution, but instead tweaking engine syntax and semantics to make 
it easier to deal with this asynchronicity.


e.g.

on mouseUp
  async do "..." as javascript into tVar
  -- implicit wait until tVar has been set
  put tVar into field 1
end mouseUp

Note, this is just pseudo-code for the idea. The hardest part about 
doing the callback thing is that it splits up the critical sequence of 
actions you are trying to code into lots of bits separated by cruft (the 
handler definitions). This reduces readability, and maintainability 
which is something we really don't want. i.e. The problem you are trying 
to solve is obfuscated by the technical baggage needed to solve it.


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: Web vs Native (was Re: HTML5 limitations?)

[Richard Gaskin via use-livecode]

Sannyasin Brahmanathaswami wrote:

> As for web app vs native app, @Richard Gaskin  You *can*, obviously,
> build a "web app" (html5+js+css) and  package it in the app and run
> it off line. another lad here on our team builds in ionic/React
> /Angular. But his app is "native" to the phone, appears in stores.

Yes, OS-native apps can be made in many languages, including scripting 
languages like LiveCode and JavaScript.


My explorations here are less about the programming languages one might 
use to make them and more about the delivered result, whether the app is 
its own executable or lives within a web browser executable.



> In your quest for understanding,  does your idea of "web app" cover
> this? or are *only* think "delivered runtime from web servers."

More specifically, the distinction is that the app is delivered within a 
browser, since even OS-native apps can have most of their UI and code 
downloaded from a server just like web apps do.



> At any rate, I would re-iterate Jonathan's earlier sentiment, that,
> unless you are a super JS expert, once you get past the presentation
> layer, doing a lot of work that requires manipulation of data, more
> complex framework integration of many elements, Livecode would put
> you far ahead in terms of productivity and transparency.
>
> And even if you *could* you could actually do all that with JS, it
> would be such a horrible snake pit that you and only you could
> possibly maintain it, scale it or refactor it.
>
> Hence oft-repeated prayer that we get the browser "widget" to become
> a true member of the LC message hierarchy, they we can leverage the
> web apps eye candy layer (easy to build, responsive, CSS is already
> done for us…) with LC powerful framework, so that we don't have to
> waste time using JS to get work done, but use it just for "clicking
> here and there" while LC does the heavy lifting in the background.

If the web client technology stack (JavaScript/HTML/DOM/CSS) is a "snake 
pit", do we really want to increase dependency on snakes in LiveCode?


If I want an asynchronous progress indicator like a spinning wheel, 
should it be necessary to include and embed an entire other web 
application process just to get that?  Is that the story we want to tell 
new users?  I'd much rather have an async playback option for the LC 
engine's handling of GIFs, which already covers the other 95% of what we 
need very well.


Same for broader use-cases, like smooth transition effects of the sort 
CSS3 now does so well.  Those are also now so pervasively expected by 
users that it benefits the LC platform more to have as much of that as 
practical right in the engine, rather than limited to one specific 
widget that requires us to leave LiveCode and program it in JavaScript.


A sense of smooth liquid flow is the hallmark of modern UI.  If support 
for this were limited to one widget that requires JavaScript, we might 
as well use the other tools you mentioned above.


Fortunately it seems some of the work needed for the DG update will help 
with some of this.


Related, Jacque's request for swipe transitions was well received, but 
oddly its status was changed to "Hibernated":

http://quality.livecode.com/show_bug.cgi?id=20141

I hope that's only momentary.  Swipe transitions are no longer merely 
optional for mobile UIs, and the level of effort required to work around 
that with groups diminishes many of the advantages of choosing LiveCode, 
lowering LC's score when potential new users do a comparative 
evaluations of tools. I may be a dreamer, but I'd like to see LC match 
or exceed capabilities in such comparisons.


--
 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: Web vs Native (was Re: HTML5 limitations?)

[Jonathan Lynch via use-livecode]

It requires setting up chained handlers on both the LC and JS side, but as long 
as you structure it well, it is not that bad.

I can tell you that for working with maps, it is essential.

Sent from my iPhone

> On Jul 28, 2017, at 12:28 PM, William Prothero via use-livecode 
>  wrote:
> 
> Folks:
> As a long term Director developer, I found the use of listeners and callbacks 
> to be quite easy to implement. I don’t see the problem.
> 
> on myRequest
>   —send a POST or GET request, whatever, with a callback handler specified.
>   —display a mask that inhibits new mouse clicks and sets a busy icon.
> end myRequest
> on myCallbackHander myReturnData
>  —do whatever you want with myReturnData
> end myCallbackHander
> 
> But then again, I’m not a master of javascript, so there may be other issues.
> 
> Best,
> Bill
> 
>> On Jul 28, 2017, at 9:16 AM, Jonathan Lynch via use-livecode 
>>  wrote:
>> 
>> Although I am one of the people calling for more browser widget 
>> development...
>> 
>> I have my doubts about the ability to make it synchronous with LC.
>> 
>> JavaScript is not even reliably synchronous with HTML5, forcing JS 
>> developers to use callbacks and event listeners in weird places.
>> 
>> Unless you guys are going to rewrite JavaScript AND HTML, how could this be 
>> accomplished?
>> 
>> Sent from my iPhone
>> 
 On Jul 28, 2017, at 11:57 AM, Mark Waddingham via use-livecode 
  wrote:
 
 On 2017-07-28 16:47, Sannyasin Brahmanathaswami via use-livecode wrote:
 Hence oft-repeated prayer that we get the browser "widget" to become a
 true member of the LC message hierarchy, they we can leverage the web
 apps eye candy layer (easy to build, responsive, CSS is already done
 for us…) with LC powerful framework, so that we don't have to waste
 time using JS to get work done, but use it just for "clicking here and
 there" while LC does the heavy lifting in the background.
>>> 
>>> I can assure you your 'prayer' has been heard - however, there is a slight 
>>> chasm between hearing a prayer and being able to act on it (especially for 
>>> mere mortals, like ourselves ;)).
>>> 
>>> There is a whole (reasonably sized) 'new market' for LiveCode in the space 
>>> of providing the shell into which HTML5/JS webapps can be placed. i.e. The 
>>> creation of a native app which wraps a HTML5/JS web-app which then has 
>>> direct access to all the platform features LiveCode gives you access to (a 
>>> bit like PhoneGap or Cordova or ... - the fact there are so many of these 
>>> things suggests that it is a very useful thing that people actually want to 
>>> do). Now, this works quite well right now - although I do appreciate that 
>>> the asynchronous nature of return values from the host (LiveCode) does make 
>>> some things more difficult to do (*although*, it should be pointed out that 
>>> async something I think *all* other host environments that provide this 
>>> kind of wrapping have to put up with!).
>>> 
>>> However, as you have may have noticed (from various comments - sometimes 
>>> positive, sometimes not, mostly not - about CEF) there is a fair bit of 
>>> technical challenge involved in having a browser widget and keeping it 
>>> working on all platforms. Now, this is not to say we do not like technical 
>>> challenges - we clearly do. However, in general, the greater the technical 
>>> challenge, the greater the resources required to solve it.
>>> 
>>> Such an endeavour *has* to be self supporting - i.e. it needs to generate 
>>> enough revenue in order to justify its existence. The browser widget as it 
>>> stands is already taxing us on that front (it is really important, so 
>>> whilst I sometimes get concerned about the 'money-pit' it sometimes seems 
>>> to be, one has to remind oneself that some things are a long-term 
>>> investment).
>>> 
>>> Of course, the above is entirely related to technical issues - there is 
>>> also the problem of selling LiveCode and this feature into such a space...
>>> 
>>> That old adage of 'build it and they will come' is quite possibly one of 
>>> the biggest load of bovine-backend-excretion that has ever been uttered. 
>>> Build it and, well, most people will walk by it, some might look at it and 
>>> go 'oh that's nice' and walk on, very few will actually take the time to 
>>> visit it without some sort of cajoling. Unfortunately, this kind of 
>>> activity (I'm of course talking about marketing) tends to be a great deal 
>>> more expensive than development (I could make the rather cynical 
>>> observation that there is a reason why marketing consultant's offices tend 
>>> to be a great deal 'nicer' than those of computing consultants - but I 
>>> should probably keep that to myself ;)) and it is only through marketing 
>>> such things that you can make them generate enough revenue to pay for their 
>>> seat at the table.
>>> 
>>> 

Re: Web vs Native (was Re: HTML5 limitations?)

[Mark Waddingham via use-livecode]

On 2017-07-26 23:06, hh via use-livecode wrote:

There are, sadly, still very basic things missing, which make the
HTML5 standalone
builder, TMHO, not yet ready for "beta"-state.


Well - yes - the 'beta' state as I mentioned was a slip (mainly in that 
we don't do 'beta' in our dev process as I explained).


However, there is one VERY important point I do need to make. It is easy 
to get hang up on saying 'oh the HTML5 engine doesn't do this, and oh it 
doesn't do that' - and this might well be true. *However* the only 
important metric in this regard is - does it allow a suitable percentage 
of LiveCode stacks which exist *right now* to run in the browser 
unchanged.


The problem here is that this is quite subjective - it largely depends 
on HOW you code and use LiveCode (remember my analogy of LiveCode and 
the elephant and the blind men). One thing you have pointed out is that 
'the mouse' function does not work. It does not, this is true - however, 
for every person who ever uses 'the mouse' function I can be absolutely 
sure there are probably AT LEAST 2 who do not. This is true of all 
LiveCode features to a greater or lesser degree.


Jacque (for example), clearly has an app that she would really like to 
work in the HTML5 engine. I'd really like this too. Now, I know Jacque 
quite well, I also know her coding style quite well and the way she uses 
LiveCode to solve problems. The app she is talking about should be the 
bread-and-butter of the HTML5 engine however I'm sure it does use a 
number of features which are not the easiest to get working on that 
platform (because I know a bit of Jacque's thought process). Overall, 
without looking at the code in more detail I can't really say how far we 
are from being able to allow it to run well on that platform without 
significant changes. (It might be it is almost there, it might be a very 
long way - but just FOR THAT SPECIFIC app).


In contrast, I've spent a fair bit of time with David Simpson here at 
FileMaker DevCon. Whilst chatting about HTML5 engine, David happened to 
mention that his largest product works perfectly in the current HTML5 
engine - WITH NO CODE CHANGES. This product has (if memory serves me 
correctly) in excess of 100,000 lines of code.


So PLEASE remember, we all have a different view of the elephant. Just 
because something might not yet have reached the point of intersection 
with our OWN view, it does not mean that it has not completely covered 
the view of others. Utility is in the eye of the beholder, and whilst 
our goal is to have the ability to take any LiveCode stack and have it 
run in the browser with no code changes let us not think that just 
because that is not true, it is not actually REALLY useful for many 
cases RIGHT NOW.


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: Web vs Native (was Re: HTML5 limitations?)

[William Prothero via use-livecode]

Folks:
As a long term Director developer, I found the use of listeners and callbacks 
to be quite easy to implement. I don’t see the problem.

on myRequest
   —send a POST or GET request, whatever, with a callback handler specified.
   —display a mask that inhibits new mouse clicks and sets a busy icon.
end myRequest
on myCallbackHander myReturnData
  —do whatever you want with myReturnData
end myCallbackHander

But then again, I’m not a master of javascript, so there may be other issues.

Best,
Bill

On Jul 28, 2017, at 9:16 AM, Jonathan Lynch via use-livecode 
 wrote:
> 
> Although I am one of the people calling for more browser widget development...
> 
> I have my doubts about the ability to make it synchronous with LC.
> 
> JavaScript is not even reliably synchronous with HTML5, forcing JS developers 
> to use callbacks and event listeners in weird places.
> 
> Unless you guys are going to rewrite JavaScript AND HTML, how could this be 
> accomplished?
> 
> Sent from my iPhone
> 
>> On Jul 28, 2017, at 11:57 AM, Mark Waddingham via use-livecode 
>>  wrote:
>> 
>>> On 2017-07-28 16:47, Sannyasin Brahmanathaswami via use-livecode wrote:
>>> Hence oft-repeated prayer that we get the browser "widget" to become a
>>> true member of the LC message hierarchy, they we can leverage the web
>>> apps eye candy layer (easy to build, responsive, CSS is already done
>>> for us…) with LC powerful framework, so that we don't have to waste
>>> time using JS to get work done, but use it just for "clicking here and
>>> there" while LC does the heavy lifting in the background.
>> 
>> I can assure you your 'prayer' has been heard - however, there is a slight 
>> chasm between hearing a prayer and being able to act on it (especially for 
>> mere mortals, like ourselves ;)).
>> 
>> There is a whole (reasonably sized) 'new market' for LiveCode in the space 
>> of providing the shell into which HTML5/JS webapps can be placed. i.e. The 
>> creation of a native app which wraps a HTML5/JS web-app which then has 
>> direct access to all the platform features LiveCode gives you access to (a 
>> bit like PhoneGap or Cordova or ... - the fact there are so many of these 
>> things suggests that it is a very useful thing that people actually want to 
>> do). Now, this works quite well right now - although I do appreciate that 
>> the asynchronous nature of return values from the host (LiveCode) does make 
>> some things more difficult to do (*although*, it should be pointed out that 
>> async something I think *all* other host environments that provide this kind 
>> of wrapping have to put up with!).
>> 
>> However, as you have may have noticed (from various comments - sometimes 
>> positive, sometimes not, mostly not - about CEF) there is a fair bit of 
>> technical challenge involved in having a browser widget and keeping it 
>> working on all platforms. Now, this is not to say we do not like technical 
>> challenges - we clearly do. However, in general, the greater the technical 
>> challenge, the greater the resources required to solve it.
>> 
>> Such an endeavour *has* to be self supporting - i.e. it needs to generate 
>> enough revenue in order to justify its existence. The browser widget as it 
>> stands is already taxing us on that front (it is really important, so whilst 
>> I sometimes get concerned about the 'money-pit' it sometimes seems to be, 
>> one has to remind oneself that some things are a long-term investment).
>> 
>> Of course, the above is entirely related to technical issues - there is also 
>> the problem of selling LiveCode and this feature into such a space...
>> 
>> That old adage of 'build it and they will come' is quite possibly one of the 
>> biggest load of bovine-backend-excretion that has ever been uttered. Build 
>> it and, well, most people will walk by it, some might look at it and go 'oh 
>> that's nice' and walk on, very few will actually take the time to visit it 
>> without some sort of cajoling. Unfortunately, this kind of activity (I'm of 
>> course talking about marketing) tends to be a great deal more expensive than 
>> development (I could make the rather cynical observation that there is a 
>> reason why marketing consultant's offices tend to be a great deal 'nicer' 
>> than those of computing consultants - but I should probably keep that to 
>> myself ;)) and it is only through marketing such things that you can make 
>> them generate enough revenue to pay for their seat at the table.
>> 
>> So TL;DR version. Yes - Kevin and I would both like to do more with the 
>> browser widget as it is actually a really really cool thing (so we hear your 
>> prayers - every one). However, right now, we simply don't feel we have the 
>> bandwidth (to use a Kevinism) to do it properly in a way where the endeavour 
>> can be fully self-supporting. Also, we are already seated at a rather large 
>> dinner at the moment (Infinite LiveCode, 

Re: Web vs Native (was Re: HTML5 limitations?)

[Jonathan Lynch via use-livecode]

Although I am one of the people calling for more browser widget development...

I have my doubts about the ability to make it synchronous with LC.

JavaScript is not even reliably synchronous with HTML5, forcing JS developers 
to use callbacks and event listeners in weird places.

Unless you guys are going to rewrite JavaScript AND HTML, how could this be 
accomplished?

Sent from my iPhone

> On Jul 28, 2017, at 11:57 AM, Mark Waddingham via use-livecode 
>  wrote:
> 
>> On 2017-07-28 16:47, Sannyasin Brahmanathaswami via use-livecode wrote:
>> Hence oft-repeated prayer that we get the browser "widget" to become a
>> true member of the LC message hierarchy, they we can leverage the web
>> apps eye candy layer (easy to build, responsive, CSS is already done
>> for us…) with LC powerful framework, so that we don't have to waste
>> time using JS to get work done, but use it just for "clicking here and
>> there" while LC does the heavy lifting in the background.
> 
> I can assure you your 'prayer' has been heard - however, there is a slight 
> chasm between hearing a prayer and being able to act on it (especially for 
> mere mortals, like ourselves ;)).
> 
> There is a whole (reasonably sized) 'new market' for LiveCode in the space of 
> providing the shell into which HTML5/JS webapps can be placed. i.e. The 
> creation of a native app which wraps a HTML5/JS web-app which then has direct 
> access to all the platform features LiveCode gives you access to (a bit like 
> PhoneGap or Cordova or ... - the fact there are so many of these things 
> suggests that it is a very useful thing that people actually want to do). 
> Now, this works quite well right now - although I do appreciate that the 
> asynchronous nature of return values from the host (LiveCode) does make some 
> things more difficult to do (*although*, it should be pointed out that async 
> something I think *all* other host environments that provide this kind of 
> wrapping have to put up with!).
> 
> However, as you have may have noticed (from various comments - sometimes 
> positive, sometimes not, mostly not - about CEF) there is a fair bit of 
> technical challenge involved in having a browser widget and keeping it 
> working on all platforms. Now, this is not to say we do not like technical 
> challenges - we clearly do. However, in general, the greater the technical 
> challenge, the greater the resources required to solve it.
> 
> Such an endeavour *has* to be self supporting - i.e. it needs to generate 
> enough revenue in order to justify its existence. The browser widget as it 
> stands is already taxing us on that front (it is really important, so whilst 
> I sometimes get concerned about the 'money-pit' it sometimes seems to be, one 
> has to remind oneself that some things are a long-term investment).
> 
> Of course, the above is entirely related to technical issues - there is also 
> the problem of selling LiveCode and this feature into such a space...
> 
> That old adage of 'build it and they will come' is quite possibly one of the 
> biggest load of bovine-backend-excretion that has ever been uttered. Build it 
> and, well, most people will walk by it, some might look at it and go 'oh 
> that's nice' and walk on, very few will actually take the time to visit it 
> without some sort of cajoling. Unfortunately, this kind of activity (I'm of 
> course talking about marketing) tends to be a great deal more expensive than 
> development (I could make the rather cynical observation that there is a 
> reason why marketing consultant's offices tend to be a great deal 'nicer' 
> than those of computing consultants - but I should probably keep that to 
> myself ;)) and it is only through marketing such things that you can make 
> them generate enough revenue to pay for their seat at the table.
> 
> So TL;DR version. Yes - Kevin and I would both like to do more with the 
> browser widget as it is actually a really really cool thing (so we hear your 
> prayers - every one). However, right now, we simply don't feel we have the 
> bandwidth (to use a Kevinism) to do it properly in a way where the endeavour 
> can be fully self-supporting. Also, we are already seated at a rather large 
> dinner at the moment (Infinite LiveCode, LiveCode Connect, LiveCodeForFM, 
> Version 9, Maintenance of 8, ...) so perhaps need to finish *at least* one of 
> those courses before we embark on the next (no-one likes indigestion, after 
> all).
> 
> Warmest Regards,
> 
> Mark.
> 
> P.S. By the way, I'm mainly saying all of this to make it clear that we have 
> been listening, we are just not able to act on it at the moment. Please *do* 
> keep poking us about it - as it keeps the idea in our minds, and each time it 
> comes up it causes a re-evaluation. It also helps to remind people that they 
> CAN use LiveCode for this kind of stuff and so should - which is a precursor 
> to being able to convince people who are not 'LiveCoders' 

Re: Web vs Native (was Re: HTML5 limitations?)

[Mark Waddingham via use-livecode]

On 2017-07-28 16:47, Sannyasin Brahmanathaswami via use-livecode wrote:

Hence oft-repeated prayer that we get the browser "widget" to become a
true member of the LC message hierarchy, they we can leverage the web
apps eye candy layer (easy to build, responsive, CSS is already done
for us…) with LC powerful framework, so that we don't have to waste
time using JS to get work done, but use it just for "clicking here and
there" while LC does the heavy lifting in the background.


I can assure you your 'prayer' has been heard - however, there is a 
slight chasm between hearing a prayer and being able to act on it 
(especially for mere mortals, like ourselves ;)).


There is a whole (reasonably sized) 'new market' for LiveCode in the 
space of providing the shell into which HTML5/JS webapps can be placed. 
i.e. The creation of a native app which wraps a HTML5/JS web-app which 
then has direct access to all the platform features LiveCode gives you 
access to (a bit like PhoneGap or Cordova or ... - the fact there are so 
many of these things suggests that it is a very useful thing that people 
actually want to do). Now, this works quite well right now - although I 
do appreciate that the asynchronous nature of return values from the 
host (LiveCode) does make some things more difficult to do (*although*, 
it should be pointed out that async something I think *all* other host 
environments that provide this kind of wrapping have to put up with!).


However, as you have may have noticed (from various comments - sometimes 
positive, sometimes not, mostly not - about CEF) there is a fair bit of 
technical challenge involved in having a browser widget and keeping it 
working on all platforms. Now, this is not to say we do not like 
technical challenges - we clearly do. However, in general, the greater 
the technical challenge, the greater the resources required to solve it.


Such an endeavour *has* to be self supporting - i.e. it needs to 
generate enough revenue in order to justify its existence. The browser 
widget as it stands is already taxing us on that front (it is really 
important, so whilst I sometimes get concerned about the 'money-pit' it 
sometimes seems to be, one has to remind oneself that some things are a 
long-term investment).


Of course, the above is entirely related to technical issues - there is 
also the problem of selling LiveCode and this feature into such a 
space...


That old adage of 'build it and they will come' is quite possibly one of 
the biggest load of bovine-backend-excretion that has ever been uttered. 
Build it and, well, most people will walk by it, some might look at it 
and go 'oh that's nice' and walk on, very few will actually take the 
time to visit it without some sort of cajoling. Unfortunately, this kind 
of activity (I'm of course talking about marketing) tends to be a great 
deal more expensive than development (I could make the rather cynical 
observation that there is a reason why marketing consultant's offices 
tend to be a great deal 'nicer' than those of computing consultants - 
but I should probably keep that to myself ;)) and it is only through 
marketing such things that you can make them generate enough revenue to 
pay for their seat at the table.


So TL;DR version. Yes - Kevin and I would both like to do more with the 
browser widget as it is actually a really really cool thing (so we hear 
your prayers - every one). However, right now, we simply don't feel we 
have the bandwidth (to use a Kevinism) to do it properly in a way where 
the endeavour can be fully self-supporting. Also, we are already seated 
at a rather large dinner at the moment (Infinite LiveCode, LiveCode 
Connect, LiveCodeForFM, Version 9, Maintenance of 8, ...) so perhaps 
need to finish *at least* one of those courses before we embark on the 
next (no-one likes indigestion, after all).


Warmest Regards,

Mark.

P.S. By the way, I'm mainly saying all of this to make it clear that we 
have been listening, we are just not able to act on it at the moment. 
Please *do* keep poking us about it - as it keeps the idea in our minds, 
and each time it comes up it causes a re-evaluation. It also helps to 
remind people that they CAN use LiveCode for this kind of stuff and so 
should - which is a precursor to being able to convince people who are 
not 'LiveCoders' that LiveCode might be something they should check 
out... If only to give them an easier way to ship a 'native' HTML5/JS 
app.


P.P.S. We are also fully away that this 'HTML5/JS' wrapper idea is also 
very much a gorilla activity - they might come for the wrapper, but stay 
because of LiveCode. However, one still needs to capture and tame the 
gorilla first ;)


P.P.P.S. Yes - I know it should have been 'guerilla', it is just that 
using 'gorilla' seemed more fun.


--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing 

Re: Web vs Native (was Re: HTML5 limitations?)

[Sannyasin Brahmanathaswami via use-livecode]

Matt wrote:

Except that they've aged
out of the phase where it's easy to learn new things. So they feel like an
idiot baby and it takes way too much effort to push through the learning
curve.

LOL, hence my surprise after listening to some complaints by older folks about 
the navigation in our new app, when some 8 year olds and 15 year olds tried it 
and just "had a ball/adventure" with it.

As for web app vs native app, @Richard Gaskin  You *can*, obviously, build a 
"web app" (html5+js+css) and  package it in the app and run it off line. 
another lad here on our team builds in ionic/React/Angular. But his app is 
"native" to the phone, appears in stores.

 In your quest for understanding,  does your idea of "web app" cover this? or 
are *only* think "delivered runtime from web servers."

At any rate, I would re-iterate Jonathan's earlier sentiment, that, unless you 
are a super JS expert, once you get past the presentation layer, doing a lot of 
work that requires manipulation of data, more complex framework integration of 
many elements, Livecode would put you far ahead in terms of productivity and 
transparency. 

And even if you *could* you could actually do all that with JS, it would be 
such a horrible snake pit that you and only you could possibly maintain it, 
scale it or refactor it.

Hence oft-repeated prayer that we get the browser "widget" to become a true 
member of the LC message hierarchy, they we can leverage the web apps eye candy 
layer (easy to build, responsive, CSS is already done for us…) with LC powerful 
framework, so that we don't have to waste time using JS to get work done, but 
use it just for "clicking here and there" while LC does the heavy lifting in 
the background.

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: Web vs Native (was Re: HTML5 limitations?)

[Scott Morrow via use-livecode]

> On Jul 27, 2017, at 10:48 AM, Matt Maier via use-livecode 
>  wrote:

> High market penetration of smartphones doesn't mean anyone actually has any
> idea how to use their smartphone. Most people are at about the
> Fischer-Price My First Shapes and Colors level. Except that they've aged
> out of the phase where it's easy to learn new things. So they feel like an
> idiot baby and it takes way too much effort to push through the learning
> curve.


Lovely!  :- )

Scott Morrow

Elementary Software
(Now with 20% less chalk dust!)
web   http://elementarysoftware.com/
email sc...@elementarysoftware.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: Web vs Native (was Re: HTML5 limitations?)

[Matt Maier via use-livecode]

Word. I barely have any experience and I've already run into multiple
users/customers who think that "add to homescreen" is impossible hacker
magic.

High market penetration of smartphones doesn't mean anyone actually has any
idea how to use their smartphone. Most people are at about the
Fischer-Price My First Shapes and Colors level. Except that they've aged
out of the phase where it's easy to learn new things. So they feel like an
idiot baby and it takes way too much effort to push through the learning
curve.

A lot of developers use "hybrid apps" (like PhoneGap) as the quickest,
easiest way to get a web app into the app store(s). It doesn't actually
have an app in it. It's basically just a browser with a built-in link to
the web app. But there are a lot of users who don't understand how to use
the app if it's not in the app store.

On Thu, Jul 27, 2017 at 9:56 AM, Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Which point illustrates something I'm sure seasoned developers have known
> for a long time: There is no way to write an app so that it will satisfy
> everyone, especially these days with all the ways to deliver an app!
>
> To illustrate, I had a gal here in the office lose some documents, because
> I had to reinitialize the copier HD in order to fix a problem that
> installing a web app for the copier had caused. Come to find out, she scans
> documents and keeps them stored on the copier for many days until she can
> get around to processing them. I asked her why she didn't just scan the
> documents directly into our document management app, and she said she
> doesn't do things that way, but instead uses Acrobat (or some other app) to
> COMBINE THE SCANNED DOCUMENTS WITH EXISTING PDF DOCUMENTS! All documents
> become one PDF!
>
> So I told her that it would be much better having each kind of document as
> a discreet document, so that routing each document somewhere else would not
> require her to pull the document apart again. Her response was, "This is
> the way I have always done it. This is the way I will always do it. I am
> not going to change!"
>
> Oh kay then. Turns out you cannot program around human will.
>
> Bob S
>
>
> > On Jul 27, 2017, at 09:03 , Richard Gaskin via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > But we're making an app anyway, because of feedback from his customers
> which suggests that using bookmarks on mobile is too onerous.  They
> expressed a very strong preference for having in icon on their home screen,
> and even the one step needed to put a bookmark on their home screen was
> perceived as too difficult.  They'd much rather find, download, and install
> an app just to get an easy launch.
> >
> > --
> > Richard Gaskin
>
>
> ___
> 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: Web vs Native (was Re: HTML5 limitations?)

[Bob Sneidar via use-livecode]

Which point illustrates something I'm sure seasoned developers have known for a 
long time: There is no way to write an app so that it will satisfy everyone, 
especially these days with all the ways to deliver an app! 

To illustrate, I had a gal here in the office lose some documents, because I 
had to reinitialize the copier HD in order to fix a problem that installing a 
web app for the copier had caused. Come to find out, she scans documents and 
keeps them stored on the copier for many days until she can get around to 
processing them. I asked her why she didn't just scan the documents directly 
into our document management app, and she said she doesn't do things that way, 
but instead uses Acrobat (or some other app) to COMBINE THE SCANNED DOCUMENTS 
WITH EXISTING PDF DOCUMENTS! All documents become one PDF! 

So I told her that it would be much better having each kind of document as a 
discreet document, so that routing each document somewhere else would not 
require her to pull the document apart again. Her response was, "This is the 
way I have always done it. This is the way I will always do it. I am not going 
to change!" 

Oh kay then. Turns out you cannot program around human will. 

Bob S


> On Jul 27, 2017, at 09:03 , Richard Gaskin via use-livecode 
>  wrote:
> 
> But we're making an app anyway, because of feedback from his customers which 
> suggests that using bookmarks on mobile is too onerous.  They expressed a 
> very strong preference for having in icon on their home screen, and even the 
> one step needed to put a bookmark on their home screen was perceived as too 
> difficult.  They'd much rather find, download, and install an app just to get 
> an easy launch.
> 
> -- 
> Richard Gaskin


___
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: Web vs Native (was Re: HTML5 limitations?)

[Richard Gaskin via use-livecode]

hh wrote:

>> RG wrote:
>> - What are the use-cases where a native app is a better choice than
>>   a web app?
>> - What are the perceived benefits of web apps and native apps?
>> The first question is about actual capabilities, and the second
>> is about the psychological drivers of clients and customers,
>> which may or may not reflect those capabilities.
>
> Yes. More specific and very clear now.
>
> The answer to the first question is of course: Native is always better
> performant.

Good point.  Not having to download the UI and code each time you use an 
app helps.  But isn't that mitigated somewhat with modern local storage 
options in browsers?



> But with a web app you have "all-in-one": For example, no nasty switch
> to an other app for a simple "wiki"-info, or for some lines of
> feed-back, or for looking into news. A web app means: You are already
> "surfing".  These are my experiences from discussions with non-IT
> users/clients/customers

This is part of why I raised the question, as I came across a use-case 
with a client recently that was very much the opposite:


He has a service which is simple enough that it could be well served in 
a web app.  Seemed like a good idea to me - write it once, available to 
everyone everywhere, no app store headaches, no platform-specific 
considerations.


But we're making an app anyway, because of feedback from his customers 
which suggests that using bookmarks on mobile is too onerous.  They 
expressed a very strong preference for having in icon on their home 
screen, and even the one step needed to put a bookmark on their home 
screen was perceived as too difficult.  They'd much rather find, 
download, and install an app just to get an easy launch.


--
 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: Web vs Native (was Re: HTML5 limitations?)

[Bob Sneidar via use-livecode]

Add to list as necessary. I've already pulled in a few items from other posts. 
We can come up with a referendum/consensus on the topic. 

Traditional Apps:
UP SIDE
Better performance
No dependent on an internet connection (if server is not installed locally)
Many people still prefer to own product outright
Product keeps working even if company goes belly up
Generally has access to system resources that allowing a web app to have may be 
problematic
Information is locally secured and controlled

DOWN SIDE
Require advanced development personel to produce (high cost)
Can be cumbersome to upgrade/update
Use local storage
OS Update can make app buggy or unusable
Data must be secured and backed up by trained professionals 

Web Apps:
UP SIDE
Nothing to download
Purchases can be subscription based, guaranteeing steady income stream (upside 
for the dev!)
Generally universal (provided they are developed to be so)
Sites are typically high availability (given good ISP SLA and servers running 
in data center)

DOWN SIDE
Dependent on internet connection availability and speed
Purchases are typically subscription based (downside for the consumer!)
Prone to drive by attacks (site is compromised)


___
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: Web vs Native (was Re: HTML5 limitations?)

[Matt Maier via use-livecode]

On Wed, Jul 26, 2017 at 5:27 PM, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> hh wrote:
> >> RG wrote:
> >> My bigger question here is what needs to be delivered specifically
> >> in a web browser window vs a native app, and why?
> >
> > This questions browsers ("the web") as platform in general.
> > TMHO, you are too late with that question, by 25 years.
>
> Perhaps just poor writing on my part.  I'm not questioning whether web
> pages exist or are useful.  Of course they are.
>
> As I think about this more, there seem to be two question here:
>
> - What are the use-cases where a native app is a better choice
>   than a web app?
>

- when the app needs access to the phone's functions (notifications, GPS,
screen dimming, text messages, etc)
- when it's important that at least some of the app's features work in
degraded/denied signal environments (no/low data)
- when your users don't understand what they're doing and insist that they
can't find your web app in the app store
- when you want to ensure that you control the experience; a web app is
accessed through the browser which means the browser's navigation and
settings take priority


>
> - What are the perceived benefits of web apps and native apps?
>

- web apps make your app instantly available to everyone in the world who
has internet and a browser
- web apps automatically "support" all operating systems and devices,
provided they have internet and a browser
- web apps don't have to compromise with any of the app stores; you can
offer anything you want whenever you want
- web apps have more direct access to other web services, so if you need to
leverage them it can be easier

- native apps can easily be more expensive than web apps for the same
functionality because they have more and more specific standards

- there are several "hybrid app" options where you get something installed
on the phone but it's just the bare minimum, not the whole app; usually
it's a native browser that only navigates to the web app


>
> The first question is about actual capabilities, and the second is about
> the psychological drivers of clients and customers, which may or may not
> reflect those capabilities.
>
> --
>  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
>
___
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: Web vs Native (was Re: HTML5 limitations?)

[hh via use-livecode]

> RG wrote:
> - What are the use-cases where a native app is a better choice than a web app?
> - What are the perceived benefits of web apps and native apps?
> The first question is about actual capabilities, and the second is about the
> psychological drivers of clients and customers, which may or may not reflect
> those capabilities.

Yes. More specific and very clear now.

The answer to the first question is of course: Native is always better 
performant.
But with a web app you have "all-in-one": For example, no nasty switch to an 
other
app for a simple "wiki"-info, or for some lines of feed-back, or for looking 
into
news. A web app means: You are already "surfing".

These are my experiences from discussions with non-IT users/clients/customers
for the second question: They identify web apps with special (also) mobile apps,
special in that they are not connected to any download torture. And they expect
them to have _no_ minor performance. They forget, that they are in a web view 
when
they read or write or draw/paint, they are not a bit impressed, impressed as we 
are,
that some things are now also possible in the 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: Web vs Native (was Re: HTML5 limitations?)

[Richard Gaskin via use-livecode]

hh wrote:
>> RG wrote:
>> My bigger question here is what needs to be delivered specifically
>> in a web browser window vs a native app, and why?
>
> This questions browsers ("the web") as platform in general.
> TMHO, you are too late with that question, by 25 years.

Perhaps just poor writing on my part.  I'm not questioning whether web 
pages exist or are useful.  Of course they are.


As I think about this more, there seem to be two question here:

- What are the use-cases where a native app is a better choice
  than a web app?

- What are the perceived benefits of web apps and native apps?

The first question is about actual capabilities, and the second is about 
the psychological drivers of clients and customers, which may or may not 
reflect those capabilities.


--
 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: Web vs Native (was Re: HTML5 limitations?)

[hh via use-livecode]

> RG wrote:
> My bigger question here is what needs to be delivered specifically
> in a web browser window vs a native app, and why?

This questions browsers ("the web") as platform in general.
TMHO, you are too late with that question, by 25 years.


___
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: Web vs Native (was Re: HTML5 limitations?)

[Richard Gaskin via use-livecode]

hh wrote:

>> Mike K. wrote:
>> My perception is that the web experience is very close to a desktop-
>> native experience, and the two are almost interchangable. Running an
>> app in a browser feels and works almost the same as a native one
>> does.
>
> The HTML5 standalone builder...
...
> @Mike.
> Your experience is *much* better. May be I'm making even basic
> mistakes that cause an essential loss of speed and/or performance.

I'm not sure if Mike was thinking in terms of LC's C++ -> JS -> LC 
method.  My own question was about web deployment in general.  I 
certainly have more experience with LC, but don't mind JS and definitely 
enjoy the small size and great performance of writing directly in 
browser-native DOM/JS.  With the biggest companies in the industry 
throwing giant piles of money into JS engines, it's become very 
performant.


Subjectively I wouldn't put it on par with native apps (FB's web 
implementation is poor compared to their native app, and things like 
Google Docs feel a bit clumsy to me compared with LibreOffice).  But for 
things that need to be confined to a browser, JS is very nice.


My bigger question here is what needs to be delivered specifically in a 
web browser window vs a native app, and why?


So many mixed messages coming from audiences these days

--
 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: Web vs Native (was Re: HTML5 limitations?)

[hh via use-livecode]

> Mike K. wrote:
> My perception is that the web experience is very close to a desktop-native
> experience, and the two are almost interchangable. Running an app in a
> browser feels and works almost the same as a native one does.

The HTML5 standalone builder has greatly improved within the last year. Besides
networking and javascript-interaction with the calling web page are these my
experiences:

Compared to the LC IDE/desktop standalones there was in July 2016 at about a 
slow
down by factors of 3 (Safari) over 5 (Firefox) to 10 (Chrome/Opera). This is now
down to a slow down by factors of 2 (Safari), 4 (Firefox) and 6 (Chrome/Opera).
Loading speed is here at an average of 50 MBit/s down to less than 10 seconds
and reloading down to 3 secs using Safari, 6 secs using Firefox and 8 secs using
Chrome/Opera --- all on desktop. Server settings were optimized for that, as 
good
as I could do that.
The total minimum file size has doubled up but the new 'type' of html.mem-file
(though four times larger than the previous versions) has improved the overall
startup time significantly.

In sum the best result:
Using Safari on MacOS the slowdown of HTML5 standalones compared to IDE/desktop
standalones has arrived at about a factor of 2.
As the IDE also has improved its performance, this is a result better than I 
ever
expected to get. And it is at about 10 times faster than the first HTML5 
standalones.

OK, these are my own special trials and tests, at least 50 different examples, 
all
available for you to test by yourself ( hh.on-rev.com/html5/ . Replace "X.html" 
or
"hhX.html" with ".zip" for the source and compile with whatever version you 
like.)

There are, sadly, still very basic things missing, which make the HTML5 
standalone
builder, TMHO, not yet ready for "beta"-state.

@Mike.
Your experience is *much* better. May be I'm making even basic mistakes that 
cause
an essential loss of speed and/or performance. And I overlooked simple 
workarounds
for some missing basic functionality?
So could you please give one (or a few) examples so that we can reproduce such 
an
"almost interchangability"?
___
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: Web vs Native (was Re: HTML5 limitations?)

[Mike Kerner via use-livecode]

My perception is that the web experience is very close to a desktop-native
experience, and the two are almost interchangable.  Running an app in a
browser feels and works almost the same as a native one does.  However,
once you get to mobile, the web app experience is nowhere on par.  Even
mobile web pages are awkward and slow.  Transitions take forever,
especially when on the road on a cell data connection.  That is where
mobile apps really shine, especially if you can have a combination of local
and remote data storage and access.

On Wed, Jul 26, 2017 at 12:56 PM, hh via use-livecode <
use-livecode@lists.runrev.com> wrote:

> > JLG wrote:
> > In my case, the app is courseware and students are complaining they want
> it
> > to work on their mobile devices. Some don't have laptops and don't want
> to
> > use the computer lab. The options are to create mobile apps or
> alternately
> > run it in the mobile browser.
>
> There is currently really no chance to have it running with HTML5
> standalones.
> Compared to 8.0 minimum file sizes (i.e. standalone.js and
> standalone.html.mem)
> in 9.0 have increased in sum by a factor of 2 from 27 MByte to 55 MByte.
> Stacks/resources will add to that. (You need 9.0 if you wish to use
> javascript.)
> Even simple clocks with very basic animations have big problems to run in
> mobile
> browsers.
>
>
> ___
> 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: Web vs Native (was Re: HTML5 limitations?)

[hh via use-livecode]

> JLG wrote:
> In my case, the app is courseware and students are complaining they want it 
> to work on their mobile devices. Some don't have laptops and don't want to 
> use the computer lab. The options are to create mobile apps or alternately 
> run it in the mobile browser.

There is currently really no chance to have it running with HTML5 standalones.
Compared to 8.0 minimum file sizes (i.e. standalone.js and standalone.html.mem)
in 9.0 have increased in sum by a factor of 2 from 27 MByte to 55 MByte.
Stacks/resources will add to that. (You need 9.0 if you wish to use javascript.)
Even simple clocks with very basic animations have big problems to run in mobile
browsers.


___
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: Web vs Native (was Re: HTML5 limitations?)

[Richard Gaskin via use-livecode]

J. Landman Gay wrote:

> In my case, the app is courseware and students are complaining they
> want it to work on their mobile devices. Some don't have laptops and
> don't want to use the computer lab.

That's an interesting subset.  Do you have a feel for what percentage of 
that audience doesn't have a laptop?



> The options are to create mobile apps or alternately
> run it in the mobile browser.
>
> The app currently isn't suitable for either, but I think a mobile app
> would be easier. Regardless, it would still need a major rewrite.

Amen to that, sister.  As we consider HTML export there's one aspect I 
don't see discussed often, but is a key driver for the desirability of 
web apps as you noted:  web layouts MUST be responsive, adjusting 
themselves for any and all screen sizes.


Historically most LC projects tend to use separate layouts for mobile 
and desktop, but on the web users expect responsive design and will 
abandon or complain about sites that don't adjust gracefully to the 
confines of their device size.


This is now more than two years old:

85% of web users believe a company’s mobile website should be
just as good as or better than their desktop site.


In addition to layout, control sizes and types are also considerations, 
since most desktop apps use controls that are appropriate for the 
precision of a pointer but are too small for touch, or rely on mouse 
behaviors like mouseEnter and mouseWithin that don't exist in touch systems.



> The client also doesn't want to deal with Apple's 30% cut and they
> already  have their own registration system. So we may be out of luck.

Yes, with iOS we still have no choice.  For macOS you're in good 
company: developers are reporting more revenue, better customer 
engagement. and less hassle ignoring Apple's app store and just selling 
direct as we always have.


Survey Suggests Mac Developers Continue to Be Dissatisfied With Mac App 
Store



Why Do Developers Keep Leaving the Mac App Store?


Mac Developers Survey Results
Selling on the App Store VS Building Your Own Theme Park


--
 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: Web vs Native (was Re: HTML5 limitations?)

[J. Landman Gay via use-livecode]

On July 26, 2017 9:20:17 AM Richard Gaskin via use-livecode 
 wrote:



I believe Rick's "Why" here is key to much of what we may be doing over
the next couple years.


In my case, the app is courseware and students are complaining they want it 
to work on their mobile devices. Some don't have laptops and don't want to 
use the computer lab. The options are to create mobile apps or alternately 
run it in the mobile browser.


The app currently isn't suitable for either, but I think a mobile app would 
be easier. Regardless, it would still need a major rewrite.


The client also doesn't want to deal with Apple's 30% cut and they already 
have their own registration system. So we may be out of luck.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.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: Web vs Native (was Re: HTML5 limitations?)

[Richard Gaskin via use-livecode]

Roger Eller wrote:

> As for in-house or "corporate" mobile, they seem to also want
> everything to be web based as well.  I tried real hard to get
> LiveCode accepted for mobile development...

Well at least they're consistent in their desire for web apps.

I keep coming across people who insist they need web on desktop, but 
also insist on native apps on mobile, which seems to reflect much of the 
discussion we see here and in the forums.



> ...but they only wanted a tool that could create secure html5
> apps.

How do they define "secure"?

--
 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: Web vs Native (was Re: HTML5 limitations?)

[Roger Eller via use-livecode]

As for in-house or "corporate" mobile, they seem to also want everything to
be web based as well.  I tried real hard to get LiveCode accepted for
mobile development, but they only wanted a tool that could create secure
html5 apps.  This was back when LC html5 was only in early planning.

~Roger


On Wed, Jul 26, 2017 at 10:17 AM, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I believe Rick's "Why" here is key to much of what we may be doing over
> the next couple years.
>
> We developers currently find ourselves in a very strange place:
>
> On desktop, the requests are "Web! Web! Web!"
>
> On mobile, they're "Apps! Apps! Apps!"
>
> If the web offers advantages that can't be matched with native apps, why
> is this perceived as true for the desktop but not for mobile?
>
> If native apps offer advantages that can't be matched with the web, why is
> this perceived as true for mobile but not for the desktop?
>
> --
>  Richard Gaskin
>  Fourth World Systems
>  Software Design and Development for the Desktop, Mobile, and the Web
>  
>  ambassa...@fourthworld.comhttp://www.FourthWorld.com
>
>
> Rick Harrison wrote:
>
> > Why does the client want to move the project over to HTML5?
> > What advantage does he/she think it is going to provide that
> > the current setup does not?
> >
> > Based on the complexity of what you already have going I think
> > it could be a very serious waste of time and energy.
> >
> > It’s easier to just have a website where your users download
> > whatever version they need for their computer.  One for macOS,
> > one for Windows, and one for Unix.  If you need mobile versions
> > you can create them too.
> >
> > Trying to convert everything so it all runs in a client’s web-browser,
> > and too slowly at that considering all of your animations, I just
> > don’t see it.  You would be better off knowing you have all of
> > LC’s engine capabilities in your app than in trusting something
> > that is still listed as experimental - although soon to become beta.
> >
> > On the other hand if your client has very very deep pockets, and
> > isn’t in a rush to get it all done by tomorrow, you could make a
> > lot of money struggling with trying to get it all working.
> >
> > Good luck with whatever you do!
>
>
___
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

Web vs Native (was Re: HTML5 limitations?)

[Richard Gaskin via use-livecode]

I believe Rick's "Why" here is key to much of what we may be doing over 
the next couple years.


We developers currently find ourselves in a very strange place:

On desktop, the requests are "Web! Web! Web!"

On mobile, they're "Apps! Apps! Apps!"

If the web offers advantages that can't be matched with native apps, why 
is this perceived as true for the desktop but not for mobile?


If native apps offer advantages that can't be matched with the web, why 
is this perceived as true for mobile but not for the desktop?


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com


Rick Harrison wrote:

> Why does the client want to move the project over to HTML5?
> What advantage does he/she think it is going to provide that
> the current setup does not?
>
> Based on the complexity of what you already have going I think
> it could be a very serious waste of time and energy.
>
> It’s easier to just have a website where your users download
> whatever version they need for their computer.  One for macOS,
> one for Windows, and one for Unix.  If you need mobile versions
> you can create them too.
>
> Trying to convert everything so it all runs in a client’s web-browser,
> and too slowly at that considering all of your animations, I just
> don’t see it.  You would be better off knowing you have all of
> LC’s engine capabilities in your app than in trusting something
> that is still listed as experimental - although soon to become beta.
>
> On the other hand if your client has very very deep pockets, and
> isn’t in a rush to get it all done by tomorrow, you could make a
> lot of money struggling with trying to get it all working.
>
> Good luck with whatever you do!


___
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