Re: Where do we want LiveCode to go? (was "Re: Where LiveCode is Now")

[Jjs via use-livecode]

@Sean Ok i have to agree. It is looking very professional. and maybe you are 
right. In this way that i think that for employees of a company this is good to 
work with. Even the loading times, i acknowledge in that case it is workable. 
For an average unknown visitor or possible customer who comes by it takes too 
long to be attractive. 

Peter Bogdanoff via use-livecode  schreef op 9 
oktober 2019 08:32:58 CEST:
>Yes Sean, that looks good!
>
>Already when I see the table, I’m blind typing, trying the page up/down
>keys on the keyboard, resizing the window while it is loading, trying
>to stress it…
>
>Peter
>
>> On Oct 8, 2019, at 10:21 PM, Brian Milby via use-livecode
> wrote:
>> 
>> I'll say that is a good job so far.  The grid is very responsive (but
>I am
>> using a pretty fast laptop).  Second time to the page was much faster
>than
>> the first.  And I'll agree that some of the corporate web apps that I
>have
>> to use can take time to get themselves ready for anything.  Even the
>SAP
>> desktop client can be slow to load.
>> 
>> Thanks for posting this.
>> 
>> Brian
>> 
>> On Tue, Oct 8, 2019 at 8:18 PM Pi Digital via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
>> 
 On 8 Oct 2019, at 19:37, JJS via use-livecode <
>>> use-livecode@lists.runrev.com> wrote:
 
 So that's why i say, the HTML5 export is a nice thing to
>experiment, but
>>> no visitor is going to return after the first time of long waiting,
>not
>>> even if the 2nd time is somewhat quicker
>>> 
>>> 
>>> Again, this only potentially applies to the landing page, not a web
>app
>>> which any visitor would or could expect a loading time, especially
>if
>>> warned. Our clients are already happy with this. It’s still less or
>about
>>> the same as they experienced with the desktop app.
>>> 
>>> HTML5 deployment from LC is not intended for making web pages.
>>> 
>>> Have you loaded MS Dynamics or any other CRM for that matter in a
>browser.
>>> And yet they are used day in day out by thousands of businesses
>globally.
>>> Each MSD window is tedious - loading takes 16-20sec and
>inconsistent. LC
>>> html is a dream in comparison (despite its current bugs and
>screwups).
>>> 
>>> https://tariffanalyser.porrima.co.uk
>>> 
>>> Double click the circle icon to see some demo data and display 28k+
>>> records in a custom built DataGrid (coz datagrid2 is broken and mega
>slow
>>> at the moment).
>>> 
>>> That’s what I’m working on and it loads pretty fast in comparison.
>10
>>> seconds to download the app and engine, run, Connect to a list from
>MySQL
>>> via php, resize to fit the screen and display. (Note: this is not
>designed
>>> for mobile platforms)
>>> 
>>> Each sales agent will have a link on their desktop that will open up
>>> Chrome to this page as if opening a desktop app. And they can leave
>it open
>>> over night if they wish and come back to it the next morning after
>logging
>>> back into their machine.
>>> 
>>> This ‘experiment’ seems to be working.
>>> 
>>> Sean Cole
>>> Pi Digital Prod Ltd
>>> 
>>> ___
>>> use-livecode mailing list
>>> use-livecode@lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
>___
>use-livecode mailing list
>use-livecode@lists.runrev.com
>Please visit this url to subscribe, unsubscribe and manage your
>subscription preferences:
>http://lists.runrev.com/mailman/listinfo/use-livecode

-- 
Verstuurd vanaf mijn Android apparaat met K-9 Mail.
___
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: Where do we want LiveCode to go? (was "Re: Where LiveCode is Now")

[Peter Bogdanoff via use-livecode]

Yes Sean, that looks good!

Already when I see the table, I’m blind typing, trying the page up/down keys on 
the keyboard, resizing the window while it is loading, trying to stress it…

Peter

> On Oct 8, 2019, at 10:21 PM, Brian Milby via use-livecode 
>  wrote:
> 
> I'll say that is a good job so far.  The grid is very responsive (but I am
> using a pretty fast laptop).  Second time to the page was much faster than
> the first.  And I'll agree that some of the corporate web apps that I have
> to use can take time to get themselves ready for anything.  Even the SAP
> desktop client can be slow to load.
> 
> Thanks for posting this.
> 
> Brian
> 
> On Tue, Oct 8, 2019 at 8:18 PM Pi Digital via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> 
>>> On 8 Oct 2019, at 19:37, JJS via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
>>> 
>>> So that's why i say, the HTML5 export is a nice thing to experiment, but
>> no visitor is going to return after the first time of long waiting, not
>> even if the 2nd time is somewhat quicker
>> 
>> 
>> Again, this only potentially applies to the landing page, not a web app
>> which any visitor would or could expect a loading time, especially if
>> warned. Our clients are already happy with this. It’s still less or about
>> the same as they experienced with the desktop app.
>> 
>> HTML5 deployment from LC is not intended for making web pages.
>> 
>> Have you loaded MS Dynamics or any other CRM for that matter in a browser.
>> And yet they are used day in day out by thousands of businesses globally.
>> Each MSD window is tedious - loading takes 16-20sec and inconsistent. LC
>> html is a dream in comparison (despite its current bugs and screwups).
>> 
>> https://tariffanalyser.porrima.co.uk
>> 
>> Double click the circle icon to see some demo data and display 28k+
>> records in a custom built DataGrid (coz datagrid2 is broken and mega slow
>> at the moment).
>> 
>> That’s what I’m working on and it loads pretty fast in comparison. 10
>> seconds to download the app and engine, run, Connect to a list from MySQL
>> via php, resize to fit the screen and display. (Note: this is not designed
>> for mobile platforms)
>> 
>> Each sales agent will have a link on their desktop that will open up
>> Chrome to this page as if opening a desktop app. And they can leave it open
>> over night if they wish and come back to it the next morning after logging
>> back into their machine.
>> 
>> This ‘experiment’ seems to be working.
>> 
>> Sean Cole
>> Pi Digital Prod Ltd
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Where do we want LiveCode to go? (was "Re: Where LiveCode is Now")

[Brian Milby via use-livecode]

I'll say that is a good job so far.  The grid is very responsive (but I am
using a pretty fast laptop).  Second time to the page was much faster than
the first.  And I'll agree that some of the corporate web apps that I have
to use can take time to get themselves ready for anything.  Even the SAP
desktop client can be slow to load.

Thanks for posting this.

Brian

On Tue, Oct 8, 2019 at 8:18 PM Pi Digital via use-livecode <
use-livecode@lists.runrev.com> wrote:

> > On 8 Oct 2019, at 19:37, JJS via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > So that's why i say, the HTML5 export is a nice thing to experiment, but
> no visitor is going to return after the first time of long waiting, not
> even if the 2nd time is somewhat quicker
>
>
> Again, this only potentially applies to the landing page, not a web app
> which any visitor would or could expect a loading time, especially if
> warned. Our clients are already happy with this. It’s still less or about
> the same as they experienced with the desktop app.
>
> HTML5 deployment from LC is not intended for making web pages.
>
> Have you loaded MS Dynamics or any other CRM for that matter in a browser.
> And yet they are used day in day out by thousands of businesses globally.
> Each MSD window is tedious - loading takes 16-20sec and inconsistent. LC
> html is a dream in comparison (despite its current bugs and screwups).
>
> https://tariffanalyser.porrima.co.uk
>
> Double click the circle icon to see some demo data and display 28k+
> records in a custom built DataGrid (coz datagrid2 is broken and mega slow
> at the moment).
>
> That’s what I’m working on and it loads pretty fast in comparison. 10
> seconds to download the app and engine, run, Connect to a list from MySQL
> via php, resize to fit the screen and display. (Note: this is not designed
> for mobile platforms)
>
> Each sales agent will have a link on their desktop that will open up
> Chrome to this page as if opening a desktop app. And they can leave it open
> over night if they wish and come back to it the next morning after logging
> back into their machine.
>
> This ‘experiment’ seems to be working.
>
> Sean Cole
> Pi Digital Prod Ltd
>
> ___
> 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: Where do we want LiveCode to go? (was "Re: Where LiveCode is Now")

[Pi Digital via use-livecode]

> On 8 Oct 2019, at 19:37, JJS via use-livecode  
> wrote:
> 
> So that's why i say, the HTML5 export is a nice thing to experiment, but no 
> visitor is going to return after the first time of long waiting, not even if 
> the 2nd time is somewhat quicker


Again, this only potentially applies to the landing page, not a web app which 
any visitor would or could expect a loading time, especially if warned. Our 
clients are already happy with this. It’s still less or about the same as they 
experienced with the desktop app. 

HTML5 deployment from LC is not intended for making web pages. 

Have you loaded MS Dynamics or any other CRM for that matter in a browser. And 
yet they are used day in day out by thousands of businesses globally. Each MSD 
window is tedious - loading takes 16-20sec and inconsistent. LC html is a dream 
in comparison (despite its current bugs and screwups). 

https://tariffanalyser.porrima.co.uk

Double click the circle icon to see some demo data and display 28k+ records in 
a custom built DataGrid (coz datagrid2 is broken and mega slow at the moment). 

That’s what I’m working on and it loads pretty fast in comparison. 10 seconds 
to download the app and engine, run, Connect to a list from MySQL via php, 
resize to fit the screen and display. (Note: this is not designed for mobile 
platforms)

Each sales agent will have a link on their desktop that will open up Chrome to 
this page as if opening a desktop app. And they can leave it open over night if 
they wish and come back to it the next morning after logging back into their 
machine. 

This ‘experiment’ seems to be working. 

Sean Cole
Pi Digital Prod Ltd

___
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: Where do we want LiveCode to go? (was "Re: Where LiveCode is Now")

[Bob Sneidar via use-livecode]

When first connecting to a KIP plotter web portal it takes sometimes 20 to 30 
seconds to load the page. Before that it's blank. What we need to do is stop 
giving web devs right out of college the responsibility for creating web 
portals. ;-) (Always blame it on them yungsters is my motto.)

Bob S


> On Oct 8, 2019, at 09:19 , Richard Gaskin via use-livecode 
>  wrote:
> 
> Pi Digital wrote:
> 
> > I also don’t trust this statistic of 3 seconds. Count out 3 seconds
> > and see if that feels uncomfortable to you to give up.
> 
> 3 seconds is the shortest threshold I've seen suggested as critical.
> 
> But there's no debate on the principle in general: longer load times lose 
> users.

___
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: Where do we want LiveCode to go? (was "Re: Where LiveCode is Now")

[JJS via use-livecode]

If you watch the movie a bit on the link i posted about the webapps, it 
is quite interesting. Superfast loading, works on all platforms, on all 
browsers. Pages and applications. Works even Offline via caches. All 
your work is synced when going online again (in case you have a bad 
connection or whatever).


People adjust to speed, once you have a faster system with SSD for 
example and you go back to your previous computer which is slower, slow 
networking, slow harddrive etcetera, you get irritated quickly. So 
that's why i say, the HTML5 export is a nice thing to experiment, but no 
visitor is going to return after the first time of long waiting, not 
even if the 2nd time is somewhat quicker.


So i think Progressive Webapps is going to be the next leading thing and 
not only because Google wants it, but because it's already majorly 
supported by all webbrowsers.


Maybe this could be a new feature for LC server and apps. Just a wild 
thought.



Op 8-10-2019 om 18:19 schreef Richard Gaskin via use-livecode:

Pi Digital wrote:

> I also don’t trust this statistic of 3 seconds. Count out 3 seconds
> and see if that feels uncomfortable to you to give up.

3 seconds is the shortest threshold I've seen suggested as critical.

But there's no debate on the principle in general: longer load times 
lose users.


Awareness of this is not new.  Jacob Nielsen first drew attention to 
it back in the '90s, with his methodology and results summarized here:

