Re: NSButton state not persisting
On 10 Dec 2013, at 22:26, Jens Alfke j...@mooseyard.com wrote: On Dec 10, 2013, at 1:07 PM, Pax 45rpmli...@googlemail.com wrote: Ah! Exactly right. It is nil - but surely I shouldn't have to initialise it? I never have in the past - I built the UI with IB, and I was under the impression that that would handle all the initialisation for me. The code must be running before the nib’s been loaded. Set a breakpoint and look at the backtrace for clues. You mentioned awakeFromNib being called twice — the situation I’ve seen this happen is when an object is _contained_ in one nib, and also the _owner_ of another (that it loads). For instance if your app delegate has a method that loads a nib with itself as the owner, then -awakeFromNib will be called once when the app initializes and MainMenu.nib is loaded, and then again when you load your own nib. Different outlets are going to be hooked up at those times. Another popular mistake is to have 2 objects instead of one. E.g. if you have an NSWindowController subclass that gets created by your app delegate, and in this NSWindowController’s XIB you have dragged out a second instance of the same subclass, and instead of hooking up the outlets of the File’s Owner, you’ve hooked them up to the second object. Then the File’s Owner gets created, loads its XIB, which creates the second subclass, which gets hooked up to the window. Then one of the two objects has all the UI objects, the other is the one you set properties on and so on. So have you checked whether ‘self’ is actually the same in both calls? A variant of this issue can happen with objects whose superclass implements NSCopying, but you forgot to implement -copyWithZone: in your subclass. Then sometimes you seem to get parts of your object initialized twice, when in fact you’re seeing a copy of your object being talked to. Mind you, NSPreferencePane doesn’t implement NSCopying, so I doubt this is the case here, at least not directly. Cheers, -- Uli Kusterer “The Witnesses of TeachText are everywhere...” http://zathras.de ___ 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: Preferences caching?
On 10 Dec 2013, at 18:08, Kyle Sluder k...@ksluder.com wrote: On Dec 10, 2013, at 7:46 AM, Jakob Egger ja...@eggerapps.at wrote: Or does OS X Mavericks recreate deleted preference files in some cases? Bingo. You are now caught up with the original post in this thread. The plist files are and always have been an implementation detail. The only supported interface to preferences has always been through CFPreferences/NSUserDefaults, whether via code or the defaults command line tool. To add a little bit of detail, the preferences are handled by a daemon, which seems to read in the prefs file at startup, and then only looks at its cached copy in RAM until it gets terminated, at which point they get written back to the file. Every app that wants to read preferences (indirectly, via CFPrefs or NSUD, including the ‘defaults’ command line tool) calls this daemon to get the values in RAM. Once that daemon has loaded the preferences into RAM, you can do whatever you want to a prefs file, it gets ignored. Also, reading that prefs file directly instead of through API that talks to the daemon may give outdated results. When you delete the prefs file, it’s usually *before* the system has shut down the CFPrefs daemon, so what will happen after the deletion is that the daemon will write its changed settings back out, re-creating the plist file. Graham Cox wrote: Great. For me. For users in the field, the command line is the badlands, and we can’t expect many users to be comfortable doing that. Trashing a file is at least something they can understand, even if sometimes even that can be an ordeal getting them to the ~/Library/Preferences folder, now it’s hidden by default. Really, Apple are supposed to be the champions of the average user aren’t they? Have they talked to any recently? Honestly, it would serve everyone well if every developer served a month in a call centre. I guess we’re going to have to put a button somewhere that’s going to do this for them. Sigh. As others have said, deleting prefs shouldn’t be so common that you need to have a button in your UI for it. If it is, your app has some sort of problem. That said, we actually created a ‘supporter’ application to help our customers do things like that, including save and send off all settings files to our support, reset the application to a pristine installation, restore saved settings files, save system profile information etc. (given we include hardware, some of which does network communications, and are the market leader in our segment, it was worth the effort to spend time on a ‘push one button’ solution for this edge case). In your case, I could see you sending them a shell script with a .command extension that does a defaults delete call to nuke your prefs domain. They can simply double-click that, and you can have it do a ‘clear’ and then display a friendly message like “GrahamApp Preferences reset to factory defaults”. Cheers, -- Uli Kusterer “The Witnesses of TeachText are everywhere...” http://zathras.de ___ 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: NSURLSessionUploadTask - stops uploading after sending 160kB of data (5x 32kB chunks)
Staring at the code for a long time. Typo in one letter and found it just one minute after I did send the question, as always. Works like a charm. My apologize for the noise. Sent from my iPhone On 10. 12. 2013, at 20:38, Jens Alfke j...@mooseyard.com wrote: On Dec 10, 2013, at 11:16 AM, Robert Vojta rob...@tapmates.com wrote: When I’m testing it, it starts upload almost immediately, I see it in logs and then it suddenly stops after 160kB of data sent and is stalled ... Is it possible this is a server-side issue? What exactly are you uploading it to? Have you looked at the server logs? (Also, FYI, networking issues generally get better attention on the macnetworkprog mailing list, where Quinn hangs out.) —Jens ___ 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 10 Dec 2013, at 7:39 pm, Kyle Sluder k...@ksluder.com wrote: but more directly, by using CATiledLayer you don't have to handle the tiling and threading yourself, and it avoids the final blit of your buffer into the view because you're (presumably) drawing directly into the layer backing. Yup, these two points are exactly why I suggested it. Well, looks like we have a winner :) Thanks to all that suggested CATiledLayer, I guess I shouldn’t be surprised, but it does actually work, and as well as performing excellently is very easy to set up as well. Seems to do the job without any kinks in the road - just set it as the view’s layer and away it goes. The documentation is sparse though, I’m not quite sure what I should be using for -levelsOfDetail and -levelsOfDetailBias. It’s clear I do need to set these to something other than their defaults to get the behaviour I need, which is not to pixelize my vector drawing as I zoom in. The defaults do show pixelization. My understanding is that -levelsOfDetail pertains to zooming OUT, and how many images get cached. So I have a fairly small number here, as zooming out isn’t a huge deal. -levelsOfDetailBias*, on the other hand, appears to pertain to zooming IN, and at what point the content is redrawn at a higher resolution. Since I need to attain up to 250x zoom, I’ve set this to 8, as each level is double the res of the last one, and 2^8 is 256. That’s my somewhat limited understanding, not particularly well-informed by the docs, but appears to work by experimentation. If anyone knows more than this, I’d love to know if I’m off-track. *who comes up with these names? Are they self-describing? Performance wise, It’s very hard to come up with a number as to whether this is showing any benefit in my test case (which isn’t very ‘heavy’ on drawing). Instruments shows a very different profile, with no one stack really dominating, which I suppose is good. The CPU Usage graph also shows considerably less overall work being done with no peaks hitting the max level. But the overall milliseconds appears to be very slightly more than straight drawing in the test case. *Shrugs*, I guess I have to throw it at my ‘heavy’ drawing and just see if it is noticeably better. —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: Threaded drawing
On Dec 11, 2013, at 4:20 AM, Graham Cox wrote: The documentation is sparse though, I’m not quite sure what I should be using for -levelsOfDetail and -levelsOfDetailBias. It’s clear I do need to set these to something other than their defaults to get the behaviour I need, which is not to pixelize my vector drawing as I zoom in. The defaults do show pixelization. By searching the docs for levelsOfDetailBias, I found Apple's CALayerEssentials sample code. A section of the AppController.m sets these properties and has a comment which explains them fairly well: // To provide multiple levels of content, you need to set the levelsOfDetail property. // For this sample, we have 5 levels of detail (1/4x - 4x). // By setting the value to 5, we establish that we have levels of 1/16x - 1x (2^-4 - 2^0) // we use the levelsOfDetailBias property we shift this up by 2 raised to the power // of the bias, changing the range to 1/4-4x (2^-2 - 2^2). exampleCATiledLayer.levelsOfDetail = 5; exampleCATiledLayer.levelsOfDetailBias = 2; Why such a clear explanation isn't in the class reference, I couldn't tell you. Regards, Ken ___ 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 17:20, Graham Cox graham@bigpond.com wrote: The documentation is sparse though SNIP...That’s my somewhat limited understanding, not particularly well-informed by the docs, but appears to work by experimentation. The commonality of this experience makes me wonder almost with everything I try to do in Cocoa whether it really IS true as advertised that the pre-written APIs make it easier than writing your own raw code all the way down in C and Obj-C or whether the whole Cocoa edifice has turned into such a monster that for anyone except the seasoned expert, quite the reverse is true. 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. Of course, I always give in to Cocoa on the grounds that I figure I must be being stupid and missing the obvious and/or it’s inevitable that I’ll have to learn how to do it ‘the Cocoa way’ in the end. Still, you can’t help wondering… ;) ___ 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 1:39 pm, 2551 2551p...@gmail.com wrote: The commonality of this experience makes me wonder almost with everything I try to do in Cocoa whether it really IS true as advertised that the pre-written APIs make it easier than writing your own raw code all the way down in C and Obj-C or whether the whole Cocoa edifice has turned into such a monster that for anyone except the seasoned expert, quite the reverse is true. Actually I think my experiences illustrated in this thread show the opposite. I started by attempting to write my own code (still in Obj-C) and it got moderately complicated before I gave up without showing any performance benefit (in fact the opposite). Using CATiledLayer, as badly documented as it is, was about 5 lines of code and actually worked in doing what I had been attempting to do all along. The problem for me was one of even realising that the class was a good fit for my situation. On the whole, using Cocoa is a huge benefit. Of course it’ll have some bugs, bad documentation, etc - in other words the same problems all projects have. The difference I suppose is that it has many knowledgable engineers working on it, it is extremely well-funded (in theory) and is more thoroughly debugged than pretty much anything you could write on your own of its size and scope. We do complain sometimes, and frustration isn’t uncommon, but let’s keep things in perspective. File radars, maybe we’ll get better documentation. —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: Threaded drawing
On 11 Dec 2013, at 12:40 pm, Ken Thomases k...@codeweavers.com wrote: By searching the docs for levelsOfDetailBias, I found Apple's CALayerEssentials sample code. A section of the AppController.m sets these properties and has a comment which explains them fairly well: Ah, thanks! That makes more sense and explains the method names better as well. Why such a clear explanation isn't in the class reference, I couldn't tell you. Indeed ;-) —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
Custom view and NSText
Hi, I have an view that acts as an text view by implementing the NSTextInputClient protocol. This works fine in 10.8 but leads to crashes in 10.9. The report says: Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'All NSText methods must be implemented by subclassers. They should not call super.' It seems to be related to the new input methods in 10.9. Like if you hold a key it will show a small popover that gives you some variants of that character (like accented characters) similar to the iOD keyboard. I tried to find any documentation about this... The problem goes away if I link to the 10.9 SDK but I can't do that as I still support 10.6 and need to build on a 10.7 machine. So can anyone point me in the right direction on how to implement the popovers? below is a backtrace. Thanks Georg Last Exception Backtrace: 0 CoreFoundation 0x7fff89467404 ___exceptionPreprocess + 148 1 libobjc.A.dylib 0x7fff921a0e75 _objc_exception_throw + 43 2 CoreFoundation 0x7fff894672cc +[NSException raise:format:] + 204 3 AppKit 0x7fff8c41c1ff -[NSText string] + 43 4 AppKit 0x7fff8bfb786c -[NSTextInputContext handleTSMEvent:] + 3555 5 AppKit 0x7fff8bfb6a65 __NSTSMEventHandler + 205 6 HIToolbox 0x7fff8cf5f6d4 __ZL23DispatchEventToHandlersP14EventTargetRecP14OpaqueEventRefP14HandlerCallRec + 892 7 HIToolbox 0x7fff8cf5ec87 __ZL30SendEventToEventTargetInternalP14OpaqueEventRefP20OpaqueEventTargetRefP14HandlerCallRec + 385 8 HIToolbox 0x7fff8cf72d90 _SendEventToEventTarget + 40 9 HIToolbox 0x7fff8cfb40ed _SendTSMEvent + 33 10 HIToolbox 0x7fff8d16171f _SendTextInputEvent + 1028 11 HIToolbox 0x7fff8d1ac8ec -[IMKInputSession _copyUniCharsForRange:intoBuffer:ofLength:] + 268 12 HIToolbox 0x7fff8d1ac9bb -[IMKInputSession _coreAttributesFromRange:whichAttributes:actualRange:] + 137 13 HIToolbox 0x7fff8d1adaac -[IMKInputSession attributedSubstringFromRange:] + 89 14 CoreFoundation 0x7fff89352dec ___invoking___ + 140 15 CoreFoundation 0x7fff89352c54 -[NSInvocation invoke] + 308 16 CoreFoundation 0x7fff893f57a6 -[NSInvocation invokeWithTarget:] + 54 17 CoreFoundation 0x7fff893c5384 forwarding___ + 452 18 CoreFoundation 0x7fff893c5138 __CF_forwarding_prep_0 + 120 19 CoreFoundation 0x7fff89352dec ___invoking___ + 140 20 CoreFoundation 0x7fff89352c54 -[NSInvocation invoke] + 308 21 Foundation 0x7fff90130c67 -[NSConnection dispatchInvocation:] + 135 22 Foundation 0x7fff9013092d -[NSConnection handleRequest:sequence:] + 1434 23 Foundation 0x7fff900d7cf0 -[NSConnection handlePortCoder:] + 652 24 Foundation 0x7fff900d7628 -[NSConnection dispatchWithComponents:] + 50 25 Foundation 0x7fff900bbed8 ___NSFireMachPort + 257 26 CoreFoundation 0x7fff89398d04 ___CFMachPortPerform + 388 27 CoreFoundation 0x7fff89398b69 ___CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 41 28 CoreFoundation 0x7fff89398ade ___CFRunLoopDoSource1 + 478 29 CoreFoundation 0x7fff89389bd6 ___CFRunLoopRun + 1830 30 CoreFoundation 0x7fff89389275 _CFRunLoopRunSpecific + 309 31 Foundation 0x7fff900d400e -[NSConnection sendInvocation:internal:] + 1965 32 CoreFoundation 0x7fff893c5384 forwarding___ + 452 33 CoreFoundation 0x7fff893c5138 __CF_forwarding_prep_0 + 120 34 HIToolbox 0x7fff8d1a8b8d -[IMKInputSession handleEvent:] + 946 35 HIToolbox 0x7fff8d16c2e8 _IMKInputSessionProcessEventRef + 45 36 HIToolbox 0x7fff8d16b8aa _InputMethodInstanceProcessEventRef + 100 37 HIToolbox 0x7fff8d160e6f _TSMEventToInputMethod + 131 38 HIToolbox 0x7fff8cfa0452 _TSMProcessRawKeyEvent + 3034 39 AppKit 0x7fff8bfb62b0 -[NSTextInputContext handleEvent:] + 731 40 AppKit 0x7fff8bf95b5d -[NSView interpretKeyEvents:] + 180 ... ... ... ___ 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
Re: Threaded drawing
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) ;-) —Jens ___ 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 2013 Dec 11, at 10:01, Jens Alfke wrote: On 2013 Dec 11, at 04:39, 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... When a software developer is figuring out something new is exactly when he is in a flow state. Flow state requires a challenge which can be met. In this case, at some level, we're weighing trying to figure out from the cryptic docs and experiments how the frame-work works*, vs. building something that works as you think of it and as you want it to work from simpler components. Sometimes the frame-works are easier/better, and sometimes designing and developing your own is better. * (The posted snippet from sample code was as clear as mud to me. Why powers of 4 (and -4) instead of 5 when we're talking about 5 levels of detail? 1/(2^2) - 2^2 = (1/4) - 4 means ...levelsOfDetail should be set to 5?!? It needs more words, more context.) Leave comments on the docs, file radars, maybe we’ll get better documentation... some day. dum spiro spero ___ 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
Strange Static Analyzer Warning
(I have been trying to send this to xcode-users, but for some reason it won't
go through, although it is not entirely off-topic for this list)
In this method:
- (void) drawBezelWithFrame:(NSRect)frame inView:(NSView *)controlView {
if (self.state == NSOnState) {
// If selected we need to draw the border new background for selection
(otherwise we will use default back color)
// Save current context
[[NSGraphicsContext currentContext] saveGraphicsState];
// Draw light vertical gradient
139 [kDMTabBarItemGradient drawInRect:frame angle:-90.0f];
// Draw shadow on the left border of the item
142 NSShadow *shadow = [[NSShadow alloc] init];
shadow.shadowOffset = NSMakeSize(1.0f, 0.0f);
shadow.shadowBlurRadius = 2.0f;
shadow.shadowColor = [NSColor darkGrayColor];
[shadow set];
[[NSColor blackColor] set];
CGFloat radius = 50.0;
NSPoint center = NSMakePoint(NSMinX(frame) - radius, NSMidY(frame));
NSBezierPath *path = [NSBezierPath bezierPath];
[path moveToPoint:center];
[path appendBezierPathWithArcWithCenter:center radius:radius
startAngle:-90.0f endAngle:90.0f];
[path closePath];
[path fill];
// shadow of the right border
shadow.shadowOffset = NSMakeSize(-1.0f, 0.0f);
[shadow set];
center = NSMakePoint(NSMaxX(frame) + radius, NSMidY(frame));
path = [NSBezierPath bezierPath];
[path moveToPoint:center];
[path appendBezierPathWithArcWithCenter:center radius:radius
startAngle:90.0f endAngle:270.0f];
[path closePath];
[path fill];
[shadow release];
// Restore context
[[NSGraphicsContext currentContext] restoreGraphicsState];
}
}
I am getting a warning that I wasn't getting before, in Xcode 4.3.3 LLVM 3.1:
Potential leak of an object allocated on line 139, with two sub-warnings: 1)
Method returns an Objective-C object with a +1 retain count (highlights
kDMTabBarItemGradient), 2) Object leaked: allocated object is not referenced
later in this execution path and has a retain count of +1 (highlights
NSShadow *shadow on line 142.
In Xcode 5, I was able to get rid of the warning by inserting the explicit
release of shadow (before it was autoreleased), but I can't seem to get Xcode
4.3 to do so. I tried relocating the shadow alloc/init before the save graphics
state, and the release after the restore, but that didn't work. In all cases it
trips on the gradient method call, which is odd, but it doesn't make any sense
to me in any case...
TIA,
Keary Suska
Esoteritech, Inc.
Demystifying technology for your home or business
Keary Suska
Esoteritech, Inc.
Demystifying technology for your home or business
___
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
Cocoaheads 92630 will be meeting today, Wed, Dec 11 at 7pm
CocoaHeads Lake Forest will be meeting on the second Wednesday of the month. We will be meeting at the Orange County Public Library (El Toro) community room, 24672 Raymond Way, Lake Forest, CA 92630. Peter Hosey will be discussing bugs he has found and fixed in his own apps, with an open mic to talk about bugs you have found in your own. We will be making some directional changes in the new year to better focus the group on topics of interest to the Cocoa and Cocoa Touch developers in the local community, so please bring topic suggestions. Please join us from 7pm to 9pm on Wednesday Bring laptops, code, discussion topics, etc. As always, details can be found on the cocoaheads web site at www.cocoaheads.org (note: cross-post cleared with moderators previously.) ___ 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 13:10, Graham Cox graham@bigpond.com wrote: On 11 Dec 2013, at 1:39 pm, 2551 2551p...@gmail.com wrote: The commonality of this experience makes me wonder almost with everything I try to do in Cocoa whether it really IS true as advertised that the pre-written APIs make it easier than writing your own raw code all the way down in C and Obj-C or whether the whole Cocoa edifice has turned into such a monster that for anyone except the seasoned expert, quite the reverse is true. Actually I think my experiences illustrated in this thread show the opposite. I started by attempting to write my own code (still in Obj-C) and it got moderately complicated before I gave up without showing any performance benefit (in fact the opposite). Using CATiledLayer, as badly documented as it is, was about 5 lines of code and actually worked in doing what I had been attempting to do all along. The problem for me was one of even realising that the class was a good fit for my situation. On the whole, using Cocoa is a huge benefit. Of course it’ll have some bugs, bad documentation, etc - in other words the same problems all projects have. The difference I suppose is that it has many knowledgable engineers working on it, it is extremely well-funded (in theory) and is more thoroughly debugged than pretty much anything you could write on your own of its size and scope. We do complain sometimes, and frustration isn’t uncommon, but let’s keep things in perspective. File radars, maybe we’ll get better documentation. Even better, use the “Provide Feedback” links in the documentation. They’re quicker to fill out, and preferred by Apple’s engineers as give them more context as to what you’re complaining about. ___ 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: Strange Static Analyzer Warning
On Dec 11, 2013, at 10:25 AM, Keary Suska wrote:
In this method:
- (void) drawBezelWithFrame:(NSRect)frame inView:(NSView *)controlView {
if (self.state == NSOnState) {
// If selected we need to draw the border new background for selection
(otherwise we will use default back color)
// Save current context
[[NSGraphicsContext currentContext] saveGraphicsState];
// Draw light vertical gradient
139 [kDMTabBarItemGradient drawInRect:frame angle:-90.0f];
Method returns an Objective-C object with a +1 retain count (highlights
kDMTabBarItemGradient)
Googling for kDMTabBarItemGradient finds this:
https://github.com/hetima/SafariStand/blob/master/DMTabBar/DMTabBarItem.m#L16
where that is a preprocessor macro defined as:
#define kDMTabBarItemGradient [[NSGradient alloc]
initWithColors: [NSArray arrayWithObjects: \
kDMTabBarItemGradientColor1, \
kDMTabBarItemGradientColor2, \
kDMTabBarItemGradientColor1, nil] \
atLocations: kDMTabBarItemGradientColor_Locations \
colorSpace: [NSColorSpace genericGrayColorSpace]]
That's horrible. I'd avoid using this code. An identifier prefixed with k
is usually a constant. Certainly, it shouldn't be an expression with side
effects!
Anyway, right there is the allocated object that you're leaking.
// Draw shadow on the left border of the item
142 NSShadow *shadow = [[NSShadow alloc] init];
Object leaked: allocated object is not referenced later in this execution
path and has a retain count of +1 (highlights NSShadow *shadow
Do you have another shadow variable involved? Perhaps an instance variable
(although I would think the local would hide it)?
Could there be another horrible preprocessor macro that's making the shadow
identifier into something strange?
What happens if you change all instances of shadow in this method to
localShadow or something like that?
shadow.shadowOffset = NSMakeSize(1.0f, 0.0f);
shadow.shadowBlurRadius = 2.0f;
shadow.shadowColor = [NSColor darkGrayColor];
[shadow set];
[[NSColor blackColor] set];
CGFloat radius = 50.0;
NSPoint center = NSMakePoint(NSMinX(frame) - radius, NSMidY(frame));
NSBezierPath *path = [NSBezierPath bezierPath];
[path moveToPoint:center];
[path appendBezierPathWithArcWithCenter:center radius:radius
startAngle:-90.0f endAngle:90.0f];
[path closePath];
[path fill];
// shadow of the right border
shadow.shadowOffset = NSMakeSize(-1.0f, 0.0f);
[shadow set];
center = NSMakePoint(NSMaxX(frame) + radius, NSMidY(frame));
path = [NSBezierPath bezierPath];
[path moveToPoint:center];
[path appendBezierPathWithArcWithCenter:center radius:radius
startAngle:90.0f endAngle:270.0f];
[path closePath];
[path fill];
[shadow release];
// Restore context
[[NSGraphicsContext currentContext] restoreGraphicsState];
}
}
Regards,
Ken
___
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: Strange Static Analyzer Warning
On Dec 11, 2013, at 10:25:42, Keary Suska cocoa-...@esoteritech.com wrote: I am getting a warning that I wasn't getting before, in Xcode 4.3.3 LLVM 3.1: Potential leak of an object allocated on line 139, with two sub-warnings: 1) Method returns an Objective-C object with a +1 retain count (highlights kDMTabBarItemGradient), 2) Object leaked: allocated object is not referenced later in this execution path and has a retain count of +1 (highlights NSShadow *shadow on line 142. In Xcode 5, I was able to get rid of the warning by inserting the explicit release of shadow (before it was autoreleased), but I can't seem to get Xcode 4.3 to do so. I tried relocating the shadow alloc/init before the save graphics state, and the release after the restore, but that didn't work. In all cases it trips on the gradient method call, which is odd, but it doesn't make any sense to me in any case... I was able to compile everything but the kDMTabBarItemGradient line, so maybe it's doing something that causes a leak. You didn't provide that code. The rest of the code (well, everything inside the if() anyway) analyzes with no problems reported in Xcode 5. -- Steve Mills office: 952-818-3871 home: 952-401-6255 ___ 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
At 10:25 AM -0800 12/10/13, Seth Willits wrote: On Dec 10, 2013, at 1:32 AM, Graham Cox graham@bigpond.com 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. Thanks, -Steve ___ 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: Strange Static Analyzer Warning
On Dec 11, 2013, at 9:48 AM, Ken Thomases wrote:
On Dec 11, 2013, at 10:25 AM, Keary Suska wrote:
In this method:
- (void) drawBezelWithFrame:(NSRect)frame inView:(NSView *)controlView {
if (self.state == NSOnState) {
// If selected we need to draw the border new background for selection
(otherwise we will use default back color)
// Save current context
[[NSGraphicsContext currentContext] saveGraphicsState];
// Draw light vertical gradient
139 [kDMTabBarItemGradient drawInRect:frame angle:-90.0f];
Method returns an Objective-C object with a +1 retain count (highlights
kDMTabBarItemGradient)
Googling for kDMTabBarItemGradient finds this:
https://github.com/hetima/SafariStand/blob/master/DMTabBar/DMTabBarItem.m#L16
where that is a preprocessor macro defined as:
#define kDMTabBarItemGradient [[NSGradient
alloc] initWithColors: [NSArray arrayWithObjects: \
kDMTabBarItemGradientColor1, \
kDMTabBarItemGradientColor2, \
kDMTabBarItemGradientColor1, nil] \
atLocations: kDMTabBarItemGradientColor_Locations \
colorSpace: [NSColorSpace genericGrayColorSpace]]
That's horrible. I'd avoid using this code. An identifier prefixed with k
is usually a constant. Certainly, it shouldn't be an expression with side
effects!
Anyway, right there is the allocated object that you're leaking.
Thanks, yep, that was it. Adding autorelease to the define avoids the error. It
just never dawned on me that that identifier would be a macro. That particular
method is the only place it is used! I know the code isn't very good but it
does what I need and I have fixed most of the bugs. If you know of a better lib
that will imitate an Xcode-like inspector tab bar I would happily look into it.
Thanks,
Keary Suska
Esoteritech, Inc.
Demystifying technology for your home or business
___
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 Dec 11, 2013, at 9:53 AM, Steve Sisak sgs-li...@codewell.com wrote: 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. Simple attempt: when you get the JPEG, create a CGBitmapContext on a background thread and draw the JPEG into it. Then use the CGBitmapContext to draw on the main thread. -- 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Threaded drawing
On Dec 11, 2013, at 8:05 AM, Jeffrey Oleander jgo...@yahoo.com wrote: * (The posted snippet from sample code was as clear as mud to me. Why powers of 4 (and -4) instead of 5 when we're talking about 5 levels of detail? 1/(2^2) - 2^2 = (1/4) - 4 means ...levelsOfDetail should be set to 5?!? It needs more words, more context.) The base level of detail is a zoom level of 2^0 (1 level of detail only allows for a single representation like that). Each additional level of detail is a zoom level half that size smaller (thus a 2nd level if 2^-1x or 1/2x, then 2^-2x or 1/4x, etc). The bias adds to the base level’s exponent, thus a bias of 2 means the base level if 2^2x (4x) zoom instead of 2^0x zoom. There are no powers of 4, (or 5 or any other except for 2). The level of detail is range of the exponent, not the base. -- 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: Threaded drawing - JPEG
On 11 Dec 2013, at 22:43, Greg Parker gpar...@apple.com wrote: On Dec 11, 2013, at 9:53 AM, Steve Sisak sgs-li...@codewell.com wrote: 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. Simple attempt: when you get the JPEG, create a CGBitmapContext on a background thread and draw the JPEG into it. Then use the CGBitmapContext to draw on the main thread. I think I must have missed something, because when drawing from the context created using CGBitmapContext don't you have to create a CGImage from the bitmap first and then draw that. Plus didn't part of the previous discussion in this thread suggest that you can't get the details of the window context that you'll be drawing into so that the image will have to be drawn again rather than just a bunch of memory copies. See Graham Cox's e-mail 9 December at 19:02 (GMT). So that's a jpeg decompress and draw, the CGImage creation, and then a draw into a context that you don't know what it is. I haven't profiled this but it doesn't seem efficient though the main thread might be a little more responsive. Kevin ___ 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
Is there any way to zoom in just one dimension? On Dec 11, 2013, at 6:05 PM, David Duncan david.dun...@apple.com wrote: On Dec 11, 2013, at 8:05 AM, Jeffrey Oleander jgo...@yahoo.com wrote: * (The posted snippet from sample code was as clear as mud to me. Why powers of 4 (and -4) instead of 5 when we're talking about 5 levels of detail? 1/(2^2) - 2^2 = (1/4) - 4 means ...levelsOfDetail should be set to 5?!? It needs more words, more context.) The base level of detail is a zoom level of 2^0 (1 level of detail only allows for a single representation like that). Each additional level of detail is a zoom level half that size smaller (thus a 2nd level if 2^-1x or 1/2x, then 2^-2x or 1/4x, etc). The bias adds to the base level’s exponent, thus a bias of 2 means the base level if 2^2x (4x) zoom instead of 2^0x zoom. There are no powers of 4, (or 5 or any other except for 2). The level of detail is range of the exponent, not the base. -- 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/dave.fernandes%40utoronto.ca This email sent to dave.fernan...@utoronto.ca ___ 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 Dec 11, 2013, at 4:17 PM, Dave Fernandes dave.fernan...@utoronto.ca wrote: Is there any way to zoom in just one dimension? Not really. You could put a counter transform before drawing that eliminates the opposite direction (and the aforementioned sample should show how to find out the current zoom level) but thats not really a satisfying solution... On Dec 11, 2013, at 6:05 PM, David Duncan david.dun...@apple.com wrote: On Dec 11, 2013, at 8:05 AM, Jeffrey Oleander jgo...@yahoo.com wrote: * (The posted snippet from sample code was as clear as mud to me. Why powers of 4 (and -4) instead of 5 when we're talking about 5 levels of detail? 1/(2^2) - 2^2 = (1/4) - 4 means ...levelsOfDetail should be set to 5?!? It needs more words, more context.) The base level of detail is a zoom level of 2^0 (1 level of detail only allows for a single representation like that). Each additional level of detail is a zoom level half that size smaller (thus a 2nd level if 2^-1x or 1/2x, then 2^-2x or 1/4x, etc). The bias adds to the base level’s exponent, thus a bias of 2 means the base level if 2^2x (4x) zoom instead of 2^0x zoom. There are no powers of 4, (or 5 or any other except for 2). The level of detail is range of the exponent, not the base. -- 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/dave.fernandes%40utoronto.ca This email sent to dave.fernan...@utoronto.ca -- 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
Autolayout Freespace
Is there a way autolayout can be told to proportionally divide available free space amongst a set of views? For example (please ignore the actual 'VFL' and consider the following horizontal layout string as pseudo code): H:|-[FirstName]-[LastName]-[SocialSecurity]-[Birthday]-[Age]-| Assume that each control hugs its own content tightly and that in the simple case, the initial display ends up requiring only 50% of the available parent view width. Can I set up the constraints so that the remaining space is divided up according to some user-defined relative weighting mechanism? IE: I want the FirstName and LastName textfields to grow - receiving 20% each of the remaining space with the Birthday button then getting the final extra 10%? Using resistance and hugging properties, I know how to make 1 control receive all the extra space ... but I don't know how to balance free space across several controls. ___ 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
iPad keyboards
Why does the Google Hangouts app on iPad, on iOS 7, have a nice-looking iOS-6 style keyboard? Other UI in the app looks like iOS 7 UI. Hangouts: http://cl.ly/image/1U2T1e1y1G15 Safari: http://cl.ly/image/2C1B2r2n2J3J -- 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: Autolayout Freespace
Sent from my iPhone On 2013/12/12, at 13:50, Luther Baker lutherba...@gmail.com wrote: Is there a way autolayout can be told to proportionally divide available free space amongst a set of views? For example (please ignore the actual 'VFL' and consider the following horizontal layout string as pseudo code): H:|-[FirstName]-[LastName]-[SocialSecurity]-[Birthday]-[Age]-| Assume that each control hugs its own content tightly and that in the simple case, the initial display ends up requiring only 50% of the available parent view width. Can I set up the constraints so that the remaining space is divided up according to some user-defined relative weighting mechanism? IE: I want the FirstName and LastName textfields to grow - receiving 20% each of the remaining space with the Birthday button then getting the final extra 10%? Using resistance and hugging properties, I know how to make 1 control receive all the extra space ... but I don't know how to balance free space across several controls. So this is where you might use long form. But basic thing is you need to calculate. Then set the metrics. Of course you might need to do some KVO or other means of keeping in sync with resizing. You might also just consider NSStackView designed for this purpose. ___ 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/m ___ 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
They simulated iOS 7 looks using iOS 6 SDK. It is not that difficult by using appearance proxy. On Dec 12, 2013, at 13:26, Rick Mann rm...@latencyzero.com wrote: Why does the Google Hangouts app on iPad, on iOS 7, have a nice-looking iOS-6 style keyboard? Other UI in the app looks like iOS 7 UI. Hangouts: http://cl.ly/image/1U2T1e1y1G15 Safari: http://cl.ly/image/2C1B2r2n2J3J -- 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/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: iPad keyboards
I'm running iOS 7. You're saying they styled their own keyboard to look like the iOS 6 keyboard? It's a pretty good imitation. On Dec 11, 2013, at 21:29 , Maxthon Chan xcvi...@me.com wrote: They simulated iOS 7 looks using iOS 6 SDK. It is not that difficult by using appearance proxy. On Dec 12, 2013, at 13:26, Rick Mann rm...@latencyzero.com wrote: Why does the Google Hangouts app on iPad, on iOS 7, have a nice-looking iOS-6 style keyboard? Other UI in the app looks like iOS 7 UI. Hangouts: http://cl.ly/image/1U2T1e1y1G15 Safari: http://cl.ly/image/2C1B2r2n2J3J -- 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/xcvista%40me.com This email sent to xcvi...@me.com -- 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
The other way around - they styled their UI in iOS 7 fashion but used iOS 6 SDK. It is actually quite simple if you ignore the blur effect. And I used to do that as well - when I worked for a game company and designed a UIKit-only game imitating iOS 7 looks on iOS 6 SDK. On Dec 12, 2013, at 13:44, Rick Mann rm...@latencyzero.com wrote: I'm running iOS 7. You're saying they styled their own keyboard to look like the iOS 6 keyboard? It's a pretty good imitation. On Dec 11, 2013, at 21:29 , Maxthon Chan xcvi...@me.com wrote: They simulated iOS 7 looks using iOS 6 SDK. It is not that difficult by using appearance proxy. On Dec 12, 2013, at 13:26, Rick Mann rm...@latencyzero.com wrote: Why does the Google Hangouts app on iPad, on iOS 7, have a nice-looking iOS-6 style keyboard? Other UI in the app looks like iOS 7 UI. Hangouts: http://cl.ly/image/1U2T1e1y1G15 Safari: http://cl.ly/image/2C1B2r2n2J3J -- 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/xcvista%40me.com This email sent to xcvi...@me.com -- 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
Re: iPad keyboards
They released the latest version of their app Nov 19. They would've had to build against the iOS 7 SDK. So, how do they get that look? On Dec 11, 2013, at 21:47 , Maxthon Chan xcvi...@me.com wrote: The other way around - they styled their UI in iOS 7 fashion but used iOS 6 SDK. It is actually quite simple if you ignore the blur effect. And I used to do that as well - when I worked for a game company and designed a UIKit-only game imitating iOS 7 looks on iOS 6 SDK. On Dec 12, 2013, at 13:44, Rick Mann rm...@latencyzero.com wrote: I'm running iOS 7. You're saying they styled their own keyboard to look like the iOS 6 keyboard? It's a pretty good imitation. On Dec 11, 2013, at 21:29 , Maxthon Chan xcvi...@me.com wrote: They simulated iOS 7 looks using iOS 6 SDK. It is not that difficult by using appearance proxy. On Dec 12, 2013, at 13:26, Rick Mann rm...@latencyzero.com wrote: Why does the Google Hangouts app on iPad, on iOS 7, have a nice-looking iOS-6 style keyboard? Other UI in the app looks like iOS 7 UI. Hangouts: http://cl.ly/image/1U2T1e1y1G15 Safari: http://cl.ly/image/2C1B2r2n2J3J -- 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/xcvista%40me.com This email sent to xcvi...@me.com -- Rick -- 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: Autolayout Freespace
Thanks - and yeah, I'm trying to avoid calculation. 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? Back to the original question, do I misunderstand priorities? Can these act as weights at all ... or does the highest priority just win? Thanks. On Wed, Dec 11, 2013 at 11:28 PM, dangerwillrobinsondan...@gmail.comwrote: Sent from my iPhone On 2013/12/12, at 13:50, Luther Baker lutherba...@gmail.com wrote: Is there a way autolayout can be told to proportionally divide available free space amongst a set of views? For example (please ignore the actual 'VFL' and consider the following horizontal layout string as pseudo code): H:|-[FirstName]-[LastName]-[SocialSecurity]-[Birthday]-[Age]-| Assume that each control hugs its own content tightly and that in the simple case, the initial display ends up requiring only 50% of the available parent view width. Can I set up the constraints so that the remaining space is divided up according to some user-defined relative weighting mechanism? IE: I want the FirstName and LastName textfields to grow - receiving 20% each of the remaining space with the Birthday button then getting the final extra 10%? Using resistance and hugging properties, I know how to make 1 control receive all the extra space ... but I don't know how to balance free space across several controls. So this is where you might use long form. But basic thing is you need to calculate. Then set the metrics. Of course you might need to do some KVO or other means of keeping in sync with resizing. You might also just consider NSStackView designed for this purpose. ___ 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/m ___ 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
Technically, an iPad running iOS7 can run apps in iOS6 compatibility mode. The keyboard is a dead giveaway. It is similar to an original OSX upgrade from OS9, where some OS9 apps could run within OSX under an OS9 compatibility mode. Or think of it like running a windows app in Parallels on a Mac. If an app is running in iOS6 compatibility mode, some of the controls you will see (like the alert view) will look like iOS7 - but alas, an iOS6 keyboard showing up on an iOS7 device is a dead giveaway that the app was built with iOS6 SDK ... which automatically runs on the iOS7 device in iOS6 compatibility mode. The key, you must build your app with the iOS6 SDK. That means ... Xcode 4.3 ... or download an older version of Xcode and copy the 6 SDK into your Xcode 5. In general, not everything works perfectly in iOS6 compatibility mode - so be sure and do some testing ... but for instance, it allows my existing apphttps://itunes.apple.com/tc/app/bliki-wiki/id623149294?mt=8 released May 2013 to continue to function and run on iOS7 devices without requiring an updated binary from me. On Wed, Dec 11, 2013 at 11:47 PM, Maxthon Chan xcvi...@me.com wrote: The other way around - they styled their UI in iOS 7 fashion but used iOS 6 SDK. It is actually quite simple if you ignore the blur effect. And I used to do that as well - when I worked for a game company and designed a UIKit-only game imitating iOS 7 looks on iOS 6 SDK. On Dec 12, 2013, at 13:44, Rick Mann rm...@latencyzero.com wrote: I'm running iOS 7. You're saying they styled their own keyboard to look like the iOS 6 keyboard? It's a pretty good imitation. On Dec 11, 2013, at 21:29 , Maxthon Chan xcvi...@me.com wrote: They simulated iOS 7 looks using iOS 6 SDK. It is not that difficult by using appearance proxy. On Dec 12, 2013, at 13:26, Rick Mann rm...@latencyzero.com wrote: Why does the Google Hangouts app on iPad, on iOS 7, have a nice-looking iOS-6 style keyboard? Other UI in the app looks like iOS 7 UI. Hangouts: http://cl.ly/image/1U2T1e1y1G15 Safari: http://cl.ly/image/2C1B2r2n2J3J -- 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/xcvista%40me.com This email sent to xcvi...@me.com -- 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
Right, so how were they able to release an app 11/19 without using the iOS 7 sdk? I doubt they submitted it long before that. Sent from my iPhone On Dec 11, 2013, at 22:04, Luther Baker lutherba...@gmail.com wrote: Technically, an iPad running iOS7 can run apps in iOS6 compatibility mode. The keyboard is a dead giveaway. It is similar to an original OSX upgrade from OS9, where some OS9 apps could run within OSX under an OS9 compatibility mode. Or think of it like running a windows app in Parallels on a Mac. If an app is running in iOS6 compatibility mode, some of the controls you will see (like the alert view) will look like iOS7 - but alas, an iOS6 keyboard showing up on an iOS7 device is a dead giveaway that the app was built with iOS6 SDK ... which automatically runs on the iOS7 device in iOS6 compatibility mode. The key, you must build your app with the iOS6 SDK. That means ... Xcode 4.3 ... or download an older version of Xcode and copy the 6 SDK into your Xcode 5. In general, not everything works perfectly in iOS6 compatibility mode - so be sure and do some testing ... but for instance, it allows my existing app released May 2013 to continue to function and run on iOS7 devices without requiring an updated binary from me. On Wed, Dec 11, 2013 at 11:47 PM, Maxthon Chan xcvi...@me.com wrote: The other way around - they styled their UI in iOS 7 fashion but used iOS 6 SDK. It is actually quite simple if you ignore the blur effect. And I used to do that as well - when I worked for a game company and designed a UIKit-only game imitating iOS 7 looks on iOS 6 SDK. On Dec 12, 2013, at 13:44, Rick Mann rm...@latencyzero.com wrote: I'm running iOS 7. You're saying they styled their own keyboard to look like the iOS 6 keyboard? It's a pretty good imitation. On Dec 11, 2013, at 21:29 , Maxthon Chan xcvi...@me.com wrote: They simulated iOS 7 looks using iOS 6 SDK. It is not that difficult by using appearance proxy. On Dec 12, 2013, at 13:26, Rick Mann rm...@latencyzero.com wrote: Why does the Google Hangouts app on iPad, on iOS 7, have a nice-looking iOS-6 style keyboard? Other UI in the app looks like iOS 7 UI. Hangouts: http://cl.ly/image/1U2T1e1y1G15 Safari: http://cl.ly/image/2C1B2r2n2J3J -- 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/xcvista%40me.com This email sent to xcvi...@me.com -- 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
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. The UIAlertView is somewhat special because it is not implemented in UIKit actually, instead they are in SpringBoard.app which is a native iOS 7 app. SpringBoard.app is (was, after some touch handling code got split into backboardd) Finder.app and WindowServer rolled into one package. On Dec 12, 2013, at 14:04, Luther Baker lutherba...@gmail.com wrote: Technically, an iPad running iOS7 can run apps in iOS6 compatibility mode. The keyboard is a dead giveaway. It is similar to an original OSX upgrade from OS9, where some OS9 apps could run within OSX under an OS9 compatibility mode. Or think of it like running a windows app in Parallels on a Mac. If an app is running in iOS6 compatibility mode, some of the controls you will see (like the alert view) will look like iOS7 - but alas, an iOS6 keyboard showing up on an iOS7 device is a dead giveaway that the app was built with iOS6 SDK ... which automatically runs on the iOS7 device in iOS6 compatibility mode. The key, you must build your app with the iOS6 SDK. That means ... Xcode 4.3 ... or download an older version of Xcode and copy the 6 SDK into your Xcode 5. In general, not everything works perfectly in iOS6 compatibility mode - so be sure and do some testing ... but for instance, it allows my existing app released May 2013 to continue to function and run on iOS7 devices without requiring an updated binary from me. On Wed, Dec 11, 2013 at 11:47 PM, Maxthon Chan xcvi...@me.com wrote: The other way around - they styled their UI in iOS 7 fashion but used iOS 6 SDK. It is actually quite simple if you ignore the blur effect. And I used to do that as well - when I worked for a game company and designed a UIKit-only game imitating iOS 7 looks on iOS 6 SDK. On Dec 12, 2013, at 13:44, Rick Mann rm...@latencyzero.com wrote: I'm running iOS 7. You're saying they styled their own keyboard to look like the iOS 6 keyboard? It's a pretty good imitation. On Dec 11, 2013, at 21:29 , Maxthon Chan xcvi...@me.com wrote: They simulated iOS 7 looks using iOS 6 SDK. It is not that difficult by using appearance proxy. On Dec 12, 2013, at 13:26, Rick Mann rm...@latencyzero.com wrote: Why does the Google Hangouts app on iPad, on iOS 7, have a nice-looking iOS-6 style keyboard? Other UI in the app looks like iOS 7 UI. Hangouts: http://cl.ly/image/1U2T1e1y1G15 Safari: http://cl.ly/image/2C1B2r2n2J3J -- 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/xcvista%40me.com This email sent to xcvi...@me.com -- 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 Dec 11, 2013, at 10:46 PM, Maxthon Chan xcvi...@me.com 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: iPad keyboards
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 gpar...@apple.com wrote: On Dec 11, 2013, at 10:46 PM, Maxthon Chan xcvi...@me.com 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
