Re: "Z" in setDateFormat ?

[Roland King via Cocoa-dev]

Yes

> On 22 Jul 2023, at 08:42, Gabriel Zachmann  wrote:
> 
> Thanks! ... and what is the meaning of the Z at the end of a date/time ?
> GMT+0:0 ?
> 
> Best regards, Gabriel
> 
> 
>> On 22. Jul 2023, at 12:25, Roland King  wrote:
>> 
>> It’s a literal. It’s quoted. So it prints “Z”
>> 
>>>> On 22 Jul 2023, at 06:15, Gabriel Zachmann via Cocoa-dev 
>>>>  wrote:
>>> 
>>> In the Apple docs in chapter "Date Formatters" I found sample code that 
>>> contains this line:
>>> 
>>> [rfc3339DateFormatter setDateFormat:@"'-'MM'-'dd'T'HH':'mm':'ss'Z'"];
>>> 
>>> Now, my very specific question is: what does the 'Z' do?
>>> And where would I find the doc about it? (and potential other letters?)
>>> My guess would be it has something to do with the 'Z'/time offset mentioned 
>>> in RFC 3339, but it is unclear to me exactly what is meant here.
>>> 
>>> Best regards, Gabriel
>>> 
>>> ___
>>> 
>>> 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/rols%40rols.org
>>> 
>>> This email sent to r...@rols.org
> 
___

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: "Z" in setDateFormat ?

[Roland King via Cocoa-dev]

It’s a literal. It’s quoted. So it prints “Z”

> On 22 Jul 2023, at 06:15, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> In the Apple docs in chapter "Date Formatters" I found sample code that 
> contains this line:
> 
>  [rfc3339DateFormatter setDateFormat:@"'-'MM'-'dd'T'HH':'mm':'ss'Z'"];
> 
> Now, my very specific question is: what does the 'Z' do?
> And where would I find the doc about it? (and potential other letters?)
> My guess would be it has something to do with the 'Z'/time offset mentioned 
> in RFC 3339, but it is unclear to me exactly what is meant here.
> 
> Best regards, Gabriel
> 
> ___
> 
> 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/rols%40rols.org
> 
> This email sent to r...@rols.org
___

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: dictionaryWithObjects:keys: looses elements

[Roland King via Cocoa-dev]

First guess would be that only 7 of the 17 keys are actually unique dates so 
the dictionary only has 7 entries, one for each of them. 

> On 4 Jan 2023, at 06:52, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> I have this line in my code:
> 
>NSDictionary * temp = [NSDictionary dictionaryWithObjects: imagefiles_ 
> forKeys: datesAndTimes_ ];
> 
> The funny thing is: 
> the input arrays (imagefiles_ and datesAndTimes_) both have 17 elements;
> however, the dictionary temp has only 7 elements afterwards!
> 
> In the debugger, both input arrays appear to be OK, nothing peculiar about 
> them.
> 
> The array for the keys is constructed essentially the following way:
> 
>iso_date = [isoDateFormatter_ dateFromString: (__bridge NSString * 
> _Nonnull)(dateref) ];
>[datesAndTimes_ addObject: iso_date ];
> 
> (I also tried 
> 
>[datesAndTimes_ addObject: [iso_date copy] ];
> 
> to no avail.)
> 
> The values array is constructed like this:
> 
>imagefiles_ = [NSMutableArray arrayWithArray: [filelist 
> componentsSeparatedByString: @"\n"] ];
> 
> 
> I'd be very grateful if anybody could shed some light on this.
> 
> Best regards, Gabriel
> 
> ___
> 
> 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/rols%40rols.org
> 
> This email sent to r...@rols.org

___

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

[Roland King via Cocoa-dev]

> 
> BTW, one site we looked at describes ARC as "kind of like a Japanese B-horror 
> movie". That seems accurate.
> 

I don’t know what site wrote that but it couldn’t be less accurate. ARC is one 
of the better pieces of technology Apple introduced into Objective-C and it cut 
down on a huge number of memory leaks and random crashes which came from people 
messing up implementing retain/release manually. And it interoperated with 
manual retain/release. And unlike other solutions to memory management it 
doesn’t have a garbage collection thread running somewhere looking for things 
to deallocate and reference loops. And Apple, when they introduced it, added 
tools into XCode and Instruments to find reference loops so you could fix them 
before you ship. 

You have to learn a couple of rules, and really just a couple, and think about 
the ownership of your objects, which most of the time is trivial. Your reward 
is an application with deterministic and memory handling without having to 
scrub through the code working out who ought to release an object. 

___

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: Cannot include Carbon on Mojave

[Roland King]

… and now I look at your command line it has -arch i386 which is why the 
compiler isn’t defining __LP64__ automatically. You can see this with the 
rather useful define printing trick

normal 64 bit

g++  -dM -E - < /dev/null|grep LP64

shows that __LP64__ is defined

but if you force 32 bit architecture

g++ -arch i386 -dM -E - < /dev/null|grep LP64

it isn’t defined. 

So the basic ‘reason’ you’re getting a failure is because CarbonSound is (and 
may for some time have been) only included in 32bit builds. Apple has now 
removed the actual package from the SDK but left the include in there. This was 
probably not noticed as everyone is building 64 bit so the macro is defined so 
the header include was skipped and it didn’t matter that it’s not there. So you 
could say the header is broken, it kind of is, they should have just removed it 
entirely when they removed the package. 



> On 15 May 2019, at 05:23, Roland King  wrote:
> 
> CarbonSound has most definitely been removed from the current SDK, you can 
> use find or grep or the really useful utility ‘ack’ to prove that
> 
> If you look at the header file for carbon you’ll find 
> 
> #if !__LP64__
> #ifndef __CARBONSOUND__
> #include 
> #endif
> 
> so the include is guarded by __LP64__ which is the define which says you’re 
> building a 64 bit target. Xcode and any Xcode type build sets that define for 
> you, so if you’re using g++ and your own command line, you need to set it 
> somewhere, either on the command line or at the very start of any code to 
> ensure it’s set everywhere. 
> 
> If you aren’t building for a 64 bit target, can’t really help you, do non-64 
> bit targets even exist any more and work? It’s been so long since Apple did 
> the transition. 
> 
>> On 15 May 2019, at 05:11, Vojtěch Meluzín  wrote:
>> 
>> I know it has been deprecated, no argues there, but my point is that the
>> headers are there, yet the compiler doesn't find them.
>> I'm trying to find out what XCode does exactly - is there a way to display
>> the actual command line XCode uses to compile the source codes?
>> 
>> Cheers!
>> Vojtech
>> 
>> 
>> út 14. 5. 2019 v 22:13 odesílatel Richard Charles 
>> napsal:
>> 
>>>> On May 14, 2019, at 12:02 PM, Vojtěch Meluzín 
>>> wrote:
>>>> 
>>>> Not really,
>>> 
>>> Yes really, CarbonSound was depreciated in OS X v10.5. Depreciated does
>>> not mean that the framework has been removed from current installations of
>>> the OS (although that is possible). It means that developers are
>>> discouraged from using the API and that at some point in the future it may
>>> be unsupported or removed.
>>> 
>>> "Apple did not create a 64-bit version of Carbon while updating their
>>> other frameworks in the 2007 time-frame, and eventually deprecated the
>>> entire API in OS X 10.8 Mountain Lion, which was released on July 24, 2012."
>>> 
>>> https://en.wikipedia.org/wiki/Carbon_(API)
>>> 
>>> 
>>>> On May 14, 2019, at 9:29 AM, Vojtěch Meluzín 
>>> wrote:
>>>> 
>>>> Compiling carbon.h ends up with this:
>>>> 
>>>> 
>>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/
>>>> Carbon.framework/Headers/Carbon.h:34:10: fatal error:
>>>> 'CarbonSound/CarbonSound.h' file not found
>>> 
>>> My guess is that this is deliberate and Xcode is trying to warn you move
>>> to another API. But maybe not and you will find a workaround.
>>> 
>>> --Richard Charles
>>> 
>>> 
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>> 
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/cocoa-dev/rols%40rols.org
>> 
>> This email sent to r...@rols.org
> 
> ___
> 
> 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/rols%40rols.org
> 
> This email sent to r...@rols.org

___

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: Cannot include Carbon on Mojave

[Roland King]

CarbonSound has most definitely been removed from the current SDK, you can use 
find or grep or the really useful utility ‘ack’ to prove that

If you look at the header file for carbon you’ll find 

#if !__LP64__
#ifndef __CARBONSOUND__
#include 
#endif

so the include is guarded by __LP64__ which is the define which says you’re 
building a 64 bit target. Xcode and any Xcode type build sets that define for 
you, so if you’re using g++ and your own command line, you need to set it 
somewhere, either on the command line or at the very start of any code to 
ensure it’s set everywhere. 

If you aren’t building for a 64 bit target, can’t really help you, do non-64 
bit targets even exist any more and work? It’s been so long since Apple did the 
transition. 

> On 15 May 2019, at 05:11, Vojtěch Meluzín  wrote:
> 
> I know it has been deprecated, no argues there, but my point is that the
> headers are there, yet the compiler doesn't find them.
> I'm trying to find out what XCode does exactly - is there a way to display
> the actual command line XCode uses to compile the source codes?
> 
> Cheers!
> Vojtech
> 
> 
> út 14. 5. 2019 v 22:13 odesílatel Richard Charles 
> napsal:
> 
>>> On May 14, 2019, at 12:02 PM, Vojtěch Meluzín 
>> wrote:
>>> 
>>> Not really,
>> 
>> Yes really, CarbonSound was depreciated in OS X v10.5. Depreciated does
>> not mean that the framework has been removed from current installations of
>> the OS (although that is possible). It means that developers are
>> discouraged from using the API and that at some point in the future it may
>> be unsupported or removed.
>> 
>> "Apple did not create a 64-bit version of Carbon while updating their
>> other frameworks in the 2007 time-frame, and eventually deprecated the
>> entire API in OS X 10.8 Mountain Lion, which was released on July 24, 2012."
>> 
>> https://en.wikipedia.org/wiki/Carbon_(API)
>> 
>> 
>>> On May 14, 2019, at 9:29 AM, Vojtěch Meluzín 
>> wrote:
>>> 
>>> Compiling carbon.h ends up with this:
>>> 
>>> 
>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/
>>> Carbon.framework/Headers/Carbon.h:34:10: fatal error:
>>> 'CarbonSound/CarbonSound.h' file not found
>> 
>> My guess is that this is deliberate and Xcode is trying to warn you move
>> to another API. But maybe not and you will find a workaround.
>> 
>> --Richard Charles
>> 
>> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/rols%40rols.org
> 
> This email sent to r...@rols.org

___

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: Mac App Store paid upgrades and app settings

[Roland King]

> On 14 Aug 2018, at 04:08, Richard Charles  wrote:
> 
> 
> 
> It has been reported that Microsoft Office 365 and Adobe Lightroom are coming 
> to the new Mac App Store. Those apps surely are not single time payment apps. 
> So does this mean that the new Mac App Store will allow for upgrade payments 
> or recurring payments? Perhaps Apple, Microsoft and Adobe know the answer to 
> that question but are not telling anyone.
> 

I’m 99% sure both those apps will be monthly subscriptions, just as Lightroom 
is on iOS (you can subscribe to the mobile app through the iOS app store or get 
an Adobe subscription for their creative cloud apps and that unlocks mobile). 
Adobe moved to a monthly payment model a while ago and Microsoft has been 
pushing that as much as they can too. So I don’t think the upgrade issue is 
going to be relevant in either of those cases. 
___

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: ANN: New unofficial developer mailing lists

[Roland King]

indeed there hasn’t - however it was more than possible they were all going to 
get shut down but only the Xcode list maintainer was nice enough to tell 
anyone. It was rather odd they only killed one of them 

In the event however, this still seems to be working. Hopefully the others I’m 
on are similarly blessed. 

> On 9 Jul 2017, at 11:55, Quincey Morris <quinceymor...@rivergatesoftware.com> 
> wrote:
> 
> On Jul 8, 2017, at 20:45 , Roland King <r...@rols.org <mailto:r...@rols.org>> 
> wrote:
>> 
>> wondered if this list is still working today - we got the ‘goodnight to all’ 
>> message on xcode yesterday, not that I’ve tried it. 
> 
> Apple hasn’t shut this one down, and there hasn’t been a notification like 
> there was for code-users.
> 

___

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: ANN: New unofficial developer mailing lists

[Roland King]

wondered if this list is still working today - we got the ‘goodnight to all’ 
message on xcode yesterday, not that I’ve tried it. 

> On 7 Jun 2017, at 08:23, Jens Alfke  wrote:
> 
> You may have seen the announcement that the xcode-users mailing list is going 
> away. On the assumption that it’s only a matter of time before the rest of  
> lists.apple.com follows suit, I’ve taken the initiative to make a new set of 
> mailing lists at groups.io. So far there’s an Xcode and a Cocoa list.
> 
> The top-level group is at: https://apple-dev.groups.io/g/main
> On that page you’ll see a section called “Subgroups”, which links to:
>   Xcode list: https://apple-dev.groups.io/g/xcode
>   Cocoa list: https://apple-dev.groups.io/g/cocoa
> 
> I believe you have to join the top-level group first to be able to subscribe 
> to the child groups, but you can change the settings independently. Much like 
> Google Groups, you can view and interact with messages in the web like a 
> forum, as well as getting emails of individual posts or digests.
> 
> Tell your friends!
> 
> —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/rols%40rols.org
> 
> This email sent to r...@rols.org

___

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: Very slow NSTableView

[Roland King]

isn't this what Instruments is supposed to be good at telling you?


On 04/07/2017 11:07, Alex Zavatone wrote:

Stab in the dark, but what is your cell identifier value?

I have seen WAY TOO MUCH CODE where people have created a different cell 
identifier for each cell.

Also, on iOS, there is a method called prepareCellForReuse that might apply 
here.

You can also log when the cell is displayed at the start and the end and see 
where the time suck is happening in an attempt to narrow this down.

GL.

- Alex Zavatone


On Jul 3, 2017, at 8:19 PM, Graham Cox  wrote:

I have a NSTableView, cell-based (partially because it’s a very long-standing 
piece of code, partially because it is just a table of values which a 
cell-based table is ideally suited to - view-based would not do anything for me 
here).

This table has always worked fine, but in Sierra, it is slow. as. molasses.

It is particularly noticeable when scrolling, which is needed when it has more 
than about 20 items. I get a ‘framerate’ of about 1 every 2 seconds.

I assumed my data source methods were slow, so I tried stubbing them out to see 
if that was indeed the cause, but no - even returning placeholder strings 
doesn’t make any difference.

Has anyone else noticed this in Sierra? What has changed that could make table 
views slow, and how can I restore its normal performance? I’ve turned off 
elasticity and ‘auto content inset’ for the scrollview, which I have noticed to 
cause some performance issues in other views, but it hasn’t helped.

—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/zav%40mac.com

This email sent to z...@mac.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/rols%40rols.org

This email sent to r...@rols.org


___

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: Mystery Threads

[Roland King]

> On 29 Sep 2016, at 16:59, Gerriet M. Denkmann  wrote:
> 
> 
>> On 29 Sep 2016, at 15:34, Quincey Morris 
>>  wrote:
>> 
>> On Sep 29, 2016, at 01:05 , Gerriet M. Denkmann  wrote:
>>> 
>>> Well, nothing. Just let’s call it nbrOfBlocksToBeUsedByDispatchApply, or 
>>> whatever. But ultimately any of these things has to run on a CPU, of which 
>>> there are no more than 8.
>> 
>> Well, here’s my narrative. It may be fiction or non-fiction.
>> 
>> You said you tried “nbrOf…” as a few ten-thousands, vs. 8. Let’s be concrete 
>> and call this (a) 40,000 vs. (b) 8. So, for each set of 40,000 iterations of 
>> your block, you’re doing 1 dispatch_apply in case #a, and 5,000 
>> dispatch_apply calls in case #b. So, you’ve established that 4,999 
>> dispatch_apply calls — and related per-dispatch_appy overhead — take a long 
>> time.
> 
> Well, I count this as (bigArea = 4 GB):
> (a) one call of dispatch_appy which schedules 40 000 times a block to GCD 
> which handles 0.1 MB
> (b) one call of dispatch_appy which schedules 8 times a block to GCD which 
> handles 500 MB
> 
> Could be that these blocks sometimes collide (maybe when they are operating 
> on adjacent areas), which slows them down. Such a collision is rather 
> unlikely if only 8 of 40 000 are running.
> 
> 
>> Of course, I’m relying on the fact that you’re doing the same number of 
>> *total* iterations of your inner loop in case #a and case #b. This is not 
>> quite the whole story, because there are loop setup overheads per block. 
>> However, the loop setup that you’ve shown is very simple — a couple of Int 
>> operations — so the additional 4,999 loop setup executions are likely 
>> dwarfed by 4,999 dispatch_apply executions.
> 
> The actual story is: one outer loop (same in all cases) which sets up some 
> parameters, then another loop which covers the area which is assigned to this 
> block.
> In case (a) this area is small: 0.1 MB, whereas in case (b) it is large: 500 
> MB. Which seems to be in favour of case (b).
> 
> 

Why guess - this is exactly what Instruments is designed to tell you. It’s even 
dispatch-aware so it can show you results broken down by dispatch queue and 
worker thread inside the dispatch queue. Run the two under instruments and find 
out where all the time is spent. 


___

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

Entitlements for non-appstore developer-id signed apps

[Roland King]

I was reading a review of MacOS Sierra and it was claiming that Developer ID 
signed, non mac-appstore apps now have access to more of iCloud than they did 
previously, however it wasn’t very clear about exactly what those available 
entitlements are. 

I’ve hunted around the documentation, in the Entitlements section, the iCloud 
section and a few other places but I can’t find a table, or similar resource, 
which says what entitlements are available to Developer ID signed apps and 
which are still reserved for mac app store apps in MacOS Sierra.

Has anyone seen such a table and have a link for it please? 
___

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: Odd File Truncation

[Roland King]

> On 7 Sep 2016, at 19:19, Peter Hudson  wrote:
> 
> 
> ___


