Re: Setting app icon in NSWorkspace

[Mark Allan via Cocoa-dev]

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

[Mark Allan via Cocoa-dev]

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

[Mark Allan via Cocoa-dev]

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

[Mark Allan via Cocoa-dev]

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?

[Mark Allan via Cocoa-dev]

>> 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?

[Mark Allan via Cocoa-dev]

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

[Mark Allan via Cocoa-dev]

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

[Mark Allan via Cocoa-dev]

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

[Mark Allan via Cocoa-dev]

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

[Mark Allan via Cocoa-dev]

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

[Mark Allan via Cocoa-dev]

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

[Mark Allan via Cocoa-dev]

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

[Mark Allan via Cocoa-dev]

> 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

[Mark Allan via Cocoa-dev]

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

Re: Mojave Privileged Helper Tool - full disk access

[Mark Allan]

So I worked out most of this for myself. 

My privileged helper tool is only executable by root. If I set it to 
world-executable, then it's possible to drag and drop it into the Full Disk 
Access panel.  Still can't get it to show up when pressing the add/plus (+) 
button, but that's not a big issue.

Mark

> On 6 Sep 2018, at 12:39 pm, Mark Allan  wrote:
> 
> Hi All,
> 
> I have an app with a privileged helper tool which needs full disk access in 
> 10.14 Mojave.
> 
> The privileged helper tool is (as you'd expect) a binary rather than an app 
> bundle, so it's not showing up when I press the plus (+) button in Security & 
> Privacy -> Privacy -> Full Disk Access. Neither can I drag and drop it in 
> there.
> 
> I've looked around online and I can't find the answer to this anywhere. I've 
> found a couple of threads in Apple's Developer Forums (most useful being 
> https://forums.developer.apple.com/thread/107546 
> <https://forums.developer.apple.com/thread/107546> ) but I still can't get it 
> to work.
> 
> I see that it must be possible because Carbon Copy Cloner is able to do it - 
> you can add their helper tool either by using the plus button or drag and 
> dropping the binary.
> 
> My helper tool is signed properly, has a bundle identifier and otherwise 
> works fine...it just isn't permitted access to the full disk.
> 
> Any help would be greatly appreciated.
> 
> 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

Mojave Privileged Helper Tool - full disk access

[Mark Allan]

Hi All,

I have an app with a privileged helper tool which needs full disk access in
10.14 Mojave.

The privileged helper tool is (as you'd expect) a binary rather than an app
bundle, so it's not showing up when I press the plus (+) button in Security
& Privacy -> Privacy -> Full Disk Access. Neither can I drag and drop it in
there.

I've looked around online and I can't find the answer to this anywhere.
I've found a couple of threads in Apple's Developer Forums (most useful
being https://forums.developer.apple.com/thread/107546 ) but I still can't
get it to work.

I see that it must be possible because Carbon Copy Cloner is able to do it
- you can add their helper tool either by using the plus button or drag and
dropping the binary.

My helper tool is signed properly, has a bundle identifier and otherwise
works fine...it just isn't permitted access to the full disk.

Any help would be greatly appreciated.

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: Xcode Versions

[Mark Allan]

> ...By the way how did you end up with all those leading spaces at the 
> begining of each line in your email.
> 
> --Richard Charles

I know - I was on line four before I realised it wasn't a poem!!  Have to say, 
I thought it started rather well.

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: Problem using NSTimer in privileged helper tool

[Mark Allan]

(sending again - the list was missed off the 'cc' in my reply)

> On 19 Oct 2017, at 6:19 pm, Jens Alfke <j...@mooseyard.com 
> <mailto:j...@mooseyard.com>> wrote:
> 
>> On Oct 19, 2017, at 9:04 AM, Mark Allan <markjal...@gmail.com 
>> <mailto:markjal...@gmail.com>> wrote:
>> 
>> Initially, I thought this meant my own class needed to conform to 
>> NSSecureCoding, but after some failed attempts, it think it's trying to tell 
>> me that it can't do it because *NSTimer* doesn't conform to NSSecureCoding.  
>> Is that correct, and if so does anyone know of a way around this issue?
> 
> You’re probably not intentionally trying to send the NSTimer object across 
> the XPC connection, but it seems to be happening by accident. The backtrace 
> of the exception should indicate what remote method you’re calling that 
> includes the timer in a parameter.

Thanks for the suggestion. Even though I've now got a working solution, this 
intrigued me enough to try and find out where I might be inadvertently sending 
an NSTimer across the XPC connection.  Console in macOS 10.12 only shows a 
handful of lines of the backtrace so I had to implement my own logging to catch 
this!

I've checked the backtrace and there's only two methods listed - the one which 
the timer fires and the one in the delegate which communicates back to the main 
app. The only parameters involved are NSNumber and NSString, and the delegate 
method has a single line which simply passes those parameters back to the main 
app via the remote object proxy.

Thinking about it some more, if the NSTimer were being sent across the XPC 
connection, surely that would also have been happening with the newer 
block-based NSTimer API I was using originally?

I think that means it *must* be something related to the run-loop, as Quincey 
suggests, but I'm still not sure what the issue is.

I've got a working solution now, so unless anyone wants me to do a bit more 
digging or testing anything, I'll leave it at that.


Thanks for all the help.
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: Problem using NSTimer in privileged helper tool

[Mark Allan]

> On 19 Oct 2017, at 6:05 pm, Quincey Morris 
> <quinceymor...@rivergatesoftware.com> wrote:
> 
> On Oct 19, 2017, at 09:04 , Mark Allan <markjal...@gmail.com 
> <mailto:markjal...@gmail.com>> wrote:
>> 
>> Terminating app due to uncaught exception 'NSInvalidArgumentException', 
>> reason: '*** -[NSXPCEncoder _checkObject:]: This coder only encodes objects 
>> that adopt NSSecureCoding (object is of class '__NSCFTimer').'
> 
> It’s very suspicious that the timer itself would be encoded, since that would 
> suggest that the timer itself is being passed back across the interface to 
> the main app. What does the backtrace look like? Ideally there would be 
> something there that tells you what it’s trying to do at that time.
> 
> I don’t know, but I suspect that the block-based NSTimer methods might differ 
> from the selector-based ones in that they use GCD rather than the run loop. 
> If you look at the documentation, the old methods say "schedules it on the 
> current run loop”. The new methods do not.
> 
> That suggests the possibility of using dispatch_source_create and 
> dispatch_source_set_timer directly to create a GCD-based time. It’s not quite 
> as convenient to code, but not hard to get right.


Bingo...I think!

After creating the NSTimer, I was scheduling it on the main run loop with the 
following:
[[NSRunLoop mainRunLoop] addTimer:self.delegateUpdateTimer 
forMode:NSDefaultRunLoopMode];

That worked with the block-based NSTimer API but not the selector-based API.  I 
tried changing it to 'currentRunLoop' which got rid of the crash, but the timer 
never fired.

Removing NSTimer altogether and replacing it with your suggestion of a 
GCD-based timer works a treat.  Timer fires, no crashing, and the main app sees 
the expected output.


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

Problem using NSTimer in privileged helper tool

[Mark Allan]

Hi all,

I'm currently writing a Mac app which performs some lengthy process on some 
data, and for a variety of reasons it needs to do this via privileged helper 
tool.

The class which does the work sends progress updates periodically to its 
delegate, which then communicates these back to the main app.

The main app communicates with the helper tool via NSXPCConnection.

I'm using an NSTimer to send the update messages to the delegate with the 
following incantation:

[NSTimer timerWithTimeInterval:0.2 repeats:YES block:^(NSTimer * _Nonnull 
timer) { ... }];


This works fine, but I've just realised NSTimer's 
timerWithTimeInterval:repeats:block: is only available with macOS 10.12 and I 
still need to support 10.8.

So I tried refactoring the block into a separate method and using an older 
NSTimer method:
[NSTimer timerWithTimeInterval:0.2 target:self 
selector:@selector(updateTheDelegateForRunID:) userInfo:runID repeats:YES];


This causes my privileged helper tool to crash with the following message 
printed to Console:

Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 
'*** -[NSXPCEncoder _checkObject:]: This coder only encodes objects that adopt 
NSSecureCoding (object is of class '__NSCFTimer').'


Initially, I thought this meant my own class needed to conform to 
NSSecureCoding, but after some failed attempts, it think it's trying to tell me 
that it can't do it because *NSTimer* doesn't conform to NSSecureCoding.  Is 
that correct, and if so does anyone know of a way around this issue?

I guess, if push comes to shove, I could put the timer in the main app and have 
it request updates from the helper tool, but that sounds awfully like polling, 
and feels like it would be the wrong way round!

Grateful for any suggestions.

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: Best practice with NSProgressIndicator

[Mark Allan]

Many thanks for all the responses.  In terms of what I'm doing, the NSTimer 
with 0.1 second granularity sounds like the best fit.

> On 28 Jul 2017, at 7:26 pm, Charles Srstka <cocoa...@charlessoft.com> wrote:
> 
> If you’re using Swift 

Still on Objective-C.  Thanks though, I'll keep that bookmarked for when I 
venture into Swift!


> On 28 Jul 2017, at 6:57 pm, Quincey Morris 
> <quinceymor...@rivergatesoftware.com> wrote:
> 
> On Jul 28, 2017, at 08:57 , Mark Allan <markjal...@gmail.com 
> <mailto:markjal...@gmail.com>> wrote:
>> 
>> I have an app with a helper tool that performs some lengthy process in a 
>> loop and reports progress to the user.  It works out how many iterations of 
>> the loop will be needed, sets the progressbar.maxValue, and then increments 
>> the progress bar's value on each iteration.
> 
> Can you clarify this description? Is the helper tool running in a separate 
> process, in which case how (and how often) is it reporting progress back to 
> the app? Is it the helper tool that’s looping progressbar.maxValue times? 
> What is the app doing while the helper tool is running?
> 
> Also, it seems like a “code smell” if the code that’s iterating millions of 
> times is updating a progress bar directly. Actually, two issues:
> 
> 1. In a MVC design, code that’s calculating like this is generally part of 
> the model, and shouldn’t be aware of what UI element is reporting progress, 
> even though the model may provide some progress information.
> 
> 2. The iteration is presumably on a background thread, and it’s not clear how 
> you transfer the progress information safely to the main thread.
> 
> The normal solution to #1 is some kind of observation (of the progress 
> information), and to #2 is some kind of trampoline. Both of those techniques 
> lend themselves to thinning the frequency of UI updates, so you have choices 
> about how to do that.
> 
> I’m agnostic on timer vs. elapsed-time update thinning. Both are easy enough 
> to do, once you figure out *where* to do them.


Apologies for the lack of detail/clarity - I simplified things for the sake of 
keeping the email short.

The loop most definitely is not updating the progress bar directly.  In fact, 
the helper tool is a separate process, communicating via NSXPCConnection, so it 
couldn't update it directly even if I wanted it to! Reducing the frequency of 
NSXPC messages was a secondary goal to figuring out how often the main app 
ought to be updating the UI.

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

Best practice with NSProgressIndicator

[Mark Allan]

Hi all,

I'm wondering if anyone has any thoughts about or links to best practices when 
using determinate NSProgressIndicators.

I have an app with a helper tool that performs some lengthy process in a loop 
and reports progress to the user.  It works out how many iterations of the loop 
will be needed, sets the progressbar.maxValue, and then increments the progress 
bar's value on each iteration.

The consumes a large amount of CPU time just for updating the progress bar, so 
I'd like to cut down how often I update it.

Setting the max value to 100 and only updating 100 times (i.e. as a percentage) 
seems too infrequent because the loop can iterate more than a million times.

I'm debating doing it with an NSTimer firing every second, but wondered if 
anyone had any other suggestions?

What are people's thoughts?

I've tried searching online and the only problems/solutions I can see are all 
related to people's progress bars not updating properly because they're 
blocking the main thread etc. I can't see anything related to best practice.

Many thanks
Mark

PS. It could be that this is a case of premature optimisation...but I don't 
think so!
___

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: Why is XCode suddenly doing this?

[Mark Allan]

Graham,

This happened to me a few months ago and it was driving me nuts until I 
eventually figured out what was causing it (by trawling through all my git 
commits around the time it started happening).

Have you added a sub-project, or a target-dependency recently?  If so, check 
that it has the "skip install" build setting set to "yes".

You can repair/relocate any incorrect archives by quitting Xcode and tweaking 
the Info.plist file within each archive bundle so that it's similar to an 
existing archive which is in the correct section. This may or may not be 
wise/supported but I haven't experienced any issues with all the archives I had 
to change.  Obviously your mileage may vary (and blah blah something about 
backup blah) but I changed mine so that all archives were in the same correct 
place.

Mark

> On 23 Jun 2017, at 5:19 am, Graham Cox  wrote:
> 
> I’ve been archiving built Mac apps forever with no issues. (Build -> Archive)
> 
> Suddenly, XCode has stopped adding the archive to the ‘Mac OSX Apps section 
> under that particular app, and started it adding it as a ‘Generic XCode 
> Archive’ under the ‘Other’ section.
> 
> Why, and more importantly, how do I get it back to working correctly?
> 
> —Graham

___

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: Issue with addTitlebarAccessoryViewController on 10.10

[Mark Allan]

> On 5 Mar 2017, at 10:35 pm, Kyle Sluder <k...@ksluder.com> wrote:
> 
> On Fri, Mar 3, 2017, at 08:39 AM, Mark Allan wrote:
>> Hi all,
>> 
>> I've got an NSWindow which has an NSToolbar added programmatically. The
>> window does not use a shared title/toolbar.  I now want to add a little
>> bit of text/button to the window's titlebar, so for OS X 10.6 to 10.9,
>> I'm doing it the old way playing around with NSWindow subviews, which
>> works fine.
>> 
>> On versions 10.10+ I'm using addTitlebarAccessoryViewController which
>> works great on 10.11 and 10.12, but for some reason it shifts the toolbar
>> buttons out of position on 10.10.
>> 
>> Judging by the AppKit release notes, this is a known issue which was
>> fixed in 10.11, and also by linking on 10.11
>> 
>>> For applications linked on 10.11 and higher, a 
>>> NSTitlebarAccessoryViewController with the layoutAttribute set to 
>>> NSLayoutAttributeRight will no longer right indent toolbar items, unless 
>>> the titleVisibility == NSWindowTitleHidden. This allows placing a 
>>> view/button/textfield (etc) above the toolbar without right indenting the 
>>> toolbar. However, for the NSWindowTitleHidden, there is still a desire to 
>>> indent the toolbar on the right to leave space for the accessory view.
>> 
>> I'm currently building on macOS 10.12 (with target of 10.6) but the issue
>> still shows up for users on OS X 10.11, even with the viewcontroller's
>> layoutAttribute = NSLayoutAttributeRight.
>> 
>> Does anyone know of a fix or workaround I could use please?
> 
> Is it possible to reproduce this in a sample app? This should be
> behaving as documented in the release notes.
> 
> --Kyle Sluder

Hi Kyle,

Yes, I've just moved all the relevant code in to a new sample app and it 
behaves the same way.  Below is a link to the code and a three screenshots 
showing how it appears on 10.6, 10.10 and 10.11.

https://www.dropbox.com/s/1adygl9r8mhfn0s/TestApp_TitlebarAccesoryTrouble.zip?dl=0
 
<https://www.dropbox.com/s/1adygl9r8mhfn0s/TestApp_TitlebarAccesoryTrouble.zip?dl=0>

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

Issue with addTitlebarAccessoryViewController on 10.10

[Mark Allan]

Hi all,

I've got an NSWindow which has an NSToolbar added programmatically. The window 
does not use a shared title/toolbar.  I now want to add a little bit of 
text/button to the window's titlebar, so for OS X 10.6 to 10.9, I'm doing it 
the old way playing around with NSWindow subviews, which works fine.

On versions 10.10+ I'm using addTitlebarAccessoryViewController which works 
great on 10.11 and 10.12, but for some reason it shifts the toolbar buttons out 
of position on 10.10.

Judging by the AppKit release notes, this is a known issue which was fixed in 
10.11, and also by linking on 10.11

> For applications linked on 10.11 and higher, a 
> NSTitlebarAccessoryViewController with the layoutAttribute set to 
> NSLayoutAttributeRight will no longer right indent toolbar items, unless the 
> titleVisibility == NSWindowTitleHidden. This allows placing a 
> view/button/textfield (etc) above the toolbar without right indenting the 
> toolbar. However, for the NSWindowTitleHidden, there is still a desire to 
> indent the toolbar on the right to leave space for the accessory view.

I'm currently building on macOS 10.12 (with target of 10.6) but the issue still 
shows up for users on OS X 10.11, even with the viewcontroller's 
layoutAttribute = NSLayoutAttributeRight.

Does anyone know of a fix or workaround I could use please?

If it comes to it, I could still use the old subview manipulation method on 
10.10 and users would just have to put up with seeing junk in the log about 
adding an unknown subview, but I'd rather avoid that if possible!

Would appreciate any help.

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: Running apps compiled for newer OS X versions on older versions (rant)

[Mark Allan]

> On 22 Aug 2016, at 2:27 pm, Andreas Falkenhahn  wrote:
> 
> On 22.08.2016 at 13:34 Alastair Houghton wrote:
> 
> 
>>> On 22 Aug 2016, at 12:15, Andreas Falkenhahn  wrote:
>>> Out of curiosity, I've just run a little test and compiled my app on the
>>> 10.11 system for the 10.11 target and tried to run it on the 10.6 system,
>>> just to see what happens. All I got is a message "Illegal instruction"
>>> printed to stdout, or, when starting the app through Finder, a message
>>> dialog telling me that the app has crashed and needs to be shut down.
>>> Optionally, it offered me to send a crash report to Apple.
> 
>>> That was quite a surprise to me. I mean, this is the 21st century, I think
>>> one could at least expect a message dialog telling the user that this app
>>> needs at least Mac OS 10.11 or something, but no, it just crashed, leaving
>>> the user quite clueless as to why it did so.
> 
>> The trick here is that you need to set the LSMinimumSystemVersion
>> key in your Info.plist (this appears in Xcode as “Minimum system version”).
> 
> Ah, ok, thanks!

It's probably also worth noting that you *can* compile for 10.6 using the tools 
on 10.11 by adjusting the deployment target.

The only things you need to watch out for are the fact that you're compiling 
against the 10.11 SDK which will happily let you use APIs that didn't exist in 
previous incarnations of OS X, which will obviously cause your app to crash on 
those older versions. Also beware of any new projects you start, as their 
Interface Builder files will be set to use auto-layout and won't automatically 
set their deployment target to that of the project's main target.

If you're careful, there's no reason why you can't create and compile something 
on 10.11 and have it run happily on 10.6 (or even further back if you're 
feeling adventurous!)

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

Communication with privileged helper crashes my main application

[Mark Allan]

Hi all,

I have an application which installs and uses a privileged helper tool that, 
for myself and most users, seems to work just fine.

I do, however, have one user (and experience tells me there'll be more who 
simply aren't reporting it) who's experiencing my app crashing when 
communicating with the helper tool.

I still need to support OS X 10.6, so I'm using the BetterAuthorizationSample 
code and the crash appears to be happening in BetterAuthorizationSampleLib.c at 
line 1665.  The error I'm seeing is

Assertion failed: (err == noErr), function BASSetDefaultRules

To me, that would indicate the user has the wrong version of the helper tool 
for the app in use, but from the diagnostics report being sent back, they are 
using the correct version of the helper with the correct version of the 
application so I've no idea what could be going wrong.

Has anyone else experienced this?  If so, do you have any suggestions please?

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: Prioritize my own app's disk access

[Mark Allan]

Have you tried to nice/renice your process ID? I know that works for CPU usage 
but I'm not sure about other hardware resources.

A cursory glance at the man pages for getpriority & setpriority seem to 
indicate that network and disk IO can be lowered in priority so I would try 
that first to see if it also works to increase priority.

Mark

> On 5 Jul 2016, at 1:36 pm, Jonathan Taylor  
> wrote:
> 
> This is a long shot, but I thought I would ask in case an API exists to do 
> what I want. One of the roles of my code is to record video to disk as it is 
> received from a camera. A magnetic hard disk can normally keep up with this, 
> but if the user is also doing other things on the computer (e.g. long file 
> copy in the Finder) then we are unable to keep up, and accumulate an 
> ever-increasing backlog of frames waiting to be saved. This eventually leads 
> to running out of memory, thrashing, and an unresponsive computer. Dropping 
> frames is not an option. In this case, the computer is a dedicated 
> workstation running my code, so it *is* correct for me to consider my code to 
> be the number 1 priority on the computer.
> 
> What I am wondering is whether there is some way I can communicate this 
> requirement, to cause other apps such as the finder to get disk access at 
> lower priority. Or alternatively, a way that I can demand high priority 
> temporarily, at times when I identify that we have accumulated a save backlog?
> 
> I can see reasons why this is probably not possible, but I thought I’d ask if 
> anyone has any suggestions that might be relevant here.
> Thanks for any suggestions
> Jonny.



___

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: Very basic need, very difficult to achieve.

[Mark Allan]

___

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

Communicating with Privileged Helper Tool

[Mark Allan]

Hi all,

I've got a an OS X application that needs to perform some privileged 
operations, so I've written a privileged helper tool (PHT) and it all works 
fine to call the necessary functions from my user-land application and get the 
response.

What I'm struggling with is some additional communication between the helper 
tool and my application during lengthy operations, so the application can 
provide some visual feedback to the user.

I need to support 10.6, so NSXPCConnection is out of the question. I've tried 
Distributed Objects as well as CFMessagePort/NSMessagePort but neither seems to 
work.

For DO, I can successfully vend the object within my GUI application, but I'm 
unable to connect from my helper tool. When doing the following in the PHT, I 
always get the log message saying "couldn't connect", and the method in my 
application doesn't get called.

NSConnection *theConnection = [NSConnection 
connectionWithRegisteredName: @"uk.co.blahblahconnection" host:nil];
if (!theConnection) {
asl_log(logClient, NULL, ASL_LEVEL_ERR, "Couldn't connect");
}

id myServer = [theConnection rootProxy];
if (!myServer) {
asl_log(logClient, NULL, ASL_LEVEL_ERR, "myServer is nil");
}
[myServer setProtocolForProxy:@protocol(MyServerProtocol)];

asl_log(logClient, NULL, ASL_LEVEL_ERR, "Function returned 
%d",[myServer myServerFunction]);

If I use the exact same code in a new project (GUI application), it works 
absolutely fine!

I assumed that that meant DO isn't permitted from a PHT (despite being 
permitted over a network, therefore connecting from a different user on a 
different machine entirely), so dug a bit lower and tried NSMessagePort instead.

Unfortunately, this gives me the exact same issue:

CFMessagePortRef remotePort = CFMessagePortCreateRemote(NULL, 
CFSTR("com.example.app.port.server"));

if (!remotePort) {
asl_log(asl, aslMsg, ASL_LEVEL_ERR, "no remote port");
}

When using the above code in my PHT, I get "no remote port" in the console log, 
however, trying it from a completely new GUI application project, it works 
absolutely fine.

Googling/Ducking (DuckDuckGoing?) didn't turn up anything I hadn't already 
tried, and the search on CocoaBuilder.com isn't working.

Am I missing something?  Is there a way to do what I'm looking for, or am I 
just barking up the wrong tree entirely?

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: Communicating with Privileged Helper Tool

[Mark Allan]

Hi Damien,

Thanks for replying.

> On 23 Dec 2015, at 5:18 pm, Damien DeVille  wrote:
> 
>> Unfortunately, this gives me the exact same issue:
> 
> How are you creating the other end of the connection? The remote port will 
> just attempt to connect to the local port and not actually register the mach 
> service. If you never registered the mach service name it will fail as you’re 
> seeing.

Oops, sorry for missing this out.  Here's the code in my main GUI application:

CFMessagePortRef localPort = CFMessagePortCreateLocal(NULL, 
CFSTR("com.example.app.port.server"), Callback, nil, nil);
if (!localPort) {
NSLog(@"couldn't open localport");
}
CFRunLoopSourceRef runLoopSource = 
CFMessagePortCreateRunLoopSource(nil, localPort, 0);
CFRunLoopAddSource(CFRunLoopGetCurrent(), runLoopSource, 
kCFRunLoopCommonModes);

I know the port is getting created, as I can connect from another GUI app, I 
just can't connect from the helper tool.

I'm using the following to try and connect to it from the helper tool:

CFMessagePortRef remotePort = CFMessagePortCreateRemote(NULL, 
CFSTR("com.example.app.port.server"));

> You can use `CFMessagePortCreateLocal` in you helper tool. This function will 
> take care of registering the service name with the bootstrap server (on top 
> of giving you a port to listen on). If you’re using objc you can register 
> your mach port directly by calling `NSMachBootstrapServer.registerPort:name:`.
> 
> If you helper tool is launched by launchd, you can add the MachService name 
> to your job plist and launchd will bootstrap it in the right domain for you.

The helper tool *is* launched by launchd, however if I add the MachService name 
to the plist, won't that mean the connection is going the wrong way?  I want 
the GUI to listen for connections from the helper tool.

Thanks again
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: WWDC videos vs. slides?

[Mark Allan]

I know this is going slightly off-top (but it started off-topic for the list 
anyway, so I don't feel too bad!)

I usually do the same, but how do you download all the videos?  I just work 
through them manually in iTunes - is there a quicker way?

Mark

On 19 Nov 2012, at 01:28, Alex Zavatone z...@mac.com wrote:

 FYI, I download them all to my Mac, then recompress them to be MP4 at QP03 
 using 3ivx MP4, and the files end up being about 1/2 the size of the source.
 
 Then they display fine on my iPads and don't eat up the whole storage space.
 
 On Nov 17, 2012, at 12:13 AM, Rick Mann wrote:
 
 
 On Nov 16, 2012, at 21:08 , Jonathan Hull jh...@gbis.com wrote:
 
 Sounds like a glitch.  I think that has happened to me a couple of times.  
 Reloading the page (or possibly restarting Safari) should fix it.  Worst 
 case, you should be able to download it on your iPad and watch it in your 
 video app.
 
 Something went horribly wrong on the iPad. It's actually very hard to get at 
 the WWDC videos (you have to log into the dev website, then drill down, then 
 open in iTunes, and if you leave iTunes you have start all over; it's 
 marginally better on the desktop). After a while they all started to fail, 
 and no amount of retrying fixed it.
 
 I'm now downloading them on the desktop, I'll sync later.


___

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: Problem enumerating a directory

[Mark Allan]

Thanks very much for the suggestion.  I've just given that a try, but it 
doesn't make any difference.  The enumeration still stops early, but the error 
handler block doesn't get called, making me think there's no error; the 
enumeration simply thinks it's finished.

Anything else I could try.  FWIW, I've just installed 10.8 and it's still 
happening.

M

On 27 Jul 2012, at 18:10, Kevin Perry kpe...@apple.com wrote:

 You should probably try -[NSFileManager 
 enumeratorAtURL:includingPropertiesForKeys:options:errorHandler:]. The 
 errorHandler block will give you more detail about any errors that occur in 
 the middle of the enumeration (and give you the ability to ignore them).
 
 -KP
 
 On Jul 27, 2012, at 9:44 AM, Mark Allan markjal...@blueyonder.co.uk wrote:
 
 Hi all,
 
 Apologies for asking a question which has been asked many times before, but 
 I can't seem to find an answer to this particular one.
 
 I'm trying to list a directory recursively to build up a snapshot of the 
 contents and store them in a core data DB, but keep running into issues with 
 the directory list.  The core data part is working fine as far as I can tell!
 
 I've tried writing a recursive method to call scandir() until the whole tree 
 has been visited, but I'm coming unstuck converting NSStrings to const char* 
 to char*.  Unless I supply the path directly as a hard-coded C-string 
 /Users/mark, it works for a while, but then sometimes it forgets to add 
 /Users/mark and starts scanning directories at the root of my HD!  Hard 
 coding the C string works perfectly but obviously isn't an option.
 
 -(void) scan: (char *)theDir{
   struct dirent **namelist;
   int n;
  size_t thisDirLength = strlen(theDir);
  
   n = scandir(theDir, namelist, 0, NULL);
   if (n  0){
   perror(scandir);
  }
   else {
   while(n--) {
  theCounter++;
  if (theCounter = 1000) {
  theCounter = 0;
  [[self managedObjectContext] save:NULL];
  [[self managedObjectContext] reset];
  [thePool drain];
  thePool = [[NSAutoreleasePool alloc] init];
  }
  if ((strcmp(namelist[n]-d_name,.) != 0)  
 (strcmp(namelist[n]-d_name,..) != 0)) {
  char* fullPath = malloc(thisDirLength + 
 strlen(namelist[n]-d_name) + 2);
  strcpy(fullPath, theDir);
  strcat(fullPath, /);
  strcat(fullPath, namelist[n]-d_name);
  
  [self addEntityWithPath:[NSString 
 stringWithCString:fullPath encoding:NSUTF8StringEncoding]];
  
  if (namelist[n]-d_type == DT_DIR) {
  [self scan:fullPath];
  }
  free(fullPath);
  }
   free(namelist[n]);
   }
   free(namelist);
   }
 }
 
 
 I then gave up on that approach and opted for the easier but slower cocoa 
 solution (NSDirectoryEnumerator) but for some reason it gives up with 
 neither an error nor a warning about half way through the tree.  Could it be 
 that modifications to the file system during the enumeration are causing it 
 to fail?
 
 
 -(void) startSnapshotForPath:(NSString *) thePath {
  int theCounter = 0;
  NSDirectoryEnumerator *dirEnumerator = [[NSFileManager defaultManager] 
 enumeratorAtPath: thePath];
  thePool = [[NSAutoreleasePool alloc] init];
  
  for (NSString *theSubPath in dirEnumerator) {
  [self addEntityWithPath:[thePath 
 stringByAppendingPathComponent:theSubPath]];
  theCounter++;
  if (theCounter = 1000) {
  theCounter = 0;
  [[self managedObjectContext] save:NULL];
  [[self managedObjectContext] reset];
  [thePool drain];
  thePool = [[NSAutoreleasePool alloc] init];
  }
  }
  
  [[self managedObjectContext] save:NULL];
  [[self managedObjectContext] reset];
  [thePool drain];
 }
 
 I've also tried Uli Kusterer's UKDirectoryEnumerator but that doesn't appear 
 to be recursive!  I suspect (although I haven't tried) that requesting the 
 type of the path (i.e. file/directory) and creating a new 
 UKDirectoryEnumerator for each subdirectory would be massively expensive.
 
 Does anyone have any suggestions for where I can go from here please?  How 
 can I find out why NSDirectoryEnumerator is failing half-way through the 
 process, and how can I stop it doing so? Failing that, does anyone have a 
 better suggestion for how I can build the snapshot please?
 
 Many thanks
 Mark


___

Cocoa-dev mailing list

Re: Problem enumerating a directory

[Mark Allan]

On 30 Jul 2012, at 11:37, Mike Abdullah cocoa...@mikeabdullah.net wrote:
 On 30 Jul 2012, at 10:48, Mark Allan wrote:
 Thanks very much for the suggestion.  I've just given that a try, but it 
 doesn't make any difference.  The enumeration still stops early, but the 
 error handler block doesn't get called, making me think there's no error; 
 the enumeration simply thinks it's finished.
 
 Anything else I could try.  FWIW, I've just installed 10.8 and it's still 
 happening.
 
 Are you able to determine anything in common about the directories it’s 
 apparently skipping? Any symlinks involved perhaps?

No, I can't see anything in common.  It seems to stop at a different stage 
every time I run the code!

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

Problem enumerating a directory

[Mark Allan]

Hi all,

Apologies for asking a question which has been asked many times before, but I 
can't seem to find an answer to this particular one.

I'm trying to list a directory recursively to build up a snapshot of the 
contents and store them in a core data DB, but keep running into issues with 
the directory list.  The core data part is working fine as far as I can tell!

I've tried writing a recursive method to call scandir() until the whole tree 
has been visited, but I'm coming unstuck converting NSStrings to const char* to 
char*.  Unless I supply the path directly as a hard-coded C-string 
/Users/mark, it works for a while, but then sometimes it forgets to add 
/Users/mark and starts scanning directories at the root of my HD!  Hard 
coding the C string works perfectly but obviously isn't an option.

-(void) scan: (char *)theDir{
struct dirent **namelist;
int n;
size_t thisDirLength = strlen(theDir);

n = scandir(theDir, namelist, 0, NULL);
if (n  0){
perror(scandir);
}
else {
while(n--) {
theCounter++;
if (theCounter = 1000) {
theCounter = 0;
[[self managedObjectContext] save:NULL];
[[self managedObjectContext] reset];
[thePool drain];
thePool = [[NSAutoreleasePool alloc] init];
}
if ((strcmp(namelist[n]-d_name,.) != 0)  
(strcmp(namelist[n]-d_name,..) != 0)) {
char* fullPath = malloc(thisDirLength + 
strlen(namelist[n]-d_name) + 2);
strcpy(fullPath, theDir);
strcat(fullPath, /);
strcat(fullPath, namelist[n]-d_name);

[self addEntityWithPath:[NSString 
stringWithCString:fullPath encoding:NSUTF8StringEncoding]];

if (namelist[n]-d_type == DT_DIR) {
[self scan:fullPath];
}
free(fullPath);
}
free(namelist[n]);
}
free(namelist);
}
}


I then gave up on that approach and opted for the easier but slower cocoa 
solution (NSDirectoryEnumerator) but for some reason it gives up with neither 
an error nor a warning about half way through the tree.  Could it be that 
modifications to the file system during the enumeration are causing it to fail?


-(void) startSnapshotForPath:(NSString *) thePath {
int theCounter = 0;
NSDirectoryEnumerator *dirEnumerator = [[NSFileManager defaultManager] 
enumeratorAtPath: thePath];
thePool = [[NSAutoreleasePool alloc] init];

for (NSString *theSubPath in dirEnumerator) {
[self addEntityWithPath:[thePath 
stringByAppendingPathComponent:theSubPath]];
theCounter++;
if (theCounter = 1000) {
theCounter = 0;
[[self managedObjectContext] save:NULL];
[[self managedObjectContext] reset];
[thePool drain];
thePool = [[NSAutoreleasePool alloc] init];
}
}

[[self managedObjectContext] save:NULL];
[[self managedObjectContext] reset];
[thePool drain];
}

I've also tried Uli Kusterer's UKDirectoryEnumerator but that doesn't appear to 
be recursive!  I suspect (although I haven't tried) that requesting the type of 
the path (i.e. file/directory) and creating a new UKDirectoryEnumerator for 
each subdirectory would be massively expensive.

Does anyone have any suggestions for where I can go from here please?  How can 
I find out why NSDirectoryEnumerator is failing half-way through the process, 
and how can I stop it doing so? Failing that, does anyone have a better 
suggestion for how I can build the snapshot please?

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: Sandboxing and calling Launchctl

[Mark Allan]

Thanks Alex,

Thanks for your reply.

If you're talking about the com.apple.security.inherit entitlement, that only 
works for helper apps which are launched via fork/exec from the main 
application.  When the helper app is launched by LaunchServices (via 
SMLoginItemSetEnabled) it crashes immediately as it can't inherit a sandbox 
from anywhere.

In a last-ditch attempt, I was trying to get around that by:
Have my helper app launch the main app at startup.
The main app could then launch a second helper (with 
com.apple.security.inherit entitlement) to do the scheduling.
Main app then terminates immediately.

The two problems with that approach are firstly, the sandbox wouldn't let the 
helper launch my primary app because it's in a different sandbox, and secondly, 
my understanding of forking is that even if I could do that, when the main app 
terminates, any process it forked also gets terminated doesn't it?

Mark

On 1 Jun 2012, at 02:30, Alex Zavatone wrote:

 If you haven't watched the video for Session 204 - App Sandbox and the Mac 
 App Store from the WWDC 2011 videos, there might be some info in there that 
 will help you around the 9 minute mark.
 
 Search for the 2011 WWDC videos on developer.apple.com
 
 GL, 
 - Alex Zavatone
 
 On May 31, 2012, at 6:35 AM, Mark Allan wrote:
 
 On 29 May 2012, at 15:42, Mark Allan wrote:
 
 For anyone following, using temporary entitlements only gets rid of two of 
 the four errors, so I still can't make scheduling via launchd work.
 
 sandboxd still spits out:
 launchctl(14634) deny job-creation
 
 and Xcode/run log still gives:
 launch_msg(): Socket is not connected
 
 Other than rolling my own scheduling and writing a helper app which runs 
 constantly in the background, can anyone think of a way around this?
 
 Thanks
 Mark
 
 OK.  After nearly a week of head-banging, I'm just about ready to throw in 
 the towel, dump sandboxing and potentially the Mac App Store altogether.
 
 I spent the best part of yesterday reinventing the wheel and implementing my 
 own scheduling mechanism to put into a helper app which would run in the 
 background constantly as a login item... the timing/scheduling bit works 
 fine, but the helper app can't actually DO anything because it runs in a 
 different sandbox from the main app!!  This means I can't access the user's 
 preferences without a temporary entitlement, and can't access the resources 
 within my main app at all.
 
 My helper app sits in Main.app/Contents/Library/LoginItems/MainHelper.app 
 and is launched (based on user prefs) by calling
  SMLoginItemSetEnabled((CFStringRef)[NSString stringWithString:@my app 
 identifier.helpername], true)
 
 I've tried giving the helper the same bundle identifier as the main app, but 
 that doesn't work (as expected, but I wanted to try anyway!).
 
 I've even tried getting the path of the helper app ([[NSBundle mainBundle] 
 bundlePath]) and removing the last 4 path components to get the path to the 
 main application and launching it via NSWorkspace, so that I could then 
 launch my helper that way and inherit the sandbox, but sandboxd gives more 
 permission violations when attempting to launch the main application.  I 
 suspect that would have been cause for appstore rejection anyway!
 
 I feel like I've missed something obvious, but I just can't see it.  Is 
 there a way to make the helper app run in the same sandbox as the main app?
 
 Many thanks for your help.
 
 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

Re: Sandboxing and calling Launchctl

[Mark Allan]

On 29 May 2012, at 15:42, Mark Allan wrote:

 For anyone following, using temporary entitlements only gets rid of two of 
 the four errors, so I still can't make scheduling via launchd work.
 
 sandboxd still spits out:
   launchctl(14634) deny job-creation
 
 and Xcode/run log still gives:
   launch_msg(): Socket is not connected
 
 Other than rolling my own scheduling and writing a helper app which runs 
 constantly in the background, can anyone think of a way around this?
 
 Thanks
 Mark

OK.  After nearly a week of head-banging, I'm just about ready to throw in the 
towel, dump sandboxing and potentially the Mac App Store altogether.

I spent the best part of yesterday reinventing the wheel and implementing my 
own scheduling mechanism to put into a helper app which would run in the 
background constantly as a login item... the timing/scheduling bit works fine, 
but the helper app can't actually DO anything because it runs in a different 
sandbox from the main app!!  This means I can't access the user's preferences 
without a temporary entitlement, and can't access the resources within my main 
app at all.

My helper app sits in Main.app/Contents/Library/LoginItems/MainHelper.app and 
is launched (based on user prefs) by calling
SMLoginItemSetEnabled((CFStringRef)[NSString stringWithString:@my app 
identifier.helpername], true)

I've tried giving the helper the same bundle identifier as the main app, but 
that doesn't work (as expected, but I wanted to try anyway!).

I've even tried getting the path of the helper app ([[NSBundle mainBundle] 
bundlePath]) and removing the last 4 path components to get the path to the 
main application and launching it via NSWorkspace, so that I could then launch 
my helper that way and inherit the sandbox, but sandboxd gives more permission 
violations when attempting to launch the main application.  I suspect that 
would have been cause for appstore rejection anyway!

I feel like I've missed something obvious, but I just can't see it.  Is there a 
way to make the helper app run in the same sandbox as the main app?

Many thanks for your help.

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

Sandboxing and calling Launchctl

[Mark Allan]

Hi all,

I posted this to the developer forums yesterday but I think this list probably 
gets a good bit more eyeball than the forum, so I'm sending here too. Sorry for 
the cross-post if you're seeing it twice.  Anyway...

I'm trying to put together the last bits and pieces of sandboxing my app but 
I've just hit a problem.  I don't appear to be able to use launchctl to 
schedule tasks any more.
 
With my app sandboxed, I'm launching an NSTask with the following launch path 
and arguments:
 /bin/launchctl load -w /Users/mark/Library/Containers/my app 
 identifier/Data/Library/LaunchAgents/my app identifier.helpername.plist


I'm using the correct APIs to get the path and read/write the helpername.plist 
file.  As per other command line tools I launch via NSTask, launchctl is 
presumably inheriting the same entitlements as my main application, but 
launchctl obviously needs to modify other files to which my app normally 
wouldn't have access - namely:
/private/var/db/launchd.db/com.apple.launchd.peruser.501/overrides.plist

 
The inherited entitlements don't allow access to that file, so I'm seeing this 
from sandboxd in the log file:
 launchctl(4831) deny file-read-data 
 /private/var/db/launchd.db/com.apple.launchd.peruser.501/overrides.plist
and
 launchctl(4831) deny job-creation

I'm also seeing this in Xcode's run log:
 Bug: launchctl.c:2425 (25957):1: (dbfd = open(g_job_overrides_db_path, 
 O_RDONLY | O_EXLOCK | O_CREAT, S_IRUSR | S_IWUSR)) != -1
 launch_msg(): Socket is not connected

As the user ID in the filename which launchctl is trying to write will be 
different for different users, I don't think I can set a temporary entitlement 
for it (haven't tried yet, that's today's task!), and even if I can, it doesn't 
seem like the right answer for long-term use.

Has anyone else come across this problem?  If so, how did you solve it?
 
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: Sandboxing and calling Launchctl

[Mark Allan]

On 29 May 2012, at 12:24, Stephane Sudre wrote:
 On Tue, May 29, 2012 at 10:52 AM, Mark Allan
 Hi all,
 
 I posted this to the developer forums yesterday but I think this list 
 probably gets a good bit more eyeball than the forum, so I'm sending here 
 too. Sorry for the cross-post if you're seeing it twice.  Anyway...
 
 I'm trying to put together the last bits and pieces of sandboxing my app but 
 I've just hit a problem.  I don't appear to be able to use launchctl to 
 schedule tasks any more.
 
 With my app sandboxed, I'm launching an NSTask with the following launch 
 path and arguments:
 /bin/launchctl load -w /Users/mark/Library/Containers/my app 
 identifier/Data/Library/LaunchAgents/my app identifier.helpername.plist
 
 
 I'm using the correct APIs to get the path and read/write the 
 helpername.plist file.  As per other command line tools I launch via NSTask, 
 launchctl is presumably inheriting the same entitlements as my main 
 application, but launchctl obviously needs to modify other files to which my 
 app normally wouldn't have access - namely:[...]
 
 SMLoginItemSetEnabled can be a solution.
 
 https://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingLoginItems.html

Hi Stephane,

Thanks for your reply, but that's not quite what I'm looking for.  I'm not 
using launchctl to set a startup/login item, I'm using it to allow the user to 
specify a schedule to perform various tasks based on a particular time and day 
of the week.  While I could write a login item which ran indefinitely and took 
care of the timing myself, it seems like I'd be reinventing the wheel!

I already moved from cron to launchd to support the AppStore, which was a pain, 
so I really hope Apple doesn't want me to roll my own timing mechanism just to 
support sandboxing!

Still, it's an option which I'll bear in mind, so thanks for that.

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: Sandboxing and calling Launchctl

[Mark Allan]

For anyone following, using temporary entitlements only gets rid of two of the 
four errors, so I still can't make scheduling via launchd work.

sandboxd still spits out:
launchctl(14634) deny job-creation

and Xcode/run log still gives:
launch_msg(): Socket is not connected

Other than rolling my own scheduling and writing a helper app which runs 
constantly in the background, can anyone think of a way around this?

Thanks
Mark

On 29 May 2012, at 09:52, Mark Allan wrote:

 The inherited entitlements don't allow access to that file, so I'm seeing 
 this from sandboxd in the log file:
 launchctl(4831) deny file-read-data 
 /private/var/db/launchd.db/com.apple.launchd.peruser.501/overrides.plist
 and
 launchctl(4831) deny job-creation
 
 I'm also seeing this in Xcode's run log:
 Bug: launchctl.c:2425 (25957):1: (dbfd = open(g_job_overrides_db_path, 
 O_RDONLY | O_EXLOCK | O_CREAT, S_IRUSR | S_IWUSR)) != -1
 launch_msg(): Socket is not connected


___

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

Crash while adding to NSTextView

[Mark Allan]

Hi all,

I've got an intermittent crash which occurs when adding an NSString to an 
NSTextView in my app's main window.  I very rarely experience the crash myself, 
but a relatively high number of users have reported it to me.

It finally happened to me while running the app from Xcode tonight, so I've got 
a chance to debug it, but I can't see what's going wrong.

The debugger console says:

Program received signal:  “EXC_BAD_ACCESS”.

Here's how the stack looks:
_NSLayoutTreeMoveToGlyphIndex
_NSLayoutTreeLineFragmentRectForGlyphAtIndex
-[NSLayoutManager(NSPrivate) _recalculateUsageForTextContainerAtIndex:]
-[NSLayoutManager textStorage:edited:range:changeInLength:invalidatedRange:]
-[NSTextStorage _notifyEdited:range:changeInLength:invalidatedRange:]
-[NSTextStorage processEditing]
-[NSTextStorage endEditing]
-[AppController appendToConsole:]

Here's the relevant piece of code which is pretty much straight from Apple's 
sample code:
-(void) appendToConsole:(NSString *)newText{
NSRange endRange;
endRange.location = [[consoleTextView textStorage] length];
endRange.length = 0;
[consoleTextView replaceCharactersInRange:endRange withString:newText]; 
/**/ crashes here
endRange.length = [newText length];
[consoleTextView scrollRangeToVisible:endRange];
}

The consoleTextView is defined in my header file as IBOutlet NSTextView 
*consoleTextView and I make no attempts to alloc/release/retain it anywhere in 
the application.

Printing the 'newText' object in the debugger console prints out the text I'm 
expecting to see (which in this case is just a carriage return), so I'm 
confident that's not where the problem lies.  Possibly relevant is that the 
text from the previous call to this method hadn't yet appeared in the 
NSTextView before the crash happened.

Does anyone have any ideas what the cause might be?

I've got other stuff to work on, so I'm going to leave it running/paused in the 
debugger in case anyone's got any questions or any suggestions I can try which 
might point me in the right direction - I'm not sure when I'll be able to get 
it back into this state!

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Crash while adding to NSTextView

[Mark Allan]

On 3 Feb 2011, at 00:36, Kyle Sluder wrote:
 On Wed, Feb 2, 2011 at 4:12 PM, Mark Allan markjal...@blueyonder.co.uk 
 wrote:
[consoleTextView replaceCharactersInRange:endRange 
 withString:newText]; /**/ crashes here
 
 You didn't call -shouldChangeTextInRange:replacementString: first, or
 call -didChangeText when you were done.
 
 When working with the text system, it's important to remember to check
 both the NSText and NSTextView documentation. The text system is quite
 possibly the most confusing part of Cocoa.

Thanks very much, Kyle.  I'll go back and read the documentation again - 
properly this time!  I assumed that the shouldChangeTextInRange delegate 
method was something called automatically by the AppKit framework and that I 
didn't have to worry about it.  Apple's sample code ('log' method on the URL 
below) on the developer documentation website doesn't have those calls either, 
so that pretty much cemented my misunderstanding.
http://tinyurl.com/BaseWindowController-m

Thanks again for setting me straight.

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Modifying TableHeaderCell

[Mark Allan]

On 2 Dec 2009, at 11:51 am, Gustavo Pizano wrote:

Hello, I know this has been asked, but the answers I have found on  
internet even gave me a light of what to do, i still can't  
accomplish what I want.


I subclassed NSTableHeaderView, NSTableHeaderCell, NSTableView  then  
I make the table header to be class of my custom class. Then I read  
that to modify the height of the cell I must override these methods:

- (NSRect)titleRectForBounds:(NSRect)theRect ;
and
- (void)drawInteriorWithFrame:(NSRect)cellFrame inView:(NSView  
*)controlView ;
I did so, making in the first method returning a rect with the  
desired dimensions. then on the awakefromnib of the custom class of  
NSTableView, I assign to the colum headder cell, an instance of my  
custom NSTableHeaderCell.


now in my custom NSTableHeaderView., in the drawRect method, Im  
drawing the propper background, and of course, I need to get the  
title of the cell to create a rect and draw the rect above the  
background, otherwise it will be not shown because its bellow.
But anyway.. Im a little bit confused on what should I do to make  
this work, Im still looking for examples, some of them showed me how  
to setup the background on the header, but I hadn't found anything  
to make the header bigger in height.


Have a look at Matt Gemmell's code called iTableColumnHeader.  You'll  
find it at http://mattgemmell.com/source


I don't think it changes the height of the header, but it's very easy  
to modify it to your needs.


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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: My try/catch block isn't catching exceptions on 10.6

[Mark Allan]

On 27 Nov 2009, at 1:10 am, Dave Keck wrote:

Exception Type:  EXC_BAD_ACCESS (SIGBUS)


After a cursory reading of your code it looks like you're dealing with
a threading issue involving myItemList or imminentList. Your comment
mentions We don't really care if imminentList changes because the
dictionary object will always be there even if the contents aren't.
Does this mean you're modifying imminentList from one thread while
another is attempting to read from it? If so, you need a lock around
the reads and writes.


Isn't it the case that you only need locks around something if you  
plan that it will be modified by more than one thread at a time, or if  
you write to it in another thread and care that any read operation  
will be predictable?


I *do* have locks around myItemList as this thread (and others) will  
be modifying that array, but not around imminentList as I'll only be  
reading it and I wanted to avoid a situation of over-locking things.   
Two other threads do modify imminentList and I use locking in there to  
safeguard those accesses.  In this thread, if the key *is* in  
imminentList, then that's fine and I don't need to do anything.  If  
it's not, that means either it was never in the list or that it was  
just removed from under my feet, either way I'm not that bothered so I  
take the safe option and add it to myItemList.



On 27 Nov 2009, at 12:22 pm, Jeremy Pereira wrote:
// We don't really care if imminentList changes because the  
dictionary object will always be there even if the contents aren't.


Yes you do.  NsMutableDictionary methods are not thread safe.  If  
you have other threads changing imminentList, while this thread is  
inserting stuff, you'll need locking.


Other threads do change imminentList, but their access to it is  
controlled via an NSLock.  This thread doesn't insert anything into  
imminentList at all, it merely checks for the existence of a  
particular key.  The only thing being inserted into is myItemList, and  
I use NSLocks around anything that accesses that too.


Looking at the code, I don't think there is anything in it that  
could throw an exception that you would want to handle.  sending  
objectToKey: to listToCopyFrom could raise an exception if it has  
become shorter between the loop test and sending the message, but  
that's a programmer error...


... and shouldn't happen because no other thread has access to  
listToCopyFrom.


Sending setObject:forKey: could throw an exception if the NSNumber  
is nil, but that would mean virtual memory exhaustion, what are you  
going to do if you catch an out of memory condition?  So I think  
your try catch block is superfluous in this instance.


The catch block *is* superfluous.  I only added it when I started  
seeing these crashlogs come in as an attempt to pin down what was  
happening.  At least I now know why it catch block wasn't being  
executed!


However, if there was an code that could throw an exception you  
wanted to handle, your block currently leaks an object reference,  
because the exception would bypass [listToCopyFrom release].  I tend  
to use the following idiom:


Yes, I have @finally blocks elsewhere for that reason.  Thanks  
though.  As I say, the try/catch was just something I was trying in a  
development version of my app.


I'll add some locking logic around my reads from imminentList and use  
an enumerator for listToCopyFrom  to see if that makes any difference.


Thanks all for your advice,
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

My try/catch block isn't catching exceptions on 10.6

[Mark Allan]

Hi folks,

I've got a section of code which crashes intermittently under 10.6 but  
despite being enclosed in try/catch blocks, my app is still forced to  
terminate.  For what it's worth, all of the crash reports are from  
10.6.x.  My app seems to be rock solid when run under 10.4 and 10.5.   
In fact, for one user, the same version of my app only started  
crashing after he had upgraded to 10.6.  It could be coincidental but  
I figured it was worth mentioning.


Anyway, the method (code below) loops through a mutable array of  
NSStrings. Each string acts as a key into two NSMutableDictionary  
objects (myItemList and imminentList).


If the key isn't found in either dictionary, it gets added to  
myItemList with an NSNumber value of -1.  After I've examined all the  
keys, the mutable array is emptied so we don't see these particular  
items again the next time round the thread's runloop.


I've got everything apart from the NSLock logic surrounded in a try/ 
catch block, but when it goes wrong the catch block doesn't get  
executed and my app crashes.


I can't reproduce the problem myself (my main dev machine is still  
10.5.8), but enough people have it that I know it's not an isolated  
incident.


The fact that it's crashing at CFBasicHashFindBucket implies some  
issue with the calls to objectForKey or setObject:ForKey, but does  
anyone know what could be causing it to crash so badly that my  
exception handler can't catch it?


Many thanks for your help,
Mark

PS. Yes, I know there are faster and more efficient ways to enumerate  
an array, but the old-school 'for' loop approach still comes to mind  
first and I still prefer it for small arrays.



Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0010
Crashed Thread:  3

Thread 3 Crashed:
0   com.apple.CoreFoundation  	0x9079e7aa  
___CFBasicHashFindBucket1 + 170
1   com.apple.CoreFoundation  	0x907a6aac CFBasicHashFindBucket +  
252

2   com.apple.CoreFoundation0x907a6973 CFDictionaryGetValue + 131
3   ...allan.identifier0x9e06 -[Dispatcher  
copyItemsToMyItemListFrom:] + 577

4   ...allan.identifier 0x99b9 -[Dispatcher 
mainLoop:] + 223
5   com.apple.Foundation0x940d58d8 -[NSThread main] + 45
6   com.apple.Foundation0x940d5888 __NSThread__main__ + 1499
7   libSystem.B.dylib   0x9435dfbd _pthread_start + 345
8   libSystem.B.dylib   0x9435de42 thread_start + 34


- (void) copyItemsToMyItemListFrom: (NSMutableArray *) listToCopyFrom {
	// we only need to lock the itemList as it's the only array whose  
contents may be changed by external threads. We don't really care if  
imminentList changes because the dictionary object will always be  
there even if the contents aren't.

[self getLock4itemList];
@try{
[listToCopyFrom retain];
int counter = 0;
for (counter=0; counter  [listToCopyFrom count]; counter++) {
NSString *theKey = [listToCopyFrom 
objectAtIndex:counter];
if(theKey != nil){
if ( ([myItemList objectForKey:theKey] == nil)  ([imminentList  
objectForKey:theKey] == nil)) {
	[myItemList setObject:[NSNumber numberWithLongLong:-1]  
forKey:theKey];

}
else{
//theKey already exists, don't add it 
again
}
}
}
		[listToCopyFrom removeAllObjects];	// remove all the objects so we  
don't see them again next time around
		[listToCopyFrom release];			// counteracts the retain at start of  
this method

}
@catch (NSException *e) {
NSLog(@Splat! Reason: %@, [e reason]);
}
[self releaseLock4itemList];
}

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Mac Mini or iMac for Cocoa Development?

[Mark Allan]

On 14 Sep 2009, at 1:59 pm, Jonathan Hendry wrote:

On Sep 13, 2009, at 19:28 PM, Paul Bruneau wrote:

The iMac is so much prettier plus can drive a second display.  
Refurb store = $999 or even sometimes $849 ones show up.


The Mini can drive additional displays if you connect them through  
USB video adapters. They work quite well, although they can't do  
OpenGL.


For what it's worth the current Mac Mini has two video out ports (mini  
display port and mini DVI) and is capable of running two displays at  
the same time:

http://www.apple.com/macmini/specs.html

Extended desktop and video mirroring: Simultaneously supports up to  
1920 by 1200 pixels on a DVI or VGA display; up to 2560 by 1600 pixels  
on a dual-link DVI display using Mini DisplayPort to Dual-Link DVI  
Adapter (sold separately)




___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Crash in CFRunLoopWakeUp

[Mark Allan]

On 4 Sep 2009, at 12:04 am, Greg Parker wrote:

On Sep 3, 2009, at 3:41 PM, Mark Allan wrote:
I've been battling with this intermittent crash for about two weeks  
now and can't figure it out for the life of me.  I've got try/catch  
blocks around nearly all my code, and definitely around any code  
which runs in a separate thread, but it's not catching whatever  
causes this crash.  Also, I'm not even convinced it's my threads  
causing the crash as this one happened while a modal sheet was  
being displayed, before any of my external threads got started.


Exception Type:  EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0001, 0x90d5c02c
Crashed Thread:  6

Thread 6 Crashed:
0   com.apple.CoreFoundation0x90d5c02c CFRunLoopWakeUp + 156
1   com.apple.Foundation  	0x903ad0e4 _backgroundActivity +  
440


EXC_BREAKPOINT means the process deliberately killed itself  
(including `int3` on i386, `trap` on ppc, `__builtin_trap()` in  
gcc). In the case of CFRunLoopWakeUp(), it's halting because it  
tried and failed to send a Mach message to that run loop. Most  
likely this means the target run loop has already been deleted, but  
other Mach messaging problems are possible.


_backgroundActivity is part of NSFileHandle, to perform things like - 
readInBackgroundAndNotify. Perhaps there's bad memory management of  
an NSFileHandle somewhere.


Thank you so much for your answer.

It turns out one of my threads was running after all and I think what  
was happening was that the NSTask started by my second thread was  
completing so quickly that the thread (and hence the run loop) was  
disappearing before some notification was being sent/received.  I was  
under the impression that the waitUntilExit method was supposed to  
prevent this from happening, but it doesn't appear to be doing so  
reliably.  Anyway, I've now moved all my -release calls into the  
object's dealloc method, removed the -waitUntilExit call and the  
NSTask is now being started from the main run loop.  Hopefully that  
covers all the bases.


Because it's an intermittent bug, it'll be a while before I can be  
sure I've managed to squash it once and for all, but initial reports  
look good :)

