Re: NSRunningApplication executableURL issue in Swift

[Quincey Morris]

On Mar 10, 2015, at 22:57 , dangerwillrobinsondan...@gmail.com wrote:
> 
> This is one extra thing you have to really get used to with Swift. You learn 
> Swift, then learn that it effectively requires some constant special handling 
> for NSObject's descendants. 
> If you're using the frameworks that's a lot of optionals and implicitly 
> unwrapped optionals. 

It’s not the optionals that are the problem, nor the implicit unwrapping. Those 
things are just the symptoms in this case.

The problem I was referring to was implicit forced downcasting. It seems so 
arbitrary — both the fact that it downcasts without provocation, and the 
(apparent, potential) randomness of what it downcasts to.

___

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: NSRunningApplication executableURL issue in Swift

[dangerwillrobinsondanger]

>> On 2015/03/11, at 14:44, Quincey Morris 
>>  wrote:
>> 
>> On Mar 10, 2015, at 22:26 , Bavarious  wrote:
>> 
>> Much like in Objective-C. If you write
>> 
>> void someFunction(id obj) {
>>   NSLog(@"%@", [obj bundleURL]);
>> }
>> 
>> the compiler picks *some* method that matches that selector
> 
> So how come this behavior has been imported into Swift? What problems does 
> having it there actually solve? Other languages are going to laugh at us and 
> take our lunch money if we have types like ‘NSURL!?’.
> 
>> ―which method is undefined. This can be problematic when multiple methods 
>> have the same selector but different types; in particular, when one method 
>> has a floating-point type in its signature and another method doesn’t.
> 
> That’s what I don’t understand for Swift. None of the reasons I can imagine 
> for *not* removing this behavior from Obj-C** seem applicable to Swift.
This is simply part of the evolving state of affairs. 
For now, this is part of life if you use Swift and you use objects that inherit 
from NSObject. 

There's an impedance mismatch ever so small but annoying. 

Swift hates nil or potentially nil and wants to know if something is expected 
to potentially be nil. 

Objective-C and Cocoa built loads of incredible clever patterns with nil. 

This is one extra thing you have to really get used to with Swift. You learn 
Swift, then learn that it effectively requires some constant special handling 
for NSObject's descendants. 
If you're using the frameworks that's a lot of optionals and implicitly 
unwrapped optionals. 

> 
> ** such as:
> 
> #1: Historical precedent (Swift is all-new source code)
> #2: Ugly cast syntax to clarify which selector is intended (Swift has ‘as!’)
> #3: Obscures full-on polymorphism (rarely used in many classes of apps, more 
> common usage of limited polymorphism is better expressed via protocols, which 
> are more capable in Swift)
> 
> 
> 
> ___
> 
> 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/dangerwillrobinsondanger%40gmail.com
> 
> This email sent to dangerwillrobinsondan...@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: NSRunningApplication executableURL issue in Swift

[Quincey Morris]

On Mar 10, 2015, at 22:26 , Bavarious  wrote:
> 
> Much like in Objective-C. If you write
> 
> void someFunction(id obj) {
>NSLog(@"%@", [obj bundleURL]);
> }
> 
> the compiler picks *some* method that matches that selector

So how come this behavior has been imported into Swift? What problems does 
having it there actually solve? Other languages are going to laugh at us and 
take our lunch money if we have types like ‘NSURL!?’.

> —which method is undefined. This can be problematic when multiple methods 
> have the same selector but different types; in particular, when one method 
> has a floating-point type in its signature and another method doesn’t.

That’s what I don’t understand for Swift. None of the reasons I can imagine for 
*not* removing this behavior from Obj-C** seem applicable to Swift.


** such as:

#1: Historical precedent (Swift is all-new source code)
#2: Ugly cast syntax to clarify which selector is intended (Swift has ‘as!’)
#3: Obscures full-on polymorphism (rarely used in many classes of apps, more 
common usage of limited polymorphism is better expressed via protocols, which 
are more capable in Swift)



___

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

Different notification icons in push notifications

[Claudio M. E. Bastos Iorio]

Hello everyone,

I've been looking everywhere and as far as I understand, the following is
not actually possible, but.. could you guys confirm?

Is it possible to have different icons for different push notifications on
the same iOS application?

 

For example: let's say that I'm displaying a Banner notification as
described here:
https://developer.apple.com/library/ios/documentation/UserExperience/Concept
ual/MobileHIG/NotificationCenter.html  the icon displayed will be the app
icon included in the info.plist, right? Is there any chance to have
different icons instead? (one icon for a "POSITIVE/APPROVED/ETC"
notification and other ICON for "DENIED/NEGATIVE/ETC" notification..)

 

Thanks in advance,  

 

 

Claudio M. E. Bastos Iorio

 

