I'm writing an OS X app (target 10.10, Xcode 6.1) and I'm really confused by my custom NSButtonCell subclass. It seems like there are things going on here that shouldn't. I'm new to OS X programming, so I'm asking if anyone has insight into the inner workings of NSButtonCell.
First, what seems to be working?
I can set the button's image and title. The image appears normally.
The storyboard sets up the button to be Style: Textured and Type: Momentary Change. It's not Bordered, not Transparent, and doesn't allow Mixed State.
List of complaints:
I override -drawTitle:withFrame:inView: to draw the title in a custom color depending on the cell's highlighted. This color should be #cccccc when the cell is not highlighted, but it's actually #d6d6d6.
The button has both image and alternate image. The image that's drawn is never the alternate image, so I override -drawImage:withFrame:inView: to pick the correct image for cell's highlighted. This appears to work, but what the heck, NSButtonCell? How is on/off state different from highlighted? I've tried many of the Type options and none seem to change the fact that pressing the button will momentarily change highlighted, and toggle state.
Speaking of momentarily changing highlighted, it appears that its duration is about as short as possible, so I had to implement a sort of "debouncer" to prevent -drawWithFrame:inView: from being called more frequently than a specified threshold.
My button cell also has properties myBackgroundColor and myAlternateBackgroundColor. I'm not using backgroundColor because I need to be able to draw a custom background shape (filled rect, filled circle, etc). The alternate background color is used when highlighted. The problem here is that the alternate background color should be #93edbf but appears to be #a1eecb! In order to get it to look like #93edbf, I need to set the color to #84ecb2.
So far this has all been about one particular instance of this button cell. But in another instance, the alternate background isn't drawing at all! I've read through the storyboard code and the buttons are as identical as they can be. My view controller code likewise updates both button cells' properties at the same time. Why would one button behave differently from another?
I want the button to highlight on mouse down instead of "momentarily" after mouse up. I haven't yet implemented this in my custom cell. Man, NSButtonCell is really lacking some things. How does something like that happen? Don't the OS X and iOS teams ever talk to each other?
What could it be?
I've already verified that the cell's controlTint is set to NSClearControlTint. I've checked for background filters, compositing filters and content filters on the off chance they had anything to do with this.
I know Apple really wants us to use their native look and feel for UI elements, but I never thought they'd go so far as to force the use of some highlight tint.
Related
This question already has an answer here:
NSTableView with +/- buttons like in System Preferences using only Interface Builder
(1 answer)
Closed 7 years ago.
I'm building an OSX app and want to create a set of controls similar to what's found at bottom of the standard Network Preferences configuration panel. I'm running into some layout problems that I wouldn't have expected.
These are my specific questions:
What contains the 3 buttons so there's similar shading all they way across the row where the buttons are positioned? In particular, what's causing the area without buttons to have shading?
How do you do this without getting a double border where the row of buttons meets up with the table?
I want to do this with an xib file. This may be incredibly simple, but I'm missing something I guess.
I find that if you make a button with style "Gradient" and type "Momentary Change", then it looks like the other buttons but does not respond to clicks, so you can use that as the area after the last button. (The NSMomentaryChangeButton is documented as changing the image and title when clicked, so if you don't use an image or title, nothing should change.)
If you check Refuses First Responder in the attributes inspector, then it will not be possible to highlight this blank button using Full Keyboard Access.
Ken Thomases also brings up the issue of the blank button being shown as a button to Accessibility. One can fix that by using a subclass of NSButtonCell that has just one method:
- (BOOL)accessibilityIsIgnored
{
return YES;
}
I think that's easier than writing a custom view.
As d00dle says, avoid double borders by slightly overlapping things.
Since you want the slack space to have the same background as the buttons, and since the buttons can change appearance from release to release of the OS, the best thing to do is to get the frameworks to draw it like it would the buttons.
Rather than using an actual button as JWWalker suggests, I have used a custom view that leverages NSButtonCell to draw the background. The advantage is that you can be sure there's no chance of getting undesirable behavior. For example, a button could get focus (for users who have All Controls selected in System Preferences > Keyboard > Shortcuts > Full Keyboard Access) so that the user could Tab to it. Accessibility will report the presence of the button through VoiceOver. Etc.
Configure the button cell just like the buttons (set buttonType and bezelStyle). In the view's -drawRect: call [buttonCell drawWithFrame:rect inView:self];, where rect is similar to the frames of the buttons. Since one way to avoid double borders is to make the buttons larger than the view's bounds, you may need to do the same for rect. For example, you might want to use NSInsetRect(self.bounds, -1, -1).
The buttons are buttons... This can be accomplished with a custom view drawing border and the background "shading".
To avoid the double border where the table and the custom view meet you simply align it so they overlap by 1 point (pixel) or avoid drawing the top border in your custom view.
I don't know of any standard object capable of doing this.
I've recently come across a problem with a custom NSButtonCell subclass. We have a dark interface with white text, and all is going as expected, until we try to make a default button (i.e. assigning a key equivalent of \r). What we get seems mysterious: The bezel draws, but the text doesn't. But if I make the text black, it draws. If I make the text white with a black shadow, only the shadow draws!
The mystery started to unravel when I tried a test with the text set to [NSColor redColor] on a lark. (The "Create" button here has a key equivalent of \r, "Cancel" is Esc.)
What I eventually figured out is that the default button's cell is drawing into a bitmap context, presumably so that the rendered glyphs can be cached for the animated blue pulsing background that the Aqua look gives. That makes total sense, but the surprise is that that bitmap is then drawn with a multiply compositing operation. Hence black shows up and white doesn't, and anything in between shows up darkened.
I've managed to hack a workaround, by taking the text rendering out of -drawTitle:withFrame:inView: and doing it in -drawBezelInFrame:inView: instead. But that gets called repeatedly, so I'll need to manually cache the image. Plus it's just conceptually ugly, because it's specifically the wrong method for rendering the title!
My question: Surely there must be a better way, right? Is there some way to tell the button cell not to automatically use this offscreen rendering path even though the button is default?
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 have a Source-View (NSOutlineView) with two Buttons at the bottom. I added an NSBox so that the items don't "shine through" when they're behind the buttons.
This works fine when the window is active:
But as soon as I deactivate the window the NSBox still has that active color, rather than a dimmed version to match the NSOutlineView's background color:
How can I make sure that those two colors always match. Also using a specific color is a bit of a hack since the color NSOutline uses might change at some point.
Update: Apple's Mail.app as well as Things seem to have a solution for that problem. :-/
#Neha put me on the right way to find a solution.
I write it in Ruby because I work with Rubymotion but it's easy to translate :)
Assuming you have a box outlet for the NSBox, you can set it to transparent when the window loses the focus and do the opposite when it becomes the key window, using the appropriate delegate methods:
def windowDidBecomeKey(notification)
box.setTransparent(false)
end
def windowDidResignKey(notification)
box.setTransparent(true)
end
And the result looks fine with the focus:
And without it:
The solution is to keep a reference to the NSOutlineView's backgroundColor property as it is a special NSColor that dynamically changes depending on the key status of the parent window. Set the color of your custom view to that that reference. When the window loses/gains key status, call setNeedsDisplay: on your custom view to redraw it using the new color. Use KVO to observe NSWindowDidBecomeKeyNotification and NSWindowDidResignKeyNotification. Note that pointer to the color stays the same, but the actual color represented by the reference changes. The solution is explained here.
In the attributes inspector of NSBox,
set display to transparent
By default, Cocoa adds a background blur effect to transparent and semitransparent modal sheets when they are applied to a window. I would like to disable the blur effect. How would I go about doing it?
I have created a custom sheet (a subclass of NSWindow with a transparent background and some controls in it). I am able to display it using the standard beginSheet method as follows:
[NSApp beginSheet:myCustomSheet
modalForWindow:mainWindow
modalDelegate:self
didEndSelector:...];
The sheet displays fine, but everything behind it is blurred.
Note 1: I am writing a completely customized user interface for a touch screen / kiosk type app, so none of the usual Apple user interface guidelines apply.
Note 2: I do want to see what is underneath the sheet. As SirRatty pointed out, it is possible to block out the blurred portion by filling in the background. In my case, I want to have the background show through, just without appearing blurred.
There's a private API call that can be used to set a CI filter on the background of a window:
http://www.mail-archive.com/cocoa-dev#lists.apple.com/msg16280.html
There's also a CGSRemoveWindowFilter:
extern CGError CGSRemoveWindowFilter(CGSConnectionID cid, CGSWindowID wid, CGSWindowFilterRef filter);
Just be aware that the usual private API caveats apply (might go away or change in the future, etc.).
What I've done:
In IB, add a window-sized custom NSView to the window, at the bottom of the content view hierarchy. Set the object's class to MySolidView (or whatever.)
In Xcode, the MySolidView class does just one thing: on -drawRect it will fill the view with a solid color. (e.g. light grey).
You could write your own sheet animation routines that display your own NSWindow and fill the background of the window with a semitransparent colour. I'm not sure whether setAlphaValue: for NSWindow will also affect the child elements' opacity. If it does affect them, you could use setBackgroundColor: and provide the default window background colour but with an alpha component, this should not affect the child elements.
I suppose one of the problems of developing/designing your own user interface is when you have to reimplement the wheel just for a minor customisation. At least, if you write it yourself, you'll have more control over its customisation in the future.