Date   

Re: Installer pkg built with Xcode 12.2 won't open in macOS 10.10 and 10.11

Jon Gotow
 

Seriously? I have to keep an Intel machine around just to do release builds that will run on older macOS versions? Is there any chance of getting SHA-1 checksums added in the Apple Silicon version of codesign if we file bugs?

- Jon

On Dec 7, 2020, at 7:20 PM, Jack Brindle via groups.io <jackbrindle=me.com@groups.io> wrote:

That is the issue! Your post jogged my memory. The older versions of macOS need SHA1, but the Apple Silicon version of macOS doesn’t do SHA-1. Apple switched over to SHA-256 several years ago, maintaining both in the system. But, it looks like they didn’t maintain the SHA-1 for Apple Silicon systems. It may be very important to keep an Intel Mac around to handle builds for the foreseeable future.


Re: Installer pkg built with Xcode 12.2 won't open in macOS 10.10 and 10.11

Jack Brindle
 

That is the issue! Your post jogged my memory. The older versions of macOS need SHA1, but the Apple Silicon version of macOS doesn’t do SHA-1. Apple switched over to SHA-256 several years ago, maintaining both in the system. But, it looks like they didn’t maintain the SHA-1 for Apple Silicon systems. It may be very important to keep an Intel Mac around to handle builds for the foreseeable future.

Jack.

On Dec 7, 2020, at 5:52 PM, Jon Gotow <gotow@stclairsoft.com> wrote:

On Dec 7, 2020, at 3:58 PM, Alex Zavatone via groups.io <zav=mac.com@groups.io> wrote:

Jon, have you been able to isolate the difference between the two executables?
OK - so I went back and re-signed a known-working build of the app on both machines, just to make sure there weren't any inadvertent build differences caused by building the app with two different versions of Xcode (12.2 on the DTK machine, 12.2 beta 3 on the MacBook Pro). After re-signing them, I zipped both copies of the app and uploaded them to a server, then downloaded them onto an old MacBook Pro running macOS 10.10 Yosemite.

As before, the copy of the app that was code-signed on the DTK machine is reported as damaged when I double-click it to run it on Yosemite, while the copy that was code-signed on my 15" MacBook Pro launches correctly on Yosemite. Both machines where I did the code signing were running macOS 11.1 beta (20C5061b). I checksummed /usr/bin/codesign and the executables on both machines are the same, though they're presumably running different code since codesign is a universal binary.

Using 'codesign -dvvv --deep <appname>.app' (full output below) reveals that the working copy of the app includes both sha1 and sha256 hashes, while the non-working one only includes a sha256 hash. So does Yosemite not like sha256?

- Jon



For completeness, here are the commands I used to sign the code:

codesign -f -s "Developer ID Application: St. Clair Software (7HK42V8R9D)" --timestamp -o runtime Go64.app/Contents/Frameworks/Sparkle.framework/Resources/Autoupdate.app
codesign -f -s "Developer ID Application: St. Clair Software (7HK42V8R9D)" --timestamp -o runtime Go64.app/Contents/Frameworks/Sparkle.framework
codesign -f -s "Developer ID Application: St. Clair Software (7HK42V8R9D)" --entitlements Go64.entitlements --timestamp -o runtime Go64.app

And here are the results of displaying the results with codesign:

----- Copy of Go64 that works on Yosemite -----
Executable=/Volumes/StClairSW/Downloads/codesign test/Go64-Good.app/Contents/MacOS/Go64
Identifier=com.stclairsoft.Go64
Format=app bundle with Mach-O universal (x86_64 arm64)
CodeDirectory v=20500 size=2560 flags=0x10000(runtime) hashes=69+7 location=embedded
Hash type=sha256 size=32
CandidateCDHash sha1=128f8fc1408c76dabe1875e3898c8c5b15c05746
CandidateCDHash sha256=11ce01c6847639cee4bd45b20f3aec69cc367f82
Hash choices=sha1,sha256
CDHash=11ce01c6847639cee4bd45b20f3aec69cc367f82
Signature size=9067
Authority=Developer ID Application: St. Clair Software (7HK42V8R9D)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=Dec 7, 2020 at 6:31:38 PM
Info.plist entries=27
TeamIdentifier=7HK42V8R9D
Runtime Version=11.0.0
Sealed Resources version=2 rules=13 files=48
Nested=Frameworks/Sparkle.framework
Nested=MacOS/Go64Search
Internal requirements count=1 size=180


