I'm having all kinds of trouble understanding how NSWindows can have larger documents than the window bounds in them.
Unfortunately, layout and contents prevents me from simply shrinking the document (and I wouldn't want to make the layout cramped for those with larger screens).
A school needs to run this app on their new 13", non-retina MacBook Pros. Scrolling is acceptable to them, but I'm unsure as to the approach, and I'd like your advice on the best way to handle this to avoid forced scrolling on larger screens.
I've tried setting the NSWindow min and max size and embedding the document in a Scroll View. But even though you can see part of the document view sticking out, no scroll bars appear (I have set them to Always in sys prefs).
If this is the way to go I would appreciate a link to a tutorial on this exact subject, because I'm a bit lost with all the measurements and options.
If not I'd like a pointer where to start and what to read. I'm experienced with Cocoa Touch but a relative newcomer to Mac development.
Without more information it sounds like you have embedded a NSScrollView but didn't set up the springs and struts properly to allow the scroll view to resize when its parent view (assuming it's the window) resizes.
You might want to check out Specifying a View’s Behavior as Its Container Resizes in the Interface Builder Help documentation.
Related
Think before you answer because this question may be deeper than it appears.
Do we really need autolayout and constraints for an OSX app that has a fixed interface size?
The only reason for constraints and autolayout on iOS is the different sizes when you rotate the application or between devices but on OSX the reason may be scaling the interface, because there is no rotation. In this specific case the interface has a fixed size.
You interface is really fixed? No resizable windows or anything? If so, nope, you totally don't need autolayout. Just disable the "Use Auto Layout" checkbox in the File Inspector for your xib. That will allow you to use the old-fashioned Autoresizing masks, which, if your app truly has a fixed interface size, you don't even need that.
Layout your interface in IB however you like, and you're done.
I'm not sure if I thought deep enough or onderstand the interface builder enough, but I found out that the buttons keep the size I want them to if I use the constraints. Without constraints and word wrap on, your (my) buttons resize to fit around the text.
Also when you need to resize subviews to fit the content they're showing and you don't have constraints set, you tend to get a messy interface inside your window. My experience is that constraints not only help you when your window resizes. It keeps your interface objects placed correctly in position of one another and with the right size even when content in the different view objects change.
I'm an intermediate iOS developer who's trying to jump on the OSX side of things.
I've been struggling to create an accordion-like display of several views, where only one view at a time can be unfolded to occupy the whole parent's view's available space. In other words, click on a view's title bar, it will both open/unfold this view and close/fold the currently open view, with animations'n'all. Oh end, I need the views' contents to be scrollable.
I tried starting from Apple's NSStackView sample code, but first it is not quite what I want, and what's more, I can't figure out how to start from here to end up where I eventually want to be.
Then I tried to master the Auto-Layout facilities but with no success. Truth be told, this whole Auto-Layout thing still confuses me some.
Does any of you have clues as to how I should proceed? Sample code? Tutorials (I tried several Auto-Layout tutorial but at the end of the day they still leave me missing the tricks I'd need to figure...).
Thanks.
/Julian
Check out the sample code: InfoBarStackView. It creates an accordion-like interface, the one difference from what you're describing is it lets multiple views be revealed at the same time (although, that's a simple difference).
It uses NSStackView and autolayout constraints to create the interface and drive the reveal/hide animations.
The stack view could also be put into an NSScrollView to allow the content to be scrollable. (Something similar was done during a WWDC 2013 Cocoa Animation talk).
I'm trying to learn auto layout so I can set up a moderately complicated display the way I want. I'm starting with a simple version. At least I thought it was simple.
I have a content view containing a NSScrollView, and a zoom slider. The scroll view is, of course, just a window into a larger 'canvas' on which the user can do things.
I'd like the scroll view to be as big as the window allows, with the slider underneath.
I've tried many things none of which work, in some cases when I resize the window smaller, the scroll view goes on up over the window's top bar, obscuring the title and the red yellow, green, dots.. this is just a grumble, I won't attempt to describe how I got it.
I'm working with Visual Format Language.
The immediate problem: I can only get the thing to work at all if I put in a hard size constraint on the scroll view.
I've got constraints like #"V:|[ScrollView]-[ZoomSlider(==35)]-| and
#"|-20#1000-[ScrollView]-|"
With these, nothing shows at all, until I put a hard size on the scroll view:
For example, #"V:[ScrollView(>=70#20)]" and #"[ScrollView(>=140#20)]" results in a little tiny scroll view (as expected) just above the slider.
Window is resizable, all right.
Is there a simple way to make the scroll view resize to occupy the most space possible when I resize the window? The only way I can think of off hand is to produce metrics for the scroll view based on window size, and use a notification to change the constraints when the window size changes. There should be something simpler!
THanks.ee
OOps. Thought I knew the answer until I started to write it.
AT least here is a partial explanation of things that were causing me problems.
You can't add constraints that position or size the Window's content view. But apparently you can mess them up by deleting them programatically. Some of my problems were solved by getting rid of
[self.myContentView setTranslatesAutoresizingMaskIntoConstraints:NO];
and
[self.myContentView removeConstraints:self.myContentView.constraints];
This left me with a lot of conflicting constraints. I fixed this be eliminating all content window constraints that I could in IB, then by marking the rest as placeholders.
I've got a ways to go before I understand how to use auto layout, but doing it in code is easier (for me) than doing it with IB
Although I know of a solution to this problem, I am interested if someone can explain this solution to me. I also wanted to get this out there because I could not find any mention of this problem online, and it took me several hours over several days to track down. I have an NSTableView behaving strangely regarding redraws and its selection. The problem looks like this:
Table contents fades in, instead of appearing instantly upon it's appearance on screen. When scrolling through the contents, the newly appearing rows also fade in. When you make a selection (single or multiple), and scroll it off screen, then make another selection (that should replace, not add-to first selection), the first selection does not get cleared properly. If you scroll back to it, it is still there, in addition to your new selection. This is a display-update problem, not selection problem - i.e. your new selection is valid, it is just displayed wrong.
I tracked this through the NSArrayController I was binding to, the underlying Array, sorting, all the connections, and settings, etc., but all that has nothing to do with it.
What solved the problem was:
In the View Effects (right-most) Inspector, uncheck "Core Animation Layer" for the Window's main view.
Can anyone explain what is happening here, and perhaps improve upon the solution ?
It looks like Core Animation and NSTableView aren't getting along so well. The "fading" effect is a by-product of the way core animation works. When you have core animation in one view, it is also enabled in all of that view's subviews.
I don't recommend using core animation on the Mac unless absolutely necessary, because some interface elements (NSTextView and NSTableView, for example) aren't compatible with it. iOS has much better support for table views and such using core animation, mainly because it was designed with core animation in mind.
I know that some more simple UI elements are compatible (NSTextField and NSButton, for example).
If you absolutely need core animation in the rest of the window, put all the other views in a subview of the content view, while leaving the table view directly in the content view. You can then enable Core Animation in the other view.
Commenters, feel free to add to the list of what is and isn't compatible.
I have a custom view in my application, which is layer-backed and embedded in an NSScrollView. I allow the user to zoom in (which is accomplished by increasing the size of my custom view). I'm having trouble zooming in on an arbitrary point, though, since the NSScrollView keeps getting in the way and causing the view to jump around (typically to the view's origin) before I point it to the new scroll point. I would really like to use a CAScrollLayer, since I know I could definitely get the zooming right with it and have it move smoothly, but then I lose all built-in scrolling facilities.
Is there any way to leverage CAScrollLayer within an NSScrollView, possibly backing the NSClipView? If not, what purpose does CAScrollLayer actually serve? Is it possible, with a different approach, to change my view's size and the scroll point atomically and have that animate?
In short, is CAScrollLayer completely useless, or mostly useless?
Update
I've gotten my inner view to jump around less by making a CALayer subclass to display my view's contents. Rather than sizing with layout constraints, I have it sizing in an override of -resizeWithOldSuperlayerSize:. I still can't change the frame size and origin of my view simultaneously and get a smooth animation, though. To get a sense of what I'm looking for, open an image in Preview and zoom in and out. It zooms about the center of the image in a smooth manner.
In the limit, you can use an NSScroller instead; that way you would be able to use CAScrollLayer, if that’s your preferred implementation.
Note that on some (older) versions of Mac OS X, NSScroller has a bug that causes it to invoke an Apple private method on its containing view. You’ll know if this happens because you’ll get an exception about your custom view not responding to a method starting with an ‘_’.