Re: Swift Keypress KeyDown NSResponder input function needed.

I thought Yosemite view controllers put themselves in the responder chain properly now... Sent from my iPhone > On 2015/03/12, at 9:20, Jens Alfke wrote: > > >> On Mar 11, 2015, at 5:09 PM, Mutlu Qwerty wrote: >> >> self.nextResponder = super.nextResponder //insert self into the >>

Re: Swift Keypress KeyDown NSResponder input function needed.

> On Mar 11, 2015, at 5:09 PM, Mutlu Qwerty wrote: > >self.nextResponder = super.nextResponder //insert self into the > Responder chain That just sets the object's nextResponder property; it doesn’t insert the object into the responder chain. I think you want to set the _view’s_ nex

Swift Keypress KeyDown NSResponder input function needed.

Hello List:My Sudoku Puzzle game needs to get keyboard digits, 1 thru 9, and the arrow keys as input.I have read Handling Key Events in the Cocoa Event Handling Guide and produced this codewhich compiles ok and runs giving me system beeps indication that my keyDown function is not working as I e

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

On Mar 11, 2015, at 15:03 , Sean McBride wrote: > It's here: I just spent a few minutes with it. A couple of things: — I don’t think it’s a very good idea to do this (slightly abbreviated from your source): > - (void)bind:(NSString*)inBindingName toObject:(id)inObservableObject > withKeyPath

Re: Cocoa GUI app getting slower on MacPro or MacMini when disconnecting all screens

> On Mar 11, 2015, at 3:40 PM, Matthieu Beghin > wrote: > > if I do nothing in the timer, it's called as often as when a screen is > connected (120 times per second) > if I do some processing, it gets called 20 times per second, but CPU usage > is very low This sounds like some kind of Qt

Cocoa GUI app getting slower on MacPro or MacMini when disconnecting all screens

Hi, I'm developing a GUI application base on Qt-cocoa. When disconnecting the last screen my application gets slower. In Instruments, I can see it's kind of "pausing" (CPU goes 0%) regularly. I do some processing with a timer (actually using a Qt timer), if I do nothing in the timer, it's ca

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

On Wed, 11 Mar 2015 20:24:34 +, Quincey Morris said: >Sure, I’d be interested to see it. Cool, thanks. It's here: To repro: - search for all the NSLogs in the project (4 of them) and put breakpoints there - build & launch - you may

Re: NSRunningApplication executableURL issue in Swift

On Mar 11, 2015, at 14:49 , Marco S Hyman wrote: > Perhaps you are thinking of them that way because of your C/Obj-C background. > I was thinking of them that way because I didn’t have a better term. :) > Think of them instead as abbreviated .swift files. Very good. So, in the fantasy world

Re: NSRunningApplication executableURL issue in Swift

> The consequence of this possible future scenario would be that an Apple > engineer writing code for an interoperable framework would write the .m file > in Obj-C, but the public .h file in Swift. Except that swift doesn't have .h files. The auto generated files your are seeing are not .h fil

Re: NSRunningApplication executableURL issue in Swift

On Mar 11, 2015, at 14:07 , Charles Srstka wrote: > > Yes, but every time you make any change to the frameworks thereafter, you > have to make sure to keep the two in sync. Better to avoid the duplication of > data. I’m not having much success in making this point: There aren’t [wouldn’t be]

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

On Wed, 11 Mar 2015 21:06:46 +, Jonathan Mitchell said: >I recently refactored my app to use removeObserver:forKeyPath:context: >rather than removeObserver:forKeyPath and it went without a hitch. We did the same refactor a couple of years ago, and it went great also. We missed just one or t

Re: NSRunningApplication executableURL issue in Swift

On Mar 11, 2015, at 3:55 PM, Quincey Morris wrote: > > On Mar 11, 2015, at 10:53 , Charles Srstka > wrote: >> >> It would also be much more work. > > Actually, I don’t think so, once you follow through the argument… > > Even today, the ability to cross-transl

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

> On 11 Mar 2015, at 18:31, Sean McBride wrote: > > On Tue, 10 Mar 2015 18:25:23 +, Quincey Morris said: > >> 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

Re: NSRunningApplication executableURL issue in Swift

On Mar 11, 2015, at 10:53 , Charles Srstka wrote: > > It would also be much more work. Actually, I don’t think so, once you follow through the argument… Even today, the ability to cross-translate between Swift an Obj-C exists (within the Swift compiler, though used only in particular bridging

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

On Mar 11, 2015, at 11:31 , Sean McBride wrote: > > If you're curious I can put it online. Sure, I’d be interested to see it. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list.

Re: Delete propagation to parent context

> On 2015 Mar 09, at 14:56, Rick Mann wrote: > > Am I wrong to expect the object to still have its values at this point? Yes, I’ve seen objects “gutted” like that as soon as they're deleted. As to the documentation of -prepareForDeletion, I would say that, although your expectation is reason

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

On Tue, 10 Mar 2015 18:25:23 +, Quincey Morris said: >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’ observation

Re: NSRunningApplication executableURL issue in Swift

On Mar 11, 2015, at 02:36 , Charles Srstka wrote: > > Rewriting all the frameworks in another language No, no, no, that’s not the suggestion. The suggestion is to rewrite the *SDKs* in Swift. Public headers only. Almost all of the rewrite would be an automatic conversion that exists already.

Re: Programmatically putting attributed string RTF on the pasteboard

On Mar 11, 2015, at 3:36 AM, Charles Jenkins wrote: > I’m having a bit of difficulty learning how to use the pasteboard. I have a > text view which holds the text in a rich attributed string. I determined that > the built-in methods for cutting and pasting were screwing up my data because > no

Re: NSRunningApplication executableURL issue in Swift

> On 11 Mar 2015, at 17:53, Bill Cheeseman wrote: > > >> On Mar 11, 2015, at 4:13 AM, Bill Cheeseman wrote: >> >> Thanks guys, that was very enlightening and helpful. > > > I found a cleaner solution, which depends on telling the runtime that it is > to use the NSRunningApplication version

Re: Programmatically putting attributed string RTF on the pasteboard

Thank you, Ken. Because the section on copying to the pasteboard speaks of writing an array of objects to the pasteboard and elsewhere the guide says you provide each possible representation, I thought that meant I “owed” the pasteboard one object for each representation. I couldn’t see how pro

Re: NSRunningApplication executableURL issue in Swift

> On Mar 11, 2015, at 4:13 AM, Bill Cheeseman wrote: > > Thanks guys, that was very enlightening and helpful. I found a cleaner solution, which depends on telling the runtime that it is to use the NSRunningApplication version of the executableURL property. Then it only requires a single excl

Re: NSRunningApplication executableURL issue in Swift

On Mar 11, 2015, at 2:51 AM, Quincey Morris wrote: > > On Mar 11, 2015, at 00:25 , Charles Srstka > wrote: >> >> You know, this sounds like a good candidate for a collection contents >> annotation, similar to the nullability annotations that were recently adde

Programmatically putting attributed string RTF on the pasteboard

I’m having a bit of difficulty learning how to use the pasteboard. I have a text view which holds the text in a rich attributed string. I determined that the built-in methods for cutting and pasting were screwing up my data because not all attributes survive the cut-and-paste process’s translati

Re: NSRunningApplication executableURL issue in Swift

On Mar 11, 2015, at 00:25 , Charles Srstka wrote: > > You know, this sounds like a good candidate for a collection contents > annotation, similar to the nullability annotations that were recently added > to Xcode. If there was a way to notate in an Objective-C header that this > method returns

Re: NSRunningApplication executableURL issue in Swift

On Mar 11, 2015, at 1:07 AM, Quincey Morris wrote: > > 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 f