Re: Avoiding link conflicts with a static library

[Saagar Jha]

I’m basing this on rdar://problem/19209161 , which 
appears to still be open. I haven’t tried this myself.

Saagar Jha

> On Apr 5, 2018, at 18:06, Alex Zavatone  wrote:
> 
> 
>> On Apr 5, 2018, at 7:49 PM, Saagar Jha > > wrote:
>> 
>> I think there used to be a bug (might still be?) where Xcode didn’t 
>> automatically strip out the x86 simulator slices when you were archiving.
>> 
>> Saagar Jha
> 
> When looking at the Archive scheme, it should use Release as the build 
> config.  Release will not have i386 in it unless you add it manually.  Like I 
> said, if you set this up in the build configurations, you should be able to 
> get this all to be done automatically.  
> 
> Unless I’m wrong and someone is willing to share a better way to get this 
> organized within Xcode.
> 
> Cheers,
> - Alex Zavatone

___

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: Avoiding link conflicts with a static library

[Alex Zavatone]

> On Apr 5, 2018, at 7:49 PM, Saagar Jha  wrote:
> 
> I think there used to be a bug (might still be?) where Xcode didn’t 
> automatically strip out the x86 simulator slices when you were archiving.
> 
> Saagar Jha

When looking at the Archive scheme, it should use Release as the build config.  
Release will not have i386 in it unless you add it manually.  Like I said, if 
you set this up in the build configurations, you should be able to get this all 
to be done automatically.  

Unless I’m wrong and someone is willing to share a better way to get this 
organized within Xcode.

Cheers,
- Alex Zavatone
___

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: Avoiding link conflicts with a static library

[Saagar Jha]

I think there used to be a bug (might still be?) where Xcode didn’t 
automatically strip out the x86 simulator slices when you were archiving.

Saagar Jha

> On Apr 5, 2018, at 07:29, Alex Zavatone  wrote:
> 
> 
>> On Apr 5, 2018, at 4:19 AM, Redler Eyal  wrote:
>> 
 
