Re: We don't need a Player (was Re: New(?) Idea for Standalones)

[J. Landman Gay via use-livecode]

I tried that but I don't keep Xcode in the root of the Applications folder 
and the stack gave a warning. When I moved it there, the Xcode commands 
couldn't find it because I'd set the Xcode default to a copy in a subfolder.


Maybe a future update can determine the user's Xcode location. I have three 
copies because different versions of LC require different versions of Xcode.



What took the most time was figuring out what was wrong.
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On April 13, 2021 6:26:02 PM matthias rebbe via use-livecode 
 wrote:


Couldn't you search for the ASC provider in the helper stack pressing the 
"Loupe" icon in the general settings?



-
Matthias Rebbe
Life Is Too Short For Boring Code


Am 14.04.2021 um 01:12 schrieb J. Landman Gay via use-livecode 
:


Cool. Thanks. I do keep NotarizationHelper in my plugins folder since I use 
it frequently.


I probably will continue with the manual method for a while though, since I 
have three different apps to notarize and I have to update the General 
settings each time. Maybe later I'll revise your script to fill in the data 
for me.


What I did not realize until I wasted a lot of time today is that the ASC 
changes depending on the app password, the ID Application, or something 
else I can't identify. It kept telling me I wasn't a member of my own 
developer account. I finally ran the Terminal command that returns all the 
ASCs and my ASC was different than it was before.


People who are a member of only one account won't have that problem, but it 
took me a long time to figure out what was wrong. Once I had the right ASC 
your helper did its work gracefully.



On 4/13/21 2:17 PM, matthias rebbe via use-livecode wrote:

Jacque,
and if put the that NotarizerHelperStack into the plugins folder and if you 
add the below code  to your stack script
then you can directly code sign and notarize the created macOS standalone 
right after it was built. ;)

on standaloneSaved pFolderSavedIn
if the cRevStandaloneSettings["MacOSX x86-64"] of this stack is true
then
answer "Do you want to notarize?" with "yes" or "No"
if it ="yes"
then
put pFolderSavedIN & "MacOSX/" & the cRevStandaloneSettings["name"] of this 
stack & ".app" into tAppBundle

notarizeApp tAppbundle
else
put "Don't notarize"
end if
end if
pass standalonesaved
end standaloneSaved
on notarizeApp tAppbundle
 put "Now notarizing..."   after message
 ##path to the notarizer Stack..
## either use an absolute path
--go stack "/Users/matthias/Dropbox/My 
Livecode/Plugins/mrSignNotarizeHelperV2.livecode"

##or if the helper stack is in the plugins folder
go stack revEnvironmentUserPluginsPath()&"/mrSignNotarizeHelperV2.livecode"
put tAppbundle into fld "appbundle" of cd 1 of stack "mrSignNotarizeHelperV2"
set the label of btn "action" of cd 1 of stack "mrSignNotarizeHelperV2" to 
"Codesign App, create & codesign DMG, then notarize DMG and staple DMG and App"
set the hilite of btn "debugmode" of cd 1 of stack "mrSignNotarizeHelperV2" 
to false
send "mouseup" to btn "start" of cd 1 of stack "mrSignNotarizeHelperV2" in 
5 seconds

end notarizeApp
-
Matthias Rebbe
Life Is Too Short For Boring Code
Am 13.04.2021 um 21:03 schrieb J. Landman Gay via use-livecode 
:


On 4/13/21 10:43 AM, Keith Martin via use-livecode wrote:
On 13 Apr 2021, at 11:28, Andre Garzia via 
use-livecode  wrote:


On the other hand, I think that the SB should create standalones that can 
actually be deployed, this means that it should be able to handle 
notarisation on the mac out-of-the-box.

Oh boy, THIS!


+1. But for now I use Matthias' mrSignNotarize helper tool which makes the 
process much easier. Fill out some info, click a button, and your 
notarization request is sent to Apple, returned, and stapled to your app.


It's an extra step which I think LC should incorporate, but for now it 
saves quite a bit of work. You can find it at this LC lesson, which 
includes all the manual steps if you want to do it that way, but at the 
bottom describes his automated tool as well. You can download the stack 
from the link at the top of the lesson.




I've used it on more than one Mac app and it works. The hardest part is 
dealing with Apple and of course there's no help for that.


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

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

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

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

Re: We don't need a Player (was Re: New(?) Idea for Standalones)

[matthias rebbe via use-livecode]

Couldn't you search for the ASC provider in the helper stack pressing the 
"Loupe" icon in the general settings?


