I'm experimenting with NSCollectionView after doing some practicing with UICollectionView for iOS. I'm planning to write an app which central part is a flexible grid view on that cards can be dragged around freely and I want to start with a OSX version first before tackling a iOS version.
The UICollectionView seemed like a good choice for my purpose so far (with a custom UICollectionViewLayout anyway) but now that I'm getting to know NSCollectionView for Cocoa on OSX this class seems rather meagre since there doesn't seem to be a comparable NSCollectionViewLayout class and in-depth info or tutorials on the web seem really sparsely seeded.
So is the NSCollectionView class actually a recommended choice at all for what I need? Or could anyone recommend me a better approach to get started going the right way with this?
(What I need is a performant, scrollable view with rows and columns onto that sub views can be dragged and dropped around freely.)
I agree, not recommended.
NSCollectionView performance is bad.
NSArrayController is an enigma also.
That said, there was a old example of someone rolling their own,
which is good sample code to peruse.
... google "TigerCollectionView".
Your going to run into issues with every user interaction... drag, drop, insert, deferred layout, reload, etc.
Better to roll your own using arrays of dictionaries, so you can see whats going on.
Related
I am quite new to NSTableView but as I tried to get things straight, I took a look at InterfaceBuilder!!
TableView hierarchy
I understand that objects are responsible for scrolling and clipping. TableView is the real NSTableView instance. The object titled function list ist the NSTableColumn below that is my TableCellView objects. What I don't understand is the object TextCell. It doesn't seem anything to do. Even wrong colors and alike have no effect at all. I am using a view based variant. Is the TextCell solely for cell based TableViews?
I found that part not quite well documented. I am planning on building custom views for my table. So I was thinking a thorough understanding would be a good approach.
Yes, it's strange that that's still there. It's useless and has no effect on anything, but you can't delete it. Ignore it.
I'm an intermediate iOS developer who's trying to jump on the OSX side of things.
I've been struggling to create an accordion-like display of several views, where only one view at a time can be unfolded to occupy the whole parent's view's available space. In other words, click on a view's title bar, it will both open/unfold this view and close/fold the currently open view, with animations'n'all. Oh end, I need the views' contents to be scrollable.
I tried starting from Apple's NSStackView sample code, but first it is not quite what I want, and what's more, I can't figure out how to start from here to end up where I eventually want to be.
Then I tried to master the Auto-Layout facilities but with no success. Truth be told, this whole Auto-Layout thing still confuses me some.
Does any of you have clues as to how I should proceed? Sample code? Tutorials (I tried several Auto-Layout tutorial but at the end of the day they still leave me missing the tricks I'd need to figure...).
Thanks.
/Julian
Check out the sample code: InfoBarStackView. It creates an accordion-like interface, the one difference from what you're describing is it lets multiple views be revealed at the same time (although, that's a simple difference).
It uses NSStackView and autolayout constraints to create the interface and drive the reveal/hide animations.
The stack view could also be put into an NSScrollView to allow the content to be scrollable. (Something similar was done during a WWDC 2013 Cocoa Animation talk).
I want to achiece the following scenario,
My idea is to have three different tableview. But i have stuck up with the scrolling problem that if i scroll tableview3 vertically, tableview1 & tableview2 should also scroll.
Is there any other idea for implementing this? Or else a solution for my scrolling problem?
Note: The number of columns are dynamic.
Happy Coding
I'm currently in the process of implementing a similar UI system, I gave up on using UITableView for it in order to make things a little more 'dynamic'. Re-implemnting all of UITableView from scratch is a really fun exercise!
If UITableView will still work for you, all you need to remember is tableview's are subclasses of UIScrollView, which has delegate methods for scrolling. Use those, along with setContentOffset and you can trivially sync the scrolling of multiple tables.
I’m starting to develop my first full-blown Cocoa application containing a view which I would like to behave (and look) similar to Automator’s AMWorkflowView.
The basic features I’d like to achieve:
Positioning of subviews
Display of subviews in expanded / collapsed states
Multiple selection
Drag and drop
In order to get accustomed to Cocoa, I started with a custom NSView which mainly served as a container for the custom subviews and handled their positioning and multiple selection.
The subviews are also subclasses of NSView, and contain a variable amount of views themselves, like buttons, labels and popup menus, and therefore can have different heights.
This worked quite well, but before going on, I want to make sure to have everything neat and tidy according to the MVC pattern.
I suspect that there already is a class in Cocoa that facilitates the implementation of a view container, like maybe NSCollectionView.
It seems that there is no (easy) way to display differently sized views in an NSCollectionView, though. Should I continue implementing my custom NSView (probably using an NSArrayController for selection and sorting support), or are there better ways to go?
Any help is much appreciated
Unfortunately the answer is you'll have to roll your own. NSCollectionView does not allow for variable-sized items (which also rules out expanded/collapsed states).
For a limited number of items, you can accomplish this rather easily (you just need a container view that arranges the subviews properly when asked to layout, then you need to make sure you re-layout when things change). For many subviews, however, you'll need to take care to be as efficient as possible. This can start with laying out as little as possible (only those "after" the resized view, for example) and get as complex as caching a visual representation of a prototype view, drawing the cached images (fast!) for all but the view being edited, and only using/positioning a "real" view for the view being edited.
Drag and drop works the same as it always has, but none of the above accounts for the pretty animation NSCollectionView gives you. :-) It's fast and beautifully-animated precisely because all the subviews are uniform (so the layout calculations are fast and simple). Once you add irregular sizes, the problem becomes significantly more complicated.
The bottom line: If you need variably-sized views, NSCollectionView will not work and you'll need to roll your own or find someone else's shared code, but performance and beautiful animation will not be easy.
I currently have to develop a system very similar to MIT's Scratch's UI. In case you don't know it, here a screenshot: http://kidconfidence.com/blogs/wp-content/uploads/2007/10/scratch1.png
Basically you have bricks in the library on the left you can drop into the window on the right side. The problem I have is that I'm new to Cocoa and not sure what would be the best way to accomplish that.
Because you can nest these bricks sometimes and other times stick them together I wonder if there is something that would help implementing that. I recognize this is not a very common interface that there are probably no implementations of that around, but maybe there are helpers for parts of this.
Regards,
Armin
Edit: switching to desktop
There are no standard cocoa controls that you could leverage for the building blocks. You will probably want to subclass NSControl to make your standard brick object.
The list on the left could be an NSTableView. The main work area can be an NSScrollView.
You probably want to use your own brick hierarchy independent of the view hierarchy because of the freeform dragging.