The file truncation seems to have spread to mail messages !!!
___

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: Swift changes in Xcode 8

[Roland King]

> On 31 Aug 2016, at 09:02, Rick Mann  wrote:
> 
> The problem I'm having is not the changes in the language, but in the iOS 
> API. I can compile Swift 2.2 with a compiler flag. I can't make changes to 
> support iOS 10 (and still build with Xcode 7, which is necessary for 
> submitting to the App Store).
> 

But by the time you are need to and can submit to the store for iOS10 then you 
will be able to use Xcode 8, so just work using that and wait for the GM, my 
guess would be that’s a week away. 


___

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: uitabbar translucency and hiding

[Roland King]

> 
> Maybe there’s a sanctioned way of moving a child view controller to a 
> different parent view controller (so, move the view controller, not the 
> view), but I’m in over my head at this point.
> 

I haven’t read the whole thread, however to this particular comment, there is a 
sanctioned way of moving a child view controller to a different parent view 
controller, it’s view controller containment introduced, dunno 4 years ago 
perhaps. Look for all the methods on UIViewController called 
willMoveToParentViewController .. etc. There’s a sequence to the whole thing 
which you need to follow in order to have view controller messages continue to 
be passed properly to the VCs. It’s long enough ago there’s probably some 
documentation on it by now, I learned about it at the time from WWDC videos and 
I’m sure lots of bells and whistles have been added to it since. 
___

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: NSImage from bitmap - then delete bitmap

[Roland King]

> 
> I would think that even with a retain it could get weird...
> 
> The main thread wants to use the imageRef property so it calls:
> 
> myRef = [window.imageRef];
> [myref retain];
> 
> If right between these calls, the worker thread calls setImageRef (on a
> property with atomic, copy), then the retain call in the main thread might
> be on something that has already gone away.
> 
> I just don't see how I can safely set the property on a worker thread and
> read it on the main thread without some risk of it being released behind my
> back.

As Graham points out, and as we used to discuss often back in the old MRR days, 
atomic getters likely put the value in the autorelease pool, you should go see 
if that’s the case or not, if so, it’s protected for as long as that pool isn’t 
drained, and it’s your pool on the main thread, so it won’t be drained between 
those calls. In that case you don’t even need to add the extra retains, however 
for good practice, why not. 

If atomic getters don’t work like that then they are fairly useless. 
___

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: NSImage from bitmap - then delete bitmap

[Roland King]

> On 27 Jul 2016, at 10:05, Trygve Inda  wrote:
> 
>> 
> 
> How is it retained by the main thread without an explicit retain call?

are you not using ARC? If you are then all such references, both variable and 
during method calls are retained automatically. If you’re not, then do what ARC 
does and retain it explicitly and release it explicitly (and start using ARC in 
that case!)

> 
> I would be no different than a main thread calling:
> 
> someVar [[MyObj alloc] init]
> [someVar doSomething];

That isn’t compilable code. Did you mean

someVar = [ [ MyObj alloc]init ]
[ someVar doSomething ];


> 
> If a worker thread were able to call [someVar release] between these two
> lines, the doSomething call could fail.
> 

Again if you’re using ARC, none of these issues are issues. 

Why would a worker thread call [ someVar release ] on a variable it didn’t 
retain in the first place? If that’s actually a realistic scenario and you’re 
not using ARC, then call retain on someVar when you assign it in the first 
place and release it only after you’re finished with it, after the call to 
doSomething. Which, by the way, is pretty much what ARC does. 



> 
> 


___

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: NSImage from bitmap - then delete bitmap

[Roland King]

> On 27 Jul 2016, at 09:33, Trygve Inda  wrote:
> 
> 
> 
> If the worker thread calls window.imageRep = myResult; it is possible that
> the main thread is in the middle of a call like:
> 
> [[window.imageRep] 
> drawInRect:fromRect:operation:fraction:respectFlipped:hints:]
> 
> So when the setter (called from the worker thread) replaces the old imageRep
> with a new one, the old one's retain count goes to zero and it will
> disappear.
> 
> I know atomic makes the call safe as far as a vaild value is concerned, but
> the main thread could call window.imageRep and get a valid value (because it
> is atomic), but before it is able to use this value, the worker thread calls
> the setter which causes the imageRep obtained by the main thread to be
> released.

No it couldn’t - because when the main thread calls window.imageRep it gets a 
reference which, whether it assigns it to a variable or just uses it in in a 
chained call (like you have above with drawInRect:.) is retained by the main 
thread during the life of that variable or during the call. So it doesn’t 
matter if the worker thread replaces it after the call to window.imageRep, the 
main thread’s reference remains valid and usable and is only released when it’s 
finished with it and only then gets deallocated (if nothing else is referencing 
it)


___

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: NSImage from bitmap - then delete bitmap

[Roland King]

> On 22 Jul 2016, at 14:40, Trygve Inda  wrote:
> 
> 
>> With half an eye on performance, if you *do* strictly need a copy of the
>> bitmap, note that NSBitmapImageRep conforms to NSCopying. You don’t have to
>> turn it into a TIFF and back again.
>> 
>> Also, you don’t even need an NSImage - the NSImageRep can be drawn directly.
> 
> 
> 
> So how is the best way to take my NSBitmapImageRep, and hand it off to the
> main thread in such a way that I can destroy the pixels immediately while
> the main thread keeps them?
> 
> Would it be best to just call [myImagerep copy], and hand that to the main
> thread, and let the main thread release it once it has draw it into the
> window?
> 

I’d have said the best way is to create a new image buffer for each new image 
you draw, draw into it and hand it off, then make another new one instead of 
trying to use one single one per thread. Creating them is cheap, it’s basically 
malloc(). Since you need the data to persist for display whilst you write a new 
image that means there’s two separate buffers, there has to be. So either you 
make a copy, which means going through the expense of copying it, or you just 
hand it off and start a new one, which doesn’t. When the main thread has 
finished with it it can dispose of the old buffer. 
___

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: UIStackView: Variable Spacing

[Roland King]

> On 7 Jul 2016, at 04:37, Daniel Stenmark  wrote:
> 
> What’s the best way to achieve variable spacing between children of a 
> UIStackView?  I know that a popular approach is to add an empty dummy view to 
> act as padding, but this is being used in a UITableView cell, so scrolling 
> performance is critical and the implicit constraints created by adding a 
> ‘padding’ view are a death knell for us.  
> 
> Dan


There’s no trick way to do it, you need some extra view one way or another. 

It’s a bit surprising that adding extra, fixed sized children to the stack 
really adds that much overhead, that’s a few very simple constraints, all 
constant, and shouldn’t really make that much difference. Perhaps the stackview 
is being inefficient with the number of constraints it adds when you add an 
extra child. You could take a look at the view hierarchy and see if that’s the 
case or not. 

You could try going the other way around and making your real elements children 
of dummy views so you get to add the simplest top/bottom-padding constraints 
possible to those views, that may minimise the number of extra constraints 
added and you get to control it somewhat. But if your hierarchy is such that 
it’s straining the constraint system performance wise, whatever way you try to 
do this is going to have similar performance. 
___

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: NSStream and Threads

[Roland King]

> On 4 Jul 2016, at 14:34, Gerriet M. Denkmann  wrote:
> 
> 
>> On 4 Jul 2016, at 12:00, Charles Srstka  wrote:
>> 
>>> On Jul 3, 2016, at 11:35 PM, Gerriet M. Denkmann  
>>> wrote:
>>> 
>>> When I get an NSStream I do:
>>> 
>>> aStream.delegate = myStreamDelegate;
>>> [ aStream scheduleInRunLoop:[NSRunLoop currentRunLoop] forMode: 
>>> NSDefaultRunLoopMode];
>>> [ aStream open];
>>> 
>>> myStreamDelegate then receives stream:handleEvent: messages.
>>> 
>>> The documentation says: “The message is sent on the stream object’s thread."
>>> 
>>> Actually it is sent on the main thread.
>>> 
>>> How can I set the “stream object’s thread” ?
>>> 
>>> Gerriet.
>> 
>> What thread is the run loop on?
> 
> Well, seems like the main thread?
> 
> Gerriet.
> 

So schedule it on a runloop in a thread other than main then. Obviously if you 
schedule something in a runloop you are going to get calls from the thread 
which is running that runloop. 


___

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: WWDC 2016 direct download

[Roland King]

If you can’t run the WWDC app then go to developer.apple.com, find the videos 
section, find the WWDC videos section, find the one you want and on the 
Resources tab are links to the hi and sd def videos. 



> On 27 Jun 2016, at 14:47, tridiak  wrote:
> 
> Where do you download the 2016 WWDC videos directly?
> Or is that not possible (why)?
> I want to watch them on my iPod touch while on work breaks.
> 
> TIA
> ___
> 
> 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/rols%40rols.org
> 
> This email sent to r...@rols.org


___

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: Swift 3 - Notification leaks

[Roland King]

> On 18 Jun 2016, at 19:21, Andreas Mayer  wrote:
> 
> 
> Block based observers do still leak though.
> 

Not quite sure what you were asking in the mail as a whole but one question 
about block based observers, are you sure your block doesn’t have a retain 
cycle, possibly introduced by migration to Swift 3. 
___

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: Need advice on a custom run-loop mode

[Roland King]

> 
> As you can see I’ve experimented with the end date, but seems that 
> -distantPast works well enough. I’ve also tried forcing a window redisplay on 
> each pass (as here) but it doesn’t appear to do anything; my understanding 
> was that the runloop should take care of this anyway.
> 
> What am I missing?
> 

I wondered about this when you first posted about using a custom runloop mode. 
I thought window updates were performed only during cycles of the runloop in 
‘normal’ mode and so you may not see any actual updates. it seems you do in 
fact see no actual updates. 

I am surprised that displayIfNeeded() doesn’t however fix this for you, perhaps 
there’s something else not getting triggered until the runloop runs in normal 
mode or else the views aren’t being marked dirty so displayIfNeeded() thinks 
it’s not needed. 

Things I’d probably try here are 

1) putting the normal runloop mode back to test if your updates now do get 
shown animated, that will assure you it’s the runloop mode causing it not 
something else. 
2) with the code you have, override a drawRect: somewhere and see if 
displayIfNeeded() is causing the drawRect:s to be called but the display isn’t 
getting flushed or if displayIfNeeded() isn’t actually calling the drawRect and 
other update methods. 
3) explicitly invalidate the view(s) to see if you can get displayIfNeeded() to 
definitely do something. 
___

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: iOS - the joy of observers and NSInternalInconsistancyException for KVO

[Roland King]

> On 20 May 2016, at 07:04, Roland King <r...@rols.org> wrote:
> 
> 
> Reading the original post he already has the warning about an object being 
> deallocated whilst still having observers attached to it. 
> 
> This is simply a case of putting a breakpoint on dealloc and working out why 
> the object is being deallocated before you’ve gone through the observation 
> removal code you have. 

.. and if you want a condition you can put on a conditional breakpoint inside 
dealloc (or swift equivalent), checking self.observationInfo != nil may help to 
get the right dealloc. And that object, even though it’s actually opaque and 
internal and not-to-be-used, when printed will reveal some hints about who is 
still observing you .. at least in objC, I’ve never got the right commands to 
make LLDB use the objC print to show it. 

Just for clarity - I’m not suggesting using observationInfo to ‘prevent 
dealloc’, which you can’t do anyway and even if you could would be somewhere 
just the other side of insane, just to help filter out during debugging which 
dealloc to break on. 
___

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: iOS - the joy of observers and NSInternalInconsistancyException for KVO

[Roland King]

> On 20 May 2016, at 04:36, Jens Alfke  wrote:
> 
> 
>> On May 19, 2016, at 1:24 PM, Alex Zavatone  wrote:
>> 
>> In this case, I'm trying to see what is causing this deallocation.  In my 
>> code, I explicitly remove the observer before I nil the object, so I don't 
>> know where this is happening.  
> 
> If you’re observing an object, you should probably establish a strong 
> reference to it, like by assigning it to an ivar or adding it to an array or 
> something. Otherwise you can’t guarantee that it will stay alive. But since 
> say “nil the object”, which I guess means “nil a variable pointing to the 
> object”, then you should already have a strong reference, so the object 
> shouldn’t get dealloced unless you’ve got a ref-counting error somewhere. (Do 
> you use ARC?)
> 
> There is a user default NSBindingDebugLogLevel on Mac OS that you can set to 
> 1, which will generate extra warnings about KVO and bindings. It might do 
> something useful in your case; I can’t remember exactly what it does, but it 
> may produce a warning when an object with observers gets dealloced.
> 
> —Jens

Reading the original post he already has the warning about an object being 
deallocated whilst still having observers attached to it. 

This is simply a case of putting a breakpoint on dealloc and working out why 
the object is being deallocated before you’ve gone through the observation 
removal code you have. 
___

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: Codesigning pain, god it hurts!

[Roland King]

> 
> As for the App Store version, I’m not sure how I can distribute that 
> internally for testing - signing with the Developer ID doesn’t seem to be 
> right, but it’s unclear what other options I have.
> 
> —Graham
> 

That’s what the Mac Development ID is for. That’s embedded into the 
provisioning profiles for development with a list of Mac devices in it, so you 
can run your app on those machines. Then you submit it to the store with your 
Mac App Distribution signing identity which Apple then re-signs with their own 
later. I’ve never quite understood why there’s a separate Installer 
Distribution Identity but there is; and finally you have your Developer ID 
which really just signs apps as being traceably from you but allows limited 
access to any of the features like iCloud etc.

So if you don’t need any of the entitlements you can only get with a real 
sandboxed, signed, store (or Mac Development) app, then you could just sign 
with your Developer ID, or not bother to sign it at all. If you do need them, 
add the machines you want to run on to the account and generate a provisioning 
profile with them embedded, or let Xcode do that for you with one of its magic 
team provisioning profiles. 
___

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: Codesigning pain, god it hurts!

[Roland King]

.. all the stuff Quincey said plus

https://developer.apple.com/support/certificates/expiration/ 


make sure you have the latest Apple Worldwide Certs, they expired a few months 
ago so you may not. 

If you right-click on the certificate in KeyManager, a very capable app with a 
UI only its mother could love, you can evaluate the cert for various things 
including code signing. That’ll tell you if you have all your keys plus all the 
certs in the chain. 
___

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: unwind segue on navigation pop

[Roland King]

> On 13 May 2016, at 23:03, Kyle Sluder <k...@ksluder.com> wrote:
> 
> On Thu, May 12, 2016, at 09:48 PM, Roland King wrote:
>> I’m making more use of unwind segues to try and get to the point I have
>> ‘go forward’ and ‘go backward’ code in one place in the same class. So
>> during prepareForSegue I set some stuff up, during my unwind segue method
>> I tear it down again. Don’t use it for everything, but for some complex
>> presentations it’s been quite useful. 
>> 
>> I’ve just changed a piece of navigation to use a standard nav controller,
>> it used to be a modal presentation but a push makes more sense. So now
>> there’s no custom dismiss button like there used to be, you go back with
>> the normal back button on the nav controller. I can’t find a good way to
>> get that back action to trigger my unwind segue. Can’t seem to do it in
>> IB, I don’t want a custom back button because you lose the chevron (or
>> have to fake it) and all the normal uinav behaviour. 
> 
> The Back button is not customizable in this fashion. Please file an
> enhancement request at https://bugreport.apple.com.
> 
> --Kyle Sluder
> 

Yes I know it’s not customizable - but I was looking for a shorter term 
solution than an enhancement request, because I actually need to write the app. 

Is there a way to locate the exit segue method in a similar way to how exit 
segues themselves would find it so I can call it directly. In this case the 
exit segue is implemented by a VC pushed onto a nav stack below the one 
exiting. 

triggering the exit segue from viewWillDissapear: works but has a very fragile 
feel to it. 
targetForAction:withSender: doesn’t work because the responder chain goes 
through the nav controller and on upwards, but not through the sibling pushed 
VCs
targetViewControllerForAction:withSender I hoped would work, but seems to have 
the same issue, I don’t think the nav controller checks its children VCs

I didn’t really want to rebuild the machinery using 
allowedChildViewControllersForUnwindingFromSource: etc and hoped there was a 
pre-existing method to do the resolution. 

Looks like I’m using a protocol and revisiting in 2 years. 





___

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

unwind segue on navigation pop

[Roland King]

I’m making more use of unwind segues to try and get to the point I have ‘go 
forward’ and ‘go backward’ code in one place in the same class. So during 
prepareForSegue I set some stuff up, during my unwind segue method I tear it 
down again. Don’t use it for everything, but for some complex presentations 
it’s been quite useful. 

I’ve just changed a piece of navigation to use a standard nav controller, it 
used to be a modal presentation but a push makes more sense. So now there’s no 
custom dismiss button like there used to be, you go back with the normal back 
button on the nav controller. I can’t find a good way to get that back action 
to trigger my unwind segue. Can’t seem to do it in IB, I don’t want a custom 
back button because you lose the chevron (or have to fake it) and all the 
normal uinav behaviour. 

Best I’ve found so far is to give the segue a custom identifier (ie make it a 
viewcontroller segue) and performSegue it from ‘viewWillDisappear’, however 
that has a pretty bad smell about it because that’s not really an unwind, it’s 
already doing the dismissal by then. Feels like something which is going to 
break one day. 

There’s other ways I can do this obviously - change it to a protocol/delegate 
method called directly from the VC as it goes away, but I was trying to stick 
with unwind segues if possible. 



___

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: ARC [was Protecting against "app nap"]

[Roland King]

I can’t imagine going back to manual retain release. ARC lifted hours of work 
away from writing code because you just use objects and they stay when they 
need to stay go away when you’re done with them. I see hardly any questions 
about ARC at all, there were some at the very start, but they petered off 
pretty fast, that’s because it basically just works. There are a couple of 
things you need to know, how to avoid retain cycles with blocks (and the 
compiler warns you normally and Swift requires explicit selfs and warns you) 
and the annotation to keep objects alive through a scope which we discussed 
here the other day. That’s basically it, know those two things and it just 
works. The tools for debugging retain cycles are very good too, so if you do 
get one, it’s pretty easy to find it. 