-
Matthias Rebbe
Life Is Too Short For Boring Code


> Am 14.04.2021 um 01:12 schrieb J. Landman Gay via use-livecode 
> :
> 
> Cool. Thanks. I do keep NotarizationHelper in my plugins folder since I use 
> it frequently.
> 
> I probably will continue with the manual method for a while though, since I 
> have three different apps to notarize and I have to update the General 
> settings each time. Maybe later I'll revise your script to fill in the data 
> for me.
> 
> What I did not realize until I wasted a lot of time today is that the ASC 
> changes depending on the app password, the ID Application, or something else 
> I can't identify. It kept telling me I wasn't a member of my own developer 
> account. I finally ran the Terminal command that returns all the ASCs and my 
> ASC was different than it was before.
> 
> People who are a member of only one account won't have that problem, but it 
> took me a long time to figure out what was wrong. Once I had the right ASC 
> your helper did its work gracefully.
> 
> 
> On 4/13/21 2:17 PM, matthias rebbe via use-livecode wrote:
>> Jacque,
>> and if put the that NotarizerHelperStack into the plugins folder and if you 
>> add the below code  to your stack script
>> then you can directly code sign and notarize the created macOS standalone 
>> right after it was built. ;)
>> on standaloneSaved pFolderSavedIn
>> if the cRevStandaloneSettings["MacOSX x86-64"] of this stack is true
>> then
>> answer "Do you want to notarize?" with "yes" or "No"
>> if it ="yes"
>> then
>> put pFolderSavedIN & "MacOSX/" & the cRevStandaloneSettings["name"] of this 
>> stack & ".app" into tAppBundle
>> notarizeApp tAppbundle
>> else
>> put "Don't notarize"
>> end if
>> end if
>> pass standalonesaved
>> end standaloneSaved
>> on notarizeApp tAppbundle
>>  put "Now notarizing..."   after message
>>  ##path to the notarizer Stack..
>> ## either use an absolute path
>> --go stack "/Users/matthias/Dropbox/My 
>> Livecode/Plugins/mrSignNotarizeHelperV2.livecode"
>> ##or if the helper stack is in the plugins folder
>> go stack revEnvironmentUserPluginsPath()&"/mrSignNotarizeHelperV2.livecode"
>> put tAppbundle into fld "appbundle" of cd 1 of stack "mrSignNotarizeHelperV2"
>> set the label of btn "action" of cd 1 of stack "mrSignNotarizeHelperV2" to 
>> "Codesign App, create & codesign DMG, then notarize DMG and staple DMG and 
>> App"
>> set the hilite of btn "debugmode" of cd 1 of stack "mrSignNotarizeHelperV2" 
>> to false
>> send "mouseup" to btn "start" of cd 1 of stack "mrSignNotarizeHelperV2" in 5 
>> seconds
>> end notarizeApp
>> -
>> Matthias Rebbe
>> Life Is Too Short For Boring Code
>>> Am 13.04.2021 um 21:03 schrieb J. Landman Gay via use-livecode 
>>> :
>>> 
>>> On 4/13/21 10:43 AM, Keith Martin via use-livecode wrote:
> On 13 Apr 2021, at 11:28, Andre Garzia via 
> use-livecode  wrote:
> 
> On the other hand, I think that the SB should create standalones that can 
> actually be deployed, this means that it should be able to handle 
> notarisation on the mac out-of-the-box.
 Oh boy, THIS!
>>> 
>>> +1. But for now I use Matthias' mrSignNotarize helper tool which makes the 
>>> process much easier. Fill out some info, click a button, and your 
>>> notarization request is sent to Apple, returned, and stapled to your app.
>>> 
>>> It's an extra step which I think LC should incorporate, but for now it 
>>> saves quite a bit of work. You can find it at this LC lesson, which 
>>> includes all the manual steps if you want to do it that way, but at the 
>>> bottom describes his automated tool as well. You can download the stack 
>>> from the link at the top of the lesson.
>>> 
>>> 
>>> 
>>> I've used it on more than one Mac app and it works. The hardest part is 
>>> dealing with Apple and of course there's no help for that.
>>> 
>>> -- 
>>> Jacqueline Landman Gay | jac...@hyperactivesw.com
>>> HyperActive Software   | http://www.hyperactivesw.com
>>> 
>>> ___
>>> use-livecode mailing list
>>> use-livecode@lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your 
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> ___
>> 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
> 
> 
> -- 
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com
> 
> ___
> use-livecode 

