Re: Drawing when app is in active
On 24/03/2012, at 9:30 PM, Jonathan Guy wrote:
> Hi all
> This is must be the most simple a puzzling problem I've had. Take a new app,
> create a custom view class with a drawrect of
>
> - (void)drawRect:(NSRect)dirtyRect
> {
>if ([NSApp isActive]) {
> [[NSColor redColor] set];
> }
> else {
> [[NSColor blueColor] set];
> }
> NSRectFill([self bounds]);
> }
>
> pretty simple stuff you would think but if I drop this custom view onto the
> main window and run it up the view draw a blue square??? how bizarre. If I
> resize the window it suddenly draws red but deactivating a reactivating the
> app is not redrawing the view with the correct color. What is going on here?
> I can only think the whole view is being clipped as the system doesn't think
> it needs to be redrawn as the very first drawrect the app is showing as
> inactive but then subsequently drawrect gets called again with the app in an
> active state so it initially draws blue but then is supposed to draw red but
> that's not happening.
> Any help would be appreciated.
> Thanks
The problem is, I think, that the view is not automatically invalidated when
the app is inactivated or activated. Therefore what you see is whatever it was
in its previous state. You need to listen for the activation/inactivation
notification, and invalidate the view.
--Graham
___
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: Stenography
On 28/03/2012, at 7:19 AM, deoxy t2 wrote: > > > Hello friends. > I'm new to the list and new in Objective-C and Apple programming and I have a > very timely question, I want to manipulate images to develop stenography, but > do not know where begin. I'm reading:1.-vImage Programming Guide2 Core Image > Programming Guide > But it is not clear which library is correct in order to manipulate images > and achieve what I want. > any ideas?. > Thanks a lot. > deoxyt2.- > http://deoxyt2.livejournal.com Stenography? Writing using shorthand? Did you mean Steganography? vImage is powerful and very low level. It's probably unnecessary for steganography. Just create or obtain the bitmap for the image and manipulate its bits. A bitmap is wrapped by NSBitmapImageRep which is wrapped by NSImage. You can load an image (for a JPEG, say) very easily using NSImage, get its NSBitmapImageRep, get the bitmap buffer, change the bits and write it out. If you really did mean Stenography, perhaps you could explain what you want. I imagine stenography is possible using a custom font and a NSTextView, though parsing plain text into its stenographic form is more an exercise in tokenising the input text and mapping that to stenographic units. Beyond that, you probably need to ask more specific questions. --Graham ___ 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: drawRect using a Category
Den 03:46 1. april 2012 skrev Peter Teeson følgende: > Thanks very much for your input guys. > > David: > I had carefully read the Categories and Extensions page in OBJ-C Programming > Language. > And, based on the first paragraph, assumed I could add functionality to > drawRect for my particular case. You can use categories to add functionality to existing *classes*, but you shouldn't use it to override or replace *methods* that are already implemented in those classes. Per ___ 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: drawing lines in and NSTextView
On 31 Mar 2012, at 13:08, Koen van der Drift wrote:
> I have an NSTextView to which I want to add some lines that connect
> certain words. When the text changes, either by editing, or scrolling,
> that lines should follow the words. I thought about using
> CoreAnimation, but text in a CATextLayer does not appear to be
> editable like the text in an NSTextView (is that correct?). So, an
> alternative could be to override drawViewBackgroundInRect and use
> NSBezierPaths to draw my lines and I will work on that this weekend.
>
> Any thoughts or suggestions I may have overlooked?
>
You probably get get what you need form the WWDC references already given but
the following might still be useful.
http://www.cocoabuilder.com/archive/cocoa/113955-graphics-in-nstextview-ichat-like-bubbles.html?q=nstextview+draw+bubble#114075
Of course, overriding drawViewBackgroundInRect, will draw your lines behind the
text, which may be acceptable.
Another approach is to add a subview to the NSTextView instance and do all your
drawing there.
I use this approach to draw a simple Quartz 2D animation over an NSTextView.
Obviously you need to make your drawing sub view non opaque.
You also will need to resize your subview as the NSTextView size changes by
requesting that the appropriate NSView notifications be sent.
In my case I make my child view modify its behaviour if it is embedded in an
NSTextView.
// in NSTextView subview
if ([[self superview] isKindOfClass:[NSTextView class]]) {
// get the text view
_textView = (id)[self superview];
[_textView setAutoresizesSubviews:YES];
// set scrollview background drawing behaviour
[[self enclosingScrollView] setDrawsBackground:NO];
// observe changes to the scrollview content bounds.
// see "How Scroll Views Work" in the docs
[[[self enclosingScrollView] contentView]
setPostsBoundsChangedNotifications:YES];
[[NSNotificationCenter defaultCenter] addObserver:self
selector:@selector(scrollContentBoundsChanged:)
name:NSViewBoundsDidChangeNotification object:[[self enclosingScrollView]
contentView]];
[_textView setPostsFrameChangedNotifications:YES];
[[NSNotificationCenter defaultCenter] addObserver:self
selector:@selector(scrollContentBoundsChanged:)
name:NSViewFrameDidChangeNotification object:_textView];
// turn on layer backed views for this view
// and all subviews.
//
// this works fine but the cpu usage can be very high
// add a filter
if (_useLayers) {
// create layer for textview and all subviews
[_textView setWantsLayer:YES];
// this works but the overhead is high - cpu usage increases
from 4 -> 40%
CIFilter *filter = [CIFilter
filterWithName:@"CIColorBurnBlendMode"];
[self setCompositingFilter:filter];
}
}
Regards
Jonathan Mitchell
Mugginsoft LLP
___
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 disc undo stack
I think it's fair to say this is only true for a 64 bit app. In a 32 bit app, it's fairly easy to exhaust your address space if all deleted files are kept in-memory. On 26 Mar 2012, at 00:57, Steven wrote: > Thanks for the info Graham. > I'm using NSUndoManager. I thought that many large objects in the stack > would cause memory pressure and would be better occupying disc space as they > are only needed at undo/redo time. Good to know that the VM system will take > care of it. > > Steven. > > On 24 Mar 2012, at 01:04, Graham Cox wrote: > >> You can read and write to the Application Support folder. >> >> But FILES in an Undo stack? That makes little sense to me. >> >> If you want to undo changes to a file, store the changes or the command that >> will cause the changes in the undo stack. If you are changing the >> organisation of files on disc then save a description of that organisation >> in the undo stack. You may want to read up on the way Cocoa utilises Undo, >> because it sounds like you might not have a good grasp on it. >> >> Even if you need to store very large objects in the undo stack, unless you >> can prove it's a serious problem, just let the memory get paged to disk VM >> naturally. It's rare that users need to undo a very long history, so even if >> the older history is paged out, the chances are the user will never know. >> >> --Graham >> >> >> >> >> >> On 24/03/2012, at 10:17 AM, Steven wrote: >> >>> Hello, >>> >>> Where is the correct place to store an on-disc undo stack associated with a >>> NSDocument instance ? >>> The stack may contain several potentially large files so we don't want them >>> to occupy memory. >>> For a compound document the stack could reside in a directory NSFileWrapper. >>> For a single file document should a temporary directory be used ? >>> I guess the chosen location may need to persist beyond the occurrence of >>> the automatic termination feature. >>> Any advice appreciated. >>> Thanks. >>> >>> Steven. >>> ___ >>> >>> 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/graham.cox%40bigpond.com >>> >>> This email sent to graham@bigpond.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/cocoadev%40mikeabdullah.net > > This email sent to cocoa...@mikeabdullah.net ___ 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: Stenography
deoxy t2 wrote: > I'm new to the list and new in Objective-C and Apple programming and I have a > very timely question, I want to manipulate images to develop stenography, but > do not know where begin. I'm reading:1.-vImage Programming Guide2 Core Image > Programming Guide > But it is not clear which library is correct in order to manipulate images > and achieve what I want. > any ideas?. Just so we're clear, you're asking about steGAnography, right? ___ 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: drawing lines in and NSTextView
Thanks for the response, very helpful. Also the link to the iTunes U session. There is a wealth of info I was not aware of that it is available for non-WWDC attendees. - Koen. On Mar 31, 2012, at 9:41 PM, Douglas Davidson wrote: > > > On Mar 31, 2012, at 6:09 PM, Graham Cox wrote: > >> >> On 31/03/2012, at 11:08 PM, Koen van der Drift wrote: >> >>> I have an NSTextView to which I want to add some lines that connect >>> certain words. When the text changes, either by editing, or scrolling, >>> that lines should follow the words. I thought about using >>> CoreAnimation, but text in a CATextLayer does not appear to be >>> editable like the text in an NSTextView (is that correct?). So, an >>> alternative could be to override drawViewBackgroundInRect and use >>> NSBezierPaths to draw my lines and I will work on that this weekend. >>> >>> Any thoughts or suggestions I may have overlooked? >> >> >> Seems to me you're focusing on the wrong aspect of the problem. The key to >> this is to track given words' positions as the text is scrolled/reflowed. If >> you lay out the text yourself (using NSLayoutManager, for example) this is >> not hard, but if you leave it to something else, such as NSTextView, it may >> be a lot harder (though NSTextView has a NSLayoutManager of which you can >> ask questions). >> >> Drawing the lines once you have those positions is relatively easy - >> NSBezierPaths will work, and are probably the simplest. > > Actually it's pretty easy to just use the text view's layout manager to find > out where the words are, and do some additional drawing in your NSTextView > subclass. We have some developer examples of this, though I don't have them > ready to hand at the moment, and I've discussed this at more than one WWDC > text session. > > -Doug ___ 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 disc undo stack
On 25/03/2012, at 5:34 AM, Doug Clinton wrote: > I don't know if this was the issue that Steven was asking about, but I've > been wondering if there is a recommended way to persist the undo stack so > that it's still available if you restart the app, or close and re-open the > document. It's always bothered me that there is this great mechanism for > handling undo, but that all the history is thrown away when you close the app. No easy way I know of. The undo architecture relies on a huge amount of state within the app external to the undo stack itself. You'd have to save all of that state somehow. In fact, most apps throw away the undo history on a document save (you arrange this), as a way to recover the memory used by undo, since the whole state is being saved in the file anyway. Versions are the supported mechanism for persistent document undo. --Graham ___ 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 disc undo stack
I don't think it's likely to be true in practice on 64-bit systems either. In theory, yes, the old data could get paged out, and will not be paged back in until the user uses it. In practice though, unless these pieces of old data are big, contiguous buffers taking up pages by themselves, the old data will likely live in pages that also contain at least a few things that are at least intermittently used, so you'll be constantly paging. Jamie. On Sunday, 1 April 2012 at 11:42, Mike Abdullah wrote: > I think it's fair to say this is only true for a 64 bit app. In a 32 bit app, > it's fairly easy to exhaust your address space if all deleted files are kept > in-memory. > > On 26 Mar 2012, at 00:57, Steven wrote: > > > Thanks for the info Graham. > > I'm using NSUndoManager. I thought that many large objects in the stack > > would cause memory pressure and would be better occupying disc space as > > they are only needed at undo/redo time. Good to know that the VM system > > will take care of it. > > > > Steven. > > > > On 24 Mar 2012, at 01:04, Graham Cox wrote: > > > > > You can read and write to the Application Support folder. > > > > > > But FILES in an Undo stack? That makes little sense to me. > > > > > > If you want to undo changes to a file, store the changes or the command > > > that will cause the changes in the undo stack. If you are changing the > > > organisation of files on disc then save a description of that > > > organisation in the undo stack. You may want to read up on the way Cocoa > > > utilises Undo, because it sounds like you might not have a good grasp on > > > it. > > > > > > Even if you need to store very large objects in the undo stack, unless > > > you can prove it's a serious problem, just let the memory get paged to > > > disk VM naturally. It's rare that users need to undo a very long history, > > > so even if the older history is paged out, the chances are the user will > > > never know. > > > > > > --Graham > > > > > > > > > > > > > > > > > > On 24/03/2012, at 10:17 AM, Steven wrote: > > > > > > > Hello, > > > > > > > > Where is the correct place to store an on-disc undo stack associated > > > > with a NSDocument instance ? > > > > The stack may contain several potentially large files so we don't want > > > > them to occupy memory. > > > > For a compound document the stack could reside in a directory > > > > NSFileWrapper. > > > > For a single file document should a temporary directory be used ? > > > > I guess the chosen location may need to persist beyond the occurrence > > > > of the automatic termination feature. > > > > Any advice appreciated. > > > > Thanks. > > > > > > > > Steven. > > > > ___ > > > > > > > > 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/graham.cox%40bigpond.com > > > > > > > > This email sent to graham@bigpond.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/cocoadev%40mikeabdullah.net > > > > This email sent to cocoa...@mikeabdullah.net > > > ___ > > 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/jamie%40montgomerie.net > > This email sent to ja...@montgomerie.net ___ 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
"Google maps"-like zooming of NSScrollView's content view
Hello
I am trying to implement a zooming of a content view (actually it is a
PDFView page) using a mouse scrolling wheel.
What I want to have in the end - is to have the final content view
zoomed in or out in a way that the point, where the mouse was located,
does not move during this zooming operation (this point would be some
kind of an anchor around which the rest of the content view should be
zoomed). Here is an example of this: http://maps.google.com
I've managed to make the view zoom in and out using a view's center
point as such an anchor (this is an example i found on the internet):
float zoomFactor = 1.3;
-(void)zoomIn
{
NSRect visible = [scrollView documentVisibleRect];
NSRect newrect = NSInsetRect(visible, NSWidth(visible)*(1 -
1/zoomFactor)/2.0, NSHeight(visible)*(1 - 1/zoomFactor)/2.0);
NSRect frame = [scrollView.documentView frame];
[scrollView.documentView
scaleUnitSquareToSize:NSMakeSize(zoomFactor, zoomFactor)];
[scrollView.documentView setFrame:NSMakeRect(0, 0,
frame.size.width * zoomFactor, frame.size.height * zoomFactor)];
[[scrollView documentView] scrollPoint:newrect.origin];
}
-(void)zoomOut
{
NSRect visible = [scrollView documentVisibleRect];
NSRect newrect = NSOffsetRect(visible,
-NSWidth(visible)*(zoomFactor - 1)/2.0, -NSHeight(visible)*(zoomFactor
- 1)/2.0);
NSRect frame = [scrollView.documentView frame];
[scrollView.documentView
scaleUnitSquareToSize:NSMakeSize(1/zoomFactor, 1/zoomFactor)];
[scrollView.documentView setFrame:NSMakeRect(0, 0,
frame.size.width / zoomFactor, frame.size.height / zoomFactor)];
[[scrollView documentView] scrollPoint:newrect.origin];
}
However, I can't figure out how to make zooming like google maps does,
preserving that mouse "anchor" point's location. Could you give me a
hint?
Thank you
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: "Google maps"-like zooming of NSScrollView's content view
Just a comment about the UI… I find this behavior horribly counter-intuitive. I
always end up zooming when I mean to pan.
On 2012-04-01, at 11:28 AM, Nick wrote:
> Hello
>
> I am trying to implement a zooming of a content view (actually it is a
> PDFView page) using a mouse scrolling wheel.
> What I want to have in the end - is to have the final content view
> zoomed in or out in a way that the point, where the mouse was located,
> does not move during this zooming operation (this point would be some
> kind of an anchor around which the rest of the content view should be
> zoomed). Here is an example of this: http://maps.google.com
>
> I've managed to make the view zoom in and out using a view's center
> point as such an anchor (this is an example i found on the internet):
>
> float zoomFactor = 1.3;
>
> -(void)zoomIn
> {
>NSRect visible = [scrollView documentVisibleRect];
>NSRect newrect = NSInsetRect(visible, NSWidth(visible)*(1 -
> 1/zoomFactor)/2.0, NSHeight(visible)*(1 - 1/zoomFactor)/2.0);
>NSRect frame = [scrollView.documentView frame];
>
>[scrollView.documentView
> scaleUnitSquareToSize:NSMakeSize(zoomFactor, zoomFactor)];
>[scrollView.documentView setFrame:NSMakeRect(0, 0,
> frame.size.width * zoomFactor, frame.size.height * zoomFactor)];
>
>[[scrollView documentView] scrollPoint:newrect.origin];
> }
>
> -(void)zoomOut
> {
>NSRect visible = [scrollView documentVisibleRect];
>NSRect newrect = NSOffsetRect(visible,
> -NSWidth(visible)*(zoomFactor - 1)/2.0, -NSHeight(visible)*(zoomFactor
> - 1)/2.0);
>
>NSRect frame = [scrollView.documentView frame];
>
>[scrollView.documentView
> scaleUnitSquareToSize:NSMakeSize(1/zoomFactor, 1/zoomFactor)];
>[scrollView.documentView setFrame:NSMakeRect(0, 0,
> frame.size.width / zoomFactor, frame.size.height / zoomFactor)];
>
>[[scrollView documentView] scrollPoint:newrect.origin];
> }
>
> However, I can't figure out how to make zooming like google maps does,
> preserving that mouse "anchor" point's location. Could you give me a
> hint?
>
> Thank you
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/dave.fernandes%40utoronto.ca
>
> This email sent to dave.fernan...@utoronto.ca
___
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: "Google maps"-like zooming of NSScrollView's content view
Dave, while I can see that you may want the mouse wheel to navigate the current map, does it not make more sense to allow the mouse wheel to zoom in or out and then hold the mouse button down and drag left and right to pan? If you use the mouse wheel to pan, what is naturally your zoom control? On Apr 1, 2012, at 11:52 AM, Dave Fernandes wrote: > Just a comment about the UI… I find this behavior horribly counter-intuitive. > I always end up zooming when I mean to pan. ___ 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
crash on OS X when popover closes
Dear list, I've received a crash report from a customer which I'm unable to reproduce and have not heard of from any other user. The action needed for the customer to reproduce the crash is such a common one, that it seems that all other customers should hit the same issue. That makes me wonder if it's a problem of the customer's machine. The crash log is below. Does anyone have any suggestions as to how I might find the problem? Best wishes, Martin OS Version: Mac OS X 10.7.3 (11D50b) Application Specific Information: objc[11323]: garbage collection is OFF *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[NSRecursiveLock popoverDidClose:]: unrecognized selector sent to instance 0x1020e2a80' *** First throw call stack: ( 0 CoreFoundation 0x7fff8a9bcfc6 __exceptionPreprocess + 198 1 libobjc.A.dylib 0x7fff8615bd5e objc_exception_throw + 43 2 CoreFoundation 0x7fff8aa492ae -[NSObject doesNotRecognizeSelector:] + 190 3 CoreFoundation 0x7fff8a9a9e73 ___forwarding___ + 371 4 CoreFoundation 0x7fff8a9a9c88 _CF_forwarding_prep_0 + 232 5 Foundation 0x7fff8d029d32 __-[NSNotificationCenter addObserver:selector:name:object:]_block_invoke_1 + 47 6 CoreFoundation 0x7fff8a965aaa _CFXNotificationPost + 2634 7 AppKit 0x7fff877f586d _NSPopoverSendDidCloseNotification + 154 8 AppKit 0x7fff877f70a6 -[NSPopover _finishClosingAndShouldNotify:] + 60 smime.p7s Description: S/MIME cryptographic signature ___ 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: "Google maps"-like zooming of NSScrollView's content view
This is a very customized application, it is not intended for public use. Just wondering if someone could help me with the math to create this zooming effect.. Alex Zavatone wrote: > Dave, while I can see that you may want the mouse wheel to navigate the > current map, does it not make more sense to allow the mouse wheel to zoom in > or out and then hold the mouse button down and drag left and right to pan? > > If you use the mouse wheel to pan, what is naturally your zoom control? > > On Apr 1, 2012, at 11:52 AM, Dave Fernandes wrote: > >> Just a comment about the UI… I find this behavior horribly >> counter-intuitive. I always end up zooming when I mean to pan. > ___ 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: "Google maps"-like zooming of NSScrollView's content view
Den 17:28 1. april 2012 skrev Nick følgende:
> However, I can't figure out how to make zooming like google maps does,
> preserving that mouse "anchor" point's location. Could you give me a
> hint?
>
> Thank you
I can't give you readymade example code, but here's the steps:
1) Find the mouse location in the clip view's ( = content view's )
coordinate space. ( [clipView convertPoint:[theEvent locationInWindow]
formView:nil] )
2) Compute the mouse location in fractions of the clip view's bounds.
All the way to the left means x = 0, all the way to the right means x
= 1. Vice versa with y. If the point is equal to the content view's
origin, the fraction point becomes { 0, 0 }, if it's in the center,
you get { 0.5, 0.5 }, if the point's x value equals the
bounds.origin.x + bounds.size.width, and vice versa with y, you get {
1, 1 }.
3) Manipulate the bounds of the content view (NOT the document view),
so that the bounds rectangle gets smaller if you zoom in, larger if
you zoom out. How much you change the content view bound's location is
given by the fraction you found in point 2 (along each axis). How much
you change the bound's size is given by one minus the fraction you
found in point 2. For the fraction point { 0, 0 }, you do not touch
the bound's origin at all. For the fraction point { 1, 1 } you only
change the origin, not the size.
Don't touch the document view's frame or bounds. This way of zooming,
by manipulating the content view's bounds instead of the document
view's frame has worked fine for me in the past. It's usually easier,
I think.
Per
___
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: "Google maps"-like zooming of NSScrollView's content view
There is code from Paul Hegarty's class on UImageView that works really easily with the pinch gesture. I'll look to see if I have any code handy. On Apr 1, 2012, at 12:42 PM, Nick wrote: > This is a very customized application, it is not intended for public use. > Just wondering if someone could help me with the math to create this > zooming effect.. > > Alex Zavatone wrote: >> Dave, while I can see that you may want the mouse wheel to navigate the >> current map, does it not make more sense to allow the mouse wheel to zoom in >> or out and then hold the mouse button down and drag left and right to pan? >> >> If you use the mouse wheel to pan, what is naturally your zoom control? >> >> On Apr 1, 2012, at 11:52 AM, Dave Fernandes wrote: >> >>> Just a comment about the UI… I find this behavior horribly >>> counter-intuitive. I always end up zooming when I mean to pan. >> - Alex Zavatone ___ 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: crash on OS X when popover closes
On Apr 1, 2012, at 9:38 AM, Martin Hewitson wrote: > Dear list, > > I've received a crash report from a customer which I'm unable to reproduce > and have not heard of from any other user. The action needed for the customer > to reproduce the crash is such a common one, that it seems that all other > customers should hit the same issue. That makes me wonder if it's a problem > of the customer's machine. The crash log is below. > > Does anyone have any suggestions as to how I might find the problem? Does it involve displayi g a popover from a fullscreen window and swiping away and back using the trackpad gesture? We had a reproducible crasher from the Dictionary popover in this circumstance. --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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: crash on OS X when popover closes
Not sure. I'll ask the customer. That's a bit the problem at the moment - I'm unsure what to ask them to do next. Thanks for the idea, Martin On Apr 1, 2012, at 07:03 PM, Kyle Sluder wrote: > On Apr 1, 2012, at 9:38 AM, Martin Hewitson > wrote: > >> Dear list, >> >> I've received a crash report from a customer which I'm unable to reproduce >> and have not heard of from any other user. The action needed for the >> customer to reproduce the crash is such a common one, that it seems that all >> other customers should hit the same issue. That makes me wonder if it's a >> problem of the customer's machine. The crash log is below. >> >> Does anyone have any suggestions as to how I might find the problem? > > Does it involve displayi g a popover from a fullscreen window and swiping > away and back using the trackpad gesture? We had a reproducible crasher from > the Dictionary popover in this circumstance. > > --Kyle Sluder Martin Hewitson Albert-Einstein-Institut Max-Planck-Institut fuer Gravitationsphysik und Universitaet Hannover Callinstr. 38, 30167 Hannover, Germany Tel: +49-511-762-17121, Fax: +49-511-762-5861 E-Mail: martin.hewit...@aei.mpg.de WWW: http://www.aei.mpg.de/~hewitson smime.p7s Description: S/MIME cryptographic signature ___ 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: Order of Finder labels
On 31 Mar 2012, at 7:53 PM, Seth Willits wrote: > On Mar 31, 2012, at 5:29 PM, Fritz Anderson wrote: > >> +[NSWorkspace fileLabelColors] returns the available label colors in the >> same order as the index. >> >> What I'd really like is to use the same order as appears in the preferences, >> and in the File/contextual menu. That is, I'd like to conform to Apple's >> interface. Is this possible? > > Why wouldn't it be? Just display them in the same order as Finder and don't > rely on the display index being the same as the label index you use in the > assignment. I don't really see the problem. (I've done this.) Hard-coding the order works in practice — most of the time. Unless I much mistake, it doesn't work in principle. Users can change colors and label names, and I know of no way to sort colors or names to match what's in the Finder preferences. Maybe the permutation of the indices is fixed, but I'd be more comfortable if the permutation were documented. — 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: "Google maps"-like zooming of NSScrollView's content view
Den 18:51 1. april 2012 skrev Per Bull Holmen følgende:
> Den 17:28 1. april 2012 skrev Nick følgende:
>
>> However, I can't figure out how to make zooming like google maps does,
>> preserving that mouse "anchor" point's location. Could you give me a
>> hint?
>>
>> Thank you
>
> I can't give you readymade example code, but here's the steps:
OK, just because I am a naive altruist, I made one for you. This one
takes a zoom factor where 1 is 1:1, 0.5 means half size, 2.0 means
double size, etc. Works on my machine. I haven't checked what happens
if the bounds origin gets negative coordinates. You may want to put in
a little check to prevent that.
-(void)zoom:(float)newFactor event:(NSEvent *)mouseEvent {
NSScrollView *scrollView = [self enclosingScrollView];
NSClipView *clipView = [scrollView contentView];
NSRect clipViewBounds = [clipView bounds];
NSSize clipViewSize = [clipView frame].size;
NSPoint clipLocalPoint = [clipView convertPoint:[mouseEvent
locationInWindow] fromView:nil];
float xFraction = ( clipLocalPoint.x - clipViewBounds.origin.x ) /
clipViewBounds.size.width;
float yFraction = ( clipLocalPoint.y - clipViewBounds.origin.y ) /
clipViewBounds.size.height;
clipViewBounds.size.width = clipViewSize.width / newFactor;
clipViewBounds.size.height = clipViewSize.height / newFactor;
clipViewBounds.origin.x = clipLocalPoint.x - ( xFraction *
clipViewBounds.size.width );
clipViewBounds.origin.y = clipLocalPoint.y - ( yFraction *
clipViewBounds.size.height );
[clipView setBounds:clipViewBounds];
}
Per
___
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: "Google maps"-like zooming of NSScrollView's content view
I guess it makes some sense with a mouse wheel, but doesn't seem right with a Magic Mouse. On a trackpad, at least there is a pinch zoom gesture. On 2012-04-01, at 12:05 PM, Alex Zavatone wrote: > Dave, while I can see that you may want the mouse wheel to navigate the > current map, does it not make more sense to allow the mouse wheel to zoom in > or out and then hold the mouse button down and drag left and right to pan? > > If you use the mouse wheel to pan, what is naturally your zoom control? > > On Apr 1, 2012, at 11:52 AM, Dave Fernandes wrote: > >> Just a comment about the UI… I find this behavior horribly >> counter-intuitive. I always end up zooming when I mean to pan. > ___ 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: crash on OS X when popover closes
On Apr 1, 2012, at 11:38 AM, Martin Hewitson wrote: > I've received a crash report from a customer which I'm unable to reproduce > and have not heard of from any other user. The action needed for the customer > to reproduce the crash is such a common one, that it seems that all other > customers should hit the same issue. That makes me wonder if it's a problem > of the customer's machine. The crash log is below. > > Does anyone have any suggestions as to how I might find the problem? > *** Terminating app due to uncaught exception 'NSInvalidArgumentException', > reason: '-[NSRecursiveLock popoverDidClose:]: unrecognized selector sent to > instance 0x1020e2a80' This suggests a memory management bug. Something is invoking -popoverDidClose: on an NSRecursiveLock, which surely isn't what was supposed to receive that message. Usually this happens because the object that was supposed to receive it has been deallocated and another object (an NSRecursiveLock, in this case) has reused that memory. The particular memory management bug may be an over-release (or failure to retain), but it could also be a failure to unregister an object from observing a notification prior to its deallocation. In this case, it seems as though you failed to unset the delegate of the NSPopover prior to the delegate's deallocation. (The NSPopover registers the delegate as an observer of NSPopoverDidCloseNotification and would unregister it when you unset the delegate.) Regards, Ken ___ 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: "Google maps"-like zooming of NSScrollView's content view
On Apr 1, 2012, at 3:59 PM, Dave Fernandes wrote: > I guess it makes some sense with a mouse wheel, but doesn't seem right with a > Magic Mouse. On a trackpad, at least there is a pinch zoom gesture. > You could have buttons on the screen to zoom in and out , as in google maps and use the scroll wheel to pan, but it appears that Apple is pushing the control-less pan/zooming. Gestures to zoom ala pinch and single finger swipes to pan. Anyway, it's Sunday. Back to work. - Alex Zavatone ___ 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: Convert to Objective-C ARC Syntax Error
Brad,
This looks similar to Radar 10434539. Let me know if this works: simplify the
header includes in your code to just #import and just link
against Quartz. If your code is already doing this, then let us know.
Thanks!
davez
On Mar 31, 2012, at 3:39 PM, Brad Stone wrote:
> I used "Edit->Refactor->Convert to Objective-C ARC...". My app works fine
> but I'm getting a syntax error in Apple's header files. They're all in the
> same place: @private.
>
> There error is '__strong' only applies to objective-c object or block pointer
> types; type here is 'void *'
>
> Here's an example:
>
> /* Quartz Composer Composition Renderer */
> @interface QCRenderer : NSObject
> {
> @private
> __strong void* _QCRendererPrivate;
> }
>
>
> I'm thinking I should remove the __strong from these but I'm wondering why
> __strong was added here anyway and I'm wary about touching Apple's code.
>
> I'm at a loss.
>
> Thanks
>
> The same things happens in QCPlugIn.h, QCRendered.h, QCCompositionLayer.h,
> QCView.h, QCCompositionParameterView.h, QCCompositionPickerView.h,
> QCCompositionPickerPanel.h, QCPLugInViewController.h, IKImageBrowserView.h,
> IKImageBrowswerCell.h, IKImageBrowserView.h
> ___
>
> 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/zarzycki%40apple.com
>
> This email sent to zarzy...@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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Order of Finder labels
On Apr 1, 2012, at 10:33 AM, Fritz Anderson wrote: >> Why wouldn't it be? Just display them in the same order as Finder and don't >> rely on the display index being the same as the label index you use in the >> assignment. I don't really see the problem. (I've done this.) > > Hard-coding the order works in practice — most of the time. Unless I much > mistake, it doesn't work in principle. Users can change colors and label > names, and I know of no way to sort colors or names to match what's in the > Finder preferences. Maybe the permutation of the indices is fixed, but I'd be > more comfortable if the permutation were documented. Users cannot change the Finder label colors, only the label names. Though, I was wrong; My code actually is relying on pre-10.6 path FSSetCatalogInfo to set the file label. Oops. :) But as you say, in practice it'll work. The order doesn't make any sense to me either, but the label names and colors don't change their index in 10.7 or 10.6 so you can rely on it. I doubt they've changed for 10.8 either. -- 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: crash on OS X when popover closes
On Apr 1, 2012, at 4:54 PM, Ken Thomases wrote: > On Apr 1, 2012, at 11:38 AM, Martin Hewitson wrote: > >> I've received a crash report from a customer which I'm unable to reproduce >> and have not heard of from any other user. The action needed for the >> customer to reproduce the crash is such a common one, that it seems that all >> other customers should hit the same issue. That makes me wonder if it's a >> problem of the customer's machine. The crash log is below. >> >> Does anyone have any suggestions as to how I might find the problem? > >> *** Terminating app due to uncaught exception 'NSInvalidArgumentException', >> reason: '-[NSRecursiveLock popoverDidClose:]: unrecognized selector sent to >> instance 0x1020e2a80' It looks like the popup may have already been deallocated. That's where my money is. > This suggests a memory management bug. Something is invoking > -popoverDidClose: on an NSRecursiveLock, which surely isn't what was supposed > to receive that message. Usually this happens because the object that was > supposed to receive it has been deallocated and another object (an > NSRecursiveLock, in this case) has reused that memory. > > The particular memory management bug may be an over-release (or failure to > retain), but it could also be a failure to unregister an object from > observing a notification prior to its deallocation. In this case, it seems > as though you failed to unset the delegate of the NSPopover prior to the > delegate's deallocation. (The NSPopover registers the delegate as an > observer of NSPopoverDidCloseNotification and would unregister it when you > unset the delegate.) > > Regards, > Ken > ___ 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: drawRect using a Category
On Mar 31, 2012, at 6:46 PM, Peter Teeson wrote: > In my app there is only the one NSMatrix instance There's no way to tell, really. For all I know, the Open or Save panels might use NSMatrix. Or the Find panel or the font panel. Heck, I believe in the old days of OpenStep, menus were implemented as NSMatrixes of menu item cells. Also, if you ever need to add another different NSMatrix somewhere else in your app, you're now SOL because you'll now have to rip out the category method and re-implement your code the right way using subclassing. > Although I do [super drawRect] after my own drawing. That won't call the old NSMatrix drawRect, it'll call the drawRect of the superclass of NSMatrix, which is NSControl. You've effectively deleted the original NSMatrix drawRect implementation, so it's impossible to call it without some tricky gymnastics. One more time: a category doesn't override a method, it replaces it. It literally edits the class's method table to replace the old function pointer with the new one. The only way to properly override a method, in the OOP sense, is to make a subclass. —Jens smime.p7s Description: S/MIME cryptographic signature ___ 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: Drawing when app is in active
On Mar 24, 2012, at 3:30 AM, Jonathan Guy wrote: > If I resize the window it suddenly draws red but deactivating a reactivating > the app is not redrawing the view with the correct color. What is going on > here? Activating/deactivating an app does not force all of its views to redraw! That would be really expensive. If you want your view to change appearance when this happens, you'll have to listen for the right notification and call -setNeedsDisplay:. That's what controls that update their appearance when active/inactive do. Also, you probably don't want the appearance to be based on whether the app is active or inactive; that would be rather weird and nonstandard. Instead, base it on whether the window is key. —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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
