Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Preferred way to use a variant of JNWCollectionViewCellBackgroundView #102

Open
crispinb opened this issue Feb 17, 2014 · 2 comments
Open

Comments

@crispinb
Copy link

In a project of mine I use a variant of JNWCollectionViewCellBackgroundView. I have very simple drawn cells that I want Core Animation to stretch nicely, so my variant (1) is supplied with a pair of CGImages (one per resolution) rather than an NSImage, (2) sets the CALayer's .contentsCenter to (0.5, 0.5, 0, 0) to make the stretch correct for my purposes, and (3) overrides viewDidChangeBackingProperties to select the right CGImage for the layer.

To get this working, I've just made these changes directly in my local JNWCollectionViewCell.m. If such a variation would be of wide enough interest to submit as a pull request, what would be the preferred way of allowing users to customise the cell background view in related ways?

The very simplest (and with smallest necessary change to JNWCollectionViewCell) would be to have something like a customBackgroundView property on JNWCollectionViewCell. If this was set, the framework would back off and leave the background view entirely to the user. Its only role would be to place the view correctly re frame and zorder.

Thoughts?

@jwilling
Copy link
Owner

I'm glad you mentioned the background view because that's something that I think needs changing.

Right now it's created whether or not it's needed. If a background color or background image isn't set, there's an unnecessary view that is created. So it should be lazily created the first time any of those two properties are set.

In your case, I can't help but wonder if it'd be easier to set a custom content view instead of messing around with the background view. Regardless, I think your suggestion of having a readwrite property for a custom background view is perfectly legitimate, although I would want to keep the name the same for backwards API compatibility.

I'll leave this issue open for when I get some time to do some work on this library again, although I've been swamped with work lately so I'm not sure how much time I'll have.

@crispinb
Copy link
Author

In your case, I can't help but wonder if it'd be easier to set a custom content view instead of messing around with the background view.

Easier, yes, but less natural/readable as I also have true cell content views. My background views are basically just outlines with colour overlays, ie. they really are 'backgrounds', so it would be nice to name and treat them as such.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants