A poor man's app updater

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

A poor man's app updater

Skip Kimpel via use-livecode
I’ve written before about trying to include within a desktop app a check for updates, and a user-driven update action: I’ve looked a bit at Trevor’s incorporation of such a scheme in Levure, and independently at Sparkle (only for Macs), but I have never reached an encapsulated solution that works without leaving my LiveCode comfort zone. I just thought people might like to know what I’ve actually done to solve the problem - it’s primitive beyond belief to anyone who is happy to go outside the LCCZ, but it’s all I can do with very limited resources of intellect and time. I’d love to hear of a better solution (there must be one).

The app in question (only desktop right now) is a classic splash screen design, with the splash providing access to a licensing gateway and a script library, and everything else in another mainstack (let’s call it the Working Stack), which is not compiled but rather included as a file in the installed package as a template - a copy is made in a writeable area for working purposes when the program starts up for the first time. The app is installed via a web site, so there is a server we can use for stuff such as installers. This server includes a tiny text file which records the latest version number of the app.

When the app is initialised, it compares a version number built in to the Working Stack with the version number in the file on the server - of course if the program isn’t connected to the internet, this doesn’t take place.

If the comparison shows that there is a more recent version, the user is warned via a dialog and asked whether to ignore for now, ignore this particular update permanently, or to install the update. The “ignore this version” option updates a property in the Working Stack so the same warning isn’t repeated next time.

Now, here is the primitive bit: if the user selects the update option, he/she is invited to carry out the following sequence:

- quit the current version (actually this can of course be done automatically via an “OK” button);

- delete the current version using the facilities of the OS (just trash it from the Applications folder on a Mac, or use the Control Panel on Windows): there is no reliable way of doing this from within an LC standalone, AFAIK;

- download and run a special “Uninstall Helper” program that gets rid of the Working Stack in the writeable area, plus preference files and the like - I don’t see any way of making this happen automatically, since logically it needs to be done **after** the main program is deleted;

- use the information given at the time of purchase to download the appropriate installer from the server;

- reinstall the program and input the registration data from the original purchase.

Clunky ain’t in it, but so far I have not thought of a better solution.


Graham
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: A poor man's app updater

Skip Kimpel via use-livecode
On 3/18/18 6:44 AM, Graham Samuel via use-livecode wrote:
> Now, here is the primitive bit: if the user selects the update option, he/she is invited to carry out the following sequence:
>
> - quit the current version (actually this can of course be done automatically via an “OK” button);

I'd automate this. The fewer steps the user needs to follow, the better.

> - delete the current version using the facilities of the OS (just trash it from the Applications folder on a Mac, or use the Control Panel on Windows): there is no reliable way of doing this from within an LC standalone, AFAIK;

I think you'd benefit from distributing some type of installer. When the
user clicks the "OK" button, launch the URL of your web site where they
can download it. Matthias' LC installer is ready (and the signing
version is close to ready) so you could use that while staying within
the LC environment. It does all the work for you.

Users know how to use installers and many Windows users don't understand
anything else. There are more users than you think who don't know how to
find a file or where apps are stored on their drive. The OS and/or the
installer will manage older versions so you don't have to.

> - download and run a special “Uninstall Helper” program that gets rid of the Working Stack in the writeable area, plus preference files and the like - I don’t see any way of making this happen automatically, since logically it needs to be done **after** the main program is deleted;

Instead of a helper, I'd put some logic into your app itself. The
working stack would have a custom property with its current version
number. The standalone would check on launch if the working stack
exists, and if so, if its custom version property matches the one it
expects. If not, overwrite the existing one with the new one. The new
one could either be downloaded from the internet on demand, or stored as
a binary in a custom property of the standalone. Either way, overwriting
is just a matter of putting the binary content into the existing stack
file path on disk.

> - use the information given at the time of purchase to download the appropriate installer from the server;
>
> - reinstall the program and input the registration data from the original purchase.

So, it sounds like you are already using an installer. If so, they're
mostly done. I wouldn't remove the user registration file or
preferences; unless it's changed there's no reason to make the user find
their registration info again (and many will lose or misplace it, which
will increase support requests.)

The short summary: The user only has to click "OK", the app quits, and
the user is taken to a web site to download the update installer. Once
they launch that and run the install, everything else is automatic. On
first launch, the app replaces any necessary files.


--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: A poor man's app updater

