Re: Deployment: a plea/opportunity

[Mark Smith via use-livecode]

Re: The problem was getting my Apple code signing certificates AND related 
certificates on to the MacBook air from the Apple Developer site, something I 
don't think Livecode can really help with.

Paul, just so I understand this problem better. Is there a reason why you can’t 
just download your certificates from the Apple Developer site to your MacBook 
Air? Do they specifically restrict downloading to only certain devices? 

Mark

Sent from my iPhone

> On Oct 13, 2023, at 9:02 PM, Paul Dupuis via use-livecode 
>  wrote:
> 
> I'd love to see versions of Livecode stacks that assist with code signing 
> and notarization for as many platforms as possible (I am aware of stacks for 
> Windows and macOS) built into Livecode.
> 
> That said, for my two major problems (1 on macOS and 1 on Windows), I don't 
> think there is anything Livecode could have done to help (other than 
> lessons/documentation).
> 
> On Windows my current certificate - a .pfx format code signing cert - is 
> expiring in November, so I renewed it. However, as of June 1 2023, the 
> Windows code signing industry moved to requiring all code signing 
> certificates to be issued on an encrypted USB token and you must use 
> specialized software (that 3rd party can not hook into to prevent malware) to 
> access those tokens to code sign.
> 
> On macOS, I needed to update code signing and NOTARIZATION to accommodate 
> that Apple is switching to a new notary tool that only rns on new versions of 
> macOS (I was using Mojave and atool) so I HAD (forced by Apple) for update to 
> using the macBook Air I have that happened to have Sonoma on it and than 
> meant Xcode 15 command line tools for the new Notary tool. atool stops being 
> accepted by Apple some time in November so my old notarization steps will 
> stop working. The change in notary tool was easy with Matthias's lessons and 
> documentation on livecode.com. The problem was getting my Apple code signing 
> certificates AND related certificates on to the MacBook air from the Apple 
> Developer site, something I don't think Livecode can really help with.
> 
> Yes, others have had still other issues some of which improvements in 
> Livecode might help address, but for the two I ran into that I turned to the 
> list for help for, they were ultimately nothing that I think Livecode could 
> help with.
> 
> Just my 2 cents on my 2 issues.
> 
> 
>> On 10/13/2023 1:46 PM, Richard Gaskin via use-livecode wrote:
>> We see it here in this list. We see it in the forums. We see it wherever app 
>> deployment is discussed:
>> 
>> OS requirements for packaging/stapling/signing apps are onerous.
>> 
>> At the edge of, and sometimes exceeding, being prohibitively so.
>> 
>> There's no point in making a standalone if you can't ship it.
>> 
>> If pro devs with decades of experience struggle with this, newcomers will 
>> run screaming.
>> 
>> SIMPLIFYING DEPLOYMENT IS THE NUMBER ONE PRIORITY.
>> 
>> Pardon the all-caps. I rarely use them. But this is important.
>> 
>> Simplifying deployment is more important than "AI".
>> Simplifying deployment is more important than "nocode".
>> 
>> It is the single biggest pain point.
>> 
>> And so it is the single biggest opportunity.
>> 
>> Fulfill the promise of "Everyone can code": focus on simplifying deployment.
>> 
>> Step 1: Acquire Matthias' great tool.
>> 
>> Step 2: Enhance it for current requirements across platforms.
>> 
>> Step 3: Look for every opportunity to further simplify the process, and take 
>> it, at least one more simplification with each new build.
>> 
>> This is important. It really is.
>> 
>> -- 
>> 
>> And no, web export will not magically save things.  Even when that becomes 
>> truly production-ready, it's only for web apps.  Not everything needs to be 
>> a web app.
>> 
>> There are a hundred ways to make web apps.
>> 
>> There are few ways to make cross-platform native apps.
>> 
>> And almost none that rival what LC can do on the desktop.
>> 
>> Play into strengths.  Make native deployment the best it can be.
>> 
>> When that's done, only then resume work on more peripheral features.
>> 
> 
> 
> ___
> 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: Deployment: a plea/opportunity

[Bob Sneidar via use-livecode]

Don't know why I didn't see Richard's post in my email, but +1 too. 

Bob S

-Original Message-
From: use-livecode  On Behalf Of Klaus 
major-k via use-livecode
Sent: Friday, October 13, 2023 10:53 AM
To: How to use LiveCode 
Cc: Klaus major-k 
Subject: Re: Deployment: a plea/opportunity

Bravo, Richard, you are so right, bravo!

> Am 13.10.2023 um 19:46 schrieb Richard Gaskin via use-livecode 
> :
> 
> We see it here in this list. We see it in the forums. We see it wherever app 
> deployment is discussed:
> OS requirements for packaging/stapling/signing apps are onerous.
> At the edge of, and sometimes exceeding, being prohibitively so.
> There's no point in making a standalone if you can't ship it.
> If pro devs with decades of experience struggle with this, newcomers will run 
> screaming.
> SIMPLIFYING DEPLOYMENT IS THE NUMBER ONE PRIORITY.
> Pardon the all-caps. I rarely use them. But this is important.
> Simplifying deployment is more important than "AI".
> Simplifying deployment is more important than "nocode".
> It is the single biggest pain point.
> And so it is the single biggest opportunity.
> Fulfill the promise of "Everyone can code": focus on simplifying deployment.
> Step 1: Acquire Matthias' great tool.
> Step 2: Enhance it for current requirements across platforms.
> Step 3: Look for every opportunity to further simplify the process, and take 
> it, at least one more simplification with each new build.
> This is important. It really is.
> --
> And no, web export will not magically save things.  Even when that becomes 
> truly production-ready, it's only for web apps.  Not everything needs to be a 
> web app.
> There are a hundred ways to make web apps.
> There are few ways to make cross-platform native apps.
> And almost none that rival what LC can do on the desktop.
> Play into strengths.  Make native deployment the best it can be.
> When that's done, only then resume work on more peripheral features.
> -- 
> Richard Gaskin
> Fourth World Systems

