It seems like there is a lot of online information regarding switching between views in Cocoa Touch, but not that many in "desktop" Cocoa. For an app I am creating, I am wondering the pros/cons of the methods (and please list the methods if you could), and which one people personally use/suggest. I don't think that using an invisible border NSTabView will do the trick for this specific app, but I value all your options. I will be changing the view with some buttons at the side as show in iPhoto, iTunes, and generally most Mac apps out there.
Thanks for any help.
EDIT: I have looked into using NSViewController, but am wondering what advice anyone has about how to use this/why not to use this.
Cathy Shive has created a framework called KTUIKit which was designed with single window applications modeled after iPhoto/iTunes/etc. The KTTabViewController class in particular may be of interest, as it provides a way of switching between an arbitrary number of subviews. They provide a formal way of dealing with nesting views, keeping the responder chain intact, and keeping various notifications properly observed/unobserved. There are also a series of blog posts describing some of the reasoning behind the design and how the classes work (the blog posts refer to them with an "XS" prefix instead of "KT", but they're basically the same thing).
Check out Brandon Walkin's excellent BWToolkit
NSViewController will work fine. I've used it for a very similar situation without any problems.
Related
I am following a tutorial video on how to allow users to edit their profile. In this tutorial, they are using storyboards and I am not. I was wondering, do I have to use storyboards in order to follow along? Or can I use their code to plug into mine without the storyboard?
According to Apple documentation:
A storyboard is a visual representation of the user interface of an
iOS application, showing screens of content and the connections
between those screens. A storyboard is composed of a sequence of
scenes, each of which represents a view controller and its views;
scenes are connected by segue objects, which represent a transition
between two view controllers.
As you are probably guessing, storyboards contain information about widgets, animations, views that are required by the code you will be adding to yours. Additionally, Storyboards also contain the connection between the visual elements and the code (outlets and actions). All of that can be created programmatically but the code you will be pasting from this tutorial, if it's coming from a project that includes storyboards, won't contain this associated logic.
So, at this point, it would seem highly unwise to add complexity to your tutorial to recreate these elements at once. What I would suggest is for you to follow the tutorial and then try to remove some of these elements and replace them by code to obtain similar results just as an exercise to learn. Keep in mind that Storyboards have been around to simplify the design of UI in the application, so I would recommend for you to master their usage instead of shying away from them.
This is a best-practices question.
When one makes a new Swift application for OSX, it builds a Main.storyboard and places that physically in the Base.lproj folder, but logically within the app's main "group".
I decided to separate different parts of the UI into different storyboards, so I added a Document.storyboard and Preferences.storyboard.
In retrospect it's not clear if this was the correct way to do this - for items that consist of a single window or view, should I use storyboards or just use XIBs? I've read the Apple documents but I'm not clear on the practical differences. Are storyboards "replacing" XIBs, are they the new hotness that I should use from now on?
Now I will be expanding the project with additional views, specifically a series of sheets used for editing certain features of the document. Should I put these all in a single storyboard, one XIB, or individual XIBs? Is there any strong reason to select one over the others?
And finally, when I added my storyboards, it placed them in the root of the project folder. Should these really be moved to Base.lprog?
This is something I've been thinking about, too. I've recently gotten into OS X development, so I'll share my amateur view of XIBs vs storyboards. To those of you that are more familiar with this, feel free to correct me if I'm mistaken.
Interface Builder inside Xcode seems to do a pretty good job of allowing you to put a skeleton in place, but doesn't always provide all the necessary customization options for a view. When using storyboards, I frequently end up with projects that are half visually based, and half code. It's like working on a cyborg.
Nibs/Xibs suffer from the same problem, but they don't even try to implement transitions. From what I can tell, they represent single windows, views, or menu items. This makes them simpler and more modular. You get to write the code that handles the wiring of them together, and, at first, it may seem like more trouble, but it actually feels like a benefit to me because of the level of control gained. Storyboards can do a lot of this for you, but I personally tend to prefer having it all together in the code.
The ideal solution, to me, would be for Apple to implement a more abstract form of user interface design: where each window (or iOS view, depending on the platform) was contained in a nib, and a Storyboard was only a transition mapping between the nibs. For example: You create all your windows and menus, and then use the storyboard to connect them all, but the storyboard can't edit any of the views details, only transitions and connections.
That being said, I'm quickly getting to the point where I prefer nibs and do all the other coding myself. If nothing else, I'm becoming a better programmer for it. Hope this helps!
I'm working on a simple app to learn Cocoa and I've encountered a little rendering bug with the segmented controller.
As you can see here, the view does not display fully opaque. I've looked around to try and find a solution to this to no avail. I did at one point think that maybe this control wasn't supposed to be used in this way but a quick browse through the system preferences yielded several views using this technique.
The control you are looking for is actually NSTabView. Docs here:
NSTabView
I'm getting back in to Cocoa development on the Mac after a long stint doing iPhone work. My previous experience with Cocoa on the Mac has just been dinky little tools. I'm looking to build something serious.
Looking at a modern Cocoa application like iPhoto (or Mail or Things or....) many apps use the Single-Window, Source-List based approach. I'm trying to wrap my head around that as best I can because it seems to provide a good experience. However, I'm having a little trouble. Here's how I think it should look, but I'm wondering how others are doing it, and what's really the best way:
Starting point of the app is an AppDelegate object which, after launching, creates a Window[Controller?] from a nib, along with setting up its data (from, say CoreData)
WindowController loads a window which essentially just has an NSSplitView in it.
Left side of the splitview has an NSTableView or NSOutlineView which is set to have the SourceList style.
Right side has the main content of the app, depending on which item of the table view is selected.
I would assume somewhere (where?) there are NSViewControllers managing each of the different views which will appear in the right side (think how iPhoto has All Photos, Events, Faces, Places, etc. and I imagine they could all appear in different nibs... is this correct?).
Those view controllers are probably bound to the source list on the left.. how does that work (source list is backed by an NSArrayController of NSViewControllers maybe?).
Anyway, those are my thoughts, am I completely off-base or...? I've looked around the web, found this post here, and I've looked at some Apple source code but I can't seem to wrap my head around it. Any guidance would be welcome.
Breaking the views up into separate nibs is mainly good if you're going to swap out some views for others, since you can load them lazily. And yes, in a modern app, you would use NSViewController, or perhaps KTViewController from KTUIKit (see the posts she co-wrote about NSViewController)
Don't just go running into the arms of the source list, however. A single-window interface can be good for simple apps, but it can quickly become unwieldy when you have many things going on, as they may be better served by breaking them into separate windows; iTunes and Xcode both provide many examples of this (especially the latter, since you can switch it between SWI and MWI).
You need to think about whether a multiple-window or single-window interface would be better for your app. There is no one answer for all apps; it depends entirely on your app, and what you want it to do, and how you want it to look—you (plus the rest of your team, if you have one) are the only one who can answer this question. You may want to do some paper prototyping to do quick experiments in each direction so that you can hold at least fake examples of both UIs up against each other.
One easy way to get a feel for the way nibs are split up is to just go into the iPhoto directory and start opening up nibs
If you want to explore a little more into the class structure you can try browsing around using F-Script
I’m writing a simple iCal-like app in Cocoa that I’d like to resemble the main view of iCal.
Does anyone know which GUI element (i.e. NSWhatever) was used to create the Month-view (this thing: http://skitch.com/edwardog/b38ba/ical)?
Thanks!
PS – A hint at figuring this sort of thing out for myself would also be well appreciated; I’ve got a feeling that the answer lies somewhere in .nib, but after poking around I didn’t have much luck.
CalendarWindow.nib, "Window".
Looks like it's all custom views I'm afraid.
The main calendar view must be a custom subclass of NSView, with custom drawing in the overridden drawRect: method.
If you really feel like poking around in running applications, check out F-Script Anywhere.
I'm not claiming that iCal uses it, but you might try NSDatePicker, which supports a calendar style.