Re: Autosave in place - common use case that makes me hate it
On 21/09/2012, at 2:19 PM, Graham Cox graham@bigpond.com wrote: surely it's not just me? Far from it. I ended up adding a preference to turn it off, following complaints. -- Shane Stanley sstan...@myriad-com.com.au 'AppleScriptObjC Explored' www.macosxautomation.com/applescript/apps/ ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post 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: Autosave in place - common use case that makes me hate it
On Sep 20, 2012, at 11:03 PM, Shane Stanley sstan...@myriad-com.com.au wrote: On 21/09/2012, at 2:19 PM, Graham Cox graham@bigpond.com wrote: surely it's not just me? Far from it. I ended up adding a preference to turn it off, following complaints. My gut tells me you should remove that preference and direct your users to Mountain Lion's General System Preferences instead. Now that Apple has added prompt-to-revert support for autosaved documents, there is no reason to assume future versions of the OS will continue to support non-autosaving documents. And do you *really* want to test both save paths, especially when one is just a convenience wrapper around the other? --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: NSDocument -close called multiple times?
Just to clarify: -isClosed is not something that is available on NSDocument or NSWindowController, did you mean to say that I'll have to keep a flag myself? Regards Markus On 9/20/12 6:53 PM, Kevin Perry wrote: This is an known and unfortunate result of the current architecture of NSWindow, NSWindowController, and NSDocument. There isn't any documentation I'm aware of that explicitly states that -close can be invoked re-entrantly, but it can be deduced from the existing documentation: On -[NSDocument close]: The default implementation of this method … sends each of the document's window controllers a -close message On -[NSWindowController close]: If the controller belongs to a document and it is either the last controller for the document or -shouldCloseDocument is YES, then this will also -close the document. The best way around this at the moment is to first verify [self isClosed] == NO before calling super and doing your own work. [kevin perry]; On Sep 19, 2012, at 1:06 PM, Markus Spoettl ms_li...@shiftoption.com wrote: Why does AppKit call into NSDocument's -close multiple times by indirect recursion? Can this be on purpose? It happens when I have this: 1) A document with unsaved with changes 2) Terminate the app via CMD-Q 3) Answer Don't Save in the save-changes-sheet This doesn't smell right. I override -close and call super right away, doing some cleanup work afterwards. Under some bizarre situations which I have not been able to recreate it gets called up to 4 times. I'm pasting the call stack (line 366 is the call to super, line 375 is my breakpoint). Regards Markus #0 0x000134d8 in -[MyDocument close] at /Users/markus/Projects/MyApp/src/MyDocument.m:375 #1 0x7fff8bed7d25 in -[NSWindowController _windowDidClose] () #2 0x7fff8a30ddf0 in -[QLSeamlessDocumentCloser closeWindow:contentFrame:withBlock:] () #3 0x7fff8baa8602 in -[NSWindow _close] () #4 0x7fff8bbe1c74 in -[NSDocument close] () #5 0x000133c9 in -[MyDocument close] at /Users/markus/Projects/MyApp/src/MyDocument.m:366 #6 0x7fff8bbf342e in __-[NSDocumentController closeAllDocumentsWithDelegate:didCloseAllSelector:contextInfo:]_block_invoke_3 () #7 0x7fff8bbf54c5 in -[NSDocumentController _something:didSomething:soContinue:] () #8 0x7fff8bbd62a8 in __-[NSDocument canCloseDocumentWithDelegate:shouldCloseSelector:contextInfo:]_block_invoke_2 () #9 0x7fff8bbd5ec1 in __-[NSDocument canCloseDocumentWithDelegate:shouldCloseSelector:contextInfo:]_block_invoke_11 () #10 0x7fff8bbe8e08 in -[NSDocument _something:wasPresentedWithResult:soContinue:] () #11 0x7fff8bad8a4d in -[NSAlert didEndAlert:returnCode:contextInfo:] () #12 0x7fff8bae53df in -[NSApplication endSheet:returnCode:] () #13 0x7fff8bad8913 in -[NSAlert buttonPressed:] () #14 0x7fff8053770d in -[NSObject performSelector:withObject:] () #15 0x7fff8b934f7e in -[NSApplication sendAction:to:from:] () #16 0x7fff8b934eb2 in -[NSControl sendAction:to:] () #17 0x7fff8b934ddd in -[NSCell _sendActionFrom:] () #18 0x7fff8b9342a0 in -[NSCell trackMouse:inRect:ofView:untilMouseUp:] () #19 0x7fff8b9b3fc4 in -[NSButtonCell trackMouse:inRect:ofView:untilMouseUp:] () #20 0x7fff8b932eaa in -[NSControl mouseDown:] () #21 0x7fff8b8fe348 in -[NSWindow sendEvent:] () #22 0x7fff8b897a55 in -[NSApplication sendEvent:] () #23 0x7fff8bae427e in -[NSApplication _shouldTerminate] () #24 0x7fff8b838115 in -[NSApplication terminate:] () #25 0x00010001a4a3 in -[AppDelegate terminate:] at /Users/markus/Projects/rubiTrack/src/AppDelegate.m:219 #26 0x7fff8053770d in -[NSObject performSelector:withObject:] () #27 0x7fff8b934f7e in -[NSApplication sendAction:to:from:] () #28 0x7fff8ba21bfb in -[NSMenuItem _corePerformAction] () #29 0x7fff8ba21932 in -[NSCarbonMenuImpl performActionWithHighlightingForItemAtIndex:] () #30 0x7fff8b99f524 in -[NSMenu performKeyEquivalent:] () #31 0x7fff8b99e175 in -[NSApplication _handleKeyEquivalent:] () #32 0x7fff8b897536 in -[NSApplication sendEvent:] () #33 0x7fff8b82e0c6 in -[NSApplication run] () #34 0x7fff8baaa244 in NSApplicationMain () #35 0x0001b552 in main at /Users/markus/Projects/MyApp/src/main.m:22 #36 0x000121c4 in start () -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post 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/kperry%40apple.com This email sent to kpe...@apple.com --
Re: Autosave in place - common use case that makes me hate it
On 9/21/12 8:12 AM, Kyle Sluder wrote: Now that Apple has added prompt-to-revert support for autosaved documents, This makes my brain hurt... Yes, I hate it too. Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post 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: Autosave in place - common use case that makes me hate it
On 21/09/2012, at 4:12 PM, Kyle Sluder k...@ksluder.com wrote: My gut tells me you should remove that preference and direct your users to Mountain Lion's General System Preferences instead. That doesn't help with Lion users, but I take your point about what's likely to happen. I'd prefer app-level control -- in some kinds of app full autosaving makes complete sense to me. And do you *really* want to test both save paths, especially when one is just a convenience wrapper around the other? I'm using just the one save path (fileWrapperOfType:error: because I'm saving packages). What am I missing? -- Shane Stanley sstan...@myriad-com.com.au 'AppleScriptObjC Explored' www.macosxautomation.com/applescript/apps/ ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post 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
drawGlyphsForGlyphRange layout issue
The following is used to draw a glyph representing a tab character in an
NSLayoutManager subclass.
When using say the Monaco font everything looks fine.
When switching to Menlo however the glyphs drawn in the method below are
positioned lower on the line than those drawn by the super implementation.
The same is true when switching between a range of fonts - some align okay,
others are lowered.
I am aware that a flipped context is required but this seems to be so.
There is obviously something about the layout that I am missing here which is
implemented by the super implementation.
Any pointers would be appreciated.
- (void)drawGlyphsForGlyphRange:(NSRange)glyphRange
atPoint:(NSPoint)containerOrigin
{
if (showInvisibleCharacters) {
NSString *completeString = [[self textStorage] string];
NSInteger lengthToRedraw = NSMaxRange(glyphRange);
NSGraphicsContext *context = [NSGraphicsContext currentContext];
NSLog(@Context isFlipped = % d, [context isFlipped]); //
result: context is flipped
for (NSInteger idx = glyphRange.location; idx lengthToRedraw;
idx++) {
unichar characterToCheck = [completeString
characterAtIndex:idx];
if (characterToCheck == '\t') {
NSPoint pointToDrawAt = [self
locationForGlyphAtIndex:idx];
NSRect glyphFragment = [self
lineFragmentRectForGlyphAtIndex:idx effectiveRange:NULL];
pointToDrawAt.x += glyphFragment.origin.x;
pointToDrawAt.y = glyphFragment.origin.y;
[self.tabCharacter drawAtPoint:pointToDrawAt
withAttributes:self.attributes];
}
}
}
[super drawGlyphsForGlyphRange:glyphRange atPoint:containerOrigin];
}
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: Autosave in place - common use case that makes me hate it
On Sep 21, 2012, at 6:19 AM, Graham Cox graham@bigpond.com wrote: This might sound esoteric, but this is proving to be really, really common. It's not just me - our users are complaining for exactly the same reason - they make a change which they don't expect to stick because they deliberately don't save, and yet it does stick. The locking of a document doesn't help because these changes are usually right after the file was saved. Honestly, this really stinks. I'm finding it hard to believe that Apple in their wisdom feel this is actually easier to use than the old way of doing things. I'd be interested to hear others' thoughts on this, surely it's not just me? I run into it as well. But less and less. It's the same as the reversal of the scroll wheel direction: It's hard to undo more than a decade of rote memorization. But it's possible It's an aspect of having to manually save that we power users have taken advantage of as a feature. The real world doesn't work like that. New users don't expect it to work like that. For everyone but us damaged souls, this is actually an improvement. If you wanted to scribble additional annotations into a drawing, you'd make a photocopy of it. On the computer, you just have to train yourself to duplicate the file before you do these changes. Also, I think this is off-topic for this mailing list. Feel free to discuss this at the Mac-GUI-Dev mailing list: http://tech.groups.yahoo.com/group/mac-gui-dev/ Cheers, -- Uli Kusterer The Witnesses of TeachText are everywhere... http://www.zathras.de ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post 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: drawGlyphsForGlyphRange layout issue
On Sep 21, 2012, at 6:54 AM, jonat...@mugginsoft.com jonat...@mugginsoft.com wrote: The following is used to draw a glyph representing a tab character in an NSLayoutManager subclass. When using say the Monaco font everything looks fine. When switching to Menlo however the glyphs drawn in the method below are positioned lower on the line than those drawn by the super implementation. Not sure this will help, but you might compare the descender value for the 2 fonts and see if the difference is equal to the positioning problem. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post 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 -close called multiple times?
Oh dear. Forget you heard me mention anything about unpublished API. The lack of an _ threw me off... Yes, you'll probably want to keep your own flag. -KP On Sep 20, 2012, at 11:41 PM, Markus Spoettl ms_li...@shiftoption.com wrote: Just to clarify: -isClosed is not something that is available on NSDocument or NSWindowController, did you mean to say that I'll have to keep a flag myself? Regards Markus On 9/20/12 6:53 PM, Kevin Perry wrote: This is an known and unfortunate result of the current architecture of NSWindow, NSWindowController, and NSDocument. There isn't any documentation I'm aware of that explicitly states that -close can be invoked re-entrantly, but it can be deduced from the existing documentation: On -[NSDocument close]: The default implementation of this method … sends each of the document's window controllers a -close message On -[NSWindowController close]: If the controller belongs to a document and it is either the last controller for the document or -shouldCloseDocument is YES, then this will also -close the document. The best way around this at the moment is to first verify [self isClosed] == NO before calling super and doing your own work. [kevin perry]; On Sep 19, 2012, at 1:06 PM, Markus Spoettl ms_li...@shiftoption.com wrote: Why does AppKit call into NSDocument's -close multiple times by indirect recursion? Can this be on purpose? It happens when I have this: 1) A document with unsaved with changes 2) Terminate the app via CMD-Q 3) Answer Don't Save in the save-changes-sheet This doesn't smell right. I override -close and call super right away, doing some cleanup work afterwards. Under some bizarre situations which I have not been able to recreate it gets called up to 4 times. I'm pasting the call stack (line 366 is the call to super, line 375 is my breakpoint). Regards Markus #0 0x000134d8 in -[MyDocument close] at /Users/markus/Projects/MyApp/src/MyDocument.m:375 #1 0x7fff8bed7d25 in -[NSWindowController _windowDidClose] () #2 0x7fff8a30ddf0 in -[QLSeamlessDocumentCloser closeWindow:contentFrame:withBlock:] () #3 0x7fff8baa8602 in -[NSWindow _close] () #4 0x7fff8bbe1c74 in -[NSDocument close] () #5 0x000133c9 in -[MyDocument close] at /Users/markus/Projects/MyApp/src/MyDocument.m:366 #6 0x7fff8bbf342e in __-[NSDocumentController closeAllDocumentsWithDelegate:didCloseAllSelector:contextInfo:]_block_invoke_3 () #7 0x7fff8bbf54c5 in -[NSDocumentController _something:didSomething:soContinue:] () #8 0x7fff8bbd62a8 in __-[NSDocument canCloseDocumentWithDelegate:shouldCloseSelector:contextInfo:]_block_invoke_2 () #9 0x7fff8bbd5ec1 in __-[NSDocument canCloseDocumentWithDelegate:shouldCloseSelector:contextInfo:]_block_invoke_11 () #10 0x7fff8bbe8e08 in -[NSDocument _something:wasPresentedWithResult:soContinue:] () #11 0x7fff8bad8a4d in -[NSAlert didEndAlert:returnCode:contextInfo:] () #12 0x7fff8bae53df in -[NSApplication endSheet:returnCode:] () #13 0x7fff8bad8913 in -[NSAlert buttonPressed:] () #14 0x7fff8053770d in -[NSObject performSelector:withObject:] () #15 0x7fff8b934f7e in -[NSApplication sendAction:to:from:] () #16 0x7fff8b934eb2 in -[NSControl sendAction:to:] () #17 0x7fff8b934ddd in -[NSCell _sendActionFrom:] () #18 0x7fff8b9342a0 in -[NSCell trackMouse:inRect:ofView:untilMouseUp:] () #19 0x7fff8b9b3fc4 in -[NSButtonCell trackMouse:inRect:ofView:untilMouseUp:] () #20 0x7fff8b932eaa in -[NSControl mouseDown:] () #21 0x7fff8b8fe348 in -[NSWindow sendEvent:] () #22 0x7fff8b897a55 in -[NSApplication sendEvent:] () #23 0x7fff8bae427e in -[NSApplication _shouldTerminate] () #24 0x7fff8b838115 in -[NSApplication terminate:] () #25 0x00010001a4a3 in -[AppDelegate terminate:] at /Users/markus/Projects/rubiTrack/src/AppDelegate.m:219 #26 0x7fff8053770d in -[NSObject performSelector:withObject:] () #27 0x7fff8b934f7e in -[NSApplication sendAction:to:from:] () #28 0x7fff8ba21bfb in -[NSMenuItem _corePerformAction] () #29 0x7fff8ba21932 in -[NSCarbonMenuImpl performActionWithHighlightingForItemAtIndex:] () #30 0x7fff8b99f524 in -[NSMenu performKeyEquivalent:] () #31 0x7fff8b99e175 in -[NSApplication _handleKeyEquivalent:] () #32 0x7fff8b897536 in -[NSApplication sendEvent:] () #33 0x7fff8b82e0c6 in -[NSApplication run] () #34 0x7fff8baaa244 in NSApplicationMain () #35 0x0001b552 in main at /Users/markus/Projects/MyApp/src/main.m:22 #36 0x000121c4 in start () -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at
Re: drawGlyphsForGlyphRange layout issue
On Fri, Sep 21, 2012, at 03:54 AM, jonat...@mugginsoft.com wrote: There is obviously something about the layout that I am missing here which is implemented by the super implementation. Any pointers would be appreciated. 1. Consider asking your question on the coretext-dev list. 2. Watch the Session 226 - Core Text and Fonts video from WWDC 2012. --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: NSDocument -close called multiple times?
OK, so one further question: Is there any chance that if -close is called the document won't actually be closed and stays open? Regards Markus On 9/21/12 6:49 PM, Kevin Perry wrote: Oh dear. Forget you heard me mention anything about unpublished API. The lack of an _ threw me off... Yes, you'll probably want to keep your own flag. -KP On Sep 20, 2012, at 11:41 PM, Markus Spoettl ms_li...@shiftoption.com wrote: Just to clarify: -isClosed is not something that is available on NSDocument or NSWindowController, did you mean to say that I'll have to keep a flag myself? Regards Markus On 9/20/12 6:53 PM, Kevin Perry wrote: This is an known and unfortunate result of the current architecture of NSWindow, NSWindowController, and NSDocument. There isn't any documentation I'm aware of that explicitly states that -close can be invoked re-entrantly, but it can be deduced from the existing documentation: On -[NSDocument close]: The default implementation of this method … sends each of the document's window controllers a -close message On -[NSWindowController close]: If the controller belongs to a document and it is either the last controller for the document or -shouldCloseDocument is YES, then this will also -close the document. The best way around this at the moment is to first verify [self isClosed] == NO before calling super and doing your own work. [kevin perry]; On Sep 19, 2012, at 1:06 PM, Markus Spoettl ms_li...@shiftoption.com wrote: Why does AppKit call into NSDocument's -close multiple times by indirect recursion? Can this be on purpose? It happens when I have this: 1) A document with unsaved with changes 2) Terminate the app via CMD-Q 3) Answer Don't Save in the save-changes-sheet This doesn't smell right. I override -close and call super right away, doing some cleanup work afterwards. Under some bizarre situations which I have not been able to recreate it gets called up to 4 times. I'm pasting the call stack (line 366 is the call to super, line 375 is my breakpoint). Regards Markus #0 0x000134d8 in -[MyDocument close] at /Users/markus/Projects/MyApp/src/MyDocument.m:375 #1 0x7fff8bed7d25 in -[NSWindowController _windowDidClose] () #2 0x7fff8a30ddf0 in -[QLSeamlessDocumentCloser closeWindow:contentFrame:withBlock:] () #3 0x7fff8baa8602 in -[NSWindow _close] () #4 0x7fff8bbe1c74 in -[NSDocument close] () #5 0x000133c9 in -[MyDocument close] at /Users/markus/Projects/MyApp/src/MyDocument.m:366 #6 0x7fff8bbf342e in __-[NSDocumentController closeAllDocumentsWithDelegate:didCloseAllSelector:contextInfo:]_block_invoke_3 () #7 0x7fff8bbf54c5 in -[NSDocumentController _something:didSomething:soContinue:] () #8 0x7fff8bbd62a8 in __-[NSDocument canCloseDocumentWithDelegate:shouldCloseSelector:contextInfo:]_block_invoke_2 () #9 0x7fff8bbd5ec1 in __-[NSDocument canCloseDocumentWithDelegate:shouldCloseSelector:contextInfo:]_block_invoke_11 () #10 0x7fff8bbe8e08 in -[NSDocument _something:wasPresentedWithResult:soContinue:] () #11 0x7fff8bad8a4d in -[NSAlert didEndAlert:returnCode:contextInfo:] () #12 0x7fff8bae53df in -[NSApplication endSheet:returnCode:] () #13 0x7fff8bad8913 in -[NSAlert buttonPressed:] () #14 0x7fff8053770d in -[NSObject performSelector:withObject:] () #15 0x7fff8b934f7e in -[NSApplication sendAction:to:from:] () #16 0x7fff8b934eb2 in -[NSControl sendAction:to:] () #17 0x7fff8b934ddd in -[NSCell _sendActionFrom:] () #18 0x7fff8b9342a0 in -[NSCell trackMouse:inRect:ofView:untilMouseUp:] () #19 0x7fff8b9b3fc4 in -[NSButtonCell trackMouse:inRect:ofView:untilMouseUp:] () #20 0x7fff8b932eaa in -[NSControl mouseDown:] () #21 0x7fff8b8fe348 in -[NSWindow sendEvent:] () #22 0x7fff8b897a55 in -[NSApplication sendEvent:] () #23 0x7fff8bae427e in -[NSApplication _shouldTerminate] () #24 0x7fff8b838115 in -[NSApplication terminate:] () #25 0x00010001a4a3 in -[AppDelegate terminate:] at /Users/markus/Projects/rubiTrack/src/AppDelegate.m:219 #26 0x7fff8053770d in -[NSObject performSelector:withObject:] () #27 0x7fff8b934f7e in -[NSApplication sendAction:to:from:] () #28 0x7fff8ba21bfb in -[NSMenuItem _corePerformAction] () #29 0x7fff8ba21932 in -[NSCarbonMenuImpl performActionWithHighlightingForItemAtIndex:] () #30 0x7fff8b99f524 in -[NSMenu performKeyEquivalent:] () #31 0x7fff8b99e175 in -[NSApplication _handleKeyEquivalent:] () #32 0x7fff8b897536 in -[NSApplication sendEvent:] () #33 0x7fff8b82e0c6 in -[NSApplication run] () #34 0x7fff8baaa244 in NSApplicationMain () #35 0x0001b552 in main at /Users/markus/Projects/MyApp/src/main.m:22 #36 0x000121c4 in start () -- __ Markus Spoettl
Re: NSDocument -close called multiple times?
No. -[NSDocument close] is non-cancellable and non-reversible. On Sep 21, 2012, at 9:55 AM, Markus Spoettl ms_li...@shiftoption.com wrote: OK, so one further question: Is there any chance that if -close is called the document won't actually be closed and stays open? Regards Markus On 9/21/12 6:49 PM, Kevin Perry wrote: Oh dear. Forget you heard me mention anything about unpublished API. The lack of an _ threw me off... Yes, you'll probably want to keep your own flag. -KP On Sep 20, 2012, at 11:41 PM, Markus Spoettl ms_li...@shiftoption.com wrote: Just to clarify: -isClosed is not something that is available on NSDocument or NSWindowController, did you mean to say that I'll have to keep a flag myself? Regards Markus On 9/20/12 6:53 PM, Kevin Perry wrote: This is an known and unfortunate result of the current architecture of NSWindow, NSWindowController, and NSDocument. There isn't any documentation I'm aware of that explicitly states that -close can be invoked re-entrantly, but it can be deduced from the existing documentation: On -[NSDocument close]: The default implementation of this method … sends each of the document's window controllers a -close message On -[NSWindowController close]: If the controller belongs to a document and it is either the last controller for the document or -shouldCloseDocument is YES, then this will also -close the document. The best way around this at the moment is to first verify [self isClosed] == NO before calling super and doing your own work. [kevin perry]; On Sep 19, 2012, at 1:06 PM, Markus Spoettl ms_li...@shiftoption.com wrote: Why does AppKit call into NSDocument's -close multiple times by indirect recursion? Can this be on purpose? It happens when I have this: 1) A document with unsaved with changes 2) Terminate the app via CMD-Q 3) Answer Don't Save in the save-changes-sheet This doesn't smell right. I override -close and call super right away, doing some cleanup work afterwards. Under some bizarre situations which I have not been able to recreate it gets called up to 4 times. I'm pasting the call stack (line 366 is the call to super, line 375 is my breakpoint). Regards Markus #00x000134d8 in -[MyDocument close] at /Users/markus/Projects/MyApp/src/MyDocument.m:375 #10x7fff8bed7d25 in -[NSWindowController _windowDidClose] () #20x7fff8a30ddf0 in -[QLSeamlessDocumentCloser closeWindow:contentFrame:withBlock:] () #30x7fff8baa8602 in -[NSWindow _close] () #40x7fff8bbe1c74 in -[NSDocument close] () #50x000133c9 in -[MyDocument close] at /Users/markus/Projects/MyApp/src/MyDocument.m:366 #60x7fff8bbf342e in __-[NSDocumentController closeAllDocumentsWithDelegate:didCloseAllSelector:contextInfo:]_block_invoke_3 () #70x7fff8bbf54c5 in -[NSDocumentController _something:didSomething:soContinue:] () #80x7fff8bbd62a8 in __-[NSDocument canCloseDocumentWithDelegate:shouldCloseSelector:contextInfo:]_block_invoke_2 () #90x7fff8bbd5ec1 in __-[NSDocument canCloseDocumentWithDelegate:shouldCloseSelector:contextInfo:]_block_invoke_11 () #10 0x7fff8bbe8e08 in -[NSDocument _something:wasPresentedWithResult:soContinue:] () #11 0x7fff8bad8a4d in -[NSAlert didEndAlert:returnCode:contextInfo:] () #12 0x7fff8bae53df in -[NSApplication endSheet:returnCode:] () #13 0x7fff8bad8913 in -[NSAlert buttonPressed:] () #14 0x7fff8053770d in -[NSObject performSelector:withObject:] () #15 0x7fff8b934f7e in -[NSApplication sendAction:to:from:] () #16 0x7fff8b934eb2 in -[NSControl sendAction:to:] () #17 0x7fff8b934ddd in -[NSCell _sendActionFrom:] () #18 0x7fff8b9342a0 in -[NSCell trackMouse:inRect:ofView:untilMouseUp:] () #19 0x7fff8b9b3fc4 in -[NSButtonCell trackMouse:inRect:ofView:untilMouseUp:] () #20 0x7fff8b932eaa in -[NSControl mouseDown:] () #21 0x7fff8b8fe348 in -[NSWindow sendEvent:] () #22 0x7fff8b897a55 in -[NSApplication sendEvent:] () #23 0x7fff8bae427e in -[NSApplication _shouldTerminate] () #24 0x7fff8b838115 in -[NSApplication terminate:] () #25 0x00010001a4a3 in -[AppDelegate terminate:] at /Users/markus/Projects/rubiTrack/src/AppDelegate.m:219 #26 0x7fff8053770d in -[NSObject performSelector:withObject:] () #27 0x7fff8b934f7e in -[NSApplication sendAction:to:from:] () #28 0x7fff8ba21bfb in -[NSMenuItem _corePerformAction] () #29 0x7fff8ba21932 in -[NSCarbonMenuImpl performActionWithHighlightingForItemAtIndex:] () #30 0x7fff8b99f524 in -[NSMenu performKeyEquivalent:] () #31 0x7fff8b99e175 in -[NSApplication _handleKeyEquivalent:] () #32 0x7fff8b897536 in
iOS:targeting iOS3 through iOS6
Hello, all … The iPhone5 and iOS6 is out now, so a client wants me to update the apps i've done for them. The thing is, they still have users on first-generation devices and iPhone 3Gs, so I need to make sure the apps still work there, while also taking advantage of the larger display of the new iPhone / iPod touch. I've kept Xcode 4.4.1 so I can target armv6, and i've Xcode 4.5 to target the new. I'm thinking i'll have to build these apps with 4.4.1, then again with 4.5, and lipo them together. Questions I have: 1. Is this correct? If not, how do I target old and new devices? 2. Are there examples that I could reference? I appreciate any assistance / pointers :-) Regards, John ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post 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
iPad drawing and screen rotation
I have a master detail project where I draw Bezier paths in the detail view. On rotation from portrait to landscape (or vice versa) the proportions of the drawings are distorted. For example, a circle in one orientation becomes an oval in the other. What is the best way to maintain the aspect ratio of my drawings through screen rotation? Should I be embedding a second view to take the drawing in the detail view and adjusting the autosizing of this second view to keep it a fixed size? Thanks, Don Don Hall Apps More Software Design, Inc. d...@appsandmore.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: kABHomeLabel … and companions
On Sep 13, 2012, at 7:45 PM, Erik Stainsby erik.stain...@roaringsky.ca wrote: Hello folks, So the AddressBook framework's xxxLabel keys render out as strings encoded like so: _$!Home!$_, _$!Work!$_, _$!Mobile!$_ Is there framework method I am meant to use with the property keys kABHomeLabel, kABWorkLabel, etc, to render a legible text outcome ? Or am I meant to create my own lookup reference and to translate them as I see fit ? Try this // // Localization of property or label // // Returns the localized version of built in properties, labels or keys // Returns propertyOrLabel if not found (e.g. if not built in) NSString *ABLocalizedPropertyOrLabel(NSString *propertyOrLabel); in ABGlobals.h Erik Stainsby erik.stain...@roaringsky.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/demarco%40apple.com This email sent to dema...@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: kABHomeLabel … and companions
That is the one. Found it the other day. Tanks Vince. Erik Stainsby erik.stain...@roaringsky.ca On 2012-09-21, at 1:33 PM, Vince DeMarco dema...@apple.com wrote: On Sep 13, 2012, at 7:45 PM, Erik Stainsby erik.stain...@roaringsky.ca wrote: Hello folks, So the AddressBook framework's xxxLabel keys render out as strings encoded like so: _$!Home!$_, _$!Work!$_, _$!Mobile!$_ Is there framework method I am meant to use with the property keys kABHomeLabel, kABWorkLabel, etc, to render a legible text outcome ? Or am I meant to create my own lookup reference and to translate them as I see fit ? Try this // // Localization of property or label // // Returns the localized version of built in properties, labels or keys // Returns propertyOrLabel if not found (e.g. if not built in) NSString *ABLocalizedPropertyOrLabel(NSString *propertyOrLabel); in ABGlobals.h Erik Stainsby erik.stain...@roaringsky.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/demarco%40apple.com This email sent to dema...@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: drawGlyphsForGlyphRange layout issue
On 21 Sep 2012, at 17:12, Ross Carter rosscarter...@me.com wrote: On Sep 21, 2012, at 6:54 AM, jonat...@mugginsoft.com jonat...@mugginsoft.com wrote: The following is used to draw a glyph representing a tab character in an NSLayoutManager subclass. When using say the Monaco font everything looks fine. When switching to Menlo however the glyphs drawn in the method below are positioned lower on the line than those drawn by the super implementation. Not sure this will help, but you might compare the descender value for the 2 fonts and see if the difference is equal to the positioning problem. The font metrics are different (see below). I have studied the font metrics in the font handling section of the Cocoa text architecture guide but I cannot quite see how the offset arises. Perhaps I should use core text directly to draw the glyph rather than using [charString drawAtPoint:pointToDrawAt withAttributes:attributes]; Kyle I watched the WWDC 2012 Font session. Interesting but it didn't unscramble things for me. I will try posting to the core text list. 2012-09-21 21:00:18.515 Fragaria[23292:303] Context isFlipped = 1 2012-09-21 21:00:18.528 Fragaria[23292:303] baseLineOffset = 10.00, lineHeight = 13.00 2012-09-21 21:00:18.539 Fragaria[23292:303] descender = -2.594238 2012-09-21 21:00:18.549 Fragaria[23292:303] pointToDrawAt x = 5.00, y = 13.00 2012-09-21 21:00:18.550 Fragaria[23292:303] glyphFragment x = 0.00, y = 13.00, width = 677.00, height = 13.00 2012-09-21 21:00:18.553 Fragaria[23292:303] pointToDrawAt x = 5.00, y = 13.00 2012-09-21 21:00:18.554 Fragaria[23292:303] glyphFragment x = 0.00, y = 26.00, width = 677.00, height = 13.00 2012-09-21 21:03:50.519 Fragaria[23292:303] Context isFlipped = 1 2012-09-21 21:03:50.519 Fragaria[23292:303] baseLineOffset = 11.00, lineHeight = 15.00 2012-09-21 21:03:50.520 Fragaria[23292:303] descender = -2.75 2012-09-21 21:03:50.520 Fragaria[23292:303] pointToDrawAt x = 5.00, y = 15.00 2012-09-21 21:03:50.520 Fragaria[23292:303] glyphFragment x = 0.00, y = 15.00, width = 677.00, height = 15.00 2012-09-21 21:03:50.521 Fragaria[23292:303] pointToDrawAt x = 5.00, y = 15.00 2012-09-21 21:03:50.521 Fragaria[23292:303] glyphFragment x = 0.00, y = 30.00, width = 677.00, height = 15.00 Regards Jonathan Mitchell Mugginsoft LLP KosmicTask - the Integrated Scripting Environment for OS X. http://www.mugginsoft.com/KosmicTask ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post 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: iPad drawing and screen rotation
On Sep 21, 2012, at 12:18 PM, Donald Hall d...@appsandmore.com wrote: I have a master detail project where I draw Bezier paths in the detail view. On rotation from portrait to landscape (or vice versa) the proportions of the drawings are distorted. For example, a circle in one orientation becomes an oval in the other. This shouldn’t be happening if the coordinates you draw to are the same — the graphics coordinate system has the same scale in x and y. Is it possible you’re deriving your bezier coordinates from the height and width of the view, which will change as the device is rotated? —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
NSApplicationShowExceptions - useful on main thread only?
Hi all, The 10.7 release notes say: AppKit now has the ability to report uncaught exceptions. It is controlled by a user default: NSApplicationShowExceptions (YES/NO) My next version will require 10.7+, so I'm finally taking a look at this thing. It seems that it only works for the main thread, that is, if there's an uncaught exception on the main thread I get the nice error UI. But if an uncaught exception occurs on a non-main-NSThread or dispatch queue I get no nice UI. Can anyone confirm/deny? Anyone shipping with NSApplicationShowExceptions=YES? Cheers, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post 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
NSSearchField(Cell) changes size with typing
… and I can't stop it. Argh. There is nothing expressed in my code which addresses the searchField's size methods: – searchTextRectForBounds: – searchButtonRectForBounds: – cancelButtonRectForBounds: This is totally whacky and I'm hoping someone on the list has an immediate Oh yes, just do x moment. Erik Stainsby erik.stain...@roaringsky.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: NSSearchField(Cell) changes size with typing
On 2012-09-21, at 4:06 PM, Erik Stainsby erik.stain...@roaringsky.ca wrote: … and I can't stop it. Argh. There is nothing expressed in my code which addresses the searchField's size methods: – searchTextRectForBounds: – searchButtonRectForBounds: – cancelButtonRectForBounds: This is totally whacky and I'm hoping someone on the list has an immediate Oh yes, just do x moment. Erik Stainsby erik.stain...@roaringsky.ca It is behaving as if sizeToFit: were being called on it with each key stroke. OS X SDK 10.8.2 (deploy target 10.7) Xcode 4.4.1 Erik ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post 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: Autosave in place - common use case that makes me hate it
I think if you have really good undo support people find autosave less of an annoyance. Most people took advantage of the save-before-experimenting method because several apps had bad or nonexistent undo support so saving was the only way to reliably go back. On Sep 21, 2012, at 10:05 AM, Uli Kusterer wrote: I run into it as well. But less and less. It's the same as the reversal of the scroll wheel direction: It's hard to undo more than a decade of rote memorization. But it's possible It's an aspect of having to manually save that we power users have taken advantage of as a feature. The real world doesn't work like that. New users don't expect it to work like that. For everyone but us damaged souls, this is actually an improvement. If you wanted to scribble additional annotations into a drawing, you'd make a photocopy of it. On the computer, you just have to train yourself to duplicate the file before you do these changes. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post 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
How to prevent Segue with modal form-sheet and AutoLayout from resizing my view?
This problem is kind of tough to describe without pictures. Thus, there will be links to graphical images to help you understand my dilemma. So, I'm trying to display a modal form-sheet over the app's main view using Storyboards and a segue. I'm using Xcode 4.5 with iOS 6 to implement an iPad application. I'm also using AutoLayout. I already have a version of this code working on iOS 5.1 with springs and struts but I want to make the conversion to AutoLayout as I add support for iOS 6. Don't ask why; stay focused on the issue at hand, please. This is what I'm trying to display. https://dl.dropbox.com/u/4920112/1.PNG https://dl.dropbox.com/u/4920112/2.PNG https://dl.dropbox.com/u/4920112/3.PNG When I activate the segue and try to display the modal form, the form automatically resizes to cover the lower-left portion of the iPad view. In the console there are no exceptions due to conflicting constraints. There is also no reported ambiguity among the constraints in question. This is what I'm actually getting. https://dl.dropbox.com/u/4920112/4.png I added a few breakpoints to execute po self.view so I could see how the view was configured at the following points in the code: 1) Start of -viewDidLoad 2) Context of -viewDidLoad after executing self.view.autoresizingMask = UIViewAutoresizingNone; 3) Start of -viewDidAppear Here is the output from the console as a result of these three breakpoints: 1) (UIView *) $0 = 0x1dd969b0 UIView: 0x1dd969b0; frame = (0 0; 540 620); autoresize = RM+BM; autoresizesSubviews = NO; layer = CALayer: 0x1dd96aa0 2) (UIView *) $1 = 0x1dd969b0 UIView: 0x1dd969b0; frame = (0 0; 540 620); autoresizesSubviews = NO; layer = CALayer: 0x1dd96aa0 The change from 540x620 to 1024x748 is the problem. 3) (UIView *) $2 = 0x1dd969b0 UIView: 0x1dd969b0; frame = (0 0; 1024 748); clipsToBounds = YES; autoresize = W+H; autoresizesSubviews = NO; layer = CALayer: 0x1dd96aa0 This seems to tell me that the auto-resizing mask is successfully cleared but then re-instated between the call to -viewDidLoad and -viewDidAppear. Of course, I'm assuming this is the issue. I cannot assign a constraint to the main view itself in order to pin width and height. When I select the view, IB grays out the option. Anyone further along on the AutoLayout curve who can give me some suggestions as to how to prevent my form from being resized once it is loaded? -Michael ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post 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: drawGlyphsForGlyphRange layout issue
On 21/09/2012, at 8:54 PM, jonat...@mugginsoft.com wrote: The following is used to draw a glyph representing a tab character in an NSLayoutManager subclass. You might investigate an alternative (and much easier) solution. NSLayoutManager adopts the NSGlyphStorage protocol. That protocol declares a method, -layoutOptions, and one of the flags it can return is NSShowInvisibleGlyphs. Simply returning that flag may be all you need to do. In fact I think this is set for you when you call -setShowsInvisibleCharacters:YES I guess the difference is that it's all or nothing, which might be not the desired result. Another approach is to override -showCGGlyphs:positions:count:font:matrix:attributes:inContext: which is the primitive drawing method. All of the positioning and context flippedness has been handled by this point, so you can usually just go ahead and draw the characters. Inserting some other glyph at this point for the tab should be straightforward. --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: Autosave in place - common use case that makes me hate it
We had a problem recently in that I was telling my team members to duplicate a PNG file be doing a save as and turning the alpha channel off. They were in Lion and you couldn't Save As out of Preview and name a file a new name and turn off the alpha channel. In the time it took him to try and figure out how to do that, I saved all the files without the alpha, zipped them and mailed them to him from Snow Leopard. But still, we shouldn't have had to do that and our team (besides me) has not upgraded to Mountain Lion yet. All this pushing of simplified metaphors since Lion has really ended up in loads of wasted time on our end and less productivity. Hopefully we can all upgrade to ML next week remove some of the pain and wasted time. On Sep 21, 2012, at 7:24 PM, Michael Vannorsdel wrote: I think if you have really good undo support people find autosave less of an annoyance. Most people took advantage of the save-before-experimenting method because several apps had bad or nonexistent undo support so saving was the only way to reliably go back. On Sep 21, 2012, at 10:05 AM, Uli Kusterer wrote: I run into it as well. But less and less. It's the same as the reversal of the scroll wheel direction: It's hard to undo more than a decade of rote memorization. But it's possible It's an aspect of having to manually save that we power users have taken advantage of as a feature. The real world doesn't work like that. New users don't expect it to work like that. For everyone but us damaged souls, this is actually an improvement. If you wanted to scribble additional annotations into a drawing, you'd make a photocopy of it. On the computer, you just have to train yourself to duplicate the file before you do these changes. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post 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/zav%40mac.com This email sent to z...@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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Autosave in place - common use case that makes me hate it
On 22/09/2012, at 2:05 AM, Uli Kusterer witness.of.teacht...@gmx.net wrote: I run into it as well. But less and less. It's the same as the reversal of the scroll wheel direction: It's hard to undo more than a decade of rote memorization. But it's possible It's an aspect of having to manually save that we power users have taken advantage of as a feature. I think the problem isn't so much the muscle memory of manually saving, it's the fact that NOT saving has been (and still is, even for a new user) a deliberate decision. It's an action in itself, one that is very efficient because it requires NO STEPS. Of course an action by doing nothing is not something that any software can detect, which is why I think the autosave model is so frustrating. It assumes that all actions are affirmative actions that it can detect, and there can be no such thing as a deliberate action that involves doing nothing. It's a broader issue than the case of saving, since humans very often act positively by doing nothing in all sorts of situations. The design of autosave denies this possibility, which is why it's so annoying - it forces a person to think like a computer. If doing nothing is no longer allowed as a positive action, all of the necessary workarounds must be less efficient, because they all involve some steps. --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: drawGlyphsForGlyphRange layout issue
On Fri, Sep 21, 2012, at 05:33 PM, Graham Cox wrote: Another approach is to override -showCGGlyphs:positions:count:font:matrix:attributes:inContext: which is the primitive drawing method. All of the positioning and context flippedness has been handled by this point, so you can usually just go ahead and draw the characters. Inserting some other glyph at this point for the tab should be straightforward. I would imagine it would be much better to modify the glyph stream at one of its defined override points: the glyph generator. Subclass NSGlyphGenerator and override -generateGlyphsForGlyphStorage:desiredNumberOfCharacters:glyphIndex:characterIndex: to call through to the sharedGlyphGenerator's implementation to get the standard glyphs before the first tab character, generate a tab glyph and insert it into the glyph storage, and then call through to the sharedGlyphGenerator to generate the remaining characters (repeat this process for each tab character for which a glyph is requested). Call -setGlyphGenerator: on your layout manager to provide an instance of your glyph generator subclass. Aki Inoue describes this approach in the WWDC 2010 video for Session 114 - Advanced Cocoa Text Tips and Tricks. --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: Autosave in place - common use case that makes me hate it
On 21 Sep 2012, at 4:24 pm, Michael Vannorsdel mikev...@gmail.com wrote: I think if you have really good undo support people find autosave less of an annoyance. I think if you have really good first aid service then people find repeatedly tripping down the stairs less of an annoyance. b -- Ben Kennedy, chief magician Zygoat Creative Technical Services http://www.zygoat.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: Autosave in place - common use case that makes me hate it
On Sep 21, 2012, at 6:20 PM, Ben Kennedy b...@zygoat.ca wrote: On 21 Sep 2012, at 4:24 pm, Michael Vannorsdel mikev...@gmail.com wrote: I think if you have really good undo support people find autosave less of an annoyance. I think if you have really good first aid service then people find repeatedly tripping down the stairs less of an annoyance. People, **STOP.** This is not a productive thread. You are wasting your own and everyone else's time. Slinging one-liners here isn't going to change Apple's mind. If you feel like you have a compelling argument for abandoning autosavesInPlace, write up a bug and/or compose a well-thought-out blog post. You may be very correct. But this back-and-forth is useless. --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: iPad drawing and screen rotation
Anybody remember Steve Jobs having a fit about ³square pixels² somewhere back in the Lisa or early Mac days? The scale should not change on a rotation, unless you are somehow setting the bounds rect in your drawing view instead of the frame rect when rotated. That could do it. On 9/21/12 7:50 PM, cocoa-dev-requ...@lists.apple.com cocoa-dev-requ...@lists.apple.com wrote: I have a master detail project where I draw Bezier paths in the detail view. On rotation from portrait to landscape (or vice versa) the proportions of the drawings are distorted. For example, a circle in one orientation becomes an oval in the other. What is the best way to maintain the aspect ratio of my drawings through screen rotation? Should I be embedding a second view to take the drawing in the detail view and adjusting the autosizing of this second view to keep it a fixed size? ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post 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: Autosave in place - common use case that makes me hate it
I'm mostly saying is it's something we have to cope with and find ways to make it work for special cases since it's hard to get Apple to let go of mechanics they created to try and make life easier for users (it can be argued whether or not this is true). I've tried the duplicating a backup in the Caches folder to a quick restore but then ran into issues with sandboxing and multiple user accounts taking turns working on a joint document. So my choices were to track and litter common directories with file duplicates or just make sure undo can carry the user back and forth to the point they wanted to go, which isn't always all the way back to last save. I was just sharing my experience that my users, after some adaptation time, reported finding undo was more useful than closing, clicking don't save, finding and reopening the document, and starting over. Most of them had learned to ignore the chained undo ability due to slow implementation at the beginning of OS X. And it's less stress on me simply because the document copies were getting unwieldy and made me nervous unsupported behavior would be broken all over again with another OS X release. I had figured the undo route would have more lasting power through the direction changes of OS X. My shared opinion; the future will probably prove me wrong. However, I do have an appreciation for tried and true methods disappearing and understand the frustration with redesigning app behavior over decisions you didn't choose. On Sep 21, 2012, at 7:20 PM, Ben Kennedy wrote: I think if you have really good first aid service then people find repeatedly tripping down the stairs less of an annoyance. On Sep 21, 2012, at 6:50 PM, Alex Zavatone wrote: We had a problem recently in that I was telling my team members to duplicate a PNG file be doing a save as and turning the alpha channel off. They were in Lion and you couldn't Save As out of Preview and name a file a new name and turn off the alpha channel. In the time it took him to try and figure out how to do that, I saved all the files without the alpha, zipped them and mailed them to him from Snow Leopard. But still, we shouldn't have had to do that and our team (besides me) has not upgraded to Mountain Lion yet. All this pushing of simplified metaphors since Lion has really ended up in loads of wasted time on our end and less productivity. Hopefully we can all upgrade to ML next week remove some of the pain and wasted time. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: kABHomeLabel … and companions
On iOS you would be looking for ABPersonCopyLocalizedPropertyName() on the Mac
you would be looking for ABCopyLocalizedPropertyOrLabel().
-Richard
On 13/09/2012, at 9:33:06 PM, Erik Stainsby erik.stain...@roaringsky.ca wrote:
I understand that ABAddressBook methods are concerned with ABPerson and
ABGroup entities, subclasses of ABRecord.
However, the ABMultiValue collections are less intuitive. Among these are
stored the (potentially) multiple instances of addresses, phone numbers and
email addresses. For each instance of user supplied data, a multiValue
object can store - in properties keyed with kABXxxx keys - arbitrary labels:
home, work, iPhone, mobile, etc. The documentation leaves much to be
desired, but in particular, I cannot glean how to retrieve a user-supplied
string from a given multiValue object.
Some code:
Given some address, stored in an ABMultiValue object, such that:
- (void) unwrapMV:(ABMultiValue*)mv atIndex:(int)index {
NSString * _uuid = [mv identifierAtIndex:index];
NSString * _label = [mv labelForIdentifier:[mv
identifierAtIndex:index]];
NSDictionary * _dict = [mv valueAtIndex:index];
// am I the identified primary entry?
BOOL_primary= ([mv primaryIdentifier] == self.uuid)?
YES: NO;
NSLog( @%@, _label) ;
}
produces _$!Home!$_,
or one of the other variants of the actual value of the key, not the value it
refers to.
Clearly I am failing to understand where these strings are being stored.
Erik Stainsby
erik.stain...@roaringsky.ca
On 2012-09-13, at 9:04 PM, Jerry Krinock je...@ieee.org wrote:
On 2012 Sep 13, at 19:45, Erik Stainsby erik.stain...@roaringsky.ca wrote:
So the AddressBook framework's xxxLabel keys render out as strings encoded
like so: _$!Home!$_, _$!Work!$_, _$!Mobile!$_ Is there framework
method I am meant to use with the property keys kABHomeLabel, kABWorkLabel,
etc, to render a legible text outcome
Maybe you're looking for -[ABRecord valueForProperty:]. Note that
ABAddressBook methods typically return ABPerson objects, and ABPerson
inherits from ABRecord.
If that doesn't explain it, post some code.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post 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/erik.stainsby%40roaringsky.ca
This email sent to erik.stain...@roaringsky.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/heardrwt%40gmail.com
This email sent to heard...@gmail.com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Access Contacts (Address Book) Question
Per the tccutil(1) man page, you can clear Contacts privacy preferences with the shell command tccutil reset AddressBook The why string comes from the NSContactsUsageDescription (Privacy - Contacts Usage Description in Xcode) key in Info.plist: $ defaults read /Applications/iWork '09/Pages.app/Contents/Info NSContactsUsageDescription | fold -sw 72 This will let you drag contacts to Pages, and let Pages automatically add your name to templates, tracked changes, and more. To change this setting, open System Preferences and choose Security Privacy. This is documented in both the _Address Book Programming Guide for Mac_ and the _Information Property List Key Reference_, and discussed in the WWDC Privacy Support session. Cheers, Jason On Sep 17, 2012, at 3:48, Manfred Schwind li...@mani.de wrote: Hi, when an app tries to access the contacts (via Address Book Framework), OS X recently asks the user first if this should be allowed. This question is asked only once per app, then the app is on the list and this list can be seen in System Preferences - Security Privacy - Privacy - Contacts. There you can also change your decision later on (not sure if many people know this). My first question is: How can I delete an app from this list to test the behaviour of the app when OS X asks the address book question? Furthermore I am not entirely sure, but I think when this contacts questions was asked for Pages I saw a description WHY Pages want to access the contacts. But I could not find any API to set such a description. So my second question is if there is such an API that I may have overlooked? It would be really great to be able to inform the user why an app want to access contacts to help him decide wether or not he wants to allow it. Is this overall new sandboxed contacts accessing behaviour of OS X documented somewhere? Regards, Mani -- mani.de - friendly software ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post 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/jasomill%40me.com This email sent to jasom...@me.com 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
Share NSView between processes
At a high level, I'd like to share an NSView between processes. On Windows, you can share HWNDs across the process boundary, but on mac this doesn't seem possible (http://stackoverflow.com/questions/583202/mac-os-x-can-one-process-render-to-another-processs-window). To get around this, I'm hiding my subprocess' view and using the IOSurface APIs (http://developer.apple.com/library/mac/#documentation/Miscellaneous/Reference/IOSurfaceAPI_header_reference/Reference/reference.html) to get the bitmap back into the parent process. I've had some success with this approach and it seems performant enough. The problem I'm having now is in sending mouse events to the subprocess' view. Calling [NSApp sendEvent] from the subprocess, the events don't arrive, which I guess is because the application is not in the foreground. I've also tried using CGEventPost which requires the view to be visible and the API moves the mouse, two non-starters. Based on this research it appears impossible to send mouse events to views without key focus. The next approach I've been considering, which is even more outlandish than my current setup, is to overlay the subprocess' window on top of parent's window. There are a number of edge cases I'm not keen on handling, and that's assuming it's efficient enough to not look terrible. So at this stage I thought I'd take a step back and seek help. Do my assumptions look valid? Is there perhaps an alternative approach? Thanks for any help. Zak ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post 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
Toddler-proofing an app (disabling spotlight keyboard shortcut)?
My 20 month old daughter loves to bang on the keys of the keyboard. I made a simple cocos2d app that shows random animal pictures (with noises) when she presses keys. (This has proved very popular with her and she now can identify all of the animals!) Anyhow, she'll sit on my lap and bang the keyboard for 4-5 minutes at a time. The problem is that she very often hits command-space and then other keys, causing the app to exit full screen and Spotlight to activate. From time to time, she does other things, such as hiding the dock (in the background), switching spaces, etc. Is there a way for me to disable some of these system-level keyboard commands when the app that I made has focus? I came across some old Carbon, namely: void *oldHotKeyMode = PushSymbolicHotKeyMode(kHIHotKeyModeAllDisabled); ... PopSymbolicHotKeyMode(oldHotKeyMode); but I run into compiler errors when I try to use these: ld: symbol(s) not found for architecture x86_64 I'm using Xcode 4.5 and would like to continue using ARC if possible (since GC is depreciated). Any ideas? ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: iOS:targeting iOS3 through iOS6
From my experience that's correct. Apple don't want you to support old hardware so they don't facilitate. When you update Xcode it even deleted old versions if it can find. Also new Xcode doesn't support compiling for pre armv7 (if I'm not mistaken here) meaning only 3GS and newer (iPad one is gone too). So yeah you'll have to go through all those hoops to get legacy stuff running. Cheers, Ivor On 21.09.2012, at 20:43, John Michael Zorko jmzo...@mac.com wrote: Hello, all … The iPhone5 and iOS6 is out now, so a client wants me to update the apps i've done for them. The thing is, they still have users on first-generation devices and iPhone 3Gs, so I need to make sure the apps still work there, while also taking advantage of the larger display of the new iPhone / iPod touch. I've kept Xcode 4.4.1 so I can target armv6, and i've Xcode 4.5 to target the new. I'm thinking i'll have to build these apps with 4.4.1, then again with 4.5, and lipo them together. Questions I have: 1. Is this correct? If not, how do I target old and new devices? 2. Are there examples that I could reference? I appreciate any assistance / pointers :-) Regards, John ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post 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/igor.elland%40me.com This email sent to igor.ell...@me.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: iOS:targeting iOS3 through iOS6
On Sep 21, 2012, at 12:29 , Igor Elland igor.ell...@me.com wrote: 1. Is this correct? If not, how do I target old and new devices? No. Set the deployment target to 3.0. You'll have to take care not to use any new APIs, though. Apple doesn't provide an easy way to ensure you're not doing that. I recommend testing on an old device. -- Rick ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post 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: Share NSView between processes
Well there's CGEventPostToPSN (note you need the ProcessSerialNumber for the process and not its unix pid) but that's mostly useful if you're trying to control an app that's not yours. It might be a better approach to go the IPC route setting up communications and trading data objects between the apps and let them handle their own drawing. Checkout NSConnection and look up the Distributed Objects info on how to share data and communicate with each other with higher level APIs that do a lot of the grunt work for you. NSConnection is pretty flexible. But NSApp's sendEvent is for the process to send events to itself; they won't go to outside processes. On Sep 19, 2012, at 8:05 PM, Zak Nelson wrote: At a high level, I'd like to share an NSView between processes. On Windows, you can share HWNDs across the process boundary, but on mac this doesn't seem possible (http://stackoverflow.com/questions/583202/mac-os-x-can-one-process-render-to-another-processs-window). To get around this, I'm hiding my subprocess' view and using the IOSurface APIs (http://developer.apple.com/library/mac/#documentation/Miscellaneous/Reference/IOSurfaceAPI_header_reference/Reference/reference.html) to get the bitmap back into the parent process. I've had some success with this approach and it seems performant enough. The problem I'm having now is in sending mouse events to the subprocess' view. Calling [NSApp sendEvent] from the subprocess, the events don't arrive, which I guess is because the application is not in the foreground. I've also tried using CGEventPost which requires the view to be visible and the API moves the mouse, two non-starters. Based on this research it appears impossible to send mouse events to views without key focus. The next approach I've been considering, which is even more outlandish than my current setup, is to overlay the subprocess' window on top of parent's window. There are a number of edge cases I'm not keen on handling, and that's assuming it's efficient enough to not look terrible. So at this stage I thought I'd take a step back and seek help. Do my assumptions look valid? Is there perhaps an alternative approach? Thanks for any help. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSApplicationShowExceptions - useful on main thread only?
On Sep 21, 2012, at 5:20 PM, Sean McBride wrote: The 10.7 release notes say: AppKit now has the ability to report uncaught exceptions. It is controlled by a user default: NSApplicationShowExceptions (YES/NO) My next version will require 10.7+, so I'm finally taking a look at this thing. It seems that it only works for the main thread, that is, if there's an uncaught exception on the main thread I get the nice error UI. But if an uncaught exception occurs on a non-main-NSThread or dispatch queue I get no nice UI. Can anyone confirm/deny? Anyone shipping with NSApplicationShowExceptions=YES? I have no inside knowledge, but I think you've misunderstood the purpose of this default. It's simply to change the behavior where AppKit would silently swallow exceptions which reached the event loop. Of course this only applies to the main thread, because that's the only thread which does that. The new default is described as a tool for developers during development. I wouldn't necessarily argue that it _shouldn't_ be enabled for a release version of your app, but it's not really an end-user feature. If you want to change how uncaught exceptions are handled more generally, you should look into Exception Programming Topics: Controlling a Program’s Response to Exceptions https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Exceptions/Tasks/ControllingAppResponse.html and NSExceptionHandler. Of course, you should first strive to make sure your app doesn't raise exceptions, but no amount of programming care or testing can guarantee that it can never happen in the field. 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