----- Copy of Go64 that does not work on Yosemite -----
Executable=/Volumes/StClairSW/Downloads/codesign test/Go64-Bad.app/Contents/MacOS/Go64
Identifier=com.stclairsoft.Go64
Format=app bundle with Mach-O universal (x86_64 arm64)
CodeDirectory v=20500 size=2560 flags=0x10000(runtime) hashes=69+7 location=embedded
Hash type=sha256 size=32
CandidateCDHash sha256=3e39c465a06ea00880ac5b0d3c4aba523b70e49a
Hash choices=sha256
CDHash=3e39c465a06ea00880ac5b0d3c4aba523b70e49a
Signature size=8987
Authority=Developer ID Application: St. Clair Software (7HK42V8R9D)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=Dec 7, 2020 at 5:13:14 PM
Info.plist entries=27
TeamIdentifier=7HK42V8R9D
Runtime Version=11.0.0
Sealed Resources version=2 rules=13 files=48
Nested=Frameworks/Sparkle.framework
Nested=MacOS/Go64Search
Internal requirements count=1 size=180






Re: Installer pkg built with Xcode 12.2 won't open in macOS 10.10 and 10.11

Jon Gotow
 

On Dec 7, 2020, at 3:58 PM, Alex Zavatone via groups.io <zav=mac.com@groups.io> wrote:

Jon, have you been able to isolate the difference between the two executables?
OK - so I went back and re-signed a known-working build of the app on both machines, just to make sure there weren't any inadvertent build differences caused by building the app with two different versions of Xcode (12.2 on the DTK machine, 12.2 beta 3 on the MacBook Pro). After re-signing them, I zipped both copies of the app and uploaded them to a server, then downloaded them onto an old MacBook Pro running macOS 10.10 Yosemite.

As before, the copy of the app that was code-signed on the DTK machine is reported as damaged when I double-click it to run it on Yosemite, while the copy that was code-signed on my 15" MacBook Pro launches correctly on Yosemite. Both machines where I did the code signing were running macOS 11.1 beta (20C5061b). I checksummed /usr/bin/codesign and the executables on both machines are the same, though they're presumably running different code since codesign is a universal binary.

Using 'codesign -dvvv --deep <appname>.app' (full output below) reveals that the working copy of the app includes both sha1 and sha256 hashes, while the non-working one only includes a sha256 hash. So does Yosemite not like sha256?

- Jon



For completeness, here are the commands I used to sign the code:

codesign -f -s "Developer ID Application: St. Clair Software (7HK42V8R9D)" --timestamp -o runtime Go64.app/Contents/Frameworks/Sparkle.framework/Resources/Autoupdate.app
codesign -f -s "Developer ID Application: St. Clair Software (7HK42V8R9D)" --timestamp -o runtime Go64.app/Contents/Frameworks/Sparkle.framework
codesign -f -s "Developer ID Application: St. Clair Software (7HK42V8R9D)" --entitlements Go64.entitlements --timestamp -o runtime Go64.app

And here are the results of displaying the results with codesign:

----- Copy of Go64 that works on Yosemite -----
Executable=/Volumes/StClairSW/Downloads/codesign test/Go64-Good.app/Contents/MacOS/Go64
Identifier=com.stclairsoft.Go64
Format=app bundle with Mach-O universal (x86_64 arm64)
CodeDirectory v=20500 size=2560 flags=0x10000(runtime) hashes=69+7 location=embedded
Hash type=sha256 size=32
CandidateCDHash sha1=128f8fc1408c76dabe1875e3898c8c5b15c05746
CandidateCDHash sha256=11ce01c6847639cee4bd45b20f3aec69cc367f82
Hash choices=sha1,sha256
CDHash=11ce01c6847639cee4bd45b20f3aec69cc367f82
Signature size=9067
Authority=Developer ID Application: St. Clair Software (7HK42V8R9D)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=Dec 7, 2020 at 6:31:38 PM
Info.plist entries=27
TeamIdentifier=7HK42V8R9D
Runtime Version=11.0.0
Sealed Resources version=2 rules=13 files=48
Nested=Frameworks/Sparkle.framework
Nested=MacOS/Go64Search
Internal requirements count=1 size=180


----- Copy of Go64 that does not work on Yosemite -----
Executable=/Volumes/StClairSW/Downloads/codesign test/Go64-Bad.app/Contents/MacOS/Go64
Identifier=com.stclairsoft.Go64
Format=app bundle with Mach-O universal (x86_64 arm64)
CodeDirectory v=20500 size=2560 flags=0x10000(runtime) hashes=69+7 location=embedded
Hash type=sha256 size=32
CandidateCDHash sha256=3e39c465a06ea00880ac5b0d3c4aba523b70e49a
Hash choices=sha256
CDHash=3e39c465a06ea00880ac5b0d3c4aba523b70e49a
Signature size=8987
Authority=Developer ID Application: St. Clair Software (7HK42V8R9D)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=Dec 7, 2020 at 5:13:14 PM
Info.plist entries=27
TeamIdentifier=7HK42V8R9D
Runtime Version=11.0.0
Sealed Resources version=2 rules=13 files=48
Nested=Frameworks/Sparkle.framework
Nested=MacOS/Go64Search
Internal requirements count=1 size=180


Re: Installer pkg built with Xcode 12.2 won't open in macOS 10.10 and 10.11

Alex Zavatone
 

On Dec 7, 2020, at 4:19 PM, Jon Gotow <gotow@stclairsoft.com> wrote:

I've had similar problems when code-signing and notarizing an app using Xcode 12.2 on Big Sur.

On my DTK (Apple Silicon) machine running macOS 11.1 beta and Xcode 12.2, if I go through a standard build and notarization using the Xcode GUI, everything appears to be fine. The codesign and spctl commands report everything is fine when I run them on macOS 11 or 10.15 and the app launches as expected. However, on macOS 10.10, I get the error "the sealed resource directory is invalid" when I run spctl and the system refuses to launch the app, saying it's damaged.

However, if I build on my MacBook Pro running macOS 11.1 beta and Xcode 12 beta, the resulting app doesn't have any problems. I'll boot back into Big Sur and find out which Xcode 12 beta I'm running. In any case, I'm hesitant to update to Xcode 12.2 for fear my builds will no longer work on 10.10.

- Jon
Jon, have you been able to isolate the difference between the two executables?


On Dec 7, 2020, at 9:57 AM, Mark Allan <markjallan@gmail.com> wrote:

I have a script which Xcode runs as a post-action during the archive phase which takes my compiled app, and generates a signed .pkg installer file along with all the other elements of the app.

For the last few years this has worked fine, but for some reason I'm now unable to open the resulting pkg file on macOS 10.10 and 10.11. When I try to open the installer on the older OSes, I'm presented with the following error message:

Installer_signed.pkg can't be installed because its digital signature is invalid.
The package may have been corrupted or tampered with. Get a new copy of the package and try again.

The signature is valid and I can see this in macOS 11 and 10.15 when clicking the certificate icon in the upper right corner of the window, so I'm not sure what's going on.

Is anyone aware of any changes to pkgbuild and productbuild which might have caused this? The man pages don't reference anything new that might be relevant, so I'm stuck.





Re: Installer pkg built with Xcode 12.2 won't open in macOS 10.10 and 10.11

Jon Gotow
 

I've had similar problems when code-signing and notarizing an app using Xcode 12.2 on Big Sur.