ARC is 1000x more usable than manual retain release, and now it’s mature, I 
can’t think of a good reason not to use it.

> On 12 May 2016, at 16:16, Jonathan Taylor  
> wrote:
> 
> Hi Jens,
> 
> Thanks again for your reply. I'm sure this has been done to death over the 
> years on the list, but... you would definitely recommend ARC then, would you? 
> I've been a bit put off by what seems like regular questions on the list(s) 
> about debugging and fixing edge cases where ARC doesn't work. I guess that 
> only shows the times when it doesn't work, but it's rather left me thinking 
> that it's just the same, but with less explicit indication of what is going 
> on. Is that an unfair assessment, in your view?
> 
> Best regards,
> Jonny.
> 
> On 11 May 2016, at 16:10, Jens Alfke  wrote:
> 
>> 
>>> On May 11, 2016, at 2:31 AM, Jonathan Taylor 
>>>  wrote:
>>> 
>>> I guess I just found method naming a bit odd (not really referring to an 
>>> object at all), and might have expected it to have an ‘alloc/new’ naming 
>>> since I’d have thought the API would be almost exclusively used for 
>>> activities that continue beyond the calling scope.
>> 
>> The only methods named +alloc or +new are the core methods on NSObject that 
>> instantiate objects. (There’s also -copy and -mutableCopy.) Regular methods 
>> don’t use that naming scheme nor return owned references, they just 
>> consistently return unowned references. That keeps the rules simpler.
>> 
>> (And I really recommend using ARC! It saves trouble and eliminates a lot of 
>> bugs, like this one.)
>> 
>> —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: Receiver type for instance message is a forward declaration

[Roland King]

> 
> 2016-05-10 16:58:36.066 iApp[2549:2131821] *** Terminating app due to 
> uncaught exception 'NSInternalInconsistencyException', reason: '(
>" NO; view = ; target= <(action=oneFingerDoubleTap:, 
> target=)>; numberOfTapsRequired = 2>",
>" ; target= <(action=tapAndAHalf:, 
> target=)>>",
>" NO; view = ; target= <(action=oneFingerTap:, 
> target=)>>",
>" delaysTouchesEnded = NO; view = ; target= 
> <(action=loupeGesture:, target=)>>"
> ): An -observeValueForKeyPath:ofObject:change:context: message was received 
> but not handled.
> Key path: operations
> Observed object: {name = 'Upload Queue'}
> Change: {
>kind = 1;
> }
> Context: 0x1c7bb0'
> *** First throw call stack:
> (0x20d19b8b 0x204d6dff 0x20d19ad1 0x2151cd7d 0x214a3d81 0x21482fe3 0x21482c3b 
> 0x2151e311 0x214822d1 0x2152f761 0xf89b5 0x25322521 0x253224b1 0x2530a3eb 
> 0x25321dd1 0x25321a3f 0x2531a3c7 0x252eac85 0x252e9229 0x20cdba67 0x20cdb657 
> 0x20cd99bf 0x20c28289 0x20c2807d 0x22244af9 0x253532c5 0x1146c7 0x208d4873)
> libc++abi.dylib: terminating with uncaught exception of type NSException
> 
> BTW, if I remove the addObserver code, this doesn't happen.
> -Carl

Rather hard to tell but that seems to be hinting that the object not handling 
the KVO is a UITextTapRecognizer. But that may just be an artefact of what’s 
getting printed out. 

But I’ll ask the question I asked earlier

"Are you getting the warning anywhere in your debug logs that an object was 
deallocated whilst still having KVO notifications registered on it? That 
explicitly tells you that the KVO notifications can get attached to the wrong 
object.”. 

because it looks here as if something was deallocated with KVO still attached 
to it and now your KVO calls are going somewhere incorrect. 




___

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: Receiver type for instance message is a forward declaration

[Roland King]

> On 11 May 2016, at 07:39, Quincey Morris 
>  wrote:
> 
> On May 10, 2016, at 16:22 , Carl Hoefs  wrote:
>> 
>> I will set 'context' and use it in my check instead.
> 
> Yup, use the context to decide whether to call super *and return* but nothing 
> else. Once you get past that check, don’t call super.
> 
>> It appears that for some odd reason, once in a blue moon, 'object' and 
>> 'keyPath' aren't what they're supposed to be,
> 
> It’s not odd, if they’re the object and keyPath of a different observation 
> registered by a superclass of your class. You’ve proved it happens!
> 
> 

Well no he hasn’t - because if it was the object and keyPath of a different 
observation registered by a superclass of his class then passing it to super 
would allow that class to handle it, which it would do, and there would not be 
a crash. So it’s not that. 
___

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: Receiver type for instance message is a forward declaration

[Roland King]

> On 11 May 2016, at 07:22, Carl Hoefs  wrote:
> 
>> 
>> 
> Okay...  It appears that for some odd reason, once in a blue moon, 'object' 
> and 'keyPath' aren't what they're supposed to be, so I super it, and it blows.

> ….
> 
> I will set 'context' and use it in my check instead.
> -Carl

Well you should also figure out why object and keyPath aren’t what they are 
supposed to be, because that’s the actual problem here, just checking the 
context isn’t really going to help you if you are getting notifications for 
keyPath ‘foo’ when you were expecting them for keyPath ‘bar’. You’ll just hide 
the issue until it comes back to bite you another way. If it was a case of 
another KVO up the inheritance chain then it wouldn’t fail if you passed the 
message to super. Cocoa doesn’t just randomly send out notifications to test 
you, they’re coming from somewhere.  

What are object and keyPath which you don’t expect them to be? 

Are you getting the warning anywhere in your debug logs that an object was 
deallocated whilst still having KVO notifications registered on it? That 
explicitly tells you that the KVO notifications can get attached to the wrong 
object. 


___

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: Receiver type for instance message is a forward declaration

[Roland King]

> On 11 May 2016, at 07:11, Jens Alfke  wrote:
> 
> 
>> On May 10, 2016, at 4:05 PM, Carl Hoefs  
>> wrote:
>> 
>> Yes, yes, and yes! I'm using a nil context. I'm not sure how context is to 
>> be used here... Is this an arbitrary value that I check in 
>> -observeValueForKeyPath?
> 
> Yes, but I’m not aware of it being required … what goes wrong if it’s NULL, 
> Quincey?
> 
> —Jens

nothing goes wrong if it’s null, however you can’t tell which observations are 
yours and which belong to one of the other classes in the inheritance chain who 
are also potentially using KVO. 

However lots of people use nil for it and get away with it, but don’t. You will 
one-day handle the KVO notifications for something which isn’t you and starve 
it of doing so. 

Either way - this KVO notification has been passed to the superclass hence the 
exception. I’d doubt it’s because of the context, more likely that he’s 
comparing the notification name string incorrectly and not handling it, or 
handing the KVO and then *still* calling the superclass method. 



___

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: XCode snapshot function?

[Roland King]

> On 10 May 2016, at 09:48, Graham Cox  wrote:
> 
> 
> 
> oookaaayyy…
> 
> So what’s the best way to mothball and archive my project in its current 
> state so I can then fork it for the next version, and so on?
> 
> —Graham
> 
> 

archive the project in xcode (Product .. Archive), add the archive to your 
repository, git commit and tag the lot and push it somewhere remote so when 
your mac goes on fire you have a copy. 


___

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: XCode snapshot function?

[Roland King]

> On 10 May 2016, at 09:21, Graham Cox  wrote:
> 
> Hi,
> 
> Where is the snapshot function in XCode these days (XCode 7.3)?
> 
> I see in the “Projects” window there is a way to export snapshots, but I 
> can’t see anywhere to make a snapshot in the first place.
> 
> —Graham
> 

It isn’t - it was removed with Xcode 7 and never came back. You can restore old 
snapshots from Xcode 6 and prior but not make new ones. 
___

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: How to keep things alive in Arc?

[Roland King]

> On 9 May 2016, at 19:17, Dave  wrote:
> 
> Hi, 
> 
> Well if “thing” is used only within the method you don’t have to do anything 
> - ARC will keep it alive until the local you have assigned it to goes out of 
> scope.

No that’s not true, which is the whole point of the original question. ARC 
*may* keep it alive until the local goes out of scope, but it is also free to 
determine when the variable is last used and free at at any point after that, 
it doesn’t have to wait until the end of the scope. And in release mode, it 
fairly often doesn’t.

Which is why you do have to do something. And the two options are the ‘precise 
lifetime’ which tells ARC explicitly to keep the variable alive through the 
entire scope whether it thinks it’s used or not, or the ‘returns inner pointer’ 
which tells ARC that the result of an earlier call returns something which 
requires the original receiver object to stay alive whilst it’s being used. In 
that case ARC is free to remove both objects after it determines the inner 
pointer one is no-longer used (which again may be before either of them go out 
of scope). 

The usual example of the latter is [ NSData bytes ], you need the NSData object 
to stay alive whilst its bytes are being used, so [ NSData bytes ] is annotated 
to return an inner pointer. 

This is all covered in the clang discussion/documentation which highlights the 
rationale for allowing objects to be destroyed when it determines they are 
no-longer used, but before the end of the scope, and the keywords which 
suppress that behaviour in cases like this. 



___

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: How to keep things alive in Arc?

[Roland King]

> On 9 May 2016, at 10:11, Gerriet M. Denkmann  wrote:
> 
> Thing *aThing = [ Thing new ];
> 
> void *thingData = [ aThing data ];//  pointer to a buffer owned by 
> aThing
> 
> … never use aThing after this point → Arc might release aThing right now
> … but do lots of things with thingData
> 
> … no more need for thingData
> [ aThing release];
> 
> How to prevent Arc to release aThing before I have done with thingData?
> 
> Gerriet.
> 


well [ aThing release ] won’t work in ARC, I assume you really mean aThing = 
nil, or just letting aThing fall out of the bottom of the local scope

either mark [ Thing data ] with NS_RETURNS_INNER_POINTER which is equivalent to 
__attribute__((objc_returns_inner_pointer))

or mark aThing with __attribute__((objc_precise_lifetime))



___

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: Can't make an adaptive segue push

[Roland King]

> On 6 May 2016, at 20:49, Roland King <r...@rols.org> wrote:
> 
> I have a navigation controller as the detail pane of a UISplitView (pretty 
> much right from the standard splitview template). 
> 
> Now I want to push another view onto that stack. I have the view, I’ve 
> dragged out a segue to connect it up however none of the available ‘adaptive 
> segues’ do a ‘push’. Even the ‘Show (Push)’ one doesn’t push, it replaces the 
> view entirely and removes the nav controller. 
> 
> If I use the deprecated ‘push’ segue, then it pushes, but it’s deprecated and 
> gives me a handy yellow triangle warning me of such. 
> 
> Am I falling foul of the splitview controller’s adaptation here somehow? I’m 
> a little hazy on the way adaptive segues work but it feels like the ‘show’ is 
> being sent up to and interpreted by the splitview controller and doing a 
> replace on the detail pane instead of a push. But it could be something 
> entirely different. 
> 
> I could hook the button up to make the new view controller and push it 
> instead of using a segue, but I’d rather not. Is there a way I can make 
> ‘Show’ do a ‘Push’?

As usual, asking the question made me think about it and get the answer. 
Override showDetailViewController:sender: to do the push (or something else if 
appropriate in that adaptation which in this case is always push). If not, the 
targetViewController is found which is the splitview controller which does a 
detail pane replace. 

This stuff sometimes almost makes sense, if you don’t think about it too hard. 


___

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

Can't make an adaptive segue push

[Roland King]

I have a navigation controller as the detail pane of a UISplitView (pretty much 
right from the standard splitview template). 

Now I want to push another view onto that stack. I have the view, I’ve dragged 
out a segue to connect it up however none of the available ‘adaptive segues’ do 
a ‘push’. Even the ‘Show (Push)’ one doesn’t push, it replaces the view 
entirely and removes the nav controller. 

If I use the deprecated ‘push’ segue, then it pushes, but it’s deprecated and 
gives me a handy yellow triangle warning me of such. 

Am I falling foul of the splitview controller’s adaptation here somehow? I’m a 
little hazy on the way adaptive segues work but it feels like the ‘show’ is 
being sent up to and interpreted by the splitview controller and doing a 
replace on the detail pane instead of a push. But it could be something 
entirely different. 

I could hook the button up to make the new view controller and push it instead 
of using a segue, but I’d rather not. Is there a way I can make ‘Show’ do a 
‘Push’?
___

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: Thoughts on autolayout

[Roland King]

I’ve never had to do anything like step 4. I’ve certainly added or changed 
constraints and fetched up a load of red boxes but never does it take more than 
a little bit of consideration to work out which constraints to remove or 
change. 

Basically - it just isn’t that hard. 

> On 22 Apr 2016, at 17:09, Stephane Sudre  wrote:
> 
> I tend to believe that it's because of step 4 that some developers
> (#include me) still do not like auto layout. Because even with a very
> simple view, you can waste a lot of time with this step.
> 
> On Thu, Apr 21, 2016 at 9:49 PM, Bill Cheeseman  wrote:
>> 
>>> On Apr 21, 2016, at 3:19 PM, Charles Srstka  
>>> wrote:
>>> 
>>> Am I the only one who likes autolayout?
>> 
>> 
>> No, I like it, too. I developed an approach that I'm comfortable with, and 
>> if I stick to it I can get the job done quickly. Of course, trying to 
>> accomplish something I haven't done before requires a little more thought, 
>> but I find that I can figure it out pretty quickly. It almost comes natural 
>> now.
>> 
>> I use IB exclusively. My approach goes like this, on a one-window-at-a-time 
>> or one-view-at-a-time basis:
>> 
>> 1. Drag all the views and controls onto the canvas and drop them more or 
>> less where I want them to end up. Don't waste any time trying to align them 
>> or make them the right size exactly -- just get position and size 
>> approximately right and move on. Leave it looking a little ragged. Above 
>> all, don't create any constraints yet.
>> 
>> 2. Write enough of the application code to get a sense whether the layout 
>> needs to be changed. Change it as needed, but again don't waste any time 
>> getting it exactly right and don't create any constraints yet.
>> 
>> 3. When the design feels like its ready to be frozen, create the 
>> constraints. DO NOT move the controls and views into the exact place they 
>> belong and then add constraints -- instead, do it the other way around: 
>> create the constraints first and then tell the controls and views to obey 
>> them. It will be much easier to see that they all moved into the right 
>> place, because they will all move a relatively short distance. More on this 
>> step below.
>> 
>> 4. Every time you tell a window or view to obey new constraints, watch very 
>> carefully. If the controls and views move or resize in unexpected ways, or 
>> disappear completely, immediately choose undo to get back to where you were 
>> (with all the controls and views in approximately the right locations). Then 
>> figure out which constraint you left out or got wrong, and fix it. 
>> Repeatedly undo and fix as needed.
>> 
>> 5. When you think you're done, lock the constraints down and do a lot of 
>> window resizing, divider dragging, and so on to test them.
>> 
>> More on step 3. I create constraints the way I read: start at the top left 
>> corner, move item by item to the right, then move down one "row" and start 
>> at the left again, and so on until I reach the bottom right corner. This 
>> leads to some useful consistencies to help my brain figure out why something 
>> went wrong. (a) For example, it is often only the leftmost button in the top 
>> "row" of controls that needs a top constraint to the superview; the other 
>> buttons in that "row" will have their vertical dimension controlled by 
>> baseline or center alignment, or something similar. (b) Horizontal 
>> constraints are easily made complete, because I account for each piece one 
>> step at a time from left to right: leading constraint, width constraint, 
>> trailing constraint, etc. (c) I don't worry about hugging priorities and the 
>> like until all else fails, because the default priorities are designed to be 
>> right for most situations.
>> 
>> --
>> 
>> Bill Cheeseman - wjcheese...@comcast.net
>> 
>> ___
>> 
>> 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/dev.iceberg%40gmail.com
>> 
>> This email sent to dev.iceb...@gmail.com
> 
> 
> 
> -- 
> Packaging Resources - http://s.sudre.free.fr/Packaging.html
> 
> ___
> 
> 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/rols%40rols.org
> 
> This email sent to r...@rols.org


___

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 

Re: Thoughts on autolayout

[Roland King]

> On 22 Apr 2016, at 03:34, Hunter Hillegas  wrote:
> 
> Nope, I’m a huge fan, especially with newer tools like UIStackView and the 
> layout guide stuff.
> 
>> On Apr 21, 2016, at 12:19 PM, Charles Srstka  
>> wrote:
>> 
>> Am I the only one who likes autolayout?
> 
> 

I also like autolayout. Always loved the theory and the layout engine, thinking 
about UI in terms of constraints I thinks is very natural. 

The initial implementation in IB was atrocious because it tried to guess what 
you wanted to do and keep the layout satisfied at all times, which meant a 1px 
move destroyed 10 minutes of work. The current implementation strikes the right 
balance for me, add the stuff and constraints you want, look at any warnings 
you get, fix them. You can exercise the interface quickly in the preview pane, 
you can leave constraints off bits you don’t care about yet and come back to 
them later. The trait-specific bits, where you can install constraints or even 
whole views automatically as traits change has let me remove chunks of code 
messing with constraints in code, now I can just bang through a few iterations 
of a view design in one place in IB in a few minutes, ‘test’ it on various 
devices in all orientations without writing a line of code. 

For me AL in the current iteration in IB is a huge time saver and I wouldn’t 
want to go back. 
___

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: Text field alignment

[Roland King]

> On 21 Apr 2016, at 11:13, Quincey Morris 
>  wrote:
> 
> I’m laying out some views (using auto-layout, though I don’t think that’s the 
> cause of the problem) on OS X 10.11.4 with Xcode 7.3. In many cases, I’m 
> baseline-aligning a pair of text fields, one label and one editable. The font 
> is the default (System-Regular, i.e. 13 pt) and the text field heights are 
> default too.
> 
> Unfortunately, the label and the text field are not baseline aligned, but the 
> text field contents are one point too low. It looks wrong, too, because it’s 
> too close to the bottom of the enclosing box, and when selected there is more 
> highlighted empty space above the text than below.
> 
> I can sort of fix it by playing around with the text field heights and/or 
> offsetting the constraints, but I don’t really want to because it seems like 
> a mistake to design for this particular quirk.
> 
> Has anyone else run into this, or got any suggestions about what (if 
> anything) to do about it?
> 

Yes  - I believe your options, as well as filing a bug are

1) turn the border off on the textfield (I can hardly notice the difference 
myself and this also puts the highlight properly inside the space in the box.

or

2) adjust the baseline alignment constraint constant to 1, or -1, depending on 
which field is first in your constraint. 

