Re: Resources folder on mac, and the good old days

2021-03-31 Thread Neville Smythe via use-livecode
Interesting, and clever!

But how do they do that? Since the app can’t be running at the time it is moved 
to the trash, the code can’t be in the app itself. Which means they must 
install *another piece of code*, probably a daemon, which is running all the 
time; which would be necessary anyway for a security watchdog of course. Then 
does this but of code  uninstall itself? Possible I guess, the daemon file 
itself is not open when it is running so it could be moved to the trash and the 
daemon wasn’t killed it would just stop running the next time you reboot.

Of course for an LC standalone to use such an uninstall strategy you would need 
and Installer; and I don’t think it is really appropriate to have an ordinary 
app to have a daemon running all the time.

> On 31 Mar 2021, at 9:42 pm, Keith Martin  wrote:
> 
> 
>> On Mar 29, 2021, at 11:22 PM, Neville Smythe via use-livecode 
>>  wrote:
>> 
>> 3. There is no need for Installer code, or more problematic, and with a 
>> whiff of sulphur to sensitive old-hand Mac user noses, an Uninstaller
> 
> Hah! Yes, uninstallers should ideally never be required. I'm testing a 
> selection of macOS security tools at the moment (for a magazine, not just for 
> fun!) and I really like how – to give the most recent example – Avira Free 
> Security and Avira Prime (with help from the OS of course) will ask, when the 
> app is moved to the trash, if they should take their system extensions with 
> them. Polite, civilised, Mac-like. 
> 
> Keith
> Keith Martin
> 360 media specialist http://PanoramaPhotographer.com 
> 
> Contact and info http://thatkeith.com 
> +44 (0)7909541365
> 
> 
> 
>> 

___
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: Resources folder on mac, and the good old days

2021-03-30 Thread Bob Sneidar via use-livecode
That is correct. On my Mac, I modify 2 of the data grid behaviors (still 
waiting on nested data grid behaviors LC) and I have to launch the new LC app 
first before I do so, otherwise I bork the app. Once I do I can happily modify 
the behaviors without an issue. Haven’t tried on the lates MacOS though.

Bob S


On Mar 29, 2021, at 6:19 PM, Brian Milby via use-livecode 
mailto:use-livecode@lists.runrev.com>> wrote:

Once I took a version of the LC IDE and edited one of the files in the package 
before opening it the first time.  It would not open and complained about being 
corrupt/modified/something (can’t recall exact message).

I trashed it and extracted a fresh copy.  I launched it once and then quit.  
Then I modified the file (actually a widget I believe).  LC opened fine this 
time.  So, at least a version or two ago (pre Catalina), the package contents 
were only verified as unchanged on first launch.

___
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: Resources folder on mac, and the good old days

2021-03-29 Thread Brian Milby via use-livecode
Once I took a version of the LC IDE and edited one of the files in the package 
before opening it the first time.  It would not open and complained about being 
corrupt/modified/something (can’t recall exact message).

I trashed it and extracted a fresh copy.  I launched it once and then quit.  
Then I modified the file (actually a widget I believe).  LC opened fine this 
time.  So, at least a version or two ago (pre Catalina), the package contents 
were only verified as unchanged on first launch.

Sent from my iPad

