Re: Autolayout Freespace
On Dec 11, 2013, at 11:54 PM, Luther Baker wrote: > And just to clarify, if I need to do some manual calculation, would I be > using frames, etc? "Frame" feels like such a dirty word in autolayout > world; is there something else specific to autolayout (like intrinsic size > - obviously not in this case) ... > > Also, if I need to do some manual calculation, would I do that in the > view's layoutSubviews - and would I remove and create constraints in that > method also - and then tell them to lay themselves out again from that > method as well? You could just create width constraints for your views in IB, and give your controller outlets to the constraints themselves. You could then adjust the "constant" property on the constraints in code. The documentation claims that this performs better than removing constraints and adding new ones. Charles ___ 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
Re: iPad keyboards
> On Dec 11, 2013, at 9:49 PM, Rick Mann wrote: > > They released the latest version of their app Nov 19. They would've had to > build against the iOS 7 SDK. As far as I know, Apple is still accepting binaries linked against the iOS 6 SDK. --Kyle Sluder ___ 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
Re: iPad keyboards
I thought you had to use Xcode 5 to submit now, and I thought it had to be linked against iOS 7. I'm pretty sure Apple rejected one of my binaries because of that. On Dec 12, 2013, at 01:34 , Kyle Sluder wrote: >> On Dec 11, 2013, at 9:49 PM, Rick Mann wrote: > >> >> They released the latest version of their app Nov 19. They would've had to >> build against the iOS 7 SDK. > > As far as I know, Apple is still accepting binaries linked against the iOS 6 > SDK. > > --Kyle Sluder -- Rick signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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
Re: iPad keyboards
Seem to me that Xcode 4.6.3 and iOS 6 SDK is still working, from my friends. On Dec 12, 2013, at 15:25, Maxthon Chan wrote: > Well on OS X Mavericks I have > /System/Library/Frameworks/Foundation.framework/Version/C/Foundation - and I > can assume tat versions A are from NeXTSTEP (possibly used in early PPC OS X > too) > > Also, I distribute my CGIKit framework in two versions, version F and G - > versions F and G have different implementations to support different server > interfaces, either Apache FastCGI or ohttpd bundle interface. > > On Dec 12, 2013, at 15:20, Greg Parker wrote: > >> On Dec 11, 2013, at 10:46 PM, Maxthon Chan wrote: >>> Bad example - you should use the example between NeXTSTEP/Mach and OS X, >>> which the identical technology, library versioning, is used. (People do you >>> still remember that OS X derived from NeXTSTEP, to the extent that OS X >>> 10.0 have version number 4.0, picking up where NeXTSTEP left off, and this >>> still count till now like OS X 10.9 = NeXTSTEP 13?) >>> >>> Also, there is no need of “compatibility mode” as library versioning will >>> allow that with a framework like this >>> >>> UIKit.framework/ >>> + UIKit -> Versions/Current/UIKit >>> + Headers -> Versions/Current/Herders >>> + Resources -> Versions/Current/Resources >>> + Versions/ >>> ++ A/ >>> +++ UIKit >>> +++ Headers/ >>> +++ Resources/ >>> ++ B/ >>> +++ UIKit >>> +++ Headers/ >>> +++ Resources/ >>> ++ Current -> B >>> >>> The version A of UIKit library is what is shipped in iOS 6 (and before), >>> almost as-is. Version B is iOS 7 UIKit that have all the new bells and >>> whistles. >> >> UIKit does not use this versioning mechanism. I believe no framework on OS X >> uses it, and the machinery may have been removed from iOS. >> >> Framework versioning does not scale. The problem is that any use of >> versioning requires duplication across the rest of the system. Say you >> created Versions/A/UIKit and Versions/B/UIKit. Any client of UIKit like >> MapKit now also needs versions A and B, because it can't have just one >> version that links to both UIKits. Propagate that across the rest of the >> framework tree and you end up with two complete copies of every system >> framework. That's bad for disk space and memory usage, if you have two apps >> open that use different versions. >> >> Versioning might have been during NeXT's great Object->NXObject or >> NXObject->NSObject overhauls. (I don't know, I wasn't there.) It has been >> used approximately zero times in the OS X and iOS eras. >> >> >> -- >> Greg Parker gpar...@apple.com Runtime WRangler > > ___ > > 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/xcvista%40me.com > > This email sent to xcvi...@me.com ___ 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
Re: Threaded drawing
On 11 Dec 2013, at 16:01, Jens Alfke wrote: > On Dec 11, 2013, at 4:39 AM, 2551 <2551p...@gmail.com> wrote: >> It’s certainly seemed the case to me that I would have probably spent less >> time just writing my own code from scratch than I spend trying to figure out >> how half the methods I’m trying to use should be implemented. > > That’s probably not actually true; our experience of time is pretty > subjective, and time goes by faster when you’re in a ‘flow’ state than when > you’re trying to figure out something new. > > Even if it’s a bit faster to write your own code, using the system APIs is > probably still a win because > (a) their implementations are almost certainly better debugged and more > performant than your brand-new unused code; > (b) they will be improved and maintained by other people over time, saving > you the trouble; > (c) they’ve been designed to be reusable, so you’ll be able to use them > quickly in your next project; > (d) you can later hang out here explaining the APIs to noobs and make > yourself look like a guru (or better yet, write books) ;-) Let's preface that with the statement that I agree with your conclusion. Using Apple's code generally saves a lot of hassle and work because your code has only you doing QA. Apple's code has all of Apple, plus you, plus everyone else outside Apple who uses this API doing QA. It's bound to be more solid. That said, Apple's code still has only whatever team at Apple is responsible for that code fixing it. Only they have the source code. So occasionally, when a piece of code isn't or stops being a priority for Apple, item (b) above can actually be a liability. Still, we've seen how people circumvent that with sync code and CoreData. People first use Apple's code, getting a leg up and a release out the door and money in their coffers, and can then afford to fund their own version. -- Uli Kusterer "The Witnesses of TeachText are everywhere..." ___ 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
help with logic error
Hi folks
I need some help with a logic error the Static Analyzer is throwing up. I
didn’t write this code (in fact, its a piece of Apple sample code I’m resuing
in my project), and I’m not quite sure how to correct it. It goes like this,
where the numbers [1], [2], [3], [4] represent the end points of the analyzer's
blue arrows:
[1] const NSRect bounds = [self bounds];
[backgroundColor set];
NSRectFill(dirtyRect);
const NSRulerOrientation orientation = [self orientation];
NSRect borderLineRect;
[2] switch (orientation) {
case NSVerticalRuler:
borderLineRect = NSMakeRect(NSMaxX(bounds)-1.0, 0, 1.0,
NSHeight(bounds));
break;
case NSHorizontalRuler:
borderLineRect = NSMakeRect(0, 0, NSWidth(bounds), 1.0);
break;
}
[3]if [4]([self needsToDrawRect:borderLineRect]) {
[[backgroundColor shadowWithLevel:0.4] set];
NSRectFill(borderLineRect);
The error message says, in full: Passed-by-value struct argument contains
uninitialized data (e.g., via the field chain: 'origin.x’).
Thoughts much appreciated.
Phil
___
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
Re: Threaded drawing - JPEG
On 11 Dec 2013, at 18:53, Steve Sisak wrote: > At 10:25 AM -0800 12/10/13, Seth Willits wrote: >> On Dec 10, 2013, at 1:32 AM, Graham Cox wrote: >> > But my situation is that I need to draw VECTOR objects up to 25,000% zoom >> > with no pixelization. >> >> You're given a CGContext to draw into; What's the difference? The tiled >> drawing is async, so if the drawing doesn't occur fast enough it'll scale up >> the low-scale bitmap, but what's evil about that? It's like Apple or Google >> maps. > > Not to hijack the thread, but I'm just getting head into optimizing some code > which displays live preview for a number of JPEG streams simultaneously. > > Most implementations I've tried result in being CPU bound in JPEG code on the > main thread with the 7 other cores idle. > > I've tried variants of NSImageView, CGImage and CIImage and all that's needed > to render them on alternate threads but Cocoa appears to so good at delaying > evaluation as long as possible that it seems to end up calling the JPEG > decoder synchronously from -drawRect of whatever view subclass I've chosen on > the main thread. > > Any suggestions for what technologies to use to run a JPEG through, say > CIImage w/o blocking the main thread. > > This has turned out to be way more complicated than I thought. If you want previews, I think ImageIO has dedicated methods for generating previews (MacOS definitely has some somewhere, even if I mis-remember them being in ImageIO). Particularly in the case of JPEG these can be much more efficient because of the way JPEGs are stored. Essentially, JPEGs often contain a few small DCTs at the start that can give you a vague, blurry version of the image, then draw more DCTs on top to add in the detail (I'm criminally simplifying here). So the preview calls can actually just draw the blurry version into a smaller destination and stop there, and don't have to calculate or even load the rest of the image. -- Uli Kusterer "The Witnesses of TeachText are everywhere..." ___ 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
Re: help with logic error
On 12 Dec 2013, at 11:52, 2551 <2551p...@gmail.com> wrote:
> Hi folks
>
> I need some help with a logic error the Static Analyzer is throwing up. I
> didn’t write this code (in fact, its a piece of Apple sample code I’m resuing
> in my project), and I’m not quite sure how to correct it. It goes like this,
> where the numbers [1], [2], [3], [4] represent the end points of the
> analyzer's blue arrows:
>
> [1] const NSRect bounds = [self bounds];
>
>[backgroundColor set];
>NSRectFill(dirtyRect);
>
>const NSRulerOrientation orientation = [self orientation];
>NSRect borderLineRect;
>[2] switch (orientation) {
>case NSVerticalRuler:
>borderLineRect = NSMakeRect(NSMaxX(bounds)-1.0, 0, 1.0,
> NSHeight(bounds));
>break;
>case NSHorizontalRuler:
>borderLineRect = NSMakeRect(0, 0, NSWidth(bounds), 1.0);
>break;
>}
If orientation happens to have a value *other* than NSVerticalRuler or
NSHorizontalRuler, you’ll reach this point with borderLineRect containing
garbage since it’s never been filled in properly. This is what the analyser is
complaining of I believe.
>
>
>[3]if [4]([self needsToDrawRect:borderLineRect]) {
>[[backgroundColor shadowWithLevel:0.4] set];
>NSRectFill(borderLineRect);
>
> The error message says, in full: Passed-by-value struct argument contains
> uninitialized data (e.g., via the field chain: 'origin.x’).
>
>
> Thoughts much appreciated.
>
>
> Phil
>
> ___
>
> 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/mabdullah%40karelia.com
>
> This email sent to mabdul...@karelia.com
___
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
Re: help with logic error
> On 12 Dec 2013, at 18:56, Mike Abdullah wrote: > If orientation happens to have a value *other* than NSVerticalRuler or > NSHorizontalRuler, you’ll reach this point with borderLineRect containing > garbage since it’s never been filled in properly. This is what the analyser > is complaining of I believe. Thanks for that, Mike. Putting in a default cured the error. Best Phil ___ 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
Re: help with logic error
Probably you may need to add the Default case in Switch case block or else
initialize with Zero rect.
- Apparao
On 12/12/13 5:22 PM, "2551" <2551p...@gmail.com> wrote:
>Hi folks
>
>I need some help with a logic error the Static Analyzer is throwing up. I
>didn¹t write this code (in fact, its a piece of Apple sample code I¹m
>resuing in my project), and I¹m not quite sure how to correct it. It goes
>like this, where the numbers [1], [2], [3], [4] represent the end points
>of the analyzer's blue arrows:
>
> [1] const NSRect bounds = [self bounds];
>
>[backgroundColor set];
>NSRectFill(dirtyRect);
>
>const NSRulerOrientation orientation = [self orientation];
>NSRect borderLineRect;
>[2] switch (orientation) {
>case NSVerticalRuler:
>borderLineRect = NSMakeRect(NSMaxX(bounds)-1.0, 0, 1.0,
>NSHeight(bounds));
>break;
>case NSHorizontalRuler:
>borderLineRect = NSMakeRect(0, 0, NSWidth(bounds), 1.0);
>break;
>}
>
>[3]if [4]([self needsToDrawRect:borderLineRect]) {
>[[backgroundColor shadowWithLevel:0.4] set];
>NSRectFill(borderLineRect);
>
>The error message says, in full: Passed-by-value struct argument contains
>uninitialized data (e.g., via the field chain: 'origin.x¹).
>
>
>Thoughts much appreciated.
>
>
>Phil
>
>___
>
>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/apparaom%40ivycomptech.c
>om
>
>This email sent to appar...@ivycomptech.com
This email and any attachments are confidential, and may be legally privileged
and protected by copyright. If you are not the intended recipient dissemination
or copying of this email is prohibited. If you have received this in error,
please notify the sender by replying by email and then delete the email
completely from your system. Any views or opinions are solely those of the
sender. This communication is not intended to form a binding contract unless
expressly indicated to the contrary and properly authorised. Any actions taken
on the basis of this email are at the recipient's own risk.
___
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
Re: Threaded drawing - JPEG
On 12 Dec 2013, at 11:55, Uli Kusterer wrote: > On 11 Dec 2013, at 18:53, Steve Sisak wrote: >> At 10:25 AM -0800 12/10/13, Seth Willits wrote: >>> On Dec 10, 2013, at 1:32 AM, Graham Cox wrote: But my situation is that I need to draw VECTOR objects up to 25,000% zoom with no pixelization. >>> >>> You're given a CGContext to draw into; What's the difference? The tiled >>> drawing is async, so if the drawing doesn't occur fast enough it'll scale >>> up the low-scale bitmap, but what's evil about that? It's like Apple or >>> Google maps. >> >> Not to hijack the thread, but I'm just getting head into optimizing some >> code which displays live preview for a number of JPEG streams simultaneously. >> >> Most implementations I've tried result in being CPU bound in JPEG code on >> the main thread with the 7 other cores idle. >> >> I've tried variants of NSImageView, CGImage and CIImage and all that's >> needed to render them on alternate threads but Cocoa appears to so good at >> delaying evaluation as long as possible that it seems to end up calling the >> JPEG decoder synchronously from -drawRect of whatever view subclass I've >> chosen on the main thread. >> >> Any suggestions for what technologies to use to run a JPEG through, say >> CIImage w/o blocking the main thread. >> >> This has turned out to be way more complicated than I thought. > > > If you want previews, I think ImageIO has dedicated methods for generating > previews (MacOS definitely has some somewhere, even if I mis-remember them > being in ImageIO). Particularly in the case of JPEG these can be much more > efficient because of the way JPEGs are stored. Essentially, JPEGs often > contain a few small DCTs at the start that can give you a vague, blurry > version of the image, then draw more DCTs on top to add in the detail (I'm > criminally simplifying here). So the preview calls can actually just draw the > blurry version into a smaller destination and stop there, and don't have to > calculate or even load the rest of the image. Yes, ImageIO has highly optimised routines for generating thumbnails. (Which seems a slight misnomer seeing as you can use them to pull out some seriously large images). By default, ImageIO holds off decoding JPEGs etc. until actually needed. iOS devs have run up against this for years, where the decoding kicks in on the main thread at the first draw, and gets in the way. The standard solution most seem to have arrived at is to first — on a worker thread — draw a single pixel of the image into a 1x1 pixel bitmap context. This forces the decoding to kick in, and is now cached ready for drawing on the main thread. As of 10.9, ImageIO adds the option: kCGImageSourceShouldCacheImmediately. Sadly this hasn’t made its way through to the full docs yet, but it should solve the problem you have without the need to faff about with a bitmap context in the background. If you use the thumbnail routines instead, in my experience they perform the decoding upfront for you anyway, so there’s no need for the workaround there. ___ 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
Re: help with logic error
On 12 Dec 2013, at 12:52, 2551 <2551p...@gmail.com> wrote:
> Hi folks
>
> I need some help with a logic error the Static Analyzer is throwing up. I
> didn’t write this code (in fact, its a piece of Apple sample code I’m resuing
> in my project), and I’m not quite sure how to correct it. It goes like this,
> where the numbers [1], [2], [3], [4] represent the end points of the
> analyzer's blue arrows:
>
> [1] const NSRect bounds = [self bounds];
>
>[backgroundColor set];
>NSRectFill(dirtyRect);
>
>const NSRulerOrientation orientation = [self orientation];
>NSRect borderLineRect;
>[2] switch (orientation) {
>case NSVerticalRuler:
>borderLineRect = NSMakeRect(NSMaxX(bounds)-1.0, 0, 1.0,
> NSHeight(bounds));
>break;
>case NSHorizontalRuler:
>borderLineRect = NSMakeRect(0, 0, NSWidth(bounds), 1.0);
>break;
>}
>
>[3]if [4]([self needsToDrawRect:borderLineRect]) {
>[[backgroundColor shadowWithLevel:0.4] set];
>NSRectFill(borderLineRect);
>
> The error message says, in full: Passed-by-value struct argument contains
> uninitialized data (e.g., via the field chain: 'origin.x’).
NSRulerOrientation is typedefed as an NSUInteger. So I suppose the Static
Analyzer doesn't know that it can only be those two values. I suppose you could
fix the warning by either initializing borderLineRect = NSZeroRect; or by
adding a default: case to the switch that does this. I guess Apple hasn't yet
gotten around to turning NSRulerOrientation into one of those new-fangled
NS_ENUMs, and since the enum is anonymous, you can't declare your variable as
enum _NSRulerOrientation or the like either, to tell the Analyzer that there
are only two possible values for this variable.
Alternately, you could add an NSCAssert() that simply croaks if the
orientation is anything but these two values. Then the Analyzer will know there
can only be those two cases.
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
___
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
Re: Threaded drawing
OK, OK, point taken. I think I'll print that list (and Uli’s caveat) and hang it on the wall, right next to the space I use for banging my head when struggling with Cocoa… :p On 12 Dec 2013, at 18:46, Uli Kusterer wrote: > On 11 Dec 2013, at 16:01, Jens Alfke wrote: >> On Dec 11, 2013, at 4:39 AM, 2551 <2551p...@gmail.com> wrote: >>> It’s certainly seemed the case to me that I would have probably spent less >>> time just writing my own code from scratch than I spend trying to figure >>> out how half the methods I’m trying to use should be implemented. >> >> That’s probably not actually true; our experience of time is pretty >> subjective, and time goes by faster when you’re in a ‘flow’ state than when >> you’re trying to figure out something new. >> >> Even if it’s a bit faster to write your own code, using the system APIs is >> probably still a win because >> (a) their implementations are almost certainly better debugged and more >> performant than your brand-new unused code; >> (b) they will be improved and maintained by other people over time, saving >> you the trouble; >> (c) they’ve been designed to be reusable, so you’ll be able to use them >> quickly in your next project; >> (d) you can later hang out here explaining the APIs to noobs and make >> yourself look like a guru (or better yet, write books) ;-) > > > Let's preface that with the statement that I agree with your conclusion. > > Using Apple's code generally saves a lot of hassle and work because your code > has only you doing QA. Apple's code has all of Apple, plus you, plus everyone > else outside Apple who uses this API doing QA. It's bound to be more solid. > That said, Apple's code still has only whatever team at Apple is responsible > for that code fixing it. Only they have the source code. > > So occasionally, when a piece of code isn't or stops being a priority for > Apple, item (b) above can actually be a liability. Still, we've seen how > people circumvent that with sync code and CoreData. People first use Apple's > code, getting a leg up and a release out the door and money in their coffers, > and can then afford to fund their own version. > > -- Uli Kusterer > "The Witnesses of TeachText are everywhere..." > > > ___ 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
Neatly fitting a dash to a rect
Does anyone have code or at least an outline of how to adjust a dash so that it fits exactly to the corners of a rectangle? The dash itself is supplied, but may be minimally adjusted in both phase and length of any of its elements to fit, such that the rect corners lie exactly in the centre of a solid part of the dash. It only needs to work for rects. —Graham ___ 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
Re: Neatly fitting a dash to a rect
I assume you mean dash as in NSBezierPath's setLineDash:count:phase:. Also,
does the dash have just two elements (one segment and one gap), or is it more
complex.
Does it have to be the same exact pattern all the way around? If it's okay to
differ a teeny bit (I bet imperceptibly), you could solve the problem
separately for the horizontal edges and the vertical edges, and draw four lines
instead of one rect.
Offhand, here's what comes to mind, just solving for one edge and assuming the
pattern is simply { segmentLength, gapLength }.
In the final solution, how many iterations of the pattern will the line have?
If both ends are in the middle of a segment, the answer is the same as if one
end were at the beginning of a segment and the other at the end of a gap. In
other words, the line length will be an exact multiple of segment length.
How far off are we from that? Let's figure out how many iterations fit now,
and how much is left over. (Excuse my sloppy floating point coding.)
CGFloat iterationLength = segmentLength + gapLength;
CGFloat numIterations = floor(lineLength / iterationLength);
CGFloat leftOver = lineLength - (numIterations * iterationLength);
We want to spread the leftover amount evenly across all iterations, so let's
figure out how much to add to each iteration. We could split that fudge factor
equally between the segment and the gap, and I bet no one would notice, or to
be fussy we could distribute it proportionally:
CGFloat iterationFudge = leftOver / numIterations; // Assume numIterations > 0.
CGFloat segmentFudge = iterationFudge * (segmentLength / iterationLength);
CGFloat gapFudge = iterationFudge * (gapLength / iterationLength);
CGFloat myDashPattern[2] = { segmentLength + segmentFudge, gapLength + gapFudge
};
// Assume myBezierPath contains the line.
[myBezierPath setLineDash:myDashPattern
count:2
phase:(myDashPattern[0] / 2.0)];
You could probably tweak some things to minimize rounding issues, but I don't
know if that would make a noticeable difference.
--Andy
On Dec 12, 2013, at 7:54 AM, Graham Cox wrote:
> Does anyone have code or at least an outline of how to adjust a dash so that
> it fits exactly to the corners of a rectangle?
>
> The dash itself is supplied, but may be minimally adjusted in both phase and
> length of any of its elements to fit, such that the rect corners lie exactly
> in the centre of a solid part of the dash. It only needs to work for rects.
>
>
> —Graham
___
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
Re: Neatly fitting a dash to a rect
On Dec 12, 2013, at 10:06 AM, Andy Lee wrote: > Does it have to be the same exact pattern all the way around? If it's okay > to differ a teeny bit (I bet imperceptibly), you could solve the problem > separately for the horizontal edges and the vertical edges, and draw four > lines instead of one rect. Not sure if this might come out looking wrong depending on lineCap/lineJoin styles. If so, all I can think of is to figure out *two* sets of "fudge" amounts, for the horizontal and vertical edges, and maybe apply their average to the dash pattern. I don't know if the math would work out. This is already just about as much as my brain can handle at the moment. :) --Andy ___ 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
Re: Neatly fitting a dash to a rect
On Dec 12, 2013, at 10:06 AM, Andy Lee wrote: > In other words, the line length will be an exact multiple of segment length. Correction: exact multiple of (segmentLength + gapLength). --Andy ___ 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
Re: iPad keyboards
On Dec 12, 2013, at 3:38 AM, Rick Mann wrote: > I thought you had to use Xcode 5 to submit now, Xcode 5 can build with the 6 SDK. > and I thought it had to be linked against iOS 7. Dunno > I'm pretty sure Apple rejected one of my binaries because of that. > Might try to clarify for which reason it was rejected. They are orthogonal. > On Dec 12, 2013, at 01:34 , Kyle Sluder wrote: > >>> On Dec 11, 2013, at 9:49 PM, Rick Mann wrote: >> >>> >>> They released the latest version of their app Nov 19. They would've had to >>> build against the iOS 7 SDK. >> >> As far as I know, Apple is still accepting binaries linked against the iOS 6 >> SDK. >> >> --Kyle Sluder > > > -- > Rick > > > > ___ > > 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/lutherbaker%40gmail.com > > This email sent to lutherba...@gmail.com ___ 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
Re: iPad keyboards
On 12 Dec 2013, at 15:39, Luther Baker wrote: > > > On Dec 12, 2013, at 3:38 AM, Rick Mann wrote: > >> I thought you had to use Xcode 5 to submit now, > > Xcode 5 can build with the 6 SDK. Not without modifying the Xcode package, or other monkeying about with settings. Perhaps you’re thinking of the deployment target? ___ 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
Re: Neatly fitting a dash to a rect
On 12 Dec 2013, at 4:06 pm, Andy Lee wrote:
> I assume you mean dash as in NSBezierPath's setLineDash:count:phase:.
Yep, sorry if that wasn’t clear.
> Also, does the dash have just two elements (one segment and one gap), or is
> it more complex.
Well, it can be more complex, but it might not matter. The remainder of the
dash after the first ‘solid’ part can probably be considered as ‘gap’ for the
purposes of this. Most of the time it will be a simple dash.
> Does it have to be the same exact pattern all the way around? If it's okay
> to differ a teeny bit (I bet imperceptibly), you could solve the problem
> separately for the horizontal edges and the vertical edges, and draw four
> lines instead of one rect.
It doesn’t *have* to be the same as long as it doesn’t differ too much
visually, but detecting that a path is a simple rect (including rotated cases)
and breaking it into h and v lengths might turn out to be the hard part. I also
wonder if there’s a way to perform the calculation based on the highest common
factor (HCF) of the horizontal and vertical edges? That might allow the dash to
be tweaked as a single entity and applied in the usual way.
> Offhand, here's what comes to mind, just solving for one edge and assuming
> the pattern is simply { segmentLength, gapLength }.
I’ll experiment with this and see where it takes me, thanks :)
—Graham
___
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
Re: Neatly fitting a dash to a rect
On Dec 12, 2013, at 10:52 AM, Graham Cox wrote: >> Does it have to be the same exact pattern all the way around? If it's okay >> to differ a teeny bit (I bet imperceptibly), you could solve the problem >> separately for the horizontal edges and the vertical edges, and draw four >> lines instead of one rect. > > It doesn’t *have* to be the same as long as it doesn’t differ too much > visually, but detecting that a path is a simple rect (including rotated > cases) and breaking it into h and v lengths might turn out to be the hard > part. I also wonder if there’s a way to perform the calculation based on the > highest common factor (HCF) of the horizontal and vertical edges? That might > allow the dash to be tweaked as a single entity and applied in the usual way. Interesting. You could straighten out the angles of the rect and think of (say) the top and right edges as a single line: o---+---+---+---+---o---+---+---o Each of o's is a corner, and each of the +'s marks off a multiple of the HCF. So what you want is for the dash to be tweaked in such a way that all three o's are in the middle of some segment. Sounds fun -- good luck! --Andy ___ 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
Re: iPad keyboards
We have been submitting and getting approved apps built with Xcode 4.x and iOS 6 SDK without issue still. Apple knows the iOS 7 jump is fairly large for some apps so hasn't yet been forceful but I expect to happen at some point. On Thu, Dec 12, 2013 at 1:38 AM, Rick Mann wrote: > I thought you had to use Xcode 5 to submit now, and I thought it had to be > linked against iOS 7. I'm pretty sure Apple rejected one of my binaries > because of that. > > On Dec 12, 2013, at 01:34 , Kyle Sluder wrote: > > >> On Dec 11, 2013, at 9:49 PM, Rick Mann wrote: > > > >> > >> They released the latest version of their app Nov 19. They would've had > to build against the iOS 7 SDK. > > > > As far as I know, Apple is still accepting binaries linked against the > iOS 6 SDK. > > > > --Kyle Sluder > > > -- > Rick > > > > > ___ > > 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/shawnce%40gmail.com > > This email sent to shaw...@gmail.com > ___ 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
Re: iPad keyboards
On Dec 12, 2013, at 11:58 , Shawn Erickson wrote: > We have been submitting and getting approved apps built with Xcode 4.x and > iOS 6 SDK without issue still. Apple knows the iOS 7 jump is fairly large > for some apps so hasn't yet been forceful but I expect to happen at some > point. That's good to know; I thought they were requiring iOS 7. Even so, does an iOS 6 SDK-based app not get all iOS 7 styling? I'd try the experiment myself, but it's a bit of work to install Xc 4.6.3. -- Rick signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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
Re: iPad keyboards
On Dec 12, 2013, at 1:08 PM, Rick Mann wrote: > > On Dec 12, 2013, at 11:58 , Shawn Erickson wrote: > >> We have been submitting and getting approved apps built with Xcode 4.x and >> iOS 6 SDK without issue still. Apple knows the iOS 7 jump is fairly large >> for some apps so hasn't yet been forceful but I expect to happen at some >> point. > > That's good to know; I thought they were requiring iOS 7. > > Even so, does an iOS 6 SDK-based app not get all iOS 7 styling? I'd try the > experiment myself, but it's a bit of work to install Xc 4.6.3. Generally an application built against the iOS 6 SDK will get a compatible styling (its not exactly iOS 6, and its certainly not iOS 7, but its somewhere in between while still looking like an iOS 6 app). -- David Duncan ___ 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
Re: iPad keyboards
Your app is tagged with the SDK you link against. When running on a later version of the OS then the SDK the app is built with the OS may (and often does) run the application in a compatibility mode in an attempt to avoid causing problems for the app. On Thu, Dec 12, 2013 at 1:08 PM, Rick Mann wrote: > > On Dec 12, 2013, at 11:58 , Shawn Erickson wrote: > > > We have been submitting and getting approved apps built with Xcode 4.x > and > > iOS 6 SDK without issue still. Apple knows the iOS 7 jump is fairly large > > for some apps so hasn't yet been forceful but I expect to happen at some > > point. > > That's good to know; I thought they were requiring iOS 7. > > Even so, does an iOS 6 SDK-based app not get all iOS 7 styling? I'd try > the experiment myself, but it's a bit of work to install Xc 4.6.3. > > > -- > Rick > > > > ___ 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
