I've been following this thread because I have a similar application in mind, displaying 6 sets (groupings, not NSSets) consisting of a label with slider and textview, both bound to an ivar.
It seems so simple: create a custom view with one set, duplicate it to make 6 such custom views, and place them all into another custom view. I'm not advanced enough to understand why there's a discussion. On the other hand, there seems to be interest in more complex ways, which implies that there are advantages in them that I don't see. Specifically, I don't see advantage in going on with collection views or boxes, and I don't know what you would do with a subclass (of what?). What am I missing? It must be elementary. On Feb 16, 2013, at 10:18 AM, Gordon Apple wrote: > Don¹t use NSMatrix. Use NSCollectionView. I have a popover containing a > collection view with sliders and all kinds of other stuff. Depending on > what you are doing, you may need to make the thing create a new view for > every collection class element instead of just replicating the prototype. > (I have individual QTmovie thumbnails playing in mine.) You will need to > subclass the collection view to do this. However, from your description, > that should not be necessary. The standard prototype view should work > without subclassing the collection view. > > On 2/16/13 4:00 AM, "cocoa-dev-requ...@lists.apple.com" > <cocoa-dev-requ...@lists.apple.com> wrote: > >> I sometimes find that trying to subclass existing classes such as NSCell is >> more trouble that it's worth, unless you really need your custom cell to be >> used anywhere a cell can be used, e.g. buttons, matrices, list rows, etc. If >> you just want a particular custom control that doesn't need that degree of >> reusability, subclassing NSView or NSControl is always a lot easier. In this >> case, if NSSlider isn't suitable, just make a custom view for your custom >> slider, then add it four times to another custom view that handles the "set" >> of sliders as needed. > > > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/pu56ucla62%40alumni.purdue.edu > > This email sent to pu56ucl...@alumni.purdue.edu _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