> 2. (More importantly) It makes the client's binary larger since it will 
> have to include our full library, including simulator code. (correct me 
> if I'm wrong)
 
 No, you should ask your client to remove the simulator slice before 
 submitting to the App Store.
>>> 
>>> This is controlled in the build settings for release builds.  Compiled 
>>> Simulator code is not packaged and should not be packaged in a release 
>>> build.
>> 
>> My understanding is that the dynamic lib is copied as a resource and not 
>> processed automatically that way.
>> 
> 
> 
> But when it is built, it is built as Release or Debug, unless you have added 
> other build configurations.  When Archive is selected, that uses Release.
> 
> Why would a Simulator i386 architecture be used in a release build?  You can 
> check the configuration and see if that architecture is even there in the 
> build config.
> 
> - Alex Zavatone
> 
> ___
> 
> 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/saagar%40saagarjha.com
> 
> This email sent to saa...@saagarjha.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Avoiding link conflicts with a static library

[Saagar Jha]

You could weak link against OpenCV then dlopen it at runtime depending on 
whether it’s already loaded or not. As for packaging, I’d stick them both in a 
zip with a README telling them where to drag each thing in Xcode.

Saagar Jha

> On Apr 5, 2018, at 01:42, Redler Eyal  wrote:
> 
> We have two issues with the dynamic framework
> 1. It makes it easier to pirate our technology (having our stuff neatly 
> packaged seperaterly)
 
 I may be misunderstanding you, but why does your code need to be separate? 
 Can’t you statically link against your framework, which dynamically opens 
 OpenCV (packaged as a framework)?
>>> 
>>> At the moment, we deliver a static framework. This is linked statically to 
>>> the client's app and delivered inside the main executable to the app store. 
>>> If we switch to a dynamic library then our library will be a separate 
>>> component that is delivered as such to the app store. The potential pirate 
>>> will only have to dig our the library from the application package (and 
>>> overcome the other protections, of-course)
>> 
>> OK, but is there anything stopping you from having your static library 
>> dynamically open OpenCV?
> 
> Perhaps not but I'm wondering
> a. Will it actually solve the issue (the conflict with the clients OpenCV)?
> b. Is it possible to package a static framework with a dynamic library in one 
> package?
> 
> 
> ___
> 
> 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/saagar%40saagarjha.com
> 
> This email sent to saa...@saagarjha.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: runModalSession handling

[Quincey Morris]

On Apr 5, 2018, at 15:27 , Tom Doan  wrote:
> 
> I checked and none of my stopModalWithCodes are being fired, so the result 
> code has to be coming off the system dialog. I did a kludge where I used 100 
> and 101 for my own stop codes, and continued on 0 and 1, and that seemed to 
> work around this

This does sound like a bug, but it’s hard to know. Using different stop codes 
seems like a rational way to approach the problem.

Other possibilities you might investigate:

1. Close the modal window before using the NSOpenPanel, then reopen it with a 
new modal session afterwards.

2. Display the NSOpenPanel as a sheet on the modal window, rather than a 
separate window.

Is Carbon involved here in any way? This code looks like it was Carbon once, at 
least.

___

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: problem getting CALayer to draw an image

[James Walker]

Sorry about the mysterious blank posts.  Let's see if I can do it with 
plain text rather than HTML.



On 4/5/2018 11:05 AM, David Duncan wrote:
>> On Apr 5, 2018, at 10:53 AM, James Walker  
wrote:

>>
>> I have a generic NSView that contains some subviews, and I'd like to 
add a background image.  I tried code like this:

>>
>> NSImage* backgroundImage = [NSImage imageNamed: @"blueprint 
controls.png"];

>> CALayer* holderLayer = [CALayer layer];
>> _throttleHolder.layer = holderLayer;
>> _throttleHolder.wantsLayer = YES;
>> holderLayer.zPosition = 4.0f;
>> holderLayer.contents = backgroundImage;
>> holderLayer.hidden = NO;
>> holderLayer.bounds = NSRectToCGRect( _throttleHolder.bounds );
>> [holderLayer setNeedsDisplay];
> You don’t need to call -setNeedsDisplay here, and it may be what is 
destroying your content (when a layer displays, its stores the result of 
drawing in contents – you don’t want that since you are setting the 
contents directly).


Thank you (and also thanks to Rob Petrovec).  I think my first try 
didn't have that line, but when it didn't work, I started making 
desperate changes.  In my first attempt, I tried using the layer that 
the view already owned by virtue of being marked layer-backed in the 
nib, rather than adding my own layer.


For the record, I get correct results with just this:

NSImage* backgroundImage = [NSImage imageNamed: @"blueprint controls.png"];
_throttleHolder.layer = [CALayer layer];
_throttleHolder.layer.contents = backgroundImage;

___

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

runModalSession handling

[Tom Doan]

Based upon a recommendation that I found, I changed up code from running a 
modal dialog to use 
beginModalSessionForWindow and runModalSession. Unfortunately, if I run an 
NSOpenPanel from within this 
(used for a browse for a target directory), runModalSession for *my* dialog 
returns the 0 or 1 off the open panel 
as soon as that closes, thus (with my expected handling) closing my dialog as 
well. I checked and none of my 
stopModalWithCodes are being fired, so the result code has to be coming off the 
system dialog. I did a kludge 
where I used 100 and 101 for my own stop codes, and continued on 0 and 1, and 
that seemed to work around 
this, but I would really like to understand what is wrong with this setup.

Best regards,

Tom Doan
---
1560 Sherman Ave #1029
Evanston, IL 60201
USA




#if 0
//
//  Original code
//
itsRC = (LOGICAL) ([NSApp runModalForWindow:itsDialog->GetDlgWnd()]);
#else
//
//  Code which gives main loop time
//
NSModalSession session = [NSApp 
beginModalSessionForWindow:itsDialog->GetDlgWnd()];
int result = NSModalResponseContinue;

while (result == NSModalResponseContinue)
{
//run the modal session
//once the modal window finishes, it will return a different 
result and break out of the loop
result = [NSApp runModalSession:session];

//this gives the main run loop some time so your other code 
processes
[[NSRunLoop currentRunLoop] 
limitDateForMode:NSDefaultRunLoopMode];

//do some other non-intensive task if necessary
}
[NSApp endModalSession:session];
itsRC = (LOGICAL) (result);
#endif



___

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: Avoiding link conflicts with a static library

[Alex Zavatone]

> On Apr 5, 2018, at 3:05 PM, Jim Adams  wrote:
> 
> We build ours using archive before lipo-ing and we don’t have to strip the 
> simulator bits out.

My point was that when you distribute to clients, they will want to test using 
a simulator, but will want to ship without it.  So, you’ll likely need to 
distribute more than one binary.

If a crash is discovered in your framework by the client or by the client’s 
clients, they are going to want to have simulator and debug symbols support to 
debug.  

Shipping anything out of your company with debug symbols will often be regarded 
as a security risk, so there is that to consider regarding your intellectual 
property and agreements with the client.  That’s for the managers to decide.

This leaves you with the potential for 3 copies of the binary that you may need 
to distribute.

I managed this by creating build configs for each and then built or archived 
according to what was needed.

- Alex Zavatone
___

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: problem getting CALayer to draw an image (repost)

[James Walker]

___

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: Avoiding link conflicts with a static library

[Jim Adams]

We build ours using archive before lipo-ing and we don’t have to strip the 
simulator bits out.

> On Apr 5, 2018, at 4:03 PM, Cody Garvin  wrote:
> 
> EXTERNAL
> 
> We send them one that is lipod then give them a build phase script that 
> strips the opposite architecture out. A bit easier than switching frameworks 
> that could potentially have different versions and avoid separate targets to 
> add the different architecture library to. Let me know if you’d like our 
> script.
> 
> Please excuse mobile typos
> 
>> On Apr 5, 2018, at 12:04 PM, Alex Zavatone  wrote:
>> 
>> 
>>> On Apr 5, 2018, at 1:37 PM, Redler Eyal  wrote:
>>> 
>>> 
 On 5 Apr 2018, at 17:29, Alex Zavatone  wrote:
 
 
> On Apr 5, 2018, at 4:19 AM, Redler Eyal  wrote:
> 
>>> 
 2. (More importantly) It makes the client's binary larger since it 
 will have to include our full library, including simulator code. 
 (correct me if I'm wrong)
>>> 
>>> No, you should ask your client to remove the simulator slice before 
>>> submitting to the App Store.
>> 
>> This is controlled in the build settings for release builds.  Compiled 
>> Simulator code is not packaged and should not be packaged in a release 
>> build.
> 
> My understanding is that the dynamic lib is copied as a resource and not 
> processed automatically that way.
> 
 
 
 But when it is built, it is built as Release or Debug, unless you have 
 added other build configurations.  When Archive is selected, that uses 
 Release.
 
 Why would a Simulator i386 architecture be used in a release build?  You 
 can check the configuration and see if that architecture is even there in 
 the build config.
>>> 
>>> Because we are building an SDK - for other developers that need to be able 
>>> to run their app, with our SDK, in the simulator.
>>> 
>> 
>> I have done this twice.  If you need to distribute a version of the 
>> framework witth simulator code in it, then you will need another build 
>> configuration that does include this.  Duplicate a build config and add 
>> i386.  If you need to strip debug symbols or add debug symbols, then 
>> duplicate another build configuration and add or remove those settings.
>> 
>> Create as many build configurations as needed by duplicating and modifying 
>> what is needed.  Clearly document this for your customer.  Build them what 
>> they need and send them all the frameworks to link to.  Yes, it’s hard.
>> 
>> - Alex Zavatone
>> ___
>> 
>> 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/cody%40servalsoft.com
>> 
>> This email sent to c...@servalsoft.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/jim.adams%40sas.com
> 
> This email sent to jim.ad...@sas.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Avoiding link conflicts with a static library

[Cody Garvin]

We send them one that is lipod then give them a build phase script that strips 
the opposite architecture out. A bit easier than switching frameworks that 
could potentially have different versions and avoid separate targets to add the 
different architecture library to. Let me know if you’d like our script. 

Please excuse mobile typos

> On Apr 5, 2018, at 12:04 PM, Alex Zavatone  wrote:
> 
> 
>> On Apr 5, 2018, at 1:37 PM, Redler Eyal  wrote:
>> 
>> 
>>> On 5 Apr 2018, at 17:29, Alex Zavatone  wrote:
>>> 
>>> 
 On Apr 5, 2018, at 4:19 AM, Redler Eyal  wrote:
 
>> 
>>> 2. (More importantly) It makes the client's binary larger since it will 
>>> have to include our full library, including simulator code. (correct me 
>>> if I'm wrong)
>> 
>> No, you should ask your client to remove the simulator slice before 
>> submitting to the App Store.
> 
> This is controlled in the build settings for release builds.  Compiled 
> Simulator code is not packaged and should not be packaged in a release 
> build.
 
 My understanding is that the dynamic lib is copied as a resource and not 
 processed automatically that way.
 
>>> 
>>> 
>>> But when it is built, it is built as Release or Debug, unless you have 
>>> added other build configurations.  When Archive is selected, that uses 
>>> Release.
>>> 
>>> Why would a Simulator i386 architecture be used in a release build?  You 
>>> can check the configuration and see if that architecture is even there in 
>>> the build config.
>> 
>> Because we are building an SDK - for other developers that need to be able 
>> to run their app, with our SDK, in the simulator.
>> 
> 
> I have done this twice.  If you need to distribute a version of the framework 
> witth simulator code in it, then you will need another build configuration 
> that does include this.  Duplicate a build config and add i386.  If you need 
> to strip debug symbols or add debug symbols, then duplicate another build 
> configuration and add or remove those settings.
> 
> Create as many build configurations as needed by duplicating and modifying 
> what is needed.  Clearly document this for your customer.  Build them what 
> they need and send them all the frameworks to link to.  Yes, it’s hard.  
> 
> - Alex Zavatone
> ___
> 
> 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/cody%40servalsoft.com
> 
> This email sent to c...@servalsoft.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: problem getting CALayer to draw an image

[James Walker]

___

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: problem getting CALayer to draw an image

[James Walker]

___

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: Avoiding link conflicts with a static library

[Alex Zavatone]

> On Apr 5, 2018, at 1:37 PM, Redler Eyal  wrote:
> 
> 
>> On 5 Apr 2018, at 17:29, Alex Zavatone  wrote:
>> 
>> 
>>> On Apr 5, 2018, at 4:19 AM, Redler Eyal  wrote:
>>> 
> 
>> 2. (More importantly) It makes the client's binary larger since it will 
>> have to include our full library, including simulator code. (correct me 
>> if I'm wrong)
> 
> No, you should ask your client to remove the simulator slice before 
> submitting to the App Store.
 
 This is controlled in the build settings for release builds.  Compiled 
 Simulator code is not packaged and should not be packaged in a release 
 build.
>>> 
>>> My understanding is that the dynamic lib is copied as a resource and not 
>>> processed automatically that way.
>>> 
>> 
>> 
>> But when it is built, it is built as Release or Debug, unless you have added 
>> other build configurations.  When Archive is selected, that uses Release.
>> 
>> Why would a Simulator i386 architecture be used in a release build?  You can 
>> check the configuration and see if that architecture is even there in the 
>> build config.
> 
> Because we are building an SDK - for other developers that need to be able to 
> run their app, with our SDK, in the simulator.
> 

I have done this twice.  If you need to distribute a version of the framework 
witth simulator code in it, then you will need another build configuration that 
does include this.  Duplicate a build config and add i386.  If you need to 
strip debug symbols or add debug symbols, then duplicate another build 
configuration and add or remove those settings.

Create as many build configurations as needed by duplicating and modifying what 
is needed.  Clearly document this for your customer.  Build them what they need 
and send them all the frameworks to link to.  Yes, it’s hard.  

- Alex Zavatone
___

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: Avoiding link conflicts with a static library

[Redler Eyal]

> On 5 Apr 2018, at 17:29, Alex Zavatone  wrote:
> 
> 
>> On Apr 5, 2018, at 4:19 AM, Redler Eyal  wrote:
>> 
 
> 2. (More importantly) It makes the client's binary larger since it will 
> have to include our full library, including simulator code. (correct me 
> if I'm wrong)
 
 No, you should ask your client to remove the simulator slice before 
 submitting to the App Store.
>>> 
>>> This is controlled in the build settings for release builds.  Compiled 
>>> Simulator code is not packaged and should not be packaged in a release 
>>> build.
>> 
>> My understanding is that the dynamic lib is copied as a resource and not 
>> processed automatically that way.
>> 
> 
> 
> But when it is built, it is built as Release or Debug, unless you have added 
> other build configurations.  When Archive is selected, that uses Release.
> 
> Why would a Simulator i386 architecture be used in a release build?  You can 
> check the configuration and see if that architecture is even there in the 
> build config.

Because we are building an SDK - for other developers that need to be able to 
run their app, with our SDK, in the simulator.




___

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: problem getting CALayer to draw an image

[David Duncan]

> On Apr 5, 2018, at 10:53 AM, James Walker  wrote:
> 
> I have a generic NSView that contains some subviews, and I'd like to add a 
> background image.  I tried code like this:
> 
> NSImage* backgroundImage = [NSImage imageNamed: @"blueprint controls.png"];
> CALayer* holderLayer = [CALayer layer];
> _throttleHolder.layer = holderLayer;
> _throttleHolder.wantsLayer = YES;
> holderLayer.zPosition = 4.0f;
> holderLayer.contents = backgroundImage;
> holderLayer.hidden = NO;
> holderLayer.bounds = NSRectToCGRect( _throttleHolder.bounds );
> [holderLayer setNeedsDisplay];

You don’t need to call -setNeedsDisplay here, and it may be what is destroying 
your content (when a layer displays, its stores the result of drawing in 
contents – you don’t want that since you are setting the contents directly).

Overall however, I think AppKit has an NSView method (something like 
updateLayer I think) that you want to override to do this. The layer’s geometry 
should already be set by AppKit and you should not modify it if I recall 
correctly. Geometry includes things such as center/bounds/frame and hidden.

> 
> But no background image shows up.  On the other hand, if I add the line
> 
> holderLayer.backgroundColor = CGColorGetConstantColor( kCGColorWhite );
> 
> then I get a white background, so apparently the layer is there and capable 
> of drawing.  And yes, I have made sure that backgroundImage is not nil.
> 
> At this point, it probably would have been quicker to just go ahead and 
> subclass NSView, but I'm curious about what dumb mistake I'm making.
> ___
> 
> 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/david.duncan%40apple.com
> 
> This email sent to david.dun...@apple.com

--
David Duncan

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: problem getting CALayer to draw an image

[Rob Petrovec]

If you take out the setNeedsDisplay it draws ok.

—Rob


> On Apr 5, 2018, at 11:53 AM, James Walker  wrote:
> 
> I have a generic NSView that contains some subviews, and I'd like to add a 
> background image.  I tried code like this:
> 
> NSImage* backgroundImage = [NSImage imageNamed: @"blueprint controls.png"];
> CALayer* holderLayer = [CALayer layer];
> _throttleHolder.layer = holderLayer;
> _throttleHolder.wantsLayer = YES;
> holderLayer.zPosition = 4.0f;
> holderLayer.contents = backgroundImage;
> holderLayer.hidden = NO;
> holderLayer.bounds = NSRectToCGRect( _throttleHolder.bounds );
> [holderLayer setNeedsDisplay];
> 
> But no background image shows up.  On the other hand, if I add the line
> 
> holderLayer.backgroundColor = CGColorGetConstantColor( kCGColorWhite );
> 
> then I get a white background, so apparently the layer is there and capable 
> of drawing.  And yes, I have made sure that backgroundImage is not nil.
> 
> At this point, it probably would have been quicker to just go ahead and 
> subclass NSView, but I'm curious about what dumb mistake I'm making.
> ___
> 
> 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/petrock%40mac.com
> 
> This email sent to petr...@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/archive%40mail-archive.com

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

problem getting CALayer to draw an image

[James Walker]

I have a generic NSView that contains some subviews, and I'd like to add 
a background image.  I tried code like this:


NSImage* backgroundImage = [NSImage imageNamed: @"blueprint controls.png"];
CALayer* holderLayer = [CALayer layer];
_throttleHolder.layer = holderLayer;
_throttleHolder.wantsLayer = YES;
holderLayer.zPosition = 4.0f;
holderLayer.contents = backgroundImage;
holderLayer.hidden = NO;
holderLayer.bounds = NSRectToCGRect( _throttleHolder.bounds );
[holderLayer setNeedsDisplay];

But no background image shows up.  On the other hand, if I add the line

holderLayer.backgroundColor = CGColorGetConstantColor( kCGColorWhite );

then I get a white background, so apparently the layer is there and 
capable of drawing.  And yes, I have made sure that backgroundImage is 
not nil.


At this point, it probably would have been quicker to just go ahead and 
subclass NSView, but I'm curious about what dumb mistake I'm making.

___

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: UITabBarItem selection Voice over speaks number apart from accessibility label,value

[David Duncan]

Can you file a bug with a complete sample and report the bug# back to the list?

It isn’t immediately obvious to me where the numbers you report are coming 
from, or why accessibility would speak them, but I can take a look once I have 
a sample in front of me.

> On Apr 5, 2018, at 4:37 AM, Devarshi Kulshreshtha 
>  wrote:
> 
> I am programmatically assigning bar button items to  UITabBar using below
> code:
> 
> -(void)setupTabs {
>UIImage *icon1 = [[UIImage imageNamed:@"Icon1"]
> imageWithRenderingMode:UIImageRenderingModeAlwaysTemplate];
>UITabBarItem *option1 = [[UITabBarItem alloc] initWithTitle:@"Option1"
> image: icon1 selectedImage: icon1];
> 
>UIImage *icon2 = [[UIImage imageNamed:@"Icon2"]
> imageWithRenderingMode:UIImageRenderingModeAlwaysTemplate];
>UITabBarItem *option2 = [[UITabBarItem alloc] initWithTitle:@"Option2"
> image: icon2 selectedImage: icon2];
> 
>UIImage *icon3 = [[UIImage imageNamed:@"Icon3"]
> imageWithRenderingMode:UIImageRenderingModeAlwaysTemplate];
>UITabBarItem *option3 = [[UITabBarItem alloc] initWithTitle:@"Option3"
> image: icon3 selectedImage: icon3];
> 
>UIImage *icon4 = [[UIImage imageNamed:@"Icon4"]
> imageWithRenderingMode:UIImageRenderingModeAlwaysTemplate];
>UITabBarItem *option4 = [[UITabBarItem alloc] initWithTitle:@"Option4"
> image: icon4 selectedImage: icon4];
> 
>self.tabBar.items = @[option1, option2, option3, option4];
> }
> 
> Problem is - when I am tapping on respective tab bar item after enabling
> Accessibility - Voice Over it is stating the tab bar title as well as
> number 104 for first tab, 204 for second tab and so on.
> 
> I have tried explicitly setting the accessibilityValue, accessibilityLabel,
> etc for items but it is always speaking the number after title.
> 
> Any ideas on how to stop voice over from speaking that number after title?
> 
> Thanks
> 
> 
> 
> -- 
> Thanks,
> 
> Devarshi
> ___
> 
> 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/david.duncan%40apple.com
> 
> This email sent to david.dun...@apple.com

--
David Duncan

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Avoiding link conflicts with a static library

[Alex Zavatone]

> On Apr 5, 2018, at 4:19 AM, Redler Eyal  wrote:
> 
>>> 
 2. (More importantly) It makes the client's binary larger since it will 
 have to include our full library, including simulator code. (correct me if 
 I'm wrong)
>>> 
>>> No, you should ask your client to remove the simulator slice before 
>>> submitting to the App Store.
>> 
>> This is controlled in the build settings for release builds.  Compiled 
>> Simulator code is not packaged and should not be packaged in a release build.
> 
> My understanding is that the dynamic lib is copied as a resource and not 
> processed automatically that way.
> 


But when it is built, it is built as Release or Debug, unless you have added 
other build configurations.  When Archive is selected, that uses Release.

Why would a Simulator i386 architecture be used in a release build?  You can 
check the configuration and see if that architecture is even there in the build 
config.

- Alex Zavatone

___

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

UITabBarItem selection Voice over speaks number apart from accessibility label,value

[Devarshi Kulshreshtha]

I am programmatically assigning bar button items to  UITabBar using below
code:

-(void)setupTabs {
UIImage *icon1 = [[UIImage imageNamed:@"Icon1"]
imageWithRenderingMode:UIImageRenderingModeAlwaysTemplate];
UITabBarItem *option1 = [[UITabBarItem alloc] initWithTitle:@"Option1"
image: icon1 selectedImage: icon1];

UIImage *icon2 = [[UIImage imageNamed:@"Icon2"]
imageWithRenderingMode:UIImageRenderingModeAlwaysTemplate];
UITabBarItem *option2 = [[UITabBarItem alloc] initWithTitle:@"Option2"
image: icon2 selectedImage: icon2];

UIImage *icon3 = [[UIImage imageNamed:@"Icon3"]
imageWithRenderingMode:UIImageRenderingModeAlwaysTemplate];
UITabBarItem *option3 = [[UITabBarItem alloc] initWithTitle:@"Option3"
image: icon3 selectedImage: icon3];

UIImage *icon4 = [[UIImage imageNamed:@"Icon4"]
imageWithRenderingMode:UIImageRenderingModeAlwaysTemplate];
UITabBarItem *option4 = [[UITabBarItem alloc] initWithTitle:@"Option4"
image: icon4 selectedImage: icon4];

self.tabBar.items = @[option1, option2, option3, option4];
}

Problem is - when I am tapping on respective tab bar item after enabling
Accessibility - Voice Over it is stating the tab bar title as well as
number 104 for first tab, 204 for second tab and so on.

I have tried explicitly setting the accessibilityValue, accessibilityLabel,
etc for items but it is always speaking the number after title.

Any ideas on how to stop voice over from speaking that number after title?

Thanks



-- 
Thanks,

Devarshi
___

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: Avoiding link conflicts with a static library

[Redler Eyal]

>> 
>>> 2. (More importantly) It makes the client's binary larger since it will 
>>> have to include our full library, including simulator code. (correct me if 
>>> I'm wrong)
>> 
>> No, you should ask your client to remove the simulator slice before 
>> submitting to the App Store.
> 
> This is controlled in the build settings for release builds.  Compiled 
> Simulator code is not packaged and should not be packaged in a release build.

My understanding is that the dynamic lib is copied as a resource and not 
processed automatically that way.

___

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: Avoiding link conflicts with a static library

[Redler Eyal]

> 
>>> No, you should ask your client to remove the simulator slice before 
>>> submitting to the App Store.
>> 
>> I guess, but it would hurt the usage simplicity. Certainly compared to the 
>> current solution as a static library.
> 
> Any app using Carthage already has to do this, so it's apparently not a deal 
> breaker for many developers.

I guess so and still, it is a bit worse then it was. I was hoping to find a 
solution that would just work for the existing and future clients.

___

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: Avoiding link conflicts with a static library

[Redler Eyal]

 We have two issues with the dynamic framework
 1. It makes it easier to pirate our technology (having our stuff neatly 
 packaged seperaterly)
>>> 
>>> I may be misunderstanding you, but why does your code need to be separate? 
>>> Can’t you statically link against your framework, which dynamically opens 
>>> OpenCV (packaged as a framework)?
>> 
>> At the moment, we deliver a static framework. This is linked statically to 
>> the client's app and delivered inside the main executable to the app store. 
>> If we switch to a dynamic library then our library will be a separate 
>> component that is delivered as such to the app store. The potential pirate 
>> will only have to dig our the library from the application package (and 
>> overcome the other protections, of-course)
> 
> OK, but is there anything stopping you from having your static library 
> dynamically open OpenCV?

Perhaps not but I'm wondering
a. Will it actually solve the issue (the conflict with the clients OpenCV)?
b. Is it possible to package a static framework with a dynamic library in one 
package?


___

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