I’m fairly sure the NSTextField doesn’t properly take account of the border 
when aligning baselines. 
___

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: NSSplitview and NSTableview

[Roland King]

> On 21 Mar 2016, at 12:05, yu...@aim.com wrote:
> 
> Hi,
> I spent sometime on this strange issue but still could not figure out.  I 
> hope i could get some help from the group.
> 
> 
> I have a NSScrollView which contains an NSSplitView; the splitView contains 
> four panes;  each pane is a NSTableView with just one row of text;
> After i added the last table view to the splitView,  i scrolled the 
> NSScrollView programmatically by the scrollView content frame size like the 
> following:
> 
> [_myScrollView contentView].frame.size.width;
> 
> 
> However, the data in the last table view does not appear until 8 seconds 
> later;  strange thing is if i clicked on its neighbor view on its left, the 
> data comes up right away.
> 
> 
> The 8 seconds delay is very puzzling and i am not sure what area i should 
> look into;  seems like the delegate on the last table view is not called 
> until 8 seconds later.
> 
> 

Did you scroll on the main thread? The delay sounds like exactly what you get 
when you do UI operations on a background thread. 
___

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: UIStackView full of labels doesn't add up

[Roland King]

> On 20 Mar 2016, at 22:52, Ken Thomases <k...@codeweavers.com> wrote:
> 
> On Mar 20, 2016, at 7:57 AM, Roland King <r...@rols.org> wrote:
>> 
>> I have a UIStackView, vertical, set to ‘fill equally’ with a number of 
>> UILabels in it. The stackview in this instance happens to be 300pts high. If 
>> I put 1 UILabel in it, the UILabel is 300pts high. This is what I would 
>> expect. 
>> 
>> If I put two in it, the stackview sets them both 160pts high (total 320), 
>> three, they’re 113pts high (total 330) , four, 90pts high (total 360). None 
>> of those add up to 300 so the labels are not properly spaced out and don’t 
>> line up correctly with other groups of views which are next to them.
> 
> What are you using to measure the label heights?  Are you looking at the 
> frame or the alignment rect (i.e. applying -alignmentRectForFrame: to the 
> frame)?  Anything using auto layout, such as UIStackView, will use the 
> alignment rect.  The alignment rect may very well be inset from the frame so 
> that if you (or UIStackView) makes two labels abut according to their 
> alignment rects, their frames may actually overlap.
> 
> Also, have you set the stack view's baselineRelativeArrangement or spacing 
> properties?
> 
> Regards,
> Ken
> 

Using the frame - however if I change IB to show alignment rect, I get the same 
dimensions, although that may be IB lying to me. I’ve tried setting the layout 
margins on the UILabels to zero, that didn’t make a difference.  There’s no 
baselineRelativeArrangement or spacing properties set on the stack view either. 
I would expect if it were alignment rect then the frames would overlap (they 
do) but I would also expect the frames all to be offset by the same amount from 
the top edge. What actually happens is the topmost label’s top edge is flush to 
the top edge of the stack, the bottom label’s bottom edge is flush to the 
bottom edge of the stack. Since they are all a little too high, that means the 
top label’s text is about 8 pixels low, the bottom one’s is 8px high and the 
label in the middle is correct. When you add enough of them, the effect is 
disturbingly obvious. 

I’ll stick with the label in a view code which seems to work and I can even 
then align either the label center or baseline to the center of the view, 
haven’t decided which looks nicer yet. 
___

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

UIStackView full of labels doesn't add up

[Roland King]

I have a UIStackView, vertical, set to ‘fill equally’ with a number of UILabels 
in it. The stackview in this instance happens to be 300pts high. If I put 1 
UILabel in it, the UILabel is 300pts high. This is what I would expect. 

If I put two in it, the stackview sets them both 160pts high (total 320), 
three, they’re 113pts high (total 330) , four, 90pts high (total 360). None of 
those add up to 300 so the labels are not properly spaced out and don’t line up 
correctly with other groups of views which are next to them.

If I just put UIViews in the stackview it works as I’d expect, 2@150, 3@100, 
4@75 .. etc and they fill in the way I would expect. 

Is there an obvious reason why UIStackView ‘equally fills’ UILabels so the 
total height is more than the height of the stackview and they misalign 
themselves by a number of points? 

I’m working around it by filling the stackview full of UIViews and then pinning 
a label inside each UIView, but that’s really sad. 
___

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: Safe cross references between scenes in an OS X storyboard

[Roland King]

> On 9 Mar 2016, at 21:32, Bill Cheeseman  wrote:
> 
> I am using storyboards in an OS X application written in Swift 2. It is a 
> single window "shoebox" application that does not use NSDocument or Core 
> Data. It is built with the Xcode 7.2.1 storyboard template, where the 
> storyboard entry point is the main window controller scene and a "window 
> content" relationship segue leads to the window's content view scene.
> 
> In my AppDelegate class, I want to declare an instance property referring to 
> the main window's content view controller. I need to refer to the content 
> view controller because my AppDelegate provides programmatic content for one 
> of the menu bar's menus and it needs to update a duplicate of that menu in a 
> popup button in the content view. I anticipate needing a reference to the 
> content view controller for other purposes, too, so I want to avoid 
> duplicating code by putting it in an instance variable.
> 
> It is of course impossible to set the property's value before the window's 
> content view controller exists. The applicationDidFinishLaunching(_:) 
> delegate method is apparently too early. If I set it there with 
> 'mainContentViewController = NSApp.mainWindow!.contentViewController as! 
> MainContentViewController', I get this fatal error at launch: "unexpectedly 
> found nil while unwrapping an Optional value."
> 
> I therefore set it using a lazy instance variable, like this:
> 
>lazy var mainContentViewController: MainContentViewController = {
>NSApp.mainWindow!.contentViewController as! MainContentViewController
>}()
> 
> This works fine -- but only if I take care to use the instance variable after 
> the content view controller becomes available. My question is whether the 
> following is a safe and sensible way to take care of the possibility that I 
> might accidentally try to use it too early:
> 
>lazy var mainContentViewController: MainContentViewController? = {
>guard let window = NSApp.mainWindow,
>let controller = window.contentViewController
>else {return nil}
>return controller as? MainContentViewController
>}()
> 
> (I tried returning 'controller as! MainContentViewController', but I got this 
> warning: "Treating a forced downcast to 'MainContentViewController' as 
> optional will never produce 'nil'." I have to declare the variable as an 
> Optional type because the guard statement might return nil.)
> 
> — 


just

return NSApp.mainWIndow?.contentViewController as? 
MainContentViewController

works without all the guard and intermediate variables and still returns the 
same optional. 


___

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: Can an NSArray ever have a count of -1?

[Roland King]

> On 20 Feb 2016, at 14:14, Gerriet M. Denkmann  wrote:
> 
> 
>> On 20 Feb 2016, at 13:02, Quincey Morris 
>>  wrote:
>> 
>> On Feb 19, 2016, at 21:30 , Gerriet M. Denkmann  wrote:
>> 
>> Now that I code almost exclusively in Swift, the problem has largely 
>> disappeared, because ‘“\(someValue)"' is a lot easier*** than ‘[NSString 
>> stringWithFormat: "%lu", (someCast) someValue]’.
> 
> Is there (yet) a Swift version of ‘[NSString stringWithFormat: “%08lx”, 
> (someCast) someValue]’ ?
> Last time I checked, this was the only way to print formatted strings.
> 
> Kind regards,

var str = String( format: "%08lx", 123 )
___

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: calendar & repeating events api

[Roland King]

> On 17 Feb 2016, at 10:34, Eric Gorr  wrote:
> 
> When setting up a repeating event in Apple’s Calendar application, there is a 
> lot of flexibility. For example, I can specify that an event repeats every 
> month on the 5th Saturday. Of course, not every month has a fifth saturday, 
> so for that month there is no event.
> 
> What I am wondering is if there is direct api support for doing these date 
> calculations…can I supply a set of parameters to a function and ask what the 
> next 5th saturday of the month is?
> 
> I can, of course, implement a naive algorithm which simply iterates through 
> each day of the month, checks to see if it is the 5th Saturday encountered 
> and return that date, but I am hoping I would not need to write something so 
> tedious and prone to error. If there is a 3rd party library that would 
> provide such support, I would be interested in learning about it as well.
> 
> Thank you.

See NSCalendar - that does every type of date calculation you could think of 
and then some, and it’s all tested and maintained by someone else and knows all 
about every wrinkle in calendars known to man. 
___

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: PSA: Does your app use Sparkle? Update it, or use an HTTPS server

[Roland King]

> On 12 Feb 2016, at 17:14, sqwarqDev  wrote:
> 
> What I “think” (...read: “hope", cos I really need to be getting on with 
> other stuff, like updating the Sparkle version in my own apps…) is my final 
> version of the script to check for vulnerable Sparkle frameworks and 
> prefPanes (system wide, including backups if connected):
> 
> Script version 1.6:
> 
> http://applehelpwriter.com/2016/02/10/how-to-check-for-sparkle-vulnerability/
> 
> A great deal of excellent contributions have been made by folks over on the 
> AppleScript Users list and it is by no means solely my own work.
> 
> 
> 
> Best


That script reports things which use HTTP even if they are using a version of 
Sparkle > 1.13, even though that is one of the requirements in your list at the 
top. eg I’ve updated Hopper and VLC

> pwd
/Applications/Hopper Disassembler 
v3.app/Contents/Frameworks/Sparkle.framework/Resources

> less Info.plist 

…

CFBundleVersion
1.13.1

…

So Hopper according to me should be fine - but it shows in the list. 


___

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: PSA: Does your app use Sparkle? Update it, or use an HTTPS server

[Roland King]

> On 10 Feb 2016, at 13:45, sqwarqDev  wrote:
> 
> 
>> On 10 Feb 2016, at 09:08, Charles Srstka  wrote:
>> 
>> If your app is accessing your appcast via HTTP, that could be intercepted 
>> just the same as your relnotes, and then the attacker could set the relnotes 
>> URL to whatever s/he wants.
> 
> 
> Can I just double-check my understanding here:
> 
> 1. If the SUFeedURL uses https, the app is not vulnerable.
> 
> 2. If 1 is true, neither of these matter:
>   2.1 the version of Sparkle
>   2.2 whether the release notes are http or https
> 
> 

1. true

2. By my reading, not true. if the app notes are http then they can be spoofed 
and inject javascript via the webkit widget to run nefarious code. 

Making both https works as neither can be spoofed, upgrading sparkle fixes the 
issue even if the notes are not https. Until someone finds the next exploit, 
thus meaning all https all the time is a better way to go. 


___

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: Trying to understand a permissions failure when writing to ~/Desktop

[Roland King]

> On 28 Jan 2016, at 13:36, Graham Cox  wrote:
> 
> 
>> On 28 Jan 2016, at 3:07 PM, Kyle Sluder  wrote:
>> 
>> Any app on OS X can open documents from iCloud Drive—the user just has
>> to navigate to iCloud Drive in Finder.
>> 
> 
> 
> Well anyway, it was a red herring - has nothing to do with my problem.
> 
> 
> Why would the OS think an app was sandboxed when it has no resources 
> indicating that it is? Does the OS cache info anywhere about this? The app 
> *has* been sandboxed in the past during development, so wondering if there’s 
> some info cached somewhere that needs clearing?
> 
> —Graham


Have a different box you never installed it on before you can test that theory 
out on? 
___

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: Trying to understand a permissions failure when writing to ~/Desktop

[Roland King]

From the original mail

"Note this isn’t a sandboxed app, so that shouldn’t come into it.”


> On 28 Jan 2016, at 10:51, Alex Zavatone  wrote:
> 
> According to the sandboxing docs, I recall that for sandboxing, there are a 
> certain set of locations where you can save files to without requiring user 
> permission.  Your ~/Documents folder is one of them. IIRC, all other 
> locations require user confirmation to save the files.
> 
> Try saving to the docs folder and/or trying writing to the desktop with 
> sandboxing disabled.
> 
> On Jan 27, 2016, at 8:42 PM, Graham Cox  wrote:
> 
>> I use -[NSData writeToURL:options:error] to write data to files in a 
>> location generally chosen by the user. That works fine.
>> 
>> The default location is ~/Desktop, if the user fails to choose anything, or 
>> if the bookmark of the previously chosen location fails to resolve. However, 
>> when I try to write the file I get an error 513, ‘you don’t have 
>> permission’, underlying error 1, operation not permitted’. If the user 
>> chooses the Desktop themselves using the Open panel, it works fine.
>> 
>> The ~/Desktop permissions seem to be OK - I have readwrite permission on 
>> that folder.
>> 
>> So something is weird about the URL for ~/Desktop when I create it 
>> programatically as opposed to what NSOpenPanel returns. Note this isn’t a 
>> sandboxed app, so that shouldn’t come into it.
>> 
>> I create the default URL thusly:
>> 
>>  NSURL* desktopURL = [[NSFileManager defaultManager] 
>> URLForDirectory:NSDesktopDirectory inDomain:NSUserDomainMask 
>> appropriateForURL:nil create:YES error:];
>> 
>> 
>> I can’t see any obvious difference between the URL here and the one I get 
>> from NSOpenPanel, but there must be one.
>> 
>> 
>> Any ideas what the problem could be here?
>> 
>> —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/zav%40mac.com
>> 
>> This email sent to z...@mac.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/rols%40rols.org
> 
> This email sent to r...@rols.org

___

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: Trying to understand a permissions failure when writing to ~/Desktop

[Roland King]

have you checked your info.plist file just to be certain damned sure Xcode 
hasn’t slipped in something nasty whilst you weren’t looking? I’d actually look 
at the one in the app bundle you’re running  because I’m paranoid like that. 



> On 28 Jan 2016, at 11:17, Graham Cox <graham@bigpond.com> wrote:
> 
> I did say that, and the app definitely isn’t sandboxed (it’s running from 
> Xcode also). However, I just noticed that I get this in the log when the app 
> receives the error:
> 
> 
> 28/01/2016 12:26:35.124 PM sandboxd[127]: ([19475]) MyApp(19475) deny 
> file-write-create /Users/grahamcox/Desktop/Untitled_0001.png
> 
> 
> So for some reason the sandboxd process is rejecting the file write even 
> though the app isn’t sandboxed! 
> 
> The full report stack trace shows the expected thing (some details not 
> included):
> 
> Version: 2B06 (2.0)
> Code Type:   x86_64 (Native)
> Parent Process:  debugserver [19476]
> 
> Date/Time:   2016-01-28 12:26:34.941 +1100
> OS Version:  Mac OS X 10.11.3 (15D21)
> Report Version:  8
> 
> Thread 0:
> 0   libsystem_kernel.dylib0x7fff92ea6116 __rename + 10
> 1   Foundation0x7fff8ab056cd 
> _NSWriteDataToFileWithExtendedAttributes + 855
> 2   Foundation0x7fff8ab32ae6 -[NSData(NSData) 
> writeToURL:options:error:] + 254
> 3   MyApp 0x0001000f028f 
> -[MDABExportOperation writeToFiles:] + 1055 (MDABExportController.m:965)
> 4   MyApp 0x0001000eb511 
> __65-[MDABExportController 
> beginSheetExportOperation:onParentWindow:]_block_invoke + 449 
> (MDABExportController.m:104)
> 
> 
> 
> Sandboxing issues are bad enough to deal with, but when they bleed over into 
> ‘open’ apps that’s just nasty.
> 
> 
> —Graham
> 
> 
> 
> 
> 
> 
> 
>> On 28 Jan 2016, at 2:05 PM, Alex Zavatone <z...@mac.com> wrote:
>> 
>> Sorry man.  It’s been a long long day.
>> 
>> On Jan 27, 2016, at 9:54 PM, Roland King <r...@rols.org> wrote:
>> 
>>> From the original mail
>>> 
>>> "Note this isn’t a sandboxed app, so that shouldn’t come into it.”
>>> 
>>> 
>>>> On 28 Jan 2016, at 10:51, Alex Zavatone <z...@mac.com> wrote:
>>>> 
>>>> According to the sandboxing docs, I recall that for sandboxing, there are 
>>>> a certain set of locations where you can save files to without requiring 
>>>> user permission.  Your ~/Documents folder is one of them. IIRC, all other 
>>>> locations require user confirmation to save the files.
> 


___

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: Array of Dictionaries as .userInfo

[Roland King]

> On 26 Jan 2016, at 23:12, Eric E. Dolecki  wrote:
> 
> I have a control which takes an array of dictionaries to construct it's UI
> (as a distinct method).
> 
> Now I'd like to add a notification to supply the data as well. I'd like to
> pass the data as userInfo.
> 
> When constructing the observer method, how do I constuct?
> 
> func weHaveData(notification:NSNoticiation){
>   let dict = notification.userInfo as Array>
>   control.loadData(dict)
> }
> 
> *Can't convert value of type [NSObject:AnyObject]? to
> Array> in coercion*
> 
> I've tried without the cast. Is there an easy work around?
> ___


the userInfo of an NSNotification is an NSDictionary, so of course you can’t 
cast it to an Array. There’s no workaround, they aren’t the same thing at all. 

If you want to pass an Array of Dictionaries in the userInfo, you need to put 
it in the userInfo *dictionary* under a key, then retrieve it, then cast it. 
___

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: Screen <--> View Coordinate system conversion

[Roland King]

