I noticed the other day that one of my web pages was looking ugly. The buttons on the page looked totally different, based on whether they contained one line of text or two.
After some digging, I've learned that the typical button uses NSRoundedBezelStyle, but it has a fixed height. So, if the text is going to wrap, Firefox (and Chrome and Safari) will change the button to use NSShadowlessSquareBezelStyle which can have a variable height. I'd like to petition the maintainers of these browsers to change this and am researching the best alternative.
After finding the already-filed bug and doing some reading, I suggested that maybe they could use NSTexturedSquareBezelStyle instead. It turns out that in Mavericks it looks almost exactly the same as an NSRoundedBezelStyle button. Same in Yosemite, except that it has no border. Changing setBordered has no effect.
So my question, on behalf of browser developers everywhere: is it possible to draw an NSTexturedSquareBezelStyle button with a border? Or, is there another way around this that all the browser vendors have missed?
Rewritten Answer
I'm not seeing an NSTexturedSquareBezelStyle button showing up borderless in Yosemite:
This is a stock button dragged from the palette in Interface Builder. I encourage you to post your code since it's likely you're generating your button in code. Here's my own code for generating the same button:
NSButton * anotherButton = [[NSButton alloc] initWithFrame:NSMakeRect(10.0, 10.0, 100.0, 100.0)];
anotherButton.bezelStyle = NSTexturedSquareBezelStyle;
anotherButton.title = #"Line 1\nLine 2";
Proof:
If you're seeing different results under Yosemite, you'll need to post your code. At a guess, you might be initializing your button with -init instead of -initWithFrame:, which can cause all kinds of drawing issues since NSButton is an NSView and therefore its designated initializer is -initWithFrame:. Just a guess though.
Related
Problem solved!:
Just check the "Unified Title And Toolbar" option of the NSWindow and the 1pixel-down problem goes away!
To change the toolbar height just select the Toolbar Item - Custom View and change size in the Size inspector.
==============================
If you know Xcode 5s layout than you should recognise this:
I want to build it for my own. So I dragged a Toolbar in the Window and added a NSPopUpButton. Then I changed the PopUp Button Cell Style to Radio and turned off the Arrows. So far so good.
The first thing I noticed is that the Toolbars has different heights. Does anybody know how to change this behaviour (without subclassing NSToolbar)?
The second and more annoying thing I noticed is that if I choose an Item from the PopUp Button the Image for the NSMenuItem move 1 pixel down.
EDIT: Xcode NSMenuItems don't move 1pixel down
Any suggestions about that thing?
NSToolbar, sadly, can’t really be subclassed. It’s a poorly-written class that tries to be very “magic,” so it’s not even a subclass of NSView—you can’t control how it draws at all, it creates a private view.
You can set its “sizeMode” but I assume you’ve already done that and found that the number of pixels high isn’t what you want.
The easiest thing to do is just leave space for your widgets at the top of your window (above the document content) and have autolayout position your buttons for you. (I haven’t been able to use a real NSToolbar in years because of its limitations.)
As for the popUp menu being mis-aligned with the button: where the menu draws is basically hard-coded, so if you use a button style that NSPopUpButton doesn't expect then the menu will be offset some.
If you’ve already tried just unchecking the “draws border” flag on a default-style NSPopUpButton (one fresh off the palette), There are two solutions for to try: One is to keep trying different buttonStyles that look correct to your eye until you find one that’s not offset. Two is to leave the buttonStyle do the default for NSPopUpButtons but subclass the buttonCell and have it not draw the border (but still leave room for it).
I'm experiencing what I think is a very strange issue.
First and foremost, my application moves UI elements around the screen using the following example command:
[view setFrame:NSRectFromCGRect(CGRectMake(0, 0, 0, 0))];
I give my users the possibility to resize the application's NSWindow to one other size with this command:
[self.window setFrame:NSRectFromCGRect(CGRectMake(0, 0, 0, 0)) display:YES animate:YES];
When in 'resized mode', I obviously change every single setFrame command to the appropriate coordinate system.
However, there is an issue: when (if) the user switches back to the original NSWindow size by clicking on the button again, and the application performs the UI movements again, the views that are moved around are not in the location they are supposed to be in.
To clarify: my UI movement code runs fine, over and over, either in normal or resized mode. However, if I switch from one to the other, some items (not all) are shifted.
What could be causing this strange behavior? I'm using the same exact commands (within each screen resolution), and NSLogs confirm the UI elements are in the location that I specified; however, this location is clearly not the one I'm attempting to move to.
Has anyone experienced a similar issue here?
You've probably set some sort of autoresizing mask in Interface Builder that's interfering with your manual placements. Go in to your nib and remove all the springs and struts in the Size inspector. Although if possible you should let autosizing handle the placement, or move to Auto Layout which was introduced in 10.7.
After days and days of trying to figure this out, I've come to the following conclusion: the resizing code simply wasn't working.
I confirmed this by using NSLog after I resized my window. In the end, I changed my resizing code by adding the following line after the traditional setFrame: method:
[self.window setContentSize:NSSizeFromCGSize(CGSizeMake(desiredWidth, desiredHeight))];
I have an odd behavior with my app and I don't know where it comes from. I have implemented a NSScanner for a text view content that works very well. The scanner works in conjunction with the text storage to set attributes on the text storage string via text view delegate methods. However, each time I enter a space, the enclosing scroll view scrolls back to the top of the text view. Can anyone give me a hint where this comes from ?
Probably not much hassle for those more experienced than me, I found out the possible reason for this behavior (see above) so I post it here in case anyone will look for solutions for similar "problems". It seems that turning off "Non-contiguous layout" option in the XCode 4.x attributes inspector for the NSTextView in case will solve the problem. The documentation for NSLayoutManager provides more clues (under "Overview" section): "Noncontiguous layout is an optional layout manager behavior new in Mac OS X v10.5..."
Maybe somebody more experienced than me will provide more info on this and the reason of this behavior of the enclosing scroller view when non-contiguous option is checked (which is, by default).
I am stuck with the same problem and turning off "Non-contiguous layout" does solve the problem, but it gives rise to another problem which is that the NSTextView gets sluggish for 10k lines of text. A similar question has been answered differently but I wonder if it works. That solution also imposes some restrictions which may not be applicable to you though.
I have a custom-subclassed NSWindow which is made into a fullscreen borderless window with NSBordelessWindowMask. It works perfectly, and as far as I can see, there are no problems or anything strange about the window itself.
What I am trying to figure out why exactly a custom-subclassed NSView within the aforementioned window is respoding to setFrame: requests in an odd manner. Rather than simply taking the requests as they are, it seems they are going through some sort of change - for example, setting the x coordinate to 25 and the width to 800 does not put the right edge of the view at 825 as one would expect. Instead, the width/height grow along with the x and y coordinates, even though they report the proper numbers when asked by [view frame].size.width with an NSLog.
The sizing masks should not be an issue, as I have disabled them entirely and get the same result with several different configurations.
Has anybody else experienced this type of behavior?
Without seeing the code that you're using to create the window/view it's hard to know what might be causing this. That said, if you're targeting Leopard of later, there's a built in way to make a view go fullscreen which might help. The method is enterFullScreenMode:withOptions: on NSView. If you want the entire window to go fullscreen you can call this on the contentView of the the window. This may not fix your bug, but it should simplify things a bit at least.
I have an NSScrollView with an IKImageView inside to display images. This seems to work.
However, if I make the window smaller than the image, the scrollbars appear as they should, but the BOTTOM of the image is locked to the bottom of the window, instead of the top of the image being locked to the top of the window. In other words, I want the image to not move on the screen when I re-size the window from the bottom right.
I understand why this is, because in All of these classes, the origin is in the lower left, not the upper left. However, It's still behaving wrong. If you look at any other product (including Preview, which I assume is written with some of these libraries) the image/content/whatever, is locked to the top not the bottom.
How do I do this?
I've looked for methods in the NSScrollView and IKImageView. I've considered capturing the scroller events and manually moving the image down or up as appropriate, but I haven't seen a way to do this (Set the selector to a method I write in the controller?) and anyway, that seems very messy...
Is there an easy way to do this?
thanks.
Solution for future reference:
Make a subclass of IKImageView with only one over-ridden method:
-isFlipped()
{
return YES;
}
This subclass will also prove useful if I find that I need to re-implement the rotate:(id) method and the setImage:(NSImage) method which exist in the class (and in the case of rotate are USED IN THE DEMO supplied by Apple) but not documented, and therefore not officially supported...