Skip Kimpel via use-livecode
Thanks, Jacque, as usual your ideas are excellent. I’ll see what I can do to follow your advice and report back.

As ever, it’s one of those deployment things that I would imagine affects everyone who publishes an app that isn’t distributed via some app store, but it doesn’t seem a popular topic.

Graham
BTW, I certainly use installers, and they’re code-signed too, to simplify matters for users.

> On 18 Mar 2018, at 20:57, J. Landman Gay via use-livecode <[hidden email]> wrote:
>
> On 3/18/18 6:44 AM, Graham Samuel via use-livecode wrote:
>> Now, here is the primitive bit: if the user selects the update option, he/she is invited to carry out the following sequence:
>> - quit the current version (actually this can of course be done automatically via an “OK” button);
>
> I'd automate this. The fewer steps the user needs to follow, the better.
>
>> - delete the current version using the facilities of the OS (just trash it from the Applications folder on a Mac, or use the Control Panel on Windows): there is no reliable way of doing this from within an LC standalone, AFAIK;
>
> I think you'd benefit from distributing some type of installer. When the user clicks the "OK" button, launch the URL of your web site where they can download it. Matthias' LC installer is ready (and the signing version is close to ready) so you could use that while staying within the LC environment. It does all the work for you.
>
> Users know how to use installers and many Windows users don't understand anything else. There are more users than you think who don't know how to find a file or where apps are stored on their drive. The OS and/or the installer will manage older versions so you don't have to.
>
>> - download and run a special “Uninstall Helper” program that gets rid of the Working Stack in the writeable area, plus preference files and the like - I don’t see any way of making this happen automatically, since logically it needs to be done **after** the main program is deleted;
>
> Instead of a helper, I'd put some logic into your app itself. The working stack would have a custom property with its current version number. The standalone would check on launch if the working stack exists, and if so, if its custom version property matches the one it expects. If not, overwrite the existing one with the new one. The new one could either be downloaded from the internet on demand, or stored as a binary in a custom property of the standalone. Either way, overwriting is just a matter of putting the binary content into the existing stack file path on disk.
>
>> - use the information given at the time of purchase to download the appropriate installer from the server;
>> - reinstall the program and input the registration data from the original purchase.
>
> So, it sounds like you are already using an installer. If so, they're mostly done. I wouldn't remove the user registration file or preferences; unless it's changed there's no reason to make the user find their registration info again (and many will lose or misplace it, which will increase support requests.)
>
> The short summary: The user only has to click "OK", the app quits, and the user is taken to a web site to download the update installer. Once they launch that and run the install, everything else is automatic. On first launch, the app replaces any necessary files.
>
>
> --
> Jacqueline Landman Gay         |     [hidden email]
> HyperActive Software           |     http://www.hyperactivesw.com
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Smooth transition between stacks

Skip Kimpel via use-livecode
Folks:
This seems like it should be very easy, but I’m struggling.

I want, simply, to transition between stacks in a visually nice and clean way. I’m testing this out in the IDE, in livecode version 9.0.0 (Rc1) and I’m on Mac OS 10.13.3. I think I have a reasonable transition, but I want to close and remove the splash stack from memory. I can’t get it to do this. However, now I’m thinking that the splash stack will contain all of the code, and shouldn’t be purged. The project will have stacks for individual functions in the “Resources” folder.

How should I transition from one stack to another, and get the calling stack to leave memory when it’s launched the destination stack? My code won’t do it.

The splash stack has code like:

on mouseUp

put the short name of this stack into splashStackName

put splashStackName into appParams["splashStackName"]

put the filename of this stack into fName

set the itemdelimiter to "/"

delete the last item of fName

put "AppSetup-D3.livecode" into appSetupStackFileName

put "AppSetup-D3" into appSetupStackName

put appSetupStackName into appParams["appSetupStackName"]

put fName&"/"&appSetupStackFileName into stTarget

wait for 0 seconds with messages

go invisible to stack stTarget

send "doStackSetup "&splashStackName to stack appSetupStackName

end mouseUp


——The destination stack has this handler to initialize it.
on doStackSetup originStackName

put appParams["appSetupStackName"] into thisStack

set the rect of stack thisStack to the rect of stack originStackName

wait for 0 seconds with messages

show stack thisStack

send "doCloseThisStack "&stackName to me in 1 second

set the lockscreen to false

end doStackSetup


on doCloseThisStack

breakpoint

put "Start Earth Explorer" into stackName

set the destroyStack of stack stackName to true

close stack stackName

end doCloseThisStack



In the destination stack named appSetupStackName, I run code that accesses a database for configuration parameters. I don’t want the user to be required to click a button to initiate this process. I start it on an opencard handler.

I’ve fiddled with this way more time than I should have to. Does anyone have a nicely visual way of seamlessly going to another stack without screen flashing, windows jumping around, etc. I want the destination stack to just open in the same rect as the source stack.

I know that the opencard handler runs before the above mouseup code finishes.

Thanks for any advice.
Bill

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Smooth transition between stacks

Skip Kimpel via use-livecode
Folks:

I got it to remove the calling stack and have a clean transition. However, for a splash stack configuration with all of the stacks that do the main app functions, should I even try to delete the splash stack? Is it needed to run the application?

Best,
Bill



> On Mar 20, 2018, at 3:39 PM, William Prothero via use-livecode <[hidden email]> wrote:
>
> Folks:
> This seems like it should be very easy, but I’m struggling.
>
> I want, simply, to transition between stacks in a visually nice and clean way. I’m testing this out in the IDE, in livecode version 9.0.0 (Rc1) and I’m on Mac OS 10.13.3. I think I have a reasonable transition, but I want to close and remove the splash stack from memory. I can’t get it to do this. However, now I’m thinking that the splash stack will contain all of the code, and shouldn’t be purged. The project will have stacks for individual functions in the “Resources” folder.
>
> How should I transition from one stack to another, and get the calling stack to leave memory when it’s launched the destination stack? My code won’t do it.
>
> The splash stack has code like:
>
> on mouseUp
>
> put the short name of this stack into splashStackName
>
> put splashStackName into appParams["splashStackName"]
>
> put the filename of this stack into fName
>
> set the itemdelimiter to "/"
>
> delete the last item of fName
>
> put "AppSetup-D3.livecode" into appSetupStackFileName
>
> put "AppSetup-D3" into appSetupStackName
>
> put appSetupStackName into appParams["appSetupStackName"]
>
> put fName&"/"&appSetupStackFileName into stTarget
>
> wait for 0 seconds with messages
>
> go invisible to stack stTarget
>
> send "doStackSetup "&splashStackName to stack appSetupStackName
>
> end mouseUp
>
>
> ——The destination stack has this handler to initialize it.
> on doStackSetup originStackName
>
> put appParams["appSetupStackName"] into thisStack
>
> set the rect of stack thisStack to the rect of stack originStackName
>
> wait for 0 seconds with messages
>
> show stack thisStack
>
> send "doCloseThisStack "&stackName to me in 1 second
>
> set the lockscreen to false
>
> end doStackSetup
>
>
> on doCloseThisStack
>
> breakpoint
>
> put "Start Earth Explorer" into stackName
>
> set the destroyStack of stack stackName to true
>
> close stack stackName
>
> end doCloseThisStack
>
>
>
> In the destination stack named appSetupStackName, I run code that accesses a database for configuration parameters. I don’t want the user to be required to click a button to initiate this process. I start it on an opencard handler.
>
> I’ve fiddled with this way more time than I should have to. Does anyone have a nicely visual way of seamlessly going to another stack without screen flashing, windows jumping around, etc. I want the destination stack to just open in the same rect as the source stack.
>
> I know that the opencard handler runs before the above mouseup code finishes.
>
> Thanks for any advice.
> Bill
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

RE: Smooth transition between stacks

Skip Kimpel via use-livecode
My understanding is that the first stack has the engine, inclusions.... and needs to be in memory.

Ralph DiMola
IT Director
Evergreen Information Services
[hidden email]

-----Original Message-----
From: use-livecode [mailto:[hidden email]] On Behalf Of William Prothero via use-livecode
Sent: Tuesday, March 20, 2018 6:47 PM
To: Use-livecode Use-livecode
Cc: William Prothero
Subject: Re: Smooth transition between stacks

Folks:

I got it to remove the calling stack and have a clean transition. However, for a splash stack configuration with all of the stacks that do the main app functions, should I even try to delete the splash stack? Is it needed to run the application?

Best,
Bill