> On Mar 29, 2021, at 6:22 PM, Neville Smythe via use-livecode 
>  wrote:
> 
> 
> 
>> On 30 Mar 2021, at 12:44 am, use-livecode-requ...@lists.runrev.com wrote:
>> 
>> Unfortunately this has never been true on macOS X.
>> 
>> The Resources folder (which is in the macOS app bundle) should be 
>> treated as read-only…
> 
> Mark Waddingham chides me for saying it is OK to write to the Resources 
> folder in the app bundle on a Mac. Mark is, as ever absolutely correct. The 
> correct place for application support files is the Library/Applications 
> Support folder, and this has been the AppleGuideline for a very long time 
> (although I am not quite so sure about that *always* being the case..) I was 
> wrong, naughty, and I promise… Mea culpa, mea maxima culpa. I strongly advise 
> against this awful filthy and degrading practice.
> 
> Except m’lud (he said in a very small voice), may I offer some admittedly 
> post-hoc and flimsy excuses.
> 
> 1. The app in which I do this originates from the days before the Application 
> Support folder existed (I am pretty sure) and has grown like Topsy ever 
> since. It worked then, it still works now. With one big caveat: this is ad 
> hoc software, distributed to a small group of users (Colin: by all the usual 
> methods - server, email, DropBox… they all work to deliver a working app 
> without my having to renew my lapsed Apple Developer registration.) If I were 
> to commercialise the app and so notarise it, I would expect writing to the 
> Resources folder *not* to work, probably notarising keeps a checksum of the 
> whole app bundle not just the executable. Maybe this distinction between ad 
> hoc and notarised software is part of the confusion of this very confused 
> thread, to which I have regrettably added more confusion.
> 
> 2. It is a great convenience to my Mac users to be able to move their copy of 
> the app to another machine, or give it to a friend, without having to worry 
> about finding and transferring auxiliary files (unlike my linux users, who I 
> must advise to keep everything together in one directory).
> 
> 3. There is no need for Installer code, or more problematic, and with a whiff 
> of sulphur to sensitive old-hand Mac user noses, an Uninstaller. Again if I 
> were to commercialise the app, these would come with the territory of license 
> files etc.
> 
> 4. If my user wants to get at the auxiliary files, it is easy enough to 
> explain the arcane process of opening up the Contents of the bundle. 
> Explaining how to access the Library is only slightly more arcane, but I 
> really don’t want the uninitiated venturing into that dark scary and very 
> dangerous place .
> 
> So, readers, don’t do it. But keep it to yourself if you do. And it probably 
> won’t work in MacOS 17.6.
> 
> Finally on the problem of opening unsafe/unnotarised apps in recent MacOS, I 
> am afraid the discussion here has clearly only increased the confusion of the 
> original forum user. Surely best to refer to the definitive source, the Apple 
> Support documents which you can get by googling “How to open an unsafe app in 
> Big Sur” (or Catalina, or Mojave). The instructions from Apple are clear and 
> straightforward, unlike some tech forums which start off by talking about 
> using the terminal to turn off Gatekeeper. 
> 
> Neville
> 
> 
> 
> ___
> 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: Resources folder on mac, and the good old days

2021-03-29 Thread Neville Smythe via use-livecode


> On 30 Mar 2021, at 12:44 am, use-livecode-requ...@lists.runrev.com wrote:
> 
> Unfortunately this has never been true on macOS X.
> 
> The Resources folder (which is in the macOS app bundle) should be 
> treated as read-only…

Mark Waddingham chides me for saying it is OK to write to the Resources folder 
in the app bundle on a Mac. Mark is, as ever absolutely correct. The correct 
place for application support files is the Library/Applications Support folder, 
and this has been the AppleGuideline for a very long time (although I am not 
quite so sure about that *always* being the case..) I was wrong, naughty, and I 
promise… Mea culpa, mea maxima culpa. I strongly advise against this awful 
filthy and degrading practice.

Except m’lud (he said in a very small voice), may I offer some admittedly 
post-hoc and flimsy excuses.

1. The app in which I do this originates from the days before the Application 
Support folder existed (I am pretty sure) and has grown like Topsy ever since. 
It worked then, it still works now. With one big caveat: this is ad hoc 
software, distributed to a small group of users (Colin: by all the usual 
methods - server, email, DropBox… they all work to deliver a working app 
without my having to renew my lapsed Apple Developer registration.) If I were 
to commercialise the app and so notarise it, I would expect writing to the 
Resources folder *not* to work, probably notarising keeps a checksum of the 
whole app bundle not just the executable. Maybe this distinction between ad hoc 
and notarised software is part of the confusion of this very confused thread, 
to which I have regrettably added more confusion.

2. It is a great convenience to my Mac users to be able to move their copy of 
the app to another machine, or give it to a friend, without having to worry 
about finding and transferring auxiliary files (unlike my linux users, who I 
must advise to keep everything together in one directory).

3. There is no need for Installer code, or more problematic, and with a whiff 
of sulphur to sensitive old-hand Mac user noses, an Uninstaller. Again if I 
were to commercialise the app, these would come with the territory of license 
files etc.

