Good evening.
I have two controllers. Call them NSViewController1 and NSViewController2. Controllers placed on one NSWindow and have some network logic. It's not very good to delete them from memory while program is running.
I would like to create button. If user click on button, single window should separate on two windows. First of new window should contain NSViewController1 and second window should contain NSViewController2. Much better if switching is animated.
What is the best way to implement described behavior? May be somebody saw an open source project with this task?
It would be best if you had a controller which controls both your window controllers, as well as both of your view controllers.
If the button is clicked, you can send a message to this controller and remove the second view from the window and add it to the other window.
And of course adjust the frame of those. I guess it's not that big of a deal.
Related
I've got a button in a toolbar that I'd like to use to control the state (expanded/collapsed) of the right-hand-side split of a split-view. In a xib-based project this is trivial, but I'm using storyboards, and can't work out what the best approach is.
The key limitation is the fact that I'm not able to create target-action connections between objects in different scenes. As I see it, this leaves me with three options:
Have the window controller handle the expand/collapse request - this seems inappropriate - what's the window controller got to do with the state of the split view?
Have the window 'collect' the action and refer it on to the split-view controller for processing - this is better but to me it still seems like bad design to have the window controller in this process at all.
Add a custom action to the responder chain, and connect the button's selector to the responder chain. This is what I've done, but it still seems like a distant second-best compared with the xib-style approach - a direct drag-and-drop between objects.
I suppose as I was hoping that storyboards would just make everything easier - am I now right in thinking that this target-action dilemma is a genuine shortcoming of the storyboard approach, and that I just need to get used to one of the above?
So I am trying to emulate the new cleanlymac app. It looks like it has two windows on top of each other, one without the traffic lights and the other with it, but they were treated as one. That had the ability for the back one to slip out at the beginning. Would anyone have a good idea of how this was constructed?
Here is a photo of the cleanmymac app:
They are actually ONE WINDOW.
You can easily acheive this by using vertical NSSplitView with 2 panes.
Here you can opt for divider in between or fix the splitter.
And in each of the splitViews a new NSView is placed. Here in this view you can put your views from a single or multiple xibs.
Check here for ViewOnWindow how you can show a view from another xib to your main window.
Check here for tutorial.
That looks like a custom window with the black background for the top right part of the window. Search for custom window cocoa to find examples of how to do this. I don't see the point of the custom window in this situation, you could just split the content of the window, it probable branding.
I have a window that contains several rather complex views. Right now, I'm using a single NSWindowController to control the UI for the window and all the views. It's becoming a pretty huge class, since it's dealing with the details of each and every view.
The view behaviors are independent from one another though, so I see an opportunity to put the UI logic for each view into a separate controller.
According to the Mac App Programming Guide, this is exactly what view controllers are for:
Use view controllers to divide up the work for managing more
sophisticated window layouts. Your view controllers work together
(with the window controller) to present the window contents.
However, I can't find any documentation or examples on how this idea works in practice. Can I add multiple view controllers to the nib file in addition to the window controller?
If you add the view controllers to the nib, that's where they're going to be instantiated, and you'd add IBOutlets to the window controller (assuming that's the nib's File's Owner) in order to connect them.
In terms of memory, however, that scheme could become expensive, especially the more view controllers you have. You may want to instead consider lazily instantiating them in the window controller, (i.e., doing so only when needed), assuming this doesn't result in an objectionable lag before the view is presented for the first time.
Don't be afraid to try both approaches. One of them may be best for you.
In any case, I applaud you for your decision to factor out all that code into separate controllers. Very nice. Good luck to you in your endeavors.
I’ve been reading through several books on Mac development, but cannot find the information I’m looking for.
The books all describe how to make floating windows or panes, but never mention how to make them all in one window. A simplified example of what I’m looking to create is shown below:
Basically, there will be three windows; A selector window with radio buttons to choose which NSDocument is currently being used, a window underneath that with buttons that show different windows to the right that allow viewing and manipulation of certain data.
For a example, each NSDocument may have a color value that can be set in the window shown by clicking view A, and some text strings that can be set in the window shown by clicking view B.
So the questions are:
Is it appropriate to use a single NSDocument sub-class for each Doc #1 and Doc #2?
Which classes should I use to set up the application as shown? NSWindowController? NSWindow? NSPanel?
I’m only looking for guidance on what to read up on, so any pointers are appreciated.
EDIT:
To clarify this further, I want to have a table view where the buttons are (View A & B), and by clicking them they will cause the other window/view to change it's contents.
It's like the split view in the iPad settings application, there is a table view on the left, and when it's pressed the right side changes.
The radio buttons are there only to illustrate that I want more than one Document. I'm guessing I need more than one to handle this? Or perhaps I should place them all in a single NSDocument? Somehow that doesn't seem right.
To achieve what you want you need one window (NSWindow), one window controller and various views each with their own view controller. There are several ways you could set this up, all depending on your requirements:
You'd have at least 3 views (instances of NSView): one for the selection of the document class, one for the view selection and one for the content. Each view is controlled by a view controller (instance of NSViewController). Additionally you can opt to wrap the views in split views (NSSplitView) so your user can resize the real estate available to each view.
You have one window with a window controller. If you choose a Document based app template in Xcode, Xcode will generate a subclass of NSDocument which you can use as your window controller (or choose to use Core Data and Xcode will generate a subclass of NSPersistentDocument with all bells and whistles you need to access Core Data for document persistency).
So to come back to your questions:
1: Yes, but depending on your requirements. If Doc #1 is a completely different thing than Doc #2 than you might need to re-evaluate. For example Doc #1 might have completely different persistent requirements than #2.
2: There's no single scenario here, but one that worked for me: Take the project template for a document based app (with or without Core Data). Use the generated subclass of NSDocument (or NSPersistentDocument) as your window controller. Use NSView to implement the views in your window where each view is managed by its own controller, which is an instance of NSViewController.
I know this is an old question, but a way to do it how you want would be to use: ContainerViews and set their embed segue to be the view controllers you want.
The program I'm working on right now is a bit cumbersome, as it starts with a central menu, and then once the user chooses an option from it it opens their selection in a new window, when I've got a perfectly good window I can (at least apparently) repurpose to that effect. I've been reading the manual regarding views, and I understand what it's talking about regarding view hierarchy and such, but the method of swapping which view is active is confusing me. What do I need to do to have it "sweep away" the initial menu and replace it with another view containing the content the user selected?
Found a simple solution by using NSTabView to hold each of the views I'm looking for.
It sounds like you don't want to change views at all, but change the model you've loaded into the views.
The simplest way is probably to give the controller for the window a property by which the views can access another controller that owns a portion of the model (one such controller for every item in the menu). Then, you simply switch that controller.
In the setter for that property, you may need to send messages such as reloadData to some of the views, depending on what sort of views they are. Views that observe for changes using Bindings or KVO won't need this.