___

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: NSRunningApplication executableURL issue in Swift

[Bavarious]

> On Mar 10, 2015, at 21:17, Roland King  wrote:
> 
> 
>> On 11 Mar 2015, at 00:24, Bill Cheeseman  wrote:
>> 
>> I'm using Xcode 6.2 and Swift 1.1.
>> 
>> 1. The following statement reports the error "'NSURL?' does not have a 
>> member named 'path'" even though executableURL has a trailing exclamation 
>> point to unwrap it. The caret identifying the location of the error is 
>> placed under the exclamation point.
>> 
>> for thisApp in NSWorkspace.sharedWorkspace().runningApplications {
>>let thisPath = thisApp.executableURL!.path // ERROR
>> }
>> 
>> If I change executableURL to bundleURL, the error goes away. Yet 
>> executableURL and bundleURL are declared identically according to the 
>> NSRunningApplication reference document. As far as I know, bundleURL and 
>> executableURL both satisfy fileURL.
>> 
>> The error also goes away if I assign thisApp to a local variable and 
>> expressly downcast it to NSRunningApplication, as shown below. Why would I 
>> need to do that with executableURL, when it isn't necessary with bundleURL?
>> 
>> for thisApp in NSWorkspace.sharedWorkspace().runningApplications {
>>let myAppAndIMeanIt = thisApp as NSRunningApplication
>>let thisPath = myAppAndIMeanIt.executableURL!.path // NO ERROR
>> }
>> 
>> Is this a Swift bug?
>> 
> 
> No, one of yours again - although I don't really understand what's going on 
> with the plethora of optionals it's pretty easy, using something I've 
> recommended dozens of times, to gain insight into what the compiler thinks 
> it's doing by, as usual, splitting the line up into two assignments and using 
> opt option+click to see what type it has guessed things are. 
> 
> In the first case if you split out thisApp.executableURL into its own line 
> you will find it's of type 'NSURL?!'. I actually don't know entirely what 
> that means, an implicitly unwrapped optional to an optional. I suppose it's 
> means it's possibly something which is possibly an NSURL with an implicit 
> guarantee that it's not nothing at all. 

.executableURL has type NSURL? in all Cocoa classes that provide it (NSBundle & 
NSRunningApplication), so that’s one optionality level.

Note that `thisApp` has type AnyObject because 
NSWorkspace.runningApplications() returns [AnyObject]. But 
thisApp.executableURL forces Swift to downcast `thisApp` to some type that 
provides .executableURL, and this downcast might succeed or not — there’s the 
other optionality level.

> Anyway your '!' before '.path' just unwraps the implicitly unwrapped optional 
> bit. Yes I know it's implicitly unwrapped already but I believe the '!' just 
> unwraps it from implicitly unwrapped optional to optional NSURL to really 
> unwrapped, ie optional NSURL. So you need two '!!', one for the '!' and one 
> for the '?'. 
> 
> let thisPath = thisApp.executableURL!!.path
> 
> I tried to move the ugliness around a bit, you can do 
> 
> for thisApp in NSWorkspace.sharedWorkspace().runningApplications as [ 
> NSRunningAppliction ]
> {
>   let thisPath = thisApp.executableURL!.path
> }
> 
> except in 6.3 now you can't do that, you have to have 'as!', so it isn't much 
> nicer although possibly more consistent
> 
> 
> Why does this happen with executableURL and not bundleURL, I don't really 
> know. Both those properties are defined on both NSBundle and 
> NSRunningApplication however the bundleURL is non-optional on both of them 
> and the executableURL is optional on NSRunningApplication but not on 
> NSBundle. Since runningApplications returns an [ AnyObject ] I assume there's 
> one level of optionality in err ... something and then another one in 
> executableURL because it might be optional, or not. 

Much like in Objective-C. If you write

void someFunction(id obj) {
NSLog(@"%@", [obj bundleURL]);
}

the compiler picks *some* method that matches that selector—which method is 
undefined. This can be problematic when multiple methods have the same selector 
but different types; in particular, when one method has a floating-point type 
in its signature and another method doesn’t.

In Objective-C, -bundleURL isn’t a problem. In Swift, it can be a problem 
because NSBundle.bundleURL has type NSURL (not an optional) whereas 
NSRunningApplication.bundleURL has type NSURL? (an optional). In Bill’s case, 
the compiler is choosing NSBundle.bundleURL. Which method/property is chosen is 
probably undefined in Swift as well.

> 
> Amusing crash of the day whilst trying to work this out
> 
> import Cocoa
> 
> for thisApp in NSWorkspace.sharedWorkspace().runningApplications  
> {
>   //let pp = thisApp as! NSRunningApplication
>   let tt = thisApp.bundleURL!.path
> }
> 
> works fine. However if you uncomment the commented line, which does nothing 
> but set an unused variable, the line below crashes with EXC_i386_INVOP. 
> That's 6.3, in 6.2 you have to remove the '!' in the commented line after the 
> 'as', however you still get the same crash. 
> 
> All this to work around nil, a co

Re: NSRunningApplication executableURL issue in Swift

[Roland King]

> On 11 Mar 2015, at 00:24, Bill Cheeseman  wrote:
> 
> I'm using Xcode 6.2 and Swift 1.1.
> 
> 1. The following statement reports the error "'NSURL?' does not have a member 
> named 'path'" even though executableURL has a trailing exclamation point to 
> unwrap it. The caret identifying the location of the error is placed under 
> the exclamation point.
> 
> for thisApp in NSWorkspace.sharedWorkspace().runningApplications {
> let thisPath = thisApp.executableURL!.path // ERROR
> }
> 
> If I change executableURL to bundleURL, the error goes away. Yet 
> executableURL and bundleURL are declared identically according to the 
> NSRunningApplication reference document. As far as I know, bundleURL and 
> executableURL both satisfy fileURL.
> 
> The error also goes away if I assign thisApp to a local variable and 
> expressly downcast it to NSRunningApplication, as shown below. Why would I 
> need to do that with executableURL, when it isn't necessary with bundleURL?
> 
> for thisApp in NSWorkspace.sharedWorkspace().runningApplications {
> let myAppAndIMeanIt = thisApp as NSRunningApplication
> let thisPath = myAppAndIMeanIt.executableURL!.path // NO ERROR
> }
> 
> Is this a Swift bug?
> 

No, one of yours again - although I don't really understand what's going on 
with the plethora of optionals it's pretty easy, using something I've 
recommended dozens of times, to gain insight into what the compiler thinks it's 
doing by, as usual, splitting the line up into two assignments and using opt 
option+click to see what type it has guessed things are. 

In the first case if you split out thisApp.executableURL into its own line you 
will find it's of type 'NSURL?!'. I actually don't know entirely what that 
means, an implicitly unwrapped optional to an optional. I suppose it's means 
it's possibly something which is possibly an NSURL with an implicit guarantee 
that it's not nothing at all. Anyway your '!' before '.path' just unwraps the 
implicitly unwrapped optional bit. Yes I know it's implicitly unwrapped already 
but I believe the '!' just unwraps it from implicitly unwrapped optional to 
optional NSURL to really unwrapped, ie optional NSURL. So you need two '!!', 
one for the '!' and one for the '?'. 

let thisPath = thisApp.executableURL!!.path

I tried to move the ugliness around a bit, you can do 

for thisApp in NSWorkspace.sharedWorkspace().runningApplications as [ 
NSRunningAppliction ]
{
let thisPath = thisApp.executableURL!.path
}

except in 6.3 now you can't do that, you have to have 'as!', so it isn't much 
nicer although possibly more consistent


Why does this happen with executableURL and not bundleURL, I don't really know. 
Both those properties are defined on both NSBundle and NSRunningApplication 
however the bundleURL is non-optional on both of them and the executableURL is 
optional on NSRunningApplication but not on NSBundle. Since runningApplications 
returns an [ AnyObject ] I assume there's one level of optionality in err ... 
something and then another one in executableURL because it might be optional, 
or not. 

Amusing crash of the day whilst trying to work this out

import Cocoa

for thisApp in NSWorkspace.sharedWorkspace().runningApplications  
{
//let pp = thisApp as! NSRunningApplication
let tt = thisApp.bundleURL!.path
}

works fine. However if you uncomment the commented line, which does nothing but 
set an unused variable, the line below crashes with EXC_i386_INVOP. That's 6.3, 
in 6.2 you have to remove the '!' in the commented line after the 'as', however 
you still get the same crash. 

All this to work around nil, a concept I've always rather liked. 



___

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

NSButton (radio button) not calling action when overlapped by invisible NSButton?

[Aandi Inston]

I am implementing the Cocoa back end of a portable control library, and
have hit one particular strange problem.

The dialogs are frequently very complex, with areas showing different
groups of controls according to context. Individual controls are
shown/hidden by the higher level code to make this work. Radio buttons are
naturally implemented as an NSButton with suitable style.

I have just one dialog where some of the radio buttons are "dead". It seems
that the action callback, set with setAction: is not called some of the
time.

Initial studies suggest that this happens when a later radio button
(another NSButton, or rather the same descendent of NSButton) occupies the
same space. This later button is hidden (setHidden:true), but seems to be
somehow stopping the click getting to the rear control.

Tested:
- The front, invisible, control is not receiving an action callback either
- Disabling (setEnabled:false) the hidden control does not change anything

Can anyone make any suggestions about whether this diagnosis has any ring
of truth, and how to fix or further investigate it?