--
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:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Deployment: a plea/opportunity

[J. Landman Gay via use-livecode]

On 10/13/23 12:46 PM, Richard Gaskin via use-livecode wrote:

If pro devs with decades of experience struggle with this, newcomers will run 
screaming.


I agree. But as a "pro" dev I'm embarrassed to admit that the problem I was having was of my 
own doing. Matthias' Helper tool is invaluable and I couldn't understand why it always worked 
before but didn't now. He took a look and found the problem. Actually, I had two problems, none 
of which LC could have solved.


Problem 1: I was using a certificate for the wrong app. I wish I'd known what "no identity 
found" meant. I could have fixed it.


Problem 2: (Stupid, stupid, stupid) I uploaded my app to Google Drive for download and forgot 
to zip it. Matthias found that it was corrupted when he tried to help (bless you, Matthias.) I 
have known forever that uncompressed files don't travel well but we had customers running 
Sonoma who were flooding the tech queue, and in the rush to get the thing out I forgot. And 
since I could run the original build on my own Mac, I couldn't figure out why no one else could 
open it.


That said, it would be great if LC could create an .ipa for iOS and provide 
notarization/stapling services for Mac apps. It's a start. But honestly, that would only be of 
marginal help. The certificates, profiles, keystores, etc. can only be created by the 
developer, and that's mostly where the headaches begin.


I used to be an enthusiastic Apple advocate but now I'm not so sure. Once you've seen the 
developer side your perceptions change. Google is only marginally easier these days too. I 
understand the security reasons for all the hassle, but that doesn't help when you're in the 
middle of it.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com


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

Re: Deployment: a plea/opportunity

[Paul Dupuis via use-livecode]

I'd love to see versions of Livecode stacks that assist with code 
signing and notarization for as many platforms as possible (I am aware 
of stacks for Windows and macOS) built into Livecode.


That said, for my two major problems (1 on macOS and 1 on Windows), I 
don't think there is anything Livecode could have done to help (other 
than lessons/documentation).


On Windows my current certificate - a .pfx format code signing cert - is 
expiring in November, so I renewed it. However, as of June 1 2023, the 
Windows code signing industry moved to requiring all code signing 
certificates to be issued on an encrypted USB token and you must use 
specialized software (that 3rd party can not hook into to prevent 
malware) to access those tokens to code sign.


On macOS, I needed to update code signing and NOTARIZATION to 
accommodate that Apple is switching to a new notary tool that only rns 
on new versions of macOS (I was using Mojave and atool) so I HAD (forced 
by Apple) for update to using the macBook Air I have that happened to 
have Sonoma on it and than meant Xcode 15 command line tools for the new 
Notary tool. atool stops being accepted by Apple some time in November 
so my old notarization steps will stop working. The change in notary 
tool was easy with Matthias's lessons and documentation on livecode.com. 
The problem was getting my Apple code signing certificates AND related 
certificates on to the MacBook air from the Apple Developer site, 
something I don't think Livecode can really help with.


Yes, others have had still other issues some of which improvements in 
Livecode might help address, but for the two I ran into that I turned to 
the list for help for, they were ultimately nothing that I think 
Livecode could help with.


Just my 2 cents on my 2 issues.


On 10/13/2023 1:46 PM, Richard Gaskin via use-livecode wrote:
We see it here in this list. We see it in the forums. We see it 
wherever app deployment is discussed:


OS requirements for packaging/stapling/signing apps are onerous.

At the edge of, and sometimes exceeding, being prohibitively so.

There's no point in making a standalone if you can't ship it.

If pro devs with decades of experience struggle with this, newcomers 
will run screaming.


SIMPLIFYING DEPLOYMENT IS THE NUMBER ONE PRIORITY.

Pardon the all-caps. I rarely use them. But this is important.

Simplifying deployment is more important than "AI".
Simplifying deployment is more important than "nocode".

It is the single biggest pain point.

And so it is the single biggest opportunity.

Fulfill the promise of "Everyone can code": focus on simplifying 
deployment.


Step 1: Acquire Matthias' great tool.

Step 2: Enhance it for current requirements across platforms.

Step 3: Look for every opportunity to further simplify the process, 
and take it, at least one more simplification with each new build.


This is important. It really is.

--

And no, web export will not magically save things.  Even when that 
becomes truly production-ready, it's only for web apps.  Not 
everything needs to be a web app.


There are a hundred ways to make web apps.

There are few ways to make cross-platform native apps.

And almost none that rival what LC can do on the desktop.