> On 16 Jan 2016, at 12:27, Graham Cox  wrote:
> 
> 
> summary: view -> window -> screen -> window -> view
> 
> 
> Tried this and many variants of it, nothing works - the coordinates I end up 
> with are not in the visible part of my overlay so don’t appear.
> 
> 
> A better solution (i.e. less work) but one that needs a similar approach in 
> terms of conversion is to align the coordinate system of the overlay to that 
> of the original view. I’ve tried this by using the original view’s bounds as 
> a rectangle passed through the above coordinate conversion, and used to set 
> up a transform on the overlay view as part of its -drawRect, before it draws 
> anything. In theory this should allow me to pass coordinates directly from 
> the original view unchanged, and have them draw in the overlay in the exact 
> same place on the screen. Trouble is, I just can’t get that to work.
> 
> I’m missing something about how to correctly translate coordinates between 
> two separate windows.
> 
> If anyone can spell it out step by step that would be great - I just can’t 
> see where my thinking is faulty.
> 
> —Graham
> 

Do you need to go via the backing store? NSView has a convertRect:toView: 
which, when passed nil for the view, then you get screen coordinates from the 
window, then reverse. Remember if you’re using the frame of the view, you want 
to use the superview to convert it, as frames are in superview coordinates. 

Do you have an example going through the chain of views of converted 
coordinates so we can see if we can figure out where it’s going wrong? 
___

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

[Roland King]

> On 2 Jan 2016, at 10:14, SevenBits  wrote:
> 
> Hi list,
> 
> Xcode has decided not to cooperate with me.
> 
> My latest app is crashing constantly when I launch it. It crashes 
> immediately, without showing any UI or starting the app delegate, so I know 
> that my code isn’t the cause. The app will be able to run 3 or 4 times before 
> this happens. This did not happen before I started accessing, and writing to, 
> my app’s Application Support directory.
> 
> The app is sandboxed, destined for the MAS, and is using ARC. Deleting my 
> app’s sandbox container fixes the problem, until it tries to write to the 
> Application Support directory and the cycle starts all over.
> 
> Does anyone have any pointers? Seen this before?
> 
> Thanks in advance.
> ___

crash report? stack trace? Anything from any of the logfiles in /var/log. If 
it’s crashing it’s dumping a crash report somewhere. Without that it’s just 
guesswork. 
___

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

[Roland King]

> On 2 Jan 2016, at 10:26, SevenBits  wrote:
> 
> OS X.
> 
> Sorry, it’s been a frustrating process.
> 
> I’m working on gathering the other info; in the meantime, here’s a screenshot 
> from Xcode at the moment that crash happens: http://i.imgur.com/i7qsNOQ.png?1
> 

Looks more like an uncaught exception showing at the top level. Do you have the 
breakpoint for ‘All Exceptions’ set so you can see where it is? 

Or temporarily wrap that call in a try/catch to catch it. 
___

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

[Roland King]

> On 2 Jan 2016, at 10:54, SevenBits  wrote:
> 
> Okay, I reproduced the error. Setting an exception breakpoint didn’t help; 
> the app crashes anyway, leading me to believe that the problem either a) is 
> not an uncaught exception or b) it is an exception, but occurs before the 
> ObjC runtime is initialized.
> 
> I’ve run the app outside of Xcode and got the following crash report:
> 
> https://gist.github.com/SevenBits/dfff392c19f0332d81ef
> 

well it’s not a) because it is an uncaught exception, you can see that because 
it has the word exception all over the crash logs and it’s not been caught
and b) is meaningless

So what do you know - that it’s sending respondsToSelector() to something which 
isn’t an object. So usual things, turn on NSZombies, turn on the address 
sanitizer, whatever else you can find on that options page which looks handy. 
Address sanitizer is new, I haven’t used it, but I’ve heard wonderful things 
about it. GuardMalloc too if you like. The crash is so early you may as well 
just turn on the lot. 

I’d also try stuffing it through instruments to see if I can work out which 
bits of my code have already been run by the time it gets here. It’s unpacked 
the NIB, made windows, views too, so it’s run some stuff. 

Start with those. You could breakpoint in NSApplication updateWindows and poke 
around your threads see what else may be going on, not sure I’d go right there 
however. Would be interesting to see what selector it’s asking something 
whether it responds to. 




___

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: App refuses to launch after adding iCloud Drive support

[Roland King]

‘Developer ID’ doesn’t sound right. Developer ID is for signing apps for 
non-mac-store distribution, and I never worked out why there’s one for apps and 
one for installers. If you want to distribute a test copy of the app you need 
to sign it with the Mac developer certificate using a provisioning profile 
which contains the device which is going to run it. The Mac Distribution 
certificate is for signing apps to send to the App Store where they get 
re-signed for distribution to the world. 

iOS compilicates it more by having development and ad-hoc distribution profiles 
which appear to do mostly the same thing. 

Didn’t know that the thing would crash however, I would have just expected it 
to refuse access to iCloud drive. 


> On 1 Jan 2016, at 08:22, Graham Cox  wrote:
> 
> I’m working on adding iCloud Drive support to my app. When running from 
> Xcode, it all seemed to be working, but when I archived the app, Exported a 
> Developer ID signed copy, it refuses to launch:
> 
> Crashed Thread:0
> 
> Exception Type:EXC_CRASH (Code Signature Invalid)
> Exception Codes:   0x, 0x
> Exception Note:EXC_CORPSE_NOTIFY
> 
> Turning off the iCloud entitlment it launches normally.
> 
> When setting up the iCloud drive support I used the same Developer ID, so I 
> don’t know what the problem is.
> 
> Anyone know what’s going on here? Code signing issues are always a problem 
> when they arise because it’s such an opaque procedure which supposedly “just 
> works” in Xcode. Except when it doesn’t.
> 
> —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/rols%40rols.org
> 
> This email sent to r...@rols.org


___

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: App refuses to launch after adding iCloud Drive support

[Roland King]

> On 1 Jan 2016, at 09:05, Graham Cox <graham@bigpond.com> wrote:
> 
> 
>> On 1 Jan 2016, at 11:54 AM, Roland King <r...@rols.org> wrote:
>> 
>> Developer ID’ doesn’t sound right. Developer ID is for signing apps for 
>> non-mac-store distribution,
> 
> 
> That’s exactly what I want to do.
> 
> 
>> If you want to distribute a test copy of the app you need to sign it with 
>> the Mac developer certificate using a provisioning profile which contains 
>> the device which is going to run it.
> 
> 
> I have no idea what device is going to run it. The app is a private copy for 
> testing, but by others, not by me. I usually handle this by simply signing it 
> with a Developer ID. That stops the testers getting the Gatekeeper warning, 
> but otherwise doesn’t put any special requirements on them. They can also 
> verify that the app is signed by the expected developer.
> 
> 
>> The Mac Distribution certificate is for signing apps to send to the App 
>> Store where they get re-signed for distribution to the world. 
> 
> 
> At the stage the app isn’t destined for the App Store.
> 
> 
>> Didn’t know that the thing would crash however
> 
> Yes, I’ve never seen this behaviour before either. I don’t really get it - 
> the iCloud signatures appear to match the Developer ID. Perhaps iCloud Drive 
> is simply unavailable to non App Store apps? If so it’s not very friendly 
> about saying so, and also makes it difficult to test the functionality. The 
> app will go in the App Store eventually, but our testing procedures are far 
> smoother at this stage (beta) without bringing that into it.
> 
> —Graham
> 
> 

See if you can make head or tail of this table

https://developer.apple.com/library/mac/documentation/IDEs/Conceptual/AppDistributionGuide/SupportedCapabilities/SupportedCapabilities.html#//apple_ref/doc/uid/TP40012582-CH38-SW1
 
<https://developer.apple.com/library/mac/documentation/IDEs/Conceptual/AppDistributionGuide/SupportedCapabilities/SupportedCapabilities.html#//apple_ref/doc/uid/TP40012582-CH38-SW1>

That tells you what you can and can’t do with different types of ID. However I 
don’t understand the difference between the filled an unfilled circles. eg take 
iCloud Documents row under the ‘Mac Developer ID’ certificate, which is 
probably what you want. It’s there, so it should be available. The circle is 
filled however and the note at the bottom says

Requires an Apple ID associated with an Apple Developer Program membership. For 
Mac apps, the signing identity must be set to Mac App Store.

But hold on, if the signing identity is set to Mac App Store, why is it in a 
column where the signing identity is Mac Developer ID? 

I’ve read it several times now and I’m still confused. Possible that you select 
Mac App Store in one place and Mac Developer ID in a different place and 
somehow that combination works to do what you want. 

I also thought that the non developer program support IDs which were introduced 
in Xcode 7, meaning you didn’t have to buy the membership every year, didn’t 
have access to iCloud however looking at the lefthand column of that table, the 
icons are unfilled which to me would mean I can use iCloud using a ‘free’ 
account, for my own purposes. 

And finally see the note at the very bottom telling you how to use iCloud Drive 
in 10.11 without needing an iCloud entitlement at all. 

I think this is now officially more complicated than it needed to be.



___

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: Custom UIViewController transitions with segues

[Roland King]

> On 31 Dec 2015, at 09:12, Rick Mann  wrote:
> 
> I have a UICollectionView in a UINavigationController, and I'd like to 
> customize the transition from one to the next on push. So I set up the first 
> VC as UIViewControllerTransitioningDelegate, and in 
> prepareForSegue(_:sender:) set the destination VC's transitioningDelegate to 
> self.
> 
> But my delegate methods never get called. The docs say to set 
> modalPresentationStyle to .Custom, but that has no effect (also, it's a bit 
> weird since this is not technically a modal presentation, is it?).
> 
> Search for solutions online turns up only custom segues, which is not really 
> what I want.
> 
> Is it even possible to do this with segues? What am I missing?
> 
> TIA,

My thought here is that push != present, ie pushViewController(_:animated) 
doesn’t do the same thing as presentViewController(_:animated:completion) and 
that push calls the former and other modes call the latter. I dunno what I’d 
try, the whole UIViewController custom transitioning thing confuses the bananas 
out of me and I never found the WWDC videos on them to be as helpful as I 
wished. Perhaps change the push to a present to get it on the screen, then when 
you’re done with the transition, call pushViewController( vc, animated : false 
) to fix up the nav stack. That will probably look really ugly as the nav bar 
will likely just snap to the new content. 

There’s probably 18 other ways to do it. I’d bung some hooks into any methods I 
could find which run early in the viewcontroller presentation lifecycle and see 
if there’s a transition coordinator or animation coordinator or whatever 
objects transitions create which I could hook into and animate alongside. 

In general .. having fiddled with custom transitions when the were new and 
shiny .. I don’t bother with them any more.  



___

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: Getting the final value from an NSSlider drag

[Roland King]

> 
> If you want to know when the last value is sent during mouse tracking, set 
> the ‘actionOn’ property to mouse-up.
> 
> So, something like this:
> 
> - (void)viewDidLoad
> {
>[super viewDidLoad];
> 
>self.slider.action = @selector(valueChangedFinally:);
>self.slider.target = self;
>[self.slider sendActionOn:NSLeftMouseUpMask];
> }
> 
> - (IBAction)valueChangedFinally:(id)sender
> {
>NSLog(@“Here is the final slider value upon mouse up:%@", [sender 
> stringValue]);
> }
> 
> Presumably the other bindings/etc. code would still work to update your 
> real-time display.
> 
> Doug Hill

No they don’t - changing that to to NSLeftMouseUpMask has a similar effect to 
turning off ‘continuous’, all clients get one event, at the end, so the live 
updating realtime display doesn’t work. 

___

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: Getting the final value from an NSSlider drag

[Roland King]

> On 30 Dec 2015, at 05:53, Lee Ann Rucker  wrote:
> 
> 
>> 
> 
> 
> Actually it's easy. For very similar reasons I needed the same behavior - 
> live update of the slider's temp value for UI elements, but only call the 
> final setter when the user is done. I subclassed NSSlider's keyUp: and 
> keyDown: to call super and then call my own delegate method 
> "sliderDidEndUpdate:"
> 

Never drove a slider with the keyboard before, so I added a keyDown and keyUp 
method to the  mouseDown: one I posted earlier, with a bit of code to try and 
be smart about when to send updates, so you don’t get them if you’re just 
tabbing though. Seems to work well enough for this use-case, keyboard and 
mouse, live update on the screen, one update at the end, 15 lines of code and 
no need to artificially compress the events. 
___

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: Getting the final value from an NSSlider drag

[Roland King]

>> 
>> Never drove a slider with the keyboard before, so I added a keyDown and 
>> keyUp method to the  mouseDown: one I posted earlier, with a bit of code to 
>> try and be smart about when to send updates, so you don’t get them if you’re 
>> just tabbing though. Seems to work well enough for this use-case, keyboard 
>> and mouse, live update on the screen, one update at the end, 15 lines of 
>> code and no need to artificially compress the events.
> 
> Whoops, how did I not notice that - it should've been keyUp and mouseDown! 
> You don't need keyDown because nothing changes until keyUp, but mouseDown 
> won't return until the mouse goes up.

You don’t indeed - however if you add keyDown: as well and capture the current 
value (if you don’t already have one captured) you can decide whether anything 
actually changed on keyUp: or not. That avoids a spurious callback when you 
just tab through the field. Not that it matters in this implementation but it 
was easy to do. 

Ok enough GUI fun, I better go write the actual bluetooth bit now
___

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

Getting the final value from an NSSlider drag

[Roland King]

I have some NSSliders hooked up on my UI to text fields with formatters, all 
set up with bindings so that the label shows the slider value. The sliders are 
continuous, looks fine, nice feedback for whoever’s driving. 

However I want to capture, in the app, the value of the slider only at the end 
when the mouse goes up, once. That value ends up being sent out over bluetooth, 
and I really don’t want to send 100 float values a second, when only the last 
one matters anyway. Probably just trying would cause bad things to happen. 

I’m used to UIKit which has the alternate form of action handling method which 
gives you the event, but AppKit doesn’t have that unfortunately. 

I can’t capture mouseDown and mouseUp because the control gets them

I tried a NSEvent.addLocalMonitorForEventsMatchingMask() but that doesn’t 
capture events inside tracking loops, so I get the mouse down, and that’s it, 
the slider eats the rest, which doesn’t help. 

In the action handing code, which gets called all the time, I can call 
NSEvent.pressedMouseButtons() and that does appear to work and let me find the 
final value. I didn’t get great comfort from the documentation that this is 
reliable however. 

I can subclass NSSlider or possibly NSSliderCell but that sounds like a whole 
world of pain, if I have to do that I’ll probably just put a coalescing delay 
into the whole thing which waits 1/2 second after an update before it actually 
does the update. 

Any good ways to do this? 
___

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: Getting the final value from an NSSlider drag

[Roland King]

> On 29 Dec 2015, at 17:40, Quincey Morris 
> <quinceymor...@rivergatesoftware.com> wrote:
> 
> On Dec 29, 2015, at 00:44 , Roland King <r...@rols.org 
> <mailto:r...@rols.org>> wrote:
>> 
>> I want to capture, in the app, the value of the slider only at the end when 
>> the mouse goes up, once
> 
> Isn’t that what the NSControl property continuous==false is for?

But as I said in the post - the slider is hooked up via bindings in the UI to a 
label which shows the value *as you slide it*, so it needs to be continuous for 
that purpose. Then when you let go, only then do I want the final value to be 
delivered to the app. 

were it simply a matter of turning continuous off I wouldn’t have had a 
problem. 

Surprisingly enough the thing I assumed would be the hardest, turned out to be 
the easiest, mouseDown is documented to start a local event loop capture and it 
doesn’t return until it’s all over .. so it just took this. 

import Cocoa

public protocol RKEndValueSliderTarget : NSObjectProtocol
{
func sliderValueChangeEnded( slider : NSSlider )
}

public class RKEndValueSlider: NSSlider
{
public var endValueReceiver : RKEndValueSliderTarget?

public override func mouseDown( theEvent : NSEvent )
{
super.mouseDown( theEvent )
endValueReceiver?.sliderValueChangeEnded( self )
}
}

___

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: Getting the final value from an NSSlider drag

[Roland King]

> On 29 Dec 2015, at 17:54, Quincey Morris 
> <quinceymor...@rivergatesoftware.com> wrote:
> 
> On Dec 29, 2015, at 01:45 , Roland King <r...@rols.org 
> <mailto:r...@rols.org>> wrote:
>> 
>> the slider is hooked up via bindings in the UI to a label which shows the 
>> value *as you slide it*, so it needs to be continuous for that purpose. Then 
>> when you let go, only then do I want the final value to be delivered to the 
>> app
> 
> Yeah, I realized a minute later that you wanted *both* behaviors.
> 
> The other way you can approach something like this (though what you did is 
> more direct in this case) is to start a timer. The timer won’t actually run 
> in event loop tracking mode, so you can use time expiry as an indication that 
> the tracking is done. Something like that.
> 
> 

That’s really sneaky - I love it. I’m pleased there was a more direct way of 
attacking it in the end however, I may not have slept well for a week after 
using a timer for that, but it’s great idea. 
___

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: My alert is not firing at all

[Roland King]

What do you mean by it doesn’t fire? It doesn’t show the alert, or it doesn’t 
do anything after it shows the alert when you hit the dismiss button? 

I wrote code very similar to this today .. with an extra button or two, and it 
was fine. 

> On 26 Dec 2015, at 19:40, Scott Berry  wrote:
> 
>   Hello there,
> 
> Here is the code I wrote to fire off my alert but when I run the program on 
> the device the alert doesn’t want to fire so I am wondering what I have done 
> wrong.  I use Voiceover.
> 
> // Alert Message for first load.
>@IBAction func buttonTapped(sender: AnyObject) {
>let alertController = UIAlertController(title: "First Run Database 
> Alert", message:
>"Welcome to Flying With Voice!  Please allow us to gather some 
> airport information.  Talking Technologies is not responsible if you do not 
> allow us to gather this information every 56 (fifty-six) days.", 
> preferredStyle: UIAlertControllerStyle.Alert)
>alertController.addAction(UIAlertAction(title: "Dismiss", style: 
> UIAlertActionStyle.Default,
>handler: nil))
> 
>self.presentViewController(alertController, animated: true, 
> completion: nil)
>}
> 
> ___
> 
> 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/rols%40rols.org
> 
> This email sent to r...@rols.org


___

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: My alert is not firing at all

[Roland King]

Mine definitely shows the message so two thoughts

1) the message is really long and you’ve upset the UIAlertController, can you 
try a shorter one? 
2) it is showing the message but in a way which voiceover isn’t reading.

I have exactly the same type, an .Alert type, and I have a message. I have two 
buttons on mine, but I can’t think that would count as enough of a difference .

> On 26 Dec 2015, at 20:26, Scott Berry <sb356...@gmail.com> wrote:
> 
> Hey there,
> 
> It doesn’t actually show me the message.  I see the Okay button but not the 
> message itself.
> 
> 
>> On Dec 26, 2015, at 5:11 AM, Roland King <r...@rols.org> wrote:
>> 
>> What do you mean by it doesn’t fire? It doesn’t show the alert, or it 
>> doesn’t do anything after it shows the alert when you hit the dismiss 
>> button? 
>> 
>> I wrote code very similar to this today .. with an extra button or two, and 
>> it was fine. 
>> 
>>> On 26 Dec 2015, at 19:40, Scott Berry <sb356...@gmail.com> wrote:
>>> 
>>> Hello there,
>>> 
>>> Here is the code I wrote to fire off my alert but when I run the program on 
>>> the device the alert doesn’t want to fire so I am wondering what I have 
>>> done wrong.  I use Voiceover.
>>> 
>>> // Alert Message for first load.
>>>  @IBAction func buttonTapped(sender: AnyObject) {
>>>  let alertController = UIAlertController(title: "First Run Database 
>>> Alert", message:
>>>  "Welcome to Flying With Voice!  Please allow us to gather some 
>>> airport information.  Talking Technologies is not responsible if you do not 
>>> allow us to gather this information every 56 (fifty-six) days.", 
>>> preferredStyle: UIAlertControllerStyle.Alert)
>>>  alertController.addAction(UIAlertAction(title: "Dismiss", style: 
>>> UIAlertActionStyle.Default,
>>>  handler: nil))
>>> 
>>>  self.presentViewController(alertController, animated: true, 
>>> completion: nil)
>>>  }
>>> 
>>> ___
>>> 
>>> 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/rols%40rols.org
>>> 
>>> This email sent to r...@rols.org
>> 
> 


___

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: Frameworks in the Helper LoginItems app

[Roland King]

> On 24 Dec 2015, at 07:36, Alex Kac  wrote:
> 
> I’ve got an app with a helper in the Contents/Library/LoginItems path. Both 
> use AFNetworking.framework. I currently install AFNetworking.framework in the 
> main app’s Framework path. I would like the helper to use AFNetworking from 
> the main app’s Framework’s folder. 
> 
> I’ve tried setting the run path search path to something like 
> @executable_path/../../../../../Frameworks
> 
> but it still doesn’t run - coming back to me with an error that it can’t load 
> the dynamic library AFNetworking. As mostly an iOS developer for the last 8 
> years, how Xcode handles frameworks and how to get embedded stuff like this 
> to work isn’t really something I have a lot of experience with. So I’m hoping 
> perhaps someone has some help?


Works the same on OSX as iOS, which is rather helpful. Remember that 
@executable_path expands to the directory the executable is in, so you often 
need one less ‘..’ than you think. I believe that the executable_path for 
embedded helpers is sane (ie it’s the path to the helper) but I would check 
that. 

Either way - find the helper, run ‘otool -L’ on it and see exactly what it 
prints out to make sure you’ve put the right bits in there, then go count 
double-dots. You can also use @loader_path which in many cases gives you the 
same thing as @executable_path but is better when frameworks link other 
frameworks as it gives you what you often really wanted. You can use @rpath 
too, but then you still have to work out what paths to embed in the binary to 
search which often ends up being @loader_path/../../something/else anyway, so 
you need to find the answer to your original question anyway. 

In here are a load of environment variables you can set which spew information 
about dynamic loading, which may tell you what’s been tried and hence why it 
wasn’t found. 

https://developer.apple.com/library/mac/technotes/tn2124/_index.html#//apple_ref/doc/uid/DTS10003391-CH1-SECDYLD
 



___

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: Hurdles in converting to Swift

[Roland King]

Is SearchViewController actually referenced in your code somewhere? You need 
something in the binary which would cause the class to get loaded in the first 
place or it will not be linked into the binary and not found by IB. This has 
been an issue with IB and objC forever, I don’t see why Swift would be any 
different. 

I have dummy bits of code in a few of my apps which do nothing but get the 
class of objects in IB which aren’t in the code elsewhere, that is enough to 
keep the class in the image. I suspect your issue is something similar 



> On 24 Dec 2015, at 09:38, John Brownie  wrote:
> 
> I have a fairly simple iOS application that was working in Objective-C, and 
> which I've now rewritten in Swift, by rewriting each class and removing the 
> old .m and .h files, and keeping the storyboard. However, it falls over 
> immediately with the console message:
> 
> 2015-12-24 10:43:40.664 AppName[10464:1086828] Unknown class 
> SearchViewController in Interface Builder file.
> 
> After that, it crashes with an uncaught exception (which looks like it's 
> related to the above):
> 
> 2015-12-24 10:43:40.707 AppName[10464:1086828] *** Terminating app due to 
> uncaught exception 'NSUnknownKeyException', reason: '[ 0x7b83a990> setValue:forUndefinedKey:]: this class is not key value 
> coding-compliant for the key activityIndicator.'
> 
> Of course, there is an appropriate class called SearchViewController in the 
> application, and it has an outlet activityIndicator, and it's set as the 
> class for one scene. I've cleaned the build folder, but it still happens.
> 
> Any wisdom on how to proceed?
> 
> John
> -- 
> John Brownie, john_brow...@sil.org or j.brow...@sil.org.pg
> Summer Institute of Linguistics, Ukarumpa, Eastern Highlands Province, Papua 
> New Guinea
> Mussau-Emira language, Mussau Island, New Ireland Province, Papua New Guinea
> ___
> 
> 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/rols%40rols.org
> 
> This email sent to r...@rols.org


___

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: applicationSupportDirectory access for admin and standard users

[Roland King]

> On 22 Dec 2015, at 20:11, Jonathan Mitchell  wrote:
> 
> 
>> On 21 Dec 2015, at 22:24, Sean McBride  wrote:
>> 
>> On Mon, 21 Dec 2015 22:16:39 +, Jonathan Mitchell said:
>> 
>>> My app seems to be having trouble reading and writing to the
>>> applicationSupportDirectory.
> 
> 
> 1. My preferences file does not get updated on first launch. This causes 
> trouble further on.
> I can probably insert a try/catch block in  -applicationDidFinishLaunching: 
> but the main issue is the write failure of the preferences file.
> 

What’s trying to write the preferences file and how is that related to the 
applicationSupportDirectory? Are you trying to hand-write a preferences file 
instead of setting the user defaults and synchronize them? The connection 
between the preferences files in the ~/Library/Preferences directory and the 
things loaded by NSUserDefaults has been tenuous for a few releases of the OS, 
the plist files get written, and read, only when the OS jolly well feels like 
it, the rest of the time they’re cached probably in a daemon. 


___

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: Return from a background queue

[Roland King]

You can’t do what you’re trying to do. 

First off, a block (which is what dispatch_async() takes) is defined to take no 
parameters and return nothing. That’s the source of your compilation error, 
you’re trying to return something from a block defined not to return anything. 

Secondly, what you’re trying to do doesn’t make sense, you are trying to return 
a value from a method which enqueues work for later execution. You can’t return 
the return value of that block because at the time you return, the block hasn’t 
been executed. Your code is basically this

func thing()->Banana
{
dispatch_async( dispatch_get_main_queue() )
{
()->Banana in 
return Banana( curveyness: 1.0, smellsGross: true )
}   
}

The dispatch_async queues the block and instantly returns, at this point there 
is no Banana, the banana will be created later. dispatch_async() returns 
nothing, there is nothing to return. When the banana is eventually created and 
returned, it’s returned into nothingness, the method which called it long-since 
finished. 

You need your method to create its banana and then call asynchronously back to 
another method which consumes it. You can’t synchronise asynchronous calls like 
that. 