Thanks in advance.
___

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: removeObserver:forKeyPath:context: fails; but removeObserver:forKeyPath: works?!

[Quincey Morris]

On Mar 10, 2015, at 10:50 , Sean McBride  wrote:
> 
> Can anyone think of a sitation where using removeObserver:forKeyPath: works 
> correctly, then modernizing the code to use 
> removeObserver:forKeyPath:context: breaks things?

If something else is using a conflicting ‘removeObserver:forKeyPath:’, it might 
sorta work if all observers use it (because the total number of removals is 
equal to the number of observations, even if they remove each others’ 
observations), but fail if some try use ‘removeObserver:forKeyPath:context:’ on 
an observation that’s already been removed.

Also, a long time ago (Leopard-ish), there was a horrible bug where 
observations of (from?) the same thing could get mixed up so that attempting to 
remove one would actually remove the other. I doubt this was ever fixed — it 
was subtle.

So, all this, plus the odd backtrace that *might* indicate that the object 
controller is duplicating one of your observations, but without a context, and 
things are falling apart from there.

Unless something easy turns out to have been overlooked, this sounds TSI-worthy.



___

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: removeObserver:forKeyPath:context: fails; but removeObserver:forKeyPath: works?!

[Keary Suska]

On Mar 10, 2015, at 11:50 AM, Sean McBride  wrote:

> Hi all,
> 
> Can anyone think of a sitation where using removeObserver:forKeyPath: works 
> correctly, then modernizing the code to use 
> removeObserver:forKeyPath:context: breaks things?
> 
> Long story: I have a custom NSView subclass that exposes a custom binding.  
> In bind: it does addObserver:forKeyPath:options:context:.  In unbind: it does 
> removeObserver:forKeyPath:.  If I update unbind: to use the 'context' version 
> it breaks.
> 
> Specifically, if I have several of these views onscreen (all bound to the 
> same NSObjectController) then remove all but one of the views from the view 
> hierarchy, the remaining one no longer receives any KVO notifications.  I've 
> put logs everywhere, and subclassed NSObjectController and implemented 
> add&removeObserver methods to log and call super.  All the log output is the 
> same in the working & broken cases except the deliberate difference between 
> using removeObserver: with or without the context.  I am surprised to see 
> this backtrace however:
> 
> -[MyObjectController removeObserver:forKeyPath:]
> -[NSObject(NSKeyValueObserverRegistration) 
> removeObserver:forKeyPath:context:] ()
> -[NSController removeObserver:forKeyPath:context:] ()
> -[MyObjectController removeObserver:forKeyPath:context:]
> -[MyView unbind:]
> ...
> 
> Odd that NSObjectController removeObserver:forKeyPath:context: calls 
> removeObserver:forKeyPath:, no?
> 
> Any clues would help... :)

Have you checked observationInfo at each point to ensure that observation is 
being added/removed exactly as you expect?

HTH,

Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"


___

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

removeObserver:forKeyPath:context: fails; but removeObserver:forKeyPath: works?!

[Sean McBride]

Hi all,

Can anyone think of a sitation where using removeObserver:forKeyPath: works 
correctly, then modernizing the code to use removeObserver:forKeyPath:context: 
breaks things?

Long story: I have a custom NSView subclass that exposes a custom binding.  In 
bind: it does addObserver:forKeyPath:options:context:.  In unbind: it does 
removeObserver:forKeyPath:.  If I update unbind: to use the 'context' version 
it breaks.

Specifically, if I have several of these views onscreen (all bound to the same 
NSObjectController) then remove all but one of the views from the view 
hierarchy, the remaining one no longer receives any KVO notifications.  I've 
put logs everywhere, and subclassed NSObjectController and implemented 
add&removeObserver methods to log and call super.  All the log output is the 
same in the working & broken cases except the deliberate difference between 
using removeObserver: with or without the context.  I am surprised to see this 
backtrace however:

-[MyObjectController removeObserver:forKeyPath:]
-[NSObject(NSKeyValueObserverRegistration) removeObserver:forKeyPath:context:] 
()
-[NSController removeObserver:forKeyPath:context:] ()
-[MyObjectController removeObserver:forKeyPath:context:]
-[MyView unbind:]
...

Odd that NSObjectController removeObserver:forKeyPath:context: calls 
removeObserver:forKeyPath:, no?

Any clues would help... :)

Thanks,

-- 

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com 
Mac Software Developer  Montréal, Québec, Canada



___

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

NSRunningApplication executableURL issue in Swift

[Bill Cheeseman]

I'm using Xcode 6.2 and Swift 1.1.

1. The following statement reports the error "'NSURL?' does not have a member 
named 'path'" even though executableURL has a trailing exclamation point to 
unwrap it. The caret identifying the location of the error is placed under the 
exclamation point.