Thanks again
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Crash in CFRunLoopWakeUp

[Mark Allan]

Hi all,

I've been battling with this intermittent crash for about two weeks  
now and can't figure it out for the life of me.  I've got try/catch  
blocks around nearly all my code, and definitely around any code which  
runs in a separate thread, but it's not catching whatever causes this  
crash.  Also, I'm not even convinced it's my threads causing the crash  
as this one happened while a modal sheet was being displayed, before  
any of my external threads got started.


I'm fairly sure it's not a leak or a double-free - I've tried running  
with NSZombieEnabled, NSDebugEnabled, Malloc Guard, run the Clang  
Static Analyser over it and it's not showing anything up.


If I set NSExceptionHandlingMask to 63 in the terminal before  
launching my app, I get the following lines appearing in the console  
when a crash would have happened, and the application keeps running.   
The problem is, I can't seem to catch the exception anywhere.


NSExceptionHandler has recorded the following exception:
NSUncaughtSystemExceptionException -- Uncaught system exception:  
signal 5

Stack trace:  0x94f340a9  0x95294e3b  0x94f33b11  0xc0f2a  0xc121e
0x911502bb  0x  0x932e2556  0x91115155  0x91115012


Here's the crash log I mentioned earlier.  It's an intermittent crash  
and I'm going crazy trying to debug it.  Can anyone offer me any  
insight at all please?  Should I just burn an ADC support ticket and  
be done with it?


