Re: Help: NSScrollView is resizing its documentView down to (0, 0)
On May 6, 2015, at 9:10 PM, Luther Baker lutherba...@gmail.com wrote: I'm probably missing something ... but fundamentally, the whole point of constraints between the scrollview and its children is so that the scrollview knows how big to make its contentSize. It sounds like you've got this flipped ... the scrollview is not trying to constrain the size of the document at all - when using autolayout, the scrollview is dynamically trying to determine it's *own* contentSize. But would it use constraints for that? “contentSize” is a property of the scroll view, not a specific view. The documentView’s parent is the clipView, which does not resize with the content, so it doesn’t seem like there should be a constraint there. This seems more like a job for observing the documentView’s frame rect, either via KVO or NSNotifications. I know you skipped that report I sent you - but by doing so, I think you're missing some helpful insight. You post sounds like you're just frustrated it didn't just work in IB ... and you're upset you've finally got to actually learn about this new-fangled layout paradigm. Kind of. I’ve been working intermittently with auto-layout for a few years on smallish projects, but just figuring it out by messing with IB. I had actually not managed to find the full Auto Layout Guide before, and that should help a lot because I’m the type that likes to learn by curling up with a good book. Just my $0.02. I thoroughly enjoy your contributions to this group and I'll just say that this entire thread really surprised me. Hang in there! It isn't that difficult! Thanks! Yeah, my expertise doesn’t extend to the more modern parts of the UI frameworks. I’ve done a lot of AppKit in the past (mostly on iChat and Chromium) but very little since 2010, as I’ve since been focusing on database and networking code with no UI. And I’ve never done any UIKit beyond little toy demo apps… —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 Thu, May 7, 2015, at 10:52 AM, Jens Alfke wrote: On May 6, 2015, at 9:10 PM, Luther Baker lutherba...@gmail.com wrote: I'm probably missing something ... but fundamentally, the whole point of constraints between the scrollview and its children is so that the scrollview knows how big to make its contentSize. It sounds like you've got this flipped ... the scrollview is not trying to constrain the size of the document at all - when using autolayout, the scrollview is dynamically trying to determine it's *own* contentSize. But would it use constraints for that?' Yes, NSScrollView has supported using constraints between the document view and the clip view to specify the contentSize since 10.8. https://developer.apple.com/library/mac/releasenotes/AppKit/RN-AppKitOlderNotes/ (section Auto Layout NSSplitView Improvements) --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: Help: NSScrollView is resizing its documentView down to (0, 0)
When using auto layout with a scroll view, you would want at least constraints to fix the position of the document view within the clip view. Usually, you fix it to the top-left. If the document view should re-flow its content to fit the width of the clip view, like a text view or collection view (although those don't actually work this way), then the document view's trailing edge or width should be constrained to match the clip view's. If the document view should have a width independent of the scroll view's width, then you would *not* create trailing or width constraints. The clip view will observe the document view's size and update the scroll view accordingly. Same for the vertical orientation, although it's relatively uncommon for a document view to match its clip view's height and re-flow horizontally. For the problem where the document view is pinned to the bottom of the scroll view when the scroll view is large enough to show it its full height, there are two solutions: 1) as mentioned, use a subclass of NSClipView which is flipped; or 2) constrain the document view so its height is *at least* as tall as the clip view. The latter, of course, requires that the document view can stretch, possibly taller than strictly necessary from its subviews or contents. If it can't stretch, it will restrict the size of the clip view and scroll view. If the scroll view is attached to the window edges through a chain of constraints, that will actually fix your window size, too. You need to be careful when allowing the document view to stretch that you don't leave ambiguity. That is, don't just leave the height unconstrained. It should prefer a particular height at a lower priority than it prefers to be at least as tall as the clip view. Do not use intrinsicContentSize for size which is not, well, intrinsic to its content, where content is something like an image or text or data, but not subviews. The subviews and the constraints among them and with the document view should not influence the intrinsicContentSize. If you're trying to get behavior similar to content hugging priority and/or compression resistance priority, you can achieve those with inequality constraints of the desired priorities. For example, a constraint of the form view height = some constant @ 750 priority is the rough equivalent of a vertical content hugging priority of 750. View height = some constant @ 250 is equivalent of a vertical compression resistance priority of 250. Etc. Of course, the scroll view itself can be constrained to its siblings or superview to determine its size. And you might want to use explicit width or height constraints, too. Possibly inequalities if you just want to enforce a minimum, for example. Regards, Ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Help: NSScrollView is resizing its documentView down to (0, 0)
On May 6, 2015, at 8:36 AM, Uli Kusterer witness.of.teacht...@gmx.net wrote: So you're not setting a constraint on the *document* view? How do you expect it to know how to constrain that view otherwise? The size of the document view is fundamentally unrelated to the size of the clip or scroll view — the whole point of having a scroll view is that you have an arbitrarily large document! So I wouldn’t expect the scroll view to be trying to constrain the size of the document view at all. The app code is in charge of deciding how big the document view is, based on the content it displays. [OK, in some cases the width of the content view is limited to the width of the clip view. Not in my case though; it scrolls horizontally as well as vertically.] IIRC you need to implement updateConstraints to create proper constraints, or intrinsicContentSize, or maybe both. I’ve never seen the intrinsicContentSize property before (partly because it’s not defined in NSView.h.) Reading the docs for it, it makes sense that I’d override it. And searching the docs for that name I found the “Auto Layout Guide”, which looks very useful but which I wouldn’t have found otherwise because I didn’t know to look for the keyword “auto layout” (everywhere else it’s called “constraints”…) —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 Wed, May 6, 2015 at 11:54 AM, Jens Alfke j...@mooseyard.com wrote: On May 6, 2015, at 8:36 AM, Uli Kusterer witness.of.teacht...@gmx.net wrote: So you're not setting a constraint on the *document* view? How do you expect it to know how to constrain that view otherwise? The size of the document view is fundamentally unrelated to the size of the clip or scroll view — the whole point of having a scroll view is that you have an arbitrarily large document! So I wouldn’t expect the scroll view to be trying to constrain the size of the document view at all. The app code is in charge of deciding how big the document view is, based on the content it displays. I'm probably missing something ... but fundamentally, the whole point of constraints between the scrollview and its children is so that the scrollview knows how big to make its contentSize. It sounds like you've got this flipped ... the scrollview is not trying to constrain the size of the document at all - when using autolayout, the scrollview is dynamically trying to determine it's *own* contentSize. I know you skipped that report I sent you - but by doing so, I think you're missing some helpful insight. You post sounds like you're just frustrated it didn't just work in IB ... and you're upset you've finally got to actually learn about this new-fangled layout paradigm. IIRC you need to implement updateConstraints to create proper constraints, or intrinsicContentSize, or maybe both. I’ve never seen the intrinsicContentSize property before (partly because it’s not defined in NSView.h.) This is Autolayout 101 stuff. 2013. Admittedly, maybe you're not doing much iOS work ... but this was all part of the replacement for the UIView sizeThatFits frame stuff. There an ecosystem here of how all this works together. Reading the docs for it, it makes sense that I’d override it. And searching the docs for that name I found the “Auto Layout Guide”, which looks very useful but which I wouldn’t have found otherwise because I didn’t know to look for the keyword “auto layout” (everywhere else it’s called “constraints”… Autolayout is not a new term :-) ... What do you mean everywhere ... and what is its? Take heart Jens! I'd suggest that it isn't quite as difficult as your thread alludes to. It isn't an old timer thing either ... but it does take some understanding and experimentation. Its an abstraction over frames. Its a level of indirection ... and I'm am sorry that IB doesn't just handle it automatically. Indeed there will be much gnashing of teeth going forward if you really decide to dig in ... it is much more nuanced than literally setting and tracking frames. Just my $0.02. I thoroughly enjoy your contributions to this group and I'll just say that this entire thread really surprised me. Hang in there! It isn't that difficult! Thanks, -Luther —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/lutherbaker%40gmail.com This email sent to lutherba...@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: Help: NSScrollView is resizing its documentView down to (0, 0)
On 05 May 2015, at 18: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. So you're not setting a constraint on the *document* view? How do you expect it to know how to constrain that view otherwise? Have you tried doing that? IIRC you need to implement updateConstraints to create proper constraints, or intrinsicContentSize, or maybe both. ___ 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 06 May 2015, at 03:21, Jens Alfke j...@mooseyard.com wrote: Constrain your view to the top, right and left of the clipview but not the bottom. I have never had to do this. What are you trying to fix with this? ___ 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 23:39, Uli Kusterer witness.of.teacht...@gmx.net wrote: On 06 May 2015, at 03:21, Jens Alfke j...@mooseyard.com mailto:j...@mooseyard.com wrote: Constrain your view to the top, right and left of the clipview but not the bottom. I have never had to do this. What are you trying to fix with this? The fact that IB adds no constraints to NSScrollViews at all so the completely and totally do not work in any way whatsoever unless you add the constraints. ___ 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 06 May 2015, at 17:41, Roland King r...@rols.org wrote: On 6 May 2015, at 23:39, Uli Kusterer witness.of.teacht...@gmx.net wrote: On 06 May 2015, at 03:21, Jens Alfke j...@mooseyard.com mailto:j...@mooseyard.com wrote: Constrain your view to the top, right and left of the clipview but not the bottom. I have never had to do this. What are you trying to fix with this? The fact that IB adds no constraints to NSScrollViews at all so the completely and totally do not work in any way whatsoever unless you add the constraints. To the scroll view and content view I understand. But the clip view? ___ 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 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: 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: 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: 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: 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
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