Play into strengths.  Make native deployment the best it can be.

When that's done, only then resume work on more peripheral features.




___
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: Deployment: a plea/opportunity

[Dan Friedman via use-livecode]

+1

I obviously agree!I finally got my Mac app uploaded to the Mac Store (and 
approved)… but what a pain!!!   There are SO many steps that could easily be 
done by LiveCode that they have chosen to omit.   Simple things like generating 
the .ipa for iOS (this is a simple command line), having a place to enter the 
permission strings for Mac Desktop apps (this is a pain because you must build 
the app, then grab the generated plist, edit it, then include it in your app 
settings and then build it again.  Not hard, but this is something LC should 
provide in the Application Settings Window.  On that note, the 
“LSApplicationCategoryType” key (and category key) is not included in the 
generated plist.  I had to add it manually.  Apparently, this is now required.  
 I’m sure the great minds at LC could find a way to sign your app if you have 
the correct files installed and “fill in the blanks”.  They could probably do 
justified text too, but I won’t get into that!!  :)

Yes, this is hard to keep up with.  But isn’t that the whole point of a product 
like LiveCode?  The product is supposed to do the dirty work for you.

Although usually at the last second… LC is pretty good when it comes to keeping 
up with requirements with Apple and Android when the problem causes you to not 
be able to submit to the app stores or OS incompatibilities.  But in the case 
of the above examples, there are workarounds.  So, you are on your own.

-Dan


From: use-livecode  on behalf of Tom 
Glod via use-livecode 
Date: Friday, October 13, 2023 at 12:15 PM
To: How to use LiveCode 
Cc: Tom Glod 
Subject: Re: Deployment: a plea/opportunity
100% the biggest problem I have in my business.
Have been stuck on iOS for months.
Android and Windows is kind of OK, but still more can be done.
Agree. Would pay for a solution that just works.

On Fri, Oct 13, 2023 at 3:00 PM Mark Smith via use-livecode <
use-livecode@lists.runrev.com> wrote:

> +1,
>
> I totally agree this is really important (and really hard to keep up
> with). But Apple should take some of the responsibility for this. With the
> resources at their disposal they should be able to create a simpler and
> easier way to execute deployment without sacrificing security and
> authenticity.
>
> Very well said. I should add that I have also been using Kee Nethery’s
> instructions for signing Mac apps and it has been a godsend. I have not
> quite yet gotten to the point of deploying to the App Store (with it) but
> that will be the next step.
>
> Mark
>
>
> > On 13 Oct 2023, at 7:49 pm, William Prothero via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > I second (3rd and 4th too) Richard's plea. Deployment is a killer.
> > Bill
> >
> > William A. Prothero, PhD
> > Prof Emeritus, Dept of Earth Science
> > University of California, Santa Barbara
> >
> >> On Oct 13, 2023, at 10:47 AM, Richard Gaskin via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >>
> >> We see it here in this list. We see it in the forums. We see it
> wherever app deployment is discussed:
> >>
> >> OS requirements for packaging/stapling/signing apps are onerous.
> >>
> >> At the edge of, and sometimes exceeding, being prohibitively so.
> >>
> >> There's no point in making a standalone if you can't ship it.
> >>
> >> If pro devs with decades of experience struggle with this, newcomers
> will run screaming.
> >>
> >> SIMPLIFYING DEPLOYMENT IS THE NUMBER ONE PRIORITY.
> >>
> >> Pardon the all-caps. I rarely use them. But this is important.
> >>
> >> Simplifying deployment is more important than "AI".
> >> Simplifying deployment is more important than "nocode".
> >>
> >> It is the single biggest pain point.
> >>
> >> And so it is the single biggest opportunity.
> >>
> >> Fulfill the promise of "Everyone can code": focus on simplifying
> deployment.
> >>
> >> Step 1: Acquire Matthias' great tool.
> >>
> >> Step 2: Enhance it for current requirements across platforms.
> >>
> >> Step 3: Look for every opportunity to further simplify the process, and
> take it, at least one more simplification with each new build.
> >>
> >> This is important. It really is.
> >>
> >> --
> >>
> >> And no, web export will not magically save things.  Even when that
> becomes truly production-ready, it's only for web apps.  Not everything
> needs to be a web app.
> >>
> >> There are a hundred ways to make web apps.
> >>
> >> There are few ways to make cross-platform native apps.
> >>
> >> And almost none that rival what LC can do on the desktop.
> >>
> >> Play into strengths.  Make native deployment the best it can be.
> >>
> >> When that's done, only then resume work on more peripheral features.
> >>
> >> --
> >> 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:
> >> 

Re: Deployment: a plea/opportunity

[Tom Glod via use-livecode]

100% the biggest problem I have in my business.
Have been stuck on iOS for months.
Android and Windows is kind of OK, but still more can be done.
Agree. Would pay for a solution that just works.

On Fri, Oct 13, 2023 at 3:00 PM Mark Smith via use-livecode <
use-livecode@lists.runrev.com> wrote:

