Re: Add a view as observer of a subview transform
On Jul 3, 2011, at 9:40 PM, Tales Pinheiro De Andrade wrote: > I have a view with a subview. The subview is rotated by a drag operation, > when I change the subview transform property. > > Now I'm trying to set the view as observer of subview transform property, > like this: UIKit doesn't promise that any of the properties it exports are KV observable. I would recommend you use a different method to observe changes in the transform. -- David Duncan ___ 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
Add a view as observer of a subview transform
Hi,
I have a view with a subview. The subview is rotated by a drag operation, when
I change the subview transform property.
Now I'm trying to set the view as observer of subview transform property, like
this:
[subView addObserver:self forKeyPath:@"transform"
options:NSKeyValueObservingOptionNew context:@"subViewRotation"];
And in the superview I added just this:
- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object
change:(NSDictionary *)change context:(void *)context {
NSLog(@"%@ - %@ - %@", keyPath, object, context);
}
But this code is never called.
I also tried
[subView addObserver:self forKeyPath:@"transform"
options:NSKeyValueObservingOptionNew context:@"subViewRotation"];
which also didn't work.
What I'm doing wrong?
Is there a good reference about KVO? I have already read the KVO Quick start
guide and Key-Value Observing Programming Guide, but maybe someone have a
better reference.
Thank you
Tales
___
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: Bundled Image scaled down when displayed (drawAtPoint)
On Jul 3, 2011, at 09:00, Benjamin Dubois wrote:
> NSString* imageName = [[NSBundle mainBundle]
> pathForResource:@"image1" ofType:@"png"];
>NSLog(@"imageName:%@",imageName);
>NSImage* tempImage = [[NSImage alloc] initWithContentsOfFile:imageName];
It's a whole lot easier to use the following 1 line instead of the above 4:
NSImage* tempImage = [NSImage imageNamed: @"image1"];
You don't even need to specify the file extension.
>// Draw the image in the current context.
>
>[tempImage drawAtPoint:point
>fromRect: NSZeroRect
> operation: NSCompositeSourceOver
>fraction: 1.0];
The NSImage object has property "size" that is the logical size of the image***.
The object also has an array of representations, presumably containing just a
single representation of class NSBitmapImageRep. This has "pixelsWide" and
"pixelsHigh" properties taken from the input file, with obvious meanings.
If the image's "size" property is {0, 0}, then the size is derived from the
representation as {pixelsWide, pixelsHigh}. If the "size" property is anything
else, the representation is scaled to this size whenever the image is drawn.
Armed with the above information, you should be able to set a breakpoint (say,
at your drawAtPoint:... call), and examine these properties in the debugger to
find out why scaling is occurring. (You can log the information, but ...
sheesh! ... use the debugger, that's what it's for.)
Note that it's certainly possible that your image editor was itself displaying
the image at the wrong size, or that (if you exported from something else to
PNG format) metadata was lost or mistranslated.
*** It's the logical size in points (1/72 inch), but these may be logical
points, not real points. NSWindow can have a scale factor that translates
logical points into screen pixels, and the dpi resolution that Mac OS thinks is
your monitor resolution might be a lie. So, if you display a 72 x 72 point
image and measure the result onscreen, it may not be an inch square. But
NSImage tried its best!
___
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: Bundled Image scaled down when displayed (drawAtPoint)
On Jul 3, 2011, at 9:00 AM, Benjamin Dubois wrote: > It looks like when I run the app, my bundled image is scaled down to about > 75% of it is actual size. The resolution of the image is probably set to greater than 72dpi. Take a look at it in the Preview app’s Info pane. To fix this, either use an image editor to edit the image and change its DPI to 72, or get its pixel dimensions: NSImageRepresentation *rep = [image bestRepresentationForDevice: nil]; int width = rep.pixelsWide; int height = rep.pixelsHigh; —Jens___ 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: Line Drawing problem
On Jul 3, 2011, at 5:39 PM, Dale Satterfield wrote: > Hopefully this image will show in your email. Note that the horizontal lines > though much thinner, at least now show up as black with the anti-aliasing > turned off. I still have to have anti-aliasing on, > so I still have the problem, as well as the diagonal lines >> thicker than > horizontal issue. Not sure how to fix that either, as there are no "brushes" > that I can see discussed in the Cocoa drawing guide. You must have a bug in how you’re calculating ‘unitSize’, since that’s what determines the line width. You didn’t show that code, and it’s not really relevant here since your use of Cocoa APIs seems correct. You haven’t explained what it is you’re trying to do, either. —Jens___ 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
Bundled Image scaled down when displayed (drawAtPoint)
Hello, all! Happy 4th of July weekend! I am currently learning Cocoa/Objective C with XCode 4.0.2 and the 10.6 SDK. I had started to learn a few Cocoa bits way back when it first showed up with 10.0 preview (thanks to the student developer program) but ended up spending most of my programming time in AWT/Swing Java instead. Here is my issue: It looks like when I run the app, my bundled image is scaled down to about 75% of it is actual size. I have tried to look for a reason why my bundled image is scaled down when displayed via google searches but apparently cant find the right search terms to find an answer, and none of the sample code and apple documentation I have seen so far indicate that anything should be done in Interface Builder. Is there some kind of resolution setting in InterfaceBuilder for my Custom NSView element or MainWindow? Here is what I have in my custom NSView subclass drawRect method : *** [NSColor blackColor] setFill]; NSRectFill([self bounds]); NSString* imageName = [[NSBundle mainBundle] pathForResource:@"image1" ofType:@"png"]; NSLog(@"imageName:%@",imageName); NSImage* tempImage = [[NSImage alloc] initWithContentsOfFile:imageName]; // Draw the image in the current context. [tempImage drawAtPoint:point fromRect: NSZeroRect operation: NSCompositeSourceOver fraction: 1.0]; [tempImage release]; *** Any help, pointer would be greatly appreciated. Thank you, Ben ___ 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: How to resolve bulk warning "Creating selector for nonexistent method ..."?
Hi Motti, I would be very interested to know how you resolved this issue, if at all. I'm suddenly facing the same issue, out of no-where. Instead of trying to find the source of the problem, I just reverted to the last known working version (svn), but the warnings persist. This surprises me a bit, because earlier today i had cleaned the project and made a release-build for distribution to the client, and this went fine. I'm sure i'm overlooking something very obvious and stupid. Does anyone have an idea what that could be? thanks, arri On Mon, Jan 25, 2010 at 12:04 PM, Motti Shneor wrote: > Hi everyone. > > I'm building static library, whose outward API is plain "C", and whose > implementation is Cocoa-based. > > It was building and working alright, until (yesterday) something changed, and > any attempt to clean/build/rebuild it produces huge amount of compilation > warnings, on EVERY Obj-C message. > > First, there's a bulk of warnings like this: > > /Volumes/Data/.../FileManager_GUI_Mac.mm:224: warning: creating selector for > nonexistent method 'openPanel' > /Volumes/Data/.../FileManager_GUI_Mac.mm:196: warning: creating selector for > nonexistent method 'release' > /Volumes/Data/.../FileManager_GUI_Mac.mm:193: warning: creating selector for > nonexistent method 'code' > /Volumes/Data/.../FileManager_GUI_Mac.mm:190: warning: creating selector for > nonexistent method 'savePanel' > /Volumes/Data/.../FileManager_GUI_Mac.mm:190: warning: creating selector for > nonexistent method 'alloc' > /Volumes/Data/.../FileManager_GUI_Mac.mm:171: warning: creating selector for > nonexistent method 'stringWithFormat:' > /Volumes/Data/.../FileManager_GUI_Mac.mm:160: warning: creating selector for > nonexistent method 'getCString:maxLength:encoding:' > > Then another bulk of warnings, complaining about DOUBLE definitions for Cocoa > methods > > /Volumes/Data/.../FileManager_GUI_Mac.mm:244:0 > /Volumes/Data/.../FileManager_GUI_Mac.mm:244: warning: multiple selectors > named '+isVertical' found > /Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSSplitView.h:30:0 > > /Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSSplitView.h:30: > warning: found '-(BOOL)isVertical' > /Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSSliderCell.h:59:0 > > /Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSSliderCell.h:59: > warning: also found '-(NSInteger)isVertical' > > > > Notes: > The project is building Intel-only Universal (32/64bit, architectures i386 > and x86_64 > I only #import once, in a single source file (an interface > header file). > I added (linked) the Cocoa Framework once in the project, referencing the > "Current SDK". > The project DOES compile, and even works. > If i turn on the "Build Active Architecture Only" build option for the > project (ONLY_ACTIVE_ARCH = YES) then I only get the warnings when I compile > 32bit. 64bit compilation is free of warnings. > > > These warnings worry me, as I might be using a wrong framework, and the code > may break on a user machine. > > Any idea will be greatly appreciated. > > > Motti Shneor > -- > Senior Software Engineer > Waves Audio ltd. > > > > ___ > > 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/arritjeparretjenof%40gmail.com > > This email sent to arritjeparretje...@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
Re: Line Drawing problem
Thanks Jens, I have tried that and it does not change the appearance. One thing I did do after trying that was to turn anti-aliasing off. That does make a difference. But does not solve all the problems. I started with the code in XCode3 Unleashed in chapter 13 which plots points. On page 193 is the drawRect code. It makes the coordinate space the same as the extent of the data. In my case I know that X always ranges between 0 and 11. In any case unitSize.height = 0.28, unitSize.width = 0.013415 are the values it computes. I put the code x += 0.5 * unitSize.width and y += 0.5 * unitSize.height in the code, but that did not make any noticeable difference Hopefully this image will show in your email. Note that the horizontal lines though much thinner, at least now show up as black with the anti-aliasing turned off. I still have to have anti-aliasing on, so I still have the problem, as well as the diagonal lines >> thicker than horizontal issue. Not sure how to fix that either, as there are no "brushes" that I can see discussed in the Cocoa drawing guide. On Jul 3, 2011, at 2:51 PM, Jens Alfke wrote: > > On Jul 3, 2011, at 1:48 PM, Dale Satterfield wrote: > >> Lines with sufficient slope always draw in Black(the set color), and the >> specified width. However if the slope is low enough they print thinner, and >> in a different color. >> This is an example: > > The image didn’t show up, but you’re probably seeing the effects of subpixel > antialiasing, which uses the relative positions of the R, G and B > subcomponents of an LCD pixel to increase apparent horizontal resolution. > > Another issue that’s probably exacerbating the distortion is that, if you’re > drawing 1-pixel wide lines [or any odd integer width] you should offset their > x and y coords by 0.5 to ensure that, if horizontal/vertical or nearly so, > the lines end up entirely within a pixel instead of split between two pixels, > which will smear them. (The reason for this is that the pixels are in between > integer grid coordinates, so the pixel centers are at 0.5, 1.5, 2.5, etc.) > > —Jens Dale Satterfield dsatterfi...@mac.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: Line Drawing problem
On Jul 3, 2011, at 1:48 PM, Dale Satterfield wrote: > Lines with sufficient slope always draw in Black(the set color), and the > specified width. However if the slope is low enough they print thinner, and > in a different color. > This is an example: The image didn’t show up, but you’re probably seeing the effects of subpixel antialiasing, which uses the relative positions of the R, G and B subcomponents of an LCD pixel to increase apparent horizontal resolution. Another issue that’s probably exacerbating the distortion is that, if you’re drawing 1-pixel wide lines [or any odd integer width] you should offset their x and y coords by 0.5 to ensure that, if horizontal/vertical or nearly so, the lines end up entirely within a pixel instead of split between two pixels, which will smear them. (The reason for this is that the pixels are in between integer grid coordinates, so the pixel centers are at 0.5, 1.5, 2.5, etc.) —Jens___ 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
Line Drawing problem
I am trying to write an application that needs to plot some data and draw lines
between the points.
The code I am using is:
for(index = 0; index < (limit - 1); index++)
{
[NSBezierPath setDefaultLineWidth: 4 * MIN(unitSize.height,
unitSize.width)];
[delegate dataPointAtIndex: index x: &x y: &y];
[delegate dataPointAtIndex: index+1 x: &x1 y: &y1];
[NSBezierPath strokeLineFromPoint:NSMakePoint(x, y)
toPoint:NSMakePoint(x1, y1)];
}
Lines with sufficient slope always draw in Black(the set color), and the
specified width. However if the slope is low enough they print thinner, and in
a different color.
This is an example:
Can't find any discussion of this effect in any books or online documentation.
Would appreciate any suggestions. I am trying to use this project to learn
Cocoa and Objective-C
so am still not familiar with all the ins and outs.
Dale Satterfield
dsatterfi...@mac.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: Initial project shell and handling of window pointer
On 3 Jul 2011, at 12:49 PM, Phil Hystad wrote: > I just started playing around with iOS 4 and Xcode 4. Learning the ropes of > the new Xcode I see a difference in how the project templates are used to > create a simple Cocoa window app in iOS versus Mac OS X. > > With iOS, the app delegate handler code .h file does not declare the window > pointer variable which I see is prefixed with an underscore as in _window. > > With Mac OS X, the app delegate handler .ht file does indeed create an > instance variable for window and it does not have the prepended underscore. > > Can someone describe why this was done (differently) if there is a purpose to > this? Where is the _window instance variable created? Right now, I don't have access to the tool set you're probably using, but I believe the iOS template relies on the ability of the @synthesize directive of the modern Objective-C runtime to create backing variables for @property declarations. (Am I right that the header you're looking at includes a window @property?) iOS is guaranteed to be running the modern runtime, whereas 32-bit Mac OS X does not. As for a leading underscore, it's a matter of coding style, on which Apple never really settled (unless they're settling now). I see the merit of putting a special mark on instance variables, but I admit I haven't done it since I last used PowerPlant. Your question implies that you expect more parallels between AppKit and UIKit than would be helpful to you. — F ___ 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
Initial project shell and handling of window pointer
I am not sure if this is a question for Cocoa-dev or for Xcode. I just started playing around with iOS 4 and Xcode 4. Learning the ropes of the new Xcode I see a difference in how the project templates are used to create a simple Cocoa window app in iOS versus Mac OS X. With iOS, the app delegate handler code .h file does not declare the window pointer variable which I see is prefixed with an underscore as in _window. With Mac OS X, the app delegate handler .ht file does indeed create an instance variable for window and it does not have the prepended underscore. Can someone describe why this was done (differently) if there is a purpose to this? Where is the _window instance variable created? Thanks, phil___ 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
Leak
Environment: 'reference' rather than 'garbage collection'. Instruments tells me that I have a Foundation leak: Leaked Object,# Address SizeResponsible Library Responsible Frame Malloc 176 Bytes, 0x86e290176 Foundation -[NSNotificationCenter removeObserver:name:object:] 0 libSystem.B.dylib calloc 1 CoreFoundation __addHandler2 2 Foundation +[__NSObserver isAnObserver:] 3 Foundation -[NSNotificationCenter removeObserver:name:object:] 4 Foundation -[NSNotificationCenter removeObserver:] 5 Foundation -[NSRunLoop(NSRunLoop) dealloc] 6 CoreFoundation CFRelease 7 CoreFoundation __CFFinalizeRunLoop 8 libSystem.B.dylib _pthread_tsd_cleanup 9 libSystem.B.dylib _pthread_exit 10 libSystem.B.dylib start_wqthread I appears to be related to the use of NSNotification, which I use frequently. As you can see no source code is referenced. How do I get to the offending code? Best regards, John MacMullin ___ 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