Many thanks for any help or suggestions you can give me.

Mark


Version: 2.0 (200)
Code Type:   PPC (Native)
Parent Process:  launchd [65]

Date/Time:   2009-08-27 11:32:25.003 -0700
OS Version:  Mac OS X 10.5.8 (9L30)
Report Version:  6
Anonymous UUID:

Exception Type:  EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0001, 0x90d5c02c
Crashed Thread:  6

Thread 0:
0   libSystem.B.dylib   0x95ece1f8 mach_msg_trap + 8
1   libSystem.B.dylib   0x95ed511c mach_msg + 56
2   com.apple.CoreFoundation  	0x90d61394 CFRunLoopRunSpecific +  
1812
3   com.apple.HIToolbox   	0x938a3b14  
RunCurrentEventLoopInMode + 264
4   com.apple.HIToolbox   	0x938a3938 ReceiveNextEventCommon +  
412
5   com.apple.HIToolbox   	0x938ead04  
IsUserStillTracking(MenuSelectData*, unsigned char*) + 472
6   com.apple.HIToolbox   	0x938d47a0  
TrackMenuCommon(MenuSelectData, unsigned char*) + 3180
7   com.apple.HIToolbox   	0x938cf854  
MenuSelectCore(MenuData*, Point, double, unsigned long,  
OpaqueMenuRef**, unsigned short*) + 228
8   com.apple.HIToolbox   	0x938cf3bc _HandleMenuSelection2 +  
388
9   com.apple.AppKit  	0x93147c54 _NSHandleCarbonMenuEvent  
+ 188