> On Mar 20, 2018, at 3:39 PM, William Prothero via use-livecode <[hidden email]> wrote:
>
> Folks:
> This seems like it should be very easy, but I’m struggling.
>
> I want, simply, to transition between stacks in a visually nice and clean way. I’m testing this out in the IDE, in livecode version 9.0.0 (Rc1) and I’m on Mac OS 10.13.3. I think I have a reasonable transition, but I want to close and remove the splash stack from memory. I can’t get it to do this. However, now I’m thinking that the splash stack will contain all of the code, and shouldn’t be purged. The project will have stacks for individual functions in the “Resources” folder.
>
> How should I transition from one stack to another, and get the calling stack to leave memory when it’s launched the destination stack? My code won’t do it.
>
> The splash stack has code like:
>
> on mouseUp
>
> put the short name of this stack into splashStackName
>
> put splashStackName into appParams["splashStackName"]
>
> put the filename of this stack into fName
>
> set the itemdelimiter to "/"
>
> delete the last item of fName
>
> put "AppSetup-D3.livecode" into appSetupStackFileName
>
> put "AppSetup-D3" into appSetupStackName
>
> put appSetupStackName into appParams["appSetupStackName"]
>
> put fName&"/"&appSetupStackFileName into stTarget
>
> wait for 0 seconds with messages
>
> go invisible to stack stTarget
>
> send "doStackSetup "&splashStackName to stack appSetupStackName
>
> end mouseUp
>
>
> ——The destination stack has this handler to initialize it.
> on doStackSetup originStackName
>
> put appParams["appSetupStackName"] into thisStack
>
> set the rect of stack thisStack to the rect of stack originStackName
>
> wait for 0 seconds with messages
>
> show stack thisStack
>
> send "doCloseThisStack "&stackName to me in 1 second
>
> set the lockscreen to false
>
> end doStackSetup
>
>
> on doCloseThisStack
>
> breakpoint
>
> put "Start Earth Explorer" into stackName
>
> set the destroyStack of stack stackName to true
>
> close stack stackName
>
> end doCloseThisStack
>
>
>
> In the destination stack named appSetupStackName, I run code that accesses a database for configuration parameters. I don’t want the user to be required to click a button to initiate this process. I start it on an opencard handler.
>
> I’ve fiddled with this way more time than I should have to. Does anyone have a nicely visual way of seamlessly going to another stack without screen flashing, windows jumping around, etc. I want the destination stack to just open in the same rect as the source stack.
>
> I know that the opencard handler runs before the above mouseup code finishes.
>
> Thanks for any advice.
> Bill
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Smooth transition between stacks

Skip Kimpel via use-livecode
In reply to this post by Skip Kimpel via use-livecode
If the splash stack will become the standalone then you can't delete it,
since it will contain the LC engine and any scripts that need to run. If
you could delete it, the app would quit without warning.

You can use "go stack x in this window" if you want the destination stack
to occupy the same window frame.

--
Jacqueline Landman Gay | [hidden email]
HyperActive Software | http://www.hyperactivesw.com
On March 20, 2018 5:48:57 PM William Prothero via use-livecode
<[hidden email]> wrote:

Folks:

I got it to remove the calling stack and have a clean transition. However,
for a splash stack configuration with all of the stacks that do the main
app functions, should I even try to delete the splash stack? Is it needed
to run the application?




_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Smooth transition between stacks

Skip Kimpel via use-livecode
hide splash stack after opening one time.

BR

    If the splash stack will become the standalone then you can't delete it,
    since it will contain the LC engine and any scripts that need to run. If
    you could delete it, the app would quit without warning.

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: A poor man's app updater

Skip Kimpel via use-livecode
In reply to this post by Skip Kimpel via use-livecode
Hi,

To raise the issue again of updating Mac and Windows apps, I’m referencing this thread between Graham and Jacqueline...

Can existing files in the user’s application directory be saved/modified/replaced by my application?

> On Mar 18, 2018, at 12:57 PM, J. Landman Gay via use-livecode <[hidden email]> wrote:
>
>> - delete the current version using the facilities of the OS (just trash it from the Applications folder on a Mac, or use the Control Panel on Windows): there is no reliable way of doing this from within an LC standalone, AFAIK;
>
> I think you'd benefit from distributing some type of installer. When the user clicks the "OK" button, launch the URL of your web site where they can download it. Matthias' LC installer is ready (and the signing version is close to ready) so you could use that while staying within the LC environment. It does all the work for you.


Can Livecode download a file and replace an existing file in the user’s Application package (Mac) or Program Files folder (Win), or does the OS block that?