> +1,
>
> I totally agree this is really important (and really hard to keep up
> with). But Apple should take some of the responsibility for this. With the
> resources at their disposal they should be able to create a simpler and
> easier way to execute deployment without sacrificing security and
> authenticity.
>
> Very well said. I should add that I have also been using Kee Nethery’s
> instructions for signing Mac apps and it has been a godsend. I have not
> quite yet gotten to the point of deploying to the App Store (with it) but
> that will be the next step.
>
> Mark
>
>
> > On 13 Oct 2023, at 7:49 pm, William Prothero via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > I second (3rd and 4th too) Richard's plea. Deployment is a killer.
> > Bill
> >
> > William A. Prothero, PhD
> > Prof Emeritus, Dept of Earth Science
> > University of California, Santa Barbara
> >
> >> On Oct 13, 2023, at 10:47 AM, Richard Gaskin via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >>
> >> We see it here in this list. We see it in the forums. We see it
> wherever app deployment is discussed:
> >>
> >> OS requirements for packaging/stapling/signing apps are onerous.
> >>
> >> At the edge of, and sometimes exceeding, being prohibitively so.
> >>
> >> There's no point in making a standalone if you can't ship it.
> >>
> >> If pro devs with decades of experience struggle with this, newcomers
> will run screaming.
> >>
> >> SIMPLIFYING DEPLOYMENT IS THE NUMBER ONE PRIORITY.
> >>
> >> Pardon the all-caps. I rarely use them. But this is important.
> >>
> >> Simplifying deployment is more important than "AI".
> >> Simplifying deployment is more important than "nocode".
> >>
> >> It is the single biggest pain point.
> >>
> >> And so it is the single biggest opportunity.
> >>
> >> Fulfill the promise of "Everyone can code": focus on simplifying
> deployment.
> >>
> >> Step 1: Acquire Matthias' great tool.
> >>
> >> Step 2: Enhance it for current requirements across platforms.
> >>
> >> Step 3: Look for every opportunity to further simplify the process, and
> take it, at least one more simplification with each new build.
> >>
> >> This is important. It really is.
> >>
> >> --
> >>
> >> And no, web export will not magically save things.  Even when that
> becomes truly production-ready, it's only for web apps.  Not everything
> needs to be a web app.
> >>
> >> There are a hundred ways to make web apps.
> >>
> >> There are few ways to make cross-platform native apps.
> >>
> >> And almost none that rival what LC can do on the desktop.
> >>
> >> Play into strengths.  Make native deployment the best it can be.
> >>
> >> When that's done, only then resume work on more peripheral features.
> >>
> >> --
> >> 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
>
>
> ___
> 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: Deployment: a plea/opportunity

[Mark Smith via use-livecode]

+1, 

I totally agree this is really important (and really hard to keep up with). But 
Apple should take some of the responsibility for this. With the resources at 
their disposal they should be able to create a simpler and easier way to 
execute deployment without sacrificing security and authenticity. 

Very well said. I should add that I have also been using Kee Nethery’s 
instructions for signing Mac apps and it has been a godsend. I have not quite 
yet gotten to the point of deploying to the App Store (with it) but that will 
be the next step.

Mark


> On 13 Oct 2023, at 7:49 pm, William Prothero via use-livecode 
>  wrote:
> 
> I second (3rd and 4th too) Richard's plea. Deployment is a killer.
> Bill
> 
> William A. Prothero, PhD
> Prof Emeritus, Dept of Earth Science
> University of California, Santa Barbara
> 
>> On Oct 13, 2023, at 10:47 AM, Richard Gaskin via use-livecode 
>>  wrote:
>> 
>> We see it here in this list. We see it in the forums. We see it wherever 
>> app deployment is discussed:
>> 
>> OS requirements for packaging/stapling/signing apps are onerous.
>> 
>> At the edge of, and sometimes exceeding, being prohibitively so.
>> 
>> There's no point in making a standalone if you can't ship it.
>> 
>> If pro devs with decades of experience struggle with this, newcomers will 
>> run screaming.
>> 
>> SIMPLIFYING DEPLOYMENT IS THE NUMBER ONE PRIORITY.
>> 
>> Pardon the all-caps. I rarely use them. But this is important.
>> 
>> Simplifying deployment is more important than "AI".
>> Simplifying deployment is more important than "nocode".
>> 
>> It is the single biggest pain point.
>> 
>> And so it is the single biggest opportunity.
>> 
>> Fulfill the promise of "Everyone can code": focus on simplifying deployment.
>> 
>> Step 1: Acquire Matthias' great tool.
>> 
>> Step 2: Enhance it for current requirements across platforms.
>> 
>> Step 3: Look for every opportunity to further simplify the process, and take 
>> it, at least one more simplification with each new build.
>> 
>> This is important. It really is.
>> 
>> --
>> 
>> And no, web export will not magically save things.  Even when that becomes 
>> truly production-ready, it's only for web apps.  Not everything needs to be 
>> a web app.
>> 
>> There are a hundred ways to make web apps.
>> 
>> There are few ways to make cross-platform native apps.
>> 
>> And almost none that rival what LC can do on the desktop.
>> 
>> Play into strengths.  Make native deployment the best it can be.
>> 
>> When that's done, only then resume work on more peripheral features.
>> 
>> --
>> 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


___
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: Deployment: a plea/opportunity

[William Prothero via use-livecode]

I second (3rd and 4th too) Richard's plea. Deployment is a killer.
Bill

William A. Prothero, PhD
Prof Emeritus, Dept of Earth Science
University of California, Santa Barbara