for thisApp in NSWorkspace.sharedWorkspace().runningApplications {
 let thisPath = thisApp.executableURL!.path // ERROR
}

If I change executableURL to bundleURL, the error goes away. Yet executableURL 
and bundleURL are declared identically according to the NSRunningApplication 
reference document. As far as I know, bundleURL and executableURL both satisfy 
fileURL.

The error also goes away if I assign thisApp to a local variable and expressly 
downcast it to NSRunningApplication, as shown below. Why would I need to do 
that with executableURL, when it isn't necessary with bundleURL?

for thisApp in NSWorkspace.sharedWorkspace().runningApplications {
 let myAppAndIMeanIt = thisApp as NSRunningApplication
 let thisPath = myAppAndIMeanIt.executableURL!.path // NO ERROR
}

Is this a Swift bug?

2. Is executableURL suitable to get the URL to a flat-file (non-bundled) 
application? Or is it only intended to get the executable inside of an 
application bundle? I have always assumed the former, because 
NSRunningApplication handles LSUIElement and LSBackgroundOnly applications as 
well as ordinary foreground applications, but the reference document doesn't 
say and I can't find any discussion.

3. Are there any flat-file (non-bundled) applications out there any longer? I 
think I've noticed some in the System folder.

-- 

Bill Cheeseman - b...@cheeseman.name

___

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: disabling Apple Crash Reporter

[Jonathan Mitchell]

> On 10 Mar 2015, at 09:08, Torsten Curdt  wrote:
> 
> However the user experience is rather barren.
> The app simply dies.
> 
> As well as posting the report ReportCrash(8) also allows informs the user of 
> termination and allows restart.
> I know that prompting users twice for reporting is inelegant and confusing 
> but crashing with no UI feedback at all is a bit mystifying - where did my 
> app go!
>  
> True. It would be better to have a custom dialog - but from a signal handler?
Yep. A dialog would be preferable.

Mr Ash suggests kqueue and GCD based handlers which can (though I have not 
tested this) run arbitrary code post signal.
https://mikeash.com/pyblog/friday-qa-2011-04-01-signal-handling.html

However PLCrashReporter uses a straight ahead signal handler:
https://github.com/plausiblelabs/plcrashreporter/blob/e6d1ac18d758e8e0197f32f927bb6b31b8559f95/Source/PLCrashReporter.m

The PLCrashReporter repo does contain GTMSignalHandler (part of the google 
toolbox) which is kqueue based but this is not utilised.