10  com.apple.AppKit0x930bd728 _DPSNextEvent + 1848
11  com.apple.AppKit  	0x930bcbfc -[NSApplication  
nextEventMatchingMask:untilDate:inMode:dequeue:] + 112

12  com.apple.AppKit0x930b689c -[NSApplication run] + 744
13  com.apple.AppKit0x93087298 NSApplicationMain + 440
14  uk.co.markallan.myapp   0x27f8 _start + 756
15  uk.co.markallan.myapp   0x24fc start + 44

Thread 1:
0   libSystem.B.dylib 	0x95ece278  
semaphore_timedwait_signal_trap + 8

1   libSystem.B.dylib   0x95f11368 _pthread_cond_wait + 1320
2   com.apple.Foundation  	0x9037f1a0 -[NSCondition  
waitUntilDate:] + 384
3   com.apple.Foundation  	0x9037efcc -[NSConditionLock  
lockWhenCondition:beforeDate:] + 268
4   com.apple.AppKit  	0x931189cc -[NSUIHeartBeat  
_heartBeatThread:] + 664

5   com.apple.Foundation0x90341d84 __NSThread__main__ + 1004
6   libSystem.B.dylib   0x95f100c4 _pthread_start + 316

Thread 2:
0   libSystem.B.dylib   0x95ece1f8 mach_msg_trap + 8
1   libSystem.B.dylib   0x95ed511c mach_msg + 56
2   com.apple.CoreFoundation  	0x90d61394 CFRunLoopRunSpecific +  
1812
3   com.apple.Foundation  	0x90398d50 + 
[NSURLConnection(NSURLConnectionReallyInternal) _resourceLoadLoop:] +  
280