Re: We don't need a Player (was Re: New(?) Idea for Standalones)

[J. Landman Gay via use-livecode]

Cool. Thanks. I do keep NotarizationHelper in my plugins folder since I use it 
frequently.

I probably will continue with the manual method for a while though, since I have three 
different apps to notarize and I have to update the General settings each time. Maybe later 
I'll revise your script to fill in the data for me.


What I did not realize until I wasted a lot of time today is that the ASC changes depending on 
the app password, the ID Application, or something else I can't identify. It kept telling me I 
wasn't a member of my own developer account. I finally ran the Terminal command that returns 
all the ASCs and my ASC was different than it was before.


People who are a member of only one account won't have that problem, but it took me a long time 
to figure out what was wrong. Once I had the right ASC your helper did its work gracefully.



On 4/13/21 2:17 PM, matthias rebbe via use-livecode wrote:

Jacque,
and if put the that NotarizerHelperStack into the plugins folder and if you add 
the below code  to your stack script
then you can directly code sign and notarize the created macOS standalone right 
after it was built. ;)

on standaloneSaved pFolderSavedIn

if the cRevStandaloneSettings["MacOSX x86-64"] of this stack is true

then

answer "Do you want to notarize?" with "yes" or "No"

if it ="yes"

then

put pFolderSavedIN & "MacOSX/" & the cRevStandaloneSettings["name"] of this stack & 
".app" into tAppBundle

notarizeApp tAppbundle

else

put "Don't notarize"

end if

end if

pass standalonesaved

end standaloneSaved


on notarizeApp tAppbundle
  put "Now notarizing..."   after message

  ##path to the notarizer Stack..
## either use an absolute path
--go stack "/Users/matthias/Dropbox/My 
Livecode/Plugins/mrSignNotarizeHelperV2.livecode"

##or if the helper stack is in the plugins folder
go stack revEnvironmentUserPluginsPath()&"/mrSignNotarizeHelperV2.livecode"

put tAppbundle into fld "appbundle" of cd 1 of stack "mrSignNotarizeHelperV2"

set the label of btn "action" of cd 1 of stack "mrSignNotarizeHelperV2" to "Codesign 
App, create & codesign DMG, then notarize DMG and staple DMG and App"

set the hilite of btn "debugmode" of cd 1 of stack "mrSignNotarizeHelperV2" to 
false

send "mouseup" to btn "start" of cd 1 of stack "mrSignNotarizeHelperV2" in 5 
seconds

end notarizeApp



-
Matthias Rebbe
Life Is Too Short For Boring Code


Am 13.04.2021 um 21:03 schrieb J. Landman Gay via use-livecode 
:

On 4/13/21 10:43 AM, Keith Martin via use-livecode wrote:

On 13 Apr 2021, at 11:28, Andre Garzia via 
use-livecode  wrote:

On the other hand, I think that the SB should create standalones that can 
actually be deployed, this means that it should be able to handle notarisation 
on the mac out-of-the-box.

Oh boy, THIS!


+1. But for now I use Matthias' mrSignNotarize helper tool which makes the 
process much easier. Fill out some info, click a button, and your notarization 
request is sent to Apple, returned, and stapled to your app.

It's an extra step which I think LC should incorporate, but for now it saves 
quite a bit of work. You can find it at this LC lesson, which includes all the 
manual steps if you want to do it that way, but at the bottom describes his 
automated tool as well. You can download the stack from the link at the top of 
the lesson.



I've used it on more than one Mac app and it works. The hardest part is dealing 
with Apple and of course there's no help for that.

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

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


___
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




--
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: We don't need a Player (was Re: New(?) Idea for Standalones)

[matthias rebbe via use-livecode]

Jacque,
and if put the that NotarizerHelperStack into the plugins folder and if you add 
the below code  to your stack script 
then you can directly code sign and notarize the created macOS standalone right 
after it was built. ;)

on standaloneSaved pFolderSavedIn

if the cRevStandaloneSettings["MacOSX x86-64"] of this stack is true

then

answer "Do you want to notarize?" with "yes" or "No"

if it ="yes"

then

put pFolderSavedIN & "MacOSX/" & the cRevStandaloneSettings["name"] of this 
stack & ".app" into tAppBundle

notarizeApp tAppbundle

else

put "Don't notarize"

end if

end if

pass standalonesaved

end standaloneSaved


on notarizeApp tAppbundle
 put "Now notarizing..."   after message

 ##path to the notarizer Stack..
## either use an absolute path
--go stack "/Users/matthias/Dropbox/My 
Livecode/Plugins/mrSignNotarizeHelperV2.livecode"

##or if the helper stack is in the plugins folder
go stack revEnvironmentUserPluginsPath()&"/mrSignNotarizeHelperV2.livecode"

put tAppbundle into fld "appbundle" of cd 1 of stack "mrSignNotarizeHelperV2"

set the label of btn "action" of cd 1 of stack "mrSignNotarizeHelperV2" to 
"Codesign App, create & codesign DMG, then notarize DMG and staple DMG and App"

set the hilite of btn "debugmode" of cd 1 of stack "mrSignNotarizeHelperV2" to 
false

send "mouseup" to btn "start" of cd 1 of stack "mrSignNotarizeHelperV2" in 5 
seconds

end notarizeApp



-
Matthias Rebbe
Life Is Too Short For Boring Code

> Am 13.04.2021 um 21:03 schrieb J. Landman Gay via use-livecode 
> :
> 
> On 4/13/21 10:43 AM, Keith Martin via use-livecode wrote:
>>> On 13 Apr 2021, at 11:28, Andre Garzia via 
>>> use-livecode  wrote:
>>> 
>>> On the other hand, I think that the SB should create standalones that can 
>>> actually be deployed, this means that it should be able to handle 
>>> notarisation on the mac out-of-the-box.
>> Oh boy, THIS!
> 
> +1. But for now I use Matthias' mrSignNotarize helper tool which makes the 
> process much easier. Fill out some info, click a button, and your 
> notarization request is sent to Apple, returned, and stapled to your app.
> 
> It's an extra step which I think LC should incorporate, but for now it saves 
> quite a bit of work. You can find it at this LC lesson, which includes all 
> the manual steps if you want to do it that way, but at the bottom describes 
> his automated tool as well. You can download the stack from the link at the 
> top of the lesson.
> 
> 
> 
> I've used it on more than one Mac app and it works. The hardest part is 
> dealing with Apple and of course there's no help for that.
> 
> -- 
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
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: We don't need a Player (was Re: New(?) Idea for Standalones)

[J. Landman Gay via use-livecode]

On 4/13/21 10:43 AM, Keith Martin via use-livecode wrote:

On 13 Apr 2021, at 11:28, Andre Garzia via 
use-livecode  wrote:

On the other hand, I think that the SB should create standalones that can 
actually be deployed, this means that it should be able to handle notarisation 
on the mac out-of-the-box.


Oh boy, THIS!


+1. But for now I use Matthias' mrSignNotarize helper tool which makes the process much easier. 
Fill out some info, click a button, and your notarization request is sent to Apple, returned, 
and stapled to your app.


It's an extra step which I think LC should incorporate, but for now it saves quite a bit of 
work. You can find it at this LC lesson, which includes all the manual steps if you want to do 
it that way, but at the bottom describes his automated tool as well. You can download the stack 
from the link at the top of the lesson.




I've used it on more than one Mac app and it works. The hardest part is dealing with Apple and 
of course there's no help for that.


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

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

Re: We don't need a Player (was Re: New(?) Idea for Standalones)

[Keith Martin via use-livecode]

> On 13 Apr 2021, at 11:28, Andre Garzia via use-livecode 
>  wrote:
> 
> On the other hand, I think that the SB should create standalones that can 
> actually be deployed, this means that it should be able to handle 
> notarisation on the mac out-of-the-box.


Oh boy, THIS! And everything Richard’s written in this thread.

I’ve come to dread the process of making a deployable standalone, to the point 
where I actively avoid it. It’s a major PITA and headache inducer. This really 
is putting me off using LiveCode. I’m not saying ‘in preference to something 
else,’ just that the experience has become so convoluted and opaque that I work 
to avoid having to do it.

I’m sure others feel similarly, and that is a Very Not Good Thing for LiveCode.

:’(

k

---
Keith Martin
Mobile: +44 (0)7909 541365
360 media production, consultancy and training: PanoramaPhotographer.com
Exif Fixer 360 utility: ExifFixer.com
About me: thatkeith.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: We don't need a Player (was Re: New(?) Idea for Standalones)

[Ken Ray via use-livecode]

> On Apr 13, 2021, at 5:28 AM, Andre Garzia via use-livecode 
>  wrote:
> 
> I like all that I read here. There are things that are really hard when 
> building standalone apps that I don’t think should be handled by LC HQ, such 
> as “adding AppleScript dictionary” to your app. This is harder than it seems 
> and it involves plist manipulation, fancy sdef xml creation, etc. This is too 
> large a product to develop with a small target base.
> 
> On the other hand, I think that the SB should create standalones that can 
> actually be deployed, this means that it should be able to handle 
> notarisation on the mac out-of-the-box.

Amen, brother! 

:)


