Re: Resizable borderless windows in Lion
Problem with Xcode 4 is that this is the same build farm that compiles out standalone executable which has compatibility down to Tiger, so we're stuck on Xcode 3.x versions (at least for the next 8 months or so). Superannoying, but that's what we get for making a dev tool that will target ancient systems. Essentially, Unity is an Editor (that requires Leopard, Intel only) which we ship with a bunch of runtimes (OSX, iOS, Win, Android (ARM/Intel, etc), PS3, XBox, Flash binary, etc.). People use the Unity editor to build a data file that these binaries know how to run. The Editor could be compiled with a later compiler, but we need our runtimes to target ancient systems as well (when to up the requirements of any version is a long debate; we're just now dropping PPC). The editor also has an embedded Runtime (so people can test their games). However, getting all these dependencies right means we've ended up with a very complex build system - so it's hard for us to just upgrade a single piece of the chain. Anyone have any idea how Lion checks the compiler version so I maybe can fool it? (Failing that, I'll re-implement windows resizing myself :) Thanks, Nicholas On Nov 17, 2011, at 8:04 PM, Seth Willits wrote: On Nov 17, 2011, at 10:48 AM, Mike Abdullah wrote: Reading the Lion release notes, it says I should create my window with NSBorderlessWindowMask | NSResizableWindowMask. It also says that my app needs to be compiled with Lion as a backwards-compatibility measure. I’m pretty sure that just means that it needs to be compiled with the Lion *SDK*, i.e. by Xcode 4.2. That’s available for 10.6. Seriously? SDKs are never usually backported. Would be great if they were somehow. I did some testing last week. Building with the 10.7 SDK with 4.2 on SL vs Lion, I ended up with byte-identical binaries. The only thing that was different were the compiled nibs, and I think one other thing. Not sure exactly what the differences were though, but they varied quite a bit. I didn't compare the 10.7-SDK-built-on-SL nibs to 10.6-SDK-built-on-SL nibs to see if they were 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: http://lists.apple.com/mailman/options/cocoa-dev/nicholas%40unity3d.com This email sent to nicho...@unity3d.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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: AXUIElementPostKeyboardEvent - not sending key presses to Safari/TextEdit in Lion
On Nov 16, 2011, at 1:51 PM, Patrick Robertson wrote: AXUIElementPostKeyboardEvent (app, (CGCharCode) 0, (CGKeyCode)55, true ); //Command AXUIElementPostKeyboardEvent (app, (CGCharCode) 0, (CGKeyCode)53, true ); //Escape AXUIElementPostKeyboardEvent (app, (CGCharCode) 0, (CGKeyCode)53, false ); //Escape AXUIElementPostKeyboardEvent (app, (CGCharCode) 0, (CGKeyCode)55, true ); //Command In the last step you should have passed false instead of true, to let the command key up. -- Bill Cheeseman - b...@cheeseman.name ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Resizable borderless windows in Lion
Le 18 nov. 2011 à 10:59, Nicholas Francis a écrit : Problem with Xcode 4 is that this is the same build farm that compiles out standalone executable which has compatibility down to Tiger, so we're stuck on Xcode 3.x versions (at least for the next 8 months or so). Superannoying, but that's what we get for making a dev tool that will target ancient systems. Essentially, Unity is an Editor (that requires Leopard, Intel only) which we ship with a bunch of runtimes (OSX, iOS, Win, Android (ARM/Intel, etc), PS3, XBox, Flash binary, etc.). People use the Unity editor to build a data file that these binaries know how to run. The Editor could be compiled with a later compiler, but we need our runtimes to target ancient systems as well (when to up the requirements of any version is a long debate; we're just now dropping PPC). The editor also has an embedded Runtime (so people can test their games). However, getting all these dependencies right means we've ended up with a very complex build system - so it's hard for us to just upgrade a single piece of the chain. Anyone have any idea how Lion checks the compiler version so I maybe can fool it? http://www.mulle-kybernetik.com/weblog/2009/04/_nsi3_cfexecutablelinkedonoraf.html (Failing that, I'll re-implement windows resizing myself :) Thanks, Nicholas -- Jean-Daniel ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Resizable borderless windows in Lion
Le 18 nov. 2011 à 11:59, Jean-Daniel Dupas a écrit : Le 18 nov. 2011 à 10:59, Nicholas Francis a écrit : Problem with Xcode 4 is that this is the same build farm that compiles out standalone executable which has compatibility down to Tiger, so we're stuck on Xcode 3.x versions (at least for the next 8 months or so). Superannoying, but that's what we get for making a dev tool that will target ancient systems. Essentially, Unity is an Editor (that requires Leopard, Intel only) which we ship with a bunch of runtimes (OSX, iOS, Win, Android (ARM/Intel, etc), PS3, XBox, Flash binary, etc.). People use the Unity editor to build a data file that these binaries know how to run. The Editor could be compiled with a later compiler, but we need our runtimes to target ancient systems as well (when to up the requirements of any version is a long debate; we're just now dropping PPC). The editor also has an embedded Runtime (so people can test their games). However, getting all these dependencies right means we've ended up with a very complex build system - so it's hard for us to just upgrade a single piece of the chain. Anyone have any idea how Lion checks the compiler version so I maybe can fool it? http://www.mulle-kybernetik.com/weblog/2009/04/_nsi3_cfexecutablelinkedonoraf.html As a follow up, it look like everithing end up calling NSVersionOfLinkTimeLibrary() which is defined in the following file: http://opensource.apple.com/source/dyld/dyld-195.5/src/dyldAPIsInLibSystem.cpp As you can see, this function has a major flaw, as it check version against the executable only. A tricky way to fool the system can be to move all you application code into a framework, and have a simple launcher compiled on 10.7 that just call a 'main' entry point in your framework. (Failing that, I'll re-implement windows resizing myself :) Thanks, Nicholas -- Jean-Daniel ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Text to speech
Hi All Is there in iOS 5 something like COCOA NSSpeechSynthesizer to be used to read some text on iPhone? Thanks for any answer. Luca.___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Text to speech
There is the Nuance SDK you could use. Requires Internet access though. It rocks hard. Eric Sent from my iPhone On Nov 18, 2011, at 6:47 AM, Luca Ciciriello luca_cicirie...@hotmail.com wrote: Hi All Is there in iOS 5 something like COCOA NSSpeechSynthesizer to be used to read some text on iPhone? Thanks for any answer. Luca.___ 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: http://lists.apple.com/mailman/options/cocoa-dev/edolecki%40gmail.com This email sent to edole...@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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Does NSImageBitmapRep -drawInRect:fromRect:…hints: takes hints into account?
Hi there, I’m trying to draw a flipped NSImageBitmapRep object (data comes out of an OpenGL depth buffer) in a NSView. I thought I could set up an appropriate affine transform (x’ = x, y’ = height - y), embed it in a dictionary and put that in the hints parameter of a -drawInRect:fromRect:…hints: to ask Cocoa to apply the transform before displaying the image. However, the call seems to ignore completely my transform (whatever I set it to). Is there anything escaping from my understanding, or is this expected behavior? Thanks a lot, Vincent___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Does NSImageBitmapRep -drawInRect:fromRect:…hints: takes hints into account?
PS : Of course, a workaround is to flip the view coordinates thus: [myView translateOriginToPoint:NSMakePoint(0, [self frame].size.height)]; [myView scaleUnitSquareToSize:NSMakeSize(1, -1)]; but it still does not explain why -drawInRect:fromRect:…hints: seems to ignore the hints. Vincent ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Retained Outlet
The normal pattern for Interface Builder Outlets is assign but I have an outlet that must be retained to work corectly. The outlet is not in File's Owner but is in a custom view in a window. // Interface @property (retain) IBOutlet NSArrayController *myController; // Implementation @synthesize myController = _myController The application runs fine with no memory leaks reported by Instruments so I assume that the frameworks are releasing myController. Is this ok? --Richard ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Retained Outlet
On Fri, Nov 18, 2011 at 8:23 AM, Richard Somers rsomers.li...@infowest.com wrote: The normal pattern for Interface Builder Outlets is assign but I have an outlet that must be retained to work corectly. The outlet is not in File's Owner but is in a custom view in a window. It is very important that you specify whether you're working on iOS or Mac OS X, and whether your outlet points to a top-level object. Maybe you can answer your own question by re-reading the Resource Programming Guide: http://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/LoadingResources/CocoaNibs/CocoaNibs.html#//apple_ref/doc/uid/1051i-CH4-SW18 --Kyle Sluder ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Does NSImageBitmapRep -drawInRect:fromRect:…hints: takes hints into account?
On Fri, Nov 18, 2011 at 6:18 AM, Vincent Habchi vi...@macports.org wrote: PS : Of course, a workaround is to flip the view coordinates thus: [myView translateOriginToPoint:NSMakePoint(0, [self frame].size.height)]; [myView scaleUnitSquareToSize:NSMakeSize(1, -1)]; but it still does not explain why -drawInRect:fromRect:…hints: seems to ignore the hints. Re-read the NSImage: deprecating -[NSImage setFlipped:], adding a drawing method that respects context flippedness section of the 10.6 AppKit release notes to make sure you're correctly using the flipped property and the respectFlipped: argument to -drawInRect:: : http://developer.apple.com/library/mac/#releasenotes/Cocoa/AppKitOlderNotes.html --Kyle Sluder ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Does NSImageBitmapRep -drawInRect:fromRect:…hints: takes hints into account?
Kyle, Re-read the NSImage: deprecating -[NSImage setFlipped:], adding a drawing method that respects context flippedness section of the 10.6 AppKit release notes to make sure you're correctly using the flipped property and the respectFlipped: argument to -drawInRect:: : I’ve tried respectFlipped:YES or NO, it does not change anything. Besides, NSImageBitmapRep has no ‘flipped’ property, because it does not inherit from NSImage, but from NSImageRep! Vincent ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Does NSImageBitmapRep -drawInRect:fromRect:…hints: takes hints into account?
On Fri, Nov 18, 2011 at 8:50 AM, vincent habchi vi...@macports.org wrote: Kyle, Re-read the NSImage: deprecating -[NSImage setFlipped:], adding a drawing method that respects context flippedness section of the 10.6 AppKit release notes to make sure you're correctly using the flipped property and the respectFlipped: argument to -drawInRect:: : I’ve tried respectFlipped:YES or NO, it does not change anything. Besides, NSImageBitmapRep has no ‘flipped’ property, because it does not inherit from NSImage, but from NSImageRep! Yes, that would indeed be true. I just assumed you were adding the image rep to an NSImage and using -[NSImage drawInRect::]. --Kyle Sluder ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Does NSImageBitmapRep -drawInRect:fromRect:…hints: takes hints into account?
Le 18 nov. 2011 à 19:45, Kyle Sluder a écrit : Yes, that would indeed be true. I just assumed you were adding the image rep to an NSImage and using -[NSImage drawInRect::]. I considered that for a while, but since -drawInRect exists for NSBitmapImageRep, I thought it was useless. Besides, it seems the compositing operation in -[NSBitmapImageRep drawInRect:] does not work either or at least not in the intended way. Go figure. Thanks for your help Kyle. Vincent___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Retained Outlet
On Nov 18, 2011, at 9:31 AM, Kyle Sluder wrote: On Fri, Nov 18, 2011 at 8:23 AM, Richard Somers wrote: The normal pattern for Interface Builder Outlets is assign but I have an outlet that must be retained to work corectly. The outlet is not in File's Owner but is in a custom view in a window. It is very important that you specify whether you're working on iOS or Mac OS X, and whether your outlet points to a top-level object. I am working on Mac OS X. The outlet points to a top-level object. Maybe you can answer your own question by re-reading the Resource Programming Guide: In general, you are responsible for releasing top-level objects in a nib file. But my File's Owner is an instance of NSWindowController so it will release top-level objects for me. The outlet in question is in a custom class and requires a setter with retain semantics. NSWindowController will use this setter for the outlet when loading the nib. Object ownership policy seems a little blurry here. Normally a class will initialize its ivars and then cleanup in dealloc. But the custom class never initializes the outlet. The nib loading machinery initialize the outlet. So that may mean NSWindowController knows that the outlet has retain semantics and will set the outlet to nil when releasing top-level objects. If not then the class should release the outlet in its dealloc method. I am confused, which one is it? Maybe I am looking at this wrong. If a class, any class, has an ivar with retained property semantics, it will be initialized to nil even if the class does not explicitly initialize the ivar. In the class dealloc method it should directly release the ivar regardless. If the ivar points to an object, for what ever reason, it will receive a release message. If the ivar is nil, for what ever reason, a release message will go to nil. Either way it works. It this the correct way to look at this? --Richard ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Retained Outlet
On Fri, Nov 18, 2011 at 11:22 AM, Richard Somers rsomers.li...@infowest.com wrote: The outlet in question is in a custom class and requires a setter with retain semantics. NSWindowController will use this setter for the outlet when loading the nib. NSWindowController does not call your setter. NSNib does. Object ownership policy seems a little blurry here. Normally a class will initialize its ivars and then cleanup in dealloc. But the custom class never initializes the outlet. The nib loading machinery initialize the outlet. So that may mean NSWindowController knows that the outlet has retain semantics and will set the outlet to nil when releasing top-level objects. If not then the class should release the outlet in its dealloc method. I am confused, which one is it? It means that NSWindowController will balance NSNib's extra -retain. It doesn't balance the additional -retain from calling your setter. Think about it this way: NSWindowController loads your nib using -[NSNib instantiateNibWithOwner:topLevelObjects:]. It takes responsibility for calling -release on all of the top-level objects it gets back from this method call. -instantiateNibWithOwner:topLevelObjects: does the magic of hooking up outlets; part of that magic involves calling your setters if it finds them. NSWindowController is entirely unaware of that process. --Kyle Sluder ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Retained Outlet
On Nov 18, 2011, at 12:42 PM, Kyle Sluder wrote: It means that NSWindowController will balance NSNib's extra -retain. It doesn't balance the additional -retain from calling your setter. Consider the following case. The additional -retain from calling setter is not balanced. The outlet is not released in the class dealloc method and no additional retains or releases of the object exist in my code. But Instruments shows no leaks whatsoever. So who or what is releasing the outlet? --Richard ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Retained Outlet
You are probably orphaning (which is a leak), your window controller subclass. Make sure it's dealloc is called; I'm guessing it won't be. This isn't shown in leaks, since it isn't a true leak. corbin On Nov 18, 2011, at 11:22 AM, Richard Somers wrote: On Nov 18, 2011, at 9:31 AM, Kyle Sluder wrote: On Fri, Nov 18, 2011 at 8:23 AM, Richard Somers wrote: The normal pattern for Interface Builder Outlets is assign but I have an outlet that must be retained to work corectly. The outlet is not in File's Owner but is in a custom view in a window. It is very important that you specify whether you're working on iOS or Mac OS X, and whether your outlet points to a top-level object. I am working on Mac OS X. The outlet points to a top-level object. Maybe you can answer your own question by re-reading the Resource Programming Guide: In general, you are responsible for releasing top-level objects in a nib file. But my File's Owner is an instance of NSWindowController so it will release top-level objects for me. The outlet in question is in a custom class and requires a setter with retain semantics. NSWindowController will use this setter for the outlet when loading the nib. Object ownership policy seems a little blurry here. Normally a class will initialize its ivars and then cleanup in dealloc. But the custom class never initializes the outlet. The nib loading machinery initialize the outlet. So that may mean NSWindowController knows that the outlet has retain semantics and will set the outlet to nil when releasing top-level objects. If not then the class should release the outlet in its dealloc method. I am confused, which one is it? Maybe I am looking at this wrong. If a class, any class, has an ivar with retained property semantics, it will be initialized to nil even if the class does not explicitly initialize the ivar. In the class dealloc method it should directly release the ivar regardless. If the ivar points to an object, for what ever reason, it will receive a release message. If the ivar is nil, for what ever reason, a release message will go to nil. Either way it works. It this the correct way to look at this? --Richard ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/corbind%40apple.com This email sent to corb...@apple.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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Retained Outlet
On Nov 18, 2011, at 1:33 PM, Corbin Dunn wrote: You are probably orphaning (which is a leak), your window controller subclass. Make sure it's dealloc is called; I'm guessing it won't be. This isn't shown in leaks, since it isn't a true leak. Good suggestion. I just checked and the window controller subclass dealloc method is being called. --Richard ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Cannot modify autoresizing with some iOS views
I have a Xcode 4.2 project with a dozen or so nibs. I'm in the process of assuring that all the resizing is set up properly. I find that a small number of primary views - the one attached to the view outlet - have fixed autoresizing masks, and while I can set or unset the four outter attachments, I cannot set the inner two lines. There appears to be no other difference between these views and the other ones having variable masks. Suggestions? David ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
ARC and NSNib: How to release top-level objects?
Okay, I know you’re supposed to use the likes of NSWindowController and
NSViewController to load nibs, since they will automatically take care of
releasing the top-level objects. However, for the sake of curiosity, I created
a new project with ARC just to see what would happen with NSNib. The project
contains a xib file named “Foo.xib” whose owner is Foo, and which contains a
top-level custom object of class Bar. The implementations of Foo and Bar are as
below:
@implementation Foo
- (id)init {
if(self = [super init]) {
NSLog(@Foo init);
NSNib *nib = [[NSNib alloc] initWithNibNamed:@Foo bundle:nil];
NSArray *tlo = nil;
[nib instantiateNibWithOwner:self topLevelObjects:tlo];
NSLog(@top-level objects are: %@, tlo);
}
return self;
}
- (void)dealloc {
NSLog(@Foo dealloc);
}
@end
@implementation Bar
- (id)init {
if(self = [super init]) {
NSLog(@Bar init);
}
return self;
}
- (void)dealloc {
NSLog(@Bar dealloc);
}
@end
The application delegate simply contains buttons to create and destroy (by
assigning its ivar to nil) a Foo object. Clicking on both, the output looks
like this:
2011-11-18 15:42:42.069 test[47843:707] Foo init
2011-11-18 15:42:42.075 test[47843:707] Bar init
2011-11-18 15:42:42.075 test[47843:707] top-level objects are: (
Bar: 0x100534800,
NSApplication: 0x1001353f0
)
2011-11-18 15:42:47.437 test[47843:707] Foo dealloc
Notice that Bar never gets dealloced.
How is one supposed to manage this? You can easily get the array of the
top-level objects, but since ARC doesn’t let you send -release to them, it
doesn’t help much. The only ways I can think of to avoid leaking are to do
silly things like performSelector:NSSelectorFromString(@“release”) or to wrap
the NSNib-using code in a non-ARC source file. Neither seems ideal.
What’s the best way to deal with something like this?
Charles___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: ARC and NSNib: How to release top-level objects?
On Fri, Nov 18, 2011 at 1:47 PM, Charles Srstka cocoa...@charlessoft.com wrote: How is one supposed to manage this? You can easily get the array of the top-level objects, but since ARC doesn’t let you send -release to them, it doesn’t help much. The only ways I can think of to avoid leaking are to do silly things like performSelector:NSSelectorFromString(@“release”) or to wrap the NSNib-using code in a non-ARC source file. Neither seems ideal. What’s the best way to deal with something like this? From the recently-revised Resource Programming Guide: If the File’s Owner is not an instance of NSWindowController or NSViewController, then you need to decrement the reference count of the top level objects yourself. With manual reference counting, it was possible to achieve this by sending top-level objects a release message. You cannot do this with ARC. Instead, you cast references to top-level objects to a Core Foundation type and use CFRelease. (If you don’t want to have outlets to all top-level objects, you can use the instantiateNibWithOwner:topLevelObjects: method of the NSNib class to get an array of a nib file’s top-level objects.) http://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/LoadingResources/CocoaNibs/CocoaNibs.html#//apple_ref/doc/uid/1051i-CH4-SW10 --Kyle Sluder ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Retained Outlet
On Nov 18, 2011, at 9:23 AM, Richard Somers wrote: The normal pattern for Interface Builder Outlets is assign but I have an outlet that must be retained to work corectly. The outlet is not in File's Owner but is in a custom view in a window. // Interface @property (retain) IBOutlet NSArrayController *myController; // Implementation @synthesize myController = _myController The application runs fine with no memory leaks reported by Instruments so I assume that the frameworks are releasing myController. SOLVED - Mac OS X Retained Outlet Thanks for everyones comments. Here is what I have learned. The frameworks will not release a retained outlet (assuming top-level objects are handled correctly). You are responsible for releasing it. A retained outlet is considered ownership and so you must release it. If you do not release it, it will be alive in memory even though Instruments may not report it as a leak. For my particular case the outlet was actually a subclass of NSArrayController. Instruments reports the responsible caller as -[NSClassSwapper initWithCoder:]. I am not an expert in leaks but it appears that a reference to the outlet is maintained by the frameworks until the outlet is fully released and so Instruments does not report it as a leak. --Richard ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
CoreData and Threading
I'm struggling a bit with multi-threading approaches for CoreData… I need to _continuously_ merge changes made in the _main_ thread into a context held by a background thread. Most (all?) discussions about multi-threading in CoreData discuss merging changes from a _finite_ operation in the _background_, a quite different situation. Situation: -- My application stores an object graph in CoreData using a persistent document. The objects are manipulated by the user in the UI. Meanwhile a background thread processes the object graph continuously to generate output. Changes made by the user should be picked up and accounted for by the background thread in a timely manner. I've adopted 'thread confinement' as prescribed by Apple: the main thread and the background thread eacht have separate contexts sharing a single persistent store. Options: There are two ways to receive updates on the background thread: 1 - Through 'NSManagedObjectContextDidSaveNotification' and subsequent change merging. However, I'd have to save the document every time the user changes the document. This would not be a good user experience, to say the least. 2 - Through 'NSManagedObjectContextObjectsDidChangeNotification' The objectIDs of the changed / inserted / deleted objects can be collected from this notification and forwarded to the background thread. According to Apple: You pass the object IDs to thread A [-- my background thread --] by sending a suitable message to an object on thread A. Upon receipt, on thread A you can refetch the corresponding managed objects. Here is where I miss information: The context of my background context isn't aware of the changes in the main thread context (there was no merge) and 'refetch the corresponding managed objects' won't work because the shared persistent store wasn't updated (there was no save operation from the main context)... At the moment I cannot find an acceptable way to merge changes from the main thread into the background thread context. Is there a solution for my use case? I could probably try to extend a solution with locking, but it will be error prone… Thanks, patrick -- Patrick Machielse Hieper Software http://www.hieper.nl i...@hieper.nl ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Intermittent scrolling problem in UITableView
Hello. I'm facing the task of fixing a problem occurring in one of the UITableView of our app. The view displays cells of various height. Everything works fine, except that we have a mechanism that when we reach the last cell at the bottom, that cell will trigger loading more data and adding more cells from the server. The problem happens when scrolling. If I reach the bottom of the table view and keep scrolling up, the table view seems to get in some kind of wacky mode. The scroll indicator is always visible and the table view loses its smoothness, e.g. when scrolling, it won't have its momentum to smoothly decelerate, it will stop scrolling as soon as the touch ends. If I scroll to the bottom and just reaches the last cell without forcing it up, then after loading about a dozen cells, it will work as expected. There isn't much special code in that UITableView subclass and not much either in the UITableViewController so I'm a little bit at a lost as to what could cause this. There is nothing fancy here, no custom handling of touches and things like that, just loading a bunch of cells and then loading more when we reach the bottom of the table view and there is more data to load. Anyone has any idea where I could look for this? Thanks in advance for any pointer! -Laurent. -- Laurent Daudelin AIM/iChat/Skype:LaurentDaudelin http://www.nemesys-soft.com/ Logiciels Nemesys Software laur...@nemesys-soft.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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Intermittent scrolling problem in UITableView (2)
I forgot to add to my previous message that the scrollview will resume its dragging momentum if I touch and drag any other view. Does that give a clue to anyone? Thanks! -Laurent. -- Laurent Daudelin AIM/iChat/Skype:LaurentDaudelin http://www.nemesys-soft.com/ Logiciels Nemesys Software laur...@nemesys-soft.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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Intermittent scrolling problem in UITableView
On 11/18/11 3:29 PM, Laurent Daudelin wrote: There isn't much special code in that UITableView subclass and not much either in the UITableViewController so I'm a little bit at a lost as to what could cause this. There is nothing fancy here, no custom handling of touches and things like that, just loading a bunch of cells and then loading more when we reach the bottom of the table view and there is more data to load. Anyone has any idea where I could look for this? Nothing's jumping out for me (at least I can't recall seeing this behavior). How are you adding more data? I assume that since you are bothering to load more data only when you reach the bottom that you are downloading some data for display. I also assume you are being a good iOS citizen by doing this download on a background thread/queue. If so, is it possible that you are accidentally doing some UI work on the background thread? In particular, might you be calling one of the -reloadData methods? I could certainly see that causing UITableView to end up in an inconsistent state... -- Conrad Shultz Synthetiq Solutions www.synthetiqsolutions.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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Intermittent scrolling problem in UITableView
On Nov 19, 2011, at 10:38 AM, Conrad Shultz wrote: On 11/18/11 3:29 PM, Laurent Daudelin wrote: There isn't much special code in that UITableView subclass and not much either in the UITableViewController so I'm a little bit at a lost as to what could cause this. There is nothing fancy here, no custom handling of touches and things like that, just loading a bunch of cells and then loading more when we reach the bottom of the table view and there is more data to load. Anyone has any idea where I could look for this? Nothing's jumping out for me (at least I can't recall seeing this behavior). How are you adding more data? I assume that since you are bothering to load more data only when you reach the bottom that you are downloading some data for display. I also assume you are being a good iOS citizen by doing this download on a background thread/queue. If so, is it possible that you are accidentally doing some UI work on the background thread? In particular, might you be calling one of the -reloadData methods? I could certainly see that causing UITableView to end up in an inconsistent state... +1, I was just typing something similar, doing any UI work at all on a background thread often leads to very odd behavior and I note in your second mail that you say when you touch another UI element it all redraws nicely, that is another symptom I've seen before after doing UI work on the background thread. If you are, I would highly recommend blocks to throw the work back to the main thread again, block programming and dispatch queues are possibly one of the nicest things Apple has added in the last few years, they just make stuff like this SO easy.___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Intermittent scrolling problem in UITableView
On Nov 18, 2011, at 18:48, Roland King wrote: On Nov 19, 2011, at 10:38 AM, Conrad Shultz wrote: On 11/18/11 3:29 PM, Laurent Daudelin wrote: There isn't much special code in that UITableView subclass and not much either in the UITableViewController so I'm a little bit at a lost as to what could cause this. There is nothing fancy here, no custom handling of touches and things like that, just loading a bunch of cells and then loading more when we reach the bottom of the table view and there is more data to load. Anyone has any idea where I could look for this? Nothing's jumping out for me (at least I can't recall seeing this behavior). How are you adding more data? I assume that since you are bothering to load more data only when you reach the bottom that you are downloading some data for display. I also assume you are being a good iOS citizen by doing this download on a background thread/queue. If so, is it possible that you are accidentally doing some UI work on the background thread? In particular, might you be calling one of the -reloadData methods? I could certainly see that causing UITableView to end up in an inconsistent state... +1, I was just typing something similar, doing any UI work at all on a background thread often leads to very odd behavior and I note in your second mail that you say when you touch another UI element it all redraws nicely, that is another symptom I've seen before after doing UI work on the background thread. If you are, I would highly recommend blocks to throw the work back to the main thread again, block programming and dispatch queues are possibly one of the nicest things Apple has added in the last few years, they just make stuff like this SO easy. Thanks for the pointer, I'll check how the stuff is loaded and see if anything UI-related could be executed in the operation queue we're using to load the data. -Laurent. -- Laurent Daudelin AIM/iChat/Skype:LaurentDaudelin http://www.nemesys-soft.com/ Logiciels Nemesys Software laur...@nemesys-soft.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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: CoreData and Threading
On Nov 18, 2011, at 15:21 , patrick machielse wrote: I need to _continuously_ merge changes made in the _main_ thread into a context held by a background thread. Most (all?) discussions about multi-threading in CoreData discuss merging changes from a _finite_ operation in the _background_, a quite different situation. Situation: -- My application stores an object graph in CoreData using a persistent document. The objects are manipulated by the user in the UI. Meanwhile a background thread processes the object graph continuously to generate output. Changes made by the user should be picked up and accounted for by the background thread in a timely manner. I've adopted 'thread confinement' as prescribed by Apple: the main thread and the background thread eacht have separate contexts sharing a single persistent store. Options: There are two ways to receive updates on the background thread: 1 - Through 'NSManagedObjectContextDidSaveNotification' and subsequent change merging. However, I'd have to save the document every time the user changes the document. This would not be a good user experience, to say the least. 2 - Through 'NSManagedObjectContextObjectsDidChangeNotification' The objectIDs of the changed / inserted / deleted objects can be collected from this notification and forwarded to the background thread. According to Apple: You pass the object IDs to thread A [-- my background thread --] by sending a suitable message to an object on thread A. Upon receipt, on thread A you can refetch the corresponding managed objects. Here is where I miss information: The context of my background context isn't aware of the changes in the main thread context (there was no merge) and 'refetch the corresponding managed objects' won't work because the shared persistent store wasn't updated (there was no save operation from the main context)… The MOCs are separate scratch pads. Core Data provides no connection between their object graphs except via save-dependent synchronization, therefore there's no Core Data solution to your problem. If you weren't using NSPersistentDocument, then using Core Data -[save:] would provide a possible solution, but NSDocument semantics of course prevent you from taking that approach. At the moment I cannot find an acceptable way to merge changes from the main thread into the background thread context. Is there a solution for my use case? It's hard to suggest a solution when the description of your scenario is so general. (For example, I conclude that the main-thread operations are fairly lightweight, but the background-thread operations are fairly slow or intensive. Or not.) I'd say it's worth taking some time to ask if Core Data is the correct technology to use for this. Do the conveniences and performance characteristics it provides outweigh the impedance mismatch with your application? If you must use Core Data, it's worth taking some time to ask if this simplistic multi-threaded approach is the best approach. Is there a single-threaded solution that would work better? Is there a multi-threaded solution that uses a MOC in one thread only? If you must use multiple MOCs in multiple threads, then the simplest solution may be to invent your own set of notifications (speaking generically, not implying NSNotification in particular) to send update-property dictionaries from the main thread to the background thread. (You could probably use a KVO observer on the main thread, send change-dictionaries to the background thread, and use KVC on the background thread to apply the changes, thus automating the process almost completely.) This may sound horrendous, but could perhaps be easier than it sounds. ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
How to get Glyphs
I want to display glyphs which do NOT have a Unicode representation.
Currently I use Font Book.app to search for the Glyph and then code (following
suggestions in Technical Note TN2079):
NSGlyph glyphNbr;
NSString *familyName = [ font familyName ];
if ( [ familyName isEqualToString: @Thonburi ] )
{
glyphNbr = 28 ;
}
else if ( [ familyName isEqualToString: @Tahoma ] )
{
glyphNbr = 1163 ;
}
else if ( [ familyName isEqualToString: @Microsoft Sans Serif ]
)
{
glyphNbr = 907 ;
}
else// unknown font
{
NSLog(@%s Error unknown font %@,__FUNCTION__, familyName);
return NO;
};
NSGlyphInfo *glyphInfo = [ NSGlyphInfo glyphInfoWithGlyph: glyphNbr
forFont: font baseString: selectedString ];
[ textStorage addAttribute: NSGlyphInfoAttributeName value: glyphInfo
range: selectedRange ];
But what to do in case of Arial Unicode MS (which has 50377 glyphs) ?
Generally: is there a better, more general way to get my glyph?
What I want is a NSFont method like
- (NSGlyph)glyphSimilarTo: @ฐ but: @WithoutTheLittleCedillaBelow.
Unlikely that such a method exists (or could exist) - but is there at least
something like:
- (NSArray *)variationsOfCharacter: @ฐ
Kind regards,
Gerriet.
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Glyphs without Unicode in WebView
I NSTextView I can display glyphs which have no Unicode representation following Technical Note TN2079. But how to do this in a WebView? Kind regards, Gerriet. ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
