(I found several similar questions, but nothing quite the same. Some were older than the OS in question. Some were doing crazy things, like completely custom windows. Nobody I found has instructions for how to make a perfectly ordinary window work correctly.)
Starting in OS X Lion, standard windows have had rounded corners. Unfortunately, I'm having trouble replicating this in my application. When an NSView is pushed against the corner of an NSWindow, sometimes it stays clipped to the round NSWindow, and sometimes it escapes and makes a square corner.
I haven't been able to figure out a pattern yet.
Even NSViews that "draw their background" sometimes force square corners, so it's not that.
My custom NSViews make square corners (am I responsible for checking my position in the NSWindow, and clipping to that, if I'm near the edge?), but some standard Cocoa controls do this, too.
For example, make a new Cocoa project, put a (scrolling) NSTableView or NSTextView in the main NSWindow, and add layout constraints so it follows the edges of the window. The bottom corners are square! The Finder, in contrast, has (what looks like) an NSTableView, right up against the bottom corner of the window, and it's rounded.
How do I make an ordinary NSWindow, with the proper round corners on the bottom?
The flag to set, in order to get NSWindow to clip its contents to its actual window border (why the heck isn't this the default?) is NSView's wantsLayer.
In code: contentView!.wantsLayer = true, when the window is loaded.
Or in IB: select the root View of your Window, and then in "View Effects inspector", check the box next to it in "Core Animation Layer" (even if you're not using Core Animation).
Meta: the documentation for wantsLayer talks about a lot of complex things that don't seem at all related to window shape or clipping, and it's not even a property of NSWindow, while NSWindow has some flags that claim to be about window corner rounding but which don't work any more, so I'm not sure how anybody is supposed to discover this, except by spending 2 days on trial-and-error. I hope this answer helps somebody else!
Related
I have a window with a textview in a scrollview and two buttons. I have added constraints at all sides, leading, trailing, top, and bottom. For the buttons I have fixed width and height, and distance to bottom and edge.
I want it to look something like this:
And this is what Interface Builder keeps giving me:
It also keeps offering to fix ambiguities by adding missing constraints, but actually clicking the button has no effect. No constraints are added. The error (and the offer to fix it) remains.
I've tried added the constraints it is asking for, although I can't see why they would be needed and at least the buttons already have (fixed) width constraints. But I keep getting errors and the window keeps getting shrunk to nothing.
When actually running the program, the window looks fine. But I suspect these autolayout errors have something to do with this problem: NSTextView in magnified NSScrollView breaks on resize
The project is here: https://github.com/angstsmurf/spatterlight/tree/helpviewtest
(The branch helpviewtest is a cut down test case created specifically for this problem.)
You have a Text view embedded in a Clip view embedded in a Scroll view, none of which have an intrinsic content size.
IB has no idea what's going to go on at run-time.
So, while everything looks great when you run this, your code will have supplied enough information to lay things out as desired.
To get it to "look right" in IB (and avoid the errors/warnings), you can give the ScrollView a Placeholder Intrinsic Content Size:
I was wondering if anyone knew why IB has inexplicable high lighted areas on the odd nib here and there..
Below is an example:
What I mean is that light area within the area I marked out in red...
There's no views below the split view, there's no bounds which correspond to it and so far there's nothing complaining about "misplaced views" etc... What is it?
update: recently I worked out when it last happened that that weird "area" is always the same size as the rightmost NSView (whether its embedded in a NSSplitView or just 2 NSViews side by side.
Many thanks
Adrian S
It's due to a bug in XCode Interface Builder. And in my experiments it's been predictable according to the following explanation:
The lighter colored area is intended to highlight the container view of the current selection. So it you have an NSTextField within an NSBox, and you select the text field, the box will be highlighted. It's purpose is to dim out everything outside the scope that you can currently make constraints in.
You can see that it's a dimming down of everything outside the box, as if nothing is selected, the whole IB view port is displayed in the lighter shade.
The bug is that when you make a selection, IB clips the area of the container view to what's currently visible, and then adds this highlight as a rounded box 8 pixels larger. But when you scroll or resize the IB viewport, this clipped area isn't updated. So the rounded highlight box is seen to not cover the whole of the container view, just a clipped part (plus 8 pixels) of it.
After much reading and experimenting, I still cannot get a simple TextView to resize fully in the horizontal direction using Xcode 5.0.2 in Mavericks. It resizes partially as the window is resized, then stops with long lines wrapped around even though my containing NSScrollView continues to resize as expected (it has four default constraints and no horizontal scroller).
Can anyone point me to a simple code/IB+AutoLayout example, preferably just a window containing just an NSTextView dragged in from the IB template library --- one that works? The Apple TextEdit sample code is almost irrelevant for this purpose although it does resize horizontally quite well. Also, there is the clip view for which I can find little information.
Any other tips appreciated.
Thanks.
Answering my own question:
Turns out that my problem had nothing to do with AutoLayout and little to do with NSTextView. It was the textfile I was using to test my code! This file was composed of records with tab-delimited fields.
Turns out that NSTextView comes with a default NSParagraphStyle with predefined tab stops that end at character 56 whereas my test file had tabs beyond that. Therefore, my lines wrapped around at the last defined tab no matter how much I stretched the window.
After changing my search terms, I found what I needed at the following links:
Premature line wrapping in NSTextView when tabs are used
How to have unlimited tab stops in a NSTextView with disabled text wrap
Apologies for wasting bandwidth.
Not sure why such a simple thing does not work in your case, but nevertheless here's what I did in Xcode to get an NSTextView follow window resize:
Create a new project (not document based in my case but it doesn't really make a difference)
Drag a NSTextView from the palette to your window. Align all four edges with the window edges.
Open the "Add constraints" pop-up (second button from the segmented control on the bottom-right part of your IB view.
Each of the four spacing constraints should show a number equal to the distance of your text view from the container window. If you aligned them, this number should be either 0 or -1. Click the down arrow for each of them and select "Use Current Canvas Value". Do it for all four. Make sure no other constraints are selected.
Click on "Add constraints" on the bottom of the panel.
Run your project. Your textview should resize with the window.
Also, as Jay's comment mentions, make sure you do not have any "leftover" constraints in your view. You can check this either by observing Xcode's warnings, or manually by inspecting your view's constraints by going to the Size Inspector tab (4th tab on the Utilities bar).
If you need to have your textview arranged in a more complex layout, it might be worth taking a look at the AutoLayout Guide.
I'm a total absolute NOOB in Mac Apps so be gentle ;). Read some documentations, and jumped right in. Still continue to read but I can't figure out how to align/resize the NSImageView to the NSWindow it is in (after user resize the window).
For example, this is default run state (the NSImageView is the big rect with a border at the bottom):
Then, if I resize the window, the NSImageView's height kinda stays as before,
but the width kinda follows the window (but I don't know how I accomplished that).
See here:
Thanks for reading. Please help.
I found out the solution - which is a simple AutoResizing mask.
Can someone please tell me, why the background gradient of the textured NSWindow in this app suddenly changes, when you make the window a little bit smaller?
This is the minimal example I could find, that exhibits this behaviour. App & Source are available via Dropbox.
-- Updates:
If you put the slider lower,the gradient does not change when resizing the window:
Also, the change seems to happen when the distance between the slider and the window's right border gets smaller than the HIG says it should be.
It is really interesting question =)
I don't shure, but guess, this problem is connected to layers displaying.
If you still want to use textured window, you can put additional NSView object in the interface builder between NSView and NSSlider (NSWindow -> NSView -> NSView -> NSSlider). It fixes the bug.