Ken Ray
Sons of Thunder Software, Inc.
Email: k...@sonsothunder.com
Website: https://www.sonsothunder.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: We don't need a Player (was Re: New(?) Idea for Standalones)

[Andre Garzia via use-livecode]

I like all that I read here. There are things that are really hard when 
building standalone apps that I don’t think should be handled by LC HQ, such as 
“adding AppleScript dictionary” to your app. This is harder than it seems and 
it involves plist manipulation, fancy sdef xml creation, etc. This is too large 
a product to develop with a small target base.

On the other hand, I think that the SB should create standalones that can 
actually be deployed, this means that it should be able to handle notarisation 
on the mac out-of-the-box.

> On 29 Mar 2021, at 22:49, Trevor DeVore via use-livecode 
>  wrote:
> 
> On Mon, Mar 29, 2021 at 4:35 PM Richard Gaskin via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> 
> 
>> I think we're all on the same page here.
>> 
> 
> :thumbs_up
> 
> -- 
> Trevor DeVore
> ScreenSteps
> www.screensteps.com
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
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: We don't need a Player (was Re: New(?) Idea for Standalones)

[Trevor DeVore via use-livecode]

On Mon, Mar 29, 2021 at 4:35 PM Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:


> I think we're all on the same page here.
>

:thumbs_up

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

Re: We don't need a Player (was Re: New(?) Idea for Standalones)

[Richard Gaskin via use-livecode]

Trevor DeVore wrote:

> We agree that LiveCode should include a sensible baseline for building
> a standalone. We also agree that they shouldn't try to write solutions
> for all possible ways that someone may need to distribute a
> standalone. My 2 cents is that LiveCode should provide a way for 3rd
> parties to expand on what happens when a standalone is being built.
> This is more than just turning off an option. Turning off an option
> would introduce an absence of behavior. I'm suggesting the addition of
> behavior that can occur during key points of the standalone building
> process.

Yeah, in my effort to try to minimize my TL/DRs I didn't include a 
detailed specification, using colloquialism where more precision may 
have been useful.


I'm assuming they'd do something similar to what we have now with the 
pre- and post-build messages.  When we consider those, the Plugins 
subsystem, pubsub, and the vast range of other IDE hooks, I feel pretty 
confident that they wouldn't suddenly change direction and make a 
locked-down hookless solution on this one.



> Perhaps all use cases can adequately be handled with the messages that
> are already sent once when a standalone builder finishes (e.g.
> savingStandalone and standaloneSaved).
>
> But, perhaps the standalone building process would be better served
> with additional, more granular callbacks, and maybe those callbacks
> are sent to a target other than the stack being saved. That is what
> I would like to be considered when modernizing the Standalone Builder.

Like that.


I think we're all on the same page here.

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

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

Re: We don't need a Player (was Re: New(?) Idea for Standalones)

[Trevor DeVore via use-livecode]

On Mon, Mar 29, 2021 at 3:56 PM Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
> Here's the bottom of the post you were replying to:
>
>   One suitable solution in the box is all that's needed,
>   with the option for folks to turn it off if they prefer
>   using any other of the infinite variety of all possible
>   solutions.
>
>
> So yeah, I don't much mind whether we call them "hooks" or "options" or
> even "doilies" as long as it supports the core need right out of the
> box, without penalizing deeply-experienced professionals with specific
> tool preferences.
>

We agree that LiveCode should include a sensible baseline for building a
standalone. We also agree that they shouldn't try to write solutions for
all possible ways that someone may need to distribute a standalone. My 2
cents is that LiveCode should provide a way for 3rd parties to expand on
what happens when a standalone is being built. This is more than just
turning off an option. Turning off an option would introduce an absence of
behavior. I'm suggesting the addition of behavior that can occur during key
points of the standalone building process.

Perhaps all use cases can adequately be handled with the messages that are
already sent once when a standalone builder finishes (e.g. savingStandalone
and standaloneSaved).

But, perhaps the standalone building process would be better served with
additional, more granular callbacks, and maybe those callbacks are sent to
a target other than the stack being saved. That is what I would like to be
considered when modernizing the Standalone Builder.

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