4   com.apple.Foundation0x90341d84 __NSThread__main__ + 1004
5   libSystem.B.dylib   0x95f100c4 _pthread_start + 316

Thread 3:
0   libSystem.B.dylib   0x95ece1f8 mach_msg_trap + 8
1   libSystem.B.dylib   0x95ed511c mach_msg + 56
2   com.apple.CoreFoundation  	0x90d61394 CFRunLoopRunSpecific +  
1812
3   com.apple.CFNetwork   	0x94de63b0  
CFURLCacheWorkerThread(void*) + 288

4   libSystem.B.dylib   0x95f100c4 _pthread_start + 316

Thread 4:
0   libSystem.B.dylib   0x95f31d74 select$DARWIN_EXTSN + 12
1   com.apple.CoreFoundation0x90d6c808 __CFSocketManager + 764

Thread 5:
0   libSystem.B.dylib   0x95f0f904 kevent + 12
1   com.apple.CoreFoundation  	0x90d38a48  
__monitor_file_descriptor__ + 240


Thread 6 

Re: Recommendations to Reading the Xcode in built Documentation to the fullest effect

[Mark Allan]

I had the same problems with AppKiDo and eventually went back to  
Apple's online docs too.  They're definitely the most up-to-date  
version you're going to find anywhere, and when you've got your own  
way of using it, it works really well.  I tend to keep the main  
framework reference pages open and then middle-click the classname I'm  
interested in so that it opens in a new tab and I can quickly jump  
back and forth between the class listing and others I might be  
interested in...but that's just me.


