Re: Help: NSScrollView is resizing its documentView down to (0, 0)
On May 5, 2015, at 5:54 PM, Roland King r...@rols.org wrote: Constrain the scrollview to something above it if it needs it, if it’s the whole window, probably doesn’t. Constrain the clipview to all 4 sides of the scrollview. Constrain your view to the top, right and left of the clipview but not the bottom. Override the clipview and return isFlipped=YES I was assuming that the Editor Embed In Scroll view command would set things up to basically work. (The way it used to in the old days.) Whereas the reality is that IB creates the enclosing views for me, but then helpfully avoids actually setting up any of the constraints they need? WTF? Also, where does one go to learn that the above constraints are needed? Is this just knowledge picked up through trial and error? I realy don't want to sound like one of those old farts grousing about the old days, but when I learned Cocoa programming in 2000 I was blown away by how easy everything was and how well IB worked. If I were starting out now, I don't think I'd feel the same way. —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
Re: Help: NSScrollView is resizing its documentView down to (0, 0)
On May 5, 2015, at 4:26 PM, Graham Cox graham@bigpond.com wrote: I don’t know, but I also find setting up simple constraints baffling. Even the most straightforward cases seem to be really hard to get right. Glad to know I'm not the only one. It wouldn't be so bad if there were some real documentation I could read — I would love a fat O'Reilly book on serious AppKit and UIKit GUI implementation — but the Xcode docs only skim the surface and are nearly impossible to find anything in. I was able to get around the resize problem by overriding -resizeWithOldSuperviewSize: to do nothing, so it skips the inherited implementation that destroys the layout. I'm sure this is a terrible kludge, and I'd love to know the real solution, but it works well enough for the demo I need to give on Friday. —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
Re: Core Data sync between iOS and Mac apps
On May 5, 2015, at 2:31 PM, davel...@mac.com wrote: I'm looking into options for building an iOS and Mac app that can sync/share Core Data between them. I'm well aware of the issues with Core Data iCloud syncing in iOS 5 and 6 and that it is supposedly better so I'm willing to try it. I wouldn't recommend it. The sync mechanism for Core Data is IMHO a terrible kludge, and you have zero visibility into the server-side storage nor any ability to diagnose server-side problems. I still see user complaints in reviews of apps that use iCloud sync (Ulysses is one recent example.) On the other hand, I'm biased because I work on a competing sync solution, Couchbase Lite*. It's designed from the ground up to do sync, you can run your own server, it supports multi-user sharing, and it's all open source. It has its own Cocoa API, but you can also use it as a back-end for Core Data. Another solution to look into is Parse**. It's apparently pretty fast and reliable, although as a hosted service you don't have control over the servers (and you have to trust Facebook to play nice with your data.) Dropbox has a data-sync API, but they just announced that they're deprecating it and phasing it out. —Jens * http://www.couchbase.com/nosql-databases/couchbase-mobile http://www.couchbase.com/nosql-databases/couchbase-mobile ** http://parse.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: Help: NSScrollView is resizing its documentView down to (0, 0)
We did this a few months ago When you embed in a scrollview you end up with NSScrollView NSClipView Your View Constrain the scrollview to something above it if it needs it, if it’s the whole window, probably doesn’t. Constrain the clipview to all 4 sides of the scrollview. Constrain your view to the top, right and left of the clipview but not the bottom. Override the clipview and return isFlipped=YES On 6 May 2015, at 00:26, Jens Alfke j...@mooseyard.com wrote: I haven't done much AppKit work in a while. Right now I have a small app where I'm trying to do something very simple: put a custom NSView in a window and make it scrollable. The view determines its own frame size based on the content it needs to display. So all I did was create a new window in IB, add an instance of my view, embed it in an NSScrollView, and set up default constraints for the scroll view so it'll track the window size. It sort of works as long as the window is bigger than my custom view (although the view is pinned to the bottom of the window instead of the top for some reason.) But as soon as I resize the window to a height smaller than the custom view's, the view disappears and never comes back. I added an override of -setFrame: and found that my view's frame is being set to (0, 0, 0, 0) by AppKit while redisplaying the window. I have no idea why this is happening — it probably has something to do with constraints, but I don't understand constraints well enough to know why (and I can't find any clear documentation about how to use constraints with scroll views.) How can I fix this? (OS X 10.10.4, Xcode 6.3.) —Jens * thread #1: tid = 0x691af4, 0x00015c08 Hops`-[RevTreeView setFrame:](self=0x61141600, _cmd=0x7fff8b0c9343, frame=(origin = (x = 0, y = 0), size = (width = 0, height = 0))) + 24 at RevTreeView.m:70, queue = 'com.apple.main-thread', stop reason = breakpoint 3.1 * frame #0: 0x00015c08 Hops`-[RevTreeView setFrame:](self=0x61141600, _cmd=0x7fff8b0c9343, frame=(origin = (x = 0, y = 0), size = (width = 0, height = 0))) + 24 at RevTreeView.m:70 frame #1: 0x7fff9564628f AppKit`-[NSView resizeWithOldSuperviewSize:] + 694 frame #2: 0x7fff9574ce05 AppKit`-[NSView layoutSubtreeIfNeeded] + 810 frame #3: 0x7fff95656e66 AppKit`-[NSView _sendViewWillDrawInRect:clipRootView:] + 47 frame #4: 0x7fff957fad04 AppKit`-[NSView displayRectIgnoringOpacity:inContext:] + 362 frame #5: 0x7fff959354cd AppKit`-[_NSMirrorDocumentView drawRect:] + 265 frame #6: 0x7fff95676859 AppKit`-[NSView(NSInternal) _recursive:displayRectIgnoringOpacity:inGraphicsContext:CGContext:topView:shouldChangeFontReferenceColor:] + 1186 frame #7: 0x7fff95676278 AppKit`__46-[NSView(NSLayerKitGlue) drawLayer:inContext:]_block_invoke + 218 frame #8: 0x7fff95675f21 AppKit`-[NSView(NSLayerKitGlue) _drawViewBackingLayer:inContext:drawingHandler:] + 2407 frame #9: 0x7fff956755a3 AppKit`-[NSView(NSLayerKitGlue) drawLayer:inContext:] + 108 frame #10: 0x7fff958296c6 AppKit`-[_NSBackingLayerContents drawLayer:inContext:] + 145 frame #11: 0x7fff8a669ce7 QuartzCore`-[CALayer drawInContext:] + 119 frame #12: 0x7fff958291fe AppKit`-[_NSTiledLayer drawTile:inContext:] + 625 frame #13: 0x7fff95828f2f AppKit`-[_NSTiledLayerContents drawLayer:inContext:] + 169 frame #14: 0x7fff8a669ce7 QuartzCore`-[CALayer drawInContext:] + 119 frame #15: 0x7fff95828e70 AppKit`-[NSTileLayer drawInContext:] + 169 frame #16: 0x7fff8a6683c7 QuartzCore`CABackingStoreUpdate_ + 3306 frame #17: 0x7fff8a6676d7 QuartzCore`___ZN2CA5Layer8display_Ev_block_invoke + 59 frame #18: 0x7fff8a667694 QuartzCore`x_blame_allocations + 81 frame #19: 0x7fff8a65b43c QuartzCore`CA::Layer::display_() + 1546 frame #20: 0x7fff95828d87 AppKit`-[NSTileLayer display] + 119 frame #21: 0x7fff956c2df4 AppKit`-[_NSTiledLayerContents update:] + 5688 frame #22: 0x7fff956c14c7 AppKit`-[_NSTiledLayer display] + 375 frame #23: 0x7fff8a6597fd QuartzCore`CA::Layer::display_if_needed(CA::Transaction*) + 603 frame #24: 0x7fff8a658e81 QuartzCore`CA::Layer::layout_and_display_if_needed(CA::Transaction*) + 35 frame #25: 0x7fff8a658612 QuartzCore`CA::Context::commit_transaction(CA::Transaction*) + 242 frame #26: 0x7fff8a6583ae QuartzCore`CA::Transaction::commit() + 390 frame #27: 0x7fff9564eae6 AppKit`-[NSWindow _setFrameCommon:display:stashSize:] + 3771 frame #28: 0x7fff95937e73 AppKit`-[NSWindow(NSWindowResizing) _resizeWithEvent:] + 1469 frame #29: 0x7fff957dd47c AppKit`-[NSTitledFrame mouseDown:] + 200 frame #30: 0x7fff957dd3ab AppKit`-[NSThemeFrame mouseDown:] + 68 frame #31: 0x7fff95d4d2fc AppKit`-[NSWindow _reallySendEvent:isDelayedEvent:] +
Re: Help: NSScrollView is resizing its documentView down to (0, 0)
Not exactly the same but I found this doc helpful. https://developer.apple.com/library/ios/technotes/tn2154/_index.html Luther On May 5, 2015, at 7:58 PM, dangerwillrobinsondan...@gmail.com wrote: If you have AutoLayout on in a window it's actually on for all views. NSScrollView and its hierarchy are a bit weird though. Thing to do is create height and width constraints for the document view and outlets for them so you can configure them. If you're using 10.10+ you can make them configurable in IB. Then add a subview as your real document view. For upper left corner origin you need to subclass NSClipView and return YES from an override of isFlipped. Set the class in IB for both. You also want to uncheck the item for translatesAutoresizingMasks If that doesn't appear in IB you can set it in code or just return NO from a getter override. Sent from my iPhone On 2015/05/06, at 1:26, Jens Alfke j...@mooseyard.com wrote: I haven't done much AppKit work in a while. Right now I have a small app where I'm trying to do something very simple: put a custom NSView in a window and make it scrollable. The view determines its own frame size based on the content it needs to display. So all I did was create a new window in IB, add an instance of my view, embed it in an NSScrollView, and set up default constraints for the scroll view so it'll track the window size. It sort of works as long as the window is bigger than my custom view (although the view is pinned to the bottom of the window instead of the top for some reason.) But as soon as I resize the window to a height smaller than the custom view's, the view disappears and never comes back. I added an override of -setFrame: and found that my view's frame is being set to (0, 0, 0, 0) by AppKit while redisplaying the window. I have no idea why this is happening ― it probably has something to do with constraints, but I don't understand constraints well enough to know why (and I can't find any clear documentation about how to use constraints with scroll views.) How can I fix this? (OS X 10.10.4, Xcode 6.3.) ―Jens * thread #1: tid = 0x691af4, 0x00015c08 Hops`-[RevTreeView setFrame:](self=0x61141600, _cmd=0x7fff8b0c9343, frame=(origin = (x = 0, y = 0), size = (width = 0, height = 0))) + 24 at RevTreeView.m:70, queue = 'com.apple.main-thread', stop reason = breakpoint 3.1 * frame #0: 0x00015c08 Hops`-[RevTreeView setFrame:](self=0x61141600, _cmd=0x7fff8b0c9343, frame=(origin = (x = 0, y = 0), size = (width = 0, height = 0))) + 24 at RevTreeView.m:70 frame #1: 0x7fff9564628f AppKit`-[NSView resizeWithOldSuperviewSize:] + 694 frame #2: 0x7fff9574ce05 AppKit`-[NSView layoutSubtreeIfNeeded] + 810 frame #3: 0x7fff95656e66 AppKit`-[NSView _sendViewWillDrawInRect:clipRootView:] + 47 frame #4: 0x7fff957fad04 AppKit`-[NSView displayRectIgnoringOpacity:inContext:] + 362 frame #5: 0x7fff959354cd AppKit`-[_NSMirrorDocumentView drawRect:] + 265 frame #6: 0x7fff95676859 AppKit`-[NSView(NSInternal) _recursive:displayRectIgnoringOpacity:inGraphicsContext:CGContext:topView:shouldChangeFontReferenceColor:] + 1186 frame #7: 0x7fff95676278 AppKit`__46-[NSView(NSLayerKitGlue) drawLayer:inContext:]_block_invoke + 218 frame #8: 0x7fff95675f21 AppKit`-[NSView(NSLayerKitGlue) _drawViewBackingLayer:inContext:drawingHandler:] + 2407 frame #9: 0x7fff956755a3 AppKit`-[NSView(NSLayerKitGlue) drawLayer:inContext:] + 108 frame #10: 0x7fff958296c6 AppKit`-[_NSBackingLayerContents drawLayer:inContext:] + 145 frame #11: 0x7fff8a669ce7 QuartzCore`-[CALayer drawInContext:] + 119 frame #12: 0x7fff958291fe AppKit`-[_NSTiledLayer drawTile:inContext:] + 625 frame #13: 0x7fff95828f2f AppKit`-[_NSTiledLayerContents drawLayer:inContext:] + 169 frame #14: 0x7fff8a669ce7 QuartzCore`-[CALayer drawInContext:] + 119 frame #15: 0x7fff95828e70 AppKit`-[NSTileLayer drawInContext:] + 169 frame #16: 0x7fff8a6683c7 QuartzCore`CABackingStoreUpdate_ + 3306 frame #17: 0x7fff8a6676d7 QuartzCore`___ZN2CA5Layer8display_Ev_block_invoke + 59 frame #18: 0x7fff8a667694 QuartzCore`x_blame_allocations + 81 frame #19: 0x7fff8a65b43c QuartzCore`CA::Layer::display_() + 1546 frame #20: 0x7fff95828d87 AppKit`-[NSTileLayer display] + 119 frame #21: 0x7fff956c2df4 AppKit`-[_NSTiledLayerContents update:] + 5688 frame #22: 0x7fff956c14c7 AppKit`-[_NSTiledLayer display] + 375 frame #23: 0x7fff8a6597fd QuartzCore`CA::Layer::display_if_needed(CA::Transaction*) + 603 frame #24: 0x7fff8a658e81 QuartzCore`CA::Layer::layout_and_display_if_needed(CA::Transaction*) + 35 frame #25: 0x7fff8a658612 QuartzCore`CA::Context::commit_transaction(CA::Transaction*) + 242 frame #26: 0x7fff8a6583ae
Re: Issues with implementing WYWIWYG font menu
On 6 May 2015, at 7:21 am, David Durkee da...@dwdurkee.com wrote: (the fonts I’m guessing)? Why guess when you can measure? However it is almost certainly the fonts. No matter how you end up displaying them, you still need to initialize them at some point. You can probably warm up the Font Manager by iterating through all of its fonts (maybe as a background task) but bear in mind that could occupy a lot of memory - which might not matter. Back in the old days (pre Mac OSX) one of the frequently seen solutions to the Font menu problem was to save the font menu titles as images and use a custom menu definition to display these, loading the real font lazily when the user actually chose it. You can still do much the same trick these days I expect, using a custom menu item. It’s a lot of work just to avoid a small delay though. —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: Help: NSScrollView is resizing its documentView down to (0, 0)
On May 5, 2015, at 6:17 PM, Luther Baker lutherba...@gmail.com wrote: Not exactly the same but I found this doc helpful. https://developer.apple.com/library/ios/technotes/tn2154/_index.html https://developer.apple.com/library/ios/technotes/tn2154/_index.html I knew about that technote, but UIScrollView is different from NSScrollView in the details of how it works (IIRC there's no clipView) so I figured the technote would just get me more confused. —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
Re: Help: NSScrollView is resizing its documentView down to (0, 0)
On 6 May 2015, at 2:26 am, Jens Alfke j...@mooseyard.com wrote: (although the view is pinned to the bottom of the window instead of the top for some reason.) In the pre-autolayout days, this was always the case unless your embedded view returned YES for -isFlipped. Never made much sense then either. I added an override of -setFrame: and found that my view's frame is being set to (0, 0, 0, 0) by AppKit while redisplaying the window. I have no idea why this is happening — it probably has something to do with constraints, but I don't understand constraints well enough to know why (and I can't find any clear documentation about how to use constraints with scroll views.) How can I fix this? I don’t know, but I also find setting up simple constraints baffling. Even the most straightforward cases seem to be really hard to get right. So far my “solution” has been to disable autolayout for the nib and use good old fashioned struts and springs. Since they end up translated to the modern stuff internally, and they work, it’s been good enough for most cases. They really need to make the simple cases trivial and the more difficult cases possible, rather than the trivial cases annoyingly difficult as well. —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: Issues with implementing WYWIWYG font menu
On May 5, 2015, at 2:21 PM, David Durkee da...@dwdurkee.com wrote: 1) The first time the menu is opened, it takes as much as two seconds for it to appear. And it might take a lot longer than that, for a user with a lot of fonts installed. (I have nearly 2000.) It can also allocate a ton of RAM for glyph caches. Is there a way I can precache whatever it is that takes so long that first time (the fonts I’m guessing)? You could pre-render a sample of each font to an image, then save the image to a file or database keyed by the font name. I'm not sure if it's possible to defer configuring a menu item until it's displayed, but if so that would speed things up a whole lot, since you'd only be displaying a few dozen fonts to start with. —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
Re: Help: NSScrollView is resizing its documentView down to (0, 0)
If you have AutoLayout on in a window it's actually on for all views. NSScrollView and its hierarchy are a bit weird though. Thing to do is create height and width constraints for the document view and outlets for them so you can configure them. If you're using 10.10+ you can make them configurable in IB. Then add a subview as your real document view. For upper left corner origin you need to subclass NSClipView and return YES from an override of isFlipped. Set the class in IB for both. You also want to uncheck the item for translatesAutoresizingMasks If that doesn't appear in IB you can set it in code or just return NO from a getter override. Sent from my iPhone On 2015/05/06, at 1:26, Jens Alfke j...@mooseyard.com wrote: I haven't done much AppKit work in a while. Right now I have a small app where I'm trying to do something very simple: put a custom NSView in a window and make it scrollable. The view determines its own frame size based on the content it needs to display. So all I did was create a new window in IB, add an instance of my view, embed it in an NSScrollView, and set up default constraints for the scroll view so it'll track the window size. It sort of works as long as the window is bigger than my custom view (although the view is pinned to the bottom of the window instead of the top for some reason.) But as soon as I resize the window to a height smaller than the custom view's, the view disappears and never comes back. I added an override of -setFrame: and found that my view's frame is being set to (0, 0, 0, 0) by AppKit while redisplaying the window. I have no idea why this is happening ― it probably has something to do with constraints, but I don't understand constraints well enough to know why (and I can't find any clear documentation about how to use constraints with scroll views.) How can I fix this? (OS X 10.10.4, Xcode 6.3.) ―Jens * thread #1: tid = 0x691af4, 0x00015c08 Hops`-[RevTreeView setFrame:](self=0x61141600, _cmd=0x7fff8b0c9343, frame=(origin = (x = 0, y = 0), size = (width = 0, height = 0))) + 24 at RevTreeView.m:70, queue = 'com.apple.main-thread', stop reason = breakpoint 3.1 * frame #0: 0x00015c08 Hops`-[RevTreeView setFrame:](self=0x61141600, _cmd=0x7fff8b0c9343, frame=(origin = (x = 0, y = 0), size = (width = 0, height = 0))) + 24 at RevTreeView.m:70 frame #1: 0x7fff9564628f AppKit`-[NSView resizeWithOldSuperviewSize:] + 694 frame #2: 0x7fff9574ce05 AppKit`-[NSView layoutSubtreeIfNeeded] + 810 frame #3: 0x7fff95656e66 AppKit`-[NSView _sendViewWillDrawInRect:clipRootView:] + 47 frame #4: 0x7fff957fad04 AppKit`-[NSView displayRectIgnoringOpacity:inContext:] + 362 frame #5: 0x7fff959354cd AppKit`-[_NSMirrorDocumentView drawRect:] + 265 frame #6: 0x7fff95676859 AppKit`-[NSView(NSInternal) _recursive:displayRectIgnoringOpacity:inGraphicsContext:CGContext:topView:shouldChangeFontReferenceColor:] + 1186 frame #7: 0x7fff95676278 AppKit`__46-[NSView(NSLayerKitGlue) drawLayer:inContext:]_block_invoke + 218 frame #8: 0x7fff95675f21 AppKit`-[NSView(NSLayerKitGlue) _drawViewBackingLayer:inContext:drawingHandler:] + 2407 frame #9: 0x7fff956755a3 AppKit`-[NSView(NSLayerKitGlue) drawLayer:inContext:] + 108 frame #10: 0x7fff958296c6 AppKit`-[_NSBackingLayerContents drawLayer:inContext:] + 145 frame #11: 0x7fff8a669ce7 QuartzCore`-[CALayer drawInContext:] + 119 frame #12: 0x7fff958291fe AppKit`-[_NSTiledLayer drawTile:inContext:] + 625 frame #13: 0x7fff95828f2f AppKit`-[_NSTiledLayerContents drawLayer:inContext:] + 169 frame #14: 0x7fff8a669ce7 QuartzCore`-[CALayer drawInContext:] + 119 frame #15: 0x7fff95828e70 AppKit`-[NSTileLayer drawInContext:] + 169 frame #16: 0x7fff8a6683c7 QuartzCore`CABackingStoreUpdate_ + 3306 frame #17: 0x7fff8a6676d7 QuartzCore`___ZN2CA5Layer8display_Ev_block_invoke + 59 frame #18: 0x7fff8a667694 QuartzCore`x_blame_allocations + 81 frame #19: 0x7fff8a65b43c QuartzCore`CA::Layer::display_() + 1546 frame #20: 0x7fff95828d87 AppKit`-[NSTileLayer display] + 119 frame #21: 0x7fff956c2df4 AppKit`-[_NSTiledLayerContents update:] + 5688 frame #22: 0x7fff956c14c7 AppKit`-[_NSTiledLayer display] + 375 frame #23: 0x7fff8a6597fd QuartzCore`CA::Layer::display_if_needed(CA::Transaction*) + 603 frame #24: 0x7fff8a658e81 QuartzCore`CA::Layer::layout_and_display_if_needed(CA::Transaction*) + 35 frame #25: 0x7fff8a658612 QuartzCore`CA::Context::commit_transaction(CA::Transaction*) + 242 frame #26: 0x7fff8a6583ae QuartzCore`CA::Transaction::commit() + 390 frame #27: 0x7fff9564eae6 AppKit`-[NSWindow _setFrameCommon:display:stashSize:] + 3771 frame #28: 0x7fff95937e73 AppKit`-[NSWindow(NSWindowResizing)
Re: malloc(0) returns a pointer, not NULL
The Clang static analyzer will warn about potential calls to malloc(0). —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
Re: Help: NSScrollView is resizing its documentView down to (0, 0)
Sent from my iPhone On 2015/05/06, at 9:58, dangerwillrobinsondan...@gmail.com wrote: If you have AutoLayout on in a window it's actually on for all views. NSScrollView and its hierarchy are a bit weird though. Thing to do is create height and width constraints for the document view and outlets for them so you can configure them. I forgot to mention another nice approach is to simply create two CGFloat properties that are height and width, then return those as the NSSize from inside an override of intrinsicContentSize. Then you save a ton of code. The only trick is you need to have it at least non zero at the beginning or it will be hosed. That method creates size constraints implicitly. If you're using 10.10+ you can make them configurable in IB. Then add a subview as your real document view. For upper left corner origin you need to subclass NSClipView and return YES from an override of isFlipped. Set the class in IB for both. You also want to uncheck the item for translatesAutoresizingMasks If that doesn't appear in IB you can set it in code or just return NO from a getter override. ___ 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: Help: NSScrollView is resizing its documentView down to (0, 0)
Sent from my iPhone
On 2015/05/06, at 14:14, Roland King r...@rols.org wrote:
One of the things you ‘pick up’ as you learn autolayout is that when frame
sizes disappear to {0,0} that often means you have an ambiguous layout and
you need more constraints.
More precisely it means a view is either not sufficiently constrained to be
another size, it is constrained to be this size, other constraints took
priority, or these constraints were broken due to conflicting constraints.
Autolayout does have a learning curve but once you start thinking in the
right terms it’s not that hard, until you try using it for animation, at
which point I end up tearing my hair out on OSX at least.
Animation isn't bad as long as you're using the animator proxy on the
constraint constant.
___
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: Help: NSScrollView is resizing its documentView down to (0, 0)
On 6 May 2015, at 09:21, Jens Alfke j...@mooseyard.com wrote:
On May 5, 2015, at 5:54 PM, Roland King r...@rols.org
mailto:r...@rols.org wrote:
Constrain the scrollview to something above it if it needs it, if it’s the
whole window, probably doesn’t.
Constrain the clipview to all 4 sides of the scrollview.
Constrain your view to the top, right and left of the clipview but not the
bottom.
Override the clipview and return isFlipped=YES
I was assuming that the Editor Embed In Scroll view command would set
things up to basically work. (The way it used to in the old days.) Whereas
the reality is that IB creates the enclosing views for me, but then helpfully
avoids actually setting up any of the constraints they need? WTF?
Also, where does one go to learn that the above constraints are needed? Is
this just knowledge picked up through trial and error?
I realy don't want to sound like one of those old farts grousing about
the old days, but when I learned Cocoa programming in 2000 I was blown away
by how easy everything was and how well IB worked. If I were starting out
now, I don't think I'd feel the same way.
I think we discussed the last time whether or not that counted as a bug, that
it didn’t add the constraints for you. I’m on the fence about that one and
can’t find the last discussion. Perhaps setting the constraints up for a
‘usual’ layout of vertically scrolled content would not be unreasonable.
One of the things you ‘pick up’ as you learn autolayout is that when frame
sizes disappear to {0,0} that often means you have an ambiguous layout and you
need more constraints. Autolayout does have a learning curve but once you start
thinking in the right terms it’s not that hard, until you try using it for
animation, at which point I end up tearing my hair out on OSX at least. The
constraints editor in IB has become an awful lot better since autolayout
originally showed up, I now mostly find it fairly quick to look at my layouts
and get a mental picture of how the constraints work.
___
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: Issues with implementing WYWIWYG font menu
On May 5, 2015, at 2:21 PM, David Durkee da...@dwdurkee.com wrote: Yes, this approach has worked much better. I see only two drawbacks. 1) The first time the menu is opened, it takes as much as two seconds for it to appear. This only seems to be true for the first instance of the menu that is opened. (It’s a popup menu in a document window, so different documents will each have their own instance of it.) Is there a way I can precache whatever it is that takes so long that first time (the fonts I’m guessing)? 2) The attributed title is also displayed in the NSPopupButton, where I would rather see the font name displayed int he system font. (As in the font popup in Pages.) Is there a way to force the button to not use the attributedTitle of the selected NSMenuItem? At a guess, subclass the NSPopuButtonCell and override its attributedTitle to return one with the system font. It’s probably just returning what it gets from the menuItem. David On Apr 29, 2015, at 9:44 PM, Graham Cox graham@bigpond.com wrote: On 30 Apr 2015, at 6:33 am, David Durkee da...@dwdurkee.com wrote: using a custom view in each NSMenuItem to draw the name of the font in its own font This isn’t really necessary - you can just set an attributed title on a standard menu item and it will draw in the Font given in the attributes. You might find that is easier and less buggy than adding a view to the item. —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/lrucker%40vmware.com This email sent to lruc...@vmware.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: Proper way to perform a task in the future on iOS 7 and 8
On 4 May 2015, at 1:29 PM, Alex Zavatone z...@mac.com wrote: Since the app is already receiving location updates in the background, does it make sense to check if the current time is than the expiry timestamp within a location manager update? It makes so much sense to me that I don’t know why I’d be less than comfortable with it. You mean to disregard updates from Region A after time T. That includes the first update at (t ≥ T). How you disregard them is an implementation detail. Why can’t “disregard” at that first update mean literally that your handler ignores the “live” behavior and removes the region? I believe regions are a limited resource. Would that be a problem for you? — F ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Help: NSScrollView is resizing its documentView down to (0, 0)
I haven't done much AppKit work in a while. Right now I have a small app where I'm trying to do something very simple: put a custom NSView in a window and make it scrollable. The view determines its own frame size based on the content it needs to display. So all I did was create a new window in IB, add an instance of my view, embed it in an NSScrollView, and set up default constraints for the scroll view so it'll track the window size. It sort of works as long as the window is bigger than my custom view (although the view is pinned to the bottom of the window instead of the top for some reason.) But as soon as I resize the window to a height smaller than the custom view's, the view disappears and never comes back. I added an override of -setFrame: and found that my view's frame is being set to (0, 0, 0, 0) by AppKit while redisplaying the window. I have no idea why this is happening — it probably has something to do with constraints, but I don't understand constraints well enough to know why (and I can't find any clear documentation about how to use constraints with scroll views.) How can I fix this? (OS X 10.10.4, Xcode 6.3.) —Jens * thread #1: tid = 0x691af4, 0x00015c08 Hops`-[RevTreeView setFrame:](self=0x61141600, _cmd=0x7fff8b0c9343, frame=(origin = (x = 0, y = 0), size = (width = 0, height = 0))) + 24 at RevTreeView.m:70, queue = 'com.apple.main-thread', stop reason = breakpoint 3.1 * frame #0: 0x00015c08 Hops`-[RevTreeView setFrame:](self=0x61141600, _cmd=0x7fff8b0c9343, frame=(origin = (x = 0, y = 0), size = (width = 0, height = 0))) + 24 at RevTreeView.m:70 frame #1: 0x7fff9564628f AppKit`-[NSView resizeWithOldSuperviewSize:] + 694 frame #2: 0x7fff9574ce05 AppKit`-[NSView layoutSubtreeIfNeeded] + 810 frame #3: 0x7fff95656e66 AppKit`-[NSView _sendViewWillDrawInRect:clipRootView:] + 47 frame #4: 0x7fff957fad04 AppKit`-[NSView displayRectIgnoringOpacity:inContext:] + 362 frame #5: 0x7fff959354cd AppKit`-[_NSMirrorDocumentView drawRect:] + 265 frame #6: 0x7fff95676859 AppKit`-[NSView(NSInternal) _recursive:displayRectIgnoringOpacity:inGraphicsContext:CGContext:topView:shouldChangeFontReferenceColor:] + 1186 frame #7: 0x7fff95676278 AppKit`__46-[NSView(NSLayerKitGlue) drawLayer:inContext:]_block_invoke + 218 frame #8: 0x7fff95675f21 AppKit`-[NSView(NSLayerKitGlue) _drawViewBackingLayer:inContext:drawingHandler:] + 2407 frame #9: 0x7fff956755a3 AppKit`-[NSView(NSLayerKitGlue) drawLayer:inContext:] + 108 frame #10: 0x7fff958296c6 AppKit`-[_NSBackingLayerContents drawLayer:inContext:] + 145 frame #11: 0x7fff8a669ce7 QuartzCore`-[CALayer drawInContext:] + 119 frame #12: 0x7fff958291fe AppKit`-[_NSTiledLayer drawTile:inContext:] + 625 frame #13: 0x7fff95828f2f AppKit`-[_NSTiledLayerContents drawLayer:inContext:] + 169 frame #14: 0x7fff8a669ce7 QuartzCore`-[CALayer drawInContext:] + 119 frame #15: 0x7fff95828e70 AppKit`-[NSTileLayer drawInContext:] + 169 frame #16: 0x7fff8a6683c7 QuartzCore`CABackingStoreUpdate_ + 3306 frame #17: 0x7fff8a6676d7 QuartzCore`___ZN2CA5Layer8display_Ev_block_invoke + 59 frame #18: 0x7fff8a667694 QuartzCore`x_blame_allocations + 81 frame #19: 0x7fff8a65b43c QuartzCore`CA::Layer::display_() + 1546 frame #20: 0x7fff95828d87 AppKit`-[NSTileLayer display] + 119 frame #21: 0x7fff956c2df4 AppKit`-[_NSTiledLayerContents update:] + 5688 frame #22: 0x7fff956c14c7 AppKit`-[_NSTiledLayer display] + 375 frame #23: 0x7fff8a6597fd QuartzCore`CA::Layer::display_if_needed(CA::Transaction*) + 603 frame #24: 0x7fff8a658e81 QuartzCore`CA::Layer::layout_and_display_if_needed(CA::Transaction*) + 35 frame #25: 0x7fff8a658612 QuartzCore`CA::Context::commit_transaction(CA::Transaction*) + 242 frame #26: 0x7fff8a6583ae QuartzCore`CA::Transaction::commit() + 390 frame #27: 0x7fff9564eae6 AppKit`-[NSWindow _setFrameCommon:display:stashSize:] + 3771 frame #28: 0x7fff95937e73 AppKit`-[NSWindow(NSWindowResizing) _resizeWithEvent:] + 1469 frame #29: 0x7fff957dd47c AppKit`-[NSTitledFrame mouseDown:] + 200 frame #30: 0x7fff957dd3ab AppKit`-[NSThemeFrame mouseDown:] + 68 frame #31: 0x7fff95d4d2fc AppKit`-[NSWindow _reallySendEvent:isDelayedEvent:] + 14125 frame #32: 0x7fff956dcd76 AppKit`-[NSWindow sendEvent:] + 470 frame #33: 0x7fff956d9312 AppKit`-[NSApplication sendEvent:] + 2504 frame #34: 0x7fff95602c68 AppKit`-[NSApplication run] + 711 frame #35: 0x7fff9557f354 AppKit`NSApplicationMain + 1832 frame #36: 0x00013732 Hops`main(argc=3, argv=0x7fff5fbff930) + 34 at main.m:12 frame #37: 0x7fff982285c9 libdyld.dylib`start + 1 ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please
malloc(0) returns a pointer, not NULL
This came as news to me. The C spec says this is implementation-definited; malloc(0 may return either NULL or it may return a pointer that can subsequently be passed to free(). In the case of the bug I'm looking at just now, it's an error in my code, so I now have: assert( 0 != bytes ); ptr = malloc( bytes ); Just thought you'd like to know, Mike Michael David Crawford, Consulting Software Engineer mdcrawf...@gmail.com http://www.warplife.com/mdc/ Available for Software Development in the Portland, Oregon Metropolitan Area. ___ 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: Issues with implementing WYWIWYG font menu
Yes, this approach has worked much better. I see only two drawbacks. 1) The first time the menu is opened, it takes as much as two seconds for it to appear. This only seems to be true for the first instance of the menu that is opened. (It’s a popup menu in a document window, so different documents will each have their own instance of it.) Is there a way I can precache whatever it is that takes so long that first time (the fonts I’m guessing)? 2) The attributed title is also displayed in the NSPopupButton, where I would rather see the font name displayed int he system font. (As in the font popup in Pages.) Is there a way to force the button to not use the attributedTitle of the selected NSMenuItem? David On Apr 29, 2015, at 9:44 PM, Graham Cox graham@bigpond.com wrote: On 30 Apr 2015, at 6:33 am, David Durkee da...@dwdurkee.com wrote: using a custom view in each NSMenuItem to draw the name of the font in its own font This isn’t really necessary - you can just set an attributed title on a standard menu item and it will draw in the Font given in the attributes. You might find that is easier and less buggy than adding a view to the item. —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
Core Data sync between iOS and Mac apps
I'm looking into options for building an iOS and Mac app that can sync/share Core Data between them. I'm well aware of the issues with Core Data iCloud syncing in iOS 5 and 6 and that it is supposedly better so I'm willing to try it. The apps can have deployment targets of iOS 8 and greater and OS X 10.10. I don't expect they'll be ready to release before iOS 9 and 10.11 (or whatever it's called) are out. The apps will be document-based in that the user can open different data files each which should sync separately. The most detail explanation I can find of iCloud Core Data syncing is WWDC 2013 session 207 (which apparently also applies to iOS 8) and the objc.io issue: http://www.objc.io/issue-10/icloud-core-data.html I looked into Ensembles (http://www.ensembles.io) a bit last year and bought a support package. I'm also aware of BSManagedDocument (but haven't tried using it). And I've seen this http://ossh.com.au/design-and-technology/software-development/ but I didn't see any accompanying code. I'm comfortable with Objective-C, Swift, and Core Data locally, but not syncing Core Data. Is there someone where that I should look for that describes the steps in detail including setting the proper entitlements, etc. in Xcode 6? I assume now that the iOS synced data would show up in the iCloud Drive on the Mac - correct - or am I missing something that it is only for iCloud Documents, not Core Data sync? I don't quite understand how URLForUbiquityContainer comes into play on the Mac if the files now appear local on the Mac. After the user chooses File - Open would they navigate to the iCloud Drive and select the file? If so, how does the code then use URLForUbiquityContainer. Pointers to any documentation or tutorials or recommendations would be appreciated. Thanks, Dave Reed ___ 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