Re: We don't need a Player (was Re: New(?) Idea for Standalones)

[Richard Gaskin via use-livecode]

Trevor DeVore wrote:

> On Mon, Mar 29, 2021 at 1:24 PM Richard Gaskin wrote:
>
>> Trevor DeVore wrote:
>>
>>  > On Mon, Mar 29, 2021 at 12:31 PM Richard Gaskin wrote:
>>  >> Add-ons to the product experience can be a useful temporary
>>  >> workaround for long-time users, but if we step back and look
>>  >> at the gestalt of the user experience they're not a true
>>  >> solution.
>>  >>
>>  >
>>  > Do you think that LiveCode should have built in support for all of
>>  > the various installers such as DropDMG, InnoSetup, WIX, etc.?
>>
>> "All" is the biggest possible number, potentially infinite.  So
>> logically, of course the only answer is "no".
>
> And that is why I like hooks into the standalone building process :-)
>
> Provide the baseline solution but make it extensible so that
> developers who need more can integrate whatever they need into
> building a standalone. The less manual steps the better.

#GMTA

Here's the bottom of the post you were replying to:

 One suitable solution in the box is all that's needed,
 with the option for folks to turn it off if they prefer
 using any other of the infinite variety of all possible
 solutions.


So yeah, I don't much mind whether we call them "hooks" or "options" or 
even "doilies" as long as it supports the core need right out of the 
box, without penalizing deeply-experienced professionals with specific 
tool preferences.


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


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

Re: We don't need a Player (was Re: New(?) Idea for Standalones)

[Trevor DeVore via use-livecode]

On Mon, Mar 29, 2021 at 1:24 PM Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Trevor DeVore wrote:
>
>  > On Mon, Mar 29, 2021 at 12:31 PM Richard Gaskin wrote:
>  >> Add-ons to the product experience can be a useful temporary
>  >> workaround for long-time users, but if we step back and look
>  >> at the gestalt of the user experience they're not a true solution.
>  >>
>  >
>  > Do you think that LiveCode should have built in support for all of
>  > the various installers such as DropDMG, InnoSetup, WIX, etc.?
>
> "All" is the biggest possible number, potentially infinite.  So
> logically, of course the only answer is "no".
>

And that is why I like hooks into the standalone building process :-)

Provide the baseline solution but make it extensible so that developers who
need more can integrate whatever they need into building a standalone. The
less manual steps the better.

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

Re: We don't need a Player (was Re: New(?) Idea for Standalones)

[Richard Gaskin via use-livecode]

Trevor DeVore wrote:

> On Mon, Mar 29, 2021 at 12:31 PM Richard Gaskin wrote:
>> Add-ons to the product experience can be a useful temporary
>> workaround for long-time users, but if we step back and look
>> at the gestalt of the user experience they're not a true solution.
>>
>
> Do you think that LiveCode should have built in support for all of
> the various installers such as DropDMG, InnoSetup, WIX, etc.?

"All" is the biggest possible number, potentially infinite.  So 
logically, of course the only answer is "no".


DMGs are native to the OS, as is the AppleScript used to automate making 
them look attractive.


LC has a reasonably nice Windows installer framework, which we all use 
every time we install LC.


I don't think anyone here is expecting LC or any other tool vendor to 
provide all possible solutions to a given problem.


One suitable solution in the box is all that's needed, with the option 
for folks to turn it off if they prefer using any other of the infinite 
variety of all possible solutions.


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

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

Re: We don't need a Player (was Re: New(?) Idea for Standalones)

[Trevor DeVore via use-livecode]

On Mon, Mar 29, 2021 at 12:31 PM Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Trevor DeVore wrote:
>
>  > On Mon, Mar 29, 2021 at 10:57 AM Richard Gaskin wrote:
>  >
>  >> TL/DR:
>  >>
>  >> We don't need a generic player.
>  >>
>  >> What we need is an updated Standalone Builder, to provide
>  >> more complete tooling and better guidance for building a
>  >> modern standalone.
>  >
>  >
>  > An easy way to extend the standalone building process with plugins is
>  > a necessity IMO as well.
>
> Add-ons to the product experience can be a useful temporary workaround
> for long-time users, but if we step back and look at the gestalt of the
> user experience they're not a true solution.
>

Do you think that LiveCode should have built in support for all of the
various installers such as DropDMG, InnoSetup, WIX, etc.? You either have
to support all of them or provide a hook so the developer can extend the
process. Either that or require the developer to create their own
additional workflow for processing the standalone after the fact.

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

Re: We don't need a Player (was Re: New(?) Idea for Standalones)

[Richard Gaskin via use-livecode]

Trevor DeVore wrote:

> On Mon, Mar 29, 2021 at 10:57 AM Richard Gaskin wrote:
>
>> TL/DR:
>>
>> We don't need a generic player.
>>
>> What we need is an updated Standalone Builder, to provide
>> more complete tooling and better guidance for building a
>> modern standalone.
>
>
> An easy way to extend the standalone building process with plugins is
> a necessity IMO as well.

Add-ons to the product experience can be a useful temporary workaround 
for long-time users, but if we step back and look at the gestalt of the 
user experience they're not a true solution:



The problem is tooling and knowledge necessary but not found in the product.

Whether the third-parties delivering essential tools are OS vendors or 
community members, both require knowing where to hunt down the solution, 
set it up, and use it.


Either way it's not in the box, so many won't know where to find it, and 
most newcomers won't know it even exists.



Third-party plugins are ABSOLUTELY FANTASTIC for adding *supplemental 
capabilities and conveniences* to a product.


But they cannot be profitably relied on to provide a core requirement of 
a product's critical path of use.


When the product is a tool for building applications, nothing could be 
more integral to its mission than building standalones.


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


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

Re: We don't need a Player (was Re: New(?) Idea for Standalones)

[Trevor DeVore via use-livecode]

On Mon, Mar 29, 2021 at 10:57 AM Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> TL/DR:
>
> We don't need a generic player.
>
> What we need is an updated Standalone Builder, to provide more complete
> tooling and better guidance for building a modern standalone.
>

An easy way to extend the standalone building process with plugins is a
necessity IMO as well. For example, when packaging an app with Levure you
can add in Helpers to further customize the output generated when packaging
an app for distribution. In addition to handling signing, notarizing, and
stapling, one can generate a DMG using DropDMG, create an InnoSetup
installer script, creat a WIX installer script (creates a Windows installer
file that IT departments love), etc.

LiveCode doesn't need to build support for all of these in the SB, but it
should provide hooks so that plugins can further customize the process.

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

Re: We don't need a Player (was Re: New(?) Idea for Standalones)

[Brian Milby via use-livecode]

The days of distributing apps without a cost to the developer are unfortunately 
over (Mac/Win).  If you want someone to be able to open an app on their Mac 
without jumping through hoops, then you need to be a paid developer and do the 
sign/notarize dance.  LC could help automate parts of the process, but getting 
the certificates seems to require some manual steps.  First advanced session in 
LCG covered it last week (but since I don’t do it, I did not fully pay 
attention to all of the details).

Sent from my iPhone

> On Mar 29, 2021, at 12:38 PM, Roger Guay via use-livecode 
>  wrote:
> 
> YES . . . What he said!
> 
>> On Mar 29, 2021, at 8:55 AM, Richard Gaskin via use-livecode 
>>  wrote:
>> 
>> TL/DR:
>> 
>> We don't need a generic player.
>> 
>> What we need is an updated Standalone Builder, to provide more complete 
>> tooling and better guidance for building a modern standalone.
>> 
>> 
>> 
>> - more complete version 
>> 
>> 
>> Background
>> --
>> 
>> This thread, and many others like it, didn't start with a desire for a 
>> player.  That was merely a response to the challenges of building 
>> standalones.
>> 
>> Building standalones is the point of LiveCode, the culmination of everything 
>> in LC's user experience.
>> 
>> And it's become a pain point for most, early-prohibitive for some.
>> 
>> OS changes are of course not LC's fault.  But they are LC's opportunity, if 
>> the company wants to maintain its place as the easiest solution for making 
>> apps.
>> 
>> 
>> 
>> The Last Great Deployment Change
>> 
>> 
>> Back in the early days, the IDE's Standalone Builder didn't provide any 
>> support for document associations, creator codes, or other essentials we now 
>> take for granted.  It was expected we'd open some dev tool from Apple 
>> (ResEdit) to set those up.
>> 
>> LC Ltd recognized those steps were cumbersome, and often error-prone where 
>> they were being done at all.
>> 
>> So they took the time to completely redesign the Standalone Builder to 
>> include support for nearly every detail apps need for solid deployment.
>> 
>> 
>> 
>> The Next Great Deployment Change
>> 
>> 
>> Many if not most deployment tooling required by OSes are command-line apps, 
>> lending themselves well to being called from another program, such as LC's 
>> Standalone Builder.
>> 
>> Automate everything possible.
>> 
>> And where a step can't be automated, guidance and be provided, such as a 
>> direct link right in the SB's UI to the necessary steps for completing the 
>> process, laid out with sufficient clarity and detail to allow the user to 
>> complete the build with confidence.
>> 
>> If a standalone building step is essential, it needs to be handled in the 
>> Standalone Builder.
>> 
>> Use direct automation where possible, or a direct link in the UI to 
>> step-by-step instructions needed to complete the task.
>> 
>> 
>> 
>> The Business Case
>> -
>> As we've seen here and many other threads like it from time to time, as long 
>> as building a standalone in LC is characterized by confusion and dread, 
>> people will seek alternatives.
>> 
>> Any alternative either compromises LC's revenue model (based as it is around 
>> standalone licensing), or eliminates it (if LC is just as hard to use as 
>> anything else, why not use anything else?).
>> 
>> No option provides as much return on investment as focusing on updating the 
>> Standalone Builder to be as simple and graceful as it can possibly be.
>> 
>> LC has a strong advantage with its language, made a nearly unbeatable with 
>> its integrated GUI object model.
>> 
>> Bring deployment up to par with the rest of the experience, and LC has a 
>> chance for a good life ahead, slowing attrition rates while accelerating 
>> growth.
>> 
>> -- 
>> Richard Gaskin
>> Fourth World Systems
>> Software Design and Development for the Desktop, Mobile, and the Web
>> 
>> ambassa...@fourthworld.comhttp://www.FourthWorld.com
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
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: We don't need a Player (was Re: New(?) Idea for Standalones)