FWIW, I initially came from a Java background and something I still  
really miss from the JavaDoc style API documentation is the group of  
sections entitled Methods inherited from XYZ.  Those sections make  
it incredibly easy to see at a glance what methods/messages your class  
supports without having to load the docs for each of the superclasses  
in turn until you find (or don't as the case may be!) what you're  
looking for.


Mark


On 26 May 2009, at 10:20 pm, Nathan wrote:
I used to have the same issue, and AppKiDo was recommended to me as  
well. But it's not built into Xcode like Apple's stuff, and it  
doesn't recieve doc changes instantly. Plus, it takes a little while  
to load which is always annoying. I went back to Apple's stuff and  
found that after awhile it worked fine. Class hierarchy-wise, it's  
just a matter of learning it and using common sense. Also, at the  
top of each class doc there's a list of superclasses, in order. So I  
would stick with Apple for a little longer and see if you can't  
learn to work with it.


Good luck, Nate

On May 26, 2009, at 4:48 PM, colo colo0l...@gmail.com wrote:


I want to really get Cocoa and iphone methods etc... so I find myself
in the Docs every other minute. But I find that it's kinda wonky to
see where things subclass from or what goes with what as examples. I
know there was some sort of guide to navigating it and learning from
it better.

Do you know of such a resource? Tried google. Still trying. Good
stuff, but nothing concrete yet.
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/lipton_lover%40mac.com

This email sent to lipton_lo...@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:
http://lists.apple.com/mailman/options/cocoa-dev/markjallan%40blueyonder.co.uk

This email sent to markjal...@blueyonder.co.uk




___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Getting results from Spotlight Saved Searches

[Mark Allan]

Hello all,

I'm implementing something which requires me to perform various tasks  
on a collection of files supplied by the user.  I'd like to be able to  
offer my users the ability to select a .savedSearch file and perform  
those tasks on the files which result from that search.


What I'm doing so far is reading the .savedSearch file into an  
NSDictionary, obtaining from that the RawQueryDict, extracting the  
values for RawQuery and SearchScopes, and I'm using those to setup  
an MDQueryRef.  When I execute the query, it works, but I get back  
many more files than are visible when the query is run in the Finder  
(ie when the user double clicks their .savedSearch file).


The extra items all appear to be coming from within the Library  
directory, such as searchScope/Library/Caches and Application  
Support, which I'm fairly sure the Finder will never show in search  
results.  Without me having to modify the RawQuery string to add  
filename/path checks, does anyone know how I can exclude the extra  
files and just show exactly what the Finder shows?


There *are* two other keys in the RawQueryDict - FinderFilesOnly and  
UserFilesOnly - both with a value of true so I'm assuming this is  
where my answer lies, but I don't know where to add these into the  
query.  I've tried various ways of including them in the raw query  
string but that usually leaves me with 0 results!


Here's the code I'm working with just now:
// Get the file, query string and search scope
	NSDictionary *plistContents = [NSDictionary  
dictionaryWithContentsOfFile:savedSearchFile];
	NSDictionary *rawQueryDict = [plistContents  
valueForKey:@RawQueryDict];

NSString *theQuery = [rawQueryDict valueForKey:@RawQuery];
NSArray *theScope = [rawQueryDict objectForKey:@SearchScopes];

// Create and execute the query
MDQueryRef query;
	query = MDQueryCreate(kCFAllocatorDefault, (CFStringRef)theQuery,  
NULL, NULL);

MDQuerySetSearchScope(query, (CFArrayRef)theScope, 0);
MDQueryExecute(query, kMDQuerySynchronous);

	// Loop through and print the paths to see why I'm getting so many  
results!

NSLog(@results found %d,MDQueryGetResultCount(query));
for (int j=0; jMDQueryGetResultCount(query); j++) {
MDItemRef item = MDQueryGetResultAtIndex(query, j);
		NSLog(@result %d: %@,j,(NSString *)MDItemCopyAttribute(item,  
kMDItemPath));

}

Any help would be greatly appreciated.
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: More - Safari Download Security Alerts

[Mark Allan]

On 16 Dec 2008, at 17:55, Dave wrote:
All I have done is to create an Installer with PackageMaker, but I  
can't get it to installer a folder with the files in it.


Have you tried using the version of PackageMaker which comes with  
Xcode 2.5?  I'm probably in the minority here, but I find it much  
easier to work with than the current version.  You can download Xcode  
2.5 DevTools from the ADC website and then opt to install it in a  
different directory from the current Dev Tools.  You won't be able to  
make use of 10.5 specific things like flat packages and signed  
packages etc. but if you're also targeting previous versions of OS X,  
then that's maybe not an issue 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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: open package installer in bundle resources directory not working

[Mark Allan]

Dennis,

You need to set the launch path of the executable within your NSTask -  
currently you're passing /usr/bin/open as an argument to nothing.   
There are two ways to do this: firstly, using the same logic you've  
got below, you can have the launch path be a shell and pass /usr/bin/ 
open as an argument to the shell; alternatively, make /usr/bin/open  
the launch executable.


Option one, notice the added -c switch to the shell:
[task setLaunchPath: @/bin/tcsh];
	[task setArguments: [NSArray arrayWithObjects: @-c, @/usr/bin/ 
open, path, nil]];

Option two:
[task setLaunchPath: @/usr/bin/open];
[task setArguments: [NSArray arrayWithObjects: path, nil]];

Caveat: This is from memory, but it shouldn't be too far off.

Mark

On 13 Dec 2008, at 02:48, Denis Bohm wrote:
I'm trying to distribute an installer within my own application  
bundle in the resources directory and run it from my application.   
When I try to run it from the debugger I get the error launch path  
not accessible.  However, if I then use the terminal to run the  
command by hand using the same path it works.


Anyone have any idea why it fails to run it from the application?



Code in my application:

NSTask* task = [[NSTask alloc] init];
NSString* path = [[NSBundle mainBundle]  
pathForResource:@FTDIUSBSerialDriver ofType:@pkg];

NSLog(path);
[task setArguments: [NSArray arrayWithObjects: @/usr/bin/open,  
path, nil]];

[task launch];

Output from the debugger when it fails:

2008-12-12 18:34:15.179 Firefly Upload Center[3364:813] /Users/denis/ 
sandbox/firefly/design/device/upload/mac/UploadCenter/build/Debug/ 
Firefly Upload Center.app/Contents/Resources/FTDIUSBSerialDriver.pkg

(gdb) continue
Current language:  auto; currently objective-c
Firefly Upload Center: unexpected exception:  
NSInvalidArgumentException: launch path not accessible

-[NSConcreteTask launchWithDictionary:] (in Foundation) + 2490
-[NSConcreteTask launch] (in Foundation) + 41
	-[FDApplication applicationDidFinishLaunching:] (in Firefly Upload  
Center) (FDApplication.m:67)

_nsnote_callback (in Foundation) + 364
__CFXNotificationPost (in CoreFoundation) + 362
_CFXNotificationPostNotification (in CoreFoundation) + 179
	-[NSNotificationCenter postNotificationName:object:userInfo:] (in  
Foundation) + 128
	-[NSNotificationCenter postNotificationName:object:] (in  
Foundation) + 56

-[NSApplication _postDidFinishNotification] (in AppKit) + 125
-[NSApplication _sendFinishLaunchingNotification] (in AppKit) + 77
	-[NSApplication(NSAppleEventHandling) _handleAEOpen:] (in AppKit) +  
284
	-[NSApplication(NSAppleEventHandling)  
_handleCoreEvent:withReplyEvent:] (in AppKit) + 98
	-[NSAppleEventManager  
dispatchRawAppleEvent:withRawReply:handlerRefCon:] (in Foundation) +  
655


This works from the command line:

open /Users/denis/sandbox/firefly/design/device/upload/mac/ 
UploadCenter/build/Debug/Firefly Upload Center.app/Contents/ 
Resources/FTDIUSBSerialDriver.pkg


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: open package installer in bundle resources directory not working

[Mark Allan]

An easier way may be to get NSWorkspace to do the work for you using  
the openFile: message.


http://tinyurl.com/NSWorkspace

Mark

On 13 Dec 2008, at 11:01, Mark Allan wrote:

Dennis,

You need to set the launch path of the executable within your NSTask  
- currently you're passing /usr/bin/open as an argument to nothing.   
There are two ways to do this: firstly, using the same logic you've  
got below, you can have the launch path be a shell and pass /usr/bin/ 
open as an argument to the shell; alternatively, make /usr/bin/open  
the launch executable.


Option one, notice the added -c switch to the shell:
[task setLaunchPath: @/bin/tcsh];
	[task setArguments: [NSArray arrayWithObjects: @-c, @/usr/bin/ 
open, path, nil]];

Option two:
[task setLaunchPath: @/usr/bin/open];
[task setArguments: [NSArray arrayWithObjects: path, nil]];

Caveat: This is from memory, but it shouldn't be too far off.

Mark

On 13 Dec 2008, at 02:48, Denis Bohm wrote:
I'm trying to distribute an installer within my own application  
bundle in the resources directory and run it from my application.   
When I try to run it from the debugger I get the error launch path  
not accessible.  However, if I then use the terminal to run the  
command by hand using the same path it works.


Anyone have any idea why it fails to run it from the application?



Code in my application:

NSTask* task = [[NSTask alloc] init];
NSString* path = [[NSBundle mainBundle]  
pathForResource:@FTDIUSBSerialDriver ofType:@pkg];

NSLog(path);
[task setArguments: [NSArray arrayWithObjects: @/usr/bin/open,  
path, nil]];

[task launch];

Output from the debugger when it fails:

2008-12-12 18:34:15.179 Firefly Upload Center[3364:813] /Users/ 
denis/sandbox/firefly/design/device/upload/mac/UploadCenter/build/ 
Debug/Firefly Upload Center.app/Contents/Resources/ 
FTDIUSBSerialDriver.pkg

(gdb) continue
Current language:  auto; currently objective-c
Firefly Upload Center: unexpected exception:  
NSInvalidArgumentException: launch path not accessible

-[NSConcreteTask launchWithDictionary:] (in Foundation) + 2490
-[NSConcreteTask launch] (in Foundation) + 41
	-[FDApplication applicationDidFinishLaunching:] (in Firefly Upload  
Center) (FDApplication.m:67)

_nsnote_callback (in Foundation) + 364
__CFXNotificationPost (in CoreFoundation) + 362
_CFXNotificationPostNotification (in CoreFoundation) + 179
	-[NSNotificationCenter postNotificationName:object:userInfo:] (in  
Foundation) + 128
	-[NSNotificationCenter postNotificationName:object:] (in  
Foundation) + 56

-[NSApplication _postDidFinishNotification] (in AppKit) + 125
-[NSApplication _sendFinishLaunchingNotification] (in AppKit) + 77
	-[NSApplication(NSAppleEventHandling) _handleAEOpen:] (in AppKit)  
+ 284
	-[NSApplication(NSAppleEventHandling)  
_handleCoreEvent:withReplyEvent:] (in AppKit) + 98
	-[NSAppleEventManager  
dispatchRawAppleEvent:withRawReply:handlerRefCon:] (in Foundation)  
+ 655


This works from the command line:

open /Users/denis/sandbox/firefly/design/device/upload/mac/ 
UploadCenter/build/Debug/Firefly Upload Center.app/Contents/ 
Resources/FTDIUSBSerialDriver.pkg


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/markjallan%40blueyonder.co.uk

This email sent to markjal...@blueyonder.co.uk




___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

How to read proxy username and password?

[Mark Allan]

Hi all,

I've got an application which uses a third party command line tool to download 
some files from the web.  Unfortunately, the command line tool won't work with 
a proxy server unless the proxy settings are written in clear text (ugly but 
nothing I can do about that) in a config file.  The config file itself is 
read/write only by root, so it's not *quite* as hideous as it could be ;-)

Anyway, writing to the config file isn't a problem.  My question is how can I 
read the System proxy username and password settings from within my application 
in order to be able to write them to the file?

I've searched through the mailing list archives and had a look at the 
SystemConfiguration Framework API but still can't quite find what I'm looking 
for.  The closest thing I can see is SCDynamicStoreCopyProxies but that only 
returns the following keys in the dictionary:
kSCPropNetProxiesExceptionsList
kSCPropNetProxiesHTTPEnable
kSCPropNetProxiesHTTPProxy
kSCPropNetProxiesHTTPPort
kSCPropNetProxiesHTTPSEnable
kSCPropNetProxiesHTTPSProxy
kSCPropNetProxiesHTTPSPort
kSCPropNetProxiesFTPEnable
kSCPropNetProxiesFTPProxy
kSCPropNetProxiesFTPPort
kSCPropNetProxiesFTPPassive
none of which is what I'm looking for.

Can anyone help please?

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: How to read proxy username and password?

[Mark Allan]

Gah I feel like such a numpty now!  Yes, that's exactly where it's stored.

Thank you!

Mark

At 3:31 pm -0700 31/10/2008, Colin Barrett wrote:

Is it possible they're stored in Keychain?

-Colin

  Anyway, writing to the config file isn't a problem.  My question 
is how can I read the System proxy username and password settings 
from within my application in order to be able to write them to the 
file?



___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

RE: Re: Static text over an image

[Mark Allan]

I've seen this happen *every* time in IB if the items in question are within an 
NSView.  It was driving me crazy for a while until I figured out (completely by 
accident) that the order has to be reversed when you're setting up the NIB/XIB 
file for it to work correctly.

It's a real PITA because to see and edit the text which you want, eventually, 
to appear on top of the image, you constantly have to select the image/text and 
go the Layout menu and move it back and forward as required, and then remember 
to move the text back behind the image before you save and rebuild your project.


Mark 
PS. Apologies if this message arrives twice - I'm not convinced it sent 
properly first time.

-Begin Quoted Message-

I've seen it happen a few times where views will be layered in the  
reverse order that they're set to in IB. Try moving the label behind  
the image and see if that gives you the desired result.

Cheers,
Brandon

On 30-Oct-08, at 12:48 AM, Andre Masse wrote:

 Hi,

 I want to have text over an image. Even though I set it up in IB  
 (move image to the back, bring the label to the front), the label is  
 always drawn behind the image. Is there a setting to be set in IB  
 for that or do I have to draw the text myself?

 Thanks,

 Andre Masse

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Universal app fails on PPC.

[Mark Allan]

At 8:08 pm -0400 06/10/2008, David Melgar wrote:
Given that I don't have access to a ppc machine, sounds like I can't 
test if it works.


Given that it's obviously a leopard only application, I'm not sure 
if I should claim support for ppc and have a user complain if it 
doesn't work, or drop the claim of ppc support and make it intel 
only.


As a (quad core) G5 user who will not be cross-grading to Intel any 
time soon, please don't deliberately remove PPC support just because 
you haven't been able to test it...unless of course not being able to 
test it may result in some hideous data loss should a PPC user find a 
bug!


You have a few options.
1) As Clark already said, you could buy a cheap second hand PPC machine.
2) Ask other people to test the app before you release it
3) Make use of the ADC compatibility labs to test it for yourself

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Problem with NSUserDefaultsController

