Re: Zip file problem on Mac

[Neville Smythe via use-livecode]

I have submitting a report to QC (Bug 23698 
)

Thanks Matthias for clarifying that permissions are not correct in the archive. 
I can now add that the Linux archive has the same problem. The Windows archive 
created by revZip executes correctly.

So the problem is nothing to do with Apple. TheUnarchiver and Keka changing the 
permissions to what they think they ought to be sounds well-intentioned but 
highly problematic (what’s the meme for the opposite of an overprotective 
nanny? Busybody big sister?)

Your last comment caused me to realise that I have only changed very recently 
to automating the process of creating the zip files as a post-standalone 
build-process using revZip. Previously I created the zip files by hand, and my 
beta-tester uses Windows. Thought I was being clever. So the bug in the LC 
implementation may have been present for a long time.

Neville

> 
> Neville, i can confirm that behavior even under BigSur.
> 
> I've created a small standalone with LC 10DP3 on BigSur and created  2  zip 
> files  from the output folder using LC's zip library and using shell command 
> zip.
> 
> Running the shell command 'zipinfo' to analyse both zip files showed, that 
> the zip created with LC's zip library did not contain any executable 
> permissions while the zip created with macOS zip shell command did contain 
> the permissions.
> So it seems the LC's zip library does not store the permissions in the zip.
> 
> According to your comment about The Unarchiver. Yes, i can also confirm that 
> The Unarchiver and also Keka can extract the zip file created with LC and the 
> standalone in the extracted folder is executable again.
> But...
> As zipinfo did list all the files wihtout any executable permissions, i 
> unzipped the zip with the shell command 'unzip' and that standalone was not 
> executable again. All files showed exact those permissions that zipinfo 
> showed before.
> 
> So i assume the following: Keka and The Unarchive seem to correct file 
> permissions when they detect a folder structure that seems to be an app 
> bundle. But that's just an assumption.
> At least Keka seems to have such feature according to its change log Changes 
> in version 1.0.11 
> 
> 
> But anyway. The LC zip library ignores the permission when creating an 
> archive.  If this worked before with older versions of LC  i cannot say, as i 
> always used the zip shell command or tools like Keka.
> 
> 
> Matthias
> 
> 

___
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: Visual Dissolve Times

[Rick Harrison via use-livecode]

Hi Tore,

set the effectRate.. Cool!

Thanks Tore!

> On May 5, 2022, at 1:45 PM, Tore Nilsen via use-livecode 
>  wrote:
> 
> You can set the effectRate to speed up or down the visual effects. Lower 
> number increases the speed. Look it up in the Dictionary for more precise 
> explanation.
> 
> Best regards
> Tore Nilsen

___
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: Visual Dissolve Times

[Klaus major-k via use-livecode]

Hi Tore and Rick,

> Am 05.05.2022 um 19:45 schrieb Tore Nilsen via use-livecode 
> :
> 
> You can set the effectRate to speed up or down the visual effects. Lower 
> number increases the speed. Look it up in the Dictionary for more precise 
> explanation.

exactly!

The fact that "the effectrate" will only take effect with the "very slow" 
parameter is a bit mentally challenging however! :-D
...
set the effectrate to 500 
## millisecs
hide image 1 with visual effect dissolve VERY SLOW
## :-D
...

> Best regards
> Tore Nilsen
> 
>> 5. mai 2022 kl. 19:33 skrev Rick Harrison via use-livecode 
>> :
>> 
>> Greetings LiveCoders,
>> 
>> I was playing around with the visual dissolve effect
>> and I wanted to be able to specify an amount of
>> time for the effect.  In my case I wanted it to
>> do the effect in 0.75 seconds (3/4 of a second).
>> 
>> We only get choices of 
>> 
>> very fast
>> fast
>> normal
>> slow
>> very slow
>> 
>> When I tried the very fast setting, the 
>> fastest time I got was about 1 second.
>> 
>> Is there anyway to make it faster?
>> 
>> Thanks
>> 
>> Rick

Best

Klaus
> 

--
Klaus Major
https://www.major-k.de
https://www.major-k.de/bass
kl...@major-k.de


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

Re: Visual Dissolve Times

[Tore Nilsen via use-livecode]

You can set the effectRate to speed up or down the visual effects. Lower number 
increases the speed. Look it up in the Dictionary for more precise explanation.

Best regards
Tore Nilsen

