Looking for a vertical NSToolBar lookalike - objective-c

I'm looking for an NSToolBar type of object to use in my application. I need it to be vertical and to look nice. The buttons on the object do not need to be repositioned or customizable like the NSToolBar it, but I would like the same look and feel the NSToolBar has, just vertical.
I've tried the google route, but I'm not really sure what to search for when it comes to looking for obj-c objects or examples.
I know seeing as what I want is basically a static set of buttons along the side of my window I could just use a bunch of buttons, but it doesn't have the nice seamless look that the NSToolBar does.
Is there something out there similar to what I'm looking for? Is there a repository of obj-c objects or a nice collection of them on a site that I'm just not finding?

It wouldn't have much in the way of functionality, but if you check the 'Textured' box (under 'Appearance') in Interface Builder of an NSWindow, it will make the whole window look like a toolbar. Dropping a well-placed NSBox (set to 'Custom', and with a fill color of the background of a window-or-so) on top of the window leaving only a strip for what would look like a toolbar, you would have a visual approximation, although without any functionality of an NSToolbar whatsoever. Buttons would all have to be done manually, etc, etc.
However, I must caution you that this sounds like a major violation of the HIG. If you are trying to make something twitterish, I won't dissuade you, but it is a sort of crosroads there's no need to cross until Apple decides which path it is going to take.

The toolbar itself wouldn't be too tricky, but if you wanted to allow customization, that would be tricky. Since you didn't mention customization (or showing/hiding) all you really want is a vertical bar of buttons and a background color that matches the window color.
Make your window a textured window, using NSTexturedWindowMask, then create a subclass of NSView with the dimensions you want, drawing its background to match the window background color.
-(void)drawRect:(NSRect)dirtyRect {
[[[self window] backgroundColor] set];
NSRectFill(dirtyRect);
}
The buttons will just be subviews of this view.
Like I say, customization and showing/hiding make this is much harder task to achieve.

Related

What Cocoa Views and Controls Will Create Something like Part of the Network Prefs Display (Mac OS)? [duplicate]

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.

Programmatically make color filled UIBarButtonItem

I have a UIBarButtonItem with the UIBarButtonSystemItemSearch type. I can programmatically change the tint color, like so:
searchButton.tintColor = [UIColor purpleColor];
However, what I'm trying to do is figure out a way to programmatically "fill" the button (i.e. the magnifying glass) with a given color. More generally, I'm trying to use a change in the icon to indicate that the search functionality is active.
I really like the built in search icon, but the lack of an obvious fill functionality is annoying. Is there any way to do something like this without creating an entirely custom button/icon? If not, what's the easiest way to utilize the existing search icon to create a custom button that does have the ability to be filled?
First off I would suggest simply using the tintColor to show your selected/unselected states without trying to mess with the shape itself since it is much easier and will convey what you're trying to do. Keep in mind that in this specific case, the magnifying glass may not even look right if it is filled in, that shape is very specific and people are used to seeing empty space in the circle.
If you want to continue on that route though, no you cannot easily change the built-in search icon. Your options are 1. programmatically take a snapshot of such an icon on the screen and try to manipulate that using CoreGraphics (not a great solution) or the better solution 2. which is just to get/make your own image and then you don't have to do any of it programmatically.

Cocoa / Interface Builder: What do I need to subclass to replicate this window?

I'm guessing it is using a custom NSWindow, NSTextField, NSSecureTextField, NSButton? I don't necessarily want to replicate it, I would just like to know what would be involved in customizing my app's UI to this level.
The window itself could be a HUD-style panel, which you can get in IB without subclassing anything. It looks like there's a bit of custom background to it, unless it's just faintly showing something behind it; if it is a custom background, a custom view as the content view could do that job.
The separator could be an image view or a custom view.
The static text fields can be done without subclassing. Just change the text color.
The editable text fields, both the regular one and the secure one, you would need to subclass. I have no idea how you would do that.
The follow-link button is a mix of custom drawing and a standard image. Start with the NSImageNameFollowLinkFreestandingTemplate image; draw that, then fill an empty path with white using the source-in blend mode.
The other two buttons are customized, probably using custom cells in order to override the background without overriding the text drawing.

How can I remove the "blur" effect that Cocoa adds to transparent sheets?

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.

IKImageView and scroll bars

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...