[Mark Allan]

I think I've fixed the the problem, thanks to an idea I had whilst reading 
Oleg's Bindings - newbie question thread.

I've added a message within -init to bind my model's variable (theValue) to the 
appropriate value (thevalue) within the standardUserDefaults dictionary 
(myPrefs).  Apologies for the similarities in naming the variable and the key - 
I know it can make readability hard for others, but it's how my mind works 
unfortunately!

[self bind:@theValue toObject:myPrefs withKeyPath:@thevalue options:nil];

For completeness, here's the full code which *appears* to work:

-(id)init {
if(self = [super init]){
shared = [NSUserDefaultsController 
sharedUserDefaultsController];
[shared setAppliesImmediately:NO];
myPrefs = [NSUserDefaults standardUserDefaults];
[self bind:@theValue toObject:myPrefs withKeyPath:@thevalue 
options:nil];
}
return self;
}

-(void) savePrefs:(NSObject *) sender{
// save prefs and close the window
[shared save:self];
}

-(void) checkValue:(NSObject *) sender{
NSLog(@value is %@,theValue);
}

-(void) revertPrefs:(NSObject *) sender{
// revert and close the window
[[NSUserDefaultsController sharedUserDefaultsController] revert:sender];
}


For what it's worth, the [sharedUserDefaultsController save:] message is still 
returning before performing the save, so if I send any other messages within my 
savePrefs method, userDefaults will still contain the old value - I'm beginning 
to wonder if this is a bug within NSUserDefaultsController.

This may not be the right way to do it, but for my purposes, I think it's 
probably OK.

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Problem with NSUserDefaultsController

[Mark Allan]

  For what it's worth, the [sharedUserDefaultsController save:] 
message is still

 returning before performing the save, so if I send any other messages within
 my savePrefs method, userDefaults will still contain the old value - I'm
 beginning to wonder if this is a bug within NSUserDefaultsController.


As someone else suggested, it appears that the -save method uses a delayed
method call to update NSUserDefaults. Binding is a perfectly acceptable way
to do this. Alternatively, you can get the value directly from the defaults
controller, as it is always immediately changed there:

theValue = [[shared values] valueForKey:@thevalue];



You know, I could swear blind that I had already tried that, but I've 
just done it now and it works!  Maybe that's what comes of coding at 
1am!




Some other suggestions: storing the shared defaults and controller is really
just a waste of memory. They won't change across invocations.



With the overhead of Objective C messaging, isn't it more efficient 
to obtain once and store the shared defaults and controller for later 
use?  Admittedly, we're probably splitting hairs here with a very 
small number of messages vs very small memory requirement, but I was 
always taught that space is cheaper than time.  If necessary, space 
can be reclaimed whereas (cpu) time can't.



It would also be a good idea to keep your types consistent: a slider 
expects to manipulate a numeric value, and as you see it stores its 
value as a number in the prefs. Your object property should also be 
an NSNumber, not an NSString.


Yes, that was just laziness on my part as I played around with this. 
This particular app will never actually do anything, I was simply 
trying to see how it will work when I start writing the preferences 
routines for my real application.  The types will definitely match 
when I do it for that one! :)


M

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Problem with NSUserDefaultsController

[Mark Allan]

  I've been playing around with bindings to NSUserDefaultsController in

 a very simple app to test saving preferences, but the
 [sharedUserDefaultsController save:self] method seems to return 
immediately

 without waiting for the save operation to complete.

 The save does actually take place, which I can see if I open the 
