Is there a way to have a single full-screen picture load when the cocoa app is launched? What I mean by that is a full-screen picture, without the menus and stuff that cocoa automatically attaches to apps.( For example, I want to build an app that when the user clicks it - it brings up a picture of say, a zombie, completely full screen - kind of like the end of that maze game.)
While I'm not aware of any maze games that feature a zombie at the end (though I imagine it would be a great companion to Plants vs. Zombies), you can achieve your goal by using NSView's built-in full-screen method -enterFullScreenMode:withOptions: and exit with -exitFullScreenModeWithOptions:.
To enter full screen at launch, just use the NSApplicationDelegate method -applicationDidFinishLaunching:.
As for UI arrangement, I'd just open MainMenu.xib in Interface Builder and delete the window, then drag an NSView ("Custom View") or just a NSImageView into the IB document and open it up. Create an outlet to the view in your app delegate / app controller and connect it to the view.
Related
I have been making iOS apps for a while now and I decided that I wanted to start working on making some of them for the Mac too.
The question I have is this: is there any need for an NSWindow, now that developing for the Mac is so similar to iOS??
So I made a simple cocoa application using Xcode and its comes with a storyboard called "Main", just like on iOS.
In that storyboard file, there is a NSWindow which then links to a NSViewController.
Can I get rid of that NSWindow? As I tried setting the NSViewController as the "Initial Controller" and the app still works fine. So whats the point of the NSWindow?
Also, what class links to the NSWindow? I was trying to blur that background of the NSWindow, but I have no way of linking code to the NSWindow.
Sorry for my stupid questions, but I am completely new to development for OS X.
Thanks for your time, Dan.
Those are many questions in one question:
Can I get rid of NSwindow? No, you need a window to show you views.
What is the point of the NSWindow? NSWindow is needed as the window in which the views are displayed and your events are going up the responder chain.
What class is linked to NSWindow? Obviously the NSWindow class, but that is not what you want to know. I think you want to know the delegate that controls NSWindow. This is NSWindowController, although for the MainMenu.xib it is NSAppDelegate.
Hope this gives you the answers you need. An example for working with views in a window is given in this question.
Please, see for further details the windows programming guide, which states:
The NSWindow class defines objects that manage and coordinate the
windows an application displays on the screen. A single NSWindow
object corresponds to at most one onscreen window. The two principal
functions of an NSWindow object are to provide an area in which NSView
objects can be placed and to accept and distribute, to the appropriate
views, events the user instigates through actions with the mouse and
keyboard.
For the question: Can I get rid of NSwindow? I have further comments. In most cases, You need a NSWindow to show view on screen; but in special case you don't, for example, a popup view when you click a NSStatusItem.
So my answer is whenever you need to respond window event such as min/max, you need NSWindow as the view container.
I have a question, I do some iphone application and now I want to do a little mac application.
From a clean application I add a button on MainMenu xib, than I add a NSViewController to MainMenu (from IB) with one Action.
I create a new NSViewController (FirstViewController) with a nib file and a button.
Now I want only to create a function to push FirstController from MainMenu and a simple function to push MainMenu from FirstController.
something like this
ViewController = [[ViewController alloc] initWithNibName:#"ViewController" bundle:[NSBundle mainBundle]];
[self.navigationController pushViewController: ViewController animated:YES];
How can I do it???
I think you're trying to bring an iOS-style interface to MacOS X, and that won't work in many cases. The MacOS X user interface is very different from that of iOS.
iOS apps are limited to a single (and often small) window, and users generally do one thing at a time. The navigation interface standardizes the way that users drill down through different parts of a task so that the journey is predictable. The interface is very modal in the sense that the user is constantly navigating between different parts of the app, and user actions are often linked to the part of the app that's active.
The desktop, on the other hand, has plenty of screen space and allows multiple windows. Desktop apps should be modeless -- a user doesn't navigate through the app, but sees the whole thing laid out before him or her. As much as possible, the user should be able to perform any action at any time.
For these reasons, there is no navigation controller in Cocoa similar to Cocoa Touch's UINavigationController. If you can tell us more about the tasks that your two view controllers manage, perhaps someone here will help you think of ways to translate that better to the expected desktop experience.
Here apple discusses the migrating iOS to OS X strategies. Your scenario is also discussed here:
For example, AppKit uses the NSBrowser class to manage the display of
hierarchical information; in contrast, an iOS app would use navigation
controllers.
And NSBrowser can be seen in use here with the output as shown in the attached image.
I am about to tackle my first Mac OSX project after developing for iOS.
In my iOS applications, it is clear to me the whole NavigationViewController->MyViewController->MyViews paradigm.
A bit more background on the iOS app so it would be easier to understand me:
The application is some sort of graphic viewer. Once you login you have a list of drawings, and if you select one, it opens it up.
Now in the iOS app I have a custom UIViewController that have some menu UI and a UIScrollView that holds a UIView in which I draw the drawing.
The custom UIViewController is responsible for acting as the "application" where the UIView inside is merely a graphic context.
Now - back to Mac:
I was thinking that my main window would show the drawings and once one is selected,
I would add another window with an NSView that is the graphic context of the drawing,
and the window will be acting as the UIViewController in the iOS app.
Does that make sense?
You can have NSViewController or NSWindowController on the Mac, to put your controller logic in. If you're going for separate windows, subclassing NSWindowController would make sense.
My app has a NSView in a NSWindow which covers the screen and draws a semi-transparent shade on it, above that I've got another NSWindow which contains my app's UI, so the full screen view is designed to fade out background distraction of other windows.
How can I allow mouse clicks on the full screen view to go straight through to the underlying window, which will belong to another app, or even the desktop? Note that I don't want it to keep focus on my app.
Shady by Matt Gemmell does exactly the same, take a look at the source:
http://instinctivecode.com/shady/
It does this by sending the following message to the window:
[window setIgnoresMouseEvents:YES];
I am developing a small app that display the active mounts in a menu in the NSStatusBar. So far it looks like this:
I want to add an eject button to the right of each menu item (like the left bar in the Finder). I know that I have to create a custom view and set it with the setView: method. The problem is that I am very new to Cocoa and right now I don't know how to dive into the custom view topic. Actually, I programmed a lot but never worked with interfaces so far :). Does anyone of you have a good tutorial for adding a custom view to a NSMenuItem?
I think this app will be very handy because you can hide the mounted icons from your desktop. The problem is that you always have to go back to the finder to unmount a volume...
Thanks for any help or tips you have!
It doesn't have to be a custom view. It can just be a standard NSView that acts as a container for standard controls.
The tricky part for a newbie is making the view reusable. You'll want your own NSViewController subclass with a corresponding view nib/xib (set up with your name label and eject button). For each menu item, you'll instantiate a new NSViewController with the XIB ( -initWithNibName:bundle: ) and set its represented object to your mount point. Your view controller subclass will have all it needs to respond to the eject button click, set the label to its represented object's path, etc.