On my DTK (Apple Silicon) machine running macOS 11.1 beta and Xcode 12.2, if I go through a standard build and notarization using the Xcode GUI, everything appears to be fine. The codesign and spctl commands report everything is fine when I run them on macOS 11 or 10.15 and the app launches as expected. However, on macOS 10.10, I get the error "the sealed resource directory is invalid" when I run spctl and the system refuses to launch the app, saying it's damaged.

However, if I build on my MacBook Pro running macOS 11.1 beta and Xcode 12 beta, the resulting app doesn't have any problems. I'll boot back into Big Sur and find out which Xcode 12 beta I'm running. In any case, I'm hesitant to update to Xcode 12.2 for fear my builds will no longer work on 10.10.

- Jon

On Dec 7, 2020, at 9:57 AM, Mark Allan <markjallan@gmail.com> wrote:

I have a script which Xcode runs as a post-action during the archive phase which takes my compiled app, and generates a signed .pkg installer file along with all the other elements of the app.

For the last few years this has worked fine, but for some reason I'm now unable to open the resulting pkg file on macOS 10.10 and 10.11. When I try to open the installer on the older OSes, I'm presented with the following error message:

Installer_signed.pkg can't be installed because its digital signature is invalid.
The package may have been corrupted or tampered with. Get a new copy of the package and try again.

The signature is valid and I can see this in macOS 11 and 10.15 when clicking the certificate icon in the upper right corner of the window, so I'm not sure what's going on.

Is anyone aware of any changes to pkgbuild and productbuild which might have caused this? The man pages don't reference anything new that might be relevant, so I'm stuck.


Re: Installer pkg built with Xcode 12.2 won't open in macOS 10.10 and 10.11

Alex Zavatone
 

Out of curiosity, do you have an older copy of the installer that works on those platforms?

You may be able to open it up and view the entitlements/config files and see the differences.

One option is to create a VM with one of those operating systems on it and install a version of Xcode that works on 10.10 and 10.11, then deliver these special case installers or create installers that work on that OS and see what the difference is.

I keep around old 50 GB VMWare images and old Xcode installers just in case.

Alex Zavatone

On Dec 7, 2020, at 3:21 PM, Mark Allan <markjallan@gmail.com> wrote:

Hey Ben,

Thanks for the suggestion. No I hadn't checked that tool...but I have now, and it says "YES" ie it's signed correctly, so unfortunately I'm no further forward.

Mark

On 7 Dec 2020, at 6:53 pm, Ben Kennedy <ben-groups@zygoat.ca> wrote:

Hey Mark,

I can't speak to what might be the problem, but I've been reading about code signing and notarization recently in an effort to better understand how it all works at a lower level, so I'm interested in what you find out.