> On Oct 13, 2023, at 10:47 AM, Richard Gaskin via use-livecode 
>  wrote:
> 
> We see it here in this list. We see it in the forums. We see it wherever app 
> deployment is discussed:
> 
> OS requirements for packaging/stapling/signing apps are onerous.
> 
> At the edge of, and sometimes exceeding, being prohibitively so.
> 
> There's no point in making a standalone if you can't ship it.
> 
> If pro devs with decades of experience struggle with this, newcomers will run 
> screaming.
> 
> SIMPLIFYING DEPLOYMENT IS THE NUMBER ONE PRIORITY.
> 
> Pardon the all-caps. I rarely use them. But this is important.
> 
> Simplifying deployment is more important than "AI".
> Simplifying deployment is more important than "nocode".
> 
> It is the single biggest pain point.
> 
> And so it is the single biggest opportunity.
> 
> Fulfill the promise of "Everyone can code": focus on simplifying deployment.
> 
> Step 1: Acquire Matthias' great tool.
> 
> Step 2: Enhance it for current requirements across platforms.
> 
> Step 3: Look for every opportunity to further simplify the process, and take 
> it, at least one more simplification with each new build.
> 
> This is important. It really is.
> 
> --
> 
> And no, web export will not magically save things.  Even when that becomes 
> truly production-ready, it's only for web apps.  Not everything needs to be a 
> web app.
> 
> There are a hundred ways to make web apps.
> 
> There are few ways to make cross-platform native apps.
> 
> And almost none that rival what LC can do on the desktop.
> 
> Play into strengths.  Make native deployment the best it can be.
> 
> When that's done, only then resume work on more peripheral features.
> 
> --
> 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

Re: All Versions of LC crashing in Sonoma

[matthias rebbe via use-livecode]

Yes that is definitely the case.

But Bill asked if Apple will "fix that in Sonoma" so his old standalones will 
still work under Sonoma without building them again with 9.6.10 or 10.0.6. At 
least that was my understanding. ;) 



> Am 13.10.2023 um 18:32 schrieb Bob Sneidar via use-livecode 
> :
> 
> Heather, just to be clear, I was under the implression that 9.6.10 and 10.0.6 
> WAS the fix for this. 
> 
> Bob S
> 
> 
> -Original Message-
> From: use-livecode  On Behalf Of 
> Heather Laine via use-livecode
> Sent: Friday, October 13, 2023 1:37 AM
> To: How to use LiveCode 
> Cc: Heather Laine 
> Subject: Re: All Versions of LC crashing in Sonoma
> 
> I don't think you can hope for that. It's not a bug, its a change in the way 
> they are implementing menus.
> 
> 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: Deployment: a plea/opportunity

[Klaus major-k via use-livecode]

Bravo, Richard, you are so right, bravo!

> Am 13.10.2023 um 19:46 schrieb Richard Gaskin via use-livecode 
> :
> 
> We see it here in this list. We see it in the forums. We see it wherever app 
> deployment is discussed:
> OS requirements for packaging/stapling/signing apps are onerous.
> At the edge of, and sometimes exceeding, being prohibitively so.
> There's no point in making a standalone if you can't ship it.
> If pro devs with decades of experience struggle with this, newcomers will run 
> screaming.
> SIMPLIFYING DEPLOYMENT IS THE NUMBER ONE PRIORITY.
> Pardon the all-caps. I rarely use them. But this is important.
> Simplifying deployment is more important than "AI".
> Simplifying deployment is more important than "nocode".
> It is the single biggest pain point.
> And so it is the single biggest opportunity.
> Fulfill the promise of "Everyone can code": focus on simplifying deployment.
> Step 1: Acquire Matthias' great tool.
> Step 2: Enhance it for current requirements across platforms.
> Step 3: Look for every opportunity to further simplify the process, and take 
> it, at least one more simplification with each new build.
> This is important. It really is.
> --
> And no, web export will not magically save things.  Even when that becomes 
> truly production-ready, it's only for web apps.  Not everything needs to be a 
> web app.
> There are a hundred ways to make web apps.
> There are few ways to make cross-platform native apps.
> And almost none that rival what LC can do on the desktop.
> Play into strengths.  Make native deployment the best it can be.
> When that's done, only then resume work on more peripheral features.
> -- 
> Richard Gaskin
> Fourth World Systems

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

Deployment: a plea/opportunity

[Richard Gaskin via use-livecode]

We see it here in this list. We see it in the forums. We see it wherever 
app deployment is discussed:


OS requirements for packaging/stapling/signing apps are onerous.

At the edge of, and sometimes exceeding, being prohibitively so.

There's no point in making a standalone if you can't ship it.

If pro devs with decades of experience struggle with this, newcomers 
will run screaming.


SIMPLIFYING DEPLOYMENT IS THE NUMBER ONE PRIORITY.

Pardon the all-caps. I rarely use them. But this is important.

Simplifying deployment is more important than "AI".
Simplifying deployment is more important than "nocode".

It is the single biggest pain point.

And so it is the single biggest opportunity.

Fulfill the promise of "Everyone can code": focus on simplifying deployment.

Step 1: Acquire Matthias' great tool.

Step 2: Enhance it for current requirements across platforms.

