Re: Problem with tableView:viewForTableColumn:row:
On Aug 15, 2014, at 14:09 , Laurent Daudelin wrote: > Now, I implement *tableView:viewForTableColumn:row:*. Based on an array of > dictionaries, I set the various UI items in the tableCellView that I get > calling *makeViewWithIdentifier:owner:* passing the tableColumn identifier > that is set to my custom tableViewCell subclass. Everything works but as I > download stuff associated with each row and update the appropriate > dictionary, the tableview starts flickering. Inserting an NSLog() at the > beginning of *tableView:viewForTableColumn:row:* reveals that the method is > called several times per second. NOTE: I am not calling *reloadData* or > *reloadDataForRowIndexes:columnIndexes:* at *ANY* place in my code. > > How is that possible? Is it possible that the NSProgressIndicator is > causing this? Otherwise, what am I missing? My guess is that it’s the data updates that are leading to this, rather than the progress indicator. However, you can test it easily enough — (1) try the download without updating the dictionaries, and (2) try the download with the progress indicator hidden. *How* are you updating the data that the table view sees? Are there bindings involved? Is there an objectValue -> underlying dictionary binding, or a cell view element -> objectValue binding? ___ 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: Translating to Swift
On Aug 14, 2014, at 19:17 , Gerriet M. Denkmann wrote: > But does "global variable" means "var"? > Jean-Daniel rightly says: " I think that it should be 'let' and not 'var', > and you don't want the pointer to be changed after initialization" I know nothing about the real answer, but my guess is that writes to a global var after initialization would not be atomic, but the initialization itself would be. ___ 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: Translating to Swift
On Aug 14, 2014, at 11:44 , Gerriet M. Denkmann wrote: > But: is this thread-safe? What if several threads are trying to use the > sharedThing? Jean-Daniel is teasing you slightly. It *is* thread-safe. For the reason, look at the August 1 entry in the Swift blog: https://developer.apple.com/swift/blog/ It’s in the 2nd-last paragraph of the entry. ___ 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: KVO query
On Aug 13, 2014, at 14:53 , Jonathan Mitchell wrote: > At one point i need to invoke a manual KVO notification like so: > > [submission willChangeValueForKey:@“status”]; > [submission didChangeValueForKey:@“status”]; > > This raises like so: > > Terminating app due to uncaught exception 'NSInternalInconsistencyException', > reason: 'Cannot update for observer for > the key path "status.name" from , most likely > because the value for the key "status" has changed without an appropriate KVO > notification being sent. Check the KVO-compliance of the Submission class.’ This is one of those infuriating errors that is hard to make sense of. Try thinking about it literally. Because you’re observing the “status.name” path from ‘submission’, the observer is *also* observing the “name” path from ‘submission.status’**. In your scenario, the originally observed ‘status’ instance (call it X) is no longer the current ‘status’ instance at willChange time (it’s now Y, say), and in general it might not be the same as that at didChange time (Z, say). Even if Y == Z, there’s been a non-KVO-compliant change in ‘status’ prior to the notification being sent. Now, we do this quite often, without problems, but I’d suggest that’s only in cases where the “temporarily non KVO compliant” change is for the *last* key of the path — in which case the last object isn’t being observed, just because it’s the last key. So, in the case of a non-KVO-compliant change to the value of a non-terminal key path object, the non-KVO-compliance may not be tolerated by the frameworks. Hence this error message. What I suggest you try is to make two properties: “currentStatus” and “observableStatus”. The second of these would be updated KVO compliantly (i.e. via its setter) when you know that the first has changed and the change should be propagated (i.e. in the places where you now trigger the willChange/didChange notification manually). Code in the ‘submission’ class can use ‘self.currentStatus’ to get or set the most recent status object; observers would observe “observableStatus”, of course. ** Because there’re “really” no such thing as a key path observation. It’s “really” a chain of object/key observations. ___ 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: Advise on referencing NSDocument from custom view
On Aug 13, 2014, at 11:31 , Luc Van Bogaert wrote: > My question now is , where I should remove MyView as an observer with > 'self.model removeObserver: self forKey: @"property"...' '? > I tried to do this in 'dealloc', but it seems that from time to time my model > object is pulled right from under my when I close the document window, > resulting in an error stating that MyModel was deallocated while it still had > observers attached to it. Yes, this behavior is a consequence of the fact that the view’s “model” property is weak, and therefore not KVO compliant. (It can change to nil without anyone getting notified.) One way to handle this is to implement the window delegate method ‘windowWillClose:’ in your window controller, and use that to inform the view that it should stop observing the model. Unfortunately, there’s one other case you probably need to handle — what happens when the model is deallocated for some other reason. It’s possible that this isn’t possible in your app, but consider what happens if the user reverts the document, and the document object handles that by re-reading the document file and creating a new model. (I *think* that’s what happens if you don’t have any revert-handling code of your own.) In that case , the view’s weak “model” property will change to nil, which isn’t very useful. The upshot of this is that you’ll likely have a model-monitoring slab of code in your window controller, which is responsible for keeping the view up to date. Then, you’d probably use this mechanism to get the model reference to the view initially, rather than having the custom initializer. Or, you’d change the view to observe a “model” property of the window controller, which itself is derived from the document’s “model” property. But the details will vary depending on the details of your app. ___ 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: Bindings in Swift
On Aug 11, 2014, at 16:14 , Greg Parker wrote: > Do you have an example? For example (beta 5), enter some source that uses type “Array”, then command-click on “Array”. (I don’t know how to get Xcode to display the resulting file directly, so I’ve been using this technique. I don’t know if the result is real or synthetic.) Look for the 2nd “extension Array”, and the 2nd constructor in this extension: init(_ s: S) or look at ‘extend’ or look at ‘join’. Incidentally, I had other issues when trying to use things declared in this file. For example, if I try to define a class that conforms to “Collection”, the compiler says “‘Collection' is ambiguous for type lookup in this context”. (What I was trying to do was define a new class that had the same interface as an Array, but had only the immutable parts of the interface as its public API.) ___ 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: Bindings in Swift
On Aug 10, 2014, at 14:39 , Roland King wrote: > I haven't yet understood why there are two different syntaxes for > class/function generics, with the syntax but protocols are unadorned > but have associated types. Naively I would have expected both to look the > same, with parameters in angle brackets Well, the semantics *are* different. Each “parameterized” class is a different type, but all “parameterized” protocols (of the same name, I mean) are the same type. A while back I did start to consider what a "generic protocol” might mean, instead of a type-associated one, but my head immediately started to hurt. > I think it's time to resurrect the Swift book and read the second 1/2 of it > more slowly than I did the first time. I wouldn’t hold out much hope. The book just skates over the surface. In particular, it seems to me that what it says about associated types in protocols is either pure nonsense, or is missing a couple of key facts. [Specifically, I suspect that a ‘typealias’ in a protocol must either get bound to a specific auxiliary type in an inheritor of the protocol, otherwise it defaults to being bound to the inheritor’s type (i.e. ‘Self’). However, it looks to me that the specific binding is generally by inference, and so is indistinguishable syntactically from the default binding. The book describes one thing, but links to an example that shows the other. There’s also something going on with the silly-looking generic specifier ‘’ that appears in some of Swift’s internal class declarations, but it seems to be meaningful in relation to protocols in some non-obvious way.] ___ 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: Advise on referencing NSDocument from custom view
On Aug 10, 2014, at 13:16 , Luc Van Bogaert wrote: > Let's see if I understand this correctly: do you mean I could create a > separate model class, eg. "Drawing" with all of it's properties and reference > this in my document class as an instance variable or even as a property. > Then, from my custom view, instead of using [[self.window.windowController > document] someProperty]', I could use '[self.window.windowController > someProperty]', which in turn would message my model object to return the > value of 'someProperty' using 'return [self.document someProperty]' ? To be specific: In a document-based app, I will generally have MyDocument, MyWinController and MyModel. MyDocument has a MyModel property, referencing the model that it loaded from the document file (or whatever). MyWinController has a MyModel property, referencing the same model as the document. A custom MyView would also have a MyModel property referencing the same model, initialized in any of various ways depending on how the view was created. The view would then use myModel.someProperty whenever it needed it, perhaps even binding to it. Putting a derived “someProperty” directly on the window controller, or even on a view controller, *is* feasible too. Often, I find, I use this approach when the view presents a somewhat transformed picture of the data model. Databasey kinds of apps (such as master/detail) often seem to want to use the real data model directly. UIey kinds of apps often seem to want to use a transformed model. ___ 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: Bindings in Swift
On Aug 10, 2014, at 10:15 , Kyle Sluder wrote: >> OTOH, C++ has historically proved that generics (i.e. templates) > > I really wish people would stop referring to C++ templates as generics. Point taken, dope-slap administered. ___ 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: Advise on referencing NSDocument from custom view
On Aug 10, 2014, at 09:01 , Luc Van Bogaert wrote: > I was thinking of using a weak property for my custom view to reference the > document and set this property from the same windowDidLoad: method, but I'm > not sure if this is a good approach to take. Any advise on this? It’s not a bad approach, but it’s probably not necessary, since the view can already get the document as ‘self.window.windowController.document’. In a simple project, putting a reference to the document from a view is fine, but in a larger project I’d be a bit reluctant. The “problem” is that it puts some implementation details (that your data model is implemented in a subclass of NSDocument) in a place where they’re really irrelevant. A better approach is to define your data model separately from the document, even if the document is responsible for creating and owning the data model. The window controller would vend references to the data model (not the document) to views and view controllers that need it. In an even more sophisticated project, this may still over-constrain your design. Another approach is to create an auxiliary data model in the window controller, that’s specific to the needs of the custom view. The window controller is then responsible (usually via KVO observations) for keeping the auxiliary model in sync with the main data model. The point here is to reduce the amount of information that’s globally known, because you’ll find (in later design iterations) that global knowledge will frustrate your attempts to rearrange your design as you add features, or come to understand the design problem better. ___ 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: Bindings in Swift
On Aug 10, 2014, at 06:46 , Roland King wrote: > And if anyone thinks Swift is all simplicity and scripty loveliness I came > across this StackOverflow question and answer today. It will be a while > before I entirely understand it, it will be a long while before I could > attempt to reproduce it. Deliberately missing your point, I’d say the problem is that Swift has two kinds of generics — one for class types and one for protocols. The concepts are fairly easy to grasp individually, but become horrendously complex when allowed to interact. Personally, I regard this as a bug in the language design. OTOH, C++ has historically proved that generics (i.e. templates) *alone* can become horrendously complex. Even on this list, the most common C++ question is, “Why won’t my template instantiate properly?”. One of the joys of Obj-C has always been that it isn’t very ambitious in the language-features department. Remember the fuss when property syntax was introduced? ___ 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: Bindings in Swift
On Aug 9, 2014, at 18:13 , Roland King wrote: > If this is where we are then it would be handy to have the runtime throw, or > at least log, if you attempt to KVO a Swift property which isn't dynamic. Yes, though I expect (hope?) that there is eventually something better than traditional KVO/bindings/etc coming along for Swift. (Note, for example, that did/willSet takes over a little bit of the KVO universe. Just not very much.) > If I have understood properly, up until beta 4 that also used objc_MsgSend > and was fully dynamic, as of beta 5 it may or may not use objc_MsgSend or it > may optimize around it. I got the impression that earlier betas might have optimized around it, and therefore that KVO wasn’t reliable. I think ‘dynamic’ is a bug fix. > if you write such a property in Swift and mark it only @objc then it's quite > possible Swift will call the original, unswizzled methods, and you won't get > your notification .. because objc_MsgSend may not be used Yes, I suppose if Swift decided to use a direct call, it would call the wrong thing, but not because of swizzling, since KVO doesn’t swizzle. Instead, it dynamically changes the class of your object to a synthetic class with a method that overrides your setter. So, the error in Swift’s “reasoning” would be that the method wasn’t overridden when it really was. ___ 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: Bindings in Swift
On Aug 9, 2014, at 09:48 , Gerriet M. Denkmann wrote: > Are bindings supposed to work in Swift? I haven’t played with them at all, yet, but they have to work (eventually, even if not yet), or interoperability couldn’t work. But … 1. Don’t forget to mark your observable methods and properties as ‘dynamic’ (new in the latest beta). Now that I think about it, though, I hate this “enhancement”. It turns something that’s relatively simple to use (bindings or KVO) into something that’s obscure for Cocoa newbies, and gives us one more housekeeping task to forget, even if we’re newbies. 2. Is your class a subclass of NSObject? If not, or maybe even if so, you have name-mangling and namespace (i.e. module name) issues to be wary of. 3. You could try getting Xcode to generate the Obj-C bridging header and see what it says about your class from an Obj-C perspective. ___ 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: Does NSPointerArray support zeroing weak references under ARC
On Aug 9, 2014, at 01:46 , Roland King wrote: > I do sometimes wish the revision history was a bit more verbose, or at least > there was a way to see the various revisions of the document to see what > actually changed. The 2011-09-16 revision note was correct, because at that time (and until 10.8, I suppose) there wasn’t a way to use weak references with this class in ARC (or, NSMapTable, for that matter — for a while there I had my own implementation of a NSMapTable-API-lookalike that *did* support ARC weak references). When the weak pointer functionality was eventually restored, the new constants were introduced and the old ones deprecated. I have to admit that I’ve read the description of the difference between the old and new constants several times, and I don’t really understand what it says. On a good day, perhaps, it makes sense for a few seconds before I need to go “Huh?” again. ___ 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: Swift and NSXPCInterface
On Aug 8, 2014, at 23:48 , Gerriet M. Denkmann wrote:
> let b = NSXPCInterface( protocol: Xpc_CommonProtocol )
When I try it, the “protocol” is syntax highlighted as a keyword, so I suspect
that’s the first problem. Taking a cue from the declaration of NSXPCInterface
itself, I can fix that problem like this (using a protocol that exists for me,
just for this test):
let b = NSXPCInterface( `protocol`: NSTableViewDelegate )
After that, the compiler gives another error, and offers to fix it to:
let b = NSXPCInterface( `protocol`: NSTableViewDelegate.self )
which compiled without error.
Then I tried declaring a protocol called ‘Xpc_CommonProtocol’ and using it
instead:
protocol Xpc_CommonProtocol {}
let b = NSXPCInterface( `protocol`: Xpc_CommonProtocol.self )
and that fails with a hard-to-interpret error about type “Protocol”. Fiddling
around, I changed it to:
@objc protocol Xpc_CommonProtocol {}
let b = NSXPCInterface( `protocol`: Xpc_CommonProtocol.self )
and it compiled. I guess it makes sense that it has to be an Obj-C protocol,
but getting there isn’t at all obvious.
___
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: restricting InterfaceOrientations
On Aug 7, 2014, at 20:50 , Gerriet M. Denkmann wrote: > Problem: on iPhone the DetailView does not make sense in landscape (iPad is > fine with landscape). A while back I went through some self-immolation trying to sort out a similar difficulty. I don’t remember the details, but it’s not just a question of getting the correct orientation, but getting the status bar in the right place, and that turned out to be harder than it ought to be. My suggestion: don’t try to restrict the rotation of the detail view, but display something else when it’s in landscape. For an example, look at the Now Playing view in the built-in Music app. (It actually seems to have some controls in landscape now, but IIRC it used to just display the cover art in iOS 6 and before.) ___ 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: Is substitution of block-function parameters OK when it's an object type?
On Aug 5, 2014, at 09:38 , Daryle Walker wrote: > The type of “obj” was originally “id,” but I changed it to what I knew the > NSArray object actually held. The compiler accepted it. Can I change any > block parameter, or only ones that are Objective-C objects? (For example, > would changing the type of “idx” or “stop” cause errors?) What happens if I > use the wrong Objective-C type? There are two separate issues: 1. If you change the type, does that change the internals of the way the underlying function is called? Generally, substituting one pointer type for another is safe in this respect, since on all Apple-supported architectures, all pointers are the same size. (Same size within the architecture, I mean. Different architectures might have different sizes.) 2. If you change the type, does the value of the parameter get mishandled? Generally, yes. But when you are downcasting an object pointer (that is, the type you specify is a subclass of the object class that the API specifies), it’s safe if you have reason to know that the object is really of the downcast type. (If not, you can make a runtime check on the object class.) Changing idx's ‘NSUInteger’ to something else won’t cause any immediate crash, but in theory you might end up with the wrong value, because of a missing sign conversion, or a bit truncation. Changing the ‘stop’ parameter type is a very dangerous thing to do, because it’s an ‘out’ parameter, and so involves a pointer to somewhere else in memory. Write the wrong thing there and you can unleash havoc. The kind of object downcasting you did is fairly common, and fairly safe, pragmatically. (OTOH Swift won’t let you get away with it.) ___ 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: ARC and NSObjectController bindings through file's owner
On Aug 1, 2014, at 12:03 , Jerry Krinock wrote: > Unfortunately, I’m not able to justify my design pattern based on the Cocoa > Bindings API documentation. As I said earlier in the thread, that fact that the error messages go away doesn’t mean the problem doesn’t exist. However, I think you’re correct that a good-enough solution is here good enough. > Looking through my code, although I never really gave this too much thought, > it appears that I tend to -unbind: when in doubt. I’d suggest sprinkling around the setting of relationships to nil (KVO compliantly). If you do that, bindings will take care of themselves, and you’ll deal with more cases (that is, observations that aren’t bindings). The other thing we’ve got going for us is that we know *when* the whole structure needs to be brought down — when the window closes, or when the document closes, depending on which properties we’re talking about — and our code can act accordingly. This is not true in the general case of old GC code that implicitly relied on a “finalization is eventual resource release” heuristic. As a side effect of this last knowledge, Sean could actually solve his weak reference observation problem (though it was not, as it turned out, the cause of the error messages in this case) by changing the references back to strong, and manually breaking cycles at close time. It’s nicer not to have to do this, but it’s certainly feasible. Rambling on… I think Swift’s take on the referencing part of this problem is interesting. For a situation like this, where the objects have basically the same lifetime, as the document, window controller and view controller do in this case, Swift encourages you to use ‘unowned’ references rather than weak references to avoid the reference cycles. That’s not quite as scary as the equivalent ‘__unsafe_unretained’ in Obj-C, because such references in Swift are *guaranteed* to crash if used after the referenced object has been deallocated. In Obj-C, of course, it’s a matter of luck whether it crashes. Unfortunately, Swift has nothing to say (yet) on the subjects of KVO or observations, but we live in hope. ___ 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: ARC and NSObjectController bindings through file's owner
On Jul 31, 2014, at 09:05 , Sean McBride wrote: > Other than use of 'weak', how else might something be changed in a > non-KVO-compliant manner in ARC but not GC? Again, the error is only in ARC > and not GC. I’m not sure this is the most productive way to approach this. The detection of an error may depend on the order of deallocation, so your ARC and GC implementations may be equally incorrect, but the error not equally reported. Also, the aggressiveness with which this error is reported may vary with the system version and the memory model. I had the impression that Mavericks was checking for dangling observers more thoroughly than earlier versions. ___ 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: ARC and NSObjectController bindings through file's owner
On Jul 30, 2014, at 13:33 , Sean McBride wrote: > File's Owner (my NSViewController subclass) responds to 'windowController' > because I have a vanilla synthesized weak property relating my > NSViewController to its containing window's controller. This is the problem. Weak properties aren’t KVO compliant (they change to nil when the referenced object deallocates, but no KVO notification is produced), so you can’t safel bind through them. ___ 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: Autolayout frustrations with NSOutlineView [SOLVED, +follow-up question]
On Jul 30, 2014, at 00:39 , Graham Cox wrote: > it seems to simply be shifting the problem to another place, not solving it Yeah, I suppose so. Typically, NSClipView *not* intended to be responsible for constraining its "document view” subview in at least one direction (and possibly both). I think that means that at the very least, you’d hypothetically need to install and/or modify height or width constraints dynamically at run time to make scrolling work. That might be marginally easier than calculating the frame dynamically, but it doesn’t seem like a good use case for autolayout. ___ 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: Autolayout frustrations with NSOutlineView [SOLVED, +follow-up question]
On Jul 29, 2014, at 22:38 , Graham Cox wrote: > Unfortunately I don't think this will work for me if I understand what you're > saying correctly, because my document content is in fact a drawing canvas > that has a fixed size (that the user can set) but this is independent of the > size and aspect ratio of the clip view. The canvas can be zoomed at will, and > will often become smaller than the entire clip view, at least in one or other > dimension (though both is common too). What I’m suggesting is that the document view and the canvas are not the same thing, and the canvas need not even be a view. The canvas bounds and the document view bounds are not the same thing, in general: — The document view bounds are forced to be at least as large as the clip bounds. — The document view bounds are forced to be at least as large as the canvas bounds, in the canvas’s current scale. Thus, if the canvas is smaller than the clip view (in either or both dimensions), it is simply drawn within the document view. This can be achieved either by making the canvas a subview of the document view, or by drawing in the document view itself but limiting the drawing to the bounds of the canvas, in the dimensions that the canvas is smaller. ___ 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: Autolayout frustrations with NSOutlineView [SOLVED, +follow-up question]
On Jul 29, 2014, at 18:52 , Graham Cox wrote: > What I want is to have my enclosed custom view 'stick' to the top, left (or > wherever it's scrolled to) of the clip view as long as it's larger than the > clip view, but become horizontally and vertically centered in the clip view > if it's smaller (e.g. when zoomed so that its frame shrinks). This is a > fairly classic requirement, and has been solved in the past by having a > custom clip view that can recognise the 'smaller than' situation and force > its contained view to be centred. Actually, I’ve never (that I recall) taken that approach, but rather constrained the “document” view (the clip view’s child) to be at least as large as the clip view — and coincident with the clip view when they’re the same size, of course. Then, when the content is zoomed in far enough, it can just be drawn directly on the central part of the (too-large) document view, or you can add a subview pinned to the center of the document view that’s responsible for the drawing. There are a couple of other good reasons to draw in a clip-view-size document view, rather than a smaller view that just encloses the content: 1. If you have the ability to drag out a selection rectangle, its visible representation doesn’t stop at the edges of the central portion of the clip view. 2. IIRC, the ruler annotations stop drawing at the boundaries of the document view, which in your scenario produces blank ruler sections that can look mighty strange. 3. If there’s an inner focus-ring indication of some sort for the content area, I think it looks better drawn just inside the clip view bounds, rather than the smaller content bounds. (But I had to draw a custom indication, because it was on the inside of the view instead of the outside. Now that we have more robust outer-focus-ring drawing mechanisms, I don’t think I’d bother with the custom inside-view focus ring any more.) ___ 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: UIScrollView question
On Jul 26, 2014, at 22:19 , Luther Baker wrote: > Are you hoping that when the keyboard comes up -- it shortens the parent view > you are referring to? No, it’s more complicated than that, but I think it’s the *question* that’s complicated, more than the answer. First you have to decide what you actually want to happen when the keyboard is up. You have 4 views, you said, 3 of which I assume are short (maybe about 1 line high each), and the last of which takes up the rest of the screen normally. So, when the text view becomes first responder and brings up the keyboard, do you want all of them to keep their original sizes, but just scroll what doesn’t fit off the top of the screen? Or do you want to have the top 3 views to keep their original sizes, and the text view to get smaller according to how much space is left by the keyboard? Or something else? If you don’t need to change the scroll view’s size (if “yes” to the first question — which I think is what you originally described as the goal), then setting the content and scroll indicator insets (along with scrolling the current insertion point onto the screen) ought to be all you need. You don’t actually need to resize anything. If you need to change the scroll view’s size, then any auto layout constraints *inside* the scroll view should keep your text view at a suitable size, and you shouldn’t need to muck about with the layout inside the scroll view manually. The problem then becomes one of getting the scroll view itself sized correctly. If the scroll view itself is subject to auto layout constraints relative to its own ancestors and siblings, I guess you’ll have to update its height-controlling constraint, *or* override its superview’s ‘layoutSubviews’ to set its frame directly after auto layout has had at it. If the scroll view is not subject to auto layout constraints, then you can just resize it directly. That’s a lot of if’s… ___ 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: UIScrollView question
On Jul 26, 2014, at 21:09 , Quincey Morris wrote: > Isn’t the answer to this … Sorry, I quoted the wrong thing. I meant, isn’t the answer to the stuff about the keyboard in that documentation? Is the scroll view there only to deal with the case of the keyboard appearing? In that case, won’t a “bottom space to superview” constraint do the right thing, or (if scroll views are one of those cases where the obvious thing doesn’t work) can’t you add a height constraint to the text view at viewWillAppear time? ___ 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: UIScrollView question
On Jul 26, 2014, at 20:58 , Luther Baker wrote: > I have a pretty good frames based background but I'd like to consider an > iPhone screen done with AutoLayout on a UIScrollView such that the bottom > UITextView grows vertically to fill the vertical space remaining from the > text view to the bottom of the device. > > UIScrollView parent > > [Label] > > [TextField] > > [Label] > > [TextView] > > > > So basically, without calculating and then setting the height explicitly, > how should the TextView be directed to vertically grow to fill the lower, > visible part UIScrollView? Isn’t the answer to this here: https://developer.apple.com/library/ios/documentation/StringsTextFonts/Conceptual/TextAndWebiPhoneOS/KeyboardManagement/KeyboardManagement.html (especially the code fragment at the end)? ___ 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: NSCursor tracking areas
On Jul 24, 2014, at 14:35 , Cody Garvin wrote: > I think I’ll try your’s and Edward’s suggestion on attempt mouseEntered / > mouseMoved with a single tracking area. From one point of view, I would recommend *not* taking this approach, since it comes near to flailing, and that’s never a good way to solve a problem for realz. OTOH, I have to admit that I usually end up taking an overkill approach. That is, I implement whatever event method overrides I need (including cursorUpdate), then in *all* of them I invoke a method that decides what cursor to show. That includes mouseDown, mouseUp and mouseMoved/Dragged if they’re overridden. This doesn’t feel quite as smelly as making an end-run around cursorUpdate, but that may just be self-justification. I’d advise you to persevere with debugging the original problem. The most informative route is to find out what the conditions for failure are. (Coordinate system changes when scrolling occurs? Tracking areas overlapping system-defined tracking areas at the borders of the window? Something changing the cursor after you set it correctly? One particularly annoying special case is that in a scroll view, the clip view monitors the cursor near the edges where scroll bars appear, and will set the cursor back to the arrow if you venture into the scroll bar. You may need to set the scroll view’s “documentCursor” property to get the cursor you expect.) > Again, I am building on 10.10 for 10.10, so maybe there is something there. > It seems like a very straight forward attempt. It may of course be a 10.10 issue, but it’s not a good idea to start there. In my experience with NSTrackingArea, it’s always your own fault, but it’s always very hard to debug. ___ 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: NSStream's enum of NSStreamEventEndEncountered.
On Jul 24, 2014, at 11:58 , edward taffel wrote: > NSStreamEventOpenCompleted = 1 << 0, > > a point of style? Supposition: It’s point of API self-documentation. The shift indicates that this is a bit mask (or bit field) value, and hence that the enum’s members can usefully be OR’ed together. Unshifted, the members would be whole values, and therefore mutually exclusive. But I wouldn’t necessarily expect that the SDK is 100% consistent in this regard. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How do I temporary retain self, under ARC?
On Jul 17, 2014, at 20:01 , Jens Alfke wrote:
> The only thing I’ve found that works is
> CFRetain((__bridge CFTypeRef)self);
> at the top of the method, and a corresponding CFRelease at the end, but this
> is pretty ugly
This seems to be the right way to do it. A CFBridgingRetain/CFBridgingRelease
pair may be a slightly prettier way of achieving the same effect.
It’s always going to be ugly to some degree, because the solution you’re using
isn’t the solution to your problem, it just fixes your problem “accidentally"
as a side effect.
> and could cause leaks if the method returns early.
Perhaps the following pattern would work:
- (void) someMethod {
CFTypeRef selfRef = CFBridgingRetain (self);
@try {
doSomeStuff;
[self.delegate object: self didSomeStuff: yeah];
if (somethingWentWrong)
return;
doSomeMoreStuff;
}
@finally {
CFBridgingRelease (selfRef);
}
}
> Am I missing some convenient way of doing this? I looked through the ARC
> docs, at least those I could find, and didn’t see anything relating to this.
Your real problem is that you don’t have a safe mechanism for ensuring the
object’s lifetime. If you solve that, you won’t have to worry about any of the
above.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Issue with -[NSOutlineView autosaveExpandedItems] - SOLVED
On Jul 12, 2014, at 13:50 , Bill Cheeseman wrote:
>__block id returnItem = nil;
>__block void (^findItemForIdentifierInArray)(NSArray *) = ^(NSArray
> *contents) {
>[contents enumerateObjectsUsingBlock:^(id obj, NSUInteger idx, BOOL
> *stop) {
>if ([[obj objectForKey:ID_KEY] isEqualToString:identifier]) {
>returnItem = obj;
>*stop = YES;
>}
>id subarray = [obj objectForKey:CONTENTS_KEY];
>if (subarray) {
>findItemForIdentifierInArray(subarray); // recursive
>}
>}];
>};
>
>findItemForIdentifierInArray([self sourceListContents]);
>return returnItem;
> }
>
> The only remaining problem is that the recursive call to
> findItemForIdentifierInArray() is flagged with a warning that it is likely to
> lead to retain cycles, hence leaks.
I dunno, this sort of thing makes my head hurt too. But I can’t see any
downside to changing this to use a private method and a for loop inside it,
other than having to think of a private method 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: View-based outline view problem
On Jul 11, 2014, at 00:24 , Shane Stanley wrote: > Just seems a lot of work for something that doesn't strike me as an uncommon > need. In such a case, it’s also worth re-considering your UI at a higher level. I wonder, for example, whether there’s an alternative that uses *two* text fields. Put the file name in the ‘textField’ outlet field, and put the extension in a separate but adjacent field. Use auto-layout to keep both fields sized to their contents, and to keep the second field immediately adjacent to the first. If that’s actually possibly, it’ll look like a single string when not being edited, but will change the UI so that editing of the pieces is separate. (Or make the extension field uneditable, if you don’t actually allow it to be changed.) It might even be *better* than the old way. :) Something like that. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: View-based outline view problem
On Jul 10, 2014, at 23:34 , Ken Thomases wrote: > Have you connected the delegate outlet of your text view (field?)? This was my first thought, too, but: 1. The delegate method ‘control:textShouldBeginEditing:’ seems like it’s called too late. Presumably the selection change needs to be done when the text field gets first responder status, not when the text is actually changed. 2. It’s not obvious to me how the text field gets first responder status. In the TableViewPlayground sample code, it does, without any apparent support, so I assume this is something built into NSOutlineView -> NSTableViewCell -> textField outlet (when you press Return). I don’t know how you’d customize that if you have a non-standard table cell view. In particular, I don’t see how you’d know *when* this was happening. I guess you could solve it with a NSTextField subclass that overrides becoming first responder. Or is there a more direct solution, do you think? ___ 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: View-based outline view problem
On Jul 10, 2014, at 00:25 , Shane Stanley wrote: > I fear I'm doing something basic incorrectly, but I can't see what. My > -outlineView:viewForTableColumn:row: is not even getting called, which seems > very odd. (And yes, I commented out > -outlineView:willDisplayCell:forTableColumn:item:). Any suggestions? You are doing something basic incorrectly. That NSOutlineView delegate method is called ‘outlineView:viewForTableColumn:item:’. ___ 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: Smarter NSTimer?
On Jul 1, 2014, at 11:21 , William Squires wrote: > Use-case: > I have a (fictitious) FPS game in which the players or bots can "damage" the > scenery by leaving blast marks. A timer should remove these "decorations" > after a given delay, but I want the timers to pause if any players/bots are > within line-of-sight of the decorations. It seems to me it’s a mistake to use “per event” timers at all in this scenario — it might not scale well. The way I’d approach it (after thinking about it for about 30 seconds, so this may not be intelligent at all) is to create a set of “future event” objects, each of which has its own “remainingTimeDuration” property, along with information about what it is you want to do at the end of the duration. Then, use a single timer, which is set to fire at the end of the remaining time of the soonest event. If a new event is created, or if the game is paused, or if the timer expires, invalidate the timer, subtract the actual elapsed time since the timer was started from each pending event, and start a new timer for the soonest of the newly updated events (if not paused, or start this timer at the end of the pause). ___ 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: Problems with NSComboBox delegate
On Jun 26, 2014, at 11:44 , William Squires wrote: > the delegate method (of interest): > > -(void)comboBoxSelectionDidChange:(NSNotification *)notification > > doesn't pass the reference to the NSComboBox whose selection changed, It does. It’s usual for these sorts of delegate methods that the sender is the notification object (that is, ‘notification.object’). This is documented if you follow the documentation link to the notification itself. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How does a UIButton perform a segue?
On Jun 25, 2014, at 16:06 , Rick Mann wrote: > Well, I suppose, but that sort of forces the -prepare method to know a lot > about the view hierarchy. I'd rather not do that. Your original question was about finding the cell for the button. Therefore, it’s already implicit in your approach that the view controller doing ‘prepareForSegue:’ knows that the button is in a table view, hence in a cell, hence a subview of the cell. There’s no special-case knowledge involved there. The view controller doesn’t need to know in advance how many steps up there are from the button to the cell, if that’s what’s worrying you. You can use one of those loopy things to find the cell. ;) ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How does a UIButton perform a segue?
On Jun 25, 2014, at 16:00 , Rick Mann wrote: > The button is the sender. But there's no way to determine in which cell that > button is. Sure there is. Walk up the tree of superviews from the button till you find the enclosing cell. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How does a UIButton perform a segue?
On Jun 25, 2014, at 14:44 , Rick Mann wrote: > The problem I need to solve is for that destination view controller to know > which represented object was associated with the cell in which the source > UIButton was. But I can't see how to do that. Doesn’t ‘prepareForSegue:’ give you the information you need? Presumably ‘sender’ will be the button in this case ___ 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: NSButton, Templates, images…
On Jun 24, 2014, at 15:31 , Alex Kac wrote: > I’m sure I’m missing something simple. > I have an NSButton with an image. I’d like to have the button look etched > when unselected - and tinted blue when selected It was a while back since I was missing the same thing. IIRC, what you need to do is: 1. Set your template image as *both* the standard and the alternate image. 2. Set the button’s *value* to 1 to get the alternate image — which will then have the blue highlight. Currently, I don’t have any buttons that do this with images, but I use the same rules for text that turns blue when the button is “on”. Previously, I used this for a “play” button that had a black play icon when off, and a blue pause icon when on. That ability to use different images for the states is why you have to set the image twice. ___ 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: NSWindowController and designated initializer rules
On Jun 24, 2014, at 07:55 , Sean McBride wrote: > I guess it's omission could be a bug, but assuming not, Sketch gets a > compiler warning if you tag its own designated initializer (init) with > NS_DESIGNATED_INITIALIZER, since it doesn't call one of super's designated > initializers. It doesn’t look like a bug per se, since the old NSWindowController pattern is grandfathered into the Swift world. However, tagging a subclass ‘init’ as designated will break it. I believe you can solve it if you implement ‘initWithWindow:’ as a designated initializer in the subclass too (just calling super). In that case, your subclass will inherit ‘initWithWindowNibName:’ as a convenience initializer, so it can be called by your subclass ‘init’ — though I would assume only as ‘self initWithWindowNibName:’, not as ‘super initWithWindowNibName:’. > I was trying not to mention 10.10 due to any NDA (though Apple seems more lax > about it recently) Nothing I said was under NDA, since all the information came from the Swift book and the WWDC videos, which are not under NDA this year. In fact, I haven’t downloaded 10.10 or Xcode 6 yet. Since the answer to your question isn’t under NDA, I think we can assume the question was legal too. :) ___ 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: NSWindowController and designated initializer rules
On Jun 23, 2014, at 20:16 , Graham Cox wrote: > And the example code is Obj-C. Why would Swift come into it? Sorry, I wasn’t carping at you. It just occurred to me that “no one cares” in the pure Obj-C case — we know that invoking ‘super initWithWindowNibName:’ is safe, since we’ve all done it for years. Hence my speculation that it was Swift’s greater formalism that got Sean thinking about this. Speculation only. Anyway, I believe Roland’s answer is correct: Swift has a loophole that lets the NSWindowController init pattern work there too. ___ 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: NSWindowController and designated initializer rules
On Jun 23, 2014, at 17:30 , Graham Cox wrote: > I interpret that to mean it must call a designated initializer *eventually*, > not necessarily directly. Since all -initXXX methods of the superclass must > call the superclass's designated initializer, your subclass's D.I. can call > any of the superclass's -initXXX methods. Actually, I understood the thrust of Sean’s question as being that NSWindowController’s initializers don’t follow Swift rules. If you look in the Swift book, you’ll see that convenience constructions may only call “across” (that is, call an initializer in the same class), while designated constructors may only call “up” (to a *designated* initializer in the superclass). In that regard, ‘initWithWindowNibName:’ must be a designated initializer, since subclasses that don’t do their own nib loading have nothing else to call “up” to. I assume, therefore, that ‘initWithWindowNibName:’ is marked as a designated initializer in 10.10, though I haven’t looked to check this. ___ 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: Advice on document handling
On Jun 20, 2014, at 16:44 , John Brownie wrote: > I have a complex document bundle, and I'm trying to figure out which files > within the package have unsaved changes, and it looks like there's no support > for that model in NSDocument. I haven’t been following this thread very closely, so I may misunderstand, but there’s a fairly simple way of doing this that might work for you. The key is to *keep* the top level NSFileWrapper you’re given when opening the (multi-file) document. When creating a new one, just set the kept wrapper ivar or property to nil. When any change is made to the document (so you’d put this in the same place that creates undo actions, I guess), you determine which files within the package are/will be affected, and you *remove* the corresponding sub-wrapper from the store top level wrapper. At save time, you walk your new/intended file hierarchy, creating missing wrappers as you go. By definition, wrappers that aren’t missing represent files that haven’t changed. When you’re done, you return this revised wrapper from your save method. Because you haven’t re-created the wrappers for non-changed files, the NSDocument saving mechanism realizes that those files don’t need to be re-written and hard-links to the existing ones, typically. Thus, if your package contains 100 files but only 1 has changed, a save or autosave will be fast because only 1 file gets written and copied (from the temp save location to its final location). Is that procedure of any use to you? ___ 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: iOS app restarting from screen one. Why?
On Jun 19, 2014, at 08:24 , Alex Zavatone wrote: > There is no message thrown in the console and the applicationWillTerminate: > method isn't called at all. Generally, since iOS 4, applicationWillTerminate: is never invoked. You get applicationDidEnterBackground, and that’s where you’re supposed to save your state. (The exception is when you’re doing background processing.) This is clearly documented here: https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/ManagingYourApplicationsFlow/ManagingYourApplicationsFlow.html and a couple of people already mentioned it in this thread. If you’re still using applicationWillTerminate: in your app, you’re Doing It Wrong™. ___ 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: Dictionaries or custom class containing no methods?
On Jun 17, 2014, at 15:21 , Trygve Inda wrote: > Thoughts on the pros and cons of both methods? I strongly agree with Lee Ann that the custom class is a better approach. It almost always happens that you (eventually) want to associate behavior with the properties. There can also be issues trying to use bindings and KVO on values stored in a dictionary, when the relationship between the values and the UI gets more complex. I always find myself rewriting quickie dictionaries as classes, and swearing not to take the shortcut next time. ___ 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: initWithCoder: calling init in custom class
On Jun 16, 2014, at 13:36 , Trygve Inda wrote: > In the later method, if the encoded object does not contain kValueCKey, the > object created will still have the correct default value for valueC (9). It won’t, because you assigned nil to valueC *after* it’s set to the default. Personally, I’d be inclined to have initWithCoder call super, because in more complicated examples the logic tends to be quite different. If you have common initialization (such as the initial setting of defaults), put them in a private method that both initializers call. ___ 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: Implicitly unwrapped optionals
On Jun 14, 2014, at 13:09 , Ken Thomases wrote: > For convenience. Specifically, IIUC, the point is that NSDate? and NSDate are different, incompatible types. The convenience comes from not having to “cast” NSDate? to NSDate by using the “!” operation in expressions. On Jun 14, 2014, at 12:45 , Roland King wrote: > Finally if you have an implicitly optional Bool, bbb, what does > > if bbb > > do? Did you mean “implicitly unwrapped”? Then, by the above logic, the type of the ‘if’ expression is Bool, so it would crash if ‘bbb’ is nil. Otherwise, it would test the boolean value of ‘bbb’. IIUC ___ 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: NSOutlineView floating group row question
On Jun 14, 2014, at 11:03 , Bill Cheeseman wrote: > I must be overlooking something in those examples. I have a vague recollection of once trying to use the IB source list item and running into something that seemed oddly configured. It might be simplest to try deleting your source outline view, and adding a normal one, then reconfiguring as a source list manually. But I’m just guessing. ___ 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: Conditionally allowing multiple selections in NSOutlineView
On Jun 8, 2014, at 21:46 , Graham Cox wrote: > Can anyone think of a way to achieve this? 'outlineView:selectionIndexesForProposedSelection:’ ? It’s preferred over ‘outlineView:shouldSelectItem:’ these days anyway. ___ 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: Simple question? NSButton/checkbox color
On Jun 6, 2014, at 01:05 , Lee Ann Rucker wrote: > There's no supported way to do it and never has been I was able to do it — at least partially — in IB: — Select the checkbox — Display the “Core Animation Layer” tab of the inspector palette (the last icon on the right) — Check the box next to the checkbox’ entry in the list. — Add a filter to the “Content Filters” list. — Change the filter to “Hue Adjust”, and enter a parameter to get the color you want. This worked for me when the checkbox was checked, though it was still gray when unchecked — presumably because it’s desaturated so the hue change has no effect. You can probably make it work like Calendar by choose a different filter (Colorize?) or a combination of filters. OTOH, I can’t help saying that colorizing checkboxes doesn’t sound like a fruitful approach to UI design. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Silly ARC question - explanation requested
On Jun 4, 2014, at 14:45 , Alex Zavatone wrote: > But I need to come up with an explanation of explain why that is a bad idea > and why it smells It smells because a computationally intensive while loop will stall the dispatch queue that’s stuck on it. If you’re programming with *threads*, it’s fine to dedicate a thread to a long-running operation. If you’re programming with *dispatch queues*, you’re sharing a resource (a CPU) with other applications. Taking the resource over for yourself is detrimental to overall system performance. Breaking the long task into smaller pieces allows the pieces to be distributed over as many threads as the OS wants to use, and doesn’t deny access to CPUs to other threads and processes. ___ 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: Silly ARC question - explanation requested
On Jun 4, 2014, at 12:24 , Alex Zavatone wrote: > His response was "Well, I was able to autorelease any offending bits within > the loop without a problem, what's the big deal?" I think the deeper problem is that a while loop of this kind in an asynchronously executed block is a bit of a code smell. Surely the first step is to refactor the code so that each iteration is a separate block invocation. You either queue these for execution on a parallel queue for multitasked execution, or on a serial queue if execution must be sequential**. (If the interior of the while loop was trivial, you might not do it that way, but if it’s allocating significant amounts of memory each iteration, and doing significant work, then block-per-iteration sounds more reasonable.) Then, you can and should enclose each block’s code in an autorelease pool, which should stop memory accumulating. In the context of your original question, the problem is that while you *might* be able to predict the autorelease behavior in regard to what you *think of* as the “final” autorelease, you don’t know for certain — when any frameworks or 3rd party code is involved — if there might be *other* life-sustaining references to the objects. It’s “autorelease” after all, not “autodealloc”. This is not really an ARC-related pitfall, but a GCD-related one, IMO. ** You can use counting dispatch semaphores if you want something in between — several blocks queued but not for every iteration at the same time. ___ 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: string literals and performance
On May 24, 2014, at 21:08 , 2551 <2551p...@gmail.com> wrote: > Are there any performance implications that would suggest preferring one or > the other of these different styles? > > NSString *s = @"sing me a song"; > [myClass aMethod: s]; > > and > > [myClass aMethod: @"sing me a song”]; Basically — if not literally — no. > I have a lot of the first kind in my code, and I'm thinking of simplifying it > by turning them all into the second kind. There’s a good chance that the compiler already optimizes the first form into the second form. > A discussion on stackoverflow here: > > http://stackoverflow.com/questions/25746/whats-the-difference-between-a-string-constant-and-a-string-literal > > seems to suggest (if I've understood it correctly) that I'd be better off > sticking with the first style to avoid errors and to speed up comparisons. There is no difference in performance that you should consider *unless* you have documented evidence of certain string comparisons causing performance problem. Any other stance is unnecessary premature optimization (and you don’t know that it will make any kind of difference at all). The case discussed on SO where you use a global string variable is also unnecessary premature optimization, again unless you have some reason to believe you have a problem. If this really worries you, you can *try* to write a sample app where the source coding style leads to a measurable performance difference. If you can do it, post the code here, because I’m sure we’d all be flabbergasted to see it. ;) > However, since in my code they're all one-off 'throw away" strings that don't > get used elsewhere, that doesn't seem relevant. Is there any other reason why > I should stick with the first style rather than the second? No, the second style is better IMO: a. It’s less keystrokes to type. b. It’s clearer when you read the source code again later. OTOH, if you’ve got a method invocation that is very long, it could be be argued that splitting it into multiple lines (the first style) makes it easier to read. Since it’s almost entirely a stylistic matter, use the form that looks less ugly to you. ___ 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: 'nuther dumb question
On May 16, 2014, at 16:46 , William Squires wrote: > Why doesn't NSData have a +[NSData dataWithString:(NSString *)] or -[NSData > initWithString:(NSString *)] method? Because strings consist of *encoded* data, which (in principle) has no meaning outside the internals of the string itself**, and which is (in principle) architecture dependent***. Therefore strings (in principle) have no obvious external representation. > i.e. how do I convert the contents of an NSString object into an NSData > object? -[NSString dataUsingEncoding:allowLossyConversion:] You can specify UTF-16 for the conversion, if you like. ** That is to say, we *know* that NSString objects are arrays of UTF-16 code points, and we use that knowledge, but you can’t interpret the string’s raw data without knowing the encoding. *** That is, endianness is an issue. And the most common one these days, I think, is UTF-8, which you can’t get from NSString without a conversion. ___ 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: debugging unrecognized selector
On May 16, 2014, at 01:01 , Torsten Curdt wrote: > the debugger only stops in UIApplicationMain. That’s most likely because your “level of detail” slider (the horizontal slider below the call stack in the Debug pane) isn’t at the extreme right end. > What I am seeing in the log is > > 2014-05-16 09:46:56.796 MyApp[30998:60b] -[__NSCFString CGColor]: > unrecognized selector sent to instance 0x10debb640 > > Checking the address with `po` I can see the string. But it still did > not help to find where this happens. I added the following > breakpoints: > > * All Exceptions > * -[__NSCFString CGColor] > * -[NSString CGColor] The last 2 won’t help. NSString doesn’t have such a method, so the breakpoints will never trigger. (You’ve effectively set a breakpoint on a global symbol that doesn’t exist.) ___ 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: Custom view and array bindings
On May 13, 2014, at 21:14 , Jim Geist wrote: > Can anyone point me at sample code and/or docs around implementing bindings > to an NSArrayController from a custom view (i.e. what a control like > NSTableView might do under the covers?) AFAIK, the only documentation is here: https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/CocoaBindings/Concepts/HowDoBindingsWork.html but it’s extremely out of date, and was fairly hard to follow even when the screen shots matched the actual OS (somewhere around 10.4). I’d recommend you don’t implement a custom binding at all. Custom bindings were only really useful when they were reusable in IB (that is, in Xcode 3, which supported IB plugins), because if you are doing it all in code, you may as well just write code for a two-way observation/update mechanism, without packaging it as a binding. Any custom binding you implement now can’t be used directly in IB. ___ 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: Hang during AESend
On May 13, 2014, at 13:03 , Trygve Inda wrote: > NSAppleEventDescriptor *appleEvent = [NSAppleEventDescriptor > appleEventWithEventClass: kMyAEClass > eventID: kMyAEEventID > targetDescriptor: targetDescriptor > returnID: kAutoGenerateReturnID > transactionID: kAnyTransactionID]; > AESendMessage([appleEvent aeDesc], NULL, kAENoReply | kAENeverInteract, > kAEDefaultTimeout); What memory model? ARC? You’re getting back back a NSAppleEventDescriptor with +0 semantics, which means (if ARC) it’s going to be locally retained, then released when it goes out of scope (possibly a scope optimized optimized to the last reference). What you’re passing to AESendMessage is an interior pointer (‘aeDesc’ is marked NS_RETURNS_INNER_POINTER in the headers). AFAIK that keeps the underlying object alive *in the calling code* long enough for the interior pointer to be passed safely into the called function, but no longer. In particular, I don’t know that the interior pointer can be assumed to be valid for the entire length of the called function’s execution. Of course, there’d have to be asynchronous activity (or perhaps a autorelease pool drain inside the called function) for this to matter, but since you’re not asking for a reply, that seems possible. So, my theory: memory management bug in your code. A simple way to test this would be to put ‘[appleEvent self];’ after the AESendMessage call, and see if the problem goes away. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Problem posting to this list?
On May 11, 2014, at 17:30 , William Squires wrote: > I'm getting a mysterious message Yes, me too. I think the explanation is that someone subscribed to the list has had their email account hacked (or possibly just misconfigured), and there is some kind of bounce from their message delivery. Maybe the bounce message is actually malware. I’ve also been seeing other spam making it through spam filtering recently, and I suspect it’s related. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How to check if file exists?
On May 10, 2014, at 15:17 , Charles Srstka wrote: > Since that's the case Quincey was talking about (greying out files that don't > exist in the UI), I'd say checkResourceIsReachableAndReturnError: is the > appropriate API to use. It's certainly more efficient than reading the file > just to see if it exists. It might be the appropriate API, but its semantics are not entirely obvious. The documentation does not make clear what reachability means in the case of a file URL. Presumably, file systems are reachable if and only if they are mounted, but there’s surely a slight discomfort level with such an assumption. Maybe it’s just me. Anyway, we weren’t suggesting reading the file just to see if it exists. We were suggesting reading the file if you’re going to read the file anyway. If you’re checking for existence, I think -[NSURL getResourceValue:forKey:error:] and -[NSURL resourcesValuesForKeys:error:] are good patterns to keep in mind, because in many cases you actually *do* want to know one or more resource values. For example, you might at least want to know whether the item is a file or a directory. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How to check if file exists?
On May 10, 2014, at 12:06 , William Squires wrote: > How can I make sure MyFile.txt exists before trying to read it in? You can’t, so don’t even try. :) Because the file system gets modified asynchronously by other processes, there’s always a potential race condition between checking for existence and using the result of the check. IOW, the existence check is out of date as soon as its done. The correct strategy is to go ahead and read the file. If the read fails, look at the error code, and deal with the “file does not exist” error then. Incidentally, if you did want to check if a file exists (let’s say, if you have a list of files in your UI and you wanted to gray out the ones that don’t exist right now), I’d recommend you: — determine the directory explicitly — construct a file URL using the directory and file name — get one of the URL file resources (such as the file name) for that URL — if an error results, treat that as “file does not exist” You can check the error for an explicit “file does not exist” code, if it really, but that still leaves you with other potential errors that you need to deal with somehow. You’ll likely want to do the same thing as if the file really doesn’t exist (such as gray out its name, in the above example). P.S. Fritz beat me to the punch on replying, but I’m posting anyway because I’d like to *strongly* recommend that you use a URL-based approach, and not a path-based approach. -[NSFileManager fileExistsAtPath:] is pretty much legacy API nowadays (and it’s significant that there’s no URL-based version of it). It’s worth training yourself to use URLs over paths. ___ 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: Resizing last column of NSTableView when it touches window border
On May 9, 2014, at 02:59 , Jakob Egger wrote: > Adding an empty 5px spacer column at the end is possible, but an ugly hack. > If I can't think of anything better, I'll have to go with that. Just to clarify the scenario for posterity, you’re envisaging a situation where: — the user drags the right edge of the rightmost column either to the left or to the right — if left, the column gets smaller, so what the user actually sees is the rest of the table slide to the right? — if right, the column gets bigger, so the user sees the rest of the table slide left? — in neither case does the rightmost column edge itself move to where it’s dragged according to the mouse pointer? Although it’s logical and consistent, it doesn’t seem like a great user experience to me. (A mere opinion, I know, and so basically worthless.) I would have thought that the natural way to make the last column smaller would be to drag its left edge rightwards, and the natural way to make it bigger would be to make the window wider. Technically, I think there may be a way to do what you want with a NSTrackingArea. You could put one that’s 5pt x row-height over the right end of the header cell, and write your own tracking loop that resizes the column when a drag starts there. (You’d have to override the table view’s hitTest: method to make this work.) Or even put a little view up there. It’d be a fairly hacky solution, but it doesn’t sound non-doable. ___ 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: Document being reopened on launch during modal dialog
On May 7, 2014, at 15:08 , Mills, Steve wrote: > Is this all safe and legal, releasing self right before it returns to > whatever called it? I believe it’s safe in manual RR, though you could perhaps do ‘[self autorelease]’ if you feel uncertain. I’m not sure it’d be safe under ARC (that is, doing something that could cause ‘self’ to be deallocated), because ARC might have epilogue code at the end of the scope, and that *might* refer to self. However, it’s probably safe for a different reason. ‘performSelector’ should retain its receiver, and presumably won’t release it until after the performed method returns, so your ‘[self release]’ presumably won’t actually result in deallocation. ___ 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: Resizing last column of NSTableView when it touches window border
On May 7, 2014, at 14:42 , Avery Pierce wrote: > If I'm understanding Jakob's issue, the table view doesn't scroll more than > it needs to, so the rightmost column divider is exactly at the edge of the > window. It can never be scrolled inside. You’re right. He said “rightmost column” and I read “rightmost visible column”. Personally, I think that the ambiguity (of what’s being resize) is a small UI defect. Discriminating the two cases may actually make for a poorer UI experience. We don’t know the exact circumstances, but avoiding having the last column being resizable seems like a better outcome, if there’s a way of doing it. > Have you considered throwing in an extra, blank column at the end with a > small fixed width (5px maybe)? I think that would be reasonable, too. It’s kind of a variation of the previous suggestion. Looking at Finder windows in column view, I see that it’s able to discriminate column resizing from window resizing when the last column ends at the edge of the window (though it’s not always clear that the correct cursor is displayed). But it’s really hard to tell exactly where the mouse is pointing, since pixels are mostly pretty small these days. ___ 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: Resizing last column of NSTableView when it touches window border
On May 7, 2014, at 13:55 , Jakob Egger wrote: > The problem only occurs when you have many columns and the table view > scrolls horizontally. Then you can't make the last column wider. > Dragging the left side only makes the second-to-last column narrower, > and dragging the right side resizes the window. So where is the right edge of the rightmost visible column? If you haven’t done anything special, then it could be at the window’s edge, or it could be further to the right, scrolled off the window, depending on the column width. I don’t see how the user would know the difference. Wouldn’t a user scroll the rest of the column into the window first, stopping only after the vertical line in the header row is clearly inside the window? If that’s the case, I don’t see that you really have a problem. If you’re somehow adjusting the table (either the column widths or the amount of scroll) so that the rightmost visible column always ends at the window edge, then I’d suggest changing your algorithm so that it ends maybe 4-10 points inside the edge. That would solve the problem too, wouldn’t it? ___ 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: Serializing NSDictionary for network transfer
On May 7, 2014, at 11:17 , Carl Hoefs wrote: > (1) I see that NSDictionary has an encoding method: > > - (void)encodeWithCoder:(NSCoder *)coder; > > but this returns (void), which is puzzling to me. I would expect it to return > (void *) to a malloced region containing the serialization. Where does the > object serialization reside, and how do I access it? NSKeyedArchiver and NSKeyedUnarchiver are the classes that perform the encoding and decoding. They are responsible for invoking ‘encodeWithCoder:’ and ‘initWithCoder:’ for the objects that make up an archive — you don’t do that yourself. Both NSKeyedArchiver and NSKeyedUnarchiver have convenience class methods for archiving and unarchiving an object hierarchy to/from NSData. (You can also create instances of NSKeyedArchiver and NSKeyedUnarchiver if you need a finer level of control.) Class NSPropertyListSerialization provides a similar service, but for a more restricted kind of object graph, useful when you want a textual representation of the data, for example. You really should read some of the documentation: https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Archiving/Archiving.html https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/PropertyLists/Introduction/Introduction.html Just reading the introductory sections should orient you in this Cocoa sub universe. ___ 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: Document being reopened on launch during modal dialog
On May 6, 2014, at 12:28 , Lee Ann Rucker wrote: > This may be obvious, but did you try moving it all to > applicationDidFinishLaunching: instead? IIUC, Steve’s point was that it won’t help in this case, because state restoration is initiated before applicationDidFinishLaunching:, and he’s actually trying to defer state restoration, of documents at least, until after the modal dialog is dismissed. ___ 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: Document being reopened on launch during modal dialog
On May 6, 2014, at 11:55 , Mills, Steve wrote: > We're in [FinaleAppDelegate applicationWillFinishLaunching:] (like you > mentioned later), which is where we call our cross-platform InitApp function > to load things up, set up audio, etc. The audio engine has discovered a > sample rate mismatch and is telling the user about it via modal dialog. I see. But it seems unreasonable to expect that the app won’t finish launching regardless of the modal dialog. (It may even be *necessary* for it to finish launching in order for the modal dialog to work.) So it comes down to a question of a technical violation of runModalForWindow’s event loop blocking, keeping in mind that state restoration likely isn’t triggered by an event at all. Given that a sample rate mismatch sounds like a global condition, I think the “theoretically” correct solution is to change your document’s behavior so that it can exist under the mismatch condition without getting messed up (and perhaps also without fully functionality). However, I don’t imagine you’d contemplate doing that, so I’d suggest instead that you simply override '[NSDocumentController reopenDocumentForURL:…]’ and put its parameters on a queue so that you can re-issue the request from ‘applicationDidFinishLaunching:’. ___ 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: Document being reopened on launch during modal dialog
On May 6, 2014, at 11:23 , Mills, Steve wrote: > I'm looking at a crash log for our app that shows our app is initting. During > init ([NSApplication finishLaunching]) we discover a problem and put up a > modal dialog using [NSApplication runModalForWindow:]. During this modal run > loop, something has decided that it would be a great time to handle the > reopen event, so [NSDocumentController > reopenDocumentForURL:withContentsOfURL:display:completionHandler:] is called > and we open a document while the modal dialog is up, and before we've totally > finished handling [NSApplication finishLaunching]. It sounds like you’re Doing It Wrong™. Well, sorta j/k, but seriously you’re overriding ‘finishLaunching’? From the NSApplicationDelegate protocol documentation: > "applicationDidFinishLaunching: > > "Delegates can implement this method to perform further initialization. This > method is called after the application’s main run loop has been started but > before it has processed any events. If the application was launched by the > user opening a file, the delegate’s application:openFile: method is called > before this method. If you want to perform initialization before any files > are opened, implement the applicationWillFinishLaunching: method in your > delegate, which is called before application:openFile:.)” So documents may be opened between the issuing of the two notifications (wiil/didFinishLaunching). Both of those notifications, I would assume, are posted in ‘finishLaunching’, so your concept of “totally finished handling [NSApplication finishLaunching]” sounds flawed. In particular, putting up a modal dialog before invoking [super finishLaunching] — if that’s what you do — sounds like a bad idea. Why aren’t you doing the initialization in the delegate methods? ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How to convert a UTF-8 byte offset into an NSString character offset?
On May 5, 2014, at 12:06 , Jens Alfke wrote: > How can I map a byte offset in a UTF-8 string back to the corresponding > character offset in the NSString it came from? I’ve been thinking about this since your original question, and it seems to me that this is a subtler problem than it seems: 1. You cannot *in general* map a UTF-8 byte offset to a NSString (UTF-16) “character" offset. The two representations may have different numbers of code units (1-4 for UTF-8, 1-2 for UTF-16) per code point. There’s no real answer to the question of what UTF-16 offset corresponds to the 3rd code unit of a 4-byte UTF-8 code point. 2. So, you’re restricted at least to byte offsets of UTF-8 code units that are the *start* of a code point. However, there’s a potential problem with this, because you’re not in control of the structure of the NSString. It’s possible, for example, that the UTF-8 byte offset points to the second (or later) code point of a base+combining mark sequence, but an equivalent NSString has a single code point consisting of one or two code units (a “composed character”). Even if both versions of the string have the same number of code points (“characters”), they may have different orders. 3. It’s *possible* that you can create a NSString that has the same code points in the same order as the UTF-8 string, but I don’t see any API contract that clearly guarantees it. The documentation for -[NSString initWithCharacters:length:] says that the return value is "An initialized NSString object containing length characters taken from characters.” That *might* be a sufficient guarantee, but code-point equivalence possibly isn’t guaranteed across some NSString manipulation methods, so you’d have to be careful. 4. Otherwise, I think it’s yet more difficult. The next-higher Unicode boundary is “grapheme clusters”. You can divide a NSString into grapheme clusters (either through direct iteration using ‘rangeOfComposedCharacterSequence…’, or through enumeration using ‘enumerateSubstrings…’), but to match the UTF-8 and NSString representations cluster by cluster you’d need to break the UTF-8 string into grapheme clusters using the same algorithm as NSString, and it’s not documented what the precise algorithm is. (The documentation at: https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Strings/Articles/stringsClusters.html refers to this: http://unicode.org/reports/tr29/ which I find pretty overwhelming.) 5. Even if #3 works, you may still have some troubles with grapheme clusters. For example, if a UTF-8 byte offset is actually a code point in the middle of a cluster, you may have trouble getting consistent NSString behavior with substrings that start from that code point. FWIW, my opinion is that if your library clients are specifying UTF-8 sequences at the API, and expect byte offsets into those sequences to be meaningful, you might well be forced to maintain the original UTF-8 sequence in the library’s internal data model — or, perhaps, an array of the original code points — and do all of your internal processing in terms of code points. Conversion to NSString would happen only in the journey from data model to UI text field. ___ 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: Question on NSScrollView
On May 2, 2014, at 14:06 , Lee Ann Rucker wrote: > You might find it useful to get one of the Apple sample apps, like > TableViewPlayground, and experiment with that - it's easier to figure out > what's happening when you have a fully-implemented example than it is to > start from scratch. FWIW, the code being used by the OP has every appearance of being taken from this tutorial: https://github.com/lucasderraugh/AppleProg-Cocoa-Tutorials/blob/master/Lesson%2053/Lesson%2053/AppDelegate.m but it seems to me that the class name ‘DesktopFolderEntity’ suggests an origin in a predecessor to the current TableViewPlayground, where there’s currently a class name ‘ATDesktopFolderEntity’. However, now that I look at it, this tutorial seems to be intended to show how to use group rows, which isn’t what the OP wants. ___ 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: Question on NSScrollView
On May 1, 2014, at 23:03 , Varun Chandramohan wrote: > I ran ‘tableView:viewForTableColumn and it is always tableColumn == nil as I > have just 1 column. No. ‘tableColumn == nil’ means that you’re being asked for a view for a *group row*. A group row: (a) spans all columns (though there’s just a single column to span, in this case), and (b) has a gray background. If you don’t want the gray background, then don’t make any group rows. Group rows are *supposed* to look different from regular rows, and they have other unique behavior, too. (It is *possible* to customize the appearance of group rows, though I’ve never done it. But it is to your users’ advantage if the rows look the same as in other apps.) > I noticed that I never hit anything that is not “GroupCell”. However this > does not solve the grey background right? Presumably, the top level folder that you’re displaying only has subfolders, and no files. Note that if your intention is to display a folder *hierarchy*, you’re going to have some trouble using a NSTableView, which is intended for a flat array. NSOutlineView is better suited to a hierarchy. ___ 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: Question on NSScrollView
On May 1, 2014, at 17:25 , Varun Chandramohan
wrote:
> Yes I have implemented tableView:isGroupRow.
> - (BOOL)tableView:(NSTableView *)tableView isGroupRow:(NSInteger)row {
> DesktopEntity *entity = _tableContents[row];
> if ([entity isKindOfClass:[DesktopFolderEntity class]]) {
> return YES;
> }
> return NO;
> }
>
> What is wrong with this?
Nothing at all! Rows corresponding to a ‘DesktopFolderEntity’ are group rows,
and all the others are not.
> Also I implemented
> - (NSView *)tableView:(NSTableView *)tableView
> viewForTableColumn:(NSTableColumn *)tableColumn row:(NSInteger)row {
> DesktopEntity *entity = _tableContents[row];
> if ([entity isKindOfClass:[DesktopFolderEntity class]]) {
> NSTableCellView *groupCell = [tableView
> makeViewWithIdentifier:@"GroupCell" owner:self];
> [groupCell.textField setStringValue:entity.name];
> return groupCell;
> }
> return nil;
> }
>
> Are you saying I should not return nil here?
Well, you are returning nil for rows that aren’t ‘DesktopFolderEntity’, which
doesn’t seem a good idea, but that isn’t the issue you asked about.
In this code, you should return a view with identifier “GroupCell” — as you
have done — for rows that are ‘DesktopFolderEntity’. Since these are indeed
group rows, this correctly gives them the group-row appearance (the one with
the gray background).
That is, your table view is showing exactly what you asked it to show.
Your ‘tableView:viewForTableColumn:’ method is, however, missing some code. You
need to return a view for non-group rows (that would probably be a view with
identifier ‘DataCell’, if you have the default setup in IB), and you need to
test tableColumn (and possibly tableColumn.identifier). (‘tableColumn == nil’
means that you’re being asked for a group-row view. Otherwise you’re being
asked for a per-column view.)
___
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: Question on NSScrollView
On May 1, 2014, at 15:16 , Varun Chandramohan wrote: > However this is not the case with the same table > populated manually using NSPasteboardReading and NSTableViewDataSource, > NSTableViewDelegate. I noticed a grey background to all the entries to the > table. It looks like you have inadvertently turned all the rows into group rows. There are a couple of ways this might happen, that I can think of offhand. One is (obviously) if you implemented the ‘tableView:isGroupRow:’ delegate method and returned YES. Otherwise, make sure in methods like ‘tableView:objectValue…’ and ‘tableView:willDisplayCell…’ or ‘tableView:viewForTableColumn…’ that you don’t return a non-nil value when the column is nil. (A nil column is how the table view asks the delegate/data source for per-row values that span columns.) ___ 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: JSONSerialization 'Garbage at end' error
On Apr 30, 2014, at 16:00 , Jonathan Hull wrote: > I also find that it is good practice to set variables returned by reference > to nil before passing them. > > NSError *error = nil; > > Otherwise, they will contain garbage, and cannot reliably be tested to see if > the value was set. This point comes up every few months, and what you say isn’t technically correct. It doesn’t do anything useful to set a NSError* value returned via reference to nil before the method invocation. According to the particular pattern in use here, if the method succeeds, there’s no valid value returned for the NSError*. In this case, the value may have changed from the value before the call. The changed value is garbage, from the caller’s point of view. It is *not safe* to test ‘error’ on a successful return, regardless of how you initialize it. ___ 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: Creating selector for nonexistent method
On Apr 29, 2014, at 06:18 , Arved von Brasch wrote: > sendAction:to:from: seems to be the preferred way to invoke the responder > chain to implement the clear: method in the Window controller. This puzzles me. What are you actually trying to do? If you’re trying to invoke *the* clear: method in the window controller, then ‘sendAction:to:from:’ seems like a bad choice. You don’t know if the window controller is even in the responder chain leading upwards from the current first responder, and you don’t know if other responders in the chain also implement ‘clear:’. In other words, you’re essentially sending ‘clear:’ to a random receiver. To send a message to the window controller specifically, you’d do better to get a reference to it, and send the message normally. If the window isn’t related to a NSDocument, it’s reasonable to let your app delegate have a reference to the window controller publicly available. If it’s a document window, you can look in the document’s ‘windowControllers’ array. Even something like ‘[[NSApplication main/keyWindow] windowController]’ (with a check on the window controller class) would be preferable. If you’re trying to invoke *a* clear: method in any of several places in the responder chain, then ignore everything I just said. ___ 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: dispatch_semaphore crash on deletion
On Apr 28, 2014, at 13:02 , Ken Thomases wrote: > I've seen this discussed before, but I don't remember where. One of the > Apple engineers acknowledged the issue. This check is not done (or not > effective) if the semaphore is created with a value of 0. It was here, a few months ago. I was complaining about this — there are situations involving Cocoa frameworks where you don’t get the opportunity to restore the value back to its original setting. Greg Parker stated that it’s a feature, not a bug. > So, the workaround is to create it with a value of 0 and then call > dispatch_semaphore_signal() to increase the value up to the size of your > resource pool. Indeed. It’s a minor irritation to have to remember to do so. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: SpriteKit junk
On Apr 27, 2014, at 09:29 , William Squires wrote: > Thanks - reducing the scene to just the score label reveals that - without > the background - the (solid) background color is now a dark gray, rather than > black, and I can just make out the (simulated) title bar at the top where - > on a real device - it would show the carrier, signal strength, time, and > battery charge. It was this text at the left (the carrier and signal > strength) that was acting as a mask over the top of the SKLabelNode > rendering. Now the question is - how do I get rid of it (meaning the bar on > the top of the screen)? I remember seeing this somewhere - probably a plist > setting - but I don't recall off-hand. Override -[UIViewController prefersStatusBarHidden]. Or override -[UIViewController preferredStatusBarStyle] to return UIStatusBarStyleLightContent, and move your labels down a bit. ___ 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: SpriteKit junk
On Apr 26, 2014, at 17:13 , William Squires wrote: > I'd show you what this looks like, but I don't think users are supposed to > post pics to this group. You can post screen shots in the Developer Forums, and you’ll find more people with SpriteKit experience there. > Any ideas on how to iron this out? You’re kinda overloading us with information. You apparently haven’t tried progressively cutting this code down to see if you can tie the display issue to a particular node or a particular property. What happens, for example, if you create a scoreLabel node and nothing else? Regarding the different outcome with scoreLabel and shieldLabel, I notice that you set scoreLabel’s zPosition to 100, but leave shieldLabel’s zPosition at 0. Perhaps that has something to do with why they appear differently. ___ 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: GCD killed my performance
On Apr 26, 2014, at 12:02 , Kyle Sluder wrote: > FWIW, I’ve been of the opinion for a while that including dispatch_sync in > the API was a mistake. Too often it becomes a crutch used without > understanding, resulting in stop-start behavior across threads or cores. I don’t know if you’ll agree, but it seems to me that there’s a distinction between a *locking* mechanism such as @synchronized, and a *queuing* mechanism, which Jens seems to have demonstrated dispatch_sync to be. I understand that both mechanisms may at a lower level depend on both queues and locks, but the distinction I’m making is that a locking mechanism is used when we hope that the lock will generally be granted without contention, while a queuing mechanism is used when we expect there will generally be some contending operation in progress. ___ 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: GCD killed my performance
On Apr 24, 2014, at 22:49 , Jens Alfke wrote: > It is, but most of it appears to be memory management _caused_ by GCD, since > it goes away when I replace the dispatch calls with @synchronized. GCD is > apparently causing a lot of blocks to get copied to the heap. Well, you know what you’re seeing in Instruments, but this characterization seems improbable. Ignoring the GCD-specific entries, if block copy was causing a large number of retains and releases (if that’s what you meant by “refcount bookkeeping”), I’d expect there to be a large number of block copies, too. If block copies (as I’d also expect) are much more time-consuming than the retains/releases, by comparison you’d barely notice the retain/release times in Instruments. If the retains/releases caused by block copies do dominate, that suggests the block copies are comparatively very cheap, which in turn suggests a horrible bug in block copies. With luck someone might jump in with a plausible answer, but this is starting to sound 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: GCD killed my performance
On Apr 24, 2014, at 20:14 , Jens Alfke wrote: > On my MacBook Pro this gave me a nice speedup of 50% or more. > > But when I tested the code on my iPhone 5 today, I found performance had > dropped by about a third. > I know that dispatch queues aren’t free, but I wasn’t expecting them to be > this expensive! I’m not doing anything silly like wrapping dispatch_sync > around trivial calls. The APIs I’m using it on do things like reading and > writing values from the persistent store. Approaching this naively, this result suggests that the block content, while not trivial, is too fine-grained — is divided too finely. For example, if you’re putting (essentially) one database read/write operation (or even a handful) in each block, perhaps that’s too small a unit of work for GCD. That idea is given *some* plausibility by the different outcomes on Mac and iPhone — a physical disk access is presumably much slower on average than an access to iOS persistent memory. (Of course, if your MacBook Pro is purely SSD, that might blow that idea out of the water. I don’t know how SSD access speeds compare to iOS memory.) > Profiling shows that most of the time is being spent in thread/queue > management or Objective-C refcount bookkeeping. Unless I missed something, all of the responses in this thread went to the GCD issue. But if memory management is showing up “hot” like that too, there may be something else to investigate. One option might be to look at what Instruments reports for the hotspots in terms of *counts* rather than times, and compare OS X with iOS. This would necessitate arranging things so you could get counts for known increments of work. If iOS gives comparable counts but much longer times, you will have one way of proceeding; if it gives much larger counts but similar or smaller times per count, you will have another way of proceeding. ___ 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: Good idea/bad idea?
On Apr 24, 2014, at 14:21 , Andy Lee wrote: > I still don't see how > > foo = [@"Something" fallbackIfNil:foo]; > > has any advantage over > > foo = foo ?: @"Something"; I don’t see how the latter has any advantage over your earlier suggestion [more or less]: if (!foo) foo = @“Something”; Admittedly, it takes two lines instead of one. OTOH, as I said in another recent thread, it seems to me that for a *reader* of the code, the latter form is far more accessible than code with the “?…:” operator, which tends to force the reader to figure out if the code is correct or not. I note that in this thread, like the other one, most of the discussion has basically been about figuring out what’s actually correct. Is there *any* confusion over the “if” version? ___ 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: NSOperation - Update UI with delegate or in a Controller with oberseValueForKeyPath:
On Apr 24, 2014, at 06:47 , Gilles Celli wrote: > 1. With KVO in a Controller object: Observing the NSOperation's "isFinished" > value and then in observeValueForKeyPath:ofObject:change:context: >update the UI (graph display) on the main thread with > performSelectorOnMainThread:withObject:waitUntilDone > > 2. No KVO: in NSOperation the UI is updated after the parsing is done, by > calling the delegate again with >performSelectorOnMainThread:withObject:waitUntilDone > > I've tested both approaches but can't decide which one is the most correct / > best, or what are the benefits of using one approach or another ? There’s no absolute answer to this, but I’d choose #1, for a couple of reasons: — It means the parsing code doesn’t have to know how it’s being “watched” or by whom or for what purpose. Other “watchers” can be added later, if necessary, without having to intervene in the parsing or delegate code. — It avoids turning the delegate into a dumping ground for miscellaneous functionality. Note that it’s not absolutely necessary to use a delegate for #2. You can do: [self performSelectorOnMainThread:@selector(operationAsciiParsingDone:) withObject:[self parsedAscii] waitUntilDone:NO]; So long as ‘operationAsciiParsingDone:’ doesn’t try to access any of the object’s internal data structures (which a delegate wouldn’t have been able to do anyway), this is thread-safe, odd as it might seem at first. (More accurately, it’s exactly as thread safe as using a delegate.) ___ 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: Mouse cursors and overlapping sibling NSViews
On Apr 24, 2014, at 08:20 , Sean McBride wrote: > Tracking areas are nice, but limited to rects, and I have circular areas to > deal with too. Not really. According to the event handling guide, if a responder's cursorUpdate: declines the event (by invoking super), the event passes up the responder chain. In effect, you are not forced to provide a cursor for your entire tracking area, which sounds like what you want. ___ 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: Mouse cursors and overlapping sibling NSViews
On Apr 23, 2014, at 16:58 , Ken Thomases wrote: > If the cursor is appropriate for a given view, that's a *strong* indication > to the user that a click will act on that view. So, the view controlling the > cursor at a given point should also be the view that receives the click at > that point. Wait, did I miss something? Wasn’t Edward correct in pointing out that using mouseMoved: to set the cursor is not correct, and cursorUpdate: should be used instead (with tracking areas with NSTrackingCursorUpdate) should be used. That mechanism already chooses the correct view to get set the cursor. ___ 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: Memory Leaks and ARC
On Apr 23, 2014, at 03:01 , Dave wrote:
> If I changed the names of commandDownloadImageWithFileURLString to be
> newCommandDownloadImageWithFileURLString, this would cause it to release
> myImage on each iteration rather than using Autorelease?
It would remove one — and perhaps the only — reason for ARC to use autorelease,
but there’s no way of knowing whether there are others, hidden from you. For
example, even if you create a new image using some alloc/init that returns the
created object with +1 ownership, it may have already been autoreleased before
it gets back to you.
The outcome is also going to vary with the version of clang you compiled with,
and the OS version you’re running on. The current clang already uses
autorelease less often than the original implementation, and Cocoa classes may
get converted from MRR to ARC gradually over OS releases.
It seems to me that the best practice is:
— Return objects with +1 ownership when semantically appropriate (when the
caller gets an object that is conceptually new).
— Investigate memory usage with Instruments, preferably on supported older OS
versions too.
— Bracket problem areas with @autoreleasepool{} only you’ve identified a
problem area with Instruments.
— Don't gratuitously insert @autoreleasepool{} in loops “just for safety”.
> Is there anyway of telling if an Object is in “autorelease” state? I mean
> just for testing, I wouldn’t rely on this in shipping code.
I don’t think so.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Memory Leaks and ARC
On Apr 22, 2014, at 15:18 , Dave wrote: > I assumed that ARC would release myImage on each interation of the loop, > however, this seems not to be the case The ‘myImage’ variable gives up *ownership* of the previous image object when you create a new one in the loop, but whether that leads to a deallocation of the object is an implementation detail. If it’s autoreleased anywhere in its [short] lifetime, the image object will linger in the autorelease pool until the pool is drained, as Keary said. If you want to avoid autoreleases, you should ensure that the image is returned from the download method with +1 ownership semantics. As far as that method is concerned, you can do this by changing its name to start with ‘new…’, or decorate its declaration with ‘__attribute__((ns_returns_retained))’. You would, of course, have to ensure that the download method and the methods it calls don’t do anything else that’s likely to retain/autorelease the image. This sort of thing is a bit messy because it relies on presumed (but partially documented) knowledge of the ARC implementation. It’s more robust and straightforward to do what Keary says. However, if you really wanted to avoid autoreleases completely, there are ARC strategies that can help. ___ 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: Strange toolbar/view/resize cursor interaction
On Apr 22, 2014, at 15:36 , Eric Shepherd wrote: > When the cursor is at the top edge of my window, the Y value is off by 10 > pixels. > > When the cursor is at the bottom edge of my window, the Y value is off by 40 > pixels. As I suggested previously, this could indicate that your view bounds have been inadvertently scaled. The next thing you must do is log more environmental information. I suggest: — the view’s visibleRect — the view’s bounds — the view’s frame — the window content view’s bounds — the window content view’s frame — the window’s frame — when the cursor is at the top edge of your view, event.locationInWindow in window coordinates — when the cursor is at the top edge of your view, your ‘where’ variable (that is, event.locationInWindow converted to bounds coordinates) — when the cursor is at the bottom edge of your view, event.locationInWindow in window coordinates — when the cursor is at the bottom edge of your view, ‘where’ (bounds coordinates) ___ 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: Strange toolbar/view/resize cursor interaction
On Apr 21, 2014, at 18:28 , Kyle Sluder wrote: > Why not? Let’s assume for the sake of an example, the toolbar is 40 points high, and the OpenGL view (its visible rect, at least) is 200 points high. According to Eric, when the cursor is 40 points *above* the bottom of the view, where.y is 200, in view bounds coordinates. That seems to me to mean one of 3 possible things: — When the cursor is at the top of the visible rect, where.y is 40, so that the vertical extent of the visible rect is 40..240 in bounds coordinates. If the visible rect is the entire view, that means the bounds origin is (0, 40). [Or perhaps (0, -40), my brain’s too tired to work it out.] — Or, if the entire view is bigger than the visible rect, the bounds origin can be (0, 0), and the vertical extent must be 0..240, with the top 40 points clipped. — Or, if where.y is 0 with the cursor at the top of the visible rect, and where.y is 200 at a position 40 points above the bottom of the visible rect, then the view vertical extent is 0..240 (bounds coordinates) in a frame rect of height 200, and therefore the bounds has been scaled. Otherwise, how can where.y be 200 at a point 40 (bounds coordinates) points above the bottom of a view that’s 200 (frame coordinates) points high? On Apr 21, 2014, at 18:44 , Ken Thomases wrote: > Just in general, in the majority of cases the bounds origin is (0, 0) and its > size is equal to the frame size (although for OpenGL views, it's the frame > size in pixels rather than points). Outside of scrolling, it's relatively > rare to transform a view's bounds. I think Quincey has gotten himself turned > around on this. Unless I’m doubly confused, therefore, I don’t think I’m turned around. If the bounds origin isn’t (0, 0) or the height in bounds coordinates is greater than the height in frame coordinates, it’s certainly unexpected, and I’m suggesting that the real problem is whatever brought that unexpected situation about. ___ 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: Strange toolbar/view/resize cursor interaction
On Apr 21, 2014, at 17:15 , Eric Shepherd wrote: > I've checked -- [self bounds].origin.y is 0. That can’t be! What is ‘where.y’ at the very top of your view? Can you log self.bounds so we can see all of it? Well, it can be. A couple of other possibilities: — Your view is larger than you think, and of it is clipped away by its parent. — Your view’s bounds are vertically scaled by / . Either of those things could be caused by incorrect resizing struts, in a normal view at least. But surely where and bounds must contain the explanation between them? ___ 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: Strange toolbar/view/resize cursor interaction
On Apr 21, 2014, at 16:46 , Eric Shepherd wrote: > where = [self convertPoint:where fromView:nil]; // Convert to the view's > frame of reference > > NSLog(@"Mouse Y: %3.0f", where.y); And ‘self’ is the NSOpenGLView, yes? It sounds like your view’s bounds origin has been moved by the height of the toolbar. Perhaps what you *should* be logging (and using) is ‘where.y - self.bounds.origin.y’ — or something similar if the coordinates aren’t flipped. ___ 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: Strange toolbar/view/resize cursor interaction
On Apr 21, 2014, at 15:23 , Eric Shepherd wrote: > I added code to dump the Y-coordinate of my mouse while I move it around in > the NSOpenGLView, and sure enough, it's reaching the value that should be the > bottom edge well above the bottom. Are you sure you’re using the correct coordinate conversions? Based on what Graham said, there are actually 3 coordinate systems involved — the content view coordinates, the content (i.e. non-frame) coordinates, and the frame coordinates. Officially AFAIK there are only 2 coordinates systems (frame and content). If you’re accidentally mixing coordinate systems, perhaps you don’t need to adjust the calculations, but just use a different conversion? ___ 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: SpriteKit
On Apr 21, 2014, at 08:13 , William Squires wrote: > Question: given an SKLabelNode (reference), is there some way to render it, > and turn the rendered image into an SKSpriteNode? I know about [SKSprite > spriteWithImageNamed:], but that takes a filename of an image in the bundle, > not an actual UIImage, and - since one cannot save into the bundle (at > runtime) - that nixes that idea... (a) -[SKView textureFromNode:] (b) Render the desired content into an actual UIImage, then +[SKTexture textureWithImage:] Once you have the texture, you can create a SKSpriteNode. ___ 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: Strange toolbar/view/resize cursor interaction
On Apr 20, 2014, at 23:53 , Graham Cox wrote: > The toolbar view is actually added as a PEER of the window's content view, > and the content view is resized to accommodate the toolbar when it is shown > or hidden. That sounds correct, but IIRC the methods that convert between a window’s content size and its frame size don’t take the toolbar into account, which means that they work with a "content size” that isn’t actually the content *view* size, and correcting the calculation requires the assumption of extrinsic information. It strikes me as plausible that an OpenGL view might need to make such a conversion, and that it was never implemented to deal with the presence of a toolbar. ___ 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: canAsynchronouslyWriteToURL:ofType:forSaveOperation: Prevent Quit?
On Apr 20, 2014, at 22:26 , Kyle Sluder wrote: >> In a Save the dirty mark is not cleared until the file is written, thus it >> asks before quitting about saving the document. > Come to think of it, does your app adopt Lion Autosave? The implication of “dirty mark” — if taken literally — is that this is pre-Lion NSDocument behavior. The newer behavior has “Edited” text in the title bar, of course, and no mark in the close button. Perhaps that’s why it’s not behaving as expected on quitting — the deferral of termination may happen only with “modern” NSDocument behavior. Unfortunately, trying to predict the effects of implementing various combinations of the various overrides, return values and miscellaneous dreck that’s accumulated in NSDocument API since 10.5 is probably beyond the ability of mere mortals. ___ 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: canAsynchronouslyWriteToURL:ofType:forSaveOperation: Prevent Quit?
On Apr 20, 2014, at 13:34 , Kyle Sluder wrote: > Do you override any other NSDocument saving methods? Also, there *may* be a relevant interaction between ‘terminate:’, sudden termination and automatic termination, even though technically they’re separate things. Opting in to the latter two, if you haven’t done so already, might improve the saving situation. ___ 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: ARC Retain Cycles
On Apr 20, 2014, at 13:22 , Dave wrote: > This App was an iOS application and previously it handled manual memory > management - mostly using autorelease. I converted it by hand (didn’t use the > ARC coversion process). Ah, then ignore everything I said. :) > if ([prop1 class] == [NSDictionary class]) > self.propDict = self.pProp1; You realize that this code is utterly wrong, yes? NSDictionary is a class cluster, and so there *are no* objects of class NSDictionary, only of subclasses, most of them private to the frameworks. And even if UIImage isn’t a class cluster, particular image objects may still be a subclass. For this situation, ‘isKindOfClass:’ seem much more likely. ___ 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: Strange toolbar/view/resize cursor interaction
On Apr 20, 2014, at 12:54 , Eric Shepherd wrote: > Nope. :( The only *technical* suggestion I can add — beyond Ken’s excellent suggestions — is to move the OpenGL view down a level. That is, assuming it’s a subview of the window’s content view, make it a subview of a custom view that is a subview of the content view (with appropriate resizing behavior at both levels). More generally, though, you might reconsider using a NSToolbar at all. I guess the geometry of NSToolbar has always been "neither fish nor fowl" (that is, sort of part of the window frame, yet sort of part of the window content), and its presence may be disturbing some assumption a NSOpenGLView makes about its own relationship with the window. There may be an inherent conflict there, at least in recent versions of OS X. Also, it’s noteworthy that the NSToolbar API — which has always been horrible to use — hasn’t received much (if any, IIRC) attention in the last several OS X releases, and it somewhat has the appearance of a distasteful object drifting permanently down to the bottom of the punchbowl. If you can devise a NSToolbar-free UI for your application, you might be doing yourself a favor in the future. ___ 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: ARC Retain Cycles
On Apr 20, 2014, at 11:58 , Cody Garvin wrote: > Second, while using instruments use the “mark heap” tool. > Third, keep in mind that blocks keep strong references to self (especially > callbacks). While these are important debugging steps, I’d suggest that this isn’t the place to start *in this case*. Assuming that this app is being converted from GC (Dave didn’t say so explicitly, but presumably conversion from manual RR likely wouldn’t introduce these kinds of memory issues), it’s probably better to spend more time looking at the source code *before* getting bogged down in debugging. There are two kinds of difficult problems that a GC-ARC conversion must contend with: 1. There are patterns of object usage that work fine in GC, but aren’t translatable directly into ARC. Specifically, when clusters of objects “go away automatically when they are no longer used” under GC, there may be no equivalent technique in ARC. (Of course, reference cycles are the underlying problematic mechanism, but I’m looking at a higher level.) In particular, under ARC it may be necessary to design the app so that it knows explicitly *when* such clusters are no longer used, and so can send explicit messages to cause the cluster to be deallocated. 2. Arbitrary object graphs that work fine in GC may be a tangle of cross-references in ARC. It may be best to redesign the data model so that the objects are strictly (or pretty strictly) hierarchical. That is, to change the data model from sibling relationships to parent-child relationships**. In other words, to change all the relationships to be “up” or “down”, and ensure that all the “up” relationships are weak***. Both of the above are most effectively done by examining and rearranging the source code directly, rather than trying to detect reference cycles in Instruments or the debugger, which limit you to a lower design level. A thorough source code review should remove *most* of the cycles, and then Instruments should help find the ones that are obscure at the source level. ** Of course, if the old data model is enshrined in (say) an archive saved in a document, then the app will still need to be able to recognize the old model. *** One resulting gotcha is that weak relationships are *not* KVO compliant, and that 10.9 will detect and complain about this, even in cases where 10.8 and earlier were silent. The original code was probably wrong in some way, too, but we often didn’t notice the problem because we tended to just grab a big hammer and smash things when closing windows etc. In 10.9, big hammers aren’t quite as smashy. ___ 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: cocoapods: Problem with loading nib for a NSWindowController
On Apr 18, 2014, at 14:14 , Gerd Knops wrote: > Dangerous (and entirely wrong) assumption. I know perfectly well that Mac HFS+ can be made case sensitive, so perhaps I should have worded it better: “…even *when* the Mac file system is case insensitive.” However, both you and Fritz missed my real point, which is that it *may* be (I have a *vague* recollection of this coming up before) that nib loading might fail if the the string passed to ‘initWithNibName:’ doesn’t match the case of the actual file name, regardless of the case sensitivity of the file system. Perhaps I misremember, but IAC the point is to check for any case-sensitivity issues which might amount to a misspelled string. ___ 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
