Re: disabling Apple Crash Reporter
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, dangerwillrobinsondan...@gmail.com 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 tcu...@vafer.org 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: All buttons lost focus ring on Yosemite
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: All buttons lost focus ring on Yosemite
What happens if you turn on full keyboard access? Sent from my iPhone On 2015/03/10, at 18:45, Dragan Milić mi...@mac.com 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 your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email
MacOSX screensaver not loading due to Library not loaded: @rpath/libswiftAppKit.dylib
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 jjconti http://goog_2023646312@carouselapps.com jjco...@carouselapps.com Software Engineer - Carousel Apps https://carouselapps.com -- 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: disabling Apple Crash Reporter
On 10 Mar 2015, at 09:08, Torsten Curdt tcu...@vafer.org 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
Re: Trying to create a 1px width NSBox
On 09 Mar 2015, at 01:22, Patrick J. Collins patr...@collinatorstudios.com 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: NSRunningApplication executableURL issue in Swift
On Mar 10, 2015, at 21:17, Roland King r...@rols.org wrote:
On 11 Mar 2015, at 00:24, Bill Cheeseman wjcheese...@gmail.com 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 concept I've always rather liked.
___
Re: NSRunningApplication executableURL issue in Swift
On 2015/03/11, at 14:44, Quincey Morris
quinceymor...@rivergatesoftware.com wrote:
On Mar 10, 2015, at 22:26 , Bavarious bavari...@icloud.com 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
removeObserver:forKeyPath:context: fails; but removeObserver:forKeyPath: works?!
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 addremoveObserver 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
Different notification icons in push notifications
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
On Mar 10, 2015, at 22:26 , Bavarious bavari...@icloud.com 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
NSRunningApplication executableURL issue in Swift
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: removeObserver:forKeyPath:context: fails; but removeObserver:forKeyPath: works?!
On Mar 10, 2015, at 10:50 , Sean McBride s...@rogue-research.com 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?!
On Mar 10, 2015, at 11:50 AM, Sean McBride s...@rogue-research.com 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 addremoveObserver 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
NSButton (radio button) not calling action when overlapped by invisible NSButton?
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: disabling Apple Crash Reporter
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
Re: disabling Apple Crash Reporter
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 tcu...@vafer.org 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: NSRunningApplication executableURL issue in Swift
On 11 Mar 2015, at 00:24, Bill Cheeseman wjcheese...@gmail.com 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