TN2206 (https://developer.apple.com/library/archive/technotes/tn2206/_index.html) makes reference to using the `check-signature` tool (https://developer.apple.com/download/more/?=SignatureCheck) to validate package signatures. Have you tried that? Does it report anything useful?

-ben


On 7 Dec 2020, at 8:57 am, Mark Allan <markjallan@gmail.com> wrote:

Hi all,

I have a script which Xcode runs as a post-action during the archive phase which takes my compiled app, and generates a signed .pkg installer file along with all the other elements of the app.

For the last few years this has worked fine, but for some reason I'm now unable to open the resulting pkg file on macOS 10.10 and 10.11. When I try to open the installer on the older OSes, I'm presented with the following error message:

Installer_signed.pkg can't be installed because its digital signature is invalid.
The package may have been corrupted or tampered with. Get a new copy of the package and try again.

The signature is valid and I can see this in macOS 11 and 10.15 when clicking the certificate icon in the upper right corner of the window, so I'm not sure what's going on.

Is anyone aware of any changes to pkgbuild and productbuild which might have caused this? The man pages don't reference anything new that might be relevant, so I'm stuck.

Thanks
Mark













Re: Installer pkg built with Xcode 12.2 won't open in macOS 10.10 and 10.11

Jack Brindle
 

Which OS are you building on? There are reports of Big Sur builds having issues on early versions of the OS (pre Mojave, I believe).

Jack

On Dec 7, 2020, at 1:21 PM, Mark Allan <markjallan@gmail.com> wrote:

Hey Ben,

Thanks for the suggestion. No I hadn't checked that tool...but I have now, and it says "YES" ie it's signed correctly, so unfortunately I'm no further forward.

Mark

On 7 Dec 2020, at 6:53 pm, Ben Kennedy <ben-groups@zygoat.ca> wrote:

Hey Mark,

I can't speak to what might be the problem, but I've been reading about code signing and notarization recently in an effort to better understand how it all works at a lower level, so I'm interested in what you find out.

TN2206 (https://developer.apple.com/library/archive/technotes/tn2206/_index.html) makes reference to using the `check-signature` tool (https://developer.apple.com/download/more/?=SignatureCheck) to validate package signatures. Have you tried that? Does it report anything useful?

-ben


On 7 Dec 2020, at 8:57 am, Mark Allan <markjallan@gmail.com> wrote:

Hi all,

I have a script which Xcode runs as a post-action during the archive phase which takes my compiled app, and generates a signed .pkg installer file along with all the other elements of the app.

For the last few years this has worked fine, but for some reason I'm now unable to open the resulting pkg file on macOS 10.10 and 10.11. When I try to open the installer on the older OSes, I'm presented with the following error message:

Installer_signed.pkg can't be installed because its digital signature is invalid.
The package may have been corrupted or tampered with. Get a new copy of the package and try again.

The signature is valid and I can see this in macOS 11 and 10.15 when clicking the certificate icon in the upper right corner of the window, so I'm not sure what's going on.

Is anyone aware of any changes to pkgbuild and productbuild which might have caused this? The man pages don't reference anything new that might be relevant, so I'm stuck.

Thanks
Mark













Re: Installer pkg built with Xcode 12.2 won't open in macOS 10.10 and 10.11

Mark Allan
 

Hey Ben,

Thanks for the suggestion. No I hadn't checked that tool...but I have now, and it says "YES" ie it's signed correctly, so unfortunately I'm no further forward.

Mark

On 7 Dec 2020, at 6:53 pm, Ben Kennedy <ben-groups@zygoat.ca> wrote:

Hey Mark,

I can't speak to what might be the problem, but I've been reading about code signing and notarization recently in an effort to better understand how it all works at a lower level, so I'm interested in what you find out.

TN2206 (https://developer.apple.com/library/archive/technotes/tn2206/_index.html) makes reference to using the `check-signature` tool (https://developer.apple.com/download/more/?=SignatureCheck) to validate package signatures. Have you tried that? Does it report anything useful?

-ben


On 7 Dec 2020, at 8:57 am, Mark Allan <markjallan@gmail.com> wrote:

Hi all,

I have a script which Xcode runs as a post-action during the archive phase which takes my compiled app, and generates a signed .pkg installer file along with all the other elements of the app.

For the last few years this has worked fine, but for some reason I'm now unable to open the resulting pkg file on macOS 10.10 and 10.11. When I try to open the installer on the older OSes, I'm presented with the following error message:

Installer_signed.pkg can't be installed because its digital signature is invalid.
The package may have been corrupted or tampered with. Get a new copy of the package and try again.

The signature is valid and I can see this in macOS 11 and 10.15 when clicking the certificate icon in the upper right corner of the window, so I'm not sure what's going on.

Is anyone aware of any changes to pkgbuild and productbuild which might have caused this? The man pages don't reference anything new that might be relevant, so I'm stuck.

Thanks
Mark









Re: Installer pkg built with Xcode 12.2 won't open in macOS 10.10 and 10.11

Ben Kennedy
 

Hey Mark,

I can't speak to what might be the problem, but I've been reading about code signing and notarization recently in an effort to better understand how it all works at a lower level, so I'm interested in what you find out.

TN2206 (https://developer.apple.com/library/archive/technotes/tn2206/_index.html) makes reference to using the `check-signature` tool (https://developer.apple.com/download/more/?=SignatureCheck) to validate package signatures. Have you tried that? Does it report anything useful?

-ben

On 7 Dec 2020, at 8:57 am, Mark Allan <markjallan@gmail.com> wrote:

Hi all,

I have a script which Xcode runs as a post-action during the archive phase which takes my compiled app, and generates a signed .pkg installer file along with all the other elements of the app.

For the last few years this has worked fine, but for some reason I'm now unable to open the resulting pkg file on macOS 10.10 and 10.11. When I try to open the installer on the older OSes, I'm presented with the following error message:

Installer_signed.pkg can't be installed because its digital signature is invalid.
The package may have been corrupted or tampered with. Get a new copy of the package and try again.

The signature is valid and I can see this in macOS 11 and 10.15 when clicking the certificate icon in the upper right corner of the window, so I'm not sure what's going on.

Is anyone aware of any changes to pkgbuild and productbuild which might have caused this? The man pages don't reference anything new that might be relevant, so I'm stuck.

Thanks
Mark





Installer pkg built with Xcode 12.2 won't open in macOS 10.10 and 10.11

Mark Allan
 

Hi all,

I have a script which Xcode runs as a post-action during the archive phase which takes my compiled app, and generates a signed .pkg installer file along with all the other elements of the app.

For the last few years this has worked fine, but for some reason I'm now unable to open the resulting pkg file on macOS 10.10 and 10.11. When I try to open the installer on the older OSes, I'm presented with the following error message:

Installer_signed.pkg can't be installed because its digital signature is invalid.
The package may have been corrupted or tampered with. Get a new copy of the package and try again.

The signature is valid and I can see this in macOS 11 and 10.15 when clicking the certificate icon in the upper right corner of the window, so I'm not sure what's going on.

Is anyone aware of any changes to pkgbuild and productbuild which might have caused this? The man pages don't reference anything new that might be relevant, so I'm stuck.

Thanks
Mark


Re: How to interpret crash reason

dhoerl
 

The explanation on the crappy code is complex - but it has to do with code that scales a large image on background threads, then renders just a tiny piece of that. I think iOS gets overloaded - that code crashes my companies users occasionally, but I've never had it happen to me. So the image itself is fine, and a user who crashes may not get another crash for a long time, or never. Corrupted JPEG was a read herring. 

What I did want to share is that by breakpointing on the one C function that I saw allowed me to determine what piece of code was using that API - and it was just in one place!

David


Re: Stupid question for build schemes.

Chris Hanson
 

On Nov 12, 2020, at 12:40 PM, Alex Zavatone via groups.io <zav@...> wrote:

These things.  When you open a target’s Scheme editor, these term for all of the things on the left that the scheme can change the settings for.

The things in the pop-up in the toolbar are schemes and destinations, not targets.

Schemes have actions. The topmost action, “Build” is really more like a meta-action though—it lets you specify information that’s used by all the other actions.

  — Chris


Re: How to interpret crash reason

Alex Zavatone
 

Great!  Any idea what the underlying cause was?  Was it reproducible with certain images, colorspaces, etc?

On Nov 17, 2020, at 12:55 PM, dhoerl via groups.io <dhoerl@...> wrote:

Thanks to all who replied to this. The weird thing was that it only happens infrequently  - a user gets it then doesn't for a long time.

So I had an idea - breakpoint on FigPhotoJPEGCreateIOSurfaceFromJPEG - this is an Apple C function in the MediaToolbox. Now, I can at least see what code is using that method, and gee - it turns out to be a piece of code already flagged as buggy!

Just thought I'd share.

David


Re: How to interpret crash reason

dhoerl
 

Thanks to all who replied to this. The weird thing was that it only happens infrequently  - a user gets it then doesn't for a long time.

So I had an idea - breakpoint on FigPhotoJPEGCreateIOSurfaceFromJPEG - this is an Apple C function in the MediaToolbox. Now, I can at least see what code is using that method, and gee - it turns out to be a piece of code already flagged as buggy!

Just thought I'd share.

David


Re: NSTableView Issues

Peter Hudson
 

Thanks Quincey. 

On 14 Nov 2020, at 22:00, Quincey Morris <quinceymorris@...> wrote:

https://developer.apple.com/documentation/appkit/nstableview/3622475-style

Editorial comment: It’s really a good idea to watch WWDC videos each year, to be aware of changes like this.

On Nov 14, 2020, at 13:29 , Peter Hudson via groups.io <Peter.hudson@...> wrote:

xCode 11 on Catalina -  I set the background color of rows in my table view - the color goes right to the edge of the table view.

xCode 12.3 beta on Big Sur - I set the background color of rows in my table view - the system leaves a white margin down each side of the table view - about 3mm or so wide.

This is older code, hence using cells in the table not views.

I want the color in my table view rows to go right to the edge of the table.


Re: NSTableView Issues

Quincey Morris
 

https://developer.apple.com/documentation/appkit/nstableview/3622475-style

Editorial comment: It’s really a good idea to watch WWDC videos each year, to be aware of changes like this.

On Nov 14, 2020, at 13:29 , Peter Hudson via groups.io <Peter.hudson@...> wrote:

xCode 11 on Catalina -  I set the background color of rows in my table view - the color goes right to the edge of the table view.

xCode 12.3 beta on Big Sur - I set the background color of rows in my table view - the system leaves a white margin down each side of the table view - about 3mm or so wide.

This is older code, hence using cells in the table not views.

I want the color in my table view rows to go right to the edge of the table.


NSTableView Issues

Peter Hudson
 

Hi All

xCode 11 on Catalina - I set the background color of rows in my table view - the color goes right to the edge of the table view.

xCode 12.3 beta on Big Sur - I set the background color of rows in my table view - the system leaves a white margin down each side of the table view - about 3mm or so wide.

This is older code, hence using cells in the table not views.

I want the color in my table view rows to go right to the edge of the table.

Anybody seen this ? Anybody fixed it ?

Thanks in advance !

Peter


Re: Stupid question for build schemes.

Ben Kennedy
 

Perhaps "Build Actions"?

The "Product" menu after all has a submenu called "Perform Action" containing several of these (Run, Test, Profile).

b

On 12 Nov 2020, at 12:40 pm, Alex Zavatone via groups.io <zav=mac.com@groups.io> wrote:

These things. When you open a target’s Scheme editor, these term for all of the things on the left that the scheme can change the settings for.

<PastedGraphic-1.png>


I hope this helps.
Cheers,
Alex Zavatone



On Nov 12, 2020, at 2:33 PM, Fritz Anderson <anderson.fritz@gmail.com> wrote:

I'm easily confused. Therefore I should confuse everybody else. It doesn't help that I don't have the full thread before me.

My understanding is that someone wants to know terms for the Xcode build and execution contexts; but that can't be because well-defined terms are already there. Possibly what's wanted is to unpack the jargon. I'll offer what I know, in the hope it's relevant.

---

Schemes, build settings, and build configurations are different things. There's a potential confusion in the names, so some care is needed.

---

Build settings are options that configure the tools used in the build process. Each setting may be conditioned on platform, OS version, build configuration, etc. They may be set per-target or left to the last in a stack of defaults. They are held in the project file itself.

---

Build configurations are external files to inject a layer of build defaults. The canonical use is to provide a uniform build practice for a developer or organization. They reside in external files and are catalogued in the project file.

---

Schemes set the runtime environment for one target x platform configuration. The environment is set per-action (the verbs in the Product menu or the popup anchored at what people think of as the Run button). This includes the configuration to be injected into the settings.

The Build tab sets non-default dependencies. (Example, though defaulted: Test depends mot just on the selected product target but the corresponding test targets.)

With one exception I can think of, schemes have no effect on the deliverable product. Schemes set only the environment into which Xcode itself launches a target. The exception is that you can set the build configuration for the archived product.

affect targets only the runtime environment only when the ptoduct is launched by Xcode.

Schemes are kept in a directory tree in the project bundle, but are particular to (in short) one developer unless explicitly marked Shsred.

---

If you need to talk about these together, I'd go with "Xcode build and execution context," or reasonable subsets. I think all four nouns are necessary.

— F


Re: Stupid question for build schemes.

Alex Zavatone
 

These things.  When you open a target’s Scheme editor, these term for all of the things on the left that the scheme can change the settings for.



I hope this helps.
Cheers,
Alex Zavatone



On Nov 12, 2020, at 2:33 PM, Fritz Anderson <anderson.fritz@...> wrote:

I'm easily confused. Therefore I should confuse everybody else. It doesn't help that I don't have the full thread before me.

My understanding is that someone wants to know terms for the Xcode build and execution contexts; but that can't be because well-defined terms are already there. Possibly what's wanted is to unpack the jargon. I'll offer what I know, in the hope it's relevant.

---

Schemes, build settings, and build configurations  are different things. There's a potential confusion in the names, so some care is needed.

---

Build settings are options that configure the tools used in the build process. Each setting may be conditioned on platform, OS version, build configuration, etc. They may be set per-target or left to the last in a stack of defaults. They are held in the project file itself.

---

Build configurations are external files to inject a layer of build defaults. The canonical use is to provide a uniform build practice for a developer or organization. They reside in external files and are catalogued in the project file.

---

Schemes set the runtime environment for one target x platform configuration. The environment is set per-action (the verbs in the Product menu or the popup anchored at what people think of as the Run button). This includes the configuration to be injected into the settings.

The Build tab sets non-default dependencies. (Example, though defaulted: Test depends mot just on the selected product target but the corresponding test targets.)

With one exception I can think of, schemes have no effect on the deliverable product. Schemes set only the environment into which Xcode itself launches a target. The exception is that you can set the build configuration for the archived product.

affect targets only the runtime environment only when the ptoduct is launched by Xcode.

Schemes are kept in a directory tree in the project bundle, but are particular to (in short) one developer unless explicitly marked Shsred.

---

If you need to talk about these together, I'd go with "Xcode build and execution context," or reasonable subsets. I think all four nouns are necessary.

    — F



Re: Stupid question for build schemes.

Fritz Anderson
 

I'm easily confused. Therefore I should confuse everybody else. It doesn't help that I don't have the full thread before me.

My understanding is that someone wants to know terms for the Xcode build and execution contexts; but that can't be because well-defined terms are already there. Possibly what's wanted is to unpack the jargon. I'll offer what I know, in the hope it's relevant.

---

Schemes, build settings, and build configurations  are different things. There's a potential confusion in the names, so some care is needed.

---

Build settings are options that configure the tools used in the build process. Each setting may be conditioned on platform, OS version, build configuration, etc. They may be set per-target or left to the last in a stack of defaults. They are held in the project file itself.

---

Build configurations are external files to inject a layer of build defaults. The canonical use is to provide a uniform build practice for a developer or organization. They reside in external files and are catalogued in the project file.

---

Schemes set the runtime environment for one target x platform configuration. The environment is set per-action (the verbs in the Product menu or the popup anchored at what people think of as the Run button). This includes the configuration to be injected into the settings.

The Build tab sets non-default dependencies. (Example, though defaulted: Test depends mot just on the selected product target but the corresponding test targets.)

With one exception I can think of, schemes have no effect on the deliverable product. Schemes set only the environment into which Xcode itself launches a target. The exception is that you can set the build configuration for the archived product.

affect targets only the runtime environment only when the ptoduct is launched by Xcode.

Schemes are kept in a directory tree in the project bundle, but are particular to (in short) one developer unless explicitly marked Shsred.

---

If you need to talk about these together, I'd go with "Xcode build and execution context," or reasonable subsets. I think all four nouns are necessary.

    — F

181 - 200 of 1424