I'm trying to implement my app's settings. So I implement Preference Pane but I need to insert Toolbar to it. That is how looks my IB:
And this is how looks my pane from System Preferences:
You see, my window new height = old height - toolbar height. This is my first time I work with toolbar and prefpane, can you answer is there any restriction to use toolbar iside of prefpane?
The System Preferences application already sets a window toolbar so you cannot have a toolbar in your preferences pane.
I recommend using tabs; look at the NSTabView and NSTabViewItem classes.
Note that NSTabView does not actually require tabs to be displayed (though I recommend making tabs visible to the user). You can configure NSTabView to have no tab frame and still take advantage of it for panel-swapping.
Related
I would like to implement the OneNote app menu in my own UWP app. In the closed state, the menu only shows the 'hamburger' button, but when clicked a menu pane slides in from the left.
I have tried to use the SplitView, but it doesn't allow me to set the width to 0 when collapsed, always showing a narrow line on the left side. I also considered using the 8.1 Flyout control, but that doesn't see to animate the correct way.
So, what's the correct way to implement the OneNote menu behavior?
You need the SplitView, but don't mess with the width of its pane.
Instead, set the DisplayMode to Inline (or Overlay) and toggle the IsPaneOpen property.
I am working on OSX 10.10
I am facing a strange problem of sub view colors getting inverted for HUD Panel.
For example the button when set to default button looks right in Xib file but when executed the look and feel of button is modified by the HUD panel.
I am having a HUD Panel in my Xib file as follows
But when executed the button looses its default button status. It looks as follows
How do I maintain the look and feel of the button after execution. User is not able to judge which action will be the default action due to this look and feel
Try
_defaultButton.appearance = [NSAppearance appearanceNamed:NSAppearanceNameAqua];
Interface Builder follows a set of rules but these rules are not context-dependent. The context I'm talking about is "being displayed in a HUD Panel".
The rule applied in this case is "draw a blueish button in Interface Builder if the button is a default button" even if it's not always what happens (cf. what you're seeing in your second screenshot).
I don't know since which OS X version it's working like that, but now controls in HUD Panels are displayed with a different style (which does not have a special color for default button).
You can confirm this Interface Builder comportment by adding a simple NSTextField in your HUD Panel, it'll draw with a white background in Interface Builder but it will have a black background when running with a gray focus ring.
Interface Builder:
OS X 10.10:
I've never found a way to disable this special styling for controls in HUD Panel but several workarounds (the default button is still working correctly even if not having a special color).
The special styling only occurs when your HUD Panel have a title bar.
self.panel.styleMask = (NSHUDWindowMask | NSTitledWindowMask | NSUtilityWindowMask | NSNonactivatingPanelMask);
If you remove the title bar, it'll display without any special styling:
self.panel.styleMask = (NSHUDWindowMask | NSUtilityWindowMask | NSNonactivatingPanelMask);
At this point, you can implement and draw your own title bar in the panel and mimic the default one. I don't really like this approach because first it's a lot of work for a simple button and the custom styling of controls make them prettier and more easy to read in a HUD Panel.
Another solution was the 'VLC' way. They use HUD Panels but their controls don't have any special styling. They're using BGHUDAppKit which was released when Apple provided HUD Panel without any special controls to go with it. They use it to force the bluish style instead of the greyish one which are now used by default in HUD Panels.
I didn't really like this approach too, I didn't want to add a library for a simple button, library not updated since 2011.
What I end up doing was drawing a custom button (with a simple subclass) for default buttons in a HUD Panel. This solution is quick and allow you to choose the color you want for default button in a HUD Panel (blueish may not be the best for a HUD Panel, your call).
I have a toolbar in an NSWindow in my Cocoa app, and it works great, but I'm having trouble editing it. When I open it (or double-click on any of its items in the tree on the left in Xcode), the toolbar editing sheet hides behind other views in the NSWindow.
Is there a way to edit a toolbar by itself in a new window or something? Is there a trick to getting other views in my NSWindow to go "below" the toolbar in IB? The toolbar itself is perfectly fine when my program is running. It's just editing it that's a giant pain.
EDIT: Here, the content area of the window has a vertical NSSplitView, and the left half (an NSScrollView) is completely over the toolbar customizing sheet in IB, and the Custom View on the right side is over the sheet as well but it's transparent so I can see through it a little bit:
If I delete the window contents (the NSSplitView), then I can edit the toolbar (like Jay's picture), but that can't be what I'm expected to do every time I want to edit a toolbar item.
Basically editing the toolbar in IB is as easy as double-clicking..
Double-click on either the Toolbar or an Toolbar Item and the Toolbar Editor will open in the Editor area of IB. This is the same view users can see when customizing toolbars at runtime.
To change the toolbar configuration you then change the Default toolbar items area to whatever you desire and hit Done afterwards!
How to customize tab bar controller so that tabs appear on the top of the screen?Tabs should not appear at bottem of the screen.
Try this,
self.tabBarController.tabBar.frame=CGRectMake(0, 0, 320, 70);
You will need to create a custom control. The standard UITabBar does not offer the option to place tabs at the top unfortunately.
Tabs should not appear at bottem of the screen.
Actually, according to the iOS human interface guidelines, they should:
A tab bar appears at the bottom edge of the screen and should be accessible from every location in the application.
If you really wanted to do what you are asking, you could use a UITabBar directly (not touching UITabBarController). That handles drawing the tab bar itself, but doesn't do any view swapping for you. You should then write a custom container view controller using the view controller containment APIs (iOS 5 only) which you set as a delegate method on your tab bar, and then when the user changes tab, you swap in and out the relevant views.
Or you could use this open source version.
Don't make your top tab bar look like a standard Apple tab bar though, because they'll probably reject it from review. If you use a completely custom look you should be fine.
I would like to have something similar to the "List mode" of the stacks in the Dock.
But it should have the behavior of NSPopUpButton, in terms of displaying the selected object still, when the "drawer" is collapsed.
Each row should contain an image and to text columns.
How would you realize this?
Maybe subclassing NSPopUpButton, to display a CollectionView?
Or having an ordanary button and attaching a window containing a CollectionView to it, when clicked?
Oh and this up and down bars, instead of scrollbars on the side - how's that done?
Why not use a regular NSPopUpButton whose menu assembly is replaced with subclassed NSMenu/NSMenuItem that draws things the way you want? You get all the scrolling behavior for free.
If you insist on using NSCollectionView, however:
1 - Don't subclass NSPopUpButton if you're planning on popping up anything other than a menu. It's built to display a menu. Just use a regular NSButton and manage its -state (NSOnState while the collection view is displayed; NSOffState otherwise) manually.
2 - You could show a borderless transparent window (many examples available online) with a standard collection view / scroll view assembly minus the scroll bars. The borderless window could host the up/down areas (which can be simple views with NSTrackingAreas to detect mouse over). These areas could manually scroll the NSScrollView a bit every n milliseconds using an NSTimer while hovered.