Perhaps you could utilise the kqueue based handlers, show your UI and then call 
the PLCrashReporter signal handler (which in turn calls your signal handler 
with containing exit(-1). 

>  
> 
> Throwing up any sort of UI in the callback will be unreliable due to the 
> normal re-entrant code caveats - I think the Adium code does this anyway.
> 
> Where did you find that?

https://www.plcrashreporter.org/documentation/api/v1.2/async_safety.html
http://landonf.bikemonkey.org/code/objc/Reliable_Crash_Reporting.20110912.html

> 
> Well, I guess a crash is a crash. So maybe unreliable ist acceptable if it 
> works most of the time. After all a crash *should* be an edge case that does 
> not happen too often.
True. But an unreliable crash catcher is not much of an asset!

> 
> Maybe this could be done from another process?
> 
> cheers,
> Torsten
> 


___

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

MacOSX screensaver not loading due to Library not loaded: @rpath/libswiftAppKit.dylib

[Juanjo Conti]

We have a working Mac OS X screensaver as a standalone Xcode project, but
we needed to have it as a target in another Xcode project that also
contains a related app.

I added a target for a screensaver, copied the code, added to that target,
etc, etc. The code is the same one that works in the other screensaver, but
on this one, it generates the following error:

2015-03-10 09:43:24.766 System Preferences[32495]: Error loading
/Users/pupeno/Library/Screen Savers/Ninja.saver/Contents/MacOS/Ninja:
 dlopen(/Users/pupeno/Library/Screen
Savers/Ninja.saver/Contents/MacOS/Ninja, 265): Library not loaded:
@rpath/libswiftAppKit.dylib
  Referenced from: /Users/pupeno/Library/Screen
Savers/Ninja.saver/Contents/MacOS/Ninja
  Reason: image not found
2015-03-10 09:43:24.766 System Preferences[32495]: ScreenSaverModules:
can't get principalClass for /Users/pupeno/Library/Screen Savers/Ninja.saver
The library in question is definitely there:

$ ls -w1 Library/Screen\ Savers/Ninja.saver/Contents/Frameworks/
libswiftAppKit.dylib
libswiftCore.dylib
libswiftCoreGraphics.dylib
libswiftDarwin.dylib
libswiftDispatch.dylib
libswiftFoundation.dylib
libswiftObjectiveC.dylib
libswiftQuartzCore.dylib
libswiftSecurity.dylib

Any ideas what might be causing this?


-- 

Juanjo Conti http://goog_2023646312>@carouselapps.com
>

Software Engineer - Carousel Apps 

-- 
Carousel Apps Limited, registered in England & Wales with registered number 
7689440 and registered office Unit 2 Artbrand Studios, 7 Leathermarket 
Street, London SE1 3HN. Any communication sent by or on behalf of Carousel 
App Ltd or any of its subsidiary, holding or affiliated companies or 
entities (together "Watu") is confidential and may be privileged or 
otherwise protected. If you receive it in error please inform us and then 
delete it from your system. You should not copy it or disclose its contents 
to anyone. Messages sent to and from Watu may be monitored to ensure 
compliance with our internal policies and to protect our business. Emails 
are not secure and cannot be guaranteed to be error free. Anyone who 
communicates with us by email is taken to accept these risks.
___

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: All buttons lost focus ring on Yosemite

[dangerwillrobinsondanger]

What happens if you turn on full keyboard access?

Sent from my iPhone

> On 2015/03/10, at 18:45, Dragan Milić  wrote:
> 
> My previous message sent to the list apparently didn’t get admin approval, 
> there were two attached images showing standard alarm panels with buttons 
> which don’t draw their focus ring. Therefore, in this message I’ll combine 
> answers to both Kyle and Graham.
> 
>> On pon 09.03.2015., at 17.48, Kyle Sluder wrote:
>> 
>> I'd start by looking at that -[NSView(NTExtensions) drawFocusRing] method. 
>> If you comment it out, what happens?
> 
> No changes :-(  I even went that far to remove the category completely and 
> ignore all compiler warnings where added methods were used. Now, that would 
> normally throw exceptions, but before even loading any application window and 
> using any view requiring added category methods, the application shows two 
> alert panels (one by one, attached images of those panels is the reason my 
> previous message didn’t get through ), depending on current user preferences. 
> That enables me to see buttons' behaviour even before any exception is 
> thrown. Here is the link to the image of the first alert panel:
> 
> http://media.cocoatech.com/first_alert.png
> 
> What’s interesting here is that, as you can see, the alert’s 
> suppressionButton checkbox DOES draw its focus ring, but other two buttons 
> don’t! Believe my words, if I use tab/shift+tabs to change focus on them, 
> they are focused (I can then activate them with the space), but the focus 
> ring is not drawn, only the checkbox gets it correctly.
> 
> Immediately after that first alert is dismissed, the second one appears, here 
> is the link:
> 
> http://media.cocoatech.com/second_alert.png
> 
> With this one, even the focused suppressionButton checkbox doesn’t draw its 
> focus ring. Other two buttons don’t too. And all this is with the NSView 
> category completely removed. There are other NSView or NSControl or NSButton 
> or NSButtonCell categories defined. The code defining both alarm panels is 
> pretty standard, I can post it if necessary.
> 
> Everything worked well in Mavericks, I’ve got no idea what happened in the 
> meanwhile.
> 
>> For safety, you really ought to be prefixing all of your category methods 
>> with some unique-to-you prefix.
> 
> Yeah. As I’ve mentioned already, this is not my code, it was first created 
> back in 2002 and until this problem I haven’t even looked into it.
> 
> 
>> On uto 10.03.2015., at 00.44, Graham Cox wrote:
>> 
>> In Xcode, add OBJC_PRINT_REPLACED_METHODS (value: YES) to your scheme's 
>> environment variables. Then all of the methods replaced by categories are 
>> logged when your app launches. While the list can be long and might take 
>> some time to go through, it will show you if any of your category methods 
>> are replacing anything - it's a much more reliable way to check than doing a 
>> class dump.
> 
> Thanks for the suggestion Graham, I’ll do that. It’s be interesting to see if 
> and what methods are replaced, although I don’t think it’ll solve this 
> particular problem. I mentioned above it still happens even with the NSView  
> category completely removed.
> 
>> If you're not using those category methods, remove them. Most of them seem 
>> to be convenience methods that are possible "nice to haves" rather than 
>> vital to use NSView. Some appear to me to wholly misunderstand how a view 
>> stack (involving semi-transparancy for example) is actually drawn. Others 
>> are things that could be useful in particular circumstances but you probably 
>> wouldn't want to apply to every view your app ever instantiates including 
>> framework ones. For those custom views of yours that use these things, 
>> relocate that code to the custom view. It may mean a small duplication of 
>> code across a few different views, but it will be a lot safer than swapping 
>> out NSView wholesale. NSView just may be Cocoa's single most complicated 
>> class (any other contenders?). As a result, you probably can't foresee all 
>> possible effects of adding a category on it.
> 
> As mentioned above, I’ve never looked into that code before this problem 
> started. Now that I do, I’ll definitely do something about it and apply your 
> suggestions.
> 
> -- Dragan
> 
> ___
> 
> 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/dangerwillrobinsondanger%40gmail.com
> 
> This email sent to dangerwillrobinsondan...@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 y

Re: Trying to create a 1px width NSBox

[Uli Kusterer]

On 09 Mar 2015, at 01:22, Patrick J. Collins  
wrote:
>> Not sure why you'd waste time trying to bend unsuitable UI components to 
>> your will instead of building a custom view.
>> It's super easy and it always does exactly what you design it to do.
> 
> Well I guess I can ask the reverse question of, why does Apple waste
> their time creating and offering a "vertical line", if it's not useful?
> I mean, all I want is a vertical line.  I don't understand why something
> like that exists if it's not customizable.

 It’s not intended as a generic vertical line. The same control used to be 
called a “separator” in Carbon, which might make it more clear what this is 
intended for: It is a line that separates two groups of UI elements, just like 
NSBox. In fact, as you noticed, the view created when you drag a “vertical 
line” actually *is* just an NSBox in a special “draw a straight line” mode.

 But really, who cares if the view is 5pt wide as long as it draws the line 1px 
wide? In fact, it’s a good thing this view is 5pt wide, because if you’ve ever 
tried to hit a 1pt object with a mouse, you’ll have noticed that it is very 
hard to do. Which is exactly why the HIG has been recommending a minimum 8pt 
width for clickable objects. Look at the 1-line pane separators in Mail.app: 
They actually accept clicks several pixels to their left and right.

 Also, given NSBox has a “custom” drawing mode, have you tried just setting it 
to “Custom” using the respective NSBox methods on the view and set its line 
color?

 That said, are you sure you want to hard-code this to be a line? Usually one 
creates an image file containing the appearance of the image and then uses a 
layer or a layer-backed NSImageView to draw it. That way, if your graphics 
designer wants to give the line an emboss, or make it thicker, or give it a bit 
of shading, your code doesn’t need to change. Since you probably want to be 
able to drag it, you’d need a custom view to handle the tracking anyway, so I’d 
recommend a custom NSView. Make it layer-backed and set its layer’s contents to 
your image (setting the anchor so the image is centered in the view). That way, 
the GPU will take care of compositing the image, and won’t have to re-upload 
the entire window contents whenever the user drags, saving laptop users battery.

Cheers,
-- Uli Kusterer
“The Witnesses of TeachText are everywhere...”
http://zathras.de


___

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: All buttons lost focus ring on Yosemite

[Dragan Milić]

My previous message sent to the list apparently didn’t get admin approval, 
there were two attached images showing standard alarm panels with buttons which 
don’t draw their focus ring. Therefore, in this message I’ll combine answers to 
both Kyle and Graham.

On pon 09.03.2015., at 17.48, Kyle Sluder wrote:

> I'd start by looking at that -[NSView(NTExtensions) drawFocusRing] method. If 
> you comment it out, what happens?

No changes :-(  I even went that far to remove the category completely and 
ignore all compiler warnings where added methods were used. Now, that would 
normally throw exceptions, but before even loading any application window and 
using any view requiring added category methods, the application shows two 
alert panels (one by one, attached images of those panels is the reason my 
previous message didn’t get through ), depending on current user preferences. 
That enables me to see buttons' behaviour even before any exception is thrown. 
Here is the link to the image of the first alert panel:

http://media.cocoatech.com/first_alert.png

What’s interesting here is that, as you can see, the alert’s suppressionButton 
checkbox DOES draw its focus ring, but other two buttons don’t! Believe my 
words, if I use tab/shift+tabs to change focus on them, they are focused (I can 
then activate them with the space), but the focus ring is not drawn, only the 
checkbox gets it correctly.

Immediately after that first alert is dismissed, the second one appears, here 
is the link:

http://media.cocoatech.com/second_alert.png

With this one, even the focused suppressionButton checkbox doesn’t draw its 
focus ring. Other two buttons don’t too. And all this is with the NSView 
category completely removed. There are other NSView or NSControl or NSButton or 
NSButtonCell categories defined. The code defining both alarm panels is pretty 
standard, I can post it if necessary.

Everything worked well in Mavericks, I’ve got no idea what happened in the 
meanwhile.

> For safety, you really ought to be prefixing all of your category methods 
> with some unique-to-you prefix.

Yeah. As I’ve mentioned already, this is not my code, it was first created back 
in 2002 and until this problem I haven’t even looked into it.


On uto 10.03.2015., at 00.44, Graham Cox wrote:

> In Xcode, add OBJC_PRINT_REPLACED_METHODS (value: YES) to your scheme's 
> environment variables. Then all of the methods replaced by categories are 
> logged when your app launches. While the list can be long and might take some 
> time to go through, it will show you if any of your category methods are 
> replacing anything - it's a much more reliable way to check than doing a 
> class dump.

Thanks for the suggestion Graham, I’ll do that. It’s be interesting to see if 
and what methods are replaced, although I don’t think it’ll solve this 
particular problem. I mentioned above it still happens even with the NSView  
category completely removed.

> If you're not using those category methods, remove them. Most of them seem to 
> be convenience methods that are possible "nice to haves" rather than vital to 
> use NSView. Some appear to me to wholly misunderstand how a view stack 
> (involving semi-transparancy for example) is actually drawn. Others are 
> things that could be useful in particular circumstances but you probably 
> wouldn't want to apply to every view your app ever instantiates including 
> framework ones. For those custom views of yours that use these things, 
> relocate that code to the custom view. It may mean a small duplication of 
> code across a few different views, but it will be a lot safer than swapping 
> out NSView wholesale. NSView just may be Cocoa's single most complicated 
> class (any other contenders?). As a result, you probably can't foresee all 
> possible effects of adding a category on it.

As mentioned above, I’ve never looked into that code before this problem 
started. Now that I do, I’ll definitely do something about it and apply your 
suggestions.

-- Dragan

___

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: disabling Apple Crash Reporter

[Torsten Curdt]

I wasn't aware that this is OK to do from a signal handler. Is it really?

On Tue, Mar 10, 2015 at 10:22 AM, 
wrote:

> Again Unix to the rescue.
>
> http://stackoverflow.com/questions/19147386/system-call-fork-and-execv-function
>
>
> Sent from my iPhone
>
> On 2015/03/10, at 18:08, Torsten Curdt  wrote:
>
>
> However the user experience is rather barren.
>
> The app simply dies.
>
>
>
> As well as posting the report ReportCrash(8) also allows informs the user
>
> of termination and allows restart.
>
> I know that prompting users twice for reporting is inelegant and confusing
>
> but crashing with no UI feedback at all is a bit mystifying - where did my
>
> app go!
>
>
>
> True. It would be better to have a custom dialog - but from a signal
> handler?
>
>
> Throwing up any sort of UI in the callback will be unreliable due to the
>
> normal re-entrant code caveats - I think the Adium code does this anyway.
>
>
>
> Where did you find that?
>
> Well, I guess a crash is a crash. So maybe unreliable ist acceptable if it
> works most of the time. After all a crash *should* be an edge case that
> does not happen too often.
>
> Maybe this could be done from another process?
>
> cheers,
> Torsten
> ___
>
> 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/dangerwillrobinsondanger%40gmail.com
>
> This email sent to dangerwillrobinsondan...@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: disabling Apple Crash Reporter

[dangerwillrobinsondanger]

Again Unix to the rescue. 
http://stackoverflow.com/questions/19147386/system-call-fork-and-execv-function


Sent from my iPhone

On 2015/03/10, at 18:08, Torsten Curdt  wrote:

>> 
>> However the user experience is rather barren.
>> The app simply dies.
> 
> 
>> As well as posting the report ReportCrash(8) also allows informs the user
>> of termination and allows restart.
>> I know that prompting users twice for reporting is inelegant and confusing
>> but crashing with no UI feedback at all is a bit mystifying - where did my
>> app go!
> 
> 
> True. It would be better to have a custom dialog - but from a signal
> handler?
> 
> 
> Throwing up any sort of UI in the callback will be unreliable due to the
>> normal re-entrant code caveats - I think the Adium code does this anyway.
> 
> Where did you find that?
> 
> Well, I guess a crash is a crash. So maybe unreliable ist acceptable if it
> works most of the time. After all a crash *should* be an edge case that
> does not happen too often.
> 
> Maybe this could be done from another process?
> 
> cheers,
> Torsten
> ___
> 
> 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/dangerwillrobinsondanger%40gmail.com
> 
> This email sent to dangerwillrobinsondan...@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: disabling Apple Crash Reporter

[Torsten Curdt]

>
> However the user experience is rather barren.
> The app simply dies.


> As well as posting the report ReportCrash(8) also allows informs the user
> of termination and allows restart.
> I know that prompting users twice for reporting is inelegant and confusing
> but crashing with no UI feedback at all is a bit mystifying - where did my
> app go!


True. It would be better to have a custom dialog - but from a signal
handler?


Throwing up any sort of UI in the callback will be unreliable due to the
> normal re-entrant code caveats - I think the Adium code does this anyway.
>

Where did you find that?

Well, I guess a crash is a crash. So maybe unreliable ist acceptable if it
works most of the time. After all a crash *should* be an edge case that
does not happen too often.

Maybe this could be done from another process?

cheers,
Torsten
___

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