> On 22 Dec 2015, at 22:25, Eric E. Dolecki  wrote:
> 
> I am trying to return a dictionary from a method that uses a queue. I'm not
> sure how to actually return though as I get an error (can't convert value
> of type '() -> Dictionary' to expected argument type
> 'dispatch_block_t'. I've tried a number of things but none prevent an error
> somewhere. I could ditch the queue altogether, but it feels better to use
> one.
> 
> - Eric
> 
> 
> func getForecast(cityName:String) -> Dictionary {
>let baseUrl: String = "
> http://api.openweathermap.org/data/2.5/forecast;
>let url: String =
> "\(baseUrl)?q=\(theCityName)=imperial=\(APIKey)"
>let finalUrl: NSURL = NSURL(string: url)!
>let session = NSURLSession.sharedSession()
>let task = session.dataTaskWithURL(finalUrl, completionHandler:
> {data, response, error -> Void in
>if error != nil{
>print(error!.localizedDescription)
>}
>var err: NSError?
>let qualityOfServiceClass = QOS_CLASS_BACKGROUND
>let backgroundQueue =
> dispatch_get_global_queue(qualityOfServiceClass, 0)
>dispatch_async(backgroundQueue, {
> 
>let json = JSON(data: data!, options:
> NSJSONReadingOptions(), error: )
>//print("response is \(json)")
>let weatherCurrent = json["list"][0]["main"]["temp"]
>let weatherHigh = json["list"][0]["main"]["temp_max"]
>let weatherLow = json["list"][0]["main"]["temp_min"]
>let conditionForecast =
> json["list"][0]["weather"][0]["description"].stringValue
> 
>   * dispatch_async(dispatch_get_main_queue(), { () ->
> Dictionary in*
> *print("Forecast: Current: \(weatherCurrent)ºF.
> H:\(weatherHigh), L:\(weatherLow). Cond:
> \(conditionForecast.capitalizedString).")*
> *let dict = ["current":"\(weatherCurrent)",
> "high":"\(weatherHigh)",*
> *"low":"\(weatherLow)",
> "conditions":"\(conditionForecast.capitalizedString)"]*
> *return dict*
>})
>})
>})
>task.resume()
>}
> ___
> 
> 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/rols%40rols.org
> 
> This email sent to r...@rols.org


___

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: Bitmaps, colorspaces, etc.

[Roland King]

> On 21 Dec 2015, at 09:15, Graham Cox  wrote:
> 
> I’m trying to understand how properly to use colorspaces with bitmaps.
> 
> The problem here is that I can find no documentation that goes anywhere near 
> explaining this. Maybe NSBitmapImageRep is too high level and I need to drop 
> down to CGImageRef? That class does seem to take a specific CGColorSpace 
> object, though how I get there from +[NSColorSpace availableColorSpecs] is 
> unclear.

That bit seems straightforward, you get the CGColorSpace property of the 
NSColorSpace object returned by NSColorSpace.availableColorSpacesWithModel() 

But if you want a bitmap to draw in then CGImageRef doesn’t seem like the right 
thing, CGBitmapContext takes a CGColorSpace (as long as it’s not an indexed 
one). If you need to bridge back to NSBitmapImageRef you should be able to do 
that via the CGBitmapContext’s CGImage property which is probably more 
efficient than you might fear. 

I can’t offer much for the rest of the questions, those hard-coded strings 
don’t mean much to me, I can’t see quite what you’d get if you passed the 
‘custom’ string without being able to pass the actual custom one, which you 
can’t. Retagging and conversion probably do exactly what the names suggest and 
conversion probably does take up more memory and retagging probably goes 
in-place, hence the restriction on using the same type of colorspace. 

Having come from the iOS world, if I ever need any kind of bitmap or other 
low-level CG thing, I go right for the CG classes because the NS ones often 
don’t exist, I’ve found them to be pretty full-featured. 

> 
> Am I even asking sensible questions? This sort of impedance mismatch usually 
> suggests a conceptual misunderstanding somewhere, but without a clear 
> explanation of how colorspaces and bitmaps are used, I can’t see where I may 
> have gone wrong.
> 
> Anyone able to illuminate?
> 
> —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/rols%40rols.org
> 
> This email sent to r...@rols.org


___

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: Validating NSButton in Swift

[Roland King]

> On 14 Dec 2015, at 17:12, dangerwillrobinsondan...@gmail.com wrote:
> 
> The bug should be that it gives you a wrong message, because it already 
> conforms to the protocol because it inherits from a class that conforms to 
> the protocol. 
> 
> All you should have to do is implement an override of the methods to do 
> custom stuff or of the properties. 
> You shouldn't declare conformity to NSValidatedUserInterfaceItem because it 
> already confirms earlier in its ancestry. 
> 

Nope. That’s wrong for 2 reasons. 

Firstly although NSControl does have the methods on it to conform to the 
protocol in Objective C, it doesn’t actually declare that it conforms to the 
protocol anywhere so you don’t get the actual conformance from the bridge over 
to Swift. Its conformance is informal, not formal. 

Secondly, the methods on NSControl which implement tag and action are 
properties in Objective C, not methods. In objective C that doesn’t matter as 
properties just end up being two methods and the getter method in that case has 
the right signature for the protocol so, in objective C, you can subclass from 
any subclass of NSControl, declare protocol conformance at that point, and it 
works. Swift however imports the properties as properties, not a pair of class 
functions and properties do not make a class conform to a protocol which 
requires functions, which the protocol in this instance does. Neither can you 
override the property with a same-named method, so you can’t do it. 

I did ask earlier if Luc can declare the conformance in objective-C, literally 
by making an NSValidatedButton subclass of NSButton which does nothing but 
formally declare the protocol conformance and then use that in swift. My 
thinking there is that the formal conformance to the protocol in objc will mean 
the object is correctly tagged in swift as already conforming. I don’t see 
another way to do it. 
___

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: Validating NSButton in Swift

[Roland King]

> On 15 Dec 2015, at 04:10, Luc Van Bogaert  wrote:
>> 
> 
> 
> I tried what you suggested and made a button subclass and just declared 
> conformance in objective-c, and then imported the class into Swift.
> This seems to do the trick, my button subclass is now accepted as conforming 
> to the protocol.
> Thanks!
> 

Good - If you can find 5 minutes I really would suggest filing a bug report on 
it, it’s nice to be able to work around it for now but it’s something needs to 
get fixed, the protocol definition is inconsistent in Objective C (defined as 
properties, implemented as functions) and that needs cleaning up or 
special-casing. 

___

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: Validating NSButton in Swift

[Roland King]

> On 14 Dec 2015, at 15:42, Luc Van Bogaert  wrote:
> 
> class ValidatedButton: NSButton, ValidatedControl {
> 
> 
> I've defined ValidatedControl like this:
> 
> protocol ValidatedControl: NSValidatedUserInterfaceItem {
> 
> 
> This results in a compiler error: Type ValidatedButton does not conform to 
> protocol NSValidatedUserInterfaceItem.
> I've tried overriding the NSControl properties 'action' and 'tag', but the 
> error remains. 

You appear to be a little out of luck here because 

NSValidatedUserInterfaceItem requires two *functions*

public func tag()->Int
public func action()->Selector

however NSControl implements two *properties*

public var tag : Int { get set }
public var action : Selector { get set }

and even though the getter for those has the same signature you can’t 
substitute one for another. Nor can you add a function on the subclass which 
shadows the equivalently-named property on the superclass so .. it rather looks 
like you can’t do it. 

Can you declare this small piece of it in ObjC and import the classes, while 
Apple considers the bug report you will no-doubt file on it. 
___

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: Non-Resizable Window and Autolayout

[Roland King]

> On 8 Dec 2015, at 23:06, Jerry Krinock  wrote:
> 
> 
>> On 2015 Dec 08, at 06:31, Dave  wrote:
>> 
>> I then select the Window in IB and select “Reset to Suggested Constraints”.
> 
> also known as the “Ruin My Day” selection.

I love that button - I always try to figure out after I’ve pressed it who, or 
what, suggested those constraints, and why. I always feel it was something 
which was vaguely unaware of the constraint system but it’s always good for a 
laugh. 

> 
>> Does anyone have an idea why this is happening? 
> 
> It would be interesting to look at the window’s styleMask in the debugger and 
> see if the NSResizableWindowMask bit is on.
> 

I’d have a look at the constraints on the window itself when running to see 
what priorities they have. If they are lower than the ‘human is resizing me’ 
priorities then the human wins. 
___

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: UIView underlying rects for drawRect

[Roland King]

> On 8 Dec 2015, at 06:30, David Duncan <david.dun...@apple.com> wrote:
> 
>> 
>> On Dec 6, 2015, at 4:51 AM, Roland King <r...@rols.org 
>> <mailto:r...@rols.org>> wrote:
>> 
>>> 
>>> On 6 Dec 2015, at 20:18, Roland King <r...@rols.org <mailto:r...@rols.org>> 
>>> wrote:
>>> 
>>> 
>>>> 
>>>> CALayer has a mechanism built in for the sort of thing you want to do. 
>>>> Read up on -[CALayer display]. You should be able to override that, or 
>>>> implement the corresponding delegate method in your UIView and perform 
>>>> management of your custom bitmap there. I myself do this in one app to 
>>>> share one bitmap between multiple layers for example.
>>>> 
>>>> The other thing worth investigating perhaps is whether CATiledLayer would 
>>>> better suit your drawing needs, or if you could split your custom view up 
>>>> into a series of sub-views, so you only need invalidate slices of one or 
>>>> two of them.
>>>> 
>>>> Mike.
>>> 
>>> That’s what I was just trying. I made a subclass of CALayer() and overrode 
>>> just display() to do absolutely nothing at all, except print ‘display()’. I 
>>> then made a UIView subclass which overrides layerClass() to return the type 
>>> and stuck one such view randomly in my NIB. The view is made, the layer is 
>>> created .. and absolutely nothing else happens. I expected to get at least 
>>> ONE call to display() as the view/layer starts dirty, but I don’t get even 
>>> that. I even hooked up a button to call setNeedsDisplay on the view but 
>>> that didn’t prompt it either. I overrode a bunch of other methods too to 
>>> print but the only one which currently gets called is init(). 
>>> 
>>> I expected the UIView would drive at least an initial setNeedsDisplay on 
>>> the layer, and a setNeedsDisplay on the view would end up being 
>>> passed-through, but it doesn’t. Calling setNeedsDisplay on the actual layer 
>>> object itself seems to work, but I did sort of expect the UIView to do some 
>>> things with the layer automatically. Guess I was wrong and I will need to 
>>> hook all those bits up for myself. 
>> 
>> ok I begin to see how it all works now. So if the layer is the view’s layer, 
>> instead of a separate totally custom layer you add to the layer, then the 
>> view sets some things on it but not everything. It turns off 
>> needsDisplayOnBoundsChange (which I had set on init in the layer) unless the 
>> view’s contentMode is redraw, which somewhat confused me. That causes the 
>> layer to call display() on itself on bounds change. However it doesn’t pass 
>> setNeedsDisplay() and setNeedsDisplayInRect() through to the underlying 
>> layer which I’d have expected. I assume it only calls those that if the 
>> layer is a normal UIView layer and not a custom one. 
> 
> UIView will not dirty its layer if your subclass does not implement 
> -drawRect:.
> 

Ah - thanks - that’s a useful missing piece to know. I’m fairly happy now that 
my layer is doing what its owning UIView expects and I’m getting better 
performance with less CPU. Instruments has been great for this too, couple of 
hours looking at the heavy stack traces and watching how CPU usage changed over 
time, a few targetted tweaks to code I expected was going to need some kind of 
optimisation, I’m using about 10% of the power I was at the weekend. Good 
stuff. 
___

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: UIView underlying rects for drawRect

[Roland King]

> 
> CALayer has a mechanism built in for the sort of thing you want to do. Read 
> up on -[CALayer display]. You should be able to override that, or implement 
> the corresponding delegate method in your UIView and perform management of 
> your custom bitmap there. I myself do this in one app to share one bitmap 
> between multiple layers for example.
> 
> The other thing worth investigating perhaps is whether CATiledLayer would 
> better suit your drawing needs, or if you could split your custom view up 
> into a series of sub-views, so you only need invalidate slices of one or two 
> of them.
> 
> Mike.

That’s what I was just trying. I made a subclass of CALayer() and overrode just 
display() to do absolutely nothing at all, except print ‘display()’. I then 
made a UIView subclass which overrides layerClass() to return the type and 
stuck one such view randomly in my NIB. The view is made, the layer is created 
.. and absolutely nothing else happens. I expected to get at least ONE call to 
display() as the view/layer starts dirty, but I don’t get even that. I even 
hooked up a button to call setNeedsDisplay on the view but that didn’t prompt 
it either. I overrode a bunch of other methods too to print but the only one 
which currently gets called is init(). 

I expected the UIView would drive at least an initial setNeedsDisplay on the 
layer, and a setNeedsDisplay on the view would end up being passed-through, but 
it doesn’t. Calling setNeedsDisplay on the actual layer object itself seems to 
work, but I did sort of expect the UIView to do some things with the layer 
automatically. Guess I was wrong and I will need to hook all those bits up for 
myself. 
___

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: UIView underlying rects for drawRect

[Roland King]

> On 6 Dec 2015, at 20:18, Roland King <r...@rols.org> wrote:
> 
> 
>> 
>> CALayer has a mechanism built in for the sort of thing you want to do. Read 
>> up on -[CALayer display]. You should be able to override that, or implement 
>> the corresponding delegate method in your UIView and perform management of 
>> your custom bitmap there. I myself do this in one app to share one bitmap 
>> between multiple layers for example.
>> 
>> The other thing worth investigating perhaps is whether CATiledLayer would 
>> better suit your drawing needs, or if you could split your custom view up 
>> into a series of sub-views, so you only need invalidate slices of one or two 
>> of them.
>> 
>> Mike.
> 
> That’s what I was just trying. I made a subclass of CALayer() and overrode 
> just display() to do absolutely nothing at all, except print ‘display()’. I 
> then made a UIView subclass which overrides layerClass() to return the type 
> and stuck one such view randomly in my NIB. The view is made, the layer is 
> created .. and absolutely nothing else happens. I expected to get at least 
> ONE call to display() as the view/layer starts dirty, but I don’t get even 
> that. I even hooked up a button to call setNeedsDisplay on the view but that 
> didn’t prompt it either. I overrode a bunch of other methods too to print but 
> the only one which currently gets called is init(). 
> 
> I expected the UIView would drive at least an initial setNeedsDisplay on the 
> layer, and a setNeedsDisplay on the view would end up being passed-through, 
> but it doesn’t. Calling setNeedsDisplay on the actual layer object itself 
> seems to work, but I did sort of expect the UIView to do some things with the 
> layer automatically. Guess I was wrong and I will need to hook all those bits 
> up for myself. 

ok I begin to see how it all works now. So if the layer is the view’s layer, 
instead of a separate totally custom layer you add to the layer, then the view 
sets some things on it but not everything. It turns off 
needsDisplayOnBoundsChange (which I had set on init in the layer) unless the 
view’s contentMode is redraw, which somewhat confused me. That causes the layer 
to call display() on itself on bounds change. However it doesn’t pass 
setNeedsDisplay() and setNeedsDisplayInRect() through to the underlying layer 
which I’d have expected. I assume it only calls those that if the layer is a 
normal UIView layer and not a custom one. 

I think as long as that’s the extent of its meddling with ‘its layer’, just 
setting a few properties when it starts up and adjusting the bounds for me, I 
can live with it. I’ll try out a few more things on the view to see if there 
are other things I need to be prepared to deal with, just having it manage the 
layer bounds automatically is helpful if that’s about all it does. 


___

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: UIView underlying rects for drawRect

[Roland King]

You thought CGContext had it, I thought CALayer had it, neither of them appear 
to have it! 

AFAICT UIView is clearing the entire rectangle before drawing, so that idea 
doesn’t work either. That was a good way to confirm I was on the wrong road so 
thanks. 

So I implemented the code to capture setNeedsDisplayInRect(), drawRect() etc 
and ensure only one contiguous rectangle goes to the setNeedsDisplayInRect at a 
time, if there’s another one it waits until drawRect() finishes and then queues 
that one up. The results were good until they weren’t and I’m really at a loss 
to explain some of the oddities I saw. It was never going to be stable enough 
for real use so that idea got tossed. 

Current workaround it not to take things off the back, it’s history, I don’t 
really care, and the code moves the view along anyway so it quickly gets 
clipped and every few minutes the view is moved to a new chunk of data (it’s 
like a horizontal scroll view where only 1.5 screens wide of data is shown at a 
time which are incrementally drawn and then moved to a new chunk every few 
minutes with one single redraw). 

I think a better plan for this whole thing is to use a CALayer with a 
persistent bitmap for the graph I’m drawing. 

Currently I’m seeing a new point come in, working out what that is in view 
coordinates, calling setNeedsDisplayinRect() on that, then in drawRect I’m 
converting back to time coordinates, padding out each side so I definitely 
redraw the whole area cleared including the fuzzy edges of lines a point or two 
over on the display, then drawing. This is probably nowhere near as efficient 
as possible. 

If I use a CALayer with a bitmap I can put a point on the bitmap asynchronously 
as soon as it comes in, one point, or one tiny line segment from the previous 
point, I can do my own clearing when they expire and then all I have to do is 
arrange the bitmap to be blitted onto the CALayer’s content on a regular basis 
for update and sort out some full redraw stuff on bounds change stuff. 

What’s the right way to synchronise the update of the content property of a 
CALayer? I could do it every time I add a point, but that sounds a bit 
unnecessary. Is this where I use CADisplayLink? Is there a recommended format 
for the bitmap which eases the work the CPU/GPU has to do to transfer it to and 
from the layer? 8 bit with alpha is all I really need for the plot but if 
that’s going to trigger a huge conversion every time it’s run through 
CGBitmapContextCreateImage() and stuffed on the layer I’ll use something else. 

Sigh .. I feel a few hours of pain coming up. 



> On 5 Dec 2015, at 18:59, Mike Abdullah <mabdul...@karelia.com> wrote:
> 
> I thought CGContext had API to tell you the rects being drawn, but can’t see 
> that now, so I think I imagined it!
> 
> I’d say your next port of call is to ascertain whether the system is smart 
> enough to be only drawing the required area or not. There are debugging tools 
> to show you the portions of the screen being updated — does that suggest the 
> entire view is being redrawn, or just the ends?
> 
> Mike.
> 
>> On 5 Dec 2015, at 03:02, Roland King <r...@rols.org> wrote:
>> 
>> NSView has a method getRectsBeingDrawn:count: which gives you the actual 
>> rects being drawn in a drawRect: call. Is there something equivalent for a 
>> UIView? Does UIView even do as I believe NSView does and only invalidate 
>> just the areas passed to setNeedsDisplayInRect:, meaning those are the only 
>> areas you actually need to redraw, or does it blow away the entire 
>> containing rectangle so you must repaint the entire area?  
>> 
>> I have a time-series view which only invalidates a tiny sliver of view which 
>> changed and only draws that in drawRect:. However when the series gets long 
>> enough it trims the left hand end, so two tiny slivers of view are 
>> invalidated, one at each end, drawRect: coalesces them into one rect the 
>> entire size of the window and the whole series redraws on every iteration. I 
>> spotted this when I left the simulator running for an hour and the fans 
>> suddenly started spinning up. 
>> 
>> I can work around it by overriding setNeedsDisplayInRect: and queuing up 
>> non-contiguous updates, releasing them only when drawRect has been called, 
>> but it would be nice not to have to. I suspect I’m SOL on this one. 
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>> 
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/cocoa-dev/mabdullah%40karelia.com
>> 
>> This

Re: Need Help with Swift

[Roland King]

> On 4 Dec 2015, at 16:07, Stevo Brock  wrote:
> 
> This seems to do the trick.
> 
> I wasn’t able to just do ABC.class, as the “.class” wasn’t registered as 
> valid.
> 
> What I ended up with was a static method on the class, and calling the static 
> method, and voilà! Everything is working.
> 
> So now to clean things up…
> 
> Thanks guys so much for your help.  

well that’s just a whole bunch of ugly. Before you get TOO far, try and 
optimized release build, make sure it doesn’t go optimize that out and break it 
all again. You know these compilers love to leave the best until last. 
___

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

UIView underlying rects for drawRect

[Roland King]

NSView has a method getRectsBeingDrawn:count: which gives you the actual rects 
being drawn in a drawRect: call. Is there something equivalent for a UIView? 
Does UIView even do as I believe NSView does and only invalidate just the areas 
passed to setNeedsDisplayInRect:, meaning those are the only areas you actually 
need to redraw, or does it blow away the entire containing rectangle so you 
must repaint the entire area?  

I have a time-series view which only invalidates a tiny sliver of view which 
changed and only draws that in drawRect:. However when the series gets long 
enough it trims the left hand end, so two tiny slivers of view are invalidated, 
one at each end, drawRect: coalesces them into one rect the entire size of the 
window and the whole series redraws on every iteration. I spotted this when I 
left the simulator running for an hour and the fans suddenly started spinning 
up. 

I can work around it by overriding setNeedsDisplayInRect: and queuing up 
non-contiguous updates, releasing them only when drawRect has been called, but 
it would be nice not to have to. I suspect I’m SOL on this one. 
___

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: Need Help with Swift

[Roland King]

> On 4 Dec 2015, at 15:42, Stevo Brock  wrote:
> 
> So strange…
> 
> I added
> 
> class IB_MediaItemViewController_PhotoMediaItemView : 
> MediaItemViewController
> {
> }
> 
> and used IB_MediaItemViewController_PhotoMediaItemView in the Storyboard, and 
> I still see this error:
> 
> 2015-12-03 23:35:52.400 Media Tools[14523:313526] Unknown class 
> _TtC11Media_Tools45IB_MediaItemViewController_PhotoMediaItemView in Interface 
> Builder file.
> 
> So strange…

Try using it somewhere - even in a method which can’t possibly ever get called. 
I don’t know if Swift suffers from the same problem with IB as ObjC does, that 
if you have a class which is reference ONLY in your IB file, and not in code, 
none of the code for it actually ends up in the binary. 

I have little hack files in some of my projects which just do 

SomeClassIWantToLoad.class


___

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: Need Help with Swift

[Roland King]

> On 4 Dec 2015, at 14:45, Stevo Brock  wrote:
> 
> I’m trying to set up a UIViewController than can host a number of different 
> UIViews as long as they adhere to a given protocol.  I’ve worked through 
> getting things set up to make the compiler happy, but I’m getting a runtime 
> error loading the view controller from the storyboard.  Below is the relevant 
> code.
> 
> How do I specify the class in the storyboard so it will load correctly?  Or 
> perhaps there’s a different way to construct this all so it will work?
> 
> protocol MediaItemView {
> }
> 
> class PhotoMediaItemView : UIImageView, MediaItemView {
> }
> 
> class VideoMediaItemView : VideoPlayerView, MediaItemView {
> }
> 
> class MediaItemViewController : 
> UIViewController {
>   private var currentMediaItemView :T?
> }
> 
> 
> let   mediaItemViewController =
>   
> self.storyboard?.instantiateViewControllerWithIdentifier("MediaItemViewController")
>  as!
>   MediaItemViewController
> 
> Storyboard has a view controller with the Class set to 
> "MediaItemViewController"
> 
> 2015-12-03 22:07:23.966 Media Tools[14143:276368] Unknown class 
> _TtC11Media_Tools23MediaItemViewController in Interface Builder file.
> Could not cast value of type 'UIViewController' (0x10d1dfd60) to 
> 'Media_Tools.MediaItemViewController' 
> (0x1193fc038).

I don’t see how that would work. IB needs a fully specified class in order to 
instantiate it, you just have the name of the generic. At the least you need 
MediaItemViewController but I’m not even sure that would 
work. The error message is indeed telling you that no such class as 
MediaItemViewController exists, because it doesn’t, only specialised versions 
of it actually exist (you can probably dump your binary to see what they are 
called, I don’t know the mangled naming convention for generics)





___

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: Need Help with Swift

[Roland King]

> On 4 Dec 2015, at 15:24, Stevo Brock  wrote:
> 
> Hi Roland,
> 
> I think you’re right.  The trick is - what do I put in the Storyboard such 
> that it sticks (and IB doesn’t just change it back) and resolves at runtime?


Quincey had one idea - but I don’t know how you @objcname a specialisation of a 
generic. 

Hmm how about

public class IB_MediaItemViewController_VideoMediaItemView : 
MediaItemViewController
{
}
___

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: iOS: Using AppDelegate as an app-wide singleton

[Roland King]

> On 2 Dec 2015, at 04:58, Carl Hoefs  wrote:
> 
> I was about to implement my own singleton class to act as an app-wide context 
> repository, but then I thought: wouldn't it be simpler just to use the 
> appDelegate for that purpose? It's a singleton already and available to all 
> classes via [[UIApplication sharedApplication] delegate]. All I need to do is 
> add my @properties to it and I'm done.
> Are there any drawbacks to this?
> -Carl
> 

Overloading the AppDelegate like that isn’t really a great practice. It’s often 
done because it’s easy and because it’s a single call away, but AppDelegate 
already has its definition and responsibilities and it’s very little work to 
sort out your own top-level object, suitably named, to just deal with your 
app’s logic. And when you get to the point you find you suddenly need two of 
them, because say you’re switching an old app context for a new one or doing 
some kind of data upgrade, you’ve already got what you need mostly where you 
need it. And it’s amazing how often that happens. 

My advice, leave AppDelegate to be do its job being the generic app delegate, 
often with only about 2 methods fleshed out, and put your business logic in 
your own object. 
___

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: How to import a Framework

[Roland King]

> On 2 Dec 2015, at 10:39, Gerriet M. Denkmann  wrote:
> 
> I just made a Framework (Xcode 7.1), called ProcArgFramework.
> I copied it into /Library/Frameworks.
> 
> In some other Project I added:
> 
> @import ProcArgFramework  
> 
> But Xcode says: “Module ProcArgFramework not found”.
> 
> I tried all sorts of variations of this import-line. But all to no avail.
> 
> How can I import my framework?
> 
> Gerriet.
> 

What makes you think Xcode looks in /Library/Frameworks for framework imports? 
I’d assume there’s a build setting somewhere with a framework search path, 
perhaps finding and setting that might help. 

Or just drag the thing onto your project from the finder and see if Xcode does 
the right thing, it occasionally does. 

If it’s your own framework you can just add the project as a sub project in 
your build and have it build it locally, unless you particularly want to link 
with the system-installed one. 
___

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: Self and associated type requirements (yes again!)

[Roland King]

I hadn’t actually read that blog post, I’ve read lots, but not that one - so 
thanks for the link. Any blog post who’s first paragraph ends with ‘I want to 
tie you up in a sack, throw the sack in a river, and hurl the river into space’ 
is probably worth reading, so I’m reading it. 

I think I am stuck with it in this case because of my inability to get over 
myself and make TimeSeries a thing which returns Floats. If I did that, all my 
problems would go away (possibly not actually - see the end of my last diatribe 
about Generators, I’d probably also need to get over myself and not make 
TimeSeries a SequenceType but something which returned a thing which returned 
something concrete). But I never found a wall I didn’t like bashing my head 
against so I’ll continue. I can split some behaviour into another protocol, I 
have actually, but the basic fact that TimeSeries is a protocol and it’s a 
series of anything-you-can-think-of means at some point I have to use a 
concrete class to specify which implementation of it I actually am going to use 
so the compiler can actually compile it. 

Before the end of today I’m fairly sure my code will look like this

public struct TimeSeriesView : UIView
{
public let series : CompressedTimeSeries
}

because the CompressedTimeSeries implementation ends up being better, faster, 
saves memory and can employ some useful drawing optimisations. It would also 
mean I can stop flagellating and get back to solving the problem I was writing 
the code for in the first place, which was building a reflow oven. Anyone who’s 
heard the old saying about draining swamps and alligators knows where I am 
right now. 

But I’ll read the article first. 

> On 1 Dec 2015, at 04:05, Peter Tomaselli <vast.gra...@gmail.com> wrote:
> 
> I have no answer here, but there is a blog post I continually refer to 
> whenever I get confused about this. In case you haven't already read it 
> (although I suspect you have) it is called "Swift: Associated Types" by Russ 
> Bishop [0]. Rob Napier has also had a few nice posts about type erasure that 
> may be relevant.
> 
> I'm a C# dev by day and my first pass at your problem would probably be quite 
> similar to what you have already, in that the first instinct is to let all 
> the generic parameters bubble up to the top and trust in your ability to 
> pivot where you need to go from there. What Russ does a good job of 
> explaining in that post is that Swift protocols are not really "just [C# or 
> Java] interfaces" in this way.
> 
> Again, apologies if this is obvious stuff but it probably will be interesting 
> to someone on the list.
> 
> Just spitballing here, but it seems like two aspects of your approach here 
> might be at odds: one, you want a "strongly typed" TimeSeries collection of 
> some kind, but you also want some degree of implementation hiding, right (I 
> base this on your desire to be able to just plop one of these into a 
> tableView and have it work)? 
> 
> To me that feels like you actually don't want to include a typealias in your 
> protocol (adopters of the protocol could of course still be generic), and 
> that the truth is that the view actually doesn't care about the underlying 
> type in the collection. Instead, contractually, all it cares about is that 
> TimeSeries can be a dataSource (basically, that it can vend strings for a 
> given indexPath).
> 
> Perhaps what you want are two protocols, one that enforces whether or not a 
> collection is easily "presentable", and one that enforces that a collection 
> has some TimeSeries-ish "semantics" (whatever that might mean). Your actual 
> classes here could conform to both, but the view only need care about the 
> first one.
> 
> If you actually do want _both_ of those things together, that's where (and I 
> could be way off here; I have only casually read up on this stuff) techniques 
> of "type erasure" may be relevant?
> 
> Peter
> 
> [0] http://www.russbishop.net/swift-associated-types 
> <http://www.russbishop.net/swift-associated-types>
> 
> On Mon, Nov 30, 2015 at 7:12 AM, Roland King <r...@rols.org 
> <mailto:r...@rols.org>> wrote:
> I keep running myself into this issue when I try using some of my generic 
> classes built on top of Protocols.
> 
> [snip]
>  
> There’s still no clever way around this right, this is still how Generics and 
> Protocols work together, there’s nothing in Swift 2.0 which helps you work 
> around this, no way to use Protocol extensions to do it? I thought (I’ve 
> tried this before) of making a FloatTimeSeries protocol which only deals with 
> Floats and has no Self or associated type issues which basically has all the 
> same methods of TimeSeries but with ‘Float’ spec

Re: Self and associated type requirements (yes again!)

[Roland King]

> On 1 Dec 2015, at 06:17, Quincey Morris <quinceymor...@rivergatesoftware.com> 
> wrote:
> 
> On Nov 30, 2015, at 04:12 , Roland King <r...@rols.org 
> <mailto:r...@rols.org>> wrote:
>> 
>> I want to say that timeSeries is any TimeSeries with an underlying type of 
>> Float, but you can’t.
> 
> The problem is that this says that you want a generic protocol, and there’s 
> no such thing. Unfortunately, TimeSeries is not (in a sense) non-generic 
> either, because of its associated type requirement.
> 
> I agree that the two types of protocols in the current Swift (conformable 
> protocols and constraint protocols) is Swift’s biggest defect right now. I 
> don’t know if it’s technically feasible (or even makes sense), but I’d love 
> to see those unspecified typealias’s in protocols turn into generic type 
> parameters, so the whole thing just turns into a comprehensible generic 
> system. (Yeah, right.)
> 
> 


TL;DR version - don’t bother reading it, this is just my ramblings partly so I 
can find them later on google and re-read what I wrote

That’s how I feel too - the combination of parameters for Generics and 
associated types for protocols get into conflict in situations like this and 
while generically it’s a hard problem, there are cases in which you could 
express intent and the compiler could write the code, and I hope that comes in 
the next iteration. It’s really easy to get in this mess too. My thinking went, 
“I need a time series, what would one look like, let me make it a protocol with 
methods to add a value, get values, subsequence etc. What do I want it to be a 
timeseries of .. I don’t really care, Floats, Doubles, Bananas, let’s just make 
that an Element". At this point I have now nailed one foot to the floor, I have 
a protocol with an associated type AND Self requirements (the subsequence gives 
you that). 

I do, when I get to this point, understand why what I want to express isn’t 
sufficient, I want to have a time series of floats, I want to type a variable 
as one, perhaps with a syntax like this (which I just made up)

var series : T:TimeSeries where T.Element == Float

or perhaps putting the protocol constraints in as if they were generic 
parameters, I made this up too, along the lines of Quincey’s ‘typealiases 
turning into generic type parameters'

var series : TimeSeries

You think that defines the behaviour of ‘series’ enough for the compiler to 
work with it, and it does, it says what you can *do* with series, that should 
allow you to use ‘series’ in the code, call its methods, mutate its properties, 
but it doesn’t tell you how big it is, is it a struct with 123 bytes of data or 
a class, ie a  pointer. Without knowing what actually implements this protocol, 
the compiler can’t actually build the object which contains it. I understand 
this, although I always understand it after the fact.  

Swift lets you hoist that information up into a description of a generic 
parameter to a type

public struct UserOfTimeSeriesOfFloat
{
var series : T
}

The compiler similarly knows what a ’T’ can do and what can be called on it and 
what it can return and because the actual type is passed when you make one, the 
compiler knows how big ‘series’ is and can make the concrete type which 
contains it. 

There are cases where the compiler I think could do better. If TimeSeries is a 
class, or if you could specify in the constraint that TimeSeries in this 
instance must be implemented by a class, the compiler knows how big series is, 
it’s a pointer, and any implementation of TimeSeries where the Element is a 
Float which is implemented by a class, works and the type’s size is known. 
UserOfTimeSeriesOfFloat is (I think) fully compilable at that point. That’s a 
restriction I would probably happily accept. 

C++, ugly though it is when you have multiple nested <> and you’ve typedef’ed 
yourself into oblivion, manages to let you express this kind of intent because 
when you do you always end up using a pointer or a reference, so the type 
defines the behaviour you can use, and the pointer/reference defines the 
storage size. 

For anyone still reading, it actually got worse^H^H^H^H^H more interesting. 
TimeSeries is a SequenceType, made sense right, I want to iterate them and I 
love embracing standards. A SequenceType returns a GeneratorType which itself 
generates Elements. In this particular case what you get out of iterating a 
TimeSeries is a TimeSeriesPoint which is a struct { time : Int, value : 
Underlying }, both the full and compressed series implementations return 
Generators which generate those. So I wrote this

for tick in series { total += tick.value }

and of course it didn’t compile. The error was something like "cannot call 
‘value’ on T.Generator.Element” which stumped me for a while. But indeed, just 
because my t

Self and associated type requirements (yes again!)

[Roland King]

I keep running myself into this issue when I try using some of my generic 
classes built on top of Protocols. 

I have a TimeSeries protocol which has an Underlying (Float, Double, .. 
whatever) and also a Self requirement because you can return a sub series. 
There’s more to the protocol but this is enough for example

public protocol TimeSeries 
{
typealias Underlying
mutating func addValue( value : Underlying, tick : Int )
func subSeriesFromTick( tick : Int )->Self
}

I have two concrete implementers of this protocol, a FullTimeSeries which is a 
memory pig and a CompressedTimeSeries which usually isn't

public struct FullTimeSeries : TimeSeries
{
public typealias Underlying = T

// implementation
}

public struct CompressedTimeSeries : TimeSeries
{
public typealias Underlying = T

// implementation
}

These work just fine. Now I want a UIView which shows a TimeSeries, in this 
case actually a TimeSeries of Floats, of course the code below doesn’t work

public class TimeSeriesView : UIView
{
public typelias Underlying = Float
public var timeSeries : TimeSeries
}

"Protocol 'TimeSeries' can only be used as a generic constraint because it has 
Self or associated type requirements”, my least favourite error message which 
always pops up just after I’ve done all the work and just before I get to use 
the fruits of my labour. I never see it coming. 

The typealias in the above code doesn’t do anything of course, it was just me 
having an attempt. 

I want to say that timeSeries is any TimeSeries with an underlying type of 
Float, but you can’t. I wanted to have a generic UIView I could just stuff a 
TimeSeries of Floats into and it would show it. 

The best I can come up with is to parameterise on T, which is a TimeSeries

public class TimeSeriesView
{
public typealias Underlying = Float
public var timeSeries : T
}

now I have to create the correct TimeSeriesView or 
TimeSeriesView, which wasn’t really what I wanted 
to do. 

There’s still no clever way around this right, this is still how Generics and 
Protocols work together, there’s nothing in Swift 2.0 which helps you work 
around this, no way to use Protocol extensions to do it? I thought (I’ve tried 
this before) of making a FloatTimeSeries protocol which only deals with Floats 
and has no Self or associated type issues which basically has all the same 
methods of TimeSeries but with ‘Float’ specifically instead of Underlying and 
then using a protocol extension like this

extension FullTimeSeries : FloatTimeSeries where T:Float
{
}

but Swift has you covered on that one too .. "Extension of type 
'FullTimeSeries' with constraints cannot have an inheritance clause”

Nothing from last years WWDC I missed here? You still can’t do this, right? 

___

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

swift - making array of subclass of class also conforming to protocol

[Roland King]

I have a protocol I want some of my UIView subclasses to conform to so they can 
be controlled by a specific master object. So they are UIVIews (class) and they 
are also MasterControllable (protocol)

easy to make those UIView subclasses

public class MyVIew1 : UIView, MasterControllable {}
public class MyView2 : UIView, MasterControllable {}

etc

what I wanted in the master was an array of them, an array of UIViews which are 
also MasterControllable, but I can’t think of a way to specify that

private var myViews : Array  // nope
private var myViews : Array// nope

I can specify an array of something conforming to a protocol, or more than one 
protocol, or of a subclass of a given class, but not it seems of a subclass of 
a given class which also conforms to a given protocol. 

Yes I could write a generic UIView subclass which conforms to the 
MasterControllable protocol and stub out all the protocol methods and then 
write my UIView subclasses as subclasses of that, then use an array of that 
generic class, but that seems a very old scruffy way of doing it. 

I tried thinking about protocol extensions but didn’t get very far with that 
either. 

Did I miss something or has my quest for type perfection led me down another 
blind alley? 





___

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: swift - making array of subclass of class also conforming to protocol

[Roland King]

> On 29 Nov 2015, at 09:26, Quincey Morris 
>  wrote:
> 
> On Nov 28, 2015, at 10:32 , Quincey Morris 
>  > wrote:
>> 
>> It can’t be UIView+MasterControllable (in some syntax), because no such 
>> *single* type exists. 
> 
> One other dopey alternative occurred to me. You could add all the methods 
> from UIView, or just those your app actually uses, directly to the 
> MasterControllable protocol. Your conforming subclasses will of course 
> inherit conformity to these requirements from the real UIView, so there’s no 
> extra work or runtime overhead. If the UIView API ever changes, then you’ll 
> conformance errors in your subclasses the next time you compile.
> 
> There are probably hundreds of methods in UIView, but chances are you’ll only 
> need a couple of dozen to be exposed in the enlarged MasterController.
> 
> FWIW
> 

Thanks - I was just writing a reply to your last message which said I’d tried 
containment but it made the rest of the code clunky and so, realising I only 
need about 4-5 methods from UIView I made a UIViewProtocol protocol with those 
methods in and ‘extended’ UIView to conform to it. At the same time I did add 
another read-only property into that protocol which returns a UIView, a real 
one, which the extension trivially implements with

var view : UIView { return self }

And then I can make an array> and I 
have pretty close to what I want. 

When I’m calling methods *on* the view, they’re in the protocol so I can call 
them directly, if I need to use the object *as* a UIView, to send it to 
something else, like addSubview(), then I have to stick the ‘.view’ on the end, 
which isn’t a terrible hardship. So it looks a bit like containment in some 
cases, and like extension in most of them, not a horrid hybrid. 

Were UIView written as a protocol and a single implementing class, this would 
be pretty easy, I wonder as Swift develops whether more of the library will be 
adjusted to be that way. Perhaps UIView would be the last thing to get there 
but you an see how having many classes as just implementing various Cocoa/UIKit 
protocols would be a useful recasting. 

That also possibly suggests an answer to your question in the previous mail, 
‘what would class mean’? How about, and I’m sure there 
are some big gaping holes in this, if a class counted as an object implementing 
a protocol of the same-named-type, so protocol would mean 
a protocol which has all the methods of UIView and all the methods of 
SomeProtocol and could be used wherever a UIView class/subclass was used. That 
would be an interesting trick for moving to protocol-based programming. 

Anyway this is rigorous enough for what I’m doing, I just wanted to avoid too 
many ‘as?’ constructs which to my mind give the code a bit of an odour. 
___

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

Stopping the initial storyboard viewcontroller being created

[Roland King]

I would like to create the main viewcontroller in my 
applicationDidFinishLaunching:withOptions: method (iOS) instead of having the 
storyboard one created automatically. 

I’m doing this in order to change behaviour between simulator and device as the 
simulator doesn’t support BlueTooth, so I need to fix in a simulated version. 

I have the code to create the initial view controller and fix it up

let storyboard = UIStoryboard(name: "Main", bundle: nil)
self.window?.rootViewController = 
storyboard.instantiateInitialViewController()
// make a fix to the viewcontroller here
self.window?.makeKeyAndVisible()

however I’ve found that standard machinery still creates one for me so I end up 
with two of them, possibly with the one I want on-screen, possibly not, and the 
first one created doesn’t do the decent thing and release itself either, so two 
of them persist. (I don’t understand what’s referencing it either, when I 
assign to the rootViewController it ought to go away but doesn’t). 

How do I stop the standard storyboard initial viewcontroller load so I can do 
it myself. 
___

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: Swift - internal class conforming to public protocol

[Roland King]

> On 25 Nov 2015, at 16:30, Andreas Mayer  wrote:
> 
> 
>> Am 25.11.2015 um 08:56 schrieb Quincey Morris 
>> :
>> 
>>> That's explained in "Using Swift with Cocoa and Objective-C":
>>> 
>>> "The compiler does not automatically insert the @objc attribute for 
>>> declarations marked with the private access-level modifier.”
>> 
>> That can’t be the full explanation, because the other private method doesn’t 
>> produce an error, Roland said.
> 
> I can't replicate that behavior.
> 
> This doesn't work:
> 
> // Roland's protocol must be marked @objc since it has optional requirements.
> 
> @objc public protocol PublicProtocol {
>   func someFunction()
>   // ...
> }
> 
> private class SomeClass: NSObject, PublicProtocol {
>   func someFunction() {
>   // implementation
>   }
> }
> 
> Type 'SomeClass' does not conform to protocol 'PublicProtocol'
> Fix-it: Candidate is not '@objc', but protocol requires it
> 


I believe that is what I saw when I made the class private, it required an 
explicit @objc, in my case it said it required @objc because the method was 
optional. 

So after this discussion, which was as-usual helpful, I see why you can use a 
protocol in a class with lesser access rights. The last question I had was, if 
I define a private class to conform to a public protocol, and then arrange in 
the same source file a public class which creates an instance of the private 
one and returns it as a protocol type, can I then use it. And the answer was 
yes I can.  I had an entirely private Bar implementing a public protocol Foo 
and a public struct Baz in the same source file as Bar which had a 
returnAsFoo() method which returned a Bar .. as a Foo. I was able to use that 
in a playground even though Bar was entirely inaccessible from the playground. 

So this all makes more sense now. 



___

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: Swift - internal class conforming to public protocol

[Roland King]

> On 25 Nov 2015, at 16:37, Quincey Morris 
>  wrote:
> 
> On Nov 25, 2015, at 00:30 , Andreas Mayer  wrote:
>> 
>> I can't replicate that behavior.
> 
> Since Roland hasn’t contributed to this thread for 24 hours, I vote we blame 
> *him*. ;)
> 
> 

I just did - some of us occasionally sleep, I just occasionally slept at 4 in 
the afternoon just because I could. Then I went and tried the last question I 
had. 

Which thing of the many was Andreas saying he couldn’t replicate? 
___

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: Swift - internal class conforming to public protocol

[Roland King]

> On 25 Nov 2015, at 16:30, Andreas Mayer  wrote:
> 
> 
>> Am 25.11.2015 um 08:56 schrieb Quincey Morris 
>> :
>> 
>>> That's explained in "Using Swift with Cocoa and Objective-C":
>>> 
>>> "The compiler does not automatically insert the @objc attribute for 
>>> declarations marked with the private access-level modifier.”
>> 
>> That can’t be the full explanation, because the other private method doesn’t 
>> produce an error, Roland said.
> 
> I can't replicate that behavior.
> 
> This doesn't work:
> 
> // Roland's protocol must be marked @objc since it has optional requirements.
> 
> @objc public protocol PublicProtocol {
>   func someFunction()
>   // ...
> }
> 
> private class SomeClass: NSObject, PublicProtocol {
>   func someFunction() {
>   // implementation
>   }
> }

here’s my distilled example

import CoreBluetooth
private class Bananas : NSObject, CBCentralManagerDelegate
{
func centralManagerDidUpdateState(central: CBCentralManager)->Void {
// do nothing, I care little for your state
}

func centralManager(central: CBCentralManager, didRetrievePeripherals 
peripherals: [CBPeripheral])
{
// do nothing, you retrieved peripherals, I don't care
}
}

with the private designator, you get a warning on the second function about 
optionality and @obcj, and an error, not on the first, but on the entire class 
telling you the first function needs to be marked @objc, but not for 
optionality reasons, just says that the candidate is not @objc but the protocol 
requires it. So they both need objc, but for slightly different reasons, and 
the errors are reported in slightly different ways

change it to internal, no errors, no warnings, as now expected

change it to public and you get errors on both functions telling you to make 
them public, also as now expected. 

___

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