[Roger Guay via use-livecode]

YES . . . What he said!

> On Mar 29, 2021, at 8:55 AM, Richard Gaskin via use-livecode 
>  wrote:
> 
> TL/DR:
> 
> We don't need a generic player.
> 
> What we need is an updated Standalone Builder, to provide more complete 
> tooling and better guidance for building a modern standalone.
> 
> 
> 
> - more complete version 
> 
> 
> Background
> --
> 
> This thread, and many others like it, didn't start with a desire for a 
> player.  That was merely a response to the challenges of building standalones.
> 
> Building standalones is the point of LiveCode, the culmination of everything 
> in LC's user experience.
> 
> And it's become a pain point for most, early-prohibitive for some.
> 
> OS changes are of course not LC's fault.  But they are LC's opportunity, if 
> the company wants to maintain its place as the easiest solution for making 
> apps.
> 
> 
> 
> The Last Great Deployment Change
> 
> 
> Back in the early days, the IDE's Standalone Builder didn't provide any 
> support for document associations, creator codes, or other essentials we now 
> take for granted.  It was expected we'd open some dev tool from Apple 
> (ResEdit) to set those up.
> 
> LC Ltd recognized those steps were cumbersome, and often error-prone where 
> they were being done at all.
> 
> So they took the time to completely redesign the Standalone Builder to 
> include support for nearly every detail apps need for solid deployment.
> 
> 
> 
> The Next Great Deployment Change
> 
> 
> Many if not most deployment tooling required by OSes are command-line apps, 
> lending themselves well to being called from another program, such as LC's 
> Standalone Builder.
> 
> Automate everything possible.
> 
> And where a step can't be automated, guidance and be provided, such as a 
> direct link right in the SB's UI to the necessary steps for completing the 
> process, laid out with sufficient clarity and detail to allow the user to 
> complete the build with confidence.
> 
> If a standalone building step is essential, it needs to be handled in the 
> Standalone Builder.
> 
> Use direct automation where possible, or a direct link in the UI to 
> step-by-step instructions needed to complete the task.
> 
> 
> 
> The Business Case
> -
> As we've seen here and many other threads like it from time to time, as long 
> as building a standalone in LC is characterized by confusion and dread, 
> people will seek alternatives.
> 
> Any alternative either compromises LC's revenue model (based as it is around 
> standalone licensing), or eliminates it (if LC is just as hard to use as 
> anything else, why not use anything else?).
> 
> No option provides as much return on investment as focusing on updating the 
> Standalone Builder to be as simple and graceful as it can possibly be.
> 
> LC has a strong advantage with its language, made a nearly unbeatable with 
> its integrated GUI object model.
> 
> Bring deployment up to par with the rest of the experience, and LC has a 
> chance for a good life ahead, slowing attrition rates while accelerating 
> growth.
> 
> -- 
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> 
> ambassa...@fourthworld.comhttp://www.FourthWorld.com
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

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