Re: All threads in app periodically blocked
Holy cow!!
I figured out why process was halting every 150 ms.
I happened to find the critical clue by chance today. I was trying Ken's
suggestion of explicitly using NSActivity to avoid any potential app napping
(which wasn't what was happening), and for only then did the application
suddenly stop half way through the data processing and claim it couldn't
allocate anything Weird. 樂
Because this CVPixelBufferPool wouldn't allocate anymore pixel buffers, I
figured there must be a leak somewhere, so I profiled with Instruments for the
20th time, but yet the Allocations were pretty constant and low, and there were
no leaks... Weird.
So then out of habit, I printed out the CVPixelBufferPool in the debugger and
*luckily* (since there's no public API for this), the pool's description showed
"inUse=3768". There should be like 20 max. And if there are 3768 PBs, then
surely I should see that in Instruments! … Weird.
It quickly occurred to me that the CVPixelBuffers are actually
IOSurface-backed, not normal malloced-memory backed, so then I Snapshotted the
VM address space a bazillion times and sure enough that was every increasing up
to like 20 GB , and all of that growth was in IOKit. So yep, it's these
IOSurfaces which are allocated by the system, not by my app, which is why they
didn't show up in the normal Allocations track, and because they're in a pool,
there actually is no leak. But how does changing my operation from sync to
"async" (yet, using the exact same "work" code) make these IOSurfaces stack up?
... Weird. 樂
My thought at this point was maybe it was some autorelease pool nonsense. These
pixel buffers do get inserted into autorelease pools at various points, so I
figured maybe there was a pool draining difference because I've been bitten by
that before with GCD in past OS versions. So I plastered @autorelease{...} all
over the place to see if it had any effect. It didn't.
So then I figured, the ONLY other logical explanation is that this NSOperation
*itself* isn't being deallocated, since it keeps a reference (chain) to this
CVPixelBuffer, so if the NSOp doesn't deallocate, then the PB doesn't get
returned to the pool. So I stuck I breakpoint in -dealloc and sure enough, the
operation doesn't deallocated until *waay* later. Multiple seconds after it
and several thousand other operations are done too. *Weird*
Interestingly, the stack frame that triggered the deallocation of this
NSOperation was KVO related. That seemed a bit odd to me, but got me thinking
that the only real difference between a synchronous NSOp and async NSOp is the
KVO notifications that need to be fired, so I opened up the code again to look
at that and BOOM. I saw a bug. The very first thing I did was:
- (void)start
{
[self willChangeValueForKey:@"isExecuting"];
...
[self willChangeValueForKey:@"isExecuting"];
I had mistakenly (thanks to copy & paste ) called willChange twice and not
called didChange. As soon as I fixed that, everything was working fine. The
operation was properly deallocated, the PBs were properly returned to the pool,
and the IOSurfaces properly released.
I'm not sure of the details, but as far as I can tell, the system periodically
halted my entire process while it scrambled to keep up with my insane demands
of constantly allocating gigabytes of IOSurfaces.
I'm telling you guys I used every skill I could think of, staring at zillions
of system calls in traces etc, and in the end all I needed was a little luck
and it was all due to a simple copy & paste error.
Sigh.
Thanks,
--
Seth Willits
> On May 22, 2016, at 10:48 AM, Seth Willits <sli...@araelium.com> wrote:
>
> I'm thoroughly confused and increasingly desperate. *All* of the threads in
> my application periodically are blocked for 30-50 ms pretty regularly, about
> every 150 ms.
>
> I'm processing a bunch of data via NSOperations running in a couple of
> "serial" (maxConcurrentOperationCount = 1) NSOperationQueues. Each of the
> operations is itself synchronous (overriding -main). Everything works as
> expected. For performance reasons, I want to move one of the operation types
> to being asynchronous and eventually allow two concurrent operations.
>
> So to start with, I took the synchronous code in -main, moved it into -start,
> and added the appropriate KVO notifications for isExecuting, isFinished, and
> implemented the right accessors etc. So effectively the operation says it's
> asynchronous, but all of its work is actually done in -start, followed by
> notifying it's finished. The work is all done correctly, but I noticed it
> took significantly longer to complete.
>
> Thankfully I have a nifty bit of debugging code which tracks the start and
> ends of each of these operations and vi
Re: All threads in app periodically blocked
> On May 22, 2016, at 12:44 PM, Quincey Morris > <quinceymor...@rivergatesoftware.com> wrote: > > On May 22, 2016, at 10:48 , Seth Willits <sli...@araelium.com> wrote: >> >> Can anyone think of what I should look for to figure out *why* they're >> blocked? > > Do these operations go on long enough that you can see the usage stabilize in > Activity Monitor? If so, what are the user and system percentages of CPU > while it’s running? The whole process goes on for a long time. CPU usage is like 5-10% system, 10-15% user. These delays are periodic throughout the entire process. > On a different front, is it necessary that you use NSOperations? Can you > switch to plain GCD instead? I just switched from GCD. The operations do make it simpler to manage in this case as I'm leverage dependencies across various queues and avoiding the need for multiple semaphores as before. -- Seth Willits ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: All threads in app periodically blocked
OS X. It happens in all circumstances. -- Seth Willits > On May 22, 2016, at 10:59 AM, Alex Zavatone <z...@mac.com> wrote: > > Mac, iOS? If iOS, device or sim? IPad? > > Try publishing and not running through Xcode. > > Sent from my iPhone > >> On May 22, 2016, at 12:48 PM, Seth Willits <sli...@araelium.com> wrote: >> >> I'm thoroughly confused and increasingly desperate. *All* of the threads in >> my application periodically are blocked for 30-50 ms pretty regularly, about >> every 150 ms. >> >> I'm processing a bunch of data via NSOperations running in a couple of >> "serial" (maxConcurrentOperationCount = 1) NSOperationQueues. Each of the >> operations is itself synchronous (overriding -main). Everything works as >> expected. For performance reasons, I want to move one of the operation types >> to being asynchronous and eventually allow two concurrent operations. >> >> So to start with, I took the synchronous code in -main, moved it into >> -start, and added the appropriate KVO notifications for isExecuting, >> isFinished, and implemented the right accessors etc. So effectively the >> operation says it's asynchronous, but all of its work is actually done in >> -start, followed by notifying it's finished. The work is all done correctly, >> but I noticed it took significantly longer to complete. >> >> Thankfully I have a nifty bit of debugging code which tracks the start and >> ends of each of these operations and visualizes them, and this is what I >> noticed: >> http://www.sethwillits.com/temp/upshot/upshot_yJutoKqY.png >> >> At very regular intervals everything takes longer. >> >> First I thought it maybe didn't like my semi-async op, so I made it truly >> async, and it behaved exactly the same. To make a long story short, I looked >> at this a few different ways in Instruments, and have confirmed that what's >> actually happening is *every thread is blocked* for those 30-50ms, and then >> it just wakes up and everything continues. The threads are literally all in >> "Blocked" states. >> >> >> I can't figure out *why* everything is blocked. I can't figure out why >> simply making the NSOperation asynchronous would have this crazy effect. >> It's 100% reproducible. >> >> For what it's worth, this one particular operation is doing some Metal >> rendering, and that operation is blocked during a call to >> -waitUntilCompleted. Which yes, sound suspicious, but is exactly what's >> happening in the very-explicitly-synchronous version of the operation, and >> it takes 10x less time. I am pretty certain this has nothing to do with the >> Metal rendering itself, and has more to do with something confusing the >> dispatch manager and every thread is being blocked. >> >> >> Can anyone think of what I should look for to figure out *why* they're >> blocked? Looking at the system calls in the Instruments trace timeline just >> isn't telling *me* anything. >> >> >> -- >> Seth Willits >> ___ 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
All threads in app periodically blocked
I'm thoroughly confused and increasingly desperate. *All* of the threads in my application periodically are blocked for 30-50 ms pretty regularly, about every 150 ms. I'm processing a bunch of data via NSOperations running in a couple of "serial" (maxConcurrentOperationCount = 1) NSOperationQueues. Each of the operations is itself synchronous (overriding -main). Everything works as expected. For performance reasons, I want to move one of the operation types to being asynchronous and eventually allow two concurrent operations. So to start with, I took the synchronous code in -main, moved it into -start, and added the appropriate KVO notifications for isExecuting, isFinished, and implemented the right accessors etc. So effectively the operation says it's asynchronous, but all of its work is actually done in -start, followed by notifying it's finished. The work is all done correctly, but I noticed it took significantly longer to complete. Thankfully I have a nifty bit of debugging code which tracks the start and ends of each of these operations and visualizes them, and this is what I noticed: http://www.sethwillits.com/temp/upshot/upshot_yJutoKqY.png At very regular intervals everything takes longer. First I thought it maybe didn't like my semi-async op, so I made it truly async, and it behaved exactly the same. To make a long story short, I looked at this a few different ways in Instruments, and have confirmed that what's actually happening is *every thread is blocked* for those 30-50ms, and then it just wakes up and everything continues. The threads are literally all in "Blocked" states. I can't figure out *why* everything is blocked. I can't figure out why simply making the NSOperation asynchronous would have this crazy effect. It's 100% reproducible. For what it's worth, this one particular operation is doing some Metal rendering, and that operation is blocked during a call to -waitUntilCompleted. Which yes, sound suspicious, but is exactly what's happening in the very-explicitly-synchronous version of the operation, and it takes 10x less time. I am pretty certain this has nothing to do with the Metal rendering itself, and has more to do with something confusing the dispatch manager and every thread is being blocked. Can anyone think of what I should look for to figure out *why* they're blocked? Looking at the system calls in the Instruments trace timeline just isn't telling *me* anything. -- Seth Willits ___ 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: Multiple AVAudioPlayer - locking main thread?
> On Mar 18, 2016, at 1:10 PM, Eric E. Dolecki <edole...@gmail.com> wrote: > > I have audio buttons, each with it's own associated AVAudioPlayer > > Any ideas about the main thread lockup? Rather than just looking at memory usage, look at what's actually taking up the time on the main thread. Use a time profile in Instruments. That's where you're going to find the best indication of what's going on. -- Seth Willits ___ 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: Staggering new windows
> On Mar 3, 2016, at 2:46 PM, Daryle Walker <dary...@mac.com> wrote: > > This new Xcode project (with storyboards) makes new windows at the same > coordinates, on top of each other. Just the ever increasing shadow gives that > behavior away. Is there a way to (automatically) get that old Mac behavior of > staggered windows? I think it was 20 pixels down and right. Window Cascading: https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/WinPanel/Tasks/SizingPlacingWindows.html -- Seth Willits ___ 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: Weird Message from NSZombies
> On Jan 12, 2016, at 7:02 AM, Dave <d...@looktowindward.com> wrote: > > When I start up my App with Zombies enabled, I get the following message sent > to the log (NSLog): > > objc[2579]: Class _NSZombie_OS_xpc_array is implemented in both ?? and ??. > One of the two will be used. Which one is undefined. > > Not sure what this means? Anyone have any idea? Ignore it. It has nothing to do with you doing anything wrong. -- Seth Willits ___ 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: Nullability Question
On Jan 11, 2016, at 8:04 AM, Dave <d...@looktowindward.com> wrote: > I’ve noticed there are two forms to specify nullability on properties, is one > preferred syntax over the other? Judging by Apple's usage, using the property attributes (nullable and nonnull) are preferred. -- Seth Willits ___ 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: Presenting NSWindowController/NSWindow Pair as a Sheet?
> I have an NSWindowController/NSWindow Pair and I was wondering if I can > easily present this as a Sheet? > > At the moment it works Ok as a regular window but have need of it as a sheet > too in some cases and wondered about the best way of doing it? NSWindow has beginSheet:completionHandler: There's also NSViewController's presentViewControllerAsSheet: -- Seth Willits ___ 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 OS X's system-wide "look up" feature is implemented?
> On Oct 16, 2015, at 9:11 AM, Nick <eveningn...@gmail.com> wrote: > > When we right-click on any selected text (or tap with three fingers), a > popover view shows up, displaying info about the text selected (a > dictionary definition, a wikipedia article). > This function has been available on OS X since Lion. > > Is it possible to add my own "widget/button/tab" to this popover somehow? > Even using an undocumented way? There should be... OS X does it somehow. Dictionary Services https://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/DictionaryServicesProgGuide/Introduction/Introduction.html#//apple_ref/doc/uid/TP40006152-CH1-SW1 -- Seth Willits ___ 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 requiring NSDisableScreenUpdates
> On Aug 30, 2015, at 4:09 PM, Ken Thomases <k...@codeweavers.com> wrote: > > Turn off Visible at Launch on the window in the NIB. D'oh! You're right. I mistakenly left on that and that's what was causing it. Thanks! -- Seth Willits ___ 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
Autolayout requiring NSDisableScreenUpdates
My window's UI mainly consists of a stack view, but in the window's xib,
there's nothing in the stack view to begin with. This means that after the xib
loads, the window is tiny (like 70 x40).
In windowDidLoad I'm adding views to the stackview which actually make it the
real size it should be, once autolayout happens. The problem is that the
window is already shown and visible on screen before the new layout even takes
effect, which is requiring me to wrap xib loading in
NSDisableScreenUpdates/NSEnableScreenUpdates.
Is there something else I could/should be doing? (Besides obviously having the
window loaded from the xib be the correct size to begin with, which simply
isn't possible.)
- (void)windowWillLoad;
{
NSDisableScreenUpdates();
[super windowWillLoad];
}
- (void)windowDidLoad
{
[super windowDidLoad];
at this point, the window is already visible
...
[stackView addView:view inGravity:NSStackViewGravityTop];
...
[self.window layoutIfNeeded];
[self.window center];
NSEnableScreenUpdates();
}
--
Seth Willits
___
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: Completely baffled by NSTabViewController + Autolayout (OS X bug)
On Aug 17, 2015, at 9:13 PM, Seth Willits sli...@araelium.com wrote: The goal of this project as is, is simple: using an NSTabViewController, add multiple tab view items where each of the items has a view with its own autolayout-determined fixed size (as in, either an intrinsic content size, or the constraints of the subviews dictate the size of the view itself.) **That's it.** And I've been struggling with this for hours. The problems I'm seeing are randomly positioned views and inconsistent sizing: http://www.sethwillits.com/temp/TabViewResizing1.mp4 Here's the project: http://www.sethwillits.com/temp/TabViewResizing.zip Can anyone explain this? DTS say it's un-workaroundable bug in Yosemite and El Cap because NSTabViewController does not work well with autolayout. I filed a Radar. If you have any desire to ever use NSTabViewController, I suggest you do the same. -- Seth Willits ___ 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
Presenting VCs as Sheets — Completion Handler?
Naturally we're all accustomed to the pattern:
[sheet beginSheetModalForWindow:window completionHandler:^(NSInteger response){
...
}];
But with the new presentation API, there's no built-in mechanism for handling
the sheet being closed. To have a similar pattern as before would require:
otherVC.completionHandler = ^(NSInteger response){
...
};
[someVC presentViewControllerAsSheet:otherVC];
@implementation OtherViewController
// @property void (^completionHandler)(NSInteger response);
- (IBAction)ok:(id)sender
{
[self dismissController:nil];
if (self.completionHandler) {
self.completionHandler(NSOKButton);
self.completionHandler = nil; // Gotta kill the likely circular
reference.
}
}
@end
No doubt it's flexible, but it's a bit verbose. I just want to double-check I
didn't miss some other pattern we're supposed to be using.
--
Seth Willits
___
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: navigating NSPopUpButton menu items with arrow keys
On Aug 23, 2015, at 1:05 AM, sqwarqDev sqwarq...@icloud.com wrote: When the user navigates to the last item in the list, further presses on the down arrow key do nothing, and the user has to reverse direction using the up arrow. If the user is at the first item and wants to choice the last, or vice versa, this is a bit irritating. It's the standard behavior that's been in Mac OS for ages. I suggest not trying to fight it and introduce non-standard behavior. -- Seth Willits ___ 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: Nullability annotation best practice
On Aug 16, 2015, at 11:13 AM, Kevin Meaney k...@yvs.eu.com wrote: I’ve annotated the public methods of the API of a framework and though I haven’t yet I will annotate internal methods and functions as well. I found a small number of issues where my thinking had not been clear, and that having to stop and consider what was intended when annotating the public API for nullability exposed my lack of clarity. I did not have any recorded bugs in this case but I could see how the API could be used that would result in bugs, crashing or otherwise. I added annotations to both the public and private sides of a core framework that's about 17,000 lines of code, and I had the same experiences. On both sides, while 97% of it was clear cut, there was a small number of cases where I wasn't really sure what the answer to nullability and knock on effects was. If I say this public function returns non-null, how sure of that am I really? In a few places I really had to go digging and verify that every step along the way ensured that result. Like you, I don't believe I caught any current bugs, but it clarified my thinking, and showed potential edge cases in the future which could have resulted in problems that now would be caught by the compiler. Although it was tedious to add those annotations and validate them (it only took half a day or so), I feel better for having done it. -- Seth Willits ___ 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: Constraints across sibling stack views?
On Aug 17, 2015, at 9:57 AM, David Duncan david.dun...@apple.com wrote: What's the proper way to have these labels all equal width, when they're in different NSStackViews? Do you mean for the label to be equal width to another label (although it shouldn’t matter, but I just want to make sure I understand from your pictures)? I would expect that to work generically, but I don’t have any particular insight into why it might not. If that fails, you might try doing 2 vertical stacks and using baseline alignments across the vertical stack views instead... Thanks for the response. I took another look to try your suggestion, and it turns out I managed to get it to work both ways. It seems like the warnings I was getting were just sticky leftovers that weren't actually real. After saving, closing the xib, clean building, and reopening the xib everything is fine. So either two vertical stacks, or a vertical stack of three horizontal stacks, either works just fine. http://www.sethwillits.com/temp/upshot/upshot_taR2gwwa.png All is good! -- Seth Willits ___ 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
Completely baffled by NSTabViewController + Autolayout
I am missing something big, because I am having nothing but insane trouble when trying to get a simple tab view working with autolayout. Every path I head down has strange problems. I've tried slimming it down to the smallest test project and I'm still confused. The problems I'm seeing are randomly positioned views and inconsistent sizing: http://www.sethwillits.com/temp/TabViewResizing1.mp4 Here's the project: http://www.sethwillits.com/temp/TabViewResizing.zip The goal of this project as is, is simple: using an NSTabViewController, add multiple tab view items where each of the items has a view with its own autolayout-determined fixed size (as in, either an intrinsic content size, or the constraints of the subviews dictate the size of the view itself.) **That's it.** And I've been struggling with this for hours. In the test project I have two tabs. Each has an NSView subclass that has an intrinsic size so that the view itself must always be at that size. Those views are then added to the tabview via tab view items. I expect that the layout system will resize the views to be at their intrinsic size, and position them properly within the tab view. Instead I'm seeing them a) not always be at their intrinsic size, and b) if the tab switches in the middle of animating, then it stops at some interrupted size. Can anyone explain this? Bonus question: How am I supposed to get a normal bordered tab view with tabs on top using an NSTabViewController? Using NSTabViewControllerTabStyleSegmentedControlOnTop shows the segmented control, but there's no border? Using NSTabViewControllerTabStyleUnspecified + tabView.tabViewType = NSTopTabsBezelBorder; is as close as I can get, but then the tab view item's view placement is wrong? -- Seth Willits ___ 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: Nullability annotation best practice
Really? This list has no opinions? That's hard to imagine :-) -- Seth Willits On Aug 8, 2015, at 1:15 PM, Seth Willits sli...@araelium.com wrote: Let's stipulate that _Nullable and _Nonnull are great to have because they can catch bugs and express API intent better than before, so we want them. The question is where to put them? _Nullable and _Nonnull make perfect sense to specify in the @interface. Since those annotations existing in the @interface will produce applicable warnings and errors in the counterpart @implementation,there's really no _need_ to respecify them in the @implementation of those same methods. It makes sense for private methods to have nullability annotations for all the same reasons public Now let's assume that private methods aren't specified in any @interface, even the anonymous one. In that case, those methods would naturally have no annotations on their parameters or return values unless they're specified within the @implementation. But specifying them on the private methods in the @implementation while *not* specifying them for the public methods in the @implementation is inconsistent and potentially confusing. So I see two choices here: 1) Always add nullability annotations, for all methods and properties in both the @interface and @implementation. (Private methods may or may not be declared within @interfaces — but these days I think it's generally not done?) 2) Only add nullability annotations in the @interface, and always declare private methods within an @interface. Is there a third choice I'm not thinking of? Thoughts? I'm curious how Apple is adopting these annotations themselves. -- Seth Willits ___ 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: Initialisation pattern
On Aug 12, 2015, at 8:07 PM, André Francisco andre.frate...@hotmail.com
wrote:
Hi all,
I've been reading about object initialisation in Objective-c, as well as the
recent additions of NS_UNAVAILABLE and NS_DESIGNATED_INITIALIZER. It's been
confusing what the correct approach would be, mostly due to limitations
imposed by the compiler. My main goal is obviously to ensure proper object
initialisation, both when an object is directly instantiated and when a
constructor call is propagated by a child subclass.
It's noticeable that my background comes mostly from C++ and Java, both
languages in which constructors are not inherited by child classes, unlike
Objective-c. I can't make sense out of constructor inheritance, to be honest.
The fact that a constructor makes sense in a given class does not mean it
will to its children. -init is a great example of this if a given class has
mandatory parameters with no default values.
Lets analyse some approaches:
Override the parent constructor and make up some defaults - this is, IMO, the
worts approach. It'll force you to come up with defaults even if they are
senseless. Callers will have to rely on documentation in order to understand
what the defaults are doing, if anything at all. I've read about set all to
zero approaches but in this case enums come to mind. Obviously not only
enums will suffer from this, but setting an enum to zero does not mean that
it's an invalid state, quite the contrary. Even so, the instance would still
be useful so I really don't see a point.
,.. Instead of this approach I'd rather:Always return nil.
If the parent's initializer cannot create a child object correctly, then having
the child implement it and throw an exception is the right approach. It's a
programmer error and should be treated as such.
@implementation Child
- (instancetype)initMethodFromParent
{
[self doesNotRecognizeSelector:_cmd];
return nil;
}
@end
And now with NS_UNAVAILABLE, you would mark it as such in the @interface so the
compiler will enforce it not being called.
@interface Child : Parent
- (instancetype)initMethodFromParent NS_UNAVAILABLE;
@end
Use NS_UNAVAILABLE on constructors that do not provide required parameters
(ie., parameters without defaults). This would be my favourite approach as it
is enforced by the compiler if the method is called directly, except that you
cannot redefine the method on a subclass. Lets say a given class is
implemented and flags -init as NS_UNAVAILABLE, while implementing a second
initialiser -initWithParameter:. This is a base class and it doesn't make
sense not to provide the given parameter, whatever the reason may be. Some
other class, a child of the first, is not implemented which does provide a
default parameter - too late, -init is already unavailable.
No, it's fine. Just declare the -init method as NS_DESIGNATED_INITIALIZER in
the @interface of the child class, and implement it to call -initWithParameter:
of the parent class.
--
Seth Willits
___
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: Initialisation pattern
On Aug 13, 2015, at 1:32 PM, André Francisco andre.frate...@hotmail.com wrote: I only got Seth's email on the digest, not really sure why. Anyway, I copy pasted his response below.@Seth, thank for your answer. That's exactly what I've been doing all along, I didn't mention it because that's precisely what I'm trying to change. The problem is that it's not fine, I just tested it:@interface Parent- (instancetype)init NS_UNAVAILABLE;@end@interface Child- (instancetype)init NS_DESIGNATED_INITIALIZER;@endThis results in init is unavailable being issued by the compiler when instantiating Child. I'm using xcode 6.3.2, does your version differ? I'm using Xcode 7 (beta 5) which has a newer version of clang in it than you have, so it appears this has changed. -- Seth Willits ___ 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
Why is overriding unavailable designated initializer of super required?
I've yet to understand this: https://gist.github.com/swillits/3133e114f770947b3cf6 If a subclass says that its superclass's designated initializer is unavailable (IOW, the subclass's designated initializer must be used), why does the compiler produce a warning that the superclass's designated initializer must be overridden in the subclass? If the subclass is going to call super's designated initializer via [super init] then this subclass override would never get called anyway... What am I missing? -- Seth Willits ___ 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: Why is overriding unavailable designated initializer of super required?
First off, thanks for the answer. Unfortunately either I'm still missing
something, or perhaps my question wasn't precise enough...
On Aug 10, 2015, at 1:49 PM, Greg Parker gpar...@apple.com wrote:
Convenience initializers.
Consider: a superclass that implements a designated initializer and a
convenience initializer, and your subclass that introduces a new designated
initializer.
@implementation SomeSuperclass
-(id) init; // designated initializer
-(id) convenienceInitializer {
return [self init];
}
@end
...
or you can implement it to fail at runtime:
@interface YourSubclass
-(id) init NS_UNAVAILABLE;
@end
@implementation YourSubclass
...
-(id) init {
abort(); // or throw or whatever
}
@end
Either approach will pacify the compiler.
Say that I am taking this approach because it'd be impossible for a
YourSubclass instance to call initWithValue: on itself with an acceptable
default value; One is required by the client.
Even though -init is unavailable, it's still actually possible to call
-convenienceInitializer, which will end up calling -[YourSubclass init] and
hitting the abort. That's bad.
We can reason that by definition, convenienceInitializer must call
SomeSuperclass's designated initializer -init. Since we know that -init cannot
possibly setup a YourSubclass instance correctly, then we shouldn't allow
convenienceInitializer to be called either. So now we'd have to mark
convenienceInitializer as NS_UNAVAILABLE in YourSubclass's interface.
By declaring:
@interface YourSubclass
-(id) init NS_UNAVAILABLE;
-(id) convenienceInitializer NS_UNAVAILABLE;
@end
… this now leaves us correctly unable to call [[YourSubclass alloc] init] or
[[YourSubclass alloc] convenienceInitializer].
Which brings me right back to my original question. If neither of those can be
called, then implementations of them in YourSubclass could never be called.
Right? If not, then why does YourSubclass need to provide implementations?
--
Seth Willits
___
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: Why is overriding unavailable designated initializer of super required?
On Aug 10, 2015, at 4:29 PM, Greg Parker gpar...@apple.com wrote: Writing a halting cover for the superclass's designated initializers is a defensive measure. If you miss one of the convenience initializers then getting an immediate crash with a crash log pointing to the initializer is much better than quietly calling the wrong initializers and mysteriously crashing somewhere else later. Ok, that's the potential answer I was expecting. It'd be really nice if Xcode or the compiler actually gave succinct rationale for some of the more involved warnings and errors like this. Thanks. -- Seth Willits ___ 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
Constraints across sibling stack views?
In my OS X view, I have four popup buttons vertically stacked, each with a label on the left. The labels all have equal width as each other and are right-aligned, and the popups all have equal width as well. To manage this layout I created four horizontal stack views, one for each label-popup pair, and placed those four stack views into a vertical stack view. At this point, the labels are all sized to fit, as are the popups. If I add a constraint that says one label should be equal width to another popup, I then get a constraint warning that there's a size mismatch for the label. What's the proper way to have these labels all equal width, when they're in different NSStackViews? What I want: http://www.sethwillits.com/temp/upshot/upshot_7Yna0OGF.png After dumping into stack views: http://www.sethwillits.com/temp/upshot/upshot_yX7dV6OL.png -- Seth Willits ___ 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
Nullability annotation best practice
Let's stipulate that _Nullable and _Nonnull are great to have because they can catch bugs and express API intent better than before, so we want them. The question is where to put them? _Nullable and _Nonnull make perfect sense to specify in the @interface. Since those annotations existing in the @interface will produce applicable warnings and errors in the counterpart @implementation,there's really no _need_ to respecify them in the @implementation of those same methods. It makes sense for private methods to have nullability annotations for all the same reasons public Now let's assume that private methods aren't specified in any @interface, even the anonymous one. In that case, those methods would naturally have no annotations on their parameters or return values unless they're specified within the @implementation. But specifying them on the private methods in the @implementation while *not* specifying them for the public methods in the @implementation is inconsistent and potentially confusing. So I see two choices here: 1) Always add nullability annotations, for all methods and properties in both the @interface and @implementation. (Private methods may or may not be declared within @interfaces — but these days I think it's generally not done?) 2) Only add nullability annotations in the @interface, and always declare private methods within an @interface. Is there a third choice I'm not thinking of? Thoughts? I'm curious how Apple is adopting these annotations themselves. -- Seth Willits ___ 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
[PSA] OSStatus.com — Error code lookup
I can't tell you how many times over the years I've been frustrated by having to manually search multiple frameworks' header files to look up what the symbol or description for an error code value was. (I know 'macerror' exists, but I have never had any luck with it. I consider it useless.) I finally got fed up, wrote some code, and made a website. So, here's v1. http://www.osstatus.com/ I hope someone besides me finds it useful. ;-) -- Seth Willits ___ 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: NSNotification coalescing - which one gets through?
On May 6, 2015, at 3:54 AM, Jonathan Taylor jonathan.tay...@glasgow.ac.uk wrote: I am trying to work out whether there are any rules that define which of multiple NSNotifications combined using coalescing actually get through to the receivers, and preferably a way of controlling that behaviour. This becomes relevant if for example there is different UserInfo associated with each object. I can’t find any specific statement about what the behaviour is under these circumstances. My interpretation of the API is that user info should either be consistent or not used in coalescing scenarios, though the documentation never discusses this. Actually I think I may have answered my own question: calling dequeueNotificationsMatching immediately before posting a new notification seems to do the trick. This seems like a reasonable and logical way of achieving what I want. Can anyone see any problem with doing that? Nope. Seems fine to me. The other way to accomplish is this is to have the data stored outside of the notification and accessible to the receivers, and just let the notifications coalesce as normal. Instead of looking in userInfo, the receivers would go pull the data from the other source. But whether that's a better fit is questionable based on circumstances. -- Seth Willits -- Seth Willits ___ 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: TextView : Shifting all text down to make room for a subview
On Apr 1, 2015, at 3:00 PM, Jonathan Hull jh...@gbis.com wrote: Have you tried just setting the textContentInset to make room for your subview? The inset by definition affects both the top *and* bottom. I only want the top. -- Seth Willits ___ 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
TextView : Shifting all text down to make room for a subview
I have a text view where I added a subview at the top, and I want all of the
text to be below this subview. You can think of it like having a horizontal
ruler above the text view, but instead I want this view (it's not a ruler) _in_
the text view so that it scrolls with the text.
Here are two different strategies, neither of which I can quite get to work...
--
The simplest thing I could think of was to subclass NSTextView and override
textContainerOrigin to push the Y value down a little. My little accessory view
then becomes a direct subview of the text view. The first line of text is
exactly in the right spot so it seems like it'll work perfectly, but if the
text fills the entire text view, it won't start scrolling until the height of
the *text* is greater than the height of the entire text *view*, which means
that however many points I've shifted the text down by, that many points of
text is cut off at the bottom of the text view before scrolling is allowed.
In other words, if the text view's could hold 10 lines of text, I shift all the
text down by 1 line, and put 10 lines of text into the text view, I expect to
see 9 lines and have to scroll to see the 10th, but instead, the scrollview
doesn't allow scrolling at all, so that 10th line is completely inaccessible.
If I add an 11th line, then I can scroll to the 10th line, but not the 11th,
etc.
So whatever mechanism is calculating how much scrolling is needed, doesn't
respect the text container's origin as returned by NSTextView
-textContainerOrigin? I can't seem to figure out how to fix that.
---
A completely different approach would be to affect typesetting where the line
fragments flow around this view, by just making sure the line fragments don't
start until below it. I implemented this strategy with a custom text container,
and it appears to work at first, but if the text is long enough that scrolling
is required, then the first line fragment is just at 0,0 in the text container
regardless of the fact that I explicitly told it to not be...
@implementation MyTextContainer
- (BOOL)isSimpleRectangularTextContainer
{
return NO;
}
- (NSRect)lineFragmentRectForProposedRect:(NSRect)proposedRect
sweepDirection:(NSLineSweepDirection)sweepDirection
movementDirection:(NSLineMovementDirection)movementDirection
remainingRect:(NSRectPointer)remainingRect
{
if (proposedRect.origin.y + proposedRect.size.height
self.containerSize.height) {
return [super lineFragmentRectForProposedRect:proposedRect
sweepDirection:sweepDirection movementDirection:movementDirection
remainingRect:remainingRect];
}
if (!NSIntersectsRect(NSMakeRect(0, 0, self.containerSize.width, 26),
proposedRect)) {
return [super lineFragmentRectForProposedRect:proposedRect
sweepDirection:sweepDirection movementDirection:movementDirection
remainingRect:remainingRect];
}
NSRect reproposedRect;
reproposedRect.origin.x = proposedRect.origin.x;
reproposedRect.size.height = proposedRect.size.height;
reproposedRect.size.width = self.containerSize.width;
reproposedRect.origin.y = 26;
reproposedRect = [self lineFragmentRectForProposedRect:reproposedRect
sweepDirection:sweepDirection movementDirection:movementDirection
remainingRect:remainingRect];
return reproposedRect;
}
@end
So there are two different strategies, and I've hit a sizable enough wall that
with both that I'm kinda stumped.
Anyone had any luck doing something like this?
--
Seth Willits
___
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: Idea for Improving Vibrancy
Ugh. Mail used the wrong address again and bounced this... -- Seth Willits On Feb 15, 2015, at 9:54 PM, Seth Willits s...@freaksw.com wrote: On Feb 15, 2015, at 6:13 AM, Charles Jenkins cejw...@gmail.com wrote: Is this possible, do you think, to open a window that always hides directly behind the working window? Easily. Add a borderless child window ordered using NSWindowBelow. However, properly replicating the contents of the desktop within that window (especially given the desktop image can change — with animation —— and there's no way you can know when etc) makes it impractical. Then there's the performance and resource considerations. It is technically possible though. Beyond the technical side, there's the obligatory you shouldn't do this because of HIG and consistency statement to be made. (Hopefully this won't spiral into another ridiculous eww it's so uuugly thread...) -- Seth Willits ___ 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: Self describing NSObjects.
On Feb 4, 2015, at 10:43 AM, Alex Zavatone z...@mac.com wrote:
How would you think about implementing this? It seems like I run into this
need year after year after year.
NSString * NSObjectDescriptionUsingProperties(id obj)
{
unsigned int propCount;
objc_property_t * propList = class_copyPropertyList([obj class],
propCount);
NSMutableString * ms = [NSMutableString stringWithFormat:@%@: %p,
NSStringFromClass([obj class]), obj];
if (propCount 0) {
[ms appendString:@ {\n];
for (unsigned int i = 0; i propCount; i++) {
const char * propName = property_getName(propList[i]);
[ms appendFormat:@\t%s = %@,\n, propName, [obj
valueForKey:[NSString stringWithUTF8String:propName]]];
}
[ms appendString:@}];
free(propList);
}
return ms;
}
--
Seth Willits
___
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: Self describing NSObjects.
On Feb 5, 2015, at 3:54 PM, Seth Willits sli...@araelium.com wrote:
How would you think about implementing this? It seems like I run into this
need year after year after year.
NSString * NSObjectDescriptionUsingProperties(id obj)
{
unsigned int propCount;
objc_property_t * propList = class_copyPropertyList([obj class],
propCount);
NSMutableString * ms = [NSMutableString stringWithFormat:@%@: %p,
NSStringFromClass([obj class]), obj];
if (propCount 0) {
[ms appendString:@ {\n];
for (unsigned int i = 0; i propCount; i++) {
const char * propName = property_getName(propList[i]);
[ms appendFormat:@\t%s = %@,\n, propName, [obj
valueForKey:[NSString stringWithUTF8String:propName]]];
}
[ms appendString:@}];
free(propList);
}
return ms;
}
And if you want to get really creative, you could swizzle NSObject's
-description to call it.
--
Seth Willits
___
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: NSUserDefaults and home folder on different drive
On Dec 10, 2014, at 11:05 PM, Rick C. rickcort...@gmail.com wrote: I write an NSString and NSData object to my app’s .plist and of course read it back when needed and this works fine 99% of the time. On occasion a user reports some trouble to me and I ask for the .plist and find out that this NSString/NSData object is missing. Digging deeper I find that most often the user has their home folder on a different drive (external?) than the actual app. What would be the solution to make sure these objects are written properly in this case? Thanks for the help, Note that you simply can't ask for the plist anymore because it's not necessarily been written to yet with the latest changes. I don't know when it gets written to (maybe practically speaking it always is by the time you get to it) but the truly correct way to get a representation of what's in user defaults is to use $ defaults export domain Just worth mentioning… -- Seth Willits ___ 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
Layer-backed multiline text view rendering dim
Layer-backed multline text fields are drawing dimmer than otherwise *identical* layer-backed single line fields. The only difference is the multiline field has a new line in its text value. Here's an example: http://sethwillits.com/temp/upshot/upshot_uR7h5QTy.png This visible difference only occurs when the LCD Font Smoothing option is turned off in System Preferences. Does anyone know if there's a workaround for this? I tried telling the text field to draw an opaque white background as well (to deal with subpixelness), but that didn't change anything. -- Seth Willits ___ 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
[PSA] Non-layer backed views + scrolling + visual artifacts
UGH. So my app was doing this: http://www.sethwillits.com/temp/ScrollingWeirdness.mp4 … very often, and sometimes dramatically worse than that (but also sometimes much more subtle). For subtle, stick these two images in separate tabs and switch back and forth: http://sethwillits.com/temp/ScrollingWeirdnessSubtleA.png http://sethwillits.com/temp/ScrollingWeirdnessSubtleB.png The very first thing I tried was setting the window's content view to be layer-backed to see if that changed anything, and it didn't. So I then created a stripped down bare bones nothing-but-nibs project that was still exhibiting this behavior and then spent 3 hours exploring 6 or 7 different dead ends trying to find the cause. It took me too long to figure out that my initial test was broken, since after setting the window's content view to be layer-backed, I then _replaced_ that content view with the view from another nib which wasn't layer-backed. *sigh* As soon as I turned on layer-backing for real, the problem went away. Here's a project with two windows side by side so you can compare and see if you see them. For me it may take a lot of fiddling (scrolling, window activation changes, app changes, rain dancing, knocking on wood etc) to get it to start breaking really obviously. Other times it happens immediately and constantly. Otherwise you have to be paying attention relly closely to see the subtle brokenness. http://www.sethwillits.com/temp/ScrollingWeirdness.zip For me, this is 100% repeatable, and 100% fixable by turning on layer-backing. I'm on 10.10.1, iMac14,2 NVIDIA 780M. I imagine it's a bug, but one that's worked around by using layer-backing. I'll be filing a bug report… -- Seth Willits ___ 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
Vibrancy + Floating Group Row bug?
Some subviews of table view cells underneath a floating group row, in a vibrant table view have strange drawing: http://sethwillits.com/temp/upshot/upshot_EnYMpCzT.png Any thoughts? (In the case of the pink text field, if I leave the text color as Control Text Color, then its boundaries aren't visible when under the group row.) -- Seth Willits ___ 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: Vibrancy + Floating Group Row bug?
On Nov 6, 2014, at 12:20 PM, Seth Willits sli...@araelium.com wrote: Some subviews of table view cells underneath a floating group row, in a vibrant table view have strange drawing: http://sethwillits.com/temp/upshot/upshot_EnYMpCzT.png Any thoughts? (In the case of the pink text field, if I leave the text color as Control Text Color, then its boundaries aren't visible when under the group row.) Further experimentation shows if I subclass NSImageView and NSTextField and implement -allowsVibrancy to return YES, then their bounds are no longer visible in the group row. However, the selected row's selection drawing still is, even if it's also a custom subclass which returns YES from -allowsVibrancy. http://sethwillits.com/temp/upshot/upshot_AEyLyuSa.png I can't seem to find any way to cure that, which in a real-world app where the group row :\ -- Seth Willits ___ 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: NSSplitView divider tracking-area
in a panel, the tracking area for NSSplitView’s divider is only active if the panel is key, i.e. the cursor is not affected otherwise. as a panel is not generally key unless needed, ought not this area be always active? anyone agree? anyone have a workaround? What does a panel mean to you? AFAIK the tracking area of the split view is not affected by anything in the way you describe, and looking at the disassembly shows nothing out of the ordinary. The delegate has the ability to add to the area, but that's it. -- Seth Willits ___ 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: Waiting for callback with GCD: impossible?
On Oct 8, 2014, at 11:59 AM, Jens Alfke j...@mooseyard.com wrote: * Now, how does queue A wait for the callback? It seems to be impossible: the only way for code running on queue A to receive the callback is to return back to the queue dispatcher, so if it tries to wait it simply blocks the queue, causing a deadlock. … But given that dispatch queues can't do this, what's the solution to this design problem, i.e. turning an async call into a sync one? Simply performing the rest of the task in the callback is one way. -- Seth Willits ___ 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
Efficient CVPixelBuffer display in a CALayer
If I have an ARGB CVPixelBufferRef, what's the most efficient way to display it in a CALayer? The only officially supported formats for the CALayer.contents property are NSImage and CGImage, and both of those paths will end up copying the CVPixelBuffer's data on the CPU, and then upload the copy to the GPU. I'm trying to easily avoid that copy. It seems my only choice is to create an CAOpenGLLayer, manually create a texture from CVPixelBuffer using the typical gl*() calls, and then draw in the layer's drawInCGLContext method. Is there a simpler option? -- Seth Willits ___ 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: Preventing textfield in table from clicking default button
On Aug 16, 2014, at 9:03 PM, Ken Thomases k...@codeweavers.com wrote: The general mechanism is to implement the control delegate method -control:textView:doCommandBySelector: and alter the response to the insertNewline: selector. Thank you. That's exactly the right thing to do. I've used it before for different things, but not often or recently enough to remember it, and I was still futzing around higher in the stack trying to find something there. For posterity: the textDidBeginEditing/textDidEndEditing method won't work if the text actually doesn't change so don't use that. -- Seth Willits ___ 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
Preventing textfield in table from clicking default button
When editing in a NSTextField and return is pressed, it fires the text field's
action and also sends performKeyEquivalent: to the window, which clicks the
default button. Usually that's just fine, but in the case where a view-based
table view has editable NSTextFields in it, this makes no sense.
Anybody figured out how to prevent this?
---
It happens in NSTextField textDidEndEditing, so there's no stopping
performKeyEquivalent: from being called short of subclassing NSTextField and
reimplementing that method. (Eww)
You also can't disable the key equivalent on the button in
controlTextDidBeginEditing and re-enable it in controlTextDidEndEditing,
because the performKeyEquivalent: is called after the controlTextDidEndEditing
notification is sent.
I thought maybe I could so some light NSTExtField subclassing and use
NSWindow's disableKeyEquivalentForDefaultButtonCell...
@implementation MyTableCellTextField
- (void)textDidBeginEditing:(NSNotification *)notification;
{
[self.window disableKeyEquivalentForDefaultButtonCell];
[super textDidBeginEditing:notification];
}
- (void)textDidEndEditing:(NSNotification *)notification;
{
[super textDidEndEditing:notification];
[self.window enableKeyEquivalentForDefaultButtonCell];
}
@end
Sadly, that doesn't work. My default button is still clicked when [super
textDidEndEditing:] calls performKeyEquivalent:, despite the defaultButtonCell
being the right button… As a matter of fact, looking at the implementation of
those NSWindow methods shows they're identical to each other… which makes
absolutely no sense. So obviously that doesn't do what one would expect.
This is leaving me little choice but to do something very specialized and ugly.
Am I missing something?
--
Seth Willits
___
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: Preventing textfield in table from clicking default button
On Aug 16, 2014, at 7:53 PM, Seth Willits sli...@araelium.com wrote:
This is leaving me little choice but to do something very specialized and
ugly.
Well… the simplest solution is to just disable the key equivalent myself
instead of using NSWindow's methods. I don't like it, but it does work in my
case...
- (void)textDidBeginEditing:(NSNotification *)notification;
{
self.window.defaultButtonCell.keyEquivalent = @;
[super textDidBeginEditing:notification];
}
- (void)textDidEndEditing:(NSNotification *)notification;
{
[super textDidEndEditing:notification];
self.window.defaultButtonCell.keyEquivalent = @\r;
}
--
Seth Willits
___
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: Text System Locks Up - Can't Find Reason
On Jun 11, 2014, at 6:46 PM, KappA rejek...@gmail.com wrote: For some reason it doesn't like the below - you need to comment that out, and uncheck that option in IB: self.textView.layoutManager.allowsNonContiguousLayout = YES; At least that's how I fixed it :) Not sure why it doesn't like that property when using IB. That's not fixing it, it's just avoiding the problem. Fast has it enabled. It's on by default in every text view. -- Seth Willits ___ 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: Text System Locks Up - Can't Find Reason
On Jun 12, 2014, at 11:25 AM, Kyle Sluder k...@ksluder.com wrote: For some reason it doesn't like the below - you need to comment that out, and uncheck that option in IB: self.textView.layoutManager.allowsNonContiguousLayout = YES; At least that's how I fixed it :) Not sure why it doesn't like that property when using IB. That's not fixing it, it's just avoiding the problem. Fast has it enabled. It's on by default in every text view. Well, what if you don't use that, and instead just send -ensureLayoutForCharactersInRange: to the text view's layout manager? Why would I want to? That'd block the calling thread until the layout was done, which defeats the purpose of allowing non-contiguous layout. The Fast and Slow setups are intended to be identical. The only difference is who creates and connects the objects. If I do it, everything works fine. If I let Cocoa do it, it spins for far longer than it should. (Laying out the entire document on my machine takes about 30 seconds, but in the Slow project when locked up, it'll spin for ages and never finish. It's stuck in _insertionPointHelperForGlyphAtIndex called by boundingRectForGlyphRange:inTextContainer:, the latter of which has a perfectly reasonable and small glyph range request.) -- Seth Willits ___ 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: Another app's UTI can break your app
On Jun 10, 2014, at 8:22 PM, Uli Kusterer witness.of.teacht...@gmx.net wrote:
On 10 Jun 2014, at 21:21, Seth Willits sli...@araelium.com wrote:
- (NSString *)typeForContentsOfURL:(NSURL *)url error:(NSError **)outError;
{
if ([url.pathExtension.lowercaseString isEqual:@sql]) {
return @my.uti.type;
}
return [super typeForContentsOfURL:url error:outError];
}
I suppose that this works should be mentioned in your bug. It means Apple
could easily fix it by making the default implementation take a first stab at
looking up the UTI from your Info.plist instead of from Launch Services.
I did mention this in the bug report.
I presume the default implementation may not be this way already because it's
possible that a particular URL may be assigned a specific UTI different from
what it may normally be, and thus Cocoa always defers to the file system to
determine that. However I don't know if that actually ever happens, and even if
it did, it should still look at the app's document UTIs either before asking
the file system, or after having not found a readable type.
I'd encourage others to file a report on this topic as well.
--
Seth Willits
___
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
Text System Locks Up - Can't Find Reason
I have two sample projects: one works fine, one does not. Both read a large (120 MB) file of text into an NSTextStorage, and then display that text storage in a text view. In the Slow project, the text view is created in IB and its text storage object is replaced. Scrolling all the way to the bottom of the text view is possible, but then it basically locks up indefinitely(?) doing text layout. It's also possible to lock it up by resizing the text view soon after it opens. In the Fast project, the text view, container, and layout manager are all created manually and hooked together. In this project it works great: no lockups ever As far as I can tell, I've inspected every relevant property I can think of and the two setups are the same. I haven't a clue what's going on. The only hint I possibly had was from the docs: Note that a text view can be resized based on its text container, and a text container can resize itself based on its text view. If you set both objects up to resize automatically in the same dimension, your application can get trapped in an infinite loop. Except that I checked this, and those conditions aren't met so it shouldn't be this. I challenge(!!) any of you to figure this out. ;-) Projects (and test file): http://www.sethwillits.com/temp/TextDocumentTest.zip (700 KB) Demo: (Note at 23 seconds in, the app has locked up — pinwheels aren't visible in screen recordings) http://www.sethwillits.com/temp/SlowTextSystemDemo.mov -- Seth Willits ___ 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: Text System Locks Up - Can't Find Reason
On Jun 11, 2014, at 5:02 PM, ChanMaxthon xcvi...@me.com wrote: I believe this involves Cocoa Bindings. There are no bindings. -- Seth Willits ___ 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: Text System Locks Up - Can't Find Reason
On Jun 11, 2014, at 5:11 PM, ChanMaxthon xcvi...@me.com wrote: Bindings or not, somebody is listening to the text view when created in xib. That makes some significant dispatching overhead. There's no problem of dispatching overhead — the problem is the layout manager never stops laying out the text. -- Seth Willits ___ 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: Text System Locks Up - Can't Find Reason
On Jun 11, 2014, at 5:49 PM, ChanMaxthon xcvi...@me.com wrote: Is editing involved? If not I would render it into HTML and let WebKit render it. This is not helpful at all. -- Seth Willits ___ 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: Text System Locks Up - Can't Find Reason
On Jun 11, 2014, at 5:42 PM, Kyle Sluder k...@ksluder.com wrote: Seth, did you notice that if you change backgroundLayoutEnabled and allowsNonContiguousLayout to NO in -windowDidLoad, that the scrollbar gets perpetually longer as you scroll? Very strange indeed. Yep. That's expected AFAIK. Since you've told it layout must be contiguous, when laying out glyph N, all glyphs from 0 to N-1 are already laid out. Also, since background layout is disabled, it will only layout what it's asked to, which so far is only what's visible. Since only part of the text has been laid out, the text view is fitted to what's been laid out. When background layout is enabled, I'm not actually sure how it figure out how big to make the text view, particularly so quickly. -- Seth Willits ___ 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: Other app blocks mine from opening my documents
On Jun 10, 2014, at 5:29 AM, Uli Kusterer witness.of.teacht...@gmx.net wrote: Seems, between Panic and you registering their own UTIs for SQL files, the OS gets confused which is the actual type. AFAIK Apple assumes there is only one UTI for a type. So when it opens the file, it sees your app can do the extension, but when then looking up the UTI to go with that extension, it gives you Panic's UTI because it doesn't remember which of the registered UTIs was yours. Could that be it? That's certainly what it seems like. I guess what you could do is try to register for Panic's UTI as well (and that of any other app that declares one for SQL files), then just internally map them all to your SQL document class? The problem with that is there's probably 50 apps that could define this UTI as well. Not only I would I have to import all of their UTIs, they'd have to import mine and everyone else's too. Otherwise there's always the chance that any one of our apps would be rendered useless by simply having any of the other apps on the system too. If that's really how it works, then UTIs are really seriously stupidly broken in this kind of case, and I just can't believe that's true. The only real option I see is to not use UTIs at all. -- Seth Willits ___ 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
Another app's UTI can break your app
TLDR:
---
If your app has a document type that may use the same extension as another app,
you should override typeForContentsOfURL:error: because otherwise the existence
of that other application on a user's system can break your app.
Problem summary:
---
My app and Coda both open plain text .sql files. Coda exports a UTI for the
.sql extension. So does my app. However (because Coda was registered with
Launch Services first), my app will be prevented from opening ANY .sql file
because the system and Cocoa think it's a
com.panic.coda.structured-query-language-file file, and my app can't open files
with that UTI.
The same would happen even if my app does not use a UTI but simply declares
that it opens documents with an .sql extension.
This is a critical problem.
Investigatory work:
---
- [NSDocumentController typeForContentsOfURL:error:] is the first method being
called to determine what class will open a file. The header file (but not the
documentation) has some useful information:
The default implementation of this method merely returns the URL's
NSURLTypeIdentifierKey resource value.
You can override this to customize type determination for documents
being opened.
What this says, is that Cocoa doesn't look at my Info.plist file to see what
type *my application* would describe the file at the URL as. Instead, it by
default asks the file system what's the UTI for this URL and Launch Services
(because Coda registered its sql UTI long before my app) says: It's a Coda
file.
Cocoa *then* looks in my Info.plist file (essentially), and sees no
conformity/usage of com.panic.coda.structured-query-language-file so it throws
a fit, preventing my app from opening .sql files.
That's very unfortunate and frankly ridiculous because this means that the
existence of another application on your system can break your app.
The solution however is easy.
Solution
---
By overriding typeForContentsOfURL:error: as the header suggests, we can cure
the problem.
- (NSString *)typeForContentsOfURL:(NSURL *)url error:(NSError **)outError;
{
if ([url.pathExtension.lowercaseString isEqual:@sql]) {
return @my.uti.type;
}
return [super typeForContentsOfURL:url error:outError];
}
It's also important to note that if your document type declares a UTI, you need
to return that UTI from typeForContentsOfURL:error: even though the docs say it
returns name of the document type (AKA the CFBundleTypeName). If you return
the type name and not the UTI then the document architecture will get confused
later and things will fail. However, if you don't declare a UTI type for the
document, then return the CFBundleTypeName.
Conclusion
---
That's several hours of investigatory work. I went down many rabbit holes
during that, but I'm pretty sure that I understand this and have boiled it down
to the root cause and truth. If I'm wrong, please correct me. (I'd like to be
wrong!)
--
Seth Willits
___
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: Another app's UTI can break your app
On Jun 10, 2014, at 12:33 PM, Sean McBride s...@rogue-research.com wrote: This is a critical problem. This is well known, and has been discussed on this list years ago. Sigh. Wish I had been able to find anything on this topic when I searched. At least I'm not crazy. Yes, a malicious app could probably claim all sorts of UTIs, stopping other apps from opening documents. Then again, a malicious app could also delete a bunch of files, so... It's not even about malicious intent. Coda obviously has no malicious intent, but it breaks my app. I'd break Coda if it my app was installed before it. That's just inconceivable to me. I filed a bug back in 2007: rdar://5540833 9a559: Denial of service; Launch Services changes UTI when new app arrives I've given up on it ever being fixed (like most everything in Radar). But hey, we're getting new cool translucent stuff! :) A 7 year-old ticket is extremely disappointing. I will file another. -- Seth Willits ___ 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
Other app blocks mine from opening my documents
My app opens SQL files so I declared a UTI for it in Exported UTIs in the app
Info.plist with my own identifier, uses sql as an extension, has a text/plain
mime type, and conforms to public.plain-text.
My app opens a new document window, I edit it, it autosaves, and on relaunch
Cocoa yells at me:
-
This application can't reopen autosaved
com.panic.coda.structured-query-language-file files.
-[NSDocumentController
reopenDocumentForURL:withContentsOfURL:display:completionHandler:] failed
during state restoration. Here's the error:
Error Domain=NSCocoaErrorDomain Code=256 The autosaved document “(null)” could
not be reopened. UserInfo=0x608000470540 {NSLocalizedDescription=The
autosaved document “(null)” could not be reopened. }
-
I'm a bit puzzled. Guidance?
--
Seth Willits
___
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: Best practices with singletons
The practical answer in short is: Just always access through +sharedInstance, no need to pre-initialize, and only use it on the main thread. This is one of those threads that will easily become a stupidly long debate that's been had a dozen times before. If you're interested in all of the intricate discussion about thread safety and how singletons are the spawn of satan, go search the archives and Google. -- Seth Willits ___ 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: File's owner in nib file
On Jun 8, 2014, at 12:07 PM, Miguel Carvajal krvajal.miguelan...@gmail.com wrote: I created a new NSWindow in interface builder and using a NSWindowController i pr ogrammatically load the window from the nib and show it, but once i close the window, i don' t get it show again. Some digging in stackoverflow revealed me that it happens that way because i have to set the File's Owner of the NSWindow in IB to NSWindowsController. Whether a window will appear or not has nothing to do with File's Owner. Your window is probably marked as Release When Closed in IB. It's shown once the first time, but after closing it it's deallocated and no longer exists so it can't be shown a second time. Turn that off. Documentation on File's Owner: https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/LoadingResources/CocoaNibs/CocoaNibs.html In this case File's Owner is the NSWindowController because it's the NSWindowController that is loading and owns the nib. When you load a nib, your code needs to access certain objects in the nib (via IBOutlets) and your nib may need to set properties (like delegates, data sources, and actions) to objects that exist outside of the nib. When you connect to File's Owner, you're connecting from an object in IB to that object that already exists before nib is loaded. When you connect from File's Owner to an object in the nib, you're setting an outlet in that already existing object to an object in the nib that's being loaded. -- Seth Willits ___ 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: File's owner in nib file
On Jun 8, 2014, at 12:23 PM, Seth Willits sli...@araelium.com wrote: Whether a window will appear or not has nothing to do with File's Owner. Your window is probably marked as Release When Closed in IB. It's shown once the first time, but after closing it it's deallocated and no longer exists so it can't be shown a second time. Turn that off. Kyle pointed something out to me off-list, so now I need to backpedal and change what I said a bit. What I meant was whether or not the File's Owner class in IB is set or not doesn't really matter to the issue at hand, but that's not true because if it's not set then you can't connect the window outlet of File's Owner (your window controller) to the window itself, which of course is critical. So without setting it and connecting the window outlet, the window controller doesn't know about the window. The reason the window is being displayed the first time is probably because it has Visible At Launch checked, which will display the window when the nib loads (Launch is a misleading term, really). Once you've closed it, it can't be reopened because the window controller doesn't know it exists (because the outlet isn't connected) and thus can't tell it to display. On Jun 8, 2014, at 12:28 PM, Miguel Carvajal macarva...@estudiantes.fisica.uh.cu wrote: When you load a nib, your code needs to access certain objects in the nib (via IBOutlets) and your nib may need to set properties (like delegates, data sources, and actions) to objects that exist outside of the nib. When you connect to File's Owner, you're connecting from an object in IB to that object that already exists before nib is loaded. What does it means, the object that already exist before the nib is loaded? Do you refer in this case to NSWindowController instance? Yes. The window controller itself exists before the nib is loaded. This is true of whatever File's Owner would be for any nib being loaded. -- Seth Willits ___ 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: OpenGL and crawling ants
On Jun 8, 2014, at 6:50 PM, Todd Heberlein todd_heberl...@mac.com wrote: http://www.toddheberlein.com/blog/2014/6/8/opengl-and-crawling-ants Use mipmaps, and if that's still not high enough quality, anisotropic filtering. -- Seth Willits ___ 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: NSAlert - Default Cancel also respond to Escape? [Solution]
On May 19, 2014, at 1:30 PM, Seth Willits sli...@araelium.com wrote: Any ideas on how to get a Cancel button which is both the default button and responds to escape? Both require setting the button's key equivalent and there can only be one. Desired Behavior: Delete - First button, but *not* default button. Responds to Command-Delete Cancel - Default button, responds to both the Return and Escape keys. Solution: NSAlert * alert = [[NSAlert alloc] init]; [alert addButtonWithTitle:@Delete]; [alert addButtonWithTitle:@Cancel]; [[alert.buttons objectAtIndex:0] setKeyEquivalentModifierMask:NSCommandKeyMask]; [[alert.buttons objectAtIndex:0] setKeyEquivalent:@\b]; // Cmd-Delete [[alert.buttons objectAtIndex:1] setKeyEquivalent:@\r]; // Return NSButton * otherButton = [[NSButton alloc] initWithFrame:NSMakeRect(0, 0, 0, 0)]; otherButton.target = alert.buttons.lastObject; otherButton.action = @selector(performClick:); otherButton.keyEquivalent = @\e; // Escape [alert setAccessoryView:otherButton]; -- Seth Willits ___ 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: Another dumb question about NSWindowController(s)
initWithWindow: is the designated initializer which is why the template has it vs one other of the init methods, but it doesn't mean you have to use it. It's not there to tell you that you need to call it, it's there so you can add initialization-time code as needed. The easiest thing to do to get a window controller to load from a nib automatically is just implement -windowNibName. (In 10.10 you won't need to even bother if the xib is named the same as the class.) Nothing magical going on. You (as an example) call alloc] init], it calls initWithWindow: passing nil (because it's the designated initializer). You ask for the wc's window at some point, it realizes it doesn't have one, sees windowNibName, loads from the nib, and calls windowDidLoad. Baddabing badda boom. -- Seth Willits On Jun 7, 2014, at 12:24 PM, William Squires wsqui...@satx.rr.com wrote: Okay, if I create a new NSWindowController subclass (and tell Xcode to generate the .xib as well), it gives me simple (too simple, I think) template code, whose init... method takes an NSWindow reference. Where does this come from (the reference)? • Is the code instantiating the custom NSWindowController subclass supposed to allocate the NSWindow reference, and - if so - how? I thought the controller was supposed to mediate interactions between the UI and any models or other controllers, according to MVC; other code shouldn't have to worry about how or where the window comes from. • Or is this one of those magical things that's automatically hooked up when the .xib gets unarchived? If so, how, since I would think the controller would have to load the .xib first, and the template code simply contains no reference to loading (any) xib! Unfortunately, all my program in MacOS X books are really out-of-date; what with all the publishers focusing on either Android or iOS these days... :( (a look about in Barnes Noble the other day revealed NO books on OS X programming.) Could someone on this list please help me understand how a window, and its controller, are supposed to be loaded/instantiated/unarchived (that's not in the MainMenu.xib, but in a separate set of files (the header, implementation, and xib, all related by the class name)? P.S. This is with Xcode 5.1.1 on MacOS X 10.8, compiling for MacOS X 64 bit, 10.7 SDK. ___ 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
NSAlert - Default Cancel also respond to Escape?
Any ideas on how to get a Cancel button which is both the default button and responds to escape? Both require setting the button's key equivalent and there can only be one. -- Seth Willits -- Seth Willits ___ 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 6:18 AM, Arved von Brasch co...@atgo.org wrote: “Creating selector for nonexistent method ‘clear:’ what I’d like to understand is why it’s coming out at all. Because when compiling that array controller's file, it has no idea that -clear: exists anywhere in any header it's importing. If you import the ISWindowController header, it'd go away. Your other option is to make a protocol (say, if this array controller is legitimately not supposed to know that ISWindowController exists) or just declare a category on NSObject or something that has -clear: in it if you really want to just shut it up ASAP. -- Seth Willits ___ 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 9:56 AM, Kyle Sluder k...@ksluder.com wrote: “Creating selector for nonexistent method ‘clear:’ what I’d like to understand is why it’s coming out at all. Because when compiling that array controller's file, it has no idea that -clear: exists anywhere in any header it's importing. Arved said: “The window controller’s header file is imported into the second class.” I presume by “second class”, Arved means “the implementation file for the array controller subclass.” Oops. Apparently I skipped an important sentence. ;-) I'm stumped then. Maybe it's bad live-issues data? It's been known to happen… often. -- Seth Willits ___ 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 25, 2014, at 8:08 AM, Jens Alfke j...@mooseyard.com wrote: I’m ending up at the opposite of the received wisdom, namely: * dispatch_sync is a lot cheaper than dispatch_async * only use dispatch_async if you really need to, or for an expensive operation, because it will slow down all your dispatch_sync calls Saying dispatch_async will slow down *all* dispatch_sync calls throws up red flags for me. In my mind there's still a possibility that You're Doing It Wrong. You haven't completely outlined exactly what you've been doing, so it's very hard to offer any solid advice. For example, you didn't mention which queues you're dispatching too, how often your syncs are happen relative to the async, which threads they're being dispatch from, what in particular is happening within them, didn't show any instrument traces… I don't doubt you've found something, but your conclusion doesn't paint the whole picture. And as a matter of fact, I think your first email shows this: On my MacBook Pro this gave me a nice speedup of 50% or more. If it was all down to async universally slowing down all dispatch_sync calls, then wouldn't you expect it to be slower there too? It seems to me you need a better theory as to why the change you made worked. But really, we're flying blind here. -- Seth Willits ___ 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: what do I need the NSArrayController for?
On Apr 3, 2014, at 3:29 AM, Roland King r...@rols.org wrote: So where I ended up is understanding my model, which conflated available devices and selected device was flawed thus meaning I can't have two views each with a different selected device. I meant to make that point too. In their example it makes sense for a game character to have a list of available weapons and a selected weapon, but in your case, the same object having both properties may not. The only odd extra I've had to write is a small class which binds to the Array Controller (to get the arrangedObjects and the selectedIndexes, of which there is only ever 1... Since that class only wants to be notified, not influence the selection, KVO is better idea than a binding IMO. (There are those who will say both are war crimes, but that's besides the point.) Use bindings only if you want the both ends to be able to change the value. -- Seth Willits ___ 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: what do I need the NSArrayController for?
On Apr 2, 2014, at 6:54 AM, Roland King r...@rols.org wrote: At this point I realized the NSArrayController was doing nothing. ... I took it out and bound direct to the equivalent properties on the model It's not doing nothing. The NSArrayController doesn't simply forward objects from the model to the tableview, it has its own copy of the array (the arrangedObjects) which keeps it separate the model. Normally your controller object would have its own copy of the devices array, be the delegate and data source for the tableview, providing the filtered and sorted data to the tableview, handle the selection notifications and update things. Not to mention listen to when the source devices array changes to get a new copy of it. NSArrayController does all of that for you, without interfering with your model. By binding the table view to the model properties directly, you've now established that no other tableview or any other object can have its own selection, or order for those objects. You can't sort or filter the tableview without sorting or filtering the model data itself, which is most often a bad idea. As for the selection property on your model, you can easily listen to either the tableview or the array controller's selection changing, and set the property yourself. You're not required or expected to binding everything just because you can in some manner. -- Seth Willits ___ 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: what do I need the NSArrayController for?
On Apr 2, 2014, at 4:34 PM, Roland King r...@rols.org wrote: That sent me into the documentation to find that indeed there *is* a selected object property on NSArrayController, but it's a *property* not a binding. Note that the selection property value is a proxy which can represent a single object, multiple objects, no object, etc. So don't expect it to be a single instance of your class. But there's more. That diagram also shows how the selected weapon flows back to the Combatant (thus meaning a combatant can only have one selected weapon :) ). That binds the property selection.selectedWeapon to a binding called .. selectedObject. Where is that binding? I checked the documentation and can find that on pop up buttons and matrices but not on a table view nor an NSArrayController. The weapon control is a popup, not a table view. It's showing the selectedObject binding of the NSPopUpButton. That example states it's IB-only, no code required, is it just out of date? If it is, is there a way one could use bindings to accomplish what it's doing there, binding the selected object in a detail array directly back to a property on the selected object in the master? It's valid as is. The popup items are the weapons the combatant has (obtained via the first array controller's selection.weapons path), and then the selected item in that popup is determined by binding to the combatant's selectedWeapon (via the first controller's selection.selectedWeapon path) -- Seth Willits ___ 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 NSViewController with -init.
General advice from my experience: 1. My standard practice has always been to simply override nibName, and call alloc] init]. The majority of the time, view-related properties that need to created that you might normally stick in -initXYZ, I put in -loadView after calling super. (Burn awakeFromNib with fire.) 2. Either call initWithNibName:bundle: or override nibName. Don't rely on NSVC being smart and appropriately grabbing a file with the desired name. Offhand, I believe this is documented to be supported on iOS, but no such documentation or feature exists on OS X. I've (accidentally) experienced it picking a nib automatically on OS X, but it was always picking the wrong nib. -- Seth Willits ___ 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
VCs in the Responder Chain - Again, but with a good solution?
This is one of those topics I thought about 6 years ago, came across a decent
easy-to-use solution that has worked fine so I've never really had to think
about it again. Until today. skip long story
All the way back to when NSViewController was added it was clear that the VC
ideally should follow its view within the responder chain, and every once in a
while I see someone else's one off little hack, or
use-multiple-subclasses-and-call-some-code solution to put the VC next to the
view in the chain, but they're all overly complicated so I noodled on a new
idea.
In this solution, all you need to do is have the view controllers you want to
be in the chain, descend from an NSViewController subclass. That's it. And the
implementation is really quite simple. The end result is each view's VC is the
view's nextResponder, and the VC's next responder is the view's superview. So
it just inserts itself in there nicely.
The only possibility where I can see this being an issue is if something
_requires_ the view's nextResponder be its superview. Anybody know of a case
where that's what's required? I hope not because this is by far the easiest
solution I've seen (though it's quite possible someone's already done exactly
this).
I'm optimistic, but braced for a bubble burst.
static int AGChainedViewControllerKVOContext;
@implementation AGChainedViewController
{
// Need to avoid circular loadView/setView: nonsense,
// so we're just keeping around our own ref in parallel.
NSView * _theView;
}
- (void)dealloc;
{
if (_theView) {
[_theView removeObserver:self forKeyPath:@nextResponder
context:AGChainedViewControllerKVOContext];
_theView.nextResponder = nil;
[_theView release];
_theView = nil;
}
[super dealloc];
}
- (void)setView:(NSView *)view;
{
if (_theView) {
[_theView removeObserver:self forKeyPath:@nextResponder
context:AGChainedViewControllerKVOContext];
[_theView release];
_theView.nextResponder = nil;
_theView = nil;
}
[super setView:view];
if (self.view) {
_theView = [self.view retain];
[_theView addObserver:self forKeyPath:@nextResponder
options:0 context:AGChainedViewControllerKVOContext];
}
}
- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object
change:(NSDictionary *)change context:(void *)context;
{
if (context == AGChainedViewControllerKVOContext) {
if ((object == _theView) [keyPath isEqual:@nextResponder])
{
if (_theView.nextResponder) {
if (_theView.nextResponder != self) {
self.nextResponder =
_theView.nextResponder;
_theView.nextResponder = self;
}
} else {
self.nextResponder = nil;
}
return;
}
}
[super observeValueForKeyPath:keyPath ofObject:object change:change
context:context];
}
@end
--
Seth Willits
___
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: Layer needs display if presentation layer moves?
It was an endless series of compounding errors yesterday for some reason, but I finally managed to get it to work. In retrospect it is easy, but not easily discoverable. Here's the finished demo project: http://www.sethwillits.com/temp/CATest_PresentationLayerTracking.zip In this project a bunch of boxes fly around when you click on the view. Each box has a line drawn from the view's origin to the box's lower left corner, and the tricky part: those lines appropriately follow the boxes while they're animating. I'll try to briefly describe this for posterity: There's a ConnectionsLayer instance which has a nodeLayers property which is an array of all the of boxes' layers. On mouseDown in the view, each box's layer is randomly positioned, and then noteNodePositionsChanged is called on the connections layer. The ConnectionsLayer's drawInContext simply draws a line from the origin to the .position of the presentationLayer of each layer in nodeLayers. (The presentationLayer may be nil, so if it is, use the model layer's position.) Now the tricky part is this: - ConnectionsLayer has a private property: @property int nodePositionsDidChange; - +needsDisplayForKey: returns YES for nodePositionsDidChange (calls super for anything else) - noteNodePositionsChanged calls: [self addAnimation:[CABasicAnimation animationWithKeyPath:@nodePositionsDidChange] forKey:@animateForNodePositionsChange]; The nodePositionsDidChange property itself is never set or get. It's simply there so that we can animate it, and Core Animation will recognize (via +needsDisplayForKey :) that while this property is animating, the layer should be redisplayed. Boom. (It's a bit voodoo that it can animate even though the value doesn't change at all, but there you go.) The only negative part to this approach is that even if none of the boxes change positions, if noteNodePositionsChanged is called then it will redraw many times for whatever the duration of the animation is. So for efficiency's sake, noteNodePositionsChanged should only be called if a box's position actually did change. Ideally, we wouldn't need to call noteNodePositionsChanged manually at all. Hopefully that helps anyone else looking for this in the future. -- Seth Willits ___ 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
Layer needs display if presentation layer moves?
I have several box-shaped layers and while any of them is moving (position or bounds is changing), I need this one other shared connections layer (which draws lines between certain boxes) to continuously redraw, so it's drawing the lines between the box layers' presentation layers so it animates nicely. So simply: Each time layer A's presentation layer moves, I need to redraw layer B. Ideas? I'm fumbling my way through one and it feels awkward. -- Seth Willits ___ 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: Layer needs display if presentation layer moves?
On Jan 28, 2014, at 5:26 PM, Kyle Sluder k...@ksluder.com wrote: The most straightforward way to do this is probably going to be creating a custom CAAnimation that drives the position of the views which are moving around, as well as a property of the connections layer that encodes the positions between which lines should be drawn. The connections layer can return YES for +needsDisplayForKey: for that line endpoints key. Ok, well I think that's roughly what I'm fumbling my way through. To me there's nothing straightforward about it, though. Maybe I'm being dense, but it's just… not working. I'll spare the long explanation of failures. Here's a simple project: http://www.sethwillits.com/temp/CATest.zip Click on the view and it moves the red square. While the square is moving, the goal is to have second layer continuously update so the line spins. If you have the time and can demonstrate the approach you've described I'd be very grateful. I've been at this for hours. Still trying… -- Seth Willits ___ 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: CGCMSUtilsGetICCProfileDescription is obsolote
On Jan 27, 2014, at 2:53 PM, Tamas Nagy tamas.lov.n...@gmail.com wrote: Well, I never call that method directly, and have no idea what is that function. This probably triggered in a library I am using, but I cannot find where is the problem, since I cannot find a way to reproduce that weird loggings all the time… weird. Do you have any ideas? Stick a breakpoint on it. -- Seth Willits ___ 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: Set up an editable view based NSTableView programmatically - how to?
To clarify: this isn't mixing approaches. Willeke isn't using any datasource
methods at all.
tableView:viewForTableColumn:row: is a delegate method. The *only* datasource
method view-based table views support is the objectValue getter, which simply
sets the objectValue property on the view returned by the delegate method, if
that view has one. That's it. It's the same as assigning
tableCellView.objectValue in that delegate method yourself.
--
Seth Willits
On Jan 7, 2014, at 4:17 PM, Peter magn...@web.de wrote:
Great! Yes, this helps immensely. Thank you very much!
It didn’t occur to me that it is possible to mix the bindings and data source
approaches.
In order not to waste more time and get my job done, I took resort to a
double click method copying the data to be edited to an NSTextField, whose
action methods feeds the edited value back into the data source. Works very
nicely and fits my bill even better than inline editing.
Still, your proof of concept is extremely useful!
Am 08.01.2014 um 01:01 schrieb Willeke willeke2...@gmail.com:
Op 7 jan 2014, om 16:52 heeft Peter het volgende geschreven:
I’d actually prefer to use bindings, but my first column should simply
display the row numbers
After some experimenting I managed to create a simple editable view based
table view with row numbers, using bindings except for the row number. The
row number is in a column with identifier RowNumber. I implemented this
delegate method:
- (NSView *)tableView:(NSTableView *)tableView
viewForTableColumn:(NSTableColumn *)tableColumn
row:(NSInteger)row
{
NSTableCellView *result = [tableView
makeViewWithIdentifier:[tableColumn identifier] owner:self];
if ([[tableColumn identifier] isEqualToString:@RowNumber])
result.textField.objectValue = [NSNumber numberWithInteger:row];
return result;
}
___
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: Best Practices for Code Organization
On Dec 27, 2013, at 8:19 AM, Alex Hall mehg...@gmail.com wrote: So, that's the general idea. Now, how do you all suggest this be organized? Much of it is inter-related, which is where I am unsure. There are 1000 ways to skin a cat. To me you've already demonstrated that you know enough about separating concerns that the other details really don't matter as much as actually finishing it. Game programming is a lot messier than application development because it's not at clear cut what belongs where. Everybody has their own opinions. As long as you keep the main systems as general as possible, the rest _can_ be ugly and still be fine. That said… Take, for example, the player pressing up arrow to step forward. 1. Up arrow is pressed, and is detected by the Map object's keyUp method. I assume this is a mistake? The keyUp will happen in your view, which generally (other than drawing) will do nothing but hand it off to something else. Consider that your menus will use the Up arrow to do one thing, while the game will use it to do another. The game may use the spacebar but the menu won't. For some inputs, you only care about whether or not it was pressed this frame, (ie the jump key was pressed, so jump and the player can't jump again until the key is released and pressed again); Others, you will want to know how long it's being held and when it's released. You may also want multiple keys to perform the same action. One strategy you can employ is to create an input mapping object which says these certain inputs from these devices are for this particular InputID. The InputID is your game-specific action, (jump, fire, whatever). The input map keeps track of the state of those inputs — when it was pressed, if it's still pressed, was it pressed *this frame* or not, etc, and can be queried by anything that needs to know the current state of the player's input. Since different parts of the game will require the same keys to mean different things (ie menus vs in-game), there will be one active input map at any point. The view would simply (through some call chain perhaps) tell the current input map to activate (mouse/keyDown) or deactivate (mouse/keyUp) a given input. Your game loop can simply check the state of the inputs to know what to do. As I said, this is one strategy. Some people like an event-based approach, so your input map could call a selector on an object instead but I'm not sold on it. Also note that you usually don't want to run code *immediately* when the key is pressed. You want to run the code at the right time during the frame update because the timing and ordering of certain this is important. So, how do you all recommend this be organized? Should the GameController be god and know about everything? Any way you can make it work, do that. ;-) The GC knows about all the objects in the world and should move those objects, checking for collisions, resolve them, and fire any callbacks for those collisions and triggers entered. When the player collides with something, a callback can be fired passing in the two objects that collided, and the callback can sort out what to do about it. If one object is the player perhaps you call a more specialized player-specific handling method. If the other object is the wall, play the sound, which means calling a method on the AL controller. Since the player hit a wall, the player is also no longer moving, so you could tell the player to stop. After the GC has done all of the object movement, then you can do everything else. A common way to do this is to call update: on every object passing in (or otherwise making available) the time that has elapsed since the last update. In the player's update method you can have it check the inputs, and handle them. Check whether the footsteps should be played etc. If Fire was newly pressed this frame, then call the method which fires the weapon. Etc... Just get a general wishy-washy idea and start writing code and move it around as needed. There really is no wrong way. Don't attempt to adhere to MVC — it will fry your brain. Games are not applications and trying to make them fit is really awkward and inconvenient. (Been there done that.) The most important thing when creating your first game is to *actually create the game*. Forget about how you're doing it, and just get it done. When you start the second one you'll have a better idea of what to do differently. Hope that helps, Also: http://www.idevgames.com/forums You'll probably get much more help there than here. -- Seth Willits ___ 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
Re: NSArray firstObject?
On Dec 22, 2013, at 9:31 AM, Trygve Inda cocoa...@xericdesign.com wrote: Available in OS X v10.6 and later. This seems to be an error in the docs as the method does not seem to exist for me. What do you mean? As I recall, when it was announced at WWDC the method become public only recently, but they explicitly said it was actually implemented since 10.6. So you can safely use it as the docs mention. If you're not using the latest SDK(s) with the API change in it, then you'll simply need to declare the method yourself in a category and it'll work fine. -- Seth Willits ___ 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
CALayer's delegate prevents implicit animation?
Short version: In 10.9 only: My CALayer's delegate doesn't implement **any** delegate methods, but because a delegate is set, the layer's position will not implicitly animate. If I don't set it, it works fine. Longer version: I have a view hosting a very plain root layer, and then this layer in question as a sublayer of that root layer. rootLayer = [[CALayer alloc] init]; self.layer = rootLayer; self.wantsLayer = YES; rootLayer.frame / bounds / delegate = ...; sublayer = [[CALayer alloc] init]; sublayer.frame / bounds = ...; sublayer.delegate = self; Later on I simply move it... [CATransaction begin]; [CATransaction setAnimationDuration:1.0]; [CATransaction setAnimationTimingFunction:[CAMediaTimingFunction functionWithName:kCAMediaTimingFunctionEaseInEaseOut]]; sublayer.position = newPosition; [CATransaction commit]; ... and it's not animating. I have narrowed it down to the delegate being non-nil, even if the delegate implements none of the delegate methods. If I don't set it, it works fine. This was working fine for yeeears and now in 10.9 it's behaving differently. What could possibly be happening? -- Seth Willits ___ 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: CALayer's delegate prevents implicit animation?
Oooo… Yeah, it's an NSView which I imagine is the problem. Documenting this behavior would be very useful. My entire app is one view, with zillions of layers in it, so I have the view as the master coordinator for everything. Since it knows about various views and their layout relationships, I set it as the delegate for a few layers because of the access it already has to needed info. It's easy enough to work around this case though. -- Seth Willits On Dec 18, 2013, at 11:13 AM, David Duncan david.dun...@apple.com wrote: What is the identify of your delegate? On Dec 18, 2013, at 10:51 AM, Seth Willits sli...@araelium.com wrote: Short version: In 10.9 only: My CALayer's delegate doesn't implement **any** delegate methods, but because a delegate is set, the layer's position will not implicitly animate. If I don't set it, it works fine. ___ 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: Adding helper app to sandboxed Cocoa app
On Dec 18, 2013, at 3:33 PM, Todd Heberlein todd_heberl...@mac.com wrote: I am having troubles with the Archive step for a Cocoa program containing a command line helper app. The archive keeps coming up with Generic Xcode Archive, and clicking Validate generates the message: “combo6” does not contain a single–bundle application or contains multiple products. Please select another archive, or adjust your scheme to create a single–bundle application. ... Let's see if I can remember this correctly off the top of my head… Turn on Skip Installation in the tool's build settings. I think that will do it. If you look in the archive you'll see that there's an extra copy because it stuck in the installation path (within the archive) which messes everything up. -- Seth Willits ___ 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: Adding helper app to sandboxed Cocoa app
On Dec 18, 2013, at 4:38 PM, Todd Heberlein todd_heberl...@mac.com wrote: Turn on Skip Installation in the tool's build settings. I think that will do it. If you look in the archive you'll see that there's an extra copy because it stuck in the installation path (within the archive) which messes everything up. No, that didn’t help :-\. (I think that is only for libraries, not executables). I'm positive the same goes for the helpers. I can easily repeat this and setting Skip Install to YES on the tool's target works as expected. Look inside the archive itself at the file hierarchy and what is in there. Inside of the Products directory, the only thing in the subtree should be your app (nested within the install path folders). -- Seth Willits ___ 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: Best solution for game loop on OSX?
Are you *only* trying to do audio, or are you trying to render GL as well? -- Seth Willits On Dec 13, 2013, at 1:57 PM, Alex Hall mehg...@gmail.com wrote: Hello list, I am attempting to use OpenAL to move a sound source around. To do so smoothly, though, will require a loop, so I can update the position in small increments many times per second. This is essentially a game loop, so I've done much searching on implementing game loops in Objective-C. There seem to be a few schools of thought on the topic: NSTimer: it works initially, but you can't rely on it to provide smoothness or constant rates. A timer could take up to 0.1 seconds to execute, so don't rely on it. However, other sources suggest that a timer will work just fine, particularly on the more powerful OSX compared to iOS devices, and doing anything else is a waste of effort for lower FPS projects. Main loop: every NSApplication has an instance of NSRunLoop attached to it when it starts. Hook into that (the mechanics of doing this are still not clear to me) and you are good to go. However, this is more work for no additional benefit, and you need to worry more about memory usage (I have no idea if the samples I've read were using ARC or not). Separate thread: uses standard-issue while(keep_running) loop in a new thread to process the game logic and refresh the world, and you're set to go as fast as you need to. However, this introduces the usual multi-threading concerns and is far more advanced than many projects actually need. Additionally, there is concern about how fast to set the refresh rate, which is not a problem in a regular while loop but becomes a bit complex otherwise. Most people seem to agree that you should see how long the last cycle took, and update your interval accordingly. Again, this is not (yet) for iOS, so I cannot rely on iOS-specific solutions. I am also not currently doing visuals, and I am not sure which framework I will use when and if I need to begin doing so, so I'd rather have my loop not rely on any visual framework. The bottom line seems to be that timers are easiest but not reliable, yet some people insist they will work well enough. So, what are your thoughts on the best way to make a game loop for OSX? While I would like to port this project to iOS in the future, I'd like a solution that will work on both platforms, and the Mac first. Given that my program is mostly based in sound, would timers be okay? Should I look into hooking into the NSRunLoop somehow instead? I'd really rather not go multi-threaded yet, but if I have to, I have to. Thanks for your opinions. Have a great day, Alex (msg sent from Mac Mini) mehg...@gmail.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/slists%40araelium.com This email sent to sli...@araelium.com -- Seth Willits ___ 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: Best solution for game loop on OSX?
On Dec 16, 2013, at 3:21 PM, Alex Hall mehg...@gmail.com wrote: I went ahead and used timers, just to get things off the ground. Many people seem to dislike them, but they work for me, for now anyway. It's really helpful to know about CVDisplayLink, though, if I ever implement graphics or need a more strict timing solution. This subject line is really misleading. Having no graphics at all makes a big difference. You would not implement a solution to your problem as you would the best way for a game, and the solution you need depends on your actual requirements. update the position in small increments many times per second — What does many mean to you? What level of accuracy do you need? How should this interact with the main thread, etc? -- Seth Willits ___ 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: Threaded drawing
On Dec 10, 2013, at 2:47 AM, Kevin Meaney k...@yvs.eu.com wrote: I'm probably teaching my grandmother to suck eggs by suggesting this. Have you looked at using CGLayers? They're extremely heavy. You definitely don't want them around if performance is a consideration. -- Seth Willits ___ 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: Threaded drawing
On Dec 10, 2013, at 1:32 AM, Graham Cox graham@bigpond.com wrote: Which is another reason to seriously consider CATiledLayer I”ll consider it, and revisit it… But my situation is that I need to draw VECTOR objects up to 25,000% zoom with no pixelization. You're given a CGContext to draw into; What's the difference? The tiled drawing is async, so if the drawing doesn't occur fast enough it'll scale up the low-scale bitmap, but what's evil about that? It's like Apple or Google maps. The other problem is that CA.. anything must live in a view. My vector data model doesn’t really care about views. The same model can be rendered into multiple views if you want. Ok, two things: 1) I don't think anyone (so far) suggesting that you use CATiledLayer was also suggesting you switch *everything* over to layers. Just use a single (tiling) layer and draw into the CGContext you're handed. CATiledLayer simply does what you're trying to do: section the visible area into tiles and draw them in parallel. The idea is that by using it you push drawing commands into the ether which may end up being drawn on the GPU via QE (I don't know that anyone said that, but it's something that occurred to me, I'm just not sure on how that's done internally), but more directly, by using CATiledLayer you don't have to handle the tiling and threading yourself, and it avoids the final blit of your buffer into the view because you're (presumably) drawing directly into the layer backing. 2) Even if you *were* going to make everything a layer, you don't need to intermingle your models and layers in the same hierarchy. The layers can become their own hierarchy and you can traverse, inspect, and manipulate them in the same way you would your model hierarchy (with the addition of some helpful methods of your own). You can also add any arbitrary k/v pairs to a layer, which gives you convenient property/reference storage. It's certainly not trivial, but when you get it all setup it's not bad. -- Seth Willits ___ 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: Threaded drawing
I think I’ve explored this as far as I can go. Here’s my wrap-up, for what it’s worth to anyone. Not a lot, I expect. The conclusion is, I don’t think it can be done with the current graphics APIs with any worthwhile performance. Here’s my summary of why that is… … This last step is where it all falls down, because this one call, to CGContextDrawImage, takes a whopping 67% of the overall time for drawRect: to run, and normal drawing doesn’t need this call (this is testing in a ‘light’ view, but nevertheless, it makes the view very noticeably laggy). If all the drawRect is doing is making a single call to CGContextDrawImage then it should rightly be 100% of the time, so that measure isn’t interesting on its own. :) 1. Make one big bitmap instead and create a context for each tile... Even if this worked, it would still require an image draw, but at least it would be just one, not one per tile. You must be passing in incorrect values. It will work. I’ve done this before and I just tested it now and I’m not getting any assertions like you are. If your backing is 1600 x 800, and you want a context for the left half and another for the right half both have bytesPerRow values of 1600 * 4, a width of 800, and heigh of 800. The only thing that is different is the buffer offset. The first one is at 0 and the second at 800 * 4. It may feel odd because the second context specifies that the last row is 1600 * 4 bytes wide, but thanks to initial offset and real buffer size is only 800 * 4 wide, but CG won't try to read or write to those bytes in rows that are after width * bytesPerPixel, so it really is safe. The single CGContextDrawImage in drawRect: should end up essentially being a memcpy which will be ridiculously fast, as long as your contexts/backing all use the same color space and bitmap layout as the view’s context’s backing. Definitely make sure they’re using the same color space because converting is really slow. And as a general note separate to the threading, are you sure you can’t cache individual objects’ images? (And this just gets into trying to replicate layers, really, though, and with or without layers you’d have a memory usage concern to analyze.) -- Seth Willits ___ 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: Threaded drawing
The single CGContextDrawImage in drawRect: should end up essentially being a memcpy which will be ridiculously fast, as long as your contexts/backing all use the same color space and bitmap layout as the view’s context’s backing. Definitely make sure they’re using the same color space because converting is really slow. But how can you do that? There’s no CGContextGetColorspace function, except for a bitmap context, and the context that’s current when drawRect: is entered does not seem to be a bitmap context. I would have expected it to be, but it returns nil for all of the CGBitmapContextxxx functions, so my assumption is it’s a private variant. Same goes for the format, even if it has one. I’m using the genericRGB colourspace and premultiplied alpha first for my own contexts. Offhand I couldn’t tell you. The main thing is to look at the profile and inspect what’s happening within the draw call. It’ll be obvious if it’s doing colorspace conversion. Just thinking out loud: There’s NSView’s bitmapImageRepForCachingDisplayInRect: and you can grab a colorspace from the rep. I would certainly imagine that has the ideal space and you can confirm it’s one or another. You can use that method to create your presumably ideal backing and then create multiple contexts that share the same buffer as that original bitmap rep on your background threads. I can’t say whether it’s better or not, but it’s something that comes to mind. (CATiledLayer still sounds like a good idea to me as well.) -- Seth Willits ___ 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: Video bit rate
On Dec 9, 2013, at 2:27 AM, Damien Cooke dam...@smartphonedev.com wrote: I am taking video on in my iPhone app at 1280x720 this turns out at about 40Mb/min What I want is to drop the bit rate not the size using AVAssetWriter/AVAssetReader, is this possible or even the right way of doing this? Yes. You can specify the bit rate and profile to use when writing. -- Seth Willits ___ 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: OS X : Different icon for Status Item
On Dec 7, 2013, at 8:47 PM, Jerry Krinock je...@ieee.org wrote: How can I make my app’s Status Item (“menulet, right side of menu bar) have a different icon than its icon shown in the Dock and Finder? I cannot find any mention of this in “Status Item Programming Topics”, and tests indicate that it simply uses the same .icns resource indicated by CFBundleIconFile in Info.plist. But I’ve seen other non-Apple apps do it, so apparently it can be done. Uhh… setImage: ? -- Seth Willits ___ 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: Threaded drawing
On Dec 6, 2013, at 8:05 AM, dangerwillrobinsondan...@gmail.com wrote:
On 6 Dec 2013, at 11:26 am, Graham Cox graham@bigpond.com wrote:
NSBlockOperation* op = [NSBlockOperation
blockOperationWithBlock:^
{
CGContextClipToRect( ncx, tileRect );
[self drawTile:tileRect inContext:ncx];
}];
A question for blocks experts:
Is the value of tileRect here captured when the block is created,or when
it is run?
If the latter, it’s going to be probably wrong most of the time, so how can
I make sure it is captured when the block is created?
It's the latter IIRC
You'll want to capture it outside and prefix it to be block scoped.
No it’s not and no you don’t.
int x = 3;
void (^block)(void) = ^{ NSLog(@%d, x); };
x = 5;
block();
The result is 3 not 5.
--
Seth Willits
___
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: NSTableCellView for view-based outline view
On Nov 19, 2013, at 8:42 PM, Quincey Morris
quinceymor...@rivergatesoftware.com wrote:
Here’s something puzzling, unless I’m missing the obvious:
I’m intending to convert an outline view in an existing xib file from
cell-based to view-based. In preparation, I added the requisite delegate
method to the view controller:
- (NSView*) outlineView: (NSOutlineView*) outlineView viewForTableColumn:
(NSTableColumn*) column item: (id) item {
if (!item || !column)
return nil;
NSTableCellView* view = [outlineView makeViewWithIdentifier:
column.identifier owner: self];
if (!view)
return nil;
return view;
}
without changing the outline view itself. Somewhat to my surprise, this
delegate method *was* called for the outline view, and had the effect of
causing all of the cells to display no value. I repeat: the outline view was
still cell-based at this stage.
There’s no setting need to make it cell or view-based. It’s determined simply
by what delegate methods are implemented. It must simply be checking for
view-based methods before cell-based. Nothing special.
OK, ignoring that and moving on, I deleted the old outline view, added a new
one, and set it to “view-based”. Now, I find that the result of creating the
cell view in the delegate method:
NSTableCellView* view = [outlineView makeViewWithIdentifier:
column.identifier owner: self];
isn’t a NSTableCellView at all:
(lldb) po view
NSView: 0x60323b60
(lldb) po [view class]
NSView
(lldb) po [view objectValue]
error: Execution was interrupted, reason: Attempted to dereference an
invalid ObjC Object or send it an unrecognized selector.
The process has been returned to the state before expression evaluation.
That’s weird problem #2. The table cell view item in IB has the default class
(“NSTableCellView” in gray) in the inspector, but the outline view is not
creating a cell view of that class. Huh? The consequence is that I can’t get
a value into the text field of the cell view.
Did you set up the cell's identifier?
--
Seth Willits
___
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: NSTableView drag drop string
On Nov 20, 2013, at 10:00 AM, Todd Heberlein todd_heberl...@mac.com wrote:
I’m trying a very simple test (I just want the string “foo” to be dropped in
an email message) that I cannot seem to make work. What am I missing?
(setString:forType: is returning YES)
- (BOOL)tableView:(NSTableView *)tv
writeRowsWithIndexes:(NSIndexSet *)rowIndexes
toPasteboard:(NSPasteboard *)pboard;
{
[pboard declareTypes: [NSArray arrayWithObject: NSPasteboardTypeString]
owner: self];
if ([pboard setString: @foo forType: NSPasteboardTypeString] == YES) {
NSLog(@setString worked);
return YES;
}
return NO;
}
You’re putting it in the dragging pasteboard instead of the general pasteboard.
--
Seth Willits
___
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: toolbar icons and images
On Nov 11, 2013, at 4:44 PM, Maxthon Chan xcvi...@me.com wrote: What I stumbled upon is that you should use vector images in PDF format and the system will scale it for you. Can, may, but not “should.” Lines that are supposed to be one point wide cannot remain one point wide when the art is scaled. For a lot of images that’s unacceptable, so the best thing to do is still to create a bunch of bitmap representations at the necessary sizes and use the correct one at draw-time. For example, create an .iconset with your bitmaps which then gets turned into an .icns by Xcode for you. -- Seth Willits ___ 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: Getting mouse clicks when the main loop is busy
On Nov 10, 2013, at 1:14 PM, Kyle Sluder k...@ksluder.com wrote: On Nov 10, 2013, at 1:06 PM, Charles Srstka cocoa...@charlessoft.com wrote: What I usually do is just have NSDocument's readFromData/URL/fileWrapper/etc method not actually do much, and then in windowControllerDidLoadNib: put up a progress bar, and start the loading in a background thread. You can either do this by hiding the main window and displaying the progress bar in a separate window, or by showing the empty document window and putting up a sheet with the progress bar in it while the document window is populated with data. This sounds like a violation of file coordination and NSDocument file-activity rules. You really ought to load your document contents in the initializer. *initializer*? -- Seth Willits ___ 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: Codesigning 3rd party framework
When you use —deep, all signing options you specify [on the app bundle] will apply, in turn, to such nested content [as embedded frameworks, helpers, resources, etc]” which is not the correct thing that should happen. https://devforums.apple.com/thread/203126?start=0tstart=0 -- Seth Willits On Nov 5, 2013, at 3:39 AM, Jakob Egger ja...@eggerapps.at wrote: Does anybody know why just specifying --deep in Other Code Signing Flags is wrong? Is it only a problem with Sparkle, or is there a general problem? In my app I just specified --deep and it seems to work! On 29 Oct 2013, at 10:37 pm, Shazron shaz...@gmail.com wrote: See http://furbo.org/2013/10/17/code-signing-and-mavericks/ he specifically deals with your Sparkle.framework problem On Tue, Oct 29, 2013 at 5:30 PM, Graham Cox graham@bigpond.com wrote: Having just updated to Xcode 5.0.1, I can’t build one of our apps because it uses the Sparkle framework, which isn’t codesigned. Previously this wasn’t an issue but it seems Xcode is being a bit stricter than before. Is there a way I can codesign this module using my own credentials? I have little experience of dealing with these issues, most of the time I just hope it works and it does, but now it doesn’t I’m in a very tight spot. - I can’t easily downgrade to the older Xcode and I need this app built by tomorrow! -- Seth Willits ___ 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: NSDocument and KVO compliance
On Oct 21, 2013, at 3:58 AM, jonat...@mugginsoft.com wrote: Yes. You need to keep your wits about you with this sort of thing. I gag a little whenever I remember that's how it works, but at this point it ain't broke so I'm not going to tempt fate by fixing it. ;-) What would you suggest as a possible fix? If I remember correctly off the top of my head: In my case, I have foo watching for changes to properties on self.bar — ie self.bar.propertyXYZ. The bindings all go through an object controller whose content is bound to foo's .bar. So all changes to any properties on bar, pass through foo's setValue:forKeyPath:. This allowed me to override setValue:forKeyPath: in *foo* to watch for changes to *bar*. So other than the above, I could either change the implementation of bar to send an NSNotification or delegate method, or register for and watch all property paths via KVO. A notification is a reasonable idea, a delegate method often makes no sense, and I would say registering with KVO to be the best option (though anti-KVOists would disagree) and I do it fairly often in various places in my various apps. Using a known fixed array of key paths, the registration and unregistration becomes very small loops, and handling in observeValue… looks for the key path in the array and handles all properties the same. (I recall there being something subtle and tricky which makes this alternative non-trivial for my setValue:forKeyPath: override case.) -- Seth Willits ___ 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: Deadlock during NSCache flush
On Oct 21, 2013, at 12:28 PM, Ken Thomases wrote: Seems like a cycle to me. … Have the documents hold weak references to the database. Agreed. What reason is there for the documents to have a strong reference to the database? -- Seth Willits ___ 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: NSDocument and KVO compliance
On Oct 19, 2013, at 9:27 AM, Jerry Krinock wrote:
I don't know if this is a common technique but I use it regularly to track
binding changes.
- (void)setValue:(id)value forKeyPath:(NSString *)keyPath
{
// all bindings that reference self (such as self.representedObject.xxx)
// will pass through this method
if ([keyPath rangeOfString:@self.representedObject.].location !=
NSNotFound) {
[self.document updateChangeCount:NSChangeDone];
}
[super setValue:value forKeyPath:keyPath];
}
That's interesting and I've never seen it done.
I'd call it a variation of writing custom accessors for each attribute.
Custom accessors for each attribute have the advantage of reliably catching
all model changes, not just those driven by Cocoa Bindings. But your
technique is way less code, by a factor of the number of attributes, and
requires zero maintenance.
I've done it / do it in one particular project in one spot out of notable
convenience. It works, but only for modifications using KVC, and I do recall
having at least one bug where a modification wasn't using KVC and wasn't
triggering the code I was expecting it to.
I gag a little whenever I remember that's how it works, but at this point it
ain't broke so I'm not going to tempt fate by fixing it. ;-)
--
Seth Willits
___
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: NSDocument and KVO compliance
On Oct 18, 2013, at 11:41 AM, jonat...@mugginsoft.com wrote: Twice recently I have found myself tinkering with NSDocument et al to support observing of certain values. For example, NSDocument -isDocumentEdited is not seemingly KVO compliant. -isDocumentEdited status is driven by -updateChangeCount: so ... Is this the best way to go about addressing these sorts of issues with regard to missing KVO compliance? Well, the best thing to do is file a radar and wait a couple years for them to get around to adding it. :( That said, it would probably mostly work, but it's not always guaranteed to be bulletproof because those keys could also be influenced by private methods. -- Seth Willits ___ 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