I understand that the application itself would need to be replaced by a new installation, but can supporting files in the same installation directory be replaced while the parent LC standalone is still running without then having to later be restarted?

Is there any news on "Matthias' LC installer”?

>
> Users know how to use installers and many Windows users don't understand anything else. There are more users than you think who don't know how to find a file or where apps are stored on their drive. The OS and/or the installer will manage older versions so you don't have to.
>
>> - download and run a special “Uninstall Helper” program that gets rid of the Working Stack in the writeable area, plus preference files and the like - I don’t see any way of making this happen automatically, since logically it needs to be done **after** the main program is deleted;
>
> Instead of a helper, I'd put some logic into your app itself. The working stack would have a custom property with its current version number. The standalone would check on launch if the working stack exists, and if so, if its custom version property matches the one it expects. If not, overwrite the existing one with the new one. The new one could either be downloaded from the internet on demand, or stored as a binary in a custom property of the standalone. Either way, overwriting is just a matter of putting the binary content into the existing stack file path on disk.

Does this answer my updating files question?



>
>> - use the information given at the time of purchase to download the appropriate installer from the server;
>> - reinstall the program and input the registration data from the original purchase.
>
> So, it sounds like you are already using an installer. If so, they're mostly done. I wouldn't remove the user registration file or preferences; unless it's changed there's no reason to make the user find their registration info again (and many will lose or misplace it, which will increase support requests.)
>
> The short summary: The user only has to click "OK", the app quits, and the user is taken to a web site to download the update installer. Once they launch that and run the install, everything else is automatic. On first launch, the app replaces any necessary files.
>
>
> --
> Jacqueline Landman Gay         |     [hidden email]
> HyperActive Software           |     http://www.hyperactivesw.com

Peter Bogdanoff
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: A poor man's app updater

Skip Kimpel via use-livecode
On 8/3/2018 2:32 AM, Peter Bogdanoff via use-livecode wrote:
> Hi,
>
> To raise the issue again of updating Mac and Windows apps, I’m referencing this thread between Graham and Jacqueline...
>
> Can existing files in the user’s application directory be saved/modified/replaced by my application?
>

The accurate answer is that it all depends upon the permissions of the
account running the software. Typically for most personal or home
computers, the user has administrative privs, but that is increasingly
not the case on university or company owned computers. On these, they
may not have permission to alter files in the Program Files (Win) or
Applications (OSX) folders.

In some cases, again depending on OS and permissions, you can alter the
folders contents directly. In others you application must launch a
process (another app) with elevated privs, where the OS asks the user
for permissions for the elevated privs, and then that app (if allowed)
can make changes.


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: A poor man's app updater

Skip Kimpel via use-livecode
So, to store and access LC stacks and other files used by myApp that must be periodically updated, does it make sense to put them into

macOS—Library/Application Support/myApp
Win—user/AppData/myApp

rather than in Applications or Program Files?

Are there any restrictions or downside to this?

Peter

> On Aug 3, 2018, at 5:14 AM, Paul Dupuis via use-livecode <[hidden email]> wrote:
>
> On 8/3/2018 2:32 AM, Peter Bogdanoff via use-livecode wrote:
>> Hi,
>>
>> To raise the issue again of updating Mac and Windows apps, I’m referencing this thread between Graham and Jacqueline...
>>
>> Can existing files in the user’s application directory be saved/modified/replaced by my application?
>>
>
> The accurate answer is that it all depends upon the permissions of the
> account running the software. Typically for most personal or home
> computers, the user has administrative privs, but that is increasingly
> not the case on university or company owned computers. On these, they
> may not have permission to alter files in the Program Files (Win) or
> Applications (OSX) folders.
>
> In some cases, again depending on OS and permissions, you can alter the
> folders contents directly. In others you application must launch a
> process (another app) with elevated privs, where the OS asks the user
> for permissions for the elevated privs, and then that app (if allowed)
> can make changes.
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: A poor man's app updater

Skip Kimpel via use-livecode
/Library is going to have the same permission issue, but
/Users/username/Library... would be fine.

The down side is that the user can accidentally or intentionally mess with
stuff stored there more easily that something built into the app or stored
in the Applications/Program Files directories (although the Finder does
hide the Library folder in the go menu unless to hold down the option
key).  If it is more data related, then I think it is a great option.  For
code updates, I'll let others more experienced comment.