https://www.nngroup.com/articles/response-times-3-important-limits/

Here Neil Patel brings this into the web era, with links to the 
original research:

https://neilpatel.com/blog/speed-is-a-killer/

Among the other links in Patel's article is the report from Google on 
the 3 second threshold, worth reading for the many useful details it 
provides. While we may nitpick details on their methods, there's no 
doubt Google has enough data to make such a claim.  So the most severe 
rebuttal that can be reasonably offered might be assuming a margin of 
error of 50%, making the threshold 4.5 seconds - which happens to be a 
quite close to what other devs regularly achieve, according to the 
first set of charts here:
https://www.thinkwithgoogle.com/marketing-resources/data-measurement/mobile-page-speed-new-industry-benchmarks/ 




There are many other research citations to be found (even more if you 
have access to the ACM library), and the general takeaway is that as 
web use grows, and network speeds increase, and more devs are aware of 
and supporting the benefits of delivering a great experience quickly, 
users increasingly expect a page to be downloaded AND rendered for use 
within just a few seconds.


The exact number of seconds may vary from study to study, but the 
principle remains constant across all research I've seen on the 
subject spanning more than two decades.


---

All that said

It's useful to remember those expectations are for loading web PAGES, 
not necessarily for loading web APPLICATIONS.


Of course a web app exists within a page, but the distinction is in 
its utility: generically, a page is something you read, with the 
outcome being obtaining information, while an app is something you 
use, with outcomes that can vary but are often more significant to the 
user than something that can be read.


Not even LC Ltd. would suggest using LC's HTML export to produce 
simple textual articles for the web.  It's more work and loads much 
slower than using simpler web-native methods.


I outlined the sweet spot for LC's HTML export a couple months ago:
http://lists.runrev.com/pipermail/use-livecode/2019-August/255911.html

It boils down to:

IF
  you have an existing LC app
AND
  its functionality would be non-trivial to translate to JS
AND
  it's of high value to your specific audience
THEN
  using LC's HTML export might be a good solution.


Assuming the landing page on your site and most other content is 
simple HTML, and your audience has reason to believe your app is 
valuable enough to them to be worth the wait, they'll wait.


In such a relatively specialized circumstance, stats describing user 
behavior on generic pages don't apply.


Looking ahead, WebASM is now supported in enough browsers that it's 
become practical to replace the current LC C++ engine -> JS method 
with LC C++ engine -> WebASM.  Doing so will benefit download, 
unpacking, and rendering times, in addition to general runtime 
performance.  It would be useful to hear from the team on when they 
think they may be able to embark on that transition.


---

Another option underutilized in our community remains one of the LC's 
secret strengths:


Streaming apps: Native apps with web benefits.

A slim standalone that can download UI and code stacks from a web 
server along with data deliver all the benefits of a web app in terms 
of the user always having the latest version and the ease for the 
developer in delivering updates.  But it avoids the janky rendering 
experience 

Re: Where do we want LiveCode to go? (was "Re: Where LiveCode is Now")

[Richard Gaskin via use-livecode]

Pi Digital wrote:

> I also don’t trust this statistic of 3 seconds. Count out 3 seconds
> and see if that feels uncomfortable to you to give up.

3 seconds is the shortest threshold I've seen suggested as critical.

But there's no debate on the principle in general: longer load times 
lose users.


Awareness of this is not new.  Jacob Nielsen first drew attention to it 
back in the '90s, with his methodology and results summarized here:

https://www.nngroup.com/articles/response-times-3-important-limits/

Here Neil Patel brings this into the web era, with links to the original 
research:

https://neilpatel.com/blog/speed-is-a-killer/

Among the other links in Patel's article is the report from Google on 
the 3 second threshold, worth reading for the many useful details it 
provides. While we may nitpick details on their methods, there's no 
doubt Google has enough data to make such a claim.  So the most severe 
rebuttal that can be reasonably offered might be assuming a margin of 
error of 50%, making the threshold 4.5 seconds - which happens to be a 
quite close to what other devs regularly achieve, according to the first 
set of charts here:

https://www.thinkwithgoogle.com/marketing-resources/data-measurement/mobile-page-speed-new-industry-benchmarks/


There are many other research citations to be found (even more if you 
have access to the ACM library), and the general takeaway is that as web 
use grows, and network speeds increase, and more devs are aware of and 
supporting the benefits of delivering a great experience quickly, users 
increasingly expect a page to be downloaded AND rendered for use within 
just a few seconds.


The exact number of seconds may vary from study to study, but the 
principle remains constant across all research I've seen on the subject 
spanning more than two decades.


---

All that said

It's useful to remember those expectations are for loading web PAGES, 
not necessarily for loading web APPLICATIONS.


Of course a web app exists within a page, but the distinction is in its 
utility: generically, a page is something you read, with the outcome 
being obtaining information, while an app is something you use, with 
outcomes that can vary but are often more significant to the user than 
something that can be read.


Not even LC Ltd. would suggest using LC's HTML export to produce simple 
textual articles for the web.  It's more work and loads much slower than 
using simpler web-native methods.


I outlined the sweet spot for LC's HTML export a couple months ago:
http://lists.runrev.com/pipermail/use-livecode/2019-August/255911.html

It boils down to:

IF
  you have an existing LC app
AND
  its functionality would be non-trivial to translate to JS
AND
  it's of high value to your specific audience
THEN
  using LC's HTML export might be a good solution.


Assuming the landing page on your site and most other content is simple 
HTML, and your audience has reason to believe your app is valuable 
enough to them to be worth the wait, they'll wait.


In such a relatively specialized circumstance, stats describing user 
behavior on generic pages don't apply.


Looking ahead, WebASM is now supported in enough browsers that it's 
become practical to replace the current LC C++ engine -> JS method with 
LC C++ engine -> WebASM.  Doing so will benefit download, unpacking, and 
rendering times, in addition to general runtime performance.  It would 
be useful to hear from the team on when they think they may be able to 
embark on that transition.


---

Another option underutilized in our community remains one of the LC's 
secret strengths:


Streaming apps: Native apps with web benefits.

A slim standalone that can download UI and code stacks from a web server 
along with data deliver all the benefits of a web app in terms of the 
user always having the latest version and the ease for the developer in 
delivering updates.  But it avoids the janky rendering experience of 
browser content, and a UI overloaded with a plethora of browser controls 
that have nothing to do with your app's functionality.  Bonus that you 
can cache what you download to support fully offline workflows.


The only additional cost to the user is a one-time download and install.

In some cases this is seen as prohibitive, and in a subset of those 
cases that perception may actually reflect reality.


But it's worth noting that many of the same orgs that say "No, we can't 
download and install an app, it's got to be in a browser!" are the same 
orgs that bypass the browser for mobile where they invest heavily for 
the superior user experience a native app provides.


--

Many factors go into the decision of whether an application experience 
is best delivered natively or within the confines of a browser window, 
and there's enough written all over the web that we don't need to list 
them all here.


I don't believe there's any single "best" for all possible apps.

If we evaluate the capabilities of what we're 

Re: Where do we want LiveCode to go? (was "Re: Where LiveCode is Now")

[Bob Sneidar via use-livecode]

And as we know from past experience, the loading bar doesn't even have to 
reflect the *actual* progress! ;-)

Bob S
 

> On Oct 8, 2019, at 04:45 , Pi Digital via use-livecode 
>  wrote:
> 
> That would be true for a ‘page’ that did not load in 3 sec but if you have a 
> loading bar they would probably be more willing. 

___
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: Where do we want LiveCode to go? (was "Re: Where LiveCode is Now")

[Jjs via use-livecode]

I really don't think so. Even with a loading bar, i aint gonna wait that long, 
maybe just one time. In the 28K8 era we waited for +20minutes for a few 
megabytes, because it was new. Now everyone is spoiled with fast internet and 
always in a hurry. "Remember that 87.6543 % of statistics are made up. " ...You 
made that up did you...

Pi Digital via use-livecode  schreef op 8 
oktober 2019 13:45:44 CEST:
>That would be true for a ‘page’ that did not load in 3 sec but if you
>have a loading bar they would probably be more willing. 
>
>While developing for HTML5 I have to post up to the website and then
>refresh the page to reload the whole thing which takes about 10
>seconds. But even after repeated times of this it has not become
>uncomfortable. 
>
>I also don’t trust this statistic of 3 seconds. Count out 3 seconds and
>see if that feels uncomfortable to you to give up. 53% is a ridiculous
>number for that level of impatience. Remember that 87.6543 % of
>statistics are made up.  
>
>Sean Cole
>Pi Digital Prod Ltd
>
>> On 7 Oct 2019, at 20:35, JJS via use-livecode
> wrote:
>> 
>> by the way scroll a bit down, you'll read: 53% of the website
>visitors will click away if it does not load within 3 seconds.
>> 
>> Think again about the html5 export...too slow to load.
>> 
>> Then you are better off writing a html page yourself and add html5
>stuff in it, mucho faster
>> 
>> 
>> Op 7-10-2019 om 21:31 schreef JJS via use-livecode:
>>> , while on the other hand you can put something extra on your
>website and it can be installable as a webapp on your mobile, so that
>it becomes faster than ever to load.
>>> 
>>> https://developers.google.com/web/progressive-web-apps
>>> 
>>> Op 7-10-2019 om 18:18 schreef Bob Sneidar via use-livecode:
 Because Apple is no longer going to accept apps that are nothing
>more than a web portal.
 
>> On Oct 5, 2019, at 05:47 , R.H. via use-livecode
> wrote:
>> 
>> Let us face the fact that today's browsers are capable of almost
>> everything you want to do with a rich application. Why should I
>develop
>> even desktop applications and mobile apps if pretty much the same
>can be
>> done in a modern browser? OK, it only has a single page
>interface, but do
>> people care? Already, even in LC, I am mostly developing for
>single page
>> interface design anyway and do not use separate windows.
 
 ___
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your
>subscription preferences:
 http://lists.runrev.com/mailman/listinfo/use-livecode
>>> 
>>> ___
>>> use-livecode mailing list
>>> use-livecode@lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your
>subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>___
>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

-- 
Verstuurd vanaf mijn Android apparaat met K-9 Mail.
___
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: Where do we want LiveCode to go? (was "Re: Where LiveCode is Now")

[Matthias Rebbe via use-livecode]

For me this depends on the website. 
For new unknown websites, let´s say i found the url by a google search, i would 
not wait any longer than 3, maybe 5 seconds, even if a loading bar would show 
up.

For websites i know or if i really have an important reason to visit them, i 
would wait of course longer. 

But for websites i do not know, no way.

Regards,
Matthias


Matthias Rebbe

free tools for Livecoders:
InstaMaker 
WinSignMaker Mac 

Matthias Rebbe

free tools for Livecoders:
InstaMaker 
WinSignMaker Mac 

> Am 08.10.2019 um 13:45 schrieb Pi Digital via use-livecode 
> mailto:use-livecode@lists.runrev.com>>:
> 
> That would be true for a ‘page’ that did not load in 3 sec but if you have a 
> loading bar they would probably be more willing. 
> 
> While developing for HTML5 I have to post up to the website and then refresh 
> the page to reload the whole thing which takes about 10 seconds. But even 
> after repeated times of this it has not become uncomfortable. 
> 
> I also don’t trust this statistic of 3 seconds. Count out 3 seconds and see 
> if that feels uncomfortable to you to give up. 53% is a ridiculous number for 
> that level of impatience. Remember that 87.6543 % of statistics are made up.  
> 
> Sean Cole
> Pi Digital Prod Ltd
> 
>> On 7 Oct 2019, at 20:35, JJS via use-livecode > > wrote:
>> 
>> by the way scroll a bit down, you'll read: 53% of the website visitors will 
>> click away if it does not load within 3 seconds.
>> 
>> Think again about the html5 export...too slow to load.
>> 
>> Then you are better off writing a html page yourself and add html5 stuff in 
>> it, mucho faster
>> 
>> 
>> Op 7-10-2019 om 21:31 schreef JJS via use-livecode:
>>> , while on the other hand you can put something extra on your website 
>>> and it can be installable as a webapp on your mobile, so that it becomes 
>>> faster than ever to load.
>>> 
>>> https://developers.google.com/web/progressive-web-apps 
>>> 
>>> 
>>> Op 7-10-2019 om 18:18 schreef Bob Sneidar via use-livecode:
 Because Apple is no longer going to accept apps that are nothing more than 
 a web portal.
 