4. If my user wants to get at the auxiliary files, it is easy enough to explain 
the arcane process of opening up the Contents of the bundle. Explaining how to 
access the Library is only slightly more arcane, but I really don’t want the 
uninitiated venturing into that dark scary and very dangerous place .

So, readers, don’t do it. But keep it to yourself if you do. And it probably 
won’t work in MacOS 17.6.

Finally on the problem of opening unsafe/unnotarised apps in recent MacOS, I am 
afraid the discussion here has clearly only increased the confusion of the 
original forum user. Surely best to refer to the definitive source, the Apple 
Support documents which you can get by googling “How to open an unsafe app in 
Big Sur” (or Catalina, or Mojave). The instructions from Apple are clear and 
straightforward, unlike some tech forums which start off by talking about using 
the terminal to turn off Gatekeeper. 

Neville



___
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: Resources folder on mac, and the good old days

2021-03-29 Thread David V Glasgow via use-livecode
I am following this with interest because, as I have previously lamented, I 
would like to give away apps to colleagues without the huge, incomprehensible 
headache of certificates, signing and notarising etc.

I want to make absolutely sure that I understand it correctly, that a player 
app which was enabled to run on a machine (either by user or the more formal 
method) could be designed to list and run any number of stacks distributed as 
stacks, and placed in a designated folder or sub folder.

If correct, doesn’t that:

A/  Enable distribution and updating of any LC ‘app’ simply by the prospective 
user dropping it into the correct folder?  (AKA ‘the good old days')

B/  Undermine the fundamental intention of certification in the first place?  
(Personally, I would trust Livecoders, and indeed often run posted stacks 
without a second thought, but what if Richmond* went over to the dark side?) 

Cheers

David G

* Selected not because I think he might, but because the idea is amusing
___
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: Resources folder on mac, and the good old days

2021-03-29 Thread Mark Waddingham via use-livecode

On 2021-03-29 03:13, Neville Smythe via use-livecode wrote:

you may already know this, but this will not work in a standalone!
We will surely not have write permissions in that folder!

As a workaround I would probably use -> specialfolderpath("temporary")
Or even write the text to -> the tempname



There is no problem writing to the resources folder. That’s the
logical place to put the user-changeable stack files for a standalone,
making the auxiliary files invisible to external fiddling by the user,
 which a Good Thing (although that does make the app look different on
Windows or Linux).


Unfortunately this has never been true on macOS X.

The Resources folder (which is in the macOS app bundle) should be 
treated as read-only...


This has always been true - the correct (Apple guideline compliant!) 
place to put files that are 'internal' to the app but created/modified 
at runtime and which should persist between restarts of the app is in 
the 'Application Support' folder - in a sub-folder which is named the 
same as the app's id (e.g. com.myapp.mycompany).


[ Apple guidance is here - 
 
]


The read-only ness of resources isn't strictly enforced - especially if 
the standalone is built on the machine it is run (app bundles downloaded 
from the internet, for example, have file attributes added which mark 
them as 'quarantined' - even if unpacked from a zip/archive)... However, 
you will notice some more 'unpleasant' effects, typically, if you move 
the standalone to another machine - these will range from prompt dialogs 
allowing access, to dialogs requesting root permission (if the user has 
put the standalone, say, in /Applications).


In contrast, I do not believe that writing to stuff under 'Application 
Support' ever produces a user-visible prompt dialog on any version of 
macOS.


Additionally, code-signing requirements are becoming more stringent over 
time - off the top of my head I can't remember whether codesign has 
started including non-executable resources in the signature - but as 
soon as it does (if it doesn't already), any signed and notarized app 
will break if any of the files in the app bundle are modified / removed 
/ added to.



As for the Good Old Days of free distribution to other Mac (desktop)
users, they haven’t gone. Apple is making it harder for the
uninitiated to find out how to open “unsafe” files, but they don't
keep it a secret. And while recent rumours abound  about unnotarized
apps not working at all on some future MacOS, it does seem unlikely
that will actually happen, and if they do that’s time for us all to
reboot to Linux.


Indeed, it is unlikely that Apple will ever completely stop unnotarized 
apps from running (although they keep changing what you have to toggle 
to enable right-click Open to open the app!) - but ensuring you use 
appropriate paths for temporary / private writable app files means the 
least friction for the user.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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