> 5. mai 2022 kl. 19:33 skrev Rick Harrison via use-livecode 
> :
> 
> Greetings LiveCoders,
> 
> I was playing around with the visual dissolve effect
> and I wanted to be able to specify an amount of
> time for the effect.  In my case I wanted it to
> do the effect in 0.75 seconds (3/4 of a second).
> 
> We only get choices of 
> 
> very fast
> fast
> normal
> slow
> very slow
> 
> When I tried the very fast setting, the 
> fastest time I got was about 1 second.
> 
> Is there anyway to make it faster?
> 
> Thanks
> 
> Rick
> ___
> 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

Visual Dissolve Times

[Rick Harrison via use-livecode]

Greetings LiveCoders,

I was playing around with the visual dissolve effect
and I wanted to be able to specify an amount of
time for the effect.  In my case I wanted it to
do the effect in 0.75 seconds (3/4 of a second).

We only get choices of 

very fast
fast
normal
slow
very slow

When I tried the very fast setting, the 
fastest time I got was about 1 second.

Is there anyway to make it faster?

Thanks

Rick
___
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: Zip file problem on Mac

[panagiotis m via use-livecode]

Hello all,

This sounds like this enhancement request
https://quality.livecode.com/show_bug.cgi?id=9642

Kind regards,
Panos
--

On Thu, 5 May 2022 at 18:08, Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Open a bug report and I will +1 it.
>
> Bob S
>
>
> > On May 4, 2022, at 15:35 , matthias rebbe via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > Neville, i can confirm that behavior even under BigSur.
> >
> > I've created a small standalone with LC 10DP3 on BigSur and created  2
> zip files  from the output folder using LC's zip library and using shell
> command zip.
> >
> > Running the shell command 'zipinfo' to analyse both zip files showed,
> that the zip created with LC's zip library did not contain any executable
> permissions while the zip created with macOS zip shell command did contain
> the permissions.
> > So it seems the LC's zip library does not store the permissions in the
> zip.
> >
> > According to your comment about The Unarchiver. Yes, i can also confirm
> that The Unarchiver and also Keka can extract the zip file created with LC
> and the standalone in the extracted folder is executable again.
> > But...
> > As zipinfo did list all the files wihtout any executable permissions, i
> unzipped the zip with the shell command 'unzip' and that standalone was not
> executable again. All files showed exact those permissions that zipinfo
> showed before.
> >
> > So i assume the following: Keka and The Unarchive seem to correct file
> permissions when they detect a folder structure that seems to be an app
> bundle. But that's just an assumption.
> > At least Keka seems to have such feature according to its change log
> Changes in version 1.0.11 
> >
> >
> > But anyway. The LC zip library ignores the permission when creating an
> archive.  If this worked before with older versions of LC  i cannot say, as
> i always used the zip shell command or tools like Keka.
> >
> >
> > Matthias
> >
> >
> >> Am 04.05.2022 um 16:47 schrieb Neville Smythe via use-livecode <
> use-livecode@lists.runrev.com>:
> >>
> >> I distribute a Mac standalone via a zip file, created using
> revZipOpenArchive etc.
> >>
> >> This has worked fine until macOS Monterey or LiveCode 9.6.x
> >>
> >> Either a bug has been introduced into the revZip tools in 9.6.x, or I
> have a corrupted version, or the Mac Archive Utility has changed so as to
> make the rev zip tool fail. Can anyone verify the following?
> >>
> >> On my Mac, the Archive Utility in Monterey, which automagically unzips
> files when a zip file is downloaded by Safari or double-clicked, now unsets
> the execute bit on the application (more precisely, on the executable file
> in the bundle). Which means the user gets a “This application could not be
> opened”, with no options to continue, when they try to launch the unzipped
> app. A terminal savvy user can use chmod x+ to make the app launchable, but
> I can hardly expect the ordinary user to have to do that. The execute bit
> is definitely set in the archive, because TheUnarchiver, a free third party
> decompression tool, unzips the file leaving the app launchable. This also
> suggests that the problem is not in my code.
> >>
> >> I can see why Granny Apple might have thought this was a good idea,
> executables in zip files are a the major sources of trojans, but if Apple
> has made this change it is a bit nasty because there is no obvious way to
> override the behaviour.
> >>
> >> If I use the Archive Utility to actually create the zip file from the
> standalone app bundle rather than using the rev tools, and then
> double-click it to decompress, the file unzips with the execute bit set.
> This shows the archive produced by revZip is not the same as that expected
> by the Archive Utility. It also suggests  a workaround would be to use
> Archive Utility from a shell command (it is not AppleScriptable – bad
> Apple!). From a cursory search on Stackoverflow,  the command line would be
> (this is not yet tested and the post is 5 years old)
> >>
> >> ditto -c -k --sequesterRsrc --keepParent Product.app Product.app.zip
> >>
> >> to create the zip file for the Mac platform. The post says that is what
> the Archive Utility uses to compress files. Probably  the rev zip tools use
> zlib. Or maybe I should be creating a .dmg disk image instead of a zip file.
> >>
> >> 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: Zip file problem on Mac