>> On Oct 5, 2019, at 05:47 , R.H. via use-livecode 
>>  wrote:
>> 
>> Let us face the fact that today's browsers are capable of almost
>> everything you want to do with a rich application. Why should I develop
>> even desktop applications and mobile apps if pretty much the same can be
>> done in a modern browser? OK, it only has a single page interface, but do
>> people care? Already, even in LC, I am mostly developing for single page
>> interface design anyway and do not use separate windows.
 
 ___
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your 
 subscription preferences:
 http://lists.runrev.com/mailman/listinfo/use-livecode
>>> 
>>> ___
>>> use-livecode mailing list
>>> use-livecode@lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your 
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com 
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> ___
> 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: Where do we want LiveCode to go? (was "Re: Where LiveCode is Now")

[Pi Digital via use-livecode]

Hehe. That statistic is served by DoubleClick. Definitely NOT to be trusted! 
It’s also self-serving to Google’s narrative. Click the link to drill down to 
the source details and Safari blocks it as untrustworthy. Chrome doesn’t but 
that’s because it’s made by Google!! 53% at 3 seconds indeed. That’s probably 
people not trusting google ads and just trying to get back off those pages 
they’ve been redirected to. 

Sean Cole
Pi Digital Prod Ltd

> On 8 Oct 2019, at 12:46, Pi Digital  wrote:
> 
> That would be true for a ‘page’ that did not load in 3 sec but if you have a 
> loading bar they would probably be more willing. 
> 
> While developing for HTML5 I have to post up to the website and then refresh 
> the page to reload the whole thing which takes about 10 seconds. But even 
> after repeated times of this it has not become uncomfortable. 
> 
> I also don’t trust this statistic of 3 seconds. Count out 3 seconds and see 
> if that feels uncomfortable to you to give up. 53% is a ridiculous number for 
> that level of impatience. Remember that 87.6543 % of statistics are made up.  
> 
> Sean Cole
> Pi Digital Prod Ltd
> 
>>> On 7 Oct 2019, at 20:35, JJS via use-livecode 
>>>  wrote:
>>> 
>> by the way scroll a bit down, you'll read: 53% of the website visitors will 
>> click away if it does not load within 3 seconds.
>> 
>> Think again about the html5 export...too slow to load.
>> 
>> Then you are better off writing a html page yourself and add html5 stuff in 
>> it, mucho faster
>> 
>> 
>> Op 7-10-2019 om 21:31 schreef JJS via use-livecode:
>>> , while on the other hand you can put something extra on your website 
>>> and it can be installable as a webapp on your mobile, so that it becomes 
>>> faster than ever to load.
>>> 
>>> https://developers.google.com/web/progressive-web-apps
>>> 
>>> Op 7-10-2019 om 18:18 schreef Bob Sneidar via use-livecode:
 Because Apple is no longer going to accept apps that are nothing more than 
 a web portal.
 
> On Oct 5, 2019, at 05:47 , R.H. via use-livecode 
>  wrote:
> 
> Let us face the fact that today's browsers are capable of almost
> everything you want to do with a rich application. Why should I develop
> even desktop applications and mobile apps if pretty much the same can be
> done in a modern browser? OK, it only has a single page interface, but do
> people care? Already, even in LC, I am mostly developing for single page
> interface design anyway and do not use separate windows.
 
 ___
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your 
 subscription preferences:
 http://lists.runrev.com/mailman/listinfo/use-livecode
>>> 
>>> ___
>>> use-livecode mailing list
>>> use-livecode@lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your 
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
___
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: Where do we want LiveCode to go? (was "Re: Where LiveCode is Now")

[Pi Digital via use-livecode]

That would be true for a ‘page’ that did not load in 3 sec but if you have a 
loading bar they would probably be more willing. 

While developing for HTML5 I have to post up to the website and then refresh 
the page to reload the whole thing which takes about 10 seconds. But even after 
repeated times of this it has not become uncomfortable. 

I also don’t trust this statistic of 3 seconds. Count out 3 seconds and see if 
that feels uncomfortable to you to give up. 53% is a ridiculous number for that 
level of impatience. Remember that 87.6543 % of statistics are made up.  

Sean Cole
Pi Digital Prod Ltd

> On 7 Oct 2019, at 20:35, JJS via use-livecode  
> wrote:
> 
> by the way scroll a bit down, you'll read: 53% of the website visitors will 
> click away if it does not load within 3 seconds.
> 
> Think again about the html5 export...too slow to load.
> 
> Then you are better off writing a html page yourself and add html5 stuff in 
> it, mucho faster
> 
> 
> Op 7-10-2019 om 21:31 schreef JJS via use-livecode:
>> , while on the other hand you can put something extra on your website 
>> and it can be installable as a webapp on your mobile, so that it becomes 
>> faster than ever to load.
>> 
>> https://developers.google.com/web/progressive-web-apps
>> 
>> Op 7-10-2019 om 18:18 schreef Bob Sneidar via use-livecode:
>>> Because Apple is no longer going to accept apps that are nothing more than 
>>> a web portal.
>>> 
> On Oct 5, 2019, at 05:47 , R.H. via use-livecode 
>  wrote:
> 
> Let us face the fact that today's browsers are capable of almost
> everything you want to do with a rich application. Why should I develop
> even desktop applications and mobile apps if pretty much the same can be
> done in a modern browser? OK, it only has a single page interface, but do
> people care? Already, even in LC, I am mostly developing for single page
> interface design anyway and do not use separate windows.
>>> 
>>> ___
>>> use-livecode mailing list
>>> use-livecode@lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your 
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
___
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: Where do we want LiveCode to go? (was "Re: Where LiveCode is Now")

[JJS via use-livecode]

by the way scroll a bit down, you'll read: 53% of the website visitors 
will click away if it does not load within 3 seconds.


Think again about the html5 export...too slow to load.

Then you are better off writing a html page yourself and add html5 stuff 
in it, mucho faster



Op 7-10-2019 om 21:31 schreef JJS via use-livecode:
, while on the other hand you can put something extra on your 
website and it can be installable as a webapp on your mobile, so that 
it becomes faster than ever to load.


https://developers.google.com/web/progressive-web-apps

Op 7-10-2019 om 18:18 schreef Bob Sneidar via use-livecode:
Because Apple is no longer going to accept apps that are nothing more 
than a web portal.


On Oct 5, 2019, at 05:47 , R.H. via use-livecode 
 wrote:


Let us face the fact that today's browsers are capable of almost
everything you want to do with a rich application. Why should I develop
even desktop applications and mobile apps if pretty much the same 
can be
done in a modern browser? OK, it only has a single page interface, 
but do
people care? Already, even in LC, I am mostly developing for single 
page

interface design anyway and do not use separate windows.


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Where do we want LiveCode to go? (was "Re: Where LiveCode is Now")

[JJS via use-livecode]

, while on the other hand you can put something extra on your 
website and it can be installable as a webapp on your mobile, so that it 
becomes faster than ever to load.


https://developers.google.com/web/progressive-web-apps

Op 7-10-2019 om 18:18 schreef Bob Sneidar via use-livecode:

Because Apple is no longer going to accept apps that are nothing more than a 
web portal.


On Oct 5, 2019, at 05:47 , R.H. via use-livecode 
 wrote:

Let us face the fact that today's browsers are capable of almost
everything you want to do with a rich application. Why should I develop
even desktop applications and mobile apps if pretty much the same can be
done in a modern browser? OK, it only has a single page interface, but do
people care? Already, even in LC, I am mostly developing for single page
interface design anyway and do not use separate windows.


___
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: Where do we want LiveCode to go? (was "Re: Where LiveCode is Now")

[Bob Sneidar via use-livecode]

Because Apple is no longer going to accept apps that are nothing more than a 
web portal. 

> On Oct 5, 2019, at 05:47 , R.H. via use-livecode 
>  wrote:
> 
> Let us face the fact that today's browsers are capable of almost
> everything you want to do with a rich application. Why should I develop
> even desktop applications and mobile apps if pretty much the same can be
> done in a modern browser? OK, it only has a single page interface, but do
> people care? Already, even in LC, I am mostly developing for single page
> interface design anyway and do not use separate windows.


___
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: Where do we want LiveCode to go? (was "Re: Where LiveCode is Now")

[Bob Sneidar via use-livecode]

I have a theory that the solution to a problem cannot be simpler than the 
problem itself. If it is, then the problem wasn't as complex as first imagined. 

The issue with developing with multiple dissimilar platforms is that the 
interface is SOOO different between desktop and mobile, that a method which 
would make sense on one platform has no corrolary on another. 

The reason Windows/MacOS/Linux cross platform objects work so well is that they 
are so nearly identical in function (if not form). Mobile platforms are 
considerable different. Whereas a desktop window can be any size, a mobile app 
doesn't have windows per se. The android has a file system, the iOS does not 
(at east not one you can access). Desktop systems allow for relatively easy 
cross application communication. iOS is specifically designed to prevent this 
without at least being challenged. Desktop systems have popup menus 
(effectively a window on top of a window). Mobile devices, at least iOS has 
scroll wheels. 

I have not developed for mobile simply because when I had the business license, 
I was too lazy to get started before the license expired, and I didn't want to 
get into a situation where to add a new feature once in a while I needed to 
reup the license. I pay out of my own pocket for LC, but use it for work only. 
But it seems reading the list that mobile dev, while difficult to deploy, is 
manageable. And since deployment is a moving target anyway, the way Apple keeps 
changing xCode, I'm not sure LC could do any more to ease that process. 

Bob S


> On Oct 4, 2019, at 18:26 , Alex Tweedly via use-livecode 
>  wrote:
> 
>> LC is *an easy* environment/language to develop cross-platform apps for all 
>> major platforms
>> 
> That's right - it's already "easiest", but it's not "easy".
> 
> Currently you can't write even very simple apps using the 'built-in', 
> cross-platform features and get something acceptable for the mobile 
> platforms. You need to use some combination of "mobileXXX' and  "iosXXX'" or 
> "androidXXX" functions to get something that is even remotely acceptable as a 
> 'finished' app.


___
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: Where do we want LiveCode to go? (was "Re: Where LiveCode is Now")

[Pi Digital via use-livecode]

Hi Roland

This is the very reason my client and I have opted for the HTML5 LC. Easy 
language for him to handle, operating in the browser, no need to go through IT 
departments to have it installed on their systems. This is a seriously MAJOR 
plus for us. 100% of my clients customers IT depts have adopted Chrome as their 
default browser whether on Mac or PC. 

Its got a large amount of issues though at the moment which I will be ironing 
out this month. I’m very keen to have it working. 

Sean Cole
Pi Digital Prod Ltd

> On 5 Oct 2019, at 13:47, R.H. via use-livecode 
>  wrote:
> 
> I always appreciate Richards insight and clear expressions. Thank you
> Richard.
> 
> What do we really want LiveCode to be?
> 
> Honestly, I would enjoy LiveCode to replace JavaScript and would put this
> as CHOICE NUMBER ONE, ONE and ONE.
> 
> And, of course, I know, this will not work.
> 
> Let us face the fact that today's browsers are capable of almost
> everything you want to do with a rich application. Why should I develop
> even desktop applications and mobile apps if pretty much the same can be
> done in a modern browser? OK, it only has a single page interface, but do
> people care? Already, even in LC, I am mostly developing for single page
> interface design anyway and do not use separate windows.
> 
> Probably, any other language faces the same dilemma. Maybe it could be
> possible using LiveCode to translate LC source code to source code in
> JavaScript? But probably not, since JavaScript heavily relies on the DOM in
> the browser and LC basically has nothing to do with a browser and its
> objects.
> 
> So, I am out of ideas.
> 
> Roland
> ___
> 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

