Re: Setting app icon in NSWorkspace
Sorry Alex. I've done some more testing and it looks like I was mistaken. It *doesn't* break code signing, but it does do something odd - on any Build & Run from within Xcode after making that NSWorkspace API call, the codesign tool gives the following error message unless I clean the build folder: > appname.app: replacing existing signature > appname.app: resource fork, Finder information, or similar detritus not > allowed If I then call `spctl -a`, it tells me > invalid Info.plist (plist or signature have been modified) However, running the app, calling that API, and then running `spctl` (before doing another build in Xcode) it says it's fine! Subsequent runs without involving Xcode are problem-free. As there's no way my users can run into this problem, I'd say everything's fine. I'll just add something to the precompile script to workaround it. For what it's worth, it looks like NSWorkspace does simply mimic pasting a new icon in via Get Info - I can certainly clear it out from there. Thanks and sorry for the noise. Mark > On 22 Mar 2024, at 2:05 pm, Alex Zavatone wrote: > > That’s a great idea. > > For a Mac app, I suppose. > > I wonder if a simple change in the bundle where you have the icon file be > symlink to a folder in the app’s documents folder and then change that file? > > What if you issue a shell script to restart the Dock? > > What happens if you change the icon manually through get info? Can you > duplicate your app, change the icon manually and diff the two apps to see > where the differences are? Then change the icon using NSWorkspace and > compare the difference. > > It surprises me that NSWorkspace breaks code signing. > > Let me see what I can look in to. > > Cheers, > Alex Zavatone > >> On Mar 22, 2024, at 8:23 AM, Mark Allan via Cocoa-dev >> wrote: >> >> Hi all, >> >> I'm trying to offer my users the option (via a pre-defined list in my app's >> Preferences) to choose an app icon which shows up in the Dock and the Finder. >> >> Updating the Dock tile whilst the app is running is fairly simple to >> achieve, but I also want the Dock icon and Finder icons to remain customised >> even when the app isn't running. >> >> I have the following >> [[NSWorkspace sharedWorkspace] setIcon:newAppIcon forFile:[[NSBundle >> mainBundle] bundlePath] options:0]; >> >> This works, but has the unfortunate side-effect of breaking code signing! >> >> Can anyone help with this please? >> >> The folks at Panic have managed to do it with Nova, so it must be possible, >> I just can't figure it out. >> >> Thanks >> Mark >> >> ___ >> >> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) >> >> Please do not post admin requests or moderator comments to the list. >> Contact the moderators at cocoa-dev-admins(at)lists.apple.com >> >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com >> >> This email sent to z...@mac.com > ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Setting app icon in NSWorkspace
Hi all, I'm trying to offer my users the option (via a pre-defined list in my app's Preferences) to choose an app icon which shows up in the Dock and the Finder. Updating the Dock tile whilst the app is running is fairly simple to achieve, but I also want the Dock icon and Finder icons to remain customised even when the app isn't running. I have the following [[NSWorkspace sharedWorkspace] setIcon:newAppIcon forFile:[[NSBundle mainBundle] bundlePath] options:0]; This works, but has the unfortunate side-effect of breaking code signing! Can anyone help with this please? The folks at Panic have managed to do it with Nova, so it must be possible, I just can't figure it out. Thanks Mark ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Xcode 14 minimum deployment target
I've held off upgrading for the same reason. I wonder if it's something to do with a semantic difference between "is no longer supported" and "is no longer possible". Maybe what they really mean is "if it appears to work, great, but we can't guarantee it, and if it fails spectacularly, you're on your own"? Mark > On 28 Oct 2022, at 12:08 pm, Eyal Redler via Cocoa-dev > wrote: > > Could be, but I just found in the xcode 14 release notes: > >• Building for deployment to OS releases older than macOS 10.13, iOS 11, > tvOS 11, and watchOS 4 is no longer supported. (92834476) > > https://developer.apple.com/documentation/xcode-release-notes/xcode-14-release-notes > > Yet I'm am able to do just that without an issue... > > Eyal > > > >> On 28 Oct 2022, at 13:54, Saagar Jha wrote: >> >> I believe Xcode 14 has the old macOS bits (with the new iOS SDK). Try 14.1? >> >>> On Oct 28, 2022, at 03:51, Eyal Redler via Cocoa-dev >>> wrote: >>> >>> I read somewhere (can't recall where) that xcode 14 will not support >>> deployment target < macOS 10.13. >>> I was bracing myself for having to somehow develop my app on two machines >>> for a while or ditching my pre 10.13 users but after installing xcode 14 on >>> my new M1 machine I found out that I can compile and build my app with >>> minimum deployment target of 10.9 and could not find an issue when running >>> it on 10.9. >>> >>> I'm not sure what to make of it, did I misunderstand this, is it a fluke? >>> Did Apple change their policy? >>> >>> Eyal Redler >>> >>> "If Uri Geller bends spoons with divine powers, then he's doing it the hard >>> way." >>> --James Randi >>> www.eyalredler.com >>> >>> >>> ___ >>> >>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) >>> >>> Please do not post admin requests or moderator comments to the list. >>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com >>> >>> Help/Unsubscribe/Update your Subscription: >>> https://lists.apple.com/mailman/options/cocoa-dev/saagar%40saagarjha.com >>> >>> This email sent to saa...@saagarjha.com > > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/markjallan%40gmail.com > > This email sent to markjal...@gmail.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Exception not being caught in try statement
Hi all, Thanks to everyone for their suggestions. I spent far too much time working around this bug, but have finally got to the bottom of the original issue. It turns out this is a known issue with some other apps as well, and (thanks to https://trac.cyberduck.io/ticket/11231#comment:25 <https://trac.cyberduck.io/ticket/11231#comment:25> ) can be fixed by removing an obscure preference key from the User Defaults system. I was able to reproduce the issue by setting the __NSDisableSharingTextTabInstance key to YES using the "defaults write" command. I've solved it by removing that key in my -applicationDidFinishLaunching method: [[NSUserDefaults standardUserDefaults] removeObjectForKey: @"__NSDisableSharingTextTabInstance"]; Looks like someone has already submitted a bug report to Apple for it (https://openradar.appspot.com/FB8930278 <https://openradar.appspot.com/FB8930278> ) so I'm just posting this here in case it helps anyone else in the future. Best regards, Mark > On 29 Mar 2021, at 7:01 pm, Martin Wierschin via Cocoa-dev > wrote: > > Breaking the RTFD loading process down into subtasks is a good idea. It might > be worth trying to sidestep the issue using NSAttributedString. You can try > loading the data yourself as Mike suggested and then use initWithRTFD or > initWithRTFDFileWrapper. Once you have the text in an attributed string you > can swap its content into your NSTextView/NSTextStorage using > -replaceCharactersInRange:withAttributedString: > > However, I suspect the problem will remain. The exception is coming from > Apple's internal NSRTFReader class, which we can be reasonably certain is > utilized by all RTF/RTFD loading code paths. To really fix this you're > probably going to be stuck with ugly code that either: > > 1. Preprocess the RTFD to remove the data that Apple's code can't handle, eg: > strip tab stops as someone else suggested. > 2. Use method swizzling to patch Apple's buggy methods at runtime, eg: > replace -[NSRTFReader defaultParagraphStyle] to avert the conditions that > lead to the exception, before it gets thrown in the first place. > > One other potential debugging aid: NSExceptionHandler. You can register your > own handler, perhaps in a way that prevents AppKit from killing your app > outright when an exception occurs (this used to be possible but I don't know > the current behavior). But as Mike said, this isn't a real solution for > shipping software. Generally speaking once an app has thrown an exception its > state can't be relied upon. So you should only use this for testing to gather > additional debug information. > > ~Martin Wierschin > >> On Mar 26, 2021, at 11:22 AM, Mike Abdullah via Cocoa-dev >> wrote: >> >> This does seem quite surprising. However, here’s the thing: this code is >> very strange approach to take. >> >> Number 1: Cocoa doesn’t support exceptions as an error-handling mechanism >> except where explicitly stated and supported. You’re trying to use them, >> which is asking for trouble. The system doesn’t guarantee proper handling of >> memory if an exception does throw. >> >> Number 2: Your error handling approach is back-to-front. You’re trying an >> operation, seeing if it fails, then attempting to guess from the current >> state (which might have changed in the meantime) why it might have failed. >> >> Instead, use the proper error APIs and approach: >> >> 1. Load the data from disk, e.g. +[NSData >> dataWithContentsOfURL:options:error:] >> >> If that fails you can introspect the error to your heart’s content to find >> out what went wrong >> >> 2. Load the data into your text view. I’m not sure if there’s an API to do >> that in a single step or not, dunno. >> >> I also note that your code explicitly is trying to read an RTFD which if >> memory serves can be a document *bundle* format, so perhaps at step 1 you’d >> have to go with a file wrapper. But the path you specify is .rtf so I’m >> guessing you really do have a basic file and can load it as data. >> >> Mike. >> >>> On 26 Mar 2021, at 11:11, Mark Allan via Cocoa-dev >>> wrote: >>> >>> Hi folks, >>> >>> Some users are reporting a crash that I can't reproduce, and in an attempt >>> to gain additional diagnostics from a user, I wrapped the affected line in >>> a try/catch block. For two users it resolve the crash, but for a third, >>> it's still crashing at the same point! >>> >>> The crash occurs when a user attempts to open the "About" window from my >>>
Re: How do you handle reading a plist if it may be an array or a dictionary?
>> Now that Alex has the answer to his problem, can I ask a follow-up question >> based on this line in his initial email? >> >>> On 9 May 2021, at 1:12 am, Alex Zavatone via Cocoa-dev >>> wrote: >>> _configurationDictionary = [[NSMutableDictionary >>> alloc]initWithDictionary:[NSDictionary >>> dictionaryWithContentsOfFile:filePath]]; >> >> What's the benefit of having the immutable NSDictionary in the mix there? >> _configurationDictionary = [[NSMutableDictionary alloc] >> initWithDictionary:[NSDictionary dictionaryWithContentsOfFile:filePath]] >> >> Is that somehow better than: >> _configurationDictionary = [[NSMutableDictionary alloc] >> initWithContentsOfFile:filePath] >> >> or even: >> _configurationDictionary = [NSMutableDictionary >> dictionaryWithContentsOfFile:filePath] >> >> Is any one more efficient than the other (I would've assumed the last one, >> with there being fewer objects and messages) but I suppose it's possible the >> compiler ends up optimising them all to be the same anyway? > > It does not. The ObjC compiler is not in a position to make such > optimisations. But worrying about optimisation on that level is pointless; > you’re about to hit the file system which is vastly slower than an extra > message send. Heh, fair point! > Most likely the OP has just gone with what reads most conveniently to them... OK, thanks. So it's literally just personal preference then. I did wonder if that might be the case, but figured I'd ask the question. It reminds me of my perl days - TMTOWTDI Cheers Mark ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How do you handle reading a plist if it may be an array or a dictionary?
Hi, Now that Alex has the answer to his problem, can I ask a follow-up question based on this line in his initial email? > On 9 May 2021, at 1:12 am, Alex Zavatone via Cocoa-dev > wrote: >_configurationDictionary = [[NSMutableDictionary > alloc]initWithDictionary:[NSDictionary > dictionaryWithContentsOfFile:filePath]]; What's the benefit of having the immutable NSDictionary in the mix there? _configurationDictionary = [[NSMutableDictionary alloc] initWithDictionary:[NSDictionary dictionaryWithContentsOfFile:filePath]] Is that somehow better than: _configurationDictionary = [[NSMutableDictionary alloc] initWithContentsOfFile:filePath] or even: _configurationDictionary = [NSMutableDictionary dictionaryWithContentsOfFile:filePath] Is any one more efficient than the other (I would've assumed the last one, with there being fewer objects and messages) but I suppose it's possible the compiler ends up optimising them all to be the same anyway? Mark ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Exception not being caught in try statement
Hi folks,
Some users are reporting a crash that I can't reproduce, and in an attempt to
gain additional diagnostics from a user, I wrapped the affected line in a
try/catch block. For two users it resolve the crash, but for a third, it's
still crashing at the same point!
The crash occurs when a user attempts to open the "About" window from my app's
main menu item. I'm not using the standard about panel as there's a few
additional items I need to display, one of which is an NSTextView which I
populate with the contents of an RTF file from within the app bundle.
I've symbolicated the crash log to find it's happening when populating that
TextView. The line in question now reads as follows:
@try {
[self.aboutBox.creditsTextView readRTFDFromFile:[[NSBundle
mainBundle] pathForResource:@"Credits" ofType:@"rtf"]];
} @catch (NSException *exception) {
NSLog(@"Error loading the contents of the text file for the
About Box. %@", exception);
//Check we have a file at the expected path
if([[NSFileManager defaultManager] fileExistsAtPath:[[NSBundle
mainBundle] pathForResource:@"Credits" ofType:@"rtf"]]){
NSLog(@"Yes. Found the RTF credits file");
// check the attributes in case somehow there's no
permission to read the file
NSDictionary *fileAttributes = [[NSFileManager
defaultManager] attributesOfItemAtPath:[[NSBundle mainBundle]
pathForResource:@"Credits" ofType:@"rtf"] error:nil];
NSLog(@"RTF file has following attributes %@",
fileAttributes);
}
else {
NSLog(@"Nope, file not found");
}
}
This is the crash log from the newest build (with the try/catch around that
line):
> Performing @selector(showAboutBox:) from sender NSMenuItem 0x60634540
> *** Terminating app due to uncaught exception 'NSInvalidArgumentException',
> reason: '*** -[__NSArrayM insertObject:atIndex:]: object cannot be nil'
> terminating with uncaught exception of type NSException
> abort() called
>
> Application Specific Backtrace 1:
> 0 CoreFoundation 0x7fff206ea6af
> __exceptionPreprocess + 242
> 1 libobjc.A.dylib 0x7fff204223c9
> objc_exception_throw + 48
> 2 CoreFoundation 0x7fff2079ea9a -[__NSCFString
> characterAtIndex:].cold.1 + 0
> 3 CoreFoundation 0x7fff2079c953 -[__NSArrayM
> insertObject:atIndex:].cold.2 + 0
> 4 CoreFoundation 0x7fff20610421 -[__NSArrayM
> insertObject:atIndex:] + 1135
> 5 UIFoundation0x7fff23c223ab
> __defaultTabStops_block_invoke + 161
> 6 libdispatch.dylib 0x7fff203cd7c7
> _dispatch_client_callout + 8
> 7 libdispatch.dylib 0x7fff203ce96b
> _dispatch_once_callout + 20
> 8 UIFoundation0x7fff23c229d7
> -[NSMutableParagraphStyle setTabStops:] + 199
> 9 UIFoundation0x7fff23c3c697 -[NSRTFReader
> defaultParagraphStyle] + 75
> 10 UIFoundation0x7fff23c3c5be -[NSRTFReader
> _mutableParagraphStyle] + 112
> 11 UIFoundation0x7fff23c36113 controlClass + 1757
> 12 UIFoundation0x7fff23c356b4 -[NSRTFReader
> attributedString] + 76
> 13 UIFoundation0x7fff23c311a6
> _NSReadAttributedStringFromURLOrData + 3213
> 14 UIFoundation0x7fff23d46985
> -[NSAttributedString(NSAttributedStringUIFoundationAdditions)
> initWithURL:options:documentAttributes:error:] + 228
> 15 AppKit 0x7fff23677d9a -[NSTextView
> readRTFDFromFile:] + 126
> 16 MyAppHere 0x000105fa18a7 MyAppHere+ 227495
> 17 AppKit 0x7fff230af7fd
> -[NSApplication(NSResponder) sendAction:to:from:] + 283
> 18 AppKit 0x7fff231b2611 -[NSMenuItem
> _corePerformAction] + 413
Any ideas what's going on? Other than the file not being found, why else might
the object at line 3 in the backtrace be nil...and more interestingly, why is
the exception not being caught?
Thanks
Mark
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Updating localised auth-prompt strings
Hi all, I'm just wondering if anyone had had any thoughts on this issue? I never actually got to the bottom of it. Thanks Mark > On 15 Jun 2020, at 9:56 pm, Mark Allan wrote: > > Oops, sorry! I'm using Objective-C, targeting macOS 10.10+ > > > >> On 15 Jun 2020, at 9:41 pm, Alex Zavatone wrote: >> >> Platform? >> >>> On Jun 15, 2020, at 9:51 AM, Mark Allan via Cocoa-dev >>> wrote: >>> >>> Hi folks, >>> >>> I have an app which communicates with a privileged helper tool, and I used >>> the AuthorizationRightSet API to add the rights, requirements, and prompt >>> strings to the authorizationdb - as per Apple's documentation. As expected, >>> this initial call to "AuthorizationRightSet" does not prompt for >>> authentication to add the rights to the DB. >>> >>> Some of my app's functions require presenting an authentication prompt to >>> the user, and these prompts have been localised. >>> >>> Calling 'sudo security authorizationdb read' in the Terminal shows the >>> rule, the default prompt, and all the localised versions of the prompt >>> string. >>> >>> All fine so far, but I've recently reworded some of the authentication >>> prompt strings, so it (and all the localisations) now need to be updated. >>> >>> How do I do this? Naively I thought I could just update the respective >>> localizable.strings file, and it would just work, but as the translated >>> text is hard-coded into the authorizationdb, this doesn't seem possible. >>> >>> Using AuthorizationRightSet again will cause an authentication prompt to >>> appear as soon as my app is launched. As does AuthorizationRightRemove. >>> >>> Now, I know I could remove all my rights from the authorizationdb by >>> calling "sudo security authorizationdb remove XYZ" for each of my app's >>> rights, but I obviously can't expect users to do this. Neither do I want >>> them to be presented with an auth prompt purely to update some strings. >>> >>> I could also just change the auth right name so that the app proceeds as if >>> that particular right had never been in the database in the first place, >>> but that seems like a nasty hacky way to do it. >>> >>> so, where does this leave me? I can't be the only person who's come up >>> against this issue, but web searches and StackOverflow aren't giving me >>> much to go on. >>> >>> Many thanks >>> Mark > ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Updating localised auth-prompt strings
Oops, sorry! I'm using Objective-C, targeting macOS 10.10+ > On 15 Jun 2020, at 9:41 pm, Alex Zavatone wrote: > > Platform? > >> On Jun 15, 2020, at 9:51 AM, Mark Allan via Cocoa-dev >> wrote: >> >> Hi folks, >> >> I have an app which communicates with a privileged helper tool, and I used >> the AuthorizationRightSet API to add the rights, requirements, and prompt >> strings to the authorizationdb - as per Apple's documentation. As expected, >> this initial call to "AuthorizationRightSet" does not prompt for >> authentication to add the rights to the DB. >> >> Some of my app's functions require presenting an authentication prompt to >> the user, and these prompts have been localised. >> >> Calling 'sudo security authorizationdb read' in the Terminal shows the rule, >> the default prompt, and all the localised versions of the prompt string. >> >> All fine so far, but I've recently reworded some of the authentication >> prompt strings, so it (and all the localisations) now need to be updated. >> >> How do I do this? Naively I thought I could just update the respective >> localizable.strings file, and it would just work, but as the translated text >> is hard-coded into the authorizationdb, this doesn't seem possible. >> >> Using AuthorizationRightSet again will cause an authentication prompt to >> appear as soon as my app is launched. As does AuthorizationRightRemove. >> >> Now, I know I could remove all my rights from the authorizationdb by calling >> "sudo security authorizationdb remove XYZ" for each of my app's rights, but >> I obviously can't expect users to do this. Neither do I want them to be >> presented with an auth prompt purely to update some strings. >> >> I could also just change the auth right name so that the app proceeds as if >> that particular right had never been in the database in the first place, but >> that seems like a nasty hacky way to do it. >> >> so, where does this leave me? I can't be the only person who's come up >> against this issue, but web searches and StackOverflow aren't giving me much >> to go on. >> >> Many thanks >> Mark ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Updating localised auth-prompt strings
Hi folks, I have an app which communicates with a privileged helper tool, and I used the AuthorizationRightSet API to add the rights, requirements, and prompt strings to the authorizationdb - as per Apple's documentation. As expected, this initial call to "AuthorizationRightSet" does not prompt for authentication to add the rights to the DB. Some of my app's functions require presenting an authentication prompt to the user, and these prompts have been localised. Calling 'sudo security authorizationdb read' in the Terminal shows the rule, the default prompt, and all the localised versions of the prompt string. All fine so far, but I've recently reworded some of the authentication prompt strings, so it (and all the localisations) now need to be updated. How do I do this? Naively I thought I could just update the respective localizable.strings file, and it would just work, but as the translated text is hard-coded into the authorizationdb, this doesn't seem possible. Using AuthorizationRightSet again will cause an authentication prompt to appear as soon as my app is launched. As does AuthorizationRightRemove. Now, I know I could remove all my rights from the authorizationdb by calling "sudo security authorizationdb remove XYZ" for each of my app's rights, but I obviously can't expect users to do this. Neither do I want them to be presented with an auth prompt purely to update some strings. I could also just change the auth right name so that the app proceeds as if that particular right had never been in the database in the first place, but that seems like a nasty hacky way to do it. so, where does this leave me? I can't be the only person who's come up against this issue, but web searches and StackOverflow aren't giving me much to go on. Many thanks Mark ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Screensaver can capture mouse events under Catalina
I have to say, I'd be surprised if this were possible. From a security point of view, I can understand why Apple would want to prevent a screensaver from being able to capture keystrokes. > On 25 May 2020, at 11:34 pm, Michael Diehr via Cocoa-dev > wrote: > >> On May 25, 2020, at 12:43 PM, Gabriel Zachmann wrote: >> [...] >> Unfortunately, it seems that I still cannot get key events. >> Best regards, Gabriel > > I tried what feels like a thousand different variations and could not get key > events under Catalina screensaver. > If you can figure it out, please do share! > Mike > > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/markjallan%40gmail.com > > This email sent to markjal...@gmail.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
[Slightly OT] Cocoa developer job ad
Hi all, I run a software company in the UK and we're looking to hire some full-time Mac software developers to join our growing team in Edinburgh, Scotland on a permanent basis. We'll be advertising for junior/mid-level, and senior software engineer roles in all the usual places, but I've been a member of this list for a number of years so thought I'd reach out here too. We're looking for people with Objective-C, who either already live locally or are willing to relocate to Scotland. Swift, if you have it, would be a bonus! If that sounds like you, please get in touch with me directly and I'll send over some more details. Cheers Mark PS. I've been on here long enough to know that such requests are supposed to go to the list admins first, but the email address cocoa-dev-admins(at)lists.apple.com just bounces back with "User unknown"! ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: 10.15 command line tools headers missing
> On 13 Sep 2019, at 5:58 pm, Jens Alfke wrote: >> They've pulled the same trick again with 10.15 but this time, the installer >> for the headers is also missing meaning I'm unable to compile 3rd party >> software using the command line tools because of missing headers like zlib >> and libxml2. > > That's the first I've heard of this — I've had Xcode 11 for months and I > build 3rd party software with CLI tools all the time. And I assume lots of > other people do too, otherwise HomeBrew would be pretty broken :) > > The SDK headers aren't installed in /usr/include or > /System/Library/Frameworks, but Clang's default header search path is > pre-configured to include the equivalent dirs in the SDK. Hmm, I must be dreaming...or maybe just sleeping! It looks like the headers *were* included with the command line tools this year. The ./configure script for the tool I'm building has flags for specifying the path to zlib and libxml, setting these to /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr allows the whole thing to compile perfectly now. Thank you. Something has definitely changed with the dev-tools setup though, as I never had to do that in the past. Regardless, it's working now, so I'm happy. Thanks Mark ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
10.15 command line tools headers missing
Hi all, I was initially reluctant to post this here because of NDA concerns, but as Google is surfacing Apple's developer forum pages (including the post below), I figured I'm OK! As most of you probably know, in 10.14 last year, Apple stopped installing headers with the command line tools, but it was still possible to get them via a separate .pkg installer located at /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg. They've pulled the same trick again with 10.15 but this time, the installer for the headers is also missing meaning I'm unable to compile 3rd party software using the command line tools because of missing headers like zlib and libxml2. Does anyone know where to get them for macOS 10.15 Catalina? They're not on https://developer.apple.com/download/more/ Thanks Mark ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
