Re: LC Roadmap

[jbv via use-livecode]

Le 2021-02-14 20:46, William Prothero via use-livecode a écrit :

Jacqueline:
I didn’t know about http://lessons.livecode.com
. Thank you for letting me know of that
resource. It looks very useful and I like the user feedback part.



I find this a bit surprising, because every time I have a doubt about
the syntax of a LC command or function, I go and google "livecode" + the
name of the command/function, and the related LC lesson appears within
the first links of the search results...
And I've been doing that for years...

jbv

___
use-livecode mailing list
use-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: LC Roadmap

[J. Landman Gay via use-livecode]

BTW, I like the idea of putting a reference link to the lessons in the 
"This Week in LiveCode" newsletter. It's an easy thing to do and I think it 
would help.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On February 15, 2021 12:26:30 AM "J. Landman Gay via use-livecode" 
 wrote:



I had to check and the lessons are in fact in both the Help and Resources
menus but they are called Tutorials. Both link to the lessons site. I never
actually looked at those before, I only knew about the lessons from
elsewhere and I always use a bookmark to get there.

Like you, I don't want to go through a long tutorial, I just want to know
the bits that apply to a particular problem I need to solve. The lessons do
that for me. It seems like there should be a different name for the menu
item but I can't think what. "Tutorial" sounds time consuming.

But renaming the menu wouldn't solve the fact that I never actually
explored it. My bad.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On February 14, 2021 7:47:43 PM William Prothero  wrote:


Jacqueline:
I didn’t know about http://lessons.livecode.com
. Thank you for letting me know of that
resource. It looks very useful and I like the user feedback part.

To be clear, it is my intent to stimulate thought toward opportunities, not
to complain.

In a way, my ignorance of the lessons link illustrates my point. Where is
the marketing? Why aren’t these contributions mentioned in the “This Week
In Llivecode” mailing? I am busy with many things other than programming. I
read all of the emails from this list. Yet, I didn’t know about this
compilation. These could be promoted/marketed, not only to potential new
users, but to existing ones.

I think if folks would check out the example site I mentioned, they would
see more what I’m suggesting. http://macmost.com 

Andre Garza’s post about his planning to write a book on some aspect of
Livecode programming got me thinking about this. First, I think writing
books is useful, but the way many busy folks access information on the
internet is in more as smaller more targeted bites. I play jazz keyboard. A
couple of years ago, I subscribed to a site that gave me access to jazz
song sheet music included in video lessons lasting 30-60 minutes each. At
the same time, from a couple other  authors, I got regular (about once a
week) emails with short free improv techniques that took me 5-10 minutes to
read, but with offers (at a cost) that include more in-depth lessons. I
find that I use the short lessons a lot and the longer lessons, that I have
already paid for with my one year subscription, very little if at all.
Perhaps I’m unusual with a very short attention span, but I suspect I'm
more typical. I’m suggesting that there are unused marketing and support
strategies that could be beneficial to the Livecode enterprise. Check out
the macmost site to see what I’m talking about.

Peace to you all and thanks for all the help you have given me in my projects,

Be well,
Bill Prothero




On Feb 14, 2021, at 10:43 AM, J. Landman Gay via use-livecode
 wrote:

There is a whole lot more at http://lessons.livecode.com. While these
aren't videos, the amount of info there is impressive and lessons are added
all the time.

Personally I find written instructions much easier to follow and they don't
require me to spend extra time watching a video and needing to
run/pause/run/search for the section I want to review.

The lessons site should be prominently displayed in the Help menu.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On February 14, 2021 11:27:24 AM ELS Prothero via use-livecode
 wrote:


Curry,
Your comments echo some of my experiences with Livecode. In olden times,
when I realized that I could significantly improve my students’ learning by
enlisting computers, I began with HyperCard, went to Supercard, and when it
failed at cross platform, I went to Macromedia Director.  I’ve programmed
in FORTRAN, Pascal. When Adobe bought and killed Director, I switched my
coding to LiveCode.



William Prothero
waproth...@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: LC Roadmap

[J. Landman Gay via use-livecode]

I had to check and the lessons are in fact in both the Help and Resources 
menus but they are called Tutorials. Both link to the lessons site. I never 
actually looked at those before, I only knew about the lessons from 
elsewhere and I always use a bookmark to get there.


Like you, I don't want to go through a long tutorial, I just want to know 
the bits that apply to a particular problem I need to solve. The lessons do 
that for me. It seems like there should be a different name for the menu 
item but I can't think what. "Tutorial" sounds time consuming.


But renaming the menu wouldn't solve the fact that I never actually 
explored it. My bad.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On February 14, 2021 7:47:43 PM William Prothero  wrote:


Jacqueline:
I didn’t know about http://lessons.livecode.com 
. Thank you for letting me know of that 
resource. It looks very useful and I like the user feedback part.


To be clear, it is my intent to stimulate thought toward opportunities, not 
to complain.


In a way, my ignorance of the lessons link illustrates my point. Where is 
the marketing? Why aren’t these contributions mentioned in the “This Week 
In Llivecode” mailing? I am busy with many things other than programming. I 
read all of the emails from this list. Yet, I didn’t know about this 
compilation. These could be promoted/marketed, not only to potential new 
users, but to existing ones.


I think if folks would check out the example site I mentioned, they would 
see more what I’m suggesting. http://macmost.com 


Andre Garza’s post about his planning to write a book on some aspect of 
Livecode programming got me thinking about this. First, I think writing 
books is useful, but the way many busy folks access information on the 
internet is in more as smaller more targeted bites. I play jazz keyboard. A 
couple of years ago, I subscribed to a site that gave me access to jazz 
song sheet music included in video lessons lasting 30-60 minutes each. At 
the same time, from a couple other  authors, I got regular (about once a 
week) emails with short free improv techniques that took me 5-10 minutes to 
read, but with offers (at a cost) that include more in-depth lessons. I 
find that I use the short lessons a lot and the longer lessons, that I have 
already paid for with my one year subscription, very little if at all. 
Perhaps I’m unusual with a very short attention span, but I suspect I'm 
more typical. I’m suggesting that there are unused marketing and support 
strategies that could be beneficial to the Livecode enterprise. Check out 
the macmost site to see what I’m talking about.


Peace to you all and thanks for all the help you have given me in my projects,

Be well,
Bill Prothero



On Feb 14, 2021, at 10:43 AM, J. Landman Gay via use-livecode 
 wrote:


There is a whole lot more at http://lessons.livecode.com. While these 
aren't videos, the amount of info there is impressive and lessons are added 
all the time.


Personally I find written instructions much easier to follow and they don't 
require me to spend extra time watching a video and needing to 
run/pause/run/search for the section I want to review.


The lessons site should be prominently displayed in the Help menu.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On February 14, 2021 11:27:24 AM ELS Prothero via use-livecode 
 wrote:



Curry,
Your comments echo some of my experiences with Livecode. In olden times, 
when I realized that I could significantly improve my students’ learning by 
enlisting computers, I began with HyperCard, went to Supercard, and when it 
failed at cross platform, I went to Macromedia Director.  I’ve programmed 
in FORTRAN, Pascal. When Adobe bought and killed Director, I switched my 
coding to LiveCode.




William Prothero
waproth...@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: LC Roadmap

[William Prothero via use-livecode]

Jacqueline:
I didn’t know about http://lessons.livecode.com . 
Thank you for letting me know of that resource. It looks very useful and I like 
the user feedback part.

To be clear, it is my intent to stimulate thought toward opportunities, not to 
complain.

In a way, my ignorance of the lessons link illustrates my point. Where is the 
marketing? Why aren’t these contributions mentioned in the “This Week In 
Llivecode” mailing? I am busy with many things other than programming. I read 
all of the emails from this list. Yet, I didn’t know about this compilation. 
These could be promoted/marketed, not only to potential new users, but to 
existing ones. 

I think if folks would check out the example site I mentioned, they would see 
more what I’m suggesting. http://macmost.com 

Andre Garza’s post about his planning to write a book on some aspect of 
Livecode programming got me thinking about this. First, I think writing books 
is useful, but the way many busy folks access information on the internet is in 
more as smaller more targeted bites. I play jazz keyboard. A couple of years 
ago, I subscribed to a site that gave me access to jazz song sheet music 
included in video lessons lasting 30-60 minutes each. At the same time, from a 
couple other  authors, I got regular (about once a week) emails with short free 
improv techniques that took me 5-10 minutes to read, but with offers (at a 
cost) that include more in-depth lessons. I find that I use the short lessons a 
lot and the longer lessons, that I have already paid for with my one year 
subscription, very little if at all. Perhaps I’m unusual with a very short 
attention span, but I suspect I'm more typical. I’m suggesting that there are 
unused marketing and support strategies that could be beneficial to the 
Livecode enterprise. Check out the macmost site to see what I’m talking about.

Peace to you all and thanks for all the help you have given me in my projects,

Be well,
Bill Prothero



> On Feb 14, 2021, at 10:43 AM, J. Landman Gay via use-livecode 
>  wrote:
> 
> There is a whole lot more at http://lessons.livecode.com. While these aren't 
> videos, the amount of info there is impressive and lessons are added all the 
> time.
> 
> Personally I find written instructions much easier to follow and they don't 
> require me to spend extra time watching a video and needing to 
> run/pause/run/search for the section I want to review.
> 
> The lessons site should be prominently displayed in the Help menu.
> 
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software | http://www.hyperactivesw.com
> On February 14, 2021 11:27:24 AM ELS Prothero via use-livecode 
>  wrote:
> 
>> Curry,
>> Your comments echo some of my experiences with Livecode. In olden times, 
>> when I realized that I could significantly improve my students’ learning by 
>> enlisting computers, I began with HyperCard, went to Supercard, and when it 
>> failed at cross platform, I went to Macromedia Director.  I’ve programmed in 
>> FORTRAN, Pascal. When Adobe bought and killed Director, I switched my coding 
>> to LiveCode.
>> 

William Prothero
waproth...@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: Polygon fill algo?

[Richard Gaskin via use-livecode]

Thanks, Monte. I checked it out, but unfortunately none of the options 
handle my specific use case in the way I want (which is arguably an 
unrealistic expectation, given that I need to have the fill region paint 
over some vertices).



I also discovered what may be a bug, or at least a curiosity: after 
playing with the nonzero and evenodd options, I tried to restore the 
default with:


  set the fillrule of the selobj to none

And got:

   Message execution error:
   Error description: Property: invalid enumeration value
   Hint:

Apparently "none" must be quoted.  Has it always been that way?  I've 
seen a couple other cases in recent years where keywords I could have 
sworn I'd used unquoted now throw errors until I quote them.


What rule can help us know when keywords must be quoted?


It also occurs to me: if there's no hint, adding "Hint:" looks like a 
bug, even though it may not be (doesn't seem to be in this case). Maybe 
I'll see if I can get some time to patch that...


--
Richard Gaskin
Fourth World Systems


Monte Goulding wrote:
>
> Hi Richard
>
> Have you checked out the `fillRule` property docs?
>
> Cheers
>
> Monte
>
>> On 15 Feb 2021, at 9:25 am, Richard Gaskin via use-livecode 
 wrote:

>>
>> I was hoping to use a single polygon draw a box, using the old trick 
of making discontiguous regions by adding a blank line between lists of 
points.

>>
>> The results draws the lines as I expected, but the fill is 
unpredictable, at least for me.  Apparently the fill rules for a polygon 
cause it to not fill some regions, even when discontiguous.

>>
>> I guess I'll have to use separate objects, but I was wondering if 
anyone has a description of the polyfill rule(s), or better, a way to 
coerce discontiguous polygon regions to always be filled.

>>
>> --
>> Richard Gaskin
>> Fourth World Systems


___
use-livecode mailing list
use-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: LC Roadmap

[Roger Guay via use-livecode]

I just noticed that the "Codesigning and Notarizing your LC Standalone etc” 
lesson was updated on Feb 9, 2021. Perhaps I misrepresented the real situation 
in my previous post.

Roger


> On Feb 14, 2021, at 2:35 PM, Roger Guay via use-livecode 
>  wrote:
> 
> Well, permit me to chime in here with full knowledge that I may be out of 
> date with what’s already available. 
> 
> Arguably the most important feature of LC is its muliplatformness. 
> Recognizing that it is a moving target, We/I need and want up to date easy to 
> use lessons on how to build standalones for all the platforms. Since it is 
> moving target these lessons should have revision cycles with clear up front 
> indication of what OS and LC versions are being  used in each lesson. One of 
> the problems I encounter is the bewildering platform jargon in existing 
> lessons. I wish more simple language could be used to perhaps explain the 
> jargon.
> 
> I am an Apple user (not a bigot) and it annoys the hell of me that I can no 
> longer build distributable standalones for the Mac. It’s not reasonable to 
> expect to change Apple, so we need to make it easier for us LC users. I 
> briefly looked at the current lesson for this some time ago and at first 
> glance it seemed unnecessarily complicated. I admit I might be me at fault 
> here but here we are…
> 
> Just trying to help,
> 
> Roger
> 
>> On Feb 14, 2021, at 1:52 PM, Richard Gaskin via use-livecode 
>>  wrote:
>> 
>> What do you want to learn?
>> 
>> Let's identify topic areas, and then it will become much simpler to sort out 
>> how they get addressed.
>> 
> 
> ___
> use-livecode mailing list
> use-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: LC Roadmap

[Roger Guay via use-livecode]

Well, permit me to chime in here with full knowledge that I may be out of date 
with what’s already available. 

Arguably the most important feature of LC is its muliplatformness. Recognizing 
that it is a moving target, We/I need and want up to date easy to use lessons 
on how to build standalones for all the platforms. Since it is moving target 
these lessons should have revision cycles with clear up front indication of 
what OS and LC versions are being  used in each lesson. One of the problems I 
encounter is the bewildering platform jargon in existing lessons. I wish more 
simple language could be used to perhaps explain the jargon.

I am an Apple user (not a bigot) and it annoys the hell of me that I can no 
longer build distributable standalones for the Mac. It’s not reasonable to 
expect to change Apple, so we need to make it easier for us LC users. I briefly 
looked at the current lesson for this some time ago and at first glance it 
seemed unnecessarily complicated. I admit I might be me at fault here but here 
we are…

Just trying to help,

Roger

> On Feb 14, 2021, at 1:52 PM, Richard Gaskin via use-livecode 
>  wrote:
> 
> What do you want to learn?
> 
> Let's identify topic areas, and then it will become much simpler to sort out 
> how they get addressed.
> 

___
use-livecode mailing list
use-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: Polygon fill algo?

[Monte Goulding via use-livecode]

Hi Richard

Have you checked out the `fillRule` property docs?

Cheers

Monte

> On 15 Feb 2021, at 9:25 am, Richard Gaskin via use-livecode 
>  wrote:
> 
> I was hoping to use a single polygon draw a box, using the old trick of 
> making discontiguous regions by adding a blank line between lists of points.
> 
> The results draws the lines as I expected, but the fill is unpredictable, at 
> least for me.  Apparently the fill rules for a polygon cause it to not fill 
> some regions, even when discontiguous.
> 
> I guess I'll have to use separate objects, but I was wondering if anyone has 
> a description of the polyfill rule(s), or better, a way to coerce 
> discontiguous polygon regions to always be filled.
> 
> -- 
> Richard Gaskin
> Fourth World Systems
> 
> ___
> use-livecode mailing list
> use-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

Polygon fill algo?

[Richard Gaskin via use-livecode]

I was hoping to use a single polygon draw a box, using the old trick of 
making discontiguous regions by adding a blank line between lists of points.


The results draws the lines as I expected, but the fill is 
unpredictable, at least for me.  Apparently the fill rules for a polygon 
cause it to not fill some regions, even when discontiguous.


I guess I'll have to use separate objects, but I was wondering if anyone 
has a description of the polyfill rule(s), or better, a way to coerce 
discontiguous polygon regions to always be filled.


--
Richard Gaskin
Fourth World Systems

___
use-livecode mailing list
use-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: LC Roadmap

[Richard Gaskin via use-livecode]

Bill Prothero wrote:

> I would like to see:
> Better help files that go deeper.

If I gave you a thousand pages of deep material but they were unrelated 
to your work, would you read them?


If I gave you ten pages that completely nailed the subject you've been 
grappling with, would you kick in a couple bucks to have them written?


Andre has been writing books on LC, and I talked with him a couple weeks 
ago about possible collaborative efforts, and there are other content 
options beyond LC's Lessons and eBooks...


But the most important question is:

What do you want to learn?

Let's identify topic areas, and then it will become much simpler to sort 
out how they get addressed.


--
Richard Gaskin
Fourth World Systems

___
use-livecode mailing list
use-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: LC Roadmap

[Tore Nilsen via use-livecode]

I am currently working as a teacher in an upper secondary school in Norway. I 
teach Computer Science and languages like English and Norwegian. Besides 
working as a teacher for more than 20 years, I have also experience from 
running various businesses. The combination of the two very different, but also 
in some parts, very common experiences, forms the basis of my thoughts on this 
topic.

From being in charge of running a business with about 20 employees and more 
than 100 recurring customers, I have learnt the importance of due diligence in 
all aspects of running the business. Whenever I was about to make a promise to 
a customer, I alone was responsible for making sure I could keep this promise. 
If the job at hand required new tools, I would never commit to the task before 
I actually had said tool at my disposal. Sure enough, I could find vendors who 
would promise to deliver on time, but to me such promises are nothing more than 
a good intention.

I look at the LC Roadmap in very much the same way. As a teacher I think I 
understand why the LC Roadmap is not a reliable tool to use for planning future 
solutions. As a teacher I am supposed to make plans in advance. I should make a 
plan for the whole of the school year, and a plan for each semester, the latter 
more detailed than the first. They are very much like the roadmap or the 
promises from vendors.

In reality these plans are not worth the bytes they occupy on the server. To be 
honest, even the plans I just made for next week and for each lesson next week, 
will fail one way or another. Such is the nature of plans vs. reality. And it 
is not about me or anyone else not caring about fulfilling the promises of the 
plans. It is simply because I am not able to control every variable that will 
affect the work we do.

As developers it should not be difficult for us to understand that a roadmap is 
just an expression of what LC Ltd  hopes to achieve within a given timeframe. 
It should not be considered to be a solid basis for making future promises to 
our customers. If we choose to do so, it would be just as stupid as if I chose 
to press on with my plans for this week, without any consideration to what 
happened in the classroom last week. And the responsibility would be with us, 
not the plans or the roadmaps.

On the question on whether or not the LC Roadmap should be updated, the answer 
is of course, yes. All plans that are outdated should be updated. But the new 
plans should be treated with the same amount of caution as the previous ones. 
Especially so if our livelihood depends on how we treat these roadmaps.

Best regards
Tore Nilsen

> 13. feb. 2021 kl. 13:37 skrev Sean Cole (Pi) via use-livecode 
> :
> 
> I was told last year that HTML5 deployment would see upgrades maybe by
> Jan2021 LC 9.7. However LC9.6.2 is still awaiting an RC3. So it’s just not
> going to happen. My client and I are severely disappointed to see that the
> conference set up for 2022 may be the FIRST LOOK we might see for the HTML5
> upgrade. Actually, disappointed doesn’t even close to cut it. I am
> seriously LIVID! Absolute proof that subscription model for this is
> pointless. It pisses me right off that promise after promise I keep falling
> for this crap. I’m paying something like $400 on top of the original $400
> per year for this kind of service. I CANNOT afford to keep doing this with
> vague empty unfulfilled promises (lies). I KEEP falling for it because the
> likes of others on this forum keep trying to convince me that they have our
> best interests at heart. But keep forgetting that this is BS too.
> 
> Roadmap = careering off a cliff top.  Clean up projected for New York 2022.
> 
> 
> 
> On Fri, 12 Feb 2021 at 12:16, Richmond via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> 
>> I've said something to that effect earlier, at which point I was jumped
>> all over.
>> 
>> So, because I don't want to be jumped all over again, and because
>> saying the 'roadmap' needs to be updated will have no effect (didn't the
>> last 3 times),
>> I'm NOT stating what I think.
>> 
>> Love. kisses, and other things,
>> 
>> Richmond.
>> 
>> On 12.02.21 14:12, Klaus major-k via use-livecode wrote:
>>> Hi folks,
>>> 
>>> see subject -> Last Updated on July 14, 2020
>>> I think it is time to update the roadmap, what do you think?
>>> 
>>> 
>>> Best
>>> 
>>> Klaus
>>> --
>>> Klaus Major
>>> https://www.major-k.de
>>> https://www.major-k.de/bass
>>> kl...@major-k.de
>>> 
>>> 
>>> ___
>>> use-livecode mailing list
>>> use-livecode@lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> 
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> 

Re: LC Roadmap

[matthias rebbe via use-livecode]

Every Livecoder who is interested in creating lessons or fixing outdated ones  
can ask Livecode Support to get access to the Lessons section. 
Livecode will then create an account and will provide the tools for creating 
the lessons.
At least this was the fact when i asked if i could help.

Regards,

Matthias


> Am 14.02.2021 um 19:57 schrieb prothero--- via use-livecode 
> :
> 
> Folks, a bit more:
> Both documentation and marketing are huge tasks and keeping even basic 
> documentation current is a big job. A few years ago, I tried the lessons that 
> were produced by the livecode team to help folks create basic Apple apps. In 
> my view, they were a failure. First, they seemed either buggy or lacked 
> attention to non-specialist assumptions in the presentation, confusing me. 
> They needed to be reviewed and vetted by beginning programmers. Secondly, 
> they quickly became obsolete. Lots of effort for a mediocre showing.
> 
> This is a task where livecoders could contribute with carefully vetted 
> modules, like those in macmost.com . There would need to 
> be a presentation framework that contributors fit into. Contributions would 
> need to be reviewed (and authored), perhaps by livecoders who have already 
> purchased livecode subscriptions. Coding practices would have to be reviewed 
> and be clean. Purchase fees would be collected by the mothership and 
> distributed to authors. This would benefit the mothership by bringing in new 
> users who would subscribe to the software. There should be user feedback and 
> requests for specific lessons, which a member of the contribution team (all 
> subscribers?) could take on. Lessons would get reviewed by purchasers and 
> authors would also get ratings.
> 
> This project would be best if tightly coupled to the dev team and its 
> control. The justification for giving fees to authors is that it would be 
> enormously to the benefit of the mothership to have this resource, both by 
> supporting existing users and gaining new ones.
> 
> Happy Valentine’s day,
> Every day is “Valentine’s Day” (if your name is Valentine),
> 
> Best,
> Bill Prothero
> 
> 
>> On Feb 14, 2021, at 9:25 AM, ELS Prothero via use-livecode 
>>  wrote:
>> 
>> Curry,
>> Your comments echo some of my experiences with Livecode. In olden times, 
>> when I realized that I could significantly improve my students’ learning by 
>> enlisting computers, I began with HyperCard, went to Supercard, and when it 
>> failed at cross platform, I went to Macromedia Director.  I’ve programmed in 
>> FORTRAN, Pascal. When Adobe bought and killed Director, I switched my coding 
>> to LiveCode.
>> 
>> I still miss Director. It’s animation capabilities and web deployment with a 
>> plug-in were excellent. Of course, plug-ins are obsolete and mobile support 
>> has become mandatory. The big selling point that is front and center is: 
>> English like language. I find that a very weak claim, unless all I want to 
>> do is write “Hello World” when I click a button. To do anything non-trivial, 
>> you need to delve into coder world. Yes, it is enormously helpful at 
>> building user interfaces. Deployment is an enormous pain, with ever changing 
>> security challenges. The help files are great at the most trivial tasks, but 
>> to do beyond can be challenging. That said, I am committed to Livecode and 
>> congratulate the dev team for their accomplishments.
>> 
>> I would like to see:
>> Better help files that go deeper. Have you seen MacMost.com? This is a guy 
>> who produces quicky videos for free, and offers more detailed courses for a 
>> modest subscription fee. I don’t know whether there are enough potential 
>> clients for this, but what if a small team of live coders created something 
>> like this that would create modest size youtube videos that both bring in 
>> new users and take them to the next level with video, sample projects, and 
>> text materials? Perhaps the mothership could support and advise while user 
>> Fees pass to the authors. Just thinking.
>> 
>> That’s all for now. Valentine’s Day and breakfast beckon.
>> 
>> Best,
>> Bill Prothero
>> 
>> 
>> 
>> 
>> 
>> William Prothero
>> https://earthlearningsolutions.org
>> 
>>> On Feb 14, 2021, at 7:30 AM, e.beugelaar--- via use-livecode 
>>>  wrote:
>>> 
>>> https://www.b4x.com if u dont want headaches.
>>> 
>>> Get Outlook for Android
>>> 
>>> 
>>> From: use-livecode  on behalf of 
>>> Curry Kenworthy via use-livecode 
>>> Sent: Sunday, February 14, 2021 11:31:47 AM
>>> To: use-livecode@lists.runrev.com 
>>> Cc: Curry Kenworthy 
>>> Subject: Re: LC Roadmap
>>> 
>>> 
>>> JeeJeeStudio:
>>> 
 I like Livecode a lot, but it has it's limitations,
 lot of bugs are not solved.
>>> 
>>> True. Would be more accurate with "yet" added; solving bugs is ongoing!
>>> We could also say that many bugs HAVE been solved. Moderate progress.
>>> (I know, having been on the fro

Re: LC Roadmap

[prothero--- via use-livecode]

Folks, a bit more:
Both documentation and marketing are huge tasks and keeping even basic 
documentation current is a big job. A few years ago, I tried the lessons that 
were produced by the livecode team to help folks create basic Apple apps. In my 
view, they were a failure. First, they seemed either buggy or lacked attention 
to non-specialist assumptions in the presentation, confusing me. They needed to 
be reviewed and vetted by beginning programmers. Secondly, they quickly became 
obsolete. Lots of effort for a mediocre showing.

This is a task where livecoders could contribute with carefully vetted modules, 
like those in macmost.com . There would need to be a 
presentation framework that contributors fit into. Contributions would need to 
be reviewed (and authored), perhaps by livecoders who have already purchased 
livecode subscriptions. Coding practices would have to be reviewed and be 
clean. Purchase fees would be collected by the mothership and distributed to 
authors. This would benefit the mothership by bringing in new users who would 
subscribe to the software. There should be user feedback and requests for 
specific lessons, which a member of the contribution team (all subscribers?) 
could take on. Lessons would get reviewed by purchasers and authors would also 
get ratings.

This project would be best if tightly coupled to the dev team and its control. 
The justification for giving fees to authors is that it would be enormously to 
the benefit of the mothership to have this resource, both by supporting 
existing users and gaining new ones.

Happy Valentine’s day,
Every day is “Valentine’s Day” (if your name is Valentine),

Best,
Bill Prothero


> On Feb 14, 2021, at 9:25 AM, ELS Prothero via use-livecode 
>  wrote:
> 
> Curry,
> Your comments echo some of my experiences with Livecode. In olden times, when 
> I realized that I could significantly improve my students’ learning by 
> enlisting computers, I began with HyperCard, went to Supercard, and when it 
> failed at cross platform, I went to Macromedia Director.  I’ve programmed in 
> FORTRAN, Pascal. When Adobe bought and killed Director, I switched my coding 
> to LiveCode.
> 
> I still miss Director. It’s animation capabilities and web deployment with a 
> plug-in were excellent. Of course, plug-ins are obsolete and mobile support 
> has become mandatory. The big selling point that is front and center is: 
> English like language. I find that a very weak claim, unless all I want to do 
> is write “Hello World” when I click a button. To do anything non-trivial, you 
> need to delve into coder world. Yes, it is enormously helpful at building 
> user interfaces. Deployment is an enormous pain, with ever changing security 
> challenges. The help files are great at the most trivial tasks, but to do 
> beyond can be challenging. That said, I am committed to Livecode and 
> congratulate the dev team for their accomplishments.
> 
> I would like to see:
> Better help files that go deeper. Have you seen MacMost.com? This is a guy 
> who produces quicky videos for free, and offers more detailed courses for a 
> modest subscription fee. I don’t know whether there are enough potential 
> clients for this, but what if a small team of live coders created something 
> like this that would create modest size youtube videos that both bring in new 
> users and take them to the next level with video, sample projects, and text 
> materials? Perhaps the mothership could support and advise while user Fees 
> pass to the authors. Just thinking.
> 
> That’s all for now. Valentine’s Day and breakfast beckon.
> 
> Best,
> Bill Prothero
> 
> 
> 
> 
> 
> William Prothero
> https://earthlearningsolutions.org
> 
>> On Feb 14, 2021, at 7:30 AM, e.beugelaar--- via use-livecode 
>>  wrote:
>> 
>> https://www.b4x.com if u dont want headaches.
>> 
>> Get Outlook for Android
>> 
>> 
>> From: use-livecode  on behalf of 
>> Curry Kenworthy via use-livecode 
>> Sent: Sunday, February 14, 2021 11:31:47 AM
>> To: use-livecode@lists.runrev.com 
>> Cc: Curry Kenworthy 
>> Subject: Re: LC Roadmap
>> 
>> 
>> JeeJeeStudio:
>> 
>>> I like Livecode a lot, but it has it's limitations,
>>> lot of bugs are not solved.
>> 
>> True. Would be more accurate with "yet" added; solving bugs is ongoing!
>> We could also say that many bugs HAVE been solved. Moderate progress.
>> (I know, having been on the front lines of the bug-reporting battle.)
>> 
>> I attribute bug density to dev strategy during the "Great Refactoring."
>> Good: Kickstarter project threw money/man-hours at LC to achieve a lot.
>> Bad: Code quality was mediocre; lots of bugs introduced at that time.
>> (We are STILL finding and reporting LC 7 and 8 bugs.)
>> 
>> Problem: Digging out from under myriad bugs takes big money/man-hours.
>> Meanwhile: Platforms, especially Apple and Mobile, are moving targets.
>> 
>> Traditional solution: Use a new camp

Re: LC Roadmap

[J. Landman Gay via use-livecode]

There is a whole lot more at http://lessons.livecode.com. While these 
aren't videos, the amount of info there is impressive and lessons are added 
all the time.


Personally I find written instructions much easier to follow and they don't 
require me to spend extra time watching a video and needing to 
run/pause/run/search for the section I want to review.


The lessons site should be prominently displayed in the Help menu.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On February 14, 2021 11:27:24 AM ELS Prothero via use-livecode 
 wrote:



Curry,
Your comments echo some of my experiences with Livecode. In olden times, 
when I realized that I could significantly improve my students’ learning by 
enlisting computers, I began with HyperCard, went to Supercard, and when it 
failed at cross platform, I went to Macromedia Director.  I’ve programmed 
in FORTRAN, Pascal. When Adobe bought and killed Director, I switched my 
coding to LiveCode.


I still miss Director. It’s animation capabilities and web deployment with 
a plug-in were excellent. Of course, plug-ins are obsolete and mobile 
support has become mandatory. The big selling point that is front and 
center is: English like language. I find that a very weak claim, unless all 
I want to do is write “Hello World” when I click a button. To do anything 
non-trivial, you need to delve into coder world. Yes, it is enormously 
helpful at building user interfaces. Deployment is an enormous pain, with 
ever changing security challenges. The help files are great at the most 
trivial tasks, but to do beyond can be challenging. That said, I am 
committed to Livecode and congratulate the dev team for their accomplishments.


I would like to see:
Better help files that go deeper. Have you seen MacMost.com? This is a guy 
who produces quicky videos for free, and offers more detailed courses for a 
modest subscription fee. I don’t know whether there are enough potential 
clients for this, but what if a small team of live coders created something 
like this that would create modest size youtube videos that both bring in 
new users and take them to the next level with video, sample projects, and 
text materials? Perhaps the mothership could support and advise while user 
Fees pass to the authors. Just thinking.




___
use-livecode mailing list
use-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: LC Roadmap

[ELS Prothero via use-livecode]

 Curry,
Your comments echo some of my experiences with Livecode. In olden times, when I 
realized that I could significantly improve my students’ learning by enlisting 
computers, I began with HyperCard, went to Supercard, and when it failed at 
cross platform, I went to Macromedia Director.  I’ve programmed in FORTRAN, 
Pascal. When Adobe bought and killed Director, I switched my coding to LiveCode.

I still miss Director. It’s animation capabilities and web deployment with a 
plug-in were excellent. Of course, plug-ins are obsolete and mobile support has 
become mandatory. The big selling point that is front and center is: English 
like language. I find that a very weak claim, unless all I want to do is write 
“Hello World” when I click a button. To do anything non-trivial, you need to 
delve into coder world. Yes, it is enormously helpful at building user 
interfaces. Deployment is an enormous pain, with ever changing security 
challenges. The help files are great at the most trivial tasks, but to do 
beyond can be challenging. That said, I am committed to Livecode and 
congratulate the dev team for their accomplishments.

I would like to see:
Better help files that go deeper. Have you seen MacMost.com? This is a guy who 
produces quicky videos for free, and offers more detailed courses for a modest 
subscription fee. I don’t know whether there are enough potential clients for 
this, but what if a small team of live coders created something like this that 
would create modest size youtube videos that both bring in new users and take 
them to the next level with video, sample projects, and text materials? Perhaps 
the mothership could support and advise while user Fees pass to the authors. 
Just thinking.

That’s all for now. Valentine’s Day and breakfast beckon.

Best,
Bill Prothero





William Prothero
https://earthlearningsolutions.org

> On Feb 14, 2021, at 7:30 AM, e.beugelaar--- via use-livecode 
>  wrote:
> 
> https://www.b4x.com if u dont want headaches.
> 
> Get Outlook for Android
> 
> 
> From: use-livecode  on behalf of Curry 
> Kenworthy via use-livecode 
> Sent: Sunday, February 14, 2021 11:31:47 AM
> To: use-livecode@lists.runrev.com 
> Cc: Curry Kenworthy 
> Subject: Re: LC Roadmap
> 
> 
> JeeJeeStudio:
> 
>> I like Livecode a lot, but it has it's limitations,
>> lot of bugs are not solved.
> 
> True. Would be more accurate with "yet" added; solving bugs is ongoing!
> We could also say that many bugs HAVE been solved. Moderate progress.
> (I know, having been on the front lines of the bug-reporting battle.)
> 
> I attribute bug density to dev strategy during the "Great Refactoring."
> Good: Kickstarter project threw money/man-hours at LC to achieve a lot.
> Bad: Code quality was mediocre; lots of bugs introduced at that time.
> (We are STILL finding and reporting LC 7 and 8 bugs.)
> 
> Problem: Digging out from under myriad bugs takes big money/man-hours.
> Meanwhile: Platforms, especially Apple and Mobile, are moving targets.
> 
> Traditional solution: Use a new campaign, like FM, for cashflow.
> Underlying philosophy: Quality = energy/money/time.
> Potential weakness: History could repeat itself. New code quality??
> 
> My proposed solution: Decrease net bugs with more careful coding.
> Underlying philosophy: New code should be good code. (Almost zero-sum.)
> Potential weakness: Too late for the Refactoring; only useful from now.
> 
>> Livecode is great! Don't misunderstand and it learns a lot of
>> people to program. But it runs behind future facts.
> 
> Some truth there too, but it misses a (gigantic) point. In fact, two:
> 
> A. A good IDE is not ONLY about features, bugs, and platforms.
> B. LC's benefit is not ONLY about being easy to learn. (When it is.)
> 
> If that's the only reason you're here, you don't understand LC!
> 
> And you're not the only one. Even those at the top have missed it.
> Raney failed to see it: He considered MC a stepping stone to C.
> LC Ltd also missed part of it: many unique benefits under-promoted.
> And the way some features are added CONTRADICTS the LC paradigm.
> 
> LiveCode - and the legacy of HyperCard - is not Just Another IDE.
> People have usually failed miserably at explaining the magic.
> ("Easy English-like language?" Way too vague! Also missing the point.)
> Too few good analyses, too much parroting weak/transient slogans.
> 
> I intend to do a bit myself in that area soon, explaining what HC/LC is.
> (I had health/energy problems, thus some detractors, but they'll see!)
> The unique strengths of LC paradigm -yes, paradigm- deserve attention.
> That's why I'm making it a point to be more active on this list.
> 
> That paradigm is why many of us are here: not just a handy-dandy tool.
> It's a worldview of how to code - which should be updated not discarded.
> This paradigm has extreme value; likely more than even LC Ltd realizes.
> That's why I'm making it a point to be more active on th

Re: LC Roadmap

[Richmond via use-livecode]

I don't want any headaches, but as I develop on Macintosh and Linux B4X 
is no good.


On 14.02.21 17:29, e.beugelaar--- via use-livecode wrote:

https://www.b4x.com if u dont want headaches.

Get Outlook for Android


From: use-livecode  on behalf of Curry 
Kenworthy via use-livecode 
Sent: Sunday, February 14, 2021 11:31:47 AM
To: use-livecode@lists.runrev.com 
Cc: Curry Kenworthy 
Subject: Re: LC Roadmap


JeeJeeStudio:

  > I like Livecode a lot, but it has it's limitations,
  > lot of bugs are not solved.

True. Would be more accurate with "yet" added; solving bugs is ongoing!
We could also say that many bugs HAVE been solved. Moderate progress.
(I know, having been on the front lines of the bug-reporting battle.)

I attribute bug density to dev strategy during the "Great Refactoring."
Good: Kickstarter project threw money/man-hours at LC to achieve a lot.
Bad: Code quality was mediocre; lots of bugs introduced at that time.
(We are STILL finding and reporting LC 7 and 8 bugs.)

Problem: Digging out from under myriad bugs takes big money/man-hours.
Meanwhile: Platforms, especially Apple and Mobile, are moving targets.

Traditional solution: Use a new campaign, like FM, for cashflow.
Underlying philosophy: Quality = energy/money/time.
Potential weakness: History could repeat itself. New code quality??

My proposed solution: Decrease net bugs with more careful coding.
Underlying philosophy: New code should be good code. (Almost zero-sum.)
Potential weakness: Too late for the Refactoring; only useful from now.

  > Livecode is great! Don't misunderstand and it learns a lot of
  > people to program. But it runs behind future facts.

Some truth there too, but it misses a (gigantic) point. In fact, two:

A. A good IDE is not ONLY about features, bugs, and platforms.
B. LC's benefit is not ONLY about being easy to learn. (When it is.)

If that's the only reason you're here, you don't understand LC!

And you're not the only one. Even those at the top have missed it.
Raney failed to see it: He considered MC a stepping stone to C.
LC Ltd also missed part of it: many unique benefits under-promoted.
And the way some features are added CONTRADICTS the LC paradigm.

LiveCode - and the legacy of HyperCard - is not Just Another IDE.
People have usually failed miserably at explaining the magic.
("Easy English-like language?" Way too vague! Also missing the point.)
Too few good analyses, too much parroting weak/transient slogans.

I intend to do a bit myself in that area soon, explaining what HC/LC is.
(I had health/energy problems, thus some detractors, but they'll see!)
The unique strengths of LC paradigm -yes, paradigm- deserve attention.
That's why I'm making it a point to be more active on this list.

That paradigm is why many of us are here: not just a handy-dandy tool.
It's a worldview of how to code - which should be updated not discarded.
This paradigm has extreme value; likely more than even LC Ltd realizes.
That's why I'm making it a point to be more active on this list!

Growing the audience again requires understanding/promoting that value.
You can't just swap in any XYZ tool/language for LC. It ain't the same!
Nor is success ONLY about winning the feature and platform arms race.
That, but so much more. Paradigm is key. It has been neglected too long.

We must MAKE THE CASE for LC. Some have tried (thanks!) but not enough.
I feel paradigm is equally important to explain to LC Ltd, as to users.

  > HTML5 is a drag in LC, unusable, to play ok, to really use no way..

Not much argument there! Hopefully good things coming.

  > And next to it I'm learning Flutter platform with Dart
  > as main language, it's free, it's the future

Thanks for sharing that. It looks pretty good.
However, really the future? Maybe not!
End of LC? "Hell no!" :D

(At least, if LC Ltd play their hand well.)

Again, there's #1. Paradigm - more on that soon, when I have time.
But also several other factors in play:

2. Current and future tech changes; you ain't seen nothing yet!
3. Mega corp competition; Apple & others will frequently reinvent.
4. Tech giant control; Silicon Valley oversteps, people will push back.
5. Corporations are good at innovation, also good at screwing up.

The control factor might bite Google and Apple soon:
should I build there, when Powers That Be can pull the plug anytime?
Increasingly, the big guys don't follow their own rules; it's arbitrary.

Tip: they just love control, whether visual fashion trends or ideology.
What they encourage one year may become a "sin" the next. (Hi, Apple!)
Very often it's simply dollars and cents; more control means more fees.

Meanwhile, you're at the mercy of their tech whims.
Whatever they think should be the new trend, you must do.
Modern corporate strategy is to reinvent for profit; relentless change.

Factor #5 is also big for me. Remember how Google would "fix" search?
They "fixed" it alright! They killed it; try sea

Re: LC Roadmap

[e.beugelaar--- via use-livecode]

https://www.b4x.com if u dont want headaches.

Get Outlook for Android


From: use-livecode  on behalf of Curry 
Kenworthy via use-livecode 
Sent: Sunday, February 14, 2021 11:31:47 AM
To: use-livecode@lists.runrev.com 
Cc: Curry Kenworthy 
Subject: Re: LC Roadmap


JeeJeeStudio:

 > I like Livecode a lot, but it has it's limitations,
 > lot of bugs are not solved.

True. Would be more accurate with "yet" added; solving bugs is ongoing!
We could also say that many bugs HAVE been solved. Moderate progress.
(I know, having been on the front lines of the bug-reporting battle.)

I attribute bug density to dev strategy during the "Great Refactoring."
Good: Kickstarter project threw money/man-hours at LC to achieve a lot.
Bad: Code quality was mediocre; lots of bugs introduced at that time.
(We are STILL finding and reporting LC 7 and 8 bugs.)

Problem: Digging out from under myriad bugs takes big money/man-hours.
Meanwhile: Platforms, especially Apple and Mobile, are moving targets.

Traditional solution: Use a new campaign, like FM, for cashflow.
Underlying philosophy: Quality = energy/money/time.
Potential weakness: History could repeat itself. New code quality??

My proposed solution: Decrease net bugs with more careful coding.
Underlying philosophy: New code should be good code. (Almost zero-sum.)
Potential weakness: Too late for the Refactoring; only useful from now.

 > Livecode is great! Don't misunderstand and it learns a lot of
 > people to program. But it runs behind future facts.

Some truth there too, but it misses a (gigantic) point. In fact, two:

A. A good IDE is not ONLY about features, bugs, and platforms.
B. LC's benefit is not ONLY about being easy to learn. (When it is.)

If that's the only reason you're here, you don't understand LC!

And you're not the only one. Even those at the top have missed it.
Raney failed to see it: He considered MC a stepping stone to C.
LC Ltd also missed part of it: many unique benefits under-promoted.
And the way some features are added CONTRADICTS the LC paradigm.

LiveCode - and the legacy of HyperCard - is not Just Another IDE.
People have usually failed miserably at explaining the magic.
("Easy English-like language?" Way too vague! Also missing the point.)
Too few good analyses, too much parroting weak/transient slogans.

I intend to do a bit myself in that area soon, explaining what HC/LC is.
(I had health/energy problems, thus some detractors, but they'll see!)
The unique strengths of LC paradigm -yes, paradigm- deserve attention.
That's why I'm making it a point to be more active on this list.

That paradigm is why many of us are here: not just a handy-dandy tool.
It's a worldview of how to code - which should be updated not discarded.
This paradigm has extreme value; likely more than even LC Ltd realizes.
That's why I'm making it a point to be more active on this list!

Growing the audience again requires understanding/promoting that value.
You can't just swap in any XYZ tool/language for LC. It ain't the same!
Nor is success ONLY about winning the feature and platform arms race.
That, but so much more. Paradigm is key. It has been neglected too long.

We must MAKE THE CASE for LC. Some have tried (thanks!) but not enough.
I feel paradigm is equally important to explain to LC Ltd, as to users.

 > HTML5 is a drag in LC, unusable, to play ok, to really use no way..

Not much argument there! Hopefully good things coming.

 > And next to it I'm learning Flutter platform with Dart
 > as main language, it's free, it's the future

Thanks for sharing that. It looks pretty good.
However, really the future? Maybe not!
End of LC? "Hell no!" :D

(At least, if LC Ltd play their hand well.)

Again, there's #1. Paradigm - more on that soon, when I have time.
But also several other factors in play:

2. Current and future tech changes; you ain't seen nothing yet!
3. Mega corp competition; Apple & others will frequently reinvent.
4. Tech giant control; Silicon Valley oversteps, people will push back.
5. Corporations are good at innovation, also good at screwing up.

The control factor might bite Google and Apple soon:
should I build there, when Powers That Be can pull the plug anytime?
Increasingly, the big guys don't follow their own rules; it's arbitrary.

Tip: they just love control, whether visual fashion trends or ideology.
What they encourage one year may become a "sin" the next. (Hi, Apple!)
Very often it's simply dollars and cents; more control means more fees.

Meanwhile, you're at the mercy of their tech whims.
Whatever they think should be the new trend, you must do.
Modern corporate strategy is to reinvent for profit; relentless change.

Factor #5 is also big for me. Remember how Google would "fix" search?
They "fixed" it alright! They killed it; try searching a non-trend.

So do I want to leap into Google's IDE?

Trust them to "fix" software development? To decide what I should do?
To reinvent every 5 m

Re: LC Roadmap

[Curry Kenworthy via use-livecode]

JeeJeeStudio:

> I like Livecode a lot, but it has it's limitations,
> lot of bugs are not solved.

True. Would be more accurate with "yet" added; solving bugs is ongoing!
We could also say that many bugs HAVE been solved. Moderate progress.
(I know, having been on the front lines of the bug-reporting battle.)

I attribute bug density to dev strategy during the "Great Refactoring."
Good: Kickstarter project threw money/man-hours at LC to achieve a lot.
Bad: Code quality was mediocre; lots of bugs introduced at that time.
(We are STILL finding and reporting LC 7 and 8 bugs.)

Problem: Digging out from under myriad bugs takes big money/man-hours.
Meanwhile: Platforms, especially Apple and Mobile, are moving targets.

Traditional solution: Use a new campaign, like FM, for cashflow.
Underlying philosophy: Quality = energy/money/time.
Potential weakness: History could repeat itself. New code quality??

My proposed solution: Decrease net bugs with more careful coding.
Underlying philosophy: New code should be good code. (Almost zero-sum.)
Potential weakness: Too late for the Refactoring; only useful from now.

> Livecode is great! Don't misunderstand and it learns a lot of
> people to program. But it runs behind future facts.

Some truth there too, but it misses a (gigantic) point. In fact, two:

A. A good IDE is not ONLY about features, bugs, and platforms.
B. LC's benefit is not ONLY about being easy to learn. (When it is.)

If that's the only reason you're here, you don't understand LC!

And you're not the only one. Even those at the top have missed it.
Raney failed to see it: He considered MC a stepping stone to C.
LC Ltd also missed part of it: many unique benefits under-promoted.
And the way some features are added CONTRADICTS the LC paradigm.

LiveCode - and the legacy of HyperCard - is not Just Another IDE.
People have usually failed miserably at explaining the magic.
("Easy English-like language?" Way too vague! Also missing the point.)
Too few good analyses, too much parroting weak/transient slogans.

I intend to do a bit myself in that area soon, explaining what HC/LC is.
(I had health/energy problems, thus some detractors, but they'll see!)
The unique strengths of LC paradigm -yes, paradigm- deserve attention.
That's why I'm making it a point to be more active on this list.

That paradigm is why many of us are here: not just a handy-dandy tool.
It's a worldview of how to code - which should be updated not discarded.
This paradigm has extreme value; likely more than even LC Ltd realizes.
That's why I'm making it a point to be more active on this list!

Growing the audience again requires understanding/promoting that value.
You can't just swap in any XYZ tool/language for LC. It ain't the same!
Nor is success ONLY about winning the feature and platform arms race.
That, but so much more. Paradigm is key. It has been neglected too long.

We must MAKE THE CASE for LC. Some have tried (thanks!) but not enough.
I feel paradigm is equally important to explain to LC Ltd, as to users.

> HTML5 is a drag in LC, unusable, to play ok, to really use no way..

Not much argument there! Hopefully good things coming.

> And next to it I'm learning Flutter platform with Dart
> as main language, it's free, it's the future

Thanks for sharing that. It looks pretty good.
However, really the future? Maybe not!
End of LC? "Hell no!" :D

(At least, if LC Ltd play their hand well.)

Again, there's #1. Paradigm - more on that soon, when I have time.
But also several other factors in play:

2. Current and future tech changes; you ain't seen nothing yet!
3. Mega corp competition; Apple & others will frequently reinvent.
4. Tech giant control; Silicon Valley oversteps, people will push back.
5. Corporations are good at innovation, also good at screwing up.

The control factor might bite Google and Apple soon:
should I build there, when Powers That Be can pull the plug anytime?
Increasingly, the big guys don't follow their own rules; it's arbitrary.

Tip: they just love control, whether visual fashion trends or ideology.
What they encourage one year may become a "sin" the next. (Hi, Apple!)
Very often it's simply dollars and cents; more control means more fees.

Meanwhile, you're at the mercy of their tech whims.
Whatever they think should be the new trend, you must do.
Modern corporate strategy is to reinvent for profit; relentless change.

Factor #5 is also big for me. Remember how Google would "fix" search?
They "fixed" it alright! They killed it; try searching a non-trend.

So do I want to leap into Google's IDE?

Trust them to "fix" software development? To decide what I should do?
To reinvent every 5 minutes if the corporate bottom line demands it?
To see the present and the future more clearly than I do myself?
Bow to their proverbial calf and kiss their toes since they're big?

So incredibly tempting...(not really)...no thanks! :)
I gave them a chance to improve the Internet, and they maimed it.
With that much money and