Where do we want LiveCode to go? (was "Re: Where LiveCode is Now")

[R.H. via use-livecode]

I always appreciate Richards insight and clear expressions. Thank you
Richard.

What do we really want LiveCode to be?

Honestly, I would enjoy LiveCode to replace JavaScript and would put this
as CHOICE NUMBER ONE, ONE and ONE.

And, of course, I know, this will not work.

Let us face the fact that today's browsers are capable of almost
everything you want to do with a rich application. Why should I develop
even desktop applications and mobile apps if pretty much the same can be
done in a modern browser? OK, it only has a single page interface, but do
people care? Already, even in LC, I am mostly developing for single page
interface design anyway and do not use separate windows.

Probably, any other language faces the same dilemma. Maybe it could be
possible using LiveCode to translate LC source code to source code in
JavaScript? But probably not, since JavaScript heavily relies on the DOM in
the browser and LC basically has nothing to do with a browser and its
objects.

So, I am out of ideas.

Roland
___
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: Where do we want LiveCode to go? (was "Re: Where LiveCode is Now")

[Alex Tweedly via use-livecode]

Thank you Richard for diverting us onto a more productive direction.

This won't be my only reply to this thread. This is mostly a discussion 
of  "what do I want", rather than "what can we do".


On 04/10/2019 18:47, Richard Gaskin via use-livecode wrote:

"Where would we like LiveCode to be?"

Usually we think of a spectrum  "good, better, best ...", or perhaps 
"easy, easier, easiest".


But in this context, the spectrum is backwards. We already have (IMO)

LC is *the easiest* environment/language to develop cross-platform 
apps for all major platforms

but I think we need to aim MUCH higher; I want to see

LC is *an easy* environment/language to develop cross-platform apps 
for all major platforms



That's right - it's already "easiest", but it's not "easy".

Currently you can't write even very simple apps using the 'built-in', 
cross-platform features and get something acceptable for the mobile 
platforms. You need to use some combination of "mobileXXX' and  
"iosXXX'" or "androidXXX" functions to get something that is even 
remotely acceptable as a 'finished' app.


We even have an entire (ok, short :-) lesson on how to create a 
scrolling text field !!


In this lesson we will see how to set up a native mobile scroller to 
allow you to scroll the contents of a field.
IMHO, LC's built-in scrolling text field should do this (or whatever 
variation of this is needed) so that any scrolling text field will work, 
and look, and behave, as a user of each major platform would expect.


And if that is not possible, then we should have instead some new 
control, say "portable field" which abstracts out as much functionality 
as we can achieve cross-all-platform into easy-to-use controls. (And can 
probably use some clever backwards-compatability trick to allow easy 
porting of existing apps).


It's not just fields - for example "mobilePickDate" should *not* exist - 
there should just be a "pickDate" handler that works on all platforms; 
there should be a "textInput" handler that does 'the best it can' to 
provide appropriate functionality on *all* platforms - even if that 
means there are limitations in some implementations. Et cetera.



Of course, we also have to look at the problems of build / deployment on 
iOS and Android. There's lots of info about PWAs (Progressive Web Apps) 
- so much of it covered in so much hype and marketing, that as a casual 
reader I can't figure out exactly what to believe :-)  And my interest 
in spending time digging into it is limited by the fact that if it 
doesn't involve using Livecode then I'm almost certainly not interested :-)


But if even 25% of the hype is true, then it *should* be possible to 
produce such a web app with/from Livecode; all we need is offline 
operation/database or storage, pre-downloaded/installed executables, 
etc.  Even if this (again) required that we forego some of the existing 
controls (e.g. removing the current field, in favour of a portable 
field'), it should be possible to get a large subset of functionality on 
a way that can be deployed to all platforms.



OK, enough for tonight; more semi-rants tomorrow, and hopefully some 
actual useful suggestions by Monday :-) :-)


Alex.



___
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: Where LiveCode is Now

[J. Landman Gay via use-livecode]

Sorry, I didn't see it until January. It must have been forwarded.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On October 4, 2019 2:13:59 PM "Dr. Hawkins via use-livecode" 
 wrote:


On Oct 4, 2019, at 9:27 AM, Bob Sneidar via use-livecode 
 wrote:


Talk to Jacgue about that. Bring extra socks.



I’ll bring it up when we meet last week.  She seems to have misplaced next 
month’s message . . .


—
Richard E. Hawkins, Esq.
The Hawkins Law Firm
3430 E. Flamingo Rd.
Suite 232
Las Vegas, NV  89121
(702) 508-8462

___
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: Where LiveCode is Now

[Bob Sneidar via use-livecode]

On an old sock. Which explains why it's missing. 

Bob S


> On Oct 4, 2019, at 14:52 , Jeff Reynolds via use-livecode 
>  wrote:
> 
> That’s because she won’t write that message until a few months from now...
> 
> Jeff
> 
> On Oct 4, 2019, at 5:10 PM, use-livecode-requ...@lists.runrev.com wrote:
>> 
>>> 
>>> Talk to Jacgue about that. Bring extra socks. 
>> 
>> 
>> I?ll bring it up when we meet last week.  She seems to have misplaced next 
>> month?s message . . .
> 

___
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: Where do we want LiveCode to go? (was "Re: Where LiveCode is Now")

[JJS via use-livecode]

I agree with this, Livecode gives fairly quick insight in the 
programming process


Op 4-10-2019 om 20:09 schreef Richmond via use-livecode:

I would like LiveCode to be "up there" in the top 5 of languages
used in school world-wide for teaching within the next 10 years.

I would like private educational institutions to invest in LiveCode
and supply large-scale feedback to LiveCode Central as to any
educational enhancements they may feel will improve the IDE for 
teaching purposes.


For this to happen LiveCode has to be integrated into the curricula of 
standardised

examinations.

In England and Scotland educationalists are complaining about an 
alarming decrease
in high-school students enrolling in programming classes. I believe a 
lot of this is due
to an extremely steep start to the learning curve offered by the 
languages that are
currently "up there" and that LiveCode offers a far, far gentler entry 
point to

young learners.

Richmond.

On 4.10.19 20:47, Richard Gaskin via use-livecode wrote:

The question was: Where is LiveCode now?

It's in the 21st century, where proprietary software continues to 
thrive in consumer segments, but nearly all infrastructure and dev 
tools are Free and Open Source.


Compare and contrast:

-
Python in the third most popular language in the world.

Python is a language engine only. It has no IDE of its own, relying 
on third-party tools.  It has no packaging tools built in for mobile, 
and third-party offerings are so scarce that there are fewer Python 
apps in the mobile app stores than there are made with LiveCode.  
Even things we take for granted like having any user interface at all 
are treated like an afterthought, achievable only with your research 
into the various third-party options for such things, and your 
willingness to learn and integrate those add-on frameworks.


Python has many major players funding it:
https://www.python.org/psf/sponsorship/sponsors/

Python has a very active community, with few on payroll and most pull 
requests coming from the community.


-
LiveCode has made it into TIOBE's Top 100 languages list, but 
currently in the lower 50.


LiveCode has similar platform coverage, but with a rich IDE, built-in 
mobile packaging, and GUI support that's not merely included but an 
integral part of the language.


While LC has thousands of subscribers for the proprietary editions, 
it has no sponsors as big as Facebook, CapitalOne, AWS, or Google 
funding it. Even among the many companies deriving significant value 
from LC, some of the most successful businesses using LC for internal 
tools often use the Community edition and make few if any donations.


The LC community has only about half a dozen community members 
submitting pull requests with any regularity (big THANK YOU to those 
who do), despite half the project, the IDE, being written in the 
scripting language everyone in the community knows and loves.


-

In short, LiveCode delivers more, and does so with fewer resources.

In too many ways to count, comparisons between languages will always 
be unfair, and this oversimplified summary is no exception.  Details 
about history, shifting markets over time, and more than a little 
random luck play a role in adoption as much as anything else.


So I mean no disrespect to our scripting cousins using Python when I 
note how much LC delivers.


But I do mean to illustrate how much LC Ltd accomplishes with the 
resources at their disposal.


Rather than rebut the wealth of Dunning-Kruger inspired kvetching 
that has come to characterize a small corner of this community, or to 
contribute any kvetching of my own, I believe it's more productive to 
make choices about how we use our time which support productive 
outcomes.


To reorient, rather than ask, "Where is LiveCode now?", we might ask:

"Where would we like LiveCode to be?"

And when we have the luxury to choose how we spend our time, maybe we 
could choose to spend that time making what we want to have.


I would like to propose this forked thread be used to brainstorm 
ideas for how we can use time that might be spent on less productive 
outcomes toward having what we want with LC.


As good ideas emerge, I will do what I can in the role of Community 
Laison to help steward such things along.


But please, I forked this thread for a reason:  this is for 
initiatives to move things forward, to have what we want. Please use 
other threads for other purposes.  I find across much of life that 
when I spend too much time focused on things I don't want, it stifles 
awareness of opportunities to have what I do want.


Lets have what we want.

"Make it so, Number One."





___
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: Where LiveCode is Now

[Dr. Hawkins via use-livecode]

On Oct 4, 2019, at 9:27 AM, Bob Sneidar via use-livecode 
 wrote:
> 
> Talk to Jacgue about that. Bring extra socks. 


I’ll bring it up when we meet last week.  She seems to have misplaced next 
month’s message . . .

— 
Richard E. Hawkins, Esq.
The Hawkins Law Firm
3430 E. Flamingo Rd.
Suite 232
Las Vegas, NV  89121
(702) 508-8462

___
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: Where do we want LiveCode to go? (was "Re: Where LiveCode is Now")

[Richmond via use-livecode]

I would like LiveCode to be "up there" in the top 5 of languages
used in school world-wide for teaching within the next 10 years.

I would like private educational institutions to invest in LiveCode
and supply large-scale feedback to LiveCode Central as to any
educational enhancements they may feel will improve the IDE for teaching 
purposes.


For this to happen LiveCode has to be integrated into the curricula of 
standardised

examinations.

In England and Scotland educationalists are complaining about an 
alarming decrease
in high-school students enrolling in programming classes. I believe a 
lot of this is due
to an extremely steep start to the learning curve offered by the 
languages that are
currently "up there" and that LiveCode offers a far, far gentler entry 
point to

young learners.

Richmond.

On 4.10.19 20:47, Richard Gaskin via use-livecode wrote:

The question was: Where is LiveCode now?

It's in the 21st century, where proprietary software continues to 
thrive in consumer segments, but nearly all infrastructure and dev 
tools are Free and Open Source.


Compare and contrast:

-
Python in the third most popular language in the world.

Python is a language engine only. It has no IDE of its own, relying on 
third-party tools.  It has no packaging tools built in for mobile, and 
third-party offerings are so scarce that there are fewer Python apps 
in the mobile app stores than there are made with LiveCode.  Even 
things we take for granted like having any user interface at all are 
treated like an afterthought, achievable only with your research into 
the various third-party options for such things, and your willingness 
to learn and integrate those add-on frameworks.


Python has many major players funding it:
https://www.python.org/psf/sponsorship/sponsors/

Python has a very active community, with few on payroll and most pull 
requests coming from the community.


-
LiveCode has made it into TIOBE's Top 100 languages list, but 
currently in the lower 50.


LiveCode has similar platform coverage, but with a rich IDE, built-in 
mobile packaging, and GUI support that's not merely included but an 
integral part of the language.


While LC has thousands of subscribers for the proprietary editions, it 
has no sponsors as big as Facebook, CapitalOne, AWS, or Google funding 
it. Even among the many companies deriving significant value from LC, 
some of the most successful businesses using LC for internal tools 
often use the Community edition and make few if any donations.


The LC community has only about half a dozen community members 
submitting pull requests with any regularity (big THANK YOU to those 
who do), despite half the project, the IDE, being written in the 
scripting language everyone in the community knows and loves.


-

In short, LiveCode delivers more, and does so with fewer resources.

In too many ways to count, comparisons between languages will always 
be unfair, and this oversimplified summary is no exception.  Details 
about history, shifting markets over time, and more than a little 
random luck play a role in adoption as much as anything else.


So I mean no disrespect to our scripting cousins using Python when I 
note how much LC delivers.


But I do mean to illustrate how much LC Ltd accomplishes with the 
resources at their disposal.


Rather than rebut the wealth of Dunning-Kruger inspired kvetching that 
has come to characterize a small corner of this community, or to 
contribute any kvetching of my own, I believe it's more productive to 
make choices about how we use our time which support productive outcomes.


To reorient, rather than ask, "Where is LiveCode now?", we might ask:

"Where would we like LiveCode to be?"

And when we have the luxury to choose how we spend our time, maybe we 
could choose to spend that time making what we want to have.


I would like to propose this forked thread be used to brainstorm ideas 
for how we can use time that might be spent on less productive 
outcomes toward having what we want with LC.


As good ideas emerge, I will do what I can in the role of Community 
Laison to help steward such things along.


But please, I forked this thread for a reason:  this is for 
initiatives to move things forward, to have what we want.  Please use 
other threads for other purposes.  I find across much of life that 
when I spend too much time focused on things I don't want, it stifles 
awareness of opportunities to have what I do want.


Lets have what we want.

"Make it so, Number One."





___
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

Where do we want LiveCode to go? (was "Re: Where LiveCode is Now")

[Richard Gaskin via use-livecode]

The question was: Where is LiveCode now?

It's in the 21st century, where proprietary software continues to thrive 
in consumer segments, but nearly all infrastructure and dev tools are 
Free and Open Source.


Compare and contrast:

-
Python in the third most popular language in the world.

Python is a language engine only. It has no IDE of its own, relying on 
third-party tools.  It has no packaging tools built in for mobile, and 
third-party offerings are so scarce that there are fewer Python apps in 
the mobile app stores than there are made with LiveCode.  Even things we 
take for granted like having any user interface at all are treated like 
an afterthought, achievable only with your research into the various 
third-party options for such things, and your willingness to learn and 
integrate those add-on frameworks.


Python has many major players funding it:
https://www.python.org/psf/sponsorship/sponsors/

Python has a very active community, with few on payroll and most pull 
requests coming from the community.


-
LiveCode has made it into TIOBE's Top 100 languages list, but currently 
in the lower 50.


LiveCode has similar platform coverage, but with a rich IDE, built-in 
mobile packaging, and GUI support that's not merely included but an 
integral part of the language.


While LC has thousands of subscribers for the proprietary editions, it 
has no sponsors as big as Facebook, CapitalOne, AWS, or Google funding 
it. Even among the many companies deriving significant value from LC, 
some of the most successful businesses using LC for internal tools often 
use the Community edition and make few if any donations.


The LC community has only about half a dozen community members 
submitting pull requests with any regularity (big THANK YOU to those who 
do), despite half the project, the IDE, being written in the scripting 
language everyone in the community knows and loves.


-

In short, LiveCode delivers more, and does so with fewer resources.

In too many ways to count, comparisons between languages will always be 
unfair, and this oversimplified summary is no exception.  Details about 
history, shifting markets over time, and more than a little random luck 
play a role in adoption as much as anything else.


So I mean no disrespect to our scripting cousins using Python when I 
note how much LC delivers.


But I do mean to illustrate how much LC Ltd accomplishes with the 
resources at their disposal.


Rather than rebut the wealth of Dunning-Kruger inspired kvetching that 
has come to characterize a small corner of this community, or to 
contribute any kvetching of my own, I believe it's more productive to 
make choices about how we use our time which support productive outcomes.


To reorient, rather than ask, "Where is LiveCode now?", we might ask:

"Where would we like LiveCode to be?"

And when we have the luxury to choose how we spend our time, maybe we 
could choose to spend that time making what we want to have.


I would like to propose this forked thread be used to brainstorm ideas 
for how we can use time that might be spent on less productive outcomes 
toward having what we want with LC.


As good ideas emerge, I will do what I can in the role of Community 
Laison to help steward such things along.


But please, I forked this thread for a reason:  this is for initiatives 
to move things forward, to have what we want.  Please use other threads 
for other purposes.  I find across much of life that when I spend too 
much time focused on things I don't want, it stifles awareness of 
opportunities to have what I do want.


Lets have what we want.

"Make it so, Number One."


--
 Richard Gaskin
 LiveCode Community Laison


___
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: Where LiveCode is Now

[Bob Sneidar via use-livecode]

Talk to Jacgue about that. Bring extra socks. 

Bob S


> On Oct 4, 2019, at 04:36 , Heather Laine via use-livecode 
>  wrote:
> 
> We do not as yet have the ability to time travel in order to prevent the 
> issue having arisen.


___
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: Where LiveCode is Now

[Kurt Kaufman via use-livecode]

There are probably quite a few who, like me, have used LC/RR/MC for years, 
creating in-house labor-saving devices (for myself, they are mostly of the 
variety "pull A,B, and C from X, rearrange them and format them to Y, and spit 
the result out as a text file").  Could I have [attempted] to write these 
un-glamorous utilities in another language? Probably, but I really am not a 
"natural" programmer, so I greatly appreciate the shortcuts to functionality 
that LC provides. I sometimes watch this list for new developments or other 
news, and I am grateful to be able to query it for help when I need a function 
that I can't figure out on my own. Some bumps here and there, but I am like the 
fact that the discourse here is almost always civil.
Thanks!
-Kurt
___
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: Where LiveCode is Now

[Heather Laine via use-livecode]

Dear Sean,

If you look back through that thread you will see that we did more than 
apologise. We expressed regret, and we also showed willing to jump in and fix 
the issue as soon as was humanly possible. Which is all anyone can do when 
something goes wrong. We do not as yet have the ability to time travel in order 
to prevent the issue having arisen.

It is time to move on from this thread.

Warmest regards,

Heather

Heather Laine
Customer Services Manager
LiveCode Ltd
www.livecode.com



> On 4 Oct 2019, at 11:28, Pi Digital via use-livecode 
>  wrote:
> 
> And there it is (indeed)!! You still managed to get out of apologising to me, 
> LC. Pft! 
> 
> Sean Cole
> Pi Digital Prod Ltd


___
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: Where LiveCode is Now

[Pi Digital via use-livecode]

And there it is (indeed)!! You still managed to get out of apologising to me, 
LC. Pft! 

Sean Cole
Pi Digital Prod Ltd

> On 4 Oct 2019, at 10:11, Heather Laine via use-livecode 
>  wrote:
> 
> :) and there it is. I am happy and relieved to be able to forgive and move 
> on.
> 
> We all want the same thing here: for LiveCode to be hugely successful. Our 
> official BHAG (Big Hairy Audacious Goal, this is real actual terminology 
> believe it or not) as stated in our company articles is and has been for some 
> years to see LiveCode as number 1 on the Tiobe index. Our means for getting 
> there may differ, but we can at least all agree on the goal.
> 
> Onwards and upwards.
> 
> Warmest Regards, 
> 
> Heather
> 
> Heather Laine
> Customer Services Manager
> LiveCode Ltd
> www.livecode.com
> 
> 
> 
>> On 4 Oct 2019, at 10:02, Richmond via use-livecode 
>>  wrote:
>> 
>> Possibly, on rereading my intemperate posting I should be banished to the 
>> naughty corner at least.
>> 
>> I do apologise for all the obvious offense my posting has caused.
>> 
>> However, I will state that that posting was an explosion of frustration 
>> about some issues I feel are very real indeed.
>> 
>> I do hope that:
>> 
>> 1. You will all forgive me.
>> 
>> 2. Support my coming efforts vis Jacque Landman Gay's message to establish a 
>> fund-raiser to
>> finance a concerted effort at getting as many out-standing bugs in LiveCode 
>> sorted out as possible.
>> 
>> Richmond.
>> 
>>> On 4.10.19 10:46, Curry Kenworthy via use-livecode wrote:
>>> 
>>> To banish Richmond, or to banish bugs? Which is the bigger problem?
>>> 
>>> Which is more directly responsible for the existence of this thread?
>>> 
>>> I would encourage looking at "net" bugs: bugs fixed, versus bugs introduced 
>>> or regressed, during a time period. In development there are always bugs, 
>>> and there are always fixes. Both the number of bugs and the number fixed 
>>> are pretty impressive. Comparing the two (which takes a while, as we're 
>>> still finding old bugs) might be more meaningful than promoting either on 
>>> its own.
>>> 
>>> Not sure about "net" Richmonds. :)
>>> 
>>> I think reducing net bugs would be a plus all around, and would make a good 
>>> impression on new and old customers. I care about LC, use it exclusively, 
>>> and want the best for it.
>>> 
>>> Reducing net Richmonds could be pleasant superficially (ah, the peace, the 
>>> lack of random vulgarities, witty insults, and topic stew) but might risk 
>>> losing the occasional valuable insight. Not to mention an LC teacher and 
>>> Unicode tester and all-around issue awareness raiser. And a longstanding 
>>> part and practically parcel of this list community, whose missing presence 
>>> might be felt.
>>> 
>>> LC can and will do as they wish, and some order and decency must be 
>>> maintained on any list for that list to survive, but that's my 2 cents as 
>>> an LC well-wisher and thinking only of what LC stands to lose or gain, not 
>>> for myself.
>>> 
>>> I'm part Scottish too, you know? Our genetic curse may be that we bottle in 
>>> all our opinions (the very few we have) and keep it inside our entire 
>>> lives, and never express ourselves in the least. (Ha ha.) For several years 
>>> on some occasions with fairly wild threads I've wanted to joke: for 
>>> goodness sake, speak up for yourself! But I rarely chime in here. I'm 
>>> writing this email now, just in case it's the last opportunity to say that.
>>> 
>>> Hello and bye for now, to everyone, back to work
>>> 
>>> Best wishes,
>>> 
>>> Curry K.
>>> 
>>> ___
>>> use-livecode mailing list
>>> use-livecode@lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your 
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> 
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Where LiveCode is Now

[Heather Laine via use-livecode]

:) and there it is. I am happy and relieved to be able to forgive and move on.

We all want the same thing here: for LiveCode to be hugely successful. Our 
official BHAG (Big Hairy Audacious Goal, this is real actual terminology 
believe it or not) as stated in our company articles is and has been for some 
years to see LiveCode as number 1 on the Tiobe index. Our means for getting 
there may differ, but we can at least all agree on the goal.

Onwards and upwards.

Warmest Regards, 

Heather

Heather Laine
Customer Services Manager
LiveCode Ltd
www.livecode.com



> On 4 Oct 2019, at 10:02, Richmond via use-livecode 
>  wrote:
> 
> Possibly, on rereading my intemperate posting I should be banished to the 
> naughty corner at least.
> 
> I do apologise for all the obvious offense my posting has caused.
> 
> However, I will state that that posting was an explosion of frustration about 
> some issues I feel are very real indeed.
> 
> I do hope that:
> 
> 1. You will all forgive me.
> 
> 2. Support my coming efforts vis Jacque Landman Gay's message to establish a 
> fund-raiser to
> finance a concerted effort at getting as many out-standing bugs in LiveCode 
> sorted out as possible.
> 
> Richmond.
> 
> On 4.10.19 10:46, Curry Kenworthy via use-livecode wrote:
>> 
>> To banish Richmond, or to banish bugs? Which is the bigger problem?
>> 
>> Which is more directly responsible for the existence of this thread?
>> 
>> I would encourage looking at "net" bugs: bugs fixed, versus bugs introduced 
>> or regressed, during a time period. In development there are always bugs, 
>> and there are always fixes. Both the number of bugs and the number fixed are 
>> pretty impressive. Comparing the two (which takes a while, as we're still 
>> finding old bugs) might be more meaningful than promoting either on its own.
>> 
>> Not sure about "net" Richmonds. :)
>> 
>> I think reducing net bugs would be a plus all around, and would make a good 
>> impression on new and old customers. I care about LC, use it exclusively, 
>> and want the best for it.
>> 
>> Reducing net Richmonds could be pleasant superficially (ah, the peace, the 
>> lack of random vulgarities, witty insults, and topic stew) but might risk 
>> losing the occasional valuable insight. Not to mention an LC teacher and 
>> Unicode tester and all-around issue awareness raiser. And a longstanding 
>> part and practically parcel of this list community, whose missing presence 
>> might be felt.
>> 
>> LC can and will do as they wish, and some order and decency must be 
>> maintained on any list for that list to survive, but that's my 2 cents as an 
>> LC well-wisher and thinking only of what LC stands to lose or gain, not for 
>> myself.
>> 
>> I'm part Scottish too, you know? Our genetic curse may be that we bottle in 
>> all our opinions (the very few we have) and keep it inside our entire lives, 
>> and never express ourselves in the least. (Ha ha.) For several years on some 
>> occasions with fairly wild threads I've wanted to joke: for goodness sake, 
>> speak up for yourself! But I rarely chime in here. I'm writing this email 
>> now, just in case it's the last opportunity to say that.
>> 
>> Hello and bye for now, to everyone, back to work
>> 
>> Best wishes,
>> 
>> Curry K.
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> 
> ___
> 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: Where LiveCode is Now

[Richmond via use-livecode]

Possibly, on rereading my intemperate posting I should be banished to 
the naughty corner at least.


I do apologise for all the obvious offense my posting has caused.

However, I will state that that posting was an explosion of frustration 
about some issues I feel are very real indeed.


I do hope that:

1. You will all forgive me.

2. Support my coming efforts vis Jacque Landman Gay's message to 
establish a fund-raiser to
finance a concerted effort at getting as many out-standing bugs in 
LiveCode sorted out as possible.


Richmond.

On 4.10.19 10:46, Curry Kenworthy via use-livecode wrote:


To banish Richmond, or to banish bugs? Which is the bigger problem?

Which is more directly responsible for the existence of this thread?

I would encourage looking at "net" bugs: bugs fixed, versus bugs 
introduced or regressed, during a time period. In development there 
are always bugs, and there are always fixes. Both the number of bugs 
and the number fixed are pretty impressive. Comparing the two (which 
takes a while, as we're still finding old bugs) might be more 
meaningful than promoting either on its own.


Not sure about "net" Richmonds. :)

I think reducing net bugs would be a plus all around, and would make a 
good impression on new and old customers. I care about LC, use it 
exclusively, and want the best for it.


Reducing net Richmonds could be pleasant superficially (ah, the peace, 
the lack of random vulgarities, witty insults, and topic stew) but 
might risk losing the occasional valuable insight. Not to mention an 
LC teacher and Unicode tester and all-around issue awareness raiser. 
And a longstanding part and practically parcel of this list community, 
whose missing presence might be felt.


LC can and will do as they wish, and some order and decency must be 
maintained on any list for that list to survive, but that's my 2 cents 
as an LC well-wisher and thinking only of what LC stands to lose or 
gain, not for myself.


I'm part Scottish too, you know? Our genetic curse may be that we 
bottle in all our opinions (the very few we have) and keep it inside 
our entire lives, and never express ourselves in the least. (Ha ha.) 
For several years on some occasions with fairly wild threads I've 
wanted to joke: for goodness sake, speak up for yourself! But I rarely 
chime in here. I'm writing this email now, just in case it's the last 
opportunity to say that.


Hello and bye for now, to everyone, back to work

Best wishes,

Curry K.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-livecode



___
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: Where LiveCode is Now

[JJS via use-livecode]

I followed this thread, and what came up to me is "Don't kill your darling"

I've seen this with Synthmaker/Flowstone happening too, people not 
happy, starting to rant or whatever, murdering the thing you love.


Be constructive!

I truly believe that a lot of programmers here, including myself, would 
have never become programmers if it wasn't for the easiness we can 
program with LiveCode.


This tool gave me insight in how other languages are working and a lot 
are similar, except for constructing code sentences with a bunch of ' " 
} god knows where to put them.


So try to learn Java/Kotlin/Swift/C++ and see how more difficult it is 
to get your head around it, then come back with flowers to LC.


I'm thankful of what i have made so far (although i still did not make 
any cent, but that's because I'm a lousy entrepreneur)


Sphere.

Op 3-10-2019 om 23:18 schreef Jeff Reynolds via use-livecode:

LC team,

I too so appreciate all the work the LC team has done over the years and 
continues to do. I’ve used probably a dozen different commercial coding systems 
over the decades and LC thru all it’s incarnations back to good old MetaCard 
with Scott was the one that provided the needed options, stability and power to 
get my multimedia exhibit and education projects done. It’s allowed me to be 
both designer and developer on projects that has created synergy that has made 
all the projects come out better. I know the limits of the system and when it’s 
worth trying to bleed some as it gets you something great and when it’s just 
not worth it and usually another design approach ends up working better. When 
I’ve had to work on projects that I couldn’t develop (complexity, timeline, 
feature needs) and be done in something like C it took way more resources and 
time and although I had really great programmers and I understood all the 
basics of what they were doing things could still get lost in translation and 
some things just turn into a quagmire.

There will always be bugs, feature not there yet, etc in any development system 
and we each have a very different set of needs and wants and the LC team can’t 
make us all perfectly happy at once, nor consistently. They are the ones on the 
front lines trying to make this a profitable business for them (they need to 
feed their families and they are not our serfs) and make decisions on what the 
priorities need to be. We can of course lobby for what we think our priorities 
are (and therefore LC’s), but that doesn’t make it so.

Many of us have based a lot of our livelihood on LC which is always a risk, but 
many times completely necessary. Yes I could do my projects more safely in C 
but I would be very poor as the time needed would suck out any profit at all. 
It’s always a tradeoff and one that needs constant assessment and not trying to 
push a development system to the limits as then you are in very dangerous 
territory — payoffs can be huge but crashes huge as well. I know I have done it 
in the past and very luckily survived but probably trimmed a few months off my 
lifespan to pay for it. I’ve run into bugs in the past with LC and have always 
found a work around for them on the current project and later most have been 
taken care of in LC, I realize it takes time and priorities are not always mine.

Yes features are always promised but reality always creeps in and resets things 
all the time. But LC has gone on longer and further and covering more platforms 
than most any system out there. With every new platform or major feature it 
adds to the permutations of issues and bugs so things can go at an exponential 
curve of development anymore and decisions need to be made to best keep all the 
balls in the air for the whole system.

Richmond, you need to listen to your mother some and if you don’t have 
something constructive to say try and be quiet some, or just pontificate in 
cheese instead of being insulting. I’m sorry but your flaming of LC staff (and 
the community) constantly is just plain annoying. It does no one any good, it’s 
not the way to make good change. Come to the table with constructive, 
reasonable and positive comments and not nasty ones. Sorry, you don’t represent 
this “community”, at least none I am part of. You complain the LC treats us 
with distain, well I don’t feel like LC does and your comments just fill me 
with distain for your comments. If you talk like that to others then expect to 
be treated with distain.

You probably think I’m an LC cult member, but you are wrong, I’m the last guy 
in the room cults would go for. I think too much for myself and try to treat 
others reasonably and keep expectations in line with reality, there are no 
magic bullets, most all things are based on some thought and work, not a guru 
spewing truth which you seem to think you do and we should follow suit. Sorry 
not joining your cult.

LC all the way back to MetaCard has been a big part of making me a richer 
livelihood in both money and 

Re: Where LiveCode is Now

[Curry Kenworthy via use-livecode]

To banish Richmond, or to banish bugs? Which is the bigger problem?

Which is more directly responsible for the existence of this thread?

I would encourage looking at "net" bugs: bugs fixed, versus bugs 
introduced or regressed, during a time period. In development there are 
always bugs, and there are always fixes. Both the number of bugs and the 
number fixed are pretty impressive. Comparing the two (which takes a 
while, as we're still finding old bugs) might be more meaningful than 
promoting either on its own.


Not sure about "net" Richmonds. :)

I think reducing net bugs would be a plus all around, and would make a 
good impression on new and old customers. I care about LC, use it 
exclusively, and want the best for it.


Reducing net Richmonds could be pleasant superficially (ah, the peace, 
the lack of random vulgarities, witty insults, and topic stew) but might 
risk losing the occasional valuable insight. Not to mention an LC 
teacher and Unicode tester and all-around issue awareness raiser. And a 
longstanding part and practically parcel of this list community, whose 
missing presence might be felt.


LC can and will do as they wish, and some order and decency must be 
maintained on any list for that list to survive, but that's my 2 cents 
as an LC well-wisher and thinking only of what LC stands to lose or 
gain, not for myself.


I'm part Scottish too, you know? Our genetic curse may be that we bottle 
in all our opinions (the very few we have) and keep it inside our entire 
lives, and never express ourselves in the least. (Ha ha.) For several 
years on some occasions with fairly wild threads I've wanted to joke: 
for goodness sake, speak up for yourself! But I rarely chime in here. 
I'm writing this email now, just in case it's the last opportunity to 
say that.


Hello and bye for now, to everyone, back to work

Best wishes,

Curry K.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Where LiveCode is Now

[J. Landman Gay via use-livecode]

I was more impressed by the more than 1 fixes. :)
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On October 3, 2019 10:35:18 PM Mark Wieder via use-livecode 
 wrote:



On 10/3/19 7:51 PM, J. Landman Gay via use-livecode wrote:

Hm. The search stops at 1.


Try narrowing it by date. For instance, an impressive 130 bugs resolved
since the release of LC 9.0.5 on 16 May.



--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-livecode





___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Where LiveCode is Now

[Mark Wieder via use-livecode]

On 10/3/19 7:51 PM, J. Landman Gay via use-livecode wrote:

Hm. The search stops at 1.


Try narrowing it by date. For instance, an impressive 130 bugs resolved 
since the release of LC 9.0.5 on 16 May.




--
 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: Where LiveCode is Now

[J. Landman Gay via use-livecode]

Hm. The search stops at 1.

"This list is too long for The LiveCode Quality Control Center's little 
mind; the Next/Prev/First/Last buttons won't appear on individual bugs."

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On October 3, 2019 9:37:28 PM "J. Landman Gay via use-livecode" 
 wrote:



You speak for me too. The only people who could say such things about LC
are those who don't know them. Anyone who does know them knows that
everything Richmond said is false. "Ill-informed" is putting it mildly.

LC are very open to constructive criticism, but rants just make the speaker
a troll. We are in fact a caring community and I for one do not welcome a
member who feels common courtesy is disposable.

For a new perspective, try a search for all the fixed and resolved issues.

https://quality.livecode.com/buglist.cgi?chfieldto=Now=resolution_format=advanced=Fixed
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On October 3, 2019 7:23:00 PM PystCat via use-livecode
 wrote:


Hi Heather,

I can only speak for myself, however I think others might be with me on
this,  I think you guys ROCK!  I understand the complexities involved in
creating incredibly beautiful software that makes it look very easy to make
other software.   You make it easy for me to create easy to use apps and
hide all the complex logic behind the scenes.  For making my life easier, I
thank you guys.

Please take all the time you guys need to keep pushing out a great system.
You guys are artists.  Like all great artists, it takes time to create a
masterpiece.

Slàinte.
Paul


On Oct 3, 2019, at 12:25 PM, Heather Laine via use-livecode
 wrote:


Dear List Folks,


I'd like to reassure you, the team is anything but idle, and the fruits of
their labours are coming your way. I don't wish to steal Pano's thunder,
but you should look for an announcement on 9.0.5 tomorrow (all being well
with the build, which is currently undergoing final checks. Probably I've
just jinxed it by mentioning a release date, in direct contravention of my
rules.) 9.0.5 has had a fix shoehorned into it for the nasty debugger
crashing that was reported not long ago.


9.5.1 is well under way and shouldn't be long now, bringing the needed
updates for iOS among other things. I'm not going to even hint at a release
date of next week for this, its certain to cause a #fail.


9.6 is in progress with some nice new features and a first dp is not far
off. Real Soon Now :).


Yes, it has taken a little longer than usual between releases. A major
reason for this was the server move, which impacted our build bots and
delayed all test builds. Frustrating, but necessary work, and thankfully
that is all done now and everything is working smoothly again. One does not
appreciate the full complexity of these build bots until one attempts to
move them intact from one place to another.


The suggestion that all our efforts will remain with LCFM Native and never
bear fruit for LiveCode itself is based on a misconception, an idea that
somehow we are working on something other than LiveCode. We're not.
Everything we are building for LCFM Native is built with LiveCode. We
cannot do it without improving LiveCode. Those improvements will come back
to the community (many already have). Hermann... its not an infinite
effort. FileMaker is very much a finite set of code, with relatively slow
changes.


I hope you will like 9.0.5, 9.5.1 and 9.6, we're looking forward to
bringing them to you.


Best Regards,


Heather




Heather Laine
Customer Services Manager
LiveCode Ltd
www.livecode.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





___
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: Where LiveCode is Now

[J. Landman Gay via use-livecode]

You speak for me too. The only people who could say such things about LC 
are those who don't know them. Anyone who does know them knows that 
everything Richmond said is false. "Ill-informed" is putting it mildly.


LC are very open to constructive criticism, but rants just make the speaker 
a troll. We are in fact a caring community and I for one do not welcome a 
member who feels common courtesy is disposable.


For a new perspective, try a search for all the fixed and resolved issues.

https://quality.livecode.com/buglist.cgi?chfieldto=Now=resolution_format=advanced=Fixed
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On October 3, 2019 7:23:00 PM PystCat via use-livecode 
 wrote:



Hi Heather,

I can only speak for myself, however I think others might be with me on 
this,  I think you guys ROCK!  I understand the complexities involved in 
creating incredibly beautiful software that makes it look very easy to make 
other software.   You make it easy for me to create easy to use apps and 
hide all the complex logic behind the scenes.  For making my life easier, I 
thank you guys.


Please take all the time you guys need to keep pushing out a great system.  
You guys are artists.  Like all great artists, it takes time to create a 
masterpiece.


Slàinte.
Paul

On Oct 3, 2019, at 12:25 PM, Heather Laine via use-livecode 
 wrote:



Dear List Folks,


I'd like to reassure you, the team is anything but idle, and the fruits of 
their labours are coming your way. I don't wish to steal Pano's thunder, 
but you should look for an announcement on 9.0.5 tomorrow (all being well 
with the build, which is currently undergoing final checks. Probably I've 
just jinxed it by mentioning a release date, in direct contravention of my 
rules.) 9.0.5 has had a fix shoehorned into it for the nasty debugger 
crashing that was reported not long ago.



9.5.1 is well under way and shouldn't be long now, bringing the needed 
updates for iOS among other things. I'm not going to even hint at a release 
date of next week for this, its certain to cause a #fail.



9.6 is in progress with some nice new features and a first dp is not far 
off. Real Soon Now :).



Yes, it has taken a little longer than usual between releases. A major 
reason for this was the server move, which impacted our build bots and 
delayed all test builds. Frustrating, but necessary work, and thankfully 
that is all done now and everything is working smoothly again. One does not 
appreciate the full complexity of these build bots until one attempts to 
move them intact from one place to another.



The suggestion that all our efforts will remain with LCFM Native and never 
bear fruit for LiveCode itself is based on a misconception, an idea that 
somehow we are working on something other than LiveCode. We're not. 
Everything we are building for LCFM Native is built with LiveCode. We 
cannot do it without improving LiveCode. Those improvements will come back 
to the community (many already have). Hermann... its not an infinite 
effort. FileMaker is very much a finite set of code, with relatively slow 
changes.



I hope you will like 9.0.5, 9.5.1 and 9.6, we're looking forward to 
bringing them to you.



Best Regards,


Heather




Heather Laine
Customer Services Manager
LiveCode Ltd
www.livecode.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





___
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: Where LiveCode is Now

[Tom Glod via use-livecode]

Hi Heather, thanks for the update.

Richmond, that was way over the top dude. I respect your right to say your
peace, and not much of it rings wholly true to me.

I pretty much just trust the team, last I talked to Kevin, he seemed sure
of the direction that they are taking..and for nowesp with 9.05 the
team has delivered a powerful and stable language and platform.

Thank you.




On Thu, Oct 3, 2019 at 8:22 PM PystCat via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Hi Heather,
>
> I can only speak for myself, however I think others might be with me on
> this,  I think you guys ROCK!  I understand the complexities involved in
> creating incredibly beautiful software that makes it look very easy to make
> other software.   You make it easy for me to create easy to use apps and
> hide all the complex logic behind the scenes.  For making my life easier, I
> thank you guys.
>
> Please take all the time you guys need to keep pushing out a great
> system.  You guys are artists.  Like all great artists, it takes time to
> create a masterpiece.
>
> Slàinte.
> Paul
>
> > On Oct 3, 2019, at 12:25 PM, Heather Laine via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > Dear List Folks,
> >
> > I'd like to reassure you, the team is anything but idle, and the fruits
> of their labours are coming your way. I don't wish to steal Pano's thunder,
> but you should look for an announcement on 9.0.5 tomorrow (all being well
> with the build, which is currently undergoing final checks. Probably I've
> just jinxed it by mentioning a release date, in direct contravention of my
> rules.) 9.0.5 has had a fix shoehorned into it for the nasty debugger
> crashing that was reported not long ago.
> >
> > 9.5.1 is well under way and shouldn't be long now, bringing the needed
> updates for iOS among other things. I'm not going to even hint at a release
> date of next week for this, its certain to cause a #fail.
> >
> > 9.6 is in progress with some nice new features and a first dp is not far
> off. Real Soon Now :).
> >
> > Yes, it has taken a little longer than usual between releases. A major
> reason for this was the server move, which impacted our build bots and
> delayed all test builds. Frustrating, but necessary work, and thankfully
> that is all done now and everything is working smoothly again. One does not
> appreciate the full complexity of these build bots until one attempts to
> move them intact from one place to another.
> >
> > The suggestion that all our efforts will remain with LCFM Native and
> never bear fruit for LiveCode itself is based on a misconception, an idea
> that somehow we are working on something other than LiveCode. We're not.
> Everything we are building for LCFM Native is built with LiveCode. We
> cannot do it without improving LiveCode. Those improvements will come back
> to the community (many already have). Hermann... its not an infinite
> effort. FileMaker is very much a finite set of code, with relatively slow
> changes.
> >
> > I hope you will like 9.0.5, 9.5.1 and 9.6, we're looking forward to
> bringing them to you.
> >
> > Best Regards,
> >
> > Heather
> >
> >
> > Heather Laine
> > Customer Services Manager
> > LiveCode Ltd
> > www.livecode.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
>


-- 
Tom Glod
Founder & Developer
MakeShyft R.D.A (www.makeshyft.com)
Office:226-706-9339
Mobile:226-706-9793
___
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: Where LiveCode is Now

[PystCat via use-livecode]

Hi Heather,

I can only speak for myself, however I think others might be with me on this,  
I think you guys ROCK!  I understand the complexities involved in creating 
incredibly beautiful software that makes it look very easy to make other 
software.   You make it easy for me to create easy to use apps and hide all the 
complex logic behind the scenes.  For making my life easier, I thank you guys.  
 

Please take all the time you guys need to keep pushing out a great system.  You 
guys are artists.  Like all great artists, it takes time to create a 
masterpiece. 

Slàinte.
Paul

> On Oct 3, 2019, at 12:25 PM, Heather Laine via use-livecode 
>  wrote:
> 
> Dear List Folks,
> 
> I'd like to reassure you, the team is anything but idle, and the fruits of 
> their labours are coming your way. I don't wish to steal Pano's thunder, but 
> you should look for an announcement on 9.0.5 tomorrow (all being well with 
> the build, which is currently undergoing final checks. Probably I've just 
> jinxed it by mentioning a release date, in direct contravention of my rules.) 
> 9.0.5 has had a fix shoehorned into it for the nasty debugger crashing that 
> was reported not long ago.
> 
> 9.5.1 is well under way and shouldn't be long now, bringing the needed 
> updates for iOS among other things. I'm not going to even hint at a release 
> date of next week for this, its certain to cause a #fail.
> 
> 9.6 is in progress with some nice new features and a first dp is not far off. 
> Real Soon Now :).
> 
> Yes, it has taken a little longer than usual between releases. A major reason 
> for this was the server move, which impacted our build bots and delayed all 
> test builds. Frustrating, but necessary work, and thankfully that is all done 
> now and everything is working smoothly again. One does not appreciate the 
> full complexity of these build bots until one attempts to move them intact 
> from one place to another.
> 
> The suggestion that all our efforts will remain with LCFM Native and never 
> bear fruit for LiveCode itself is based on a misconception, an idea that 
> somehow we are working on something other than LiveCode. We're not. 
> Everything we are building for LCFM Native is built with LiveCode. We cannot 
> do it without improving LiveCode. Those improvements will come back to the 
> community (many already have). Hermann... its not an infinite effort. 
> FileMaker is very much a finite set of code, with relatively slow changes. 
> 
> I hope you will like 9.0.5, 9.5.1 and 9.6, we're looking forward to bringing 
> them to you. 
> 
> Best Regards,
> 
> Heather
> 
> 
> Heather Laine
> Customer Services Manager
> LiveCode Ltd
> www.livecode.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: Where LiveCode is Now

[Jeff Reynolds via use-livecode]

LC team,

I too so appreciate all the work the LC team has done over the years and 
continues to do. I’ve used probably a dozen different commercial coding systems 
over the decades and LC thru all it’s incarnations back to good old MetaCard 
with Scott was the one that provided the needed options, stability and power to 
get my multimedia exhibit and education projects done. It’s allowed me to be 
both designer and developer on projects that has created synergy that has made 
all the projects come out better. I know the limits of the system and when it’s 
worth trying to bleed some as it gets you something great and when it’s just 
not worth it and usually another design approach ends up working better. When 
I’ve had to work on projects that I couldn’t develop (complexity, timeline, 
feature needs) and be done in something like C it took way more resources and 
time and although I had really great programmers and I understood all the 
basics of what they were doing things could still get lost in translation and 
some things just turn into a quagmire.

There will always be bugs, feature not there yet, etc in any development system 
and we each have a very different set of needs and wants and the LC team can’t 
make us all perfectly happy at once, nor consistently. They are the ones on the 
front lines trying to make this a profitable business for them (they need to 
feed their families and they are not our serfs) and make decisions on what the 
priorities need to be. We can of course lobby for what we think our priorities 
are (and therefore LC’s), but that doesn’t make it so. 

Many of us have based a lot of our livelihood on LC which is always a risk, but 
many times completely necessary. Yes I could do my projects more safely in C 
but I would be very poor as the time needed would suck out any profit at all. 
It’s always a tradeoff and one that needs constant assessment and not trying to 
push a development system to the limits as then you are in very dangerous 
territory — payoffs can be huge but crashes huge as well. I know I have done it 
in the past and very luckily survived but probably trimmed a few months off my 
lifespan to pay for it. I’ve run into bugs in the past with LC and have always 
found a work around for them on the current project and later most have been 
taken care of in LC, I realize it takes time and priorities are not always mine.

Yes features are always promised but reality always creeps in and resets things 
all the time. But LC has gone on longer and further and covering more platforms 
than most any system out there. With every new platform or major feature it 
adds to the permutations of issues and bugs so things can go at an exponential 
curve of development anymore and decisions need to be made to best keep all the 
balls in the air for the whole system.

Richmond, you need to listen to your mother some and if you don’t have 
something constructive to say try and be quiet some, or just pontificate in 
cheese instead of being insulting. I’m sorry but your flaming of LC staff (and 
the community) constantly is just plain annoying. It does no one any good, it’s 
not the way to make good change. Come to the table with constructive, 
reasonable and positive comments and not nasty ones. Sorry, you don’t represent 
this “community”, at least none I am part of. You complain the LC treats us 
with distain, well I don’t feel like LC does and your comments just fill me 
with distain for your comments. If you talk like that to others then expect to 
be treated with distain. 

You probably think I’m an LC cult member, but you are wrong, I’m the last guy 
in the room cults would go for. I think too much for myself and try to treat 
others reasonably and keep expectations in line with reality, there are no 
magic bullets, most all things are based on some thought and work, not a guru 
spewing truth which you seem to think you do and we should follow suit. Sorry 
not joining your cult. 

LC all the way back to MetaCard has been a big part of making me a richer 
livelihood in both money and profession, won me awards, and positively educated 
many hundreds of thousands with my projects for like 35 years now. That is why 
I trust the LC team to have the best shot at keeping the boat afloat, not a 
mantra. For that I keep thanking the LC team all the way back to Scott and Bill 
Atkinson. Others like Hypercard, toolbook, supercard, Oracle media objects, 
Authorware, Etc have helped for periods and some specific projects due to 
particular needs (produce something Apple publishes it better be in HyperCard 
and make something for Mr Packard and it better run on an hp) but none have 
lasted and matured like LC has.

Jeff

> On Oct 3, 2019, at 2:15 PM, use-livecode-requ...@lists.runrev.com wrote:
> Dear List Folks,
> 
> I'd like to reassure you, the team is anything but idle, and the fruits of 
> their labours are coming your way. I don't wish to steal Pano's thunder, but 
> you should look for 

Re: Where LiveCode is Now

[Mark Smith via use-livecode]

Yes, most certainly agreed

> On Oct 3, 2019, at 5:31 PM, Bob Sneidar via use-livecode 
>  wrote:
> 
> For my part I love what you guys do. As I've mentioned before, Livecode has 
> upped my value to my employer, as they see that I am capable of more than 
> what they hider me to do. It may even have been responsible for a couple 
> raises in the recent past. 
> 
> Also as I have mentioned before, I have never seen a company so responsive to 
> it's users, and also so transparent. We have people *actually* involved in 
> the development process come on list and tell us what they are doing and 
> planning. Seriously, you guys do not get enough credit for how hard you work. 
> 
> Bob S
> 
> 
>> On Oct 3, 2019, at 09:25 , Heather Laine via use-livecode 
>>  wrote:
>> 
>> Dear List Folks,
>> 
>> I'd like to reassure you, the team is anything but idle, and the fruits of 
>> their labours are coming your way. I don't wish to steal Pano's thunder, but 
>> you should look for an announcement on 9.0.5 tomorrow (all being well with 
>> the build, which is currently undergoing final checks. Probably I've just 
>> jinxed it by mentioning a release date, in direct contravention of my 
>> rules.) 9.0.5 has had a fix shoehorned into it for the nasty debugger 
>> crashing that was reported not long ago.
>> 
>> 9.5.1 is well under way and shouldn't be long now, bringing the needed 
>> updates for iOS among other things. I'm not going to even hint at a release 
>> date of next week for this, its certain to cause a #fail.
>> 
>> 9.6 is in progress with some nice new features and a first dp is not far 
>> off. Real Soon Now :).
>> 
>> Yes, it has taken a little longer than usual between releases. A major 
>> reason for this was the server move, which impacted our build bots and 
>> delayed all test builds. Frustrating, but necessary work, and thankfully 
>> that is all done now and everything is working smoothly again. One does not 
>> appreciate the full complexity of these build bots until one attempts to 
>> move them intact from one place to another.
>> 
>> The suggestion that all our efforts will remain with LCFM Native and never 
>> bear fruit for LiveCode itself is based on a misconception, an idea that 
>> somehow we are working on something other than LiveCode. We're not. 
>> Everything we are building for LCFM Native is built with LiveCode. We cannot 
>> do it without improving LiveCode. Those improvements will come back to the 
>> community (many already have). Hermann... its not an infinite effort. 
>> FileMaker is very much a finite set of code, with relatively slow changes. 
>> 
>> I hope you will like 9.0.5, 9.5.1 and 9.6, we're looking forward to bringing 
>> them to you. 
>> 
>> Best Regards,
>> 
>> Heather
>> 
>> 
>> Heather Laine
>> Customer Services Manager
>> LiveCode Ltd
>> www.livecode.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: Where LiveCode is Now

[Phil Davis via use-livecode]

Amen Bob!
Phil Davis


On 10/3/19 9:31 AM, Bob Sneidar via use-livecode wrote:

For my part I love what you guys do. As I've mentioned before, Livecode has 
upped my value to my employer, as they see that I am capable of more than what 
they hider me to do. It may even have been responsible for a couple raises in 
the recent past.

Also as I have mentioned before, I have never seen a company so responsive to 
it's users, and also so transparent. We have people *actually* involved in the 
development process come on list and tell us what they are doing and planning. 
Seriously, you guys do not get enough credit for how hard you work.

Bob S



On Oct 3, 2019, at 09:25 , Heather Laine via use-livecode 
 wrote:

Dear List Folks,

I'd like to reassure you, the team is anything but idle, and the fruits of 
their labours are coming your way. I don't wish to steal Pano's thunder, but 
you should look for an announcement on 9.0.5 tomorrow (all being well with the 
build, which is currently undergoing final checks. Probably I've just jinxed it 
by mentioning a release date, in direct contravention of my rules.) 9.0.5 has 
had a fix shoehorned into it for the nasty debugger crashing that was reported 
not long ago.

9.5.1 is well under way and shouldn't be long now, bringing the needed updates 
for iOS among other things. I'm not going to even hint at a release date of 
next week for this, its certain to cause a #fail.

9.6 is in progress with some nice new features and a first dp is not far off. 
Real Soon Now :).

Yes, it has taken a little longer than usual between releases. A major reason 
for this was the server move, which impacted our build bots and delayed all 
test builds. Frustrating, but necessary work, and thankfully that is all done 
now and everything is working smoothly again. One does not appreciate the full 
complexity of these build bots until one attempts to move them intact from one 
place to another.

The suggestion that all our efforts will remain with LCFM Native and never bear 
fruit for LiveCode itself is based on a misconception, an idea that somehow we 
are working on something other than LiveCode. We're not. Everything we are 
building for LCFM Native is built with LiveCode. We cannot do it without 
improving LiveCode. Those improvements will come back to the community (many 
already have). Hermann... its not an infinite effort. FileMaker is very much a 
finite set of code, with relatively slow changes.

I hope you will like 9.0.5, 9.5.1 and 9.6, we're looking forward to bringing 
them to you.

Best Regards,

Heather


Heather Laine
Customer Services Manager
LiveCode Ltd
www.livecode.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




--
Phil Davis
503-307-4363


___
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: Where LiveCode is Now

[Bob Sneidar via use-livecode]

For my part I love what you guys do. As I've mentioned before, Livecode has 
upped my value to my employer, as they see that I am capable of more than what 
they hider me to do. It may even have been responsible for a couple raises in 
the recent past. 

Also as I have mentioned before, I have never seen a company so responsive to 
it's users, and also so transparent. We have people *actually* involved in the 
development process come on list and tell us what they are doing and planning. 
Seriously, you guys do not get enough credit for how hard you work. 

Bob S


> On Oct 3, 2019, at 09:25 , Heather Laine via use-livecode 
>  wrote:
> 
> Dear List Folks,
> 
> I'd like to reassure you, the team is anything but idle, and the fruits of 
> their labours are coming your way. I don't wish to steal Pano's thunder, but 
> you should look for an announcement on 9.0.5 tomorrow (all being well with 
> the build, which is currently undergoing final checks. Probably I've just 
> jinxed it by mentioning a release date, in direct contravention of my rules.) 
> 9.0.5 has had a fix shoehorned into it for the nasty debugger crashing that 
> was reported not long ago.
> 
> 9.5.1 is well under way and shouldn't be long now, bringing the needed 
> updates for iOS among other things. I'm not going to even hint at a release 
> date of next week for this, its certain to cause a #fail.
> 
> 9.6 is in progress with some nice new features and a first dp is not far off. 
> Real Soon Now :).
> 
> Yes, it has taken a little longer than usual between releases. A major reason 
> for this was the server move, which impacted our build bots and delayed all 
> test builds. Frustrating, but necessary work, and thankfully that is all done 
> now and everything is working smoothly again. One does not appreciate the 
> full complexity of these build bots until one attempts to move them intact 
> from one place to another.
> 
> The suggestion that all our efforts will remain with LCFM Native and never 
> bear fruit for LiveCode itself is based on a misconception, an idea that 
> somehow we are working on something other than LiveCode. We're not. 
> Everything we are building for LCFM Native is built with LiveCode. We cannot 
> do it without improving LiveCode. Those improvements will come back to the 
> community (many already have). Hermann... its not an infinite effort. 
> FileMaker is very much a finite set of code, with relatively slow changes. 
> 
> I hope you will like 9.0.5, 9.5.1 and 9.6, we're looking forward to bringing 
> them to you. 
> 
> Best Regards,
> 
> Heather
> 
> 
> Heather Laine
> Customer Services Manager
> LiveCode Ltd
> www.livecode.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

Where LiveCode is Now

[Heather Laine via use-livecode]

Dear List Folks,

I'd like to reassure you, the team is anything but idle, and the fruits of 
their labours are coming your way. I don't wish to steal Pano's thunder, but 
you should look for an announcement on 9.0.5 tomorrow (all being well with the 
build, which is currently undergoing final checks. Probably I've just jinxed it 
by mentioning a release date, in direct contravention of my rules.) 9.0.5 has 
had a fix shoehorned into it for the nasty debugger crashing that was reported 
not long ago.

9.5.1 is well under way and shouldn't be long now, bringing the needed updates 
for iOS among other things. I'm not going to even hint at a release date of 
next week for this, its certain to cause a #fail.

9.6 is in progress with some nice new features and a first dp is not far off. 
Real Soon Now :).

Yes, it has taken a little longer than usual between releases. A major reason 
for this was the server move, which impacted our build bots and delayed all 
test builds. Frustrating, but necessary work, and thankfully that is all done 
now and everything is working smoothly again. One does not appreciate the full 
complexity of these build bots until one attempts to move them intact from one 
place to another.

The suggestion that all our efforts will remain with LCFM Native and never bear 
fruit for LiveCode itself is based on a misconception, an idea that somehow we 
are working on something other than LiveCode. We're not. Everything we are 
building for LCFM Native is built with LiveCode. We cannot do it without 
improving LiveCode. Those improvements will come back to the community (many 
already have). Hermann... its not an infinite effort. FileMaker is very much a 
finite set of code, with relatively slow changes. 

I hope you will like 9.0.5, 9.5.1 and 9.6, we're looking forward to bringing 
them to you. 

Best Regards,

Heather


Heather Laine
Customer Services Manager
LiveCode Ltd
www.livecode.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