plist file

 in Property List Editor, but if the very next line after sending the save
 message is one which reads a property from the plist, it's the old value
 which gets returned rather than the newly saved one.


 The -save: method is unintuitive in name. It does not, as you may  think,
 save changes to disk. It simply commits any changes to the  NSUserDefaults
 object. It's a no-op if appliesImmediately is YES. The only way to  force a
 save is to call -synchronize on NSUserDefaults.


 Thanks but the problem is actually the exact opposite. The file IS  being
 saved - it's the userdefaults object which doesn't contain the  right value
 unless there's some short delay between the save and  objectForKey messages.


Sorry, I misread your post. We will need to see some code to determine the
issue.


 Calling -synchronize on the userDefaults object makes no difference.

 I'm already setting appliesimmediately to YES so that I can have
 Cancel and OK buttons, and in terms of saving/reverting the plist file
 it's working fine. Do I need to perform some action to connect the
 userdefaults object to the userDefaultsController object?


Well, not other than binding it to the shared user defaults (unless you are
creating it programmatically, where it is set on creation). My understanding
is that the NSUserDefaults object is responsible for writing to disk, so if
you get the disk commit, it must be in the shared defaults.


Exactly!  That's my understanding too, which is why I'm confused.

The complete Xcode project is available here:
http://idisk.mac.com/markallan-Public/TestingNSUserDefaultsController.zip

If anyone has time to cast an eye over it, I'd really appreciate it.

Thanks

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Problem with NSUserDefaultsController

[Mark Allan]

Hi,

I've been playing around with bindings to NSUserDefaultsController in 
a very simple app to test saving preferences, but the 
[sharedUserDefaultsController save:self] method seems to return 
immediately without waiting for the save operation to complete.


The save does actually take place, which I can see if I open the 
plist file in Property List Editor, but if the very next line after 
sending the save message is one which reads a property from the 
plist, it's the old value which gets returned rather than the newly 
saved one.


My test app consists of only one window with a slider (whose value is 
bound to the Shared User Defaults Controller), and three buttons: one 
connected to savePrefs, one to revertPrefs, and one to checkValue 
which prints out the slider's value as stored within the model.


Here's the entire code:

-(id)init {
[super init];
	[[NSUserDefaultsController sharedUserDefaultsController] 
setAppliesImmediately:NO];

myPrefs = [NSUserDefaults standardUserDefaults];
[self readPrefs];
return self;
}

-(void) readPrefs{
//[myPrefs synchronize];  //this line doesn't make any difference
theValue = [myPrefs objectForKey:@thevalue];
}

-(void) savePrefs:(NSObject *) sender{
// save prefs and close the window
[[NSUserDefaultsController sharedUserDefaultsController] save:self];
[self readPrefs];
}

-(void) checkValue:(NSObject *) sender{
NSLog(@value is %@,theValue);
}

-(void) revertPrefs:(NSObject *) sender{
// revert and close the window
	[[NSUserDefaultsController sharedUserDefaultsController] 
revert:sender];

}

If I move [self readPrefs] out of the savePrefs method and into 
checkValue, it prints the new value as expected - but I don't want to 
be reading the preferences every time I need to use that particular 
variable.  Can someone explain the right way to do this please?


For what it's worth, I also get these compiler warnings for the line 
with [sharedUserDefaultsController save:]


warning: multiple methods named '-save:' found
warning: using '-(void)save:(id)sender'
warning: also found '-(BOOL)save:(NSError **)error'

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Problem with NSUserDefaultsController

[Mark Allan]

On 31 Aug 2008, at 17:25, Keary Suska  wrote:


8/31/08 10:13 AM, also sprach:


I've been playing around with bindings to NSUserDefaultsController in
a very simple app to test saving preferences, but the
[sharedUserDefaultsController save:self] method seems to return
immediately without waiting for the save operation to complete.

The save does actually take place, which I can see if I open the
plist file in Property List Editor, but if the very next line after
sending the save message is one which reads a property from the
plist, it's the old value which gets returned rather than the newly
saved one.


The -save: method is unintuitive in name. It does not, as you may  
think,
save changes to disk. It simply commits any changes to the  
NSUserDefaults
object. It's a no-op if appliesImmediately is YES. The only way to  
force a

save is to call -synchronize on NSUserDefaults.


Thanks but the problem is actually the exact opposite. The file IS  
being saved - it's the userdefaults object which doesn't contain the  
right value unless there's some short delay between the save and  
objectForKey messages.


Calling -synchronize on the userDefaults object makes no difference.

I'm already setting appliesimmediately to YES so that I can have  
Cancel and OK buttons, and in terms of saving/reverting the plist file  
it's working fine. Do I need to perform some action to connect the  
userdefaults object to the userDefaultsController object?


Mark

Ps. Email on the iPod touch is impossible - it's taken me about 40  
minutes to write this cos the delete button keeps repeating and  
dfeleting half the message!

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Including frameworks in your app bundle

[Mark Allan]

I've been searching, but I can't find the documentation explaining 
how to include frameworks in your app bundle (third-party 
frameworks, for example), so that your user does not have to 
install these frameworks. Could someone point me at the correct 
documentation/build settings? Thanks.


This is probably better for the XCode group, but check out this document:

http://developer.apple.com/documentation/MacOSX/Conceptual/BPFrameworks/Tasks/CreatingFrameworks.html

It explains what you need to do to embed frameworks in your application.

HTH, J


As a shortcut to what you need, this website makes it very clear how 
to embed someone else's framework in your application.


http://rentzsch.com/cocoa/embeddedFrameworks

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Simple NSMutableDictionary problem

[Mark Allan]

At 9:12 pm + 12/08/2008, Matt Keyes wrote:

How do I have an int as a value in a NSMutableDictionary object?

for example:

NSMutableDictionary *myDictionary = [NSMutableDictionary alloc];

int i = 1;

[myDictionary setValue:1 forKey:@One];

This causes a compiler warning:

warning: passing argument 1 of 'setValue:forKey:' makes pointer 
from integer without a cast


It seems like (b/c the type is id for the first param) that 
NSMutableDictionary wants a pointer.  Well, how do I give it just a 
plain integer copy without having the compiler yell at me?  I have 
been banging my head on my desk over this silly little thing.


Also, how do I define a non-mutable dictionary of a particular size? 
There is no dictionaryWithCapacity function that I can find in the 
non-mutable version.  All the examples I can find are not practical 
(i.e. hardcoding a dictionary at its creation with random values 
like @One, @Two, etc.).


Thanks!
Matt


You need to pass it an NSNumber.  Do something like this:

[myDictionary setObject:[NSNumber numberWithInt:1] forKey:@one];


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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Does [NSApp setApplicationIconImage] leak memory?

[Mark Allan]

 Your idea of removing the

array from the equation also solves the leak and I suspect is more
efficient than creating and releasing a tonne of autorelease pools.


Really? Can you explain what removing the array from the equation has to
do with the memory behavior you're seeing? m.


No, sadly I can't explain it, but it does prevent the memory from leaking.

I changed my initialiser calls from
NSArray *imageX = [[NSArray arrayWithObjects: [NSImage 
imageNamed:@menu_frame1], [NSImage imageNamed:@dock_frame1], nil] 
retain];


to

NSImage *dockImageX = [[NSImage imageNamed:@dock_frame1] retain];

and for each frame of the animation, I'm passing that NSImage 
directly to the [NSApp setApplicationIconImage:theNewImage] call. 
Even without the autorelease pools, the app's memory usage now stays 
constant after the first animation of all 8 frames.


I fail to see how [NSApp setApplicationIconImage:theNewImage]; is any 
different to [NSApp setApplicationIconImage:[theNewImage 
objectAtIndex:1]] but it obviously does function differently.


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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Does [NSApp setApplicationIconImage] leak memory?

[Mark Allan]

On Thu, 7 Aug 2008 20:14:04 +0100, Mark Allan [EMAIL PROTECTED]
said:

Hi all,

Before I file a bug report against this, I just thought I'd check I'm
not being monumentally stupid first!

I'm trying to animate my app's Dock icon, which works fine and looks
great, but unfortunately, it appears to leak memory like crazy.
Every time I call [NSApp setApplicationIconImage:(NSImage *)] and
pass it pointer to an existing image, it leaks more memory.


Wrap each call to setApplicationIconImage in an autorelease pool creation
and release, like this:

NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
[NSApp setApplicationIconImage: whatever];
[pool release];

I think you'll find that solves the problem.


Sorry, I should have said in my original message that I'd already 
tried that, and the autorelease pool did solve the problem. It's just 
that doing this hundreds (possibly thousands) of times until my 
process is finished seems horribly inefficient.  Do you know if it's 
actually a leak or if it's like that by design?



___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Does [NSApp setApplicationIconImage] leak memory?

[Mark Allan]

On Fri, Aug 8, 2008 at 9:02 AM, Matt Neuburg [EMAIL PROTECTED] wrote:

 On Thu, 7 Aug 2008 20:14:04 +0100, Mark Allan [EMAIL PROTECTED]
 said:

Hi all,

Before I file a bug report against this, I just thought I'd check I'm
not being monumentally stupid first!

I'm trying to animate my app's Dock icon, which works fine and looks
great, but unfortunately, it appears to leak memory like crazy.
Every time I call [NSApp setApplicationIconImage:(NSImage *)] and
pass it pointer to an existing image, it leaks more memory.


 Wrap each call to setApplicationIconImage in an autorelease pool creation
 and release, like this:

NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
[NSApp setApplicationIconImage: whatever];
[pool release];

 I think you'll find that solves the problem.


  m.

At 6:24 pm -0400 08/08/2008, Sumner Trammell wrote:

Ok, stupid question time.

1. Is the need for the autorelease pool because of the use of
setApplicationIconImage, or because of the array that is being used in
conjunction with setApplicationIconImage?

2. Would putting the calls to setApplicationIconImage in a class
method also stop the memory leak?

Thanks,

-s


Certainly not a stupid question, in fact, now *I* feel stupid for not 
trying that first suggestion earlier.  Your idea of removing the 
array from the equation also solves the leak and I suspect is more 
efficient than creating and releasing a tonne of autorelease pools.


Thanks guys.

M

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Confusion over FSMoveObjectToTrashSync docs

[Mark Allan]

Which options argument are you talking about?  I just do the 
following and it works as advertised.


[[NSWorkspace sharedWorkspace] 
performFileOperation:NSWorkspaceRecycleOperation 
source:parentDirOfFile destination:@ files:[NSArray 
arrayWithObject:@fileName] tag:nil]


The only slightly irritating bit is that you have to supply the file 
name and the parent directory.  You can't just pass it a path for 
some reason.


Keep destination as the empty string (not nil) and your file will be 
renamed as required when it hits the trash.


Mark


At 3:12 pm -0500 07/08/2008, Nate Weaver wrote:
I'd say just try the default options and see what happens. You might 
also look at -[NSWorkspace 
performFileOperation:source:destination:files:tag:] with 
NSWorkspaceRecycleOperation as the first argument.


On Aug 7, 2008, at 2:03 PM, Randall Meadows wrote:

The description for FSMoveObjectToTrashSync says: This function 
moves a file or directory to the Trash, adjusting the object's name 
if necessary.  (Meaning, I suppose, it appends a number to the 
filename to make it unique in the Trash directory.)


Lovely, *exactly* what I need to do.  Happy happy, joy joy!

However, when I get into actually writing the code, I get to the 
options argument, which are described as:


kFSFileOperationDefaultOptions
Use the following default options:

*If the destination directory contains an object with the same name 
as a source object, abort the operation.


kFSFileOperationOverwrite
If the destination directory contains an object with the same name 
as a source object, overwrite the destination object.



Um, what happened to that part about adjusting the object's name 
if necessary?  According to the options flags, that is not 
possible; it's either abort the operation or overwrite.


Anyone know the skinny on this actually works?  The way I want to 
use this function is to move a file that resides in a document 
bundle into the Trash directory that resides on the same volume as 
the document bundle (and yes, I understand that not all volumes 
support Trash folders, I can handle that).


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]