[Bob Sneidar via use-livecode]

Open a bug report and I will +1 it. 

Bob S


> On May 4, 2022, at 15:35 , matthias rebbe via use-livecode 
>  wrote:
> 
> Neville, i can confirm that behavior even under BigSur.
> 
> I've created a small standalone with LC 10DP3 on BigSur and created  2  zip 
> files  from the output folder using LC's zip library and using shell command 
> zip.
> 
> Running the shell command 'zipinfo' to analyse both zip files showed, that 
> the zip created with LC's zip library did not contain any executable 
> permissions while the zip created with macOS zip shell command did contain 
> the permissions.
> So it seems the LC's zip library does not store the permissions in the zip.
> 
> According to your comment about The Unarchiver. Yes, i can also confirm that 
> The Unarchiver and also Keka can extract the zip file created with LC and the 
> standalone in the extracted folder is executable again.
> But...
> As zipinfo did list all the files wihtout any executable permissions, i 
> unzipped the zip with the shell command 'unzip' and that standalone was not 
> executable again. All files showed exact those permissions that zipinfo 
> showed before.
> 
> So i assume the following: Keka and The Unarchive seem to correct file 
> permissions when they detect a folder structure that seems to be an app 
> bundle. But that's just an assumption.
> At least Keka seems to have such feature according to its change log Changes 
> in version 1.0.11 
> 
> 
> But anyway. The LC zip library ignores the permission when creating an 
> archive.  If this worked before with older versions of LC  i cannot say, as i 
> always used the zip shell command or tools like Keka.
> 
> 
> Matthias
> 
> 
>> Am 04.05.2022 um 16:47 schrieb Neville Smythe via use-livecode 
>> :
>> 
>> I distribute a Mac standalone via a zip file, created using 
>> revZipOpenArchive etc.
>> 
>> This has worked fine until macOS Monterey or LiveCode 9.6.x 
>> 
>> Either a bug has been introduced into the revZip tools in 9.6.x, or I have a 
>> corrupted version, or the Mac Archive Utility has changed so as to make the 
>> rev zip tool fail. Can anyone verify the following?
>> 
>> On my Mac, the Archive Utility in Monterey, which automagically unzips files 
>> when a zip file is downloaded by Safari or double-clicked, now unsets the 
>> execute bit on the application (more precisely, on the executable file in 
>> the bundle). Which means the user gets a “This application could not be 
>> opened”, with no options to continue, when they try to launch the unzipped 
>> app. A terminal savvy user can use chmod x+ to make the app launchable, but 
>> I can hardly expect the ordinary user to have to do that. The execute bit is 
>> definitely set in the archive, because TheUnarchiver, a free third party 
>> decompression tool, unzips the file leaving the app launchable. This also 
>> suggests that the problem is not in my code.
>> 
>> I can see why Granny Apple might have thought this was a good idea, 
>> executables in zip files are a the major sources of trojans, but if Apple 
>> has made this change it is a bit nasty because there is no obvious way to 
>> override the behaviour.
>> 
>> If I use the Archive Utility to actually create the zip file from the 
>> standalone app bundle rather than using the rev tools, and then double-click 
>> it to decompress, the file unzips with the execute bit set. This shows the 
>> archive produced by revZip is not the same as that expected by the Archive 
>> Utility. It also suggests  a workaround would be to use Archive Utility from 
>> a shell command (it is not AppleScriptable – bad Apple!). From a cursory 
>> search on Stackoverflow,  the command line would be (this is not yet tested 
>> and the post is 5 years old)
>> 
>> ditto -c -k --sequesterRsrc --keepParent Product.app Product.app.zip
>> 
>> to create the zip file for the Mac platform. The post says that is what the 
>> Archive Utility uses to compress files. Probably  the rev zip tools use 
>> zlib. Or maybe I should be creating a .dmg disk image instead of a zip file.
>> 
>> 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

___
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