Step 3: Look for every opportunity to further simplify the process, and 
take it, at least one more simplification with each new build.


This is important. It really is.

--

And no, web export will not magically save things.  Even when that 
becomes truly production-ready, it's only for web apps.  Not everything 
needs to be a web app.


There are a hundred ways to make web apps.

There are few ways to make cross-platform native apps.

And almost none that rival what LC can do on the desktop.

Play into strengths.  Make native deployment the best it can be.

When that's done, only then resume work on more peripheral features.

--
 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: All Versions of LC crashing in Sonoma

[Bob Sneidar via use-livecode]

Heather, just to be clear, I was under the implression that 9.6.10 and 10.0.6 
WAS the fix for this. 

Bob S


-Original Message-
From: use-livecode  On Behalf Of Heather 
Laine via use-livecode
Sent: Friday, October 13, 2023 1:37 AM
To: How to use LiveCode 
Cc: Heather Laine 
Subject: Re: All Versions of LC crashing in Sonoma

I don't think you can hope for that. It's not a bug, its a change in the way 
they are implementing menus.

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

Re: Android: Myapp stopped

[Klaus major-k via use-livecode]

Hi Jaqcue,

> Am 13.10.2023 um 18:24 schrieb J. Landman Gay via use-livecode 
> :
> 
> Yes, it seems like the bug was fixed in later versions.

ah, thank you, I guessed.
So bad news for our guitarplayer/singer...

> There are some workarounds in the stackoverflow link using terminal but I 
> didn't understand them.

Same here, so I wouldn't even try this! :-D

> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software | http://www.hyperactivesw.com
> On October 13, 2023 10:51:26 AM Klaus major-k via use-livecode 
>  wrote:
> 
>> Hi Jacque,
>> 
>>> Am 13.10.2023 um 17:41 schrieb J. Landman Gay via use-livecode 
>>> :
>>> 
>>> I looked it up. It's a Samsung bug:
>>> 
>>> If you Google "Could not set capabilities: Operation not permitted " you'll 
>>> see lots of results.
>> 
>> thank you for this valuable info!
>> Too bad...
>> 
>> So it means the Samsung tablets with earlier versions of Android/API have 
>> this problem?
>> Our drummer and me also have Samsung tablets, but with Android 8.x resp 
>> Android 11.

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

Re: Android: Myapp stopped

[J. Landman Gay via use-livecode]

Yes, it seems like the bug was fixed in later versions. There are some 
workarounds in the stackoverflow link using terminal but I didn't 
understand them.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On October 13, 2023 10:51:26 AM Klaus major-k via use-livecode 
 wrote:



Hi Jacque,

Am 13.10.2023 um 17:41 schrieb J. Landman Gay via use-livecode 
:


I looked it up. It's a Samsung bug:

If you Google "Could not set capabilities: Operation not permitted " you'll 
see lots of results.


thank you for this valuable info!
Too bad...

So it means the Samsung tablets with earlier versions of Android/API have 
this problem?
Our drummer and me also have Samsung tablets, but with Android 8.x resp 
Android 11.



--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On October 13, 2023 3:49:32 AM Klaus major-k via use-livecode 
 wrote:



Hi Jacque,

Am 12.10.2023 um 22:37 schrieb J. Landman Gay via use-livecode 
:


What minimum Android version is set in Standalone Settings? Does it include 
Android 6?


it is set to 5, so yes, it should include version 6.


On 10/12/23 8:35 AM, Klaus major-k via use-livecode wrote:

Hi friends,
I am trying to install my app on the tablets of my bandmembers
and succeeded on all but one!?
Info:
Samsung Galaxy Tab S
Android 6.0.1, API 23
After installation from LC (Test) I tap on the icon and get the alert:
-> Leadsheeter stopped (angehalten)
immediately, no more info.
I already emptied cache and data and whatnot and even restarted
the device a couple of times, no dice!?
The only info I could get after starting Android Studio was in the
"Device File Explorer" panel for the device which reads:

data -> app -> com.major-k.de.leadsheeter-1
run-as: Could not set capabilities: Operation not permitted



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:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Android: Myapp stopped

[Klaus major-k via use-livecode]

Hi Jacque,

> Am 13.10.2023 um 17:41 schrieb J. Landman Gay via use-livecode 
> :
> 
> I looked it up. It's a Samsung bug:
> 
> If you Google "Could not set capabilities: Operation not permitted " you'll 
> see lots of results.

thank you for this valuable info!
Too bad...

So it means the Samsung tablets with earlier versions of Android/API have this 
problem?
Our drummer and me also have Samsung tablets, but with Android 8.x resp Android 
11.

> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software | http://www.hyperactivesw.com
> On October 13, 2023 3:49:32 AM Klaus major-k via use-livecode 
>  wrote:
> 
>> Hi Jacque,
>> 
>>> Am 12.10.2023 um 22:37 schrieb J. Landman Gay via use-livecode 
>>> :
>>> 
>>> What minimum Android version is set in Standalone Settings? Does it include 
>>> Android 6?
>> 
>> it is set to 5, so yes, it should include version 6.
>> 
>>> On 10/12/23 8:35 AM, Klaus major-k via use-livecode wrote:
 Hi friends,
 I am trying to install my app on the tablets of my bandmembers
 and succeeded on all but one!?
 Info:
 Samsung Galaxy Tab S
 Android 6.0.1, API 23
 After installation from LC (Test) I tap on the icon and get the alert:
 -> Leadsheeter stopped (angehalten)
 immediately, no more info.
 I already emptied cache and data and whatnot and even restarted
 the device a couple of times, no dice!?
 The only info I could get after starting Android Studio was in the
 "Device File Explorer" panel for the device which reads:
 
 data -> app -> com.major-k.de.leadsheeter-1
 run-as: Could not set capabilities: Operation not permitted
 

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

