Re: iPad keyboards

[Maxthon Chan]

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: iPad keyboards

[Greg Parker]

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: iPad keyboards

[Maxthon Chan]

There are situations that new frameworks failed to support old code and 
debugging may be impossible, especially games. Apple will not prevent them from 
being released. (Some apps are known to be linked against ancient SDKs like iOS 
4 SDK when released)

On Dec 12, 2013, at 14:46, Rick Mann  wrote:

> 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  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  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  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  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  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

[Maxthon Chan]

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  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  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  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  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  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

[Rick Mann]

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  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  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  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  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  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

[Luther Baker]

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  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  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  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  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: Autolayout Freespace

[Luther Baker]

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, wrote:

>
>
> Sent from my iPhone
>
> > On 2013/12/12, at 13:50, Luther Baker  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

[Rick Mann]

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  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  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  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  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: iPad keyboards

[Maxthon Chan]

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  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  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  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

[Rick Mann]

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  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  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

[Maxthon Chan]

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  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: Autolayout Freespace

[dangerwillrobinsondanger]

Sent from my iPhone

> On 2013/12/12, at 13:50, Luther Baker  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

iPad keyboards

[Rick Mann]

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

Autolayout Freespace

[Luther Baker]

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

Re: Threaded drawing

[David Duncan]

On Dec 11, 2013, at 4:17 PM, Dave Fernandes  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  wrote:
> 
>> On Dec 11, 2013, at 8:05 AM, Jeffrey Oleander  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

Re: Threaded drawing

[Dave Fernandes]

Is there any way to zoom in just one dimension?

On Dec 11, 2013, at 6:05 PM, David Duncan  wrote:

> On Dec 11, 2013, at 8:05 AM, Jeffrey Oleander  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 - JPEG

[Kevin Meaney]

On 11 Dec 2013, at 22:43, Greg Parker  wrote:

> On Dec 11, 2013, at 9:53 AM, Steve Sisak  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

[David Duncan]

On Dec 11, 2013, at 8:05 AM, Jeffrey Oleander  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

[Greg Parker]

On Dec 11, 2013, at 9:53 AM, Steve Sisak  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: Strange Static Analyzer Warning

[Keary Suska]

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

[Steve Sisak]

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.

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

[Steve Mills]

On Dec 11, 2013, at 10:25:42, Keary Suska  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: Strange Static Analyzer Warning

[Ken Thomases]

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: Threaded drawing

[Mike Abdullah]

On 11 Dec 2013, at 13:10, Graham Cox  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

Cocoaheads 92630 will be meeting today, Wed, Dec 11 at 7pm

[Scott Ellsworth]

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

Strange Static Analyzer Warning

[Keary Suska]

(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

Re: Threaded drawing

[Jeffrey Oleander]

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

Re: Threaded drawing

[Jens Alfke]

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

Custom view and NSText

[Georg Seifert]

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

Help/Unsubscri

Re: Threaded drawing

[Graham Cox]

On 11 Dec 2013, at 12:40 pm, Ken Thomases  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

Re: Threaded drawing

[Graham Cox]

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

[2551]

On 11 Dec 2013, at 17:20, Graham Cox  wrote:
> The documentation is sparse though ...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

[Ken Thomases]

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

[Graham Cox]

On 10 Dec 2013, at 7:39 pm, Kyle Sluder  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: NSURLSessionUploadTask - stops uploading after sending 160kB of data (5x 32kB chunks)

[Robert Vojta]

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  wrote:
> 
> 
>> On Dec 10, 2013, at 11:16 AM, Robert Vojta  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: Preferences caching?

[Uli Kusterer]

On 10 Dec 2013, at 18:08, Kyle Sluder  wrote:
>> On Dec 10, 2013, at 7:46 AM, Jakob Egger  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: NSButton state not persisting

[Uli Kusterer]

On 10 Dec 2013, at 22:26, Jens Alfke  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