My application is such that it does not require the tool-bar. It is very simple in nature and is controlled 100% by keyboard actions (one at a time, even). So while I know it's generally accepted that you should leave the toolbar in place, this time I feel that it actually hampers the UX of the program. So, I was wondering if it's possible to actually remove the tool-bar from my program?
It's easy to remove the traffic lights [ o o o ] from the bar, and there's no Title, but the space is still there, and the application simple looks 'off' with the extra space.
Any pointers are much appreciated, as I've looked around with the following queries:
How to remove the toolbar in an OSX application in XCode / Objective-C.
How do I remove the toolbar in an OSX application in XCode / Objective-C?
and a few others without much success.
You say toolbar, but I think you mean the window's title bar. This previous answer should work for you. The top answer is the way to do it, and the second answer is an argument against doing it.
Hide NSWindow Title Bar
If you want to keep title bar, but just want to customize it (including close, minimize and maximize buttons), you can use INAppStoreWindow component.
Related
I have an NSWindow that i would like to have it in front of everything (every app of the computer, fullscreen apps, etc..). Even if i click in a background app, the NSWindow cant go to background. And the NSWindow must follow the user screen if, for example, the user switches the desktop to desktop2, and so on...
How can i do that?
Thanks!
If you don't need to be visible with other apps' full-screen windows, it's not too hard.
First, to stay in front of everything else, just setLevel: with NSFloatingWindowLevel or higher. Experiment with the different values to see which seems appropriate to your needs.
Next, to stay in front even when the user changes Spaces, possibly including Exposé/Mission Control, setCollectionBehavior: with the appropriate pair of flags, or use the corresponding Spaces and Exposé settings in the Attributes Inspector if you're creating the window in the nib. Either Can Join All Spaces or Move to Active Space will make sure you stay visible on every space, in slightly different ways. You'll probably want Exposé set to Stationary, or possibly Transient, too. Again, try both ways and see.
However, Lion will hide both all-spaces and move-to-active-space windows when the user switches to a full-screen space or to Dashboard or Launchpad. And if you watch, you'll see that it does this in different ways for each of the three cases. And that Snow Leopard does things a little differently, and so does Mountain Lion.
If you want to solve that last problem, you need a bit of hackery—and different forms of hackery for each case and for each OS version. The basic trick is to catch the hide-related notifications and unhide yourself at the appropriate time.
You should modify your info.plist and set the Application is Agent flag to YES. An agent's window can be displayed in front of fullscreen windows.
Setting both,
"Application is agent (UIElement)" to "YES" in info.plist
&
window level :
self.view.window?.level = NSWindow.Level(rawValue: kCGMainMenuWindowLevel.hashValue - 1)
self.view.window?.collectionBehavior = [.stationary, .canJoinAllSpaces, .fullScreenAuxiliary]
helped me.
I'd like to create a toolbar item like the central item seen in Xcode/iTune/Instruments/etc:
Can anyone tell me what it's called and how to go about creating my own?
Also, will I face problems getting my app approved by Apple when I submit it to the Mac App Store, for imitating Apple's own apps too much?
I finally implemented the solution from here:
iTunes or Xcode style information box at top of window
Here are the initial results:
This is an Apple's private control, but you cannot create it as a NSToolbarItem. Check this other Q/A to know how to add a custom view in the window's main frame.
Is it possible to draw in the label area of NSToolbar?
I've noticed some interesting things about Instruments:
If you make the window narrow such that the overflow menu is triggered, the items in that menu are all blank.
You can't change the icon size or turn labels on/off.
Colors does not have a label when you add it to the toolbar.
The labels on Space, Flexible Space, and Colors do not line up with the other items' labels.
These are interesting because they seem to fit an idea I had for implementing this: turn labels off, and give all your items custom views, where normal-looking items actually have manually drawn labels. It would obviously be a lot of work, but it gives you enough freedom to effectively do full-height items.
The nice thing is that, unlike the view/window hack that Xcode seems to use, you still have a customizable toolbar with draggable items.
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 want to create an NSWindow (or something else) that can appear above the mac menubar. I know this is possible because TeamViewer does it with their "mouse" image.
Example: http://i.stack.imgur.com/6iZbG.png
How do they do it? (or, how can I do it?)
You want to check out window levels, as alluded to in moritz' comment. Any level above NSMainMenuWindowLevel should appear above the menu bar.
If you really want to be above everything else, you can use a shielding window level (not technically part of the regular NSWindow window level). Shielding windows are intended for full screen apps which take over the screen, but you can use a regular window which does this. I have a magnifying glass type app that uses this to good affect.
[myWindow setWindowLevel:CGShieldingWindowLevel()];
Also as alluded to moritz' comment, doing this is generally a bad idea, so make sure you've a good reason for doing so.
I am creating a Cocoa Application for Mac OS 10.6 >, and I want to hide the toolbar of an NSWindow automatically when it is not in use for at least 30 seconds.
I think this can be done with NSTimers, but I'm not familiar with them and I don't know how I can implement this.
Another problem is that both the NSToolbarDelegate and NSWindowDelegate protocols don't have delegate methods like toolbarDidShow:
Can anyone point me in the right direction? Thanks.
PS. This is not to punish the user, but rather give the user a cleaner window (the window consist of only a toolbar for color and font and a text-view).
PPS. Can the hide-toolbar-animation lead into a problem with the cursor while the user is typing?
I think this can be done with NSTimers, but I'm not familiar with them and I don't know how I can implement this.
The Timer Programming Guide might help you here. It's easy enough to show and hide the toolbar, use -setVisible:. Also, -isVisible can be used to determine the visibility of the toolbar.