Brian

On Fri, Aug 3, 2018 at 7:29 PM, Peter Bogdanoff via use-livecode <
[hidden email]> wrote:

> So, to store and access LC stacks and other files used by myApp that must
> be periodically updated, does it make sense to put them into
>
> macOS—Library/Application Support/myApp
> Win—user/AppData/myApp
>
> rather than in Applications or Program Files?
>
> Are there any restrictions or downside to this?
>
> Peter
>
> > On Aug 3, 2018, at 5:14 AM, Paul Dupuis via use-livecode <
> [hidden email]> wrote:
> >
> > On 8/3/2018 2:32 AM, Peter Bogdanoff via use-livecode wrote:
> >> Hi,
> >>
> >> To raise the issue again of updating Mac and Windows apps, I’m
> referencing this thread between Graham and Jacqueline...
> >>
> >> Can existing files in the user’s application directory be
> saved/modified/replaced by my application?
> >>
> >
> > The accurate answer is that it all depends upon the permissions of the
> > account running the software. Typically for most personal or home
> > computers, the user has administrative privs, but that is increasingly
> > not the case on university or company owned computers. On these, they
> > may not have permission to alter files in the Program Files (Win) or
> > Applications (OSX) folders.
> >
> > In some cases, again depending on OS and permissions, you can alter the
> > folders contents directly. In others you application must launch a
> > process (another app) with elevated privs, where the OS asks the user
> > for permissions for the elevated privs, and then that app (if allowed)
> > can make changes.
> >
> >
> > _______________________________________________
> > use-livecode mailing list
> > [hidden email]
> > Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: A poor man's app updater

Skip Kimpel via use-livecode
In reply to this post by Skip Kimpel via use-livecode
With the increasing use of sandboxing on Operating Systems (i.e. very
limited access on iOS and Android that will eventually be included in
desktop OSes), I might suggest using specialFolderPath("documents") and
creating a directory structure in there, say of the form
<companyName>/<appname>/ and whatever else you need. Documents is
becoming the one and only place where a user has guaranteed permissions
to access the contents for both read and write.



On 8/3/2018 8:29 PM, Peter Bogdanoff via use-livecode wrote:

> So, to store and access LC stacks and other files used by myApp that must be periodically updated, does it make sense to put them into
>
> macOS—Library/Application Support/myApp
> Win—user/AppData/myApp
>
> rather than in Applications or Program Files?
>
> Are there any restrictions or downside to this?
>
> Peter
>
>> On Aug 3, 2018, at 5:14 AM, Paul Dupuis via use-livecode <[hidden email]> wrote:
>>
>> On 8/3/2018 2:32 AM, Peter Bogdanoff via use-livecode wrote:
>>> Hi,
>>>
>>> To raise the issue again of updating Mac and Windows apps, I’m referencing this thread between Graham and Jacqueline...
>>>
>>> Can existing files in the user’s application directory be saved/modified/replaced by my application?
>>>
>> The accurate answer is that it all depends upon the permissions of the
>> account running the software. Typically for most personal or home
>> computers, the user has administrative privs, but that is increasingly
>> not the case on university or company owned computers. On these, they
>> may not have permission to alter files in the Program Files (Win) or
>> Applications (OSX) folders.
>>
>> In some cases, again depending on OS and permissions, you can alter the
>> folders contents directly. In others you application must launch a
>> process (another app) with elevated privs, where the OS asks the user
>> for permissions for the elevated privs, and then that app (if allowed)
>> can make changes.
>>
>>
>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode



_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: A poor man's app updater

Skip Kimpel via use-livecode
In reply to this post by Skip Kimpel via use-livecode
Apple specifies that apps should store their app-related data in their own
folder inside Application Support, where you will always have permissions.
You can also store prefs in the Preferences folder but it's discouraged in
favor of App Support. LC has specialFolderPath("support") for that which
works for both Mac and Windows. It would match what you suggested.

--
Jacqueline Landman Gay | [hidden email]
HyperActive Software | http://www.hyperactivesw.com
On August 3, 2018 7:31:18 PM Peter Bogdanoff via use-livecode
<[hidden email]> wrote:

> So, to store and access LC stacks and other files used by myApp that must
> be periodically updated, does it make sense to put them into
>
> macOS—Library/Application Support/myApp
> Win—user/AppData/myApp
>
> rather than in Applications or Program Files?
>
> Are there any restrictions or downside to this?
>
> Peter
>
>> On Aug 3, 2018, at 5:14 AM, Paul Dupuis via use-livecode
>> <[hidden email]> wrote:
>>
>> On 8/3/2018 2:32 AM, Peter Bogdanoff via use-livecode wrote:
>>> Hi,
>>>
>>> To raise the issue again of updating Mac and Windows apps, I’m referencing
>>> this thread between Graham and Jacqueline...
>>>
>>> Can existing files in the user’s application directory be
>>> saved/modified/replaced by my application?
>>
>> The accurate answer is that it all depends upon the permissions of the
>> account running the software. Typically for most personal or home
>> computers, the user has administrative privs, but that is increasingly
>> not the case on university or company owned computers. On these, they
>> may not have permission to alter files in the Program Files (Win) or
>> Applications (OSX) folders.
>>
>> In some cases, again depending on OS and permissions, you can alter the
>> folders contents directly. In others you application must launch a
>> process (another app) with elevated privs, where the OS asks the user
>> for permissions for the elevated privs, and then that app (if allowed)
>> can make changes.
>>
>>
>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode




_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: A poor man's app updater

Skip Kimpel via use-livecode
In reply to this post by Skip Kimpel via use-livecode
Yes, specialFolderPath would be good to use.  On a desktop, I'm not sure
that I'd want non-user facing data stored in the documents location unless
you configure it to be hidden.  Windows and Mac both have "support" folders
defined.  "library" would be the place on iOS.  Android doesn't have one
that makes sense off hand (other than "documents").  Linux doesn't have one
specified either, but you have access to the entire user's home directory
("home").

On Fri, Aug 3, 2018 at 8:05 PM, Paul Dupuis via use-livecode <
[hidden email]> wrote:

> With the increasing use of sandboxing on Operating Systems (i.e. very
> limited access on iOS and Android that will eventually be included in
> desktop OSes), I might suggest using specialFolderPath("documents") and
> creating a directory structure in there, say of the form
> <companyName>/<appname>/ and whatever else you need. Documents is
> becoming the one and only place where a user has guaranteed permissions
> to access the contents for both read and write.
>
>
>
> On 8/3/2018 8:29 PM, Peter Bogdanoff via use-livecode wrote:
> > So, to store and access LC stacks and other files used by myApp that
> must be periodically updated, does it make sense to put them into
> >
> > macOS—Library/Application Support/myApp
> > Win—user/AppData/myApp
> >
> > rather than in Applications or Program Files?
> >
> > Are there any restrictions or downside to this?
> >
> > Peter
> >
> >> On Aug 3, 2018, at 5:14 AM, Paul Dupuis via use-livecode <
> [hidden email]> wrote:
> >>
> >> On 8/3/2018 2:32 AM, Peter Bogdanoff via use-livecode wrote:
> >>> Hi,
> >>>
> >>> To raise the issue again of updating Mac and Windows apps, I’m
> referencing this thread between Graham and Jacqueline...
> >>>
> >>> Can existing files in the user’s application directory be
> saved/modified/replaced by my application?
> >>>
> >> The accurate answer is that it all depends upon the permissions of the
> >> account running the software. Typically for most personal or home
> >> computers, the user has administrative privs, but that is increasingly
> >> not the case on university or company owned computers. On these, they
> >> may not have permission to alter files in the Program Files (Win) or
> >> Applications (OSX) folders.
> >>
> >> In some cases, again depending on OS and permissions, you can alter the
> >> folders contents directly. In others you application must launch a
> >> process (another app) with elevated privs, where the OS asks the user
> >> for permissions for the elevated privs, and then that app (if allowed)
> >> can make changes.
> >>
> >>
> >> _______________________________________________
> >> use-livecode mailing list
> >> [hidden email]
> >> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> >> http://lists.runrev.com/mailman/listinfo/use-livecode
> >
> > _______________________________________________
> > use-livecode mailing list
> > [hidden email]
> > Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: A poor man's app updater

Skip Kimpel via use-livecode
On Android, "documents" is sandboxed with the app, so isn't accessible
unless the device is rooted.

On 8/3/18 8:59 PM, Brian Milby via use-livecode wrote:

> Yes, specialFolderPath would be good to use.  On a desktop, I'm not sure
> that I'd want non-user facing data stored in the documents location unless
> you configure it to be hidden.  Windows and Mac both have "support" folders
> defined.  "library" would be the place on iOS.  Android doesn't have one
> that makes sense off hand (other than "documents").  Linux doesn't have one
> specified either, but you have access to the entire user's home directory
> ("home").
>
> On Fri, Aug 3, 2018 at 8:05 PM, Paul Dupuis via use-livecode <
> [hidden email]> wrote:
>
>> With the increasing use of sandboxing on Operating Systems (i.e. very
>> limited access on iOS and Android that will eventually be included in
>> desktop OSes), I might suggest using specialFolderPath("documents") and
>> creating a directory structure in there, say of the form
>> <companyName>/<appname>/ and whatever else you need. Documents is
>> becoming the one and only place where a user has guaranteed permissions
>> to access the contents for both read and write.
>>
>>
>>
>> On 8/3/2018 8:29 PM, Peter Bogdanoff via use-livecode wrote:
>>> So, to store and access LC stacks and other files used by myApp that
>> must be periodically updated, does it make sense to put them into
>>>
>>> macOS—Library/Application Support/myApp
>>> Win—user/AppData/myApp
>>>
>>> rather than in Applications or Program Files?
>>>
>>> Are there any restrictions or downside to this?
>>>
>>> Peter
>>>
>>>> On Aug 3, 2018, at 5:14 AM, Paul Dupuis via use-livecode <
>> [hidden email]> wrote:
>>>>
>>>> On 8/3/2018 2:32 AM, Peter Bogdanoff via use-livecode wrote:
>>>>> Hi,
>>>>>
>>>>> To raise the issue again of updating Mac and Windows apps, I’m
>> referencing this thread between Graham and Jacqueline...
>>>>>
>>>>> Can existing files in the user’s application directory be
>> saved/modified/replaced by my application?
>>>>>
>>>> The accurate answer is that it all depends upon the permissions of the
>>>> account running the software. Typically for most personal or home
>>>> computers, the user has administrative privs, but that is increasingly
>>>> not the case on university or company owned computers. On these, they
>>>> may not have permission to alter files in the Program Files (Win) or
>>>> Applications (OSX) folders.
>>>>
>>>> In some cases, again depending on OS and permissions, you can alter the
>>>> folders contents directly. In others you application must launch a
>>>> process (another app) with elevated privs, where the OS asks the user
>>>> for permissions for the elevated privs, and then that app (if allowed)
>>>> can make changes.
>>>>
>>>>
>>>> _______________________________________________
>>>> use-livecode mailing list
>>>> [hidden email]
>>>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>>
>>> _______________________________________________
>>> use-livecode mailing list
>>> [hidden email]
>>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>>
>>
>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>


--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: A poor man's app updater

Skip Kimpel via use-livecode
In reply to this post by Skip Kimpel via use-livecode
For sure don’t try to write updates to Applications on macOS, that requires permissions. Far better to treat them as app data and store in same place preferences get stored.

Kee Nethery

> On Aug 3, 2018, at 5:29 PM, Peter Bogdanoff via use-livecode <[hidden email]> wrote:
>
> So, to store and access LC stacks and other files used by myApp that must be periodically updated, does it make sense to put them into
>
> macOS—Library/Application Support/myApp
> Win—user/AppData/myApp
>
> rather than in Applications or Program Files?
>
> Are there any restrictions or downside to this?
>
> Peter
>
>> On Aug 3, 2018, at 5:14 AM, Paul Dupuis via use-livecode <[hidden email]> wrote:
>>
>> On 8/3/2018 2:32 AM, Peter Bogdanoff via use-livecode wrote:
>>> Hi,
>>>
>>> To raise the issue again of updating Mac and Windows apps, I’m referencing this thread between Graham and Jacqueline...
>>>
>>> Can existing files in the user’s application directory be saved/modified/replaced by my application?
>>>
>>
>> The accurate answer is that it all depends upon the permissions of the
>> account running the software. Typically for most personal or home
>> computers, the user has administrative privs, but that is increasingly
>> not the case on university or company owned computers. On these, they
>> may not have permission to alter files in the Program Files (Win) or
>> Applications (OSX) folders.
>>
>> In some cases, again depending on OS and permissions, you can alter the
>> folders contents directly. In others you application must launch a
>> process (another app) with elevated privs, where the OS asks the user
>> for permissions for the elevated privs, and then that app (if allowed)
>> can make changes.
>>
>>
>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode