I'm looking for a way to draw a fade effect on a table view (and outline view, but I think it will be the same) when the content is scrolled. Here is an example from the Fantastical app:
Also a video of a similar fade on QuickLook windows here.
To make this I tried subclassing the scrollview of a tableview with this code:
#define kFadeEffectHeight 15
#implementation FadingScrollView
- (void)drawRect: (NSRect)dirtyRect
{
[super drawRect: dirtyRect];
NSGradient* g = [[NSGradient alloc] initWithStartingColor: [NSColor blackColor] endingColor: [NSColor clearColor]];
NSRect topRect = self.bounds;
topRect.origin.y = self.bounds.size.height - kFadeEffectHeight;
topRect.size.height = kFadeEffectHeight;
NSRect botRect = self.bounds;
botRect.size.height = kFadeEffectHeight;
[NSGraphicsContext saveGraphicsState];
[[NSGraphicsContext currentContext] setCompositingOperation: NSCompositeDestinationAtop];
// Tried every compositing operation and none worked. Please specify wich one I should use if you do it this way
[g drawInRect: topRect angle: 90];
[g drawInRect: botRect angle: 270];
[NSGraphicsContext restoreGraphicsState];
}
...but this didn't fade anything, probably because this is called before the actual table view is drawn. I have no idea on how to do this :(
By the way, both the tableview and the outlineview I want to have this effect are view-based, and the app is 10.7 only.
In Mac OS X (as your question is tagged), there are several gotchas that make this difficult. This especially true on Lion with elastic scrolling.
I've (just today) put together what I think is a better approach than working on the table or outline views directly: a custom NSScrollView subclass, which keeps two "fade views" tiled in the correct place atop its clip view. JLNFadingScrollView can be configured with the desired fade height and color and is free/open source on Github. Please respect the license and enjoy. :-)
Related
As mentioned in the title of this post I want to set the border (color and width) of a subclassed NSTableCellView which is used inside a view-based NSTableView. I tried the following
self.layer.borderColor = [[NSColor greenColor] CGColor];
self.layer.borderWidth = 3.0;
I placed the code in initWithCoder and awakeFromNib without the desired result. Changing the backgroundColor is possible within the drawRect-Method. Can someone point me to the right direction?
Thanks
EDIT
Here is my solution using NSFrameRect
- (void)drawRect:(NSRect)dirtyRect
{
[NSGraphicsContext saveGraphicsState];
[[NSColor lightGrayColor]set];
NSFrameRect([self bounds]);
[NSGraphicsContext restoreGraphicsState];
}
Views on OS X are not layer backed by default. You first need to setWantsLayer: YES
But if you are using drawRect: you can just use NSFrameRect() or one of the similar functions or draw with an NSBezierPath in you cell view subclass. However, keep in mind that usually the row view does background drawing in view based tables.
Sounds like you have a bit of learning yet to do about drawing in Cocoa.
I am looking to alter an existing iOS application so that instead of using multi-touch gestures to size and rotate images (two-finger pinch/zoom and twist), I want there to be a handle on all four corners of the image and one at the top so that the user can grab one of the handles to re-size or rotate.
I have been researching the topic but am unable to find anything pointing me in the right direction.
See this image for an example of what I'm talking about-
I'm assuming that because you're starting with a app that already has working pinch-zoom and twist gestures that your question is merely how to show those translucent circles for the handles. I'd be inclined to create UIView subclass that draws the circle, like so:
#implementation HandleView
- (id)initWithFrame:(CGRect)frame
{
self = [super initWithFrame:frame];
if (self) {
self.backgroundColor = [UIColor clearColor];
self.userInteractionEnabled = YES;
}
return self;
}
- (void)drawRect:(CGRect)rect
{
CGContextRef context = UIGraphicsGetCurrentContext();
CGContextAddEllipseInRect(context, rect);
CGContextSetFillColorWithColor(context, [[UIColor colorWithWhite:1.0 alpha:0.5] CGColor]); // white translucent
CGContextSetStrokeColorWithColor(context, [[UIColor colorWithWhite:0.25 alpha:0.5] CGColor]); // dark gray translucent
CGContextSetLineWidth(context, 1.0);
CGContextDrawPath(context, kCGPathEOFillStroke); // draw both fill and stroke
}
#end
You could achieve the same effect with CAShapeLayer layers, too, if you didn't want to write your own drawRect with Core Graphics calls like I did above. But the idea would be the same.
Your view controller can then add those five views and add gesture recognizers for them, like so:
HandleView *handleView = [[HandleView alloc] initWithFrame:CGRectMake(50, 50, 50, 50)];
[self.view addSubview:handleView];
UIPanGestureRecognizer *pan = [[UIPanGestureRecognizer alloc] initWithTarget:self action:#selector(handlePan:)];
[handleView addGestureRecognizer:pan];
Just repeat that for each of the handles you want on the screen. and then write your gesture recognizer to do whatever you want (e.g. move the bounding rectangle, move the appropriate handles, etc.).
Sounds fairly straight forward. The view hierarchy of one possible solution as ASCII art:
Container (ScalingRotatingView)
|
+----imageView (UIImageView)
|
+----upperLeftScalingHandle (HandleView)
|
+----upperRightScalingHandle (HandleView)
|
+----lowerLeftScalingHandle (HandleView)
|
+----lowerRightScalingHandle (HandleView)
|
+----rotatingHandle (HandleView)
All instances of HandleView would have a pan gesture recognizer, that feeds one of two methods in your controller:
--updateForScaleGesture:, where you’d use the gesture recognizer’s -translationInView: to compute and store the new scale, before updating the frames of all views appropriately, and resetting the translation to 0, and
- -updateForRotationGesture:, where you’d use the gesture recognizer’s -translationInView: to compute and store the new angle before updating the frames and resetting the recognizer’s translation.
For both calculations you need the translation in the coordinate system of the image view. For the scaling part, you can then simply divide the new edge lengths by the natural image dimensions, for the rotation you can use the approximation that only the x component of the translation matters:
sin(x) = x (for small values of x)
Oh, and it sure helps if the anchor point of your image view sits at its center…
My UIView structure:
I have a "master" UIView (actually UIScrollView, but it's only purpose scrolling per pagination).
As a subView on this "master" I have my "pageView" (subclass of UIScrollView). This UIScrollView can have any content (e.g. a UIImageView).
The "master" has another subView: PaintView (subclass of UIView). With this view, I track the finger movements and draw it.
The structure looks like this:
[master.view addSubview: pageView];
[master.view addSubview: paintView];
I know when the user zooms in (pageView is responsible for this) and over delegate/method calls I change the frame of paintView according to the zoom change, during the zoom action.
After zooming (scrollViewDidEndZooming:withView:atScale) I call a custom redraw method of paintView.
Redraw method and drawRect:
-(void)redrawForScale:(float)scale {
for (UIBezierPath *path in _pathArray) {
//TransformMakeScale...
}
[self setNeedsDisplay];
}
-(void)drawRect:(CGRect)rect {
for (UIBezierPath *path in _pathArray) {
[path strokeWithBlendMode:kCGBlendModeNormal alpha:1.0];
}
}
The problem:
When I zoom-in, I receive a memory warning and the app crashes.
In the Allocations profiler I can see that the app own a lot of memory, but I can't see why.
When I don't call 'setNeedDisplay' after my 'redrawForScale' method the app isn't crashing.
When I log the rect in drawRect I see values like this: {{0, 0.299316}, {4688, 6630}}.
The problem is (re)drawing such a huge CGRect (correct me if this is wrong).
The solution for me is to avoid calling a custom drawRect method. In some stackoverflow answers (and I think somewhere in the Appls docs) it was mentioned that a custom drawRect: will reduce the performance (because iOS can't do some magic on a custom drawRect method).
My solution:
Using a CAShapeLayer. For every UIBezierPath I create a CAShapeLayer instance, add the UIBezierPath to the path attribute of the layer and add the layer as a sublayer to my view.
CAShapeLayer *shapeLayer = [[CAShapeLayer alloc] initWithLayer:self.layer];
shapeLayer.lineWidth = 10.0;
shapeLayer.strokeColor = [UIColor blackColor].CGColor;
shapeLayer.fillColor = [UIColor clearColor].CGColor;
shapeLayer.path = myBezierPath.CGPath;
[self.layer addSublayer:shapeLayer];
With this solution I don't need to implement drawRect. So the App won't crash, even with a big maximumZoomScale.
After changing the UIBezierPath (translate, scale, change color) I need to set the changed bezierPath to the shapeLayer again (set the path attribute of shapeLayer again).
I'm trying to create a custom NSButton with a 50% opaque black background and white text. To do this I've subclassed NSButton and overloaded DrawRect:
- (void) drawRect:(NSRect)dirtyRect
{
[self setBordered:NO];
//REMED since it has same effect as NSRectFill below
//[[self cell] setBackgroundColor:[NSColor colorWithCalibratedRed:0 green:0 blue:0 alpha:0.2]];
NSColor* backgroundColor = [NSColor colorWithCalibratedWhite:0 alpha:0.3f];
[backgroundColor setFill];
NSRectFill(dirtyRect);
[super drawRect:dirtyRect];
}
The white text appears fine but the button's background is always 100% opaque. The alpha value is not interpreted.
Any ideas? Thanks!
The default operation of NSRectFill() is copy which is not what you want. Replace it with
NSRectFillUsingOperation(dirtyRect, NSCompositeSourceAtop);
Another solution I found was to keep my code the same but turn on the Core Animation Layer for each button in Interface Builder. I don't know enough about Core Animation Layer to know why this worked. I had previously turned CAL off because it was making my fonts look very jagged.
I have searched around and haven't found anything regarding this particular problem. I have a window with a vertical NSSplitView. Within the right view of the splitview, I have an NSBox object set to fill the contents of the view. I am loading in custom nibs using setContentView: to swap in views to the NSBox on the righthand side of the splitview. In my custom views I'm tying to fill the views with an NSColor object that uses a NSImage to pattern the background. All of this is working as expected. I am using the code based on this article: http://www.mere-mortal-software.com/blog/details.php?d=2007-01-08 to set the phase of the pattern to the top-left corner:
[[NSGraphicsContext currentContext] saveGraphicsState];
[[NSGraphicsContext currentContext] setPatternPhase: NSMakePoint( [self bounds].origin.x,
[self bounds].size.height )];
[[self leatherColor] set];
NSRectFill( [self bounds] );
[[NSGraphicsContext currentContext] restoreGraphicsState];
with the intention that the pattern appears to remain constant in the upper lefthand corner of the NSBox when the views are re-sized as would be the expected behavior (via the splitview moving or the window itself being resized). I have implemented this in a stripped-down test app with just a window and a custom view and it behaves as expected.
In my project with the splitview however, it is behaving like the patternPhase is being set on the upper lefthand corner of the entire window instead of the upper lefthand corner of the right-half of the splitview (i.e. it should shift with resizing the splitview) It behaves like it's "revealing a larger image instead of shifting with it. I'm pretty certain this is an issue with multiple coordinate spaces, me misunderstanding how the coordinates of an NSSplitView work, or something to do with the view hierarchy. From the documentation on NSGraphicsContext, in the setPatternPhase: method it says: "For example, setting the pattern phase to (2,3) has the effect of moving the start of pattern cell tiling to the point (2,3) in default user space." Will the default user space correspond with the bounds of my custom view, or could it be that I am creating the point based on the right side view set of coordinates and the setPatternPhase implements it for the full width of the spitview (including the left-half)?
Any suggestions/advice/help you could provide would be greatly appreciated.
Edit: I have uploaded a copy of the project so you can see the behavior: http://dl.dropbox.com/u/6679821/ViewSwitcher.zip
You need to adjust the phase depending on where the view sits in the window. I use this category on NSView:
#implementation NSView (RKAdditions)
- (void)rk_drawPatternImage:(NSColor*)patternColor inRect:(NSRect)rect
{
[self rk_drawPatternImage:patternColor inBezierPath:[NSBezierPath bezierPathWithRect:rect]];
}
- (void)rk_drawPatternImage:(NSColor*)patternColor inBezierPath:(NSBezierPath*)path
{
[NSGraphicsContext saveGraphicsState];
CGFloat yOffset = NSMaxY([self convertRect:self.bounds toView:nil]);
CGFloat xOffset = NSMinX([self convertRect:self.bounds toView:nil]);
[[NSGraphicsContext currentContext] setPatternPhase:NSMakePoint(xOffset, yOffset)];
[patternColor set];
[path fill];
[NSGraphicsContext restoreGraphicsState];
}
#end
In your case you'd modify -drawRect: to look like this:
-(void) drawRect: (NSRect)dirtyRect
{
[self rk_drawPatternImage:[self leatherColor] inRect:self.bounds];
}