Re: Exact semantics of NSThread executation states?

> On Jul 12, 2016, at 2:52 PM, Sean McBride wrote: > > Hi all, > > NSThread has at least 3 execution state properties: executing, finished, > cancelled. Alas, the docs don't say much about what they mean beyond > circular definitions like "A Boolean value that

Exact semantics of NSThread executation states?

Hi all, NSThread has at least 3 execution state properties: executing, finished, cancelled. Alas, the docs don't say much about what they mean beyond circular definitions like "A Boolean value that indicates whether the receiver is executing". I have code where I create an NSThread, add a

Re: specifying UIInterfaceOrientationMask

On Jul 12, 2016, at 11:25 , William Squires wrote: > > what dumb Swift feature am I overlooking now? It’s an OptionsSet now, so you specify compound values with an array literal form. In Swift 3, with API swiftification, it’ll be something like: return

Re: specifying UIInterfaceOrientationMask

So, (UIInterfaceOrientationMask.Portrait | UIInterfaceOrientationMask.LandscapeLeft) doesn't work? > On Jul 12, 2016, at 11:25 AM, William Squires wrote: > > In iOS 8, I would (in a view controller): > > ... > override func supportedInterfaceOrientations() -> Int > { >

Re: Best way to model something that's drawable (i.e. has a visual representation in the UI)

On 12 Jul 2016, at 19:11, William Squires wrote: > > Normally, of course, models shouldn't know anything about UI, and vice versa, > but what about when the models themselves represent something visual that the > UI needs to draw... [snip] > In this case, it makes sense

specifying UIInterfaceOrientationMask

In iOS 8, I would (in a view controller): ... override func supportedInterfaceOrientations() -> Int { return Int(UIInterfaceOrientationMask.Portrait.rawValue) | Int(UIInterfaceOrientationMask.LandscapeLeft.rawValue) } ... but this no longer works in iOS 9, as the method signature is now: func

Best way to model something that's drawable (i.e. has a visual representation in the UI)

Normally, of course, models shouldn't know anything about UI, and vice versa, but what about when the models themselves represent something visual that the UI needs to draw (like in a drawing/painting program, or - in my case - GameObject instances that can be objects found in the "dungeon"