Re: Android: Myapp stopped

[J. Landman Gay via use-livecode]

I looked it up. It's a Samsung bug:


If you Google "Could not set capabilities: Operation not permitted " you'll 
see lots of results.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On October 13, 2023 3:49:32 AM Klaus major-k via use-livecode 
 wrote:



Hi Jacque,

Am 12.10.2023 um 22:37 schrieb J. Landman Gay via use-livecode 
:


What minimum Android version is set in Standalone Settings? Does it include 
Android 6?


it is set to 5, so yes, it should include version 6.


On 10/12/23 8:35 AM, Klaus major-k via use-livecode wrote:

Hi friends,
I am trying to install my app on the tablets of my bandmembers
and succeeded on all but one!?
Info:
Samsung Galaxy Tab S
Android 6.0.1, API 23
After installation from LC (Test) I tap on the icon and get the alert:
-> Leadsheeter stopped (angehalten)
immediately, no more info.
I already emptied cache and data and whatnot and even restarted
the device a couple of times, no dice!?
The only info I could get after starting Android Studio was in the
"Device File Explorer" panel for the device which reads:

data -> app -> com.major-k.de.leadsheeter-1
run-as: Could not set capabilities: Operation not permitted

API too old? Anything else I can check in Android Studio?
Any hints very welcome!
Thanks a lot in advance.
Best


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:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Questions on Wasm export, licenses and file siz

[David Bovill via use-livecode]

Lets take the following scenario:

1) We have a library of interactive components created in Livecode.  They
are structured as (Levure) components. They could be turned into script
components easily, or LCB based components with a little more work.
2) We wish to compose a series of apps based on these components in which
3-15 of them interact with each other on any given screen.
3) We can prototype and deliver these apps in a Livecode based prototype.
4) There is a project need for an advanced architecture that engages the
enthusiasm of University students and the wider developer community. We
therefore require a strategy that enables developers in a range of modern
language - particularly rust, javascript and python to participate.
5) It is a long term project - so we can take out time and wait for
technologies to mature. However we wish to deliver rapid prototypes that
can be tested with communities in the short term.

Given the above I’d like to be able to prototype the software(s) by
exporting these Livecode (Levure-style) components as wasm - and embed
these on web pages in which they communicate with each other securely.
Components that need speeding up, or reduced in file size once tested may
be rewritten eventually in another language.

My concern is:

- having several wasm components on a single web view will involve
multiplying the quite large engine download for each component?
- which licence will be required so that these wasm components over the
duration of the project?

On Thu, 12 Oct 2023 at 20:16, David Bovill  wrote:

> Hi Richard specifically I need to know if I create an web page with
> multiple HTML5  export embeds whether the Livecode wasm approach forces the
> engine to be exported multiple times.
>
> On Thu, 12 Oct 2023 at 17:09, ambassador--- via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
>> David Bovill wrote:
>> > With the old JavaScript export you had a separation between the engine
>> > and stacks such that you could cache the engine part in the browser to
>> > speed up the loading of the much smaller stacks. Is that the case (or
>> > it is intended to be the case in the future) with the wasm export?
>>
>> A couple years ago Andre outlined the differences between JS and WASM,
>> worth reviewing:
>>
>> https://www.mail-archive.com/use-livecode%40lists.runrev.com/msg08.html
>>
>> With your background you're probably well aware of the differences, but
>> since we see so many conceptualizing WASM as "compiled JavaScript" it's
>> worth taking a moment to review their respective boundaries.
>>
>> Given that WASM has no direct access to the DOM, and therefore no direct
>> manipulation of controls or events, it is not a drop-in replacement for JS.
>>
>> In LC terms, it may be best to think about WASM's relationship to the
>> browser as similar to what externals are to LC.
>>
>> Of course externals are very powerful; most of the v8 bullet points were
>> new externals. But they still need LC Script to interface with our apps.
>>
>> The degree to which LC Ltd will be able to compile the whole engine into
>> WASM is a good question, but it seems clear it will be limited in some
>> ways, and it's unlikely we'll see compilation of LC Script to WASM for the
>> foreseeable future.
>>
>> The good news is that the LC Community has a growing body of knowledge
>> around JavaScript: some of the cooler widgets are just wrappers around a
>> browser instance running JS/HTML/CSS.  And given the vast amounts of
>> web-native (JS/HTML/CSS) code out in the world, folks are continually
>> finding new ways to integrate the native web stack with LC stack objects
>> nicely.
>>
>> If web deployment is the goal, I see no downside and much to be gained
>> from spending more time practicing JavaScript. While different from xTalk,
>> it's a good language, and arguably closer to what xTalk might have looked
>> like if HyperCard premiered 10 years later than it did.
>>
>> Being comfortable with JS means being able to fill in gaps between your
>> LC work and LC's web export more easily, and even within LC today it's the
>> gateway to vast components via the browser widget.
>>
>> JS is the only interactive language included in browsers.  The best time
>> to learn it was yesterday. The second best time is today.
>>
>> Like AppleScript, PowerShell, bash, and others, learning other languages
>> opens new doors for integrating LC across a wide variety of systems.
>>
>> Bonus: the more you learn JS, the less you need to wait for with the
>> feature completion in LC's web export.
>>
>> As for your question about deployment size, we can expect a WASMified
>> engine to be smaller than its JS version, but there are so many factors
>> that go into that it may just be too early to tell.
>>
>> If you do a web search for "WASM replace JavaScript" you'll not only get
>> deeper discussions than what I've offered here, but also some confounding
>> benchmarks where it's possible to have compiled WASM larger than the 

Re: Android: Myapp stopped

[Klaus major-k via use-livecode]

Hi Jacque,

> Am 12.10.2023 um 22:37 schrieb J. Landman Gay via use-livecode 
> :
> 
> What minimum Android version is set in Standalone Settings? Does it include 
> Android 6?

it is set to 5, so yes, it should include version 6.

> On 10/12/23 8:35 AM, Klaus major-k via use-livecode wrote:
>> Hi friends,
>> I am trying to install my app on the tablets of my bandmembers
>> and succeeded on all but one!?
>> Info:
>> Samsung Galaxy Tab S
>> Android 6.0.1, API 23
>> After installation from LC (Test) I tap on the icon and get the alert:
>> -> Leadsheeter stopped (angehalten)
>> immediately, no more info.
>> I already emptied cache and data and whatnot and even restarted
>> the device a couple of times, no dice!?
>> The only info I could get after starting Android Studio was in the
>> "Device File Explorer" panel for the device which reads:
>> 
>> data -> app -> com.major-k.de.leadsheeter-1
>> run-as: Could not set capabilities: Operation not permitted
>> 
>> API too old? Anything else I can check in Android Studio?
>> Any hints very welcome!
>> Thanks a lot in advance.
>> Best

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

Re: All Versions of LC crashing in Sonoma

[Heather Laine via use-livecode]

I don't think you can hope for that. It's not a bug, its a change in the way 
they are implementing menus.

Best Regards,

Heather

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



> On 12 Oct 2023, at 18:10, Bill Vlahos  wrote:
> 
> Heather,
> 
> Do you think Apple will address this issue in an update to Sonoma?
> 
> Rebuilding all my applications will be difficult.
> 
> Thank you,
> Bill Vlahos
> 
>> On Oct 3, 2023, at 6:56 AM, Heather Laine via use-livecode 
>>  wrote:
>> 
>> Hi Matthias,
>> 
>> I think ANY menu will cause a crash. |f your app has no menus it will not be 
>> affected by the issue. Otherwise, it will crash, as does LiveCode itself  
>> prior to the fix.
>> 
>> Best Regards,
>> 
>> Heather
>> 
>> Heather Laine
>> Customer Services Manager
>> LiveCode Ltd
>> www.livecode.com
>> 
>> 
>> 
>>> On 3 Oct 2023, at 11:53, matthias rebbe via use-livecode 
>>>  wrote:
>>> 
>>> Hi Heather,
>>> 
>>> thanks for clarifying the reason for the crashes.
>>> 
>>> At least this grants that standalones created with older LC versions will 
>>> run as long as they do not contain a customized menu, right?
>>> 
>>> Regards,
>>> Matthias
>>> 
>>> 
 Am 03.10.2023 um 12:24 schrieb Heather Laine via use-livecode 
 :
 
 Hi Rolf,
 
 No, the problem is not related to signing. The problem centers on how 
 Sonoma handles menus, and any app that contains a menu will crash on 
 Sonoma unless built with LiveCode 9.6.10 or 10 dp-6.
 
 Best Regards,
 
 Heather
 
 Heather Laine
 Customer Services Manager
 LiveCode Ltd
 www.livecode.com
 
 
 
> On 3 Oct 2023, at 09:53, Rolf Kocherhans via use-livecode 
>  wrote:
> 
> @Matthias and the Mothership,
> 
> My Apple Developer account expired several years ago, and I'm facing a 
> critical issue with one of my LiveCode Apps, Clarify, developed by Trevor 
> DeVore. This app is extremely important to me.
> 
> Unfortunately, Clarify is no longer actively developed and has started 
> crashing with Sonoma. I am wondering if there's a possibility to resolve 
> this issue by signing the bundles. I am more than willing to invest in a 
> new subscription with Apple if that's what it takes – I can't imagine my 
> work without Clarify.
> 
> Could someone please test if signing the bundles might make an app 
> functional again?
> Your assistance in this matter would mean the world to me.
> 
> Cheers,
> Rolf
> 
> Am 30.09.2023 um 18:00 schrieb use-livecode-requ...@lists.runrev.com:
> 
> Maybe my observation is not the reason for the crash. Would really not 
> make sense, when an unsigned app would crash instead of reporting an 
> alert.
> 
> But code signing  the complete Livecode app bundle would proof it.
> 
> Did someone btw had a look at the system log file after the crash?
> 
> ___
> 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