Is this possible to get the coordinates of where the text drawn in standard (not custom) Cocoa controls? Actually, I need a baseline of the text, the y-axis offset value (relative to the y-origin of the view’s frame rectangle).
This is what the Interface Builder shows on design pane when Layout->Show Layout Rectangles selected.
Unfortunately, there isn't a single solution that works for all controls and cells. You should be able to get a good approximation of this information with these methods:
-[NSCell titleRectForBounds:]
-[NSCell font]
-[NSFont ascender]
Here's some code that works for NSButton/NSButtonCell
NSRect titleRect = [[button cell] titleRectForBounds:[button bounds]];
CGFloat baseline = ceil(NSMinY(titleRect) + [[[button cell] font] ascender]);
At this point, baseline is in the button's (bounds) coordinate space. You might want to convert it to some other space with -[NSView convertPoint:toView:];
Also, that "ceil" in there is an approximation. Not all controls will do that. Some might floor, or use some other rounding function. Or they might layout their title's completely differently, and this approximation won't work.
Related
I´m setting up my view programmatically to show up when a button is pressed. My question is what's the difference between positioning a View programmatically with CGRect or with Constraints in storyboard/programmatic constraints?
I tried to set it programmatically and it works fine.
Simplified:
With CGRect you give certain values and UIView will have size and position depending on these values
With constraints you give instructions how these values should be created
CGRect will not fit all screen sizes as Constraints will. for example. CGRect x: 100, y: 500 may fit a large screen, but for an iPhone SE it will not work because the Item will be off screen. however with constraints like maybe Centre X & Y with a width and height constraint will centre something in the centre of the screen on all devices.
Is it possible to convert an NSGradient to an NSColor
- (void) viewWillDraw {
NSGradient *grad = [[NSGradient alloc] initWithStartingColor:[NSColor lightGrayColor] endingColor:[NSColor darkGrayColor]];
[super setBackgroundColor:*gradient*;
}
This is my method, I want to be able to pass the NSGradient in as an NSColor, which obviously i cant, is there any way to convert it to one?
On 10.8, you can create, in the following order:
A block that draws the gradient however you like.
An image that is backed by the block.
A color that repeats the image as a pattern.
In this way, you can create a color that looks like anything, including a gradient.
That said, this may not work correctly with window resizing if you try to have the gradient adapt to the size of the background (by using the rect passed to the block) and the background is of a text view in a scroll view. (When I tried it awhile back, the pattern didn't redraw the block; it simply tiled, which looked weird in at least one dimension.) If either your gradient or your window is fixed in size, then you will not have that problem.
NSGradient is not Convertible to NSColor.
The NSGradient class provides support for drawing gradient fill
colors, also known as shadings in Quartz. This class provides
convenience methods for drawing radial or linear (axial) gradients for
rectangles and NSBezierPath objects.
As you want to set the viewBackground to to an effect (Gradient effect) you need to do as:
[grad drawInRect:<the rect of your view> angle:270]; //angle is upto your requirement,
I have a variable sized UIView with a drawRect containing CoreGraphics custom drawing code. The view was originally quite small but has the potential to become very wide and is placed inside a UIScrollView to enable the user to scroll through the view.
At the moment the view is created to be as wide as it needs to be to fit the entire drawing on and the CoreGraphics code draws across the entire view in drawRect.
- (void)drawRect:(CGRect)rect {
// Only try and draw if the frame size is greater than zero and the graph has some range
if ((self.frame.size.width>0) && (self.frame.size.height>0) && ((maxX - minX)>0)) {
// Get the current drawing context
CGContextRef context = UIGraphicsGetCurrentContext();
// Save the state of the graphics context
CGContextSaveGState(context);
// Set the line style
CGContextSetRGBStrokeColor(context, 0.44, 0.58, 0.77, 1.0);
CGContextSetRGBFillColor(context, 0.44, 0.58, 0.77, 1.0);
CGContextSetLineWidth(context, 3.0);
CGContextSetLineDash(context, 0, NULL, 0);
// Draw the graph
[self drawGraphInContext:context];
// Restore the graphics context
CGContextRestoreGState(context);
}
}
I can make this more efficient by:
Doing bounding calcs with the rect parameter in the drawRect and only drawing stuff that is currently visible.
Creating a smaller UIView (say 2x the width of the scrollView frame) and as the scroll position moves, redraw the image and re-centre the scrollView.
Before I go to the effort of doing either of these things, I would like to understand if it is worth the effort and whether I could run into problems later on if the UIView becomes very wide. So far performance is not an issue, but I am worried that memory might be.
Specifically, does the scrollView limit the amount of memory used by the view to the visible area? is the graphics context created the size of the entire view, the visible area or the size of the rect parameter? Are drawing operations outside the visible area simply ignored by CoreGraphics?
Any help and best practice advice would be appreciated.
IMO, it all depends on the rect argument to the call:
- (void)drawRect:(CGRect)rect
and as far as I know, this will be set to the contentSize of your scroll view. Simply, the context and the memory used for it will be related to that rect value.
You might trying doing your own "clipping" of the area you draw in by taking into account the frame of the scroll view.
Better yet, you could have a look at a sample by Apple about tiling content in a UIScrollView. It is sample 3.
Is there a way to create a colored fill pattern dynamically in Cocoa?
In particular instead of using a fixed pattern from an image file via
NSColor *fillPattern = [NSColor colorWithPatternImage:patternImage];
I'd like to create a pattern by dynamically choosing the appropriate colors at runtime.
Background is highlighting a colored object by rendering stripes or squares in the ''opposite'' color on top of it - whatever opposite might mean in this context, but that's a different story..
Being applied to potentially hundreds of objects in a drawing app it needs to be a rather fast method so I suppose just swapping colors in patternImage won't be good enough.
(It did work just fine back in QuickDraw..!)
Why not just draw to an in-memory image and use that for your pattern?
NSImage* patternImage = [[NSImage alloc] initWithSize:someSize];
[patternImage lockFocus];
//draw your pattern
[patternImage unlockFocus];
NSColor* patternColor = [NSColor colorWithPatternImage:patternImage];
//do something with the pattern color
//remember to release patternImage if you're not using ARC
Performance-wise, you generally should be looking at optimising drawing by paying attention to the rect passed in to drawRect: and making sure you only draw what is necessary. If you do that then I can't see the pattern drawing performance being a major problem.
Background is highlighting a colored object by rendering stripes or squares in the ''opposite'' color on top of it - whatever opposite might mean in this context, but that's a different story..
You'll want to use one of Quartz's blend modes (most of them are present in Photoshop, Pixelmator, and Opacity, so you can experiment in one of those apps to determine which one you need).
You should then be able to fill with a static image—or a dynamic pattern, if it's really necessary—and Quartz will blend it in appropriately.
There's no way to do this in AppKit alone; you'll need to get a CGContext from the current NSGraphicsContext and do it in Quartz.
As discussed elsewhere, NSTabView does not have a setBackgroundColor method and subclassing NSTabView and using an drawRect to control it does no longer work - as it does not paint the top 10%, the bit just below the segmented control button.
Now I am a bit surprised by the amounts of work arounds I had to do solving this; see
code: https://github.com/dirkx/CustomizableTabView/blob/master/CustomizableTabView/CustomizableTabView.m
and am wondering if i went down the wrong path. And how to do this better & simpler:
The NSSegmentStyleTexturedSquare seems to yield me a semi-transparent segmented Control. Which means I need to do extra work to hide any bezel lines (line 240, 253).
is there a better way to do this ? I.e. negate its transparency ?
or is there a way I can use the actual/original segmented choise button ?
I find that the colours I need - like the [NSColor windowBackgroundColour] are not set to anything useful (i.e. that one is transparent) -- so right now I hardcode them (lines 87, 94).
Is there a better way to do this ?
I find I need a boatload of fluffy methods to keep things in sync ( line 128, 134, etc).
can this be avoided ?
I find that mimicking the cleverness on rescaling means I need to keep a constant eye on the segemented Control box and remove/resize it. And even then - it is not quite as good as the original
is there a better way to do this than line 157 -- i.e. hear about resizing ? Rather than do it all the time ?
The segementControl fades dark when focus is removed from the window - unlike the real McCoy.
can that easily be prevented ? is there a cheap way to track this ?
Or is this the wrong approach - and should I focus on just a transparent hole here - and let the NSTabViewItem draw a background ? But in any case - then I still have the issue with the Segemented COntrol box - or is there than a way to make that be the default again.
when trying this - I get stuck on the top 20-30 pixels being drawn in the 'real' windows background colour - which is 'transparent' - and hence the colour will not run all the way to the top or behind the segment bar and up to the bezel - but instead stop some 8 pixels below the bottom of the segment controls.
Feedback appreciated - as this feels so far off/suboptimal for such a simple things --
Thanks a lot. Brownie points for hacking/forking the github code :) :) :) As a line of running code says more than a thousand words.
Dw.
PSMTabBarControl is probably the best workaround for you. I have created several custom tab views, but cocoa does not play well with this control. PSMTabBarControl has been updated to support Xcode 4. https://github.com/ciaran/psmtabbarcontrol
Have you tried setting the background color of its underlying CALayer? (Make it a layer-backed view, if it isn't already, by setting wantsLayer = YES.)
If your situation can tolerate some fragility, a very simple and quick approach is to subclass NSTabView and manually adjust the frame of the item subviews. This gives each item a seamless yellow background:
- (void)drawRect:(NSRect)dirtyRect {
static const NSRect offsetRect = (NSRect) { -2, -16, 4, 18 };
NSRect rect = self.contentRect;
rect.origin.x += offsetRect.origin.x;
rect.origin.y += offsetRect.origin.y;
rect.size.width += offsetRect.size.width;
rect.size.height += offsetRect.size.height;
[[NSColor yellowColor] set];
NSRectFill(rect);
[super drawRect:dirtyRect];
}
A future change in the metrics of NSTabView would obviously be a problem so proceed at your own risk!