I'd really like to create a table view that is segmented similar to the screen shown ( which is taken from the XCode->Build Phases view ). To be honest, I'm a bit lost on how to start there.
I could use a NSTableView + a custom NSTableCellView that manages the expanding/collapsing behaviour, but I'm entirely not sure if the resizing of an individual row is possible or permitted ( the doc isn't too verbose here ).
The second approach would be to choose a NSOutlineView to accomplish this behaviour, yet it would require some serious subclassing to get where I'd like to go.
So, before I'm doing it wrong again, what would you do? Thanks a lot for your time
– Moritz
I am quite sure that is an NSOutlineView (not sure if is one big outline or 4). The subclassing isn't as hard as it looks. The only item that requires custom drawing is the root element (that's the row with the disclosure triangle.)
Related
I'm currently working on a prototype for a todo type app. I have a table which contains the user tasks. What I want to do is only present the user with pertinent task information. But to edit additional information, they would click on a disclosure button to expand the cell.
I was thinking of two possible ways to handle this:
Expanding NSTableViewCell
Using an NSStackView as the contents of each cell
If using the NSTableViewCell, I would probably have two NSViews to represent the cell (top part and lower part).
If using the NSStackView, I'd have an easy means of encapsulating the parts.
I suppose another method could also be just building it entirely with NSStackView.
The more difficult aspect of this seems to be related to the actual expansion/collapse of the cell.
I understand this could be deemed the type of question that's asking for an opinion. I've never built a MacOS app. So I'm looking for some guidance as to the best method to approach the problem versus spinning my wheels on approaches that are destined to not be productive.
Thanks!
In the end, it looks like the best thing to do is use an NSTableCellView with two NSViews for the top and bottom half. I had the case of this as well as the NSStackView working. But in the end, I found that using NSStackView to collapse or expand requires a call to make noteHeightOfRows work anyways.
So it would initially seem that it's not worth the effort of expanding it unless I have a more complicated cell where say I wanted a top, middle, and bottom, where the middle could expand and contract. While I would still need to use noteHeightOfRows, it would allow for it.
However, there is one benefit of using the NSStackView. The animation is much smoother for the collapse. I've found the NSTableCellView method with a top and bottom NSView shows signs of "tearing" as it collapses. This is what appears in the bottom edge, while horizontal, jitters. This is particularly apparent if you either spam the button or if the cell is selected because the bottom of the outline can sometimes grow in height.
I also found that when using NSAnimationContext to help make it look a little smoother, I'd see strange behavior. Like the hide would happen at the wrong time (even though it was in the completionHandler. I think the root cause of that are what becomes overlapping animations.
First time building a user interface, had a few general questions
1) Does it really matter if you drag and drop view objects into view controller.. or if you programmatically add subviews and specify frames and fonts? What's the better approach to take?
2) In the programmatic approach, I end up guessing frame values, (x,y) points, and then checking in simulator if I like it. Is this the right approach, or are there faster, better ways to build out the UI? Maybe methods I'm not aware of?
3) Any useful tutorials/pointers in the right direction on how to get started?
Thanks!
1) Both approaches are fine, but the Interface Builder is usually better if you have a more static UI. In a more dynamic app (where views appear and disappear, or if you use UIViewController containment), you need to add/show/hide some of the views in the code. Even in that case you can design individual views in the IB, to make sure they look good, and then instantiate and display them in the code.
2) If you design your views in the IB, then the problem of guessing the sizes largely disappears. In some cases it can be useful to have an empty view added in the IB, which acts as a placeholder for your dynamic content. Then, when you add a view to it in the code, you just use the superview's dimensions so your view fills the placeholder.
I am trying to create a view for a kind of brainstorming application like, for example, OmniGraffle, with elements that contain textviews and can be dragged around. (Also, the should be connectable with arrows, but that is not (yet) the problem)
I did my homework and searched via google and read books about cocoa, but there seems to be no similar example around.
Since I am also new to cocoa, I’m a bit helpless here.
The thing I am sure of is, that I need a custom view in which I can create my elements - what I tried until now to do that is:
First, I searched for the syntax to add subwindows to a window to create my elements. Subwindows, I imagined, would automatically be movable and come to front and so on.
The problem: As the experienced Cocoa-programmers of you probably are not surprised, I was stunned to find nothing about anything like that - this seems to be something, that is just not intended in Cocoa?!
Then I thought about creating subviews that contain a custom view for the title bar drawing (where the user can click to drag the element) and a NSTextView.
Problems:
I read, that it is not so clever to create dozens of subviews in a window because that would be very slow (or would that be not so bad in this case because all the subviews would be instances of always the same class?).
Also I can’t find out how to load a subview from a nib- or xib-file. Would I need a viewController? Or would that make the dozens-of-instances-problem even worse?
And Apple tells you not to overlap subviews (okay, that would be not so important, but I really wonder how the guys at OmniGroup made OmniGraffle...)
Because of that, I now wanted to do the title-bar-drawing in the surrounding custom view and create the textview programmatically (as I understand, a text-“view“ ist not really a view and takes its functionality from NSCell to reduce all the effort with the views?).
Problems:
Even that failed because I was not able to create a textview that doesn’t fill the complete window (the initWithFrame: of the [[NSScrollView alloc] initWithFrame: aRect] just seems to be ignored or do I get that wrong?).
Also, there should be some buttons on each element in the final application. I imagine that would be easier to accomplish with a subview from a nib-file for each element?
Well, now that nothing works and the more I read, the more problems seem to occur, I am pretty confused and frustrated.
How could I realize such a program? Could someone please push me in the right direction?
I created a class for the draggable elements where I save position, size and text in instance variables. In my view, every new element instance is added to an array (for now, this works without a controller). The array is used to draw all the elements in a loop in drawRect:. For the text of the element I just use a NSTextFieldCell which is set to the saved text from every element in the same loop.
That way it is also possible to overlap the elements.
I want to build a Cocoa App with a list of entries very similar to the ToDo list of Things.app (see the screencast). The question is whether I should use
a TableView,
a CollectionView or
a WebView.
I think it could work with all of them, but which one suits the following requirements best?
have a list of entries -> 1 column & many rows
reordering with drag & drop
select single entries & use keys for actions like delete
open up an entry: the row should expand to show more input fields
customized look: rounded corners, shadow, background gradient
So far my research says that the TableView has most of the functionality, but is harder to customize in its appearance, the CollectionView doesn't have drag & drop (right?) but is easy to design and the WebView would take much effort to not hurt the user experience and I can't bind my model directly to input fields.
What pros and cons am I missing and what would you recommend to use?
A WebView doesn't make sense. You might as well create a web application if you use a WebView. An NSCollectionView is more for grid like data, like TV listings per hour.
NSTableView is the only one that makes sense in this case. I've implemented all 5 bullet points with with an NSTableView without issue. You need to extend NSTableView and do some custom drawing for the customized look. That's the hardest part.
open up an entry: the row should expand to show more input fields
You need an outline view. A table view is for flat lists.
Note that NSOutlineView is a subclass of NSTableView, so all the table-view features work on an outline view as well.
There are people who've done this already. One that I've used successfully is by Matteo Bertozzi and is available here: http://th30z.netsons.org/2009/03/cocoa-sidebar-with-badges-take-2/ It might take a bit of massaging to get it to work properly (especially if you need complex drag-and-drop behavior), but for basic functionality, such as getting the section titles and items in the list, it works excellently.
Edit: This has come up before and is a common question on the cocoa-dev email list. Here are some other options.
Just took a look at Things.app itself using "F-script anywhere".
They've used a subclass of NSTableView called "DetailTableView" which presents the condensed todo items. Collapsed todo items are implemented using a custom cell called "ToDoCell", but the expanded look you get when editing is interesting. In that case they've got a custom view called "ToDoEditView" which is inserted as a subview of the DetailTableView when required. I suspect this editing view is temporarily added as a subview in the correct location and the corresponding row of the tableview gets resized temporarily while it is present.
All pretty speculative .. I'd love to know the details of how this was done. It's an awesome UI.
I'm approaching the very same problem in my app (with one big list similar to the Things todo list) and I think a table view would make a lot of sense here.
The trick is having your cells ("rows") expand when double-clicked. That's about all the progress I've made so far.
I think the title pretty much says it all... I'm looking to implement an interface similar to the standard OS X sidebar used in all the above mentioned programs, and I'm wondering if anybody has any thoughts as to the easiest way to do it, namely about what view to use for the left hand selection pane. Really I don't think I even need the hierarchical component as seen in the apple apps, I just need a good looking flat list of choices which determine what's shown in the right hand pane.
The obvious start is a vertical split layout view, but beyond that I'm not entirely sure where to go. A collection view with only one column or something like that?
I've done a few applications that use a similar setup.
I generally use an NSSplitView, with a single column NSTableView in the left pane. Don't forget to disable the headers, and make it display as a "Source View" style.
If you want the disclosure triangles, then you'll want to use NSOutlineView instead of NSTableView, but at least for the first go, I'd stick to a simple NSTableView.
A pattern I also use is to make the NSTableView slightly shorter than the NSSplitView, and have buttons at the bottom (add, delete, etc). I've usually built the program around Core Data, so it's easy to hook up these to methods to create/delete objects, and then bind the NSTableView to the array of objects.
Direct support for this sort of thing was added in Leopard. It's called a 'source list'.
Please see the AppKit release notes. Search for NSTableViewSelectionHighlightStyleSourceList in the document.
Or, drag out a table view and select Highlight: Source List in Interface Builder.