Re: Mystery interference with AirPlay

2022-06-15 Thread Glenn L. Austin via Cocoa-dev 
Do you use the AV framework to play videos?

If so, that sets up to play sound even if you don't actually play any sound.

--
Glenn L. Austin, Computer Wizard and Race Car Driver <><


> On Jun 15, 2022, at 9:33 AM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> There is no sound whatsoever from my app.
> 
> Best, G.
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/glenn%40austinsoft.com
> 
> This email sent to gl...@austinsoft.com



signature.asc
Description: Message signed with OpenPGP
___

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

Please do not post admin requests or moderator comments to the list.
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: Special question about NSOpenPanel

2021-05-30 Thread Glenn L. Austin via Cocoa-dev 
> On May 30, 2021, at 5:55 AM, Steve Mills via Cocoa-dev 
>  wrote:
> 
>> On May 30, 2021, at 06:46, Gabriel Zachmann via Cocoa-dev 
>>  wrote:
>> 
>> Thanks again for the hints.
>> In the meantime I have found out that it seems like legacyScreenSaver under 
>> macOS 10.15.0 does not have the right entitlements.
> 
> Didn’t we cover this a couple years ago? No, you can’t do anything other than 
> submit the problem to Apple and hope they do something about it.
> 
> Steve via iPad

Your only option is to have a separate application that displays your 
NSOpenPanel to set your preferences.

-- 
Glenn L. Austin, Computer Wizard and Race Car Driver <><


___

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

Please do not post admin requests or moderator comments to the list.
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: Free trial period for apps in Mac App Store (?)

2020-09-02 Thread Glenn L. Austin via Cocoa-dev 
I also did this (Lite and regular versions) built from the same sources. Well, 
almost the same sources since the regular version didn't include IAP.

There were a lot of conditionals, and it was written before Swift was even a 
line of code...

-- 
Glenn L. Austin, Computer Wizard and Race Car Driver <><


> On Sep 2, 2020, at 12:26 AM, Dave via Cocoa-dev  
> wrote:
> 
> Hi,
> 
> The “Light” version doesn’t take much more effort to support since its built 
> from the same source code. I actually found this the easiest and most 
> straight forward way of doing it.
> 
> Cheers
> Dave
> 
>> On 1 Sep 2020, at 22:27, Gabriel Zachmann via Cocoa-dev 
>>  wrote:
>> 
>>> Make a ?Lite? version free (Price 0.00) which has either a limited life 
>>> span or limited functionality or both.
>>> [...]
>>> The other option is to use ?In App Purchases? to upgrade the functionality.
>>> 
>> 
>> Thanks a lot for your response.
>> 
>> Option 1 would mean, in my case: develop and maintain two versions,
>> "Light" version includes full functionality, but expires after a month,
>> "Pro" version costs.
>> 
>> Option 2:
>> Only one version, with in-app purchase to unlock unlimited time.
>> 
>> 
>> I was wondering: what is your experience in terms of
>> - user experience
>> - development effort.
>> Is it more effort to develop and maintain light & pro version,
>> or is it more effort to implement the in-app purchase?
>> (The latter involves some purchases management, IIUC, for instance, if a 
>> user buys a new Mac.)
>> 
>> 
>> What are your thoughts?
>> 
>> 
>> 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/dave%40looktowindward.com
>> 
>> This email sent to d...@looktowindward.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/glenn%40austinsoft.com
> 
> This email sent to gl...@austinsoft.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: Question about Info.plist's

2020-08-19 Thread Glenn L. Austin via Cocoa-dev 
No, you can't use an "earlier" key to create a "later" value - but you can use 
code to do basically the same thing.

Or, you can use the same variable that sets your CFBuildNumber to set your 
CFBundleVersion.

--
Glenn L. Austin, Computer Wizard and Race Car Driver <><


> On Aug 19, 2020, at 9:07 AM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> Question:
> 
> Is there a way to use a key/value that was defined earlier in the plist file
> to define a value for a later key?
> 
> Explanation:
> I have a macOS project with an automatically created "About" window.
> The plist file has, additionally to all the default stuff, the key 
> CFBuildNumber (with a value that I increment automatically).
> 
> In Xcode, I tried to change "Bundle version" to a value like
> 
>   $(CURRENT_PROJECT_VERSION)_$(CFBuildNumber)
> 
> However, in the final Info.plist in the app's bundle, this then looks like
> 
>CFBundleVersion
>3.1_
> 
> Notice the underscore, but the value of CFBuildNumber is gone.
> "3.1", BTW, is the value I have set under
> 
>Project / Targets / General / Identity / Build
> 
> I have tried to change parentheses into curly braces, to no avail.
> 
> So, question again: is there a way to use a key/value that was defined 
> earlier in the plist file
> to define a value for a later key?
> I'd like to do that so that the "About" window contains the build number, too.
> 
> Thanks a lot in advance.
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/glenn%40austinsoft.com
> 
> This email sent to gl...@austinsoft.com



signature.asc
Description: Message signed with OpenPGP
___

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

Please do not post admin requests or moderator comments to the list.
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: [OT] NSTimer +timerWithTimeInterval:

2020-05-04 Thread Glenn L. Austin via Cocoa-dev 
ARC uses the analyzers rules. I was told that if you trust the analyzer (and 
follow it's rules), ARC will be fine.

I have a few pieces of code that the analyzer was unhappy with, bugs had been 
submitted, but they were primarily with C++ code wrapping CF objects.

-- 
Glenn L. Austin, Computer Wizard and Race Car Driver <><


> On May 3, 2020, at 11:46 PM, Dave via Cocoa-dev  
> wrote:
> 
> Yes, that’s correct, nothing wrong with a method beginning with new as long 
> as it follows the rules, I use it all the time.
> 
> I’m not sure if it matters at all with ARC, but I stick by the rules anyway.
> 
> Cheers
> Dave
> 
>> On 30 Apr 2020, at 00:27, Sandor Szatmari via Cocoa-dev 
>>  wrote:
>> 
>> Alex,
>> 
>>> On Apr 29, 2020, at 17:12, Alex Zavatone via Cocoa-dev 
>>>  wrote:
>>> 
>>> Not sure about this, but in Objective-C, you’re not supposed to start 
>>> methods with new.
>> 
>> I’ve always operated under the premise that using a reserved prefix, such as 
>> new, was not verboten.  Rather, if one chose the prefix new one must ensure 
>> that the method followed memory management conventions, and would return an 
>> object with a +1 retain count.  Am I mistaken about this?
>> 
>> Sandor
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/glenn%40austinsoft.com
> 
> This email sent to gl...@austinsoft.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: Open a panel in secondary thread?

2020-03-23 Thread Glenn L. Austin via Cocoa-dev 
Correct.

main_queue will *always* be on the main thread, but the main thread may be 
running a different queue at any specific point in time.

So, if you're *not* on the main thread, throwing code over to the main queue to 
execute will guarantee that it's on the main thread - but not vice-versa.

> On Mar 23, 2020, at 8:25 AM, Alex Zavatone via Cocoa-dev 
>  wrote:
> 
> Main queue is analogous to the main thread, but not exactly the same - 
> according to Apple’s docs.
> 
> Sent from my iPhone
> 
>> On Mar 23, 2020, at 12:53 PM, Gabriel Zachmann via Cocoa-dev 
>>  wrote:
>> 
>> Thanks a lot for your response.
>> 
>>> I would not do this.  It is widely documented that AppKit API that produce 
>>> UI elements, like NSOpenPanel, are _not_ thread safe.  
>> 
>> Right, and that is why I have to execute any UI code in the main thread,
>> or so I thought.
>> As far as I understand, the dispatch_get_main_queue is executed by the main 
>> thread, isn't it?
>> 
>> 
>>> So you may find your app hitting some memory stomping issues or strange 
>>> crashes/exceptions due to this.  Specifically what problems you will hit 
>>> are anyones guess, but its just a matter of time.  There is a reason Xcode 
>>> has the Main Thread Checker to catch UI elements being used on secondary 
>>> threads.
>>> 
>>> Lets come at  this from a different direction: What are you trying to do? 
>>> Why do you think you need to use the open panel on a secondary thread?
>> 
>> When the user selects a directory, I collect all files in that sub-tree (aka 
>> "scan").
>> That might involve aliases. which means I need to ask the user to open the 
>> directory that alias points to.
>> Because that scan can take several seconds (10-20),
>> I wanted to do that scan in a secondary thread so that it can update 
>> progress info in the UI.
>> 
>> 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/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/glenn%40austinsoft.com
> 
> This email sent to gl...@austinsoft.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: Future of Cocoa #2

2019-12-10 Thread Glenn L. Austin via Cocoa-dev 
> On Dec 10, 2019, at 12:58 PM, Richard Charles via Cocoa-dev 
>  wrote:
> 
> 
>> On Dec 10, 2019, at 10:55 AM, Turtle Creek Software via Cocoa-dev 
>>  wrote:
>> 
>> Thoughts?
>> 
> 
> 
> What if Apple were to open source Foundation, Core Data, etc., most every 
> thing but the UI so that developers could more easily generate cross platform 
> apps.
> 
> Recently visited this Microsoft web site where the tag line is 
> "cross-platform". It would be interesting to know if this stuff really works.
> 
> https://dotnet.microsoft.com/learn/dotnet/what-is-dotnet
> 
> --Richard Charles
> 

If you're so absolutely set on cross-platform, leave the cross-platform work to 
those who do that — and write your code to those libraries.

Here's some options: wxWidgets, Qt, Cocotron, Xojo. Each has strengths and 
weaknesses, but you're never going to get an entirely "platform native" 
experience on all platforms because each platform is *different*. The 
advantages to libraries like wxWidgets, Qt, and Xojo is that *they* do the work 
to support new technologies, the downside is that the support may take some 
time and not work exactly the same on all platforms.

MVVM might help save you, but that's basically what cross-platform libraries 
provide. You're stuck developing your own or using one of the pre-existing ones 
(and I'd suggest one of the pre-existing ones). The advantage is that the 
libraries open up options beyond "macOS" and "Windows" - the disadvantage is 
that they eliminate much of the platform-specific behaviors.

Apple has absolutely zero need to deliver a cross-OS-platform GUI toolset 
beyond macOS/iOS/tvOS/watchOS - and even then, it's likely to be based on 
SwiftUI, and not C++. It's their competitive advantage, and the reason why 
you're looking to *them* to do the work is so that you don't need to. The 
problem is that you've waited until the train has pulled into the station two 
stops after yours before deciding to jump on.

-- 
Glenn L. Austin, Computer Wizard and Race Car Driver <><


___

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

Please do not post admin requests or moderator comments to the list.
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: Cocoa-dev Digest, Vol 16, Issue 144

2019-11-14 Thread Glenn L. Austin via Cocoa-dev 
> On Nov 14, 2019, at 6:11 AM, Turtle Creek Software via Cocoa-dev 
>  wrote:
> 
> Convert resources from ResEdit
>>> DUDE.  This is what, 20 years overdue?
> 
> Dude.  Why would we change them before it was necessary?  Don't fix it if
> it ain't broke.  There were better things to work on in the past 20 years.
> 
> We wrote code to go through each type of resource and convert them to XML.
> Then that turned out to be a huge PITA to maintain, so we revised it to tab
> text.  Easy to revise in Excel and 10x faster to load.
> 
> My question is, why on earth didn't Apple provide a conversion tool like
> that?  It would have saved thousands of developers from having to write
> their own resource translators or do it by hand.
> 
> Casey McDermott
> TurtleSoft.com

They did. It's called derez. It's still available on Catalina.

-- 
Glenn L. Austin, Computer Wizard and Race Car Driver <><



___

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

Please do not post admin requests or moderator comments to the list.
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 Objective-C++

2019-11-13 Thread Glenn L. Austin via Cocoa-dev 
> On Nov 12, 2019, at 11:56 PM, Chris Ridd via Cocoa-dev 
>  wrote:
> 
>> 
>> On 12 Nov 2019, at 21:14, Jean-Daniel via Cocoa-dev 
>>  wrote:
>> 
>> 
>> 
>>> Le 12 nov. 2019 à 21:30, Richard Charles via Cocoa-dev 
>>>  a écrit :
>>> 
>>> 
 On Nov 12, 2019, at 1:16 PM, GNDGN  wrote:
 
 ‘It’s like giving a glass of ice water to somebody in hell’ - Jobs
 
>>> 
>>> Apple released iTunes for Windows in October 2003. Apparently Cocoa and any 
>>> supporting frameworks were ported to Windows 16 years ago. So what is the 
>>> problem providing this to outside developers?
>>> 
>>> --Richard Charles
>> 
>> Supporting a public API is far more complex and costlier than supporting 
>> some private frameworks.
>> What would be the benefit for Apple to support public API for Windows ?
> 
> Apple did have the Red Box environment, back in the Rhapsody days. I guess 
> they agreed with you, because it never got released AFAIK. I think it was 
> mostly inherited from Next.
> 
> https://lowendmac.com/1997/red-box-blue-box-yellow-box/ 
> 
> 
> Chris

Having worked on an Apple cross-platform application that used the same APIs 
that iTunes use...
...was a nightmare.

You'd think that it would be easy, but there are so many assumptions about 
*how* the APIs work and work together to get your code running - and many of 
those assumptions simply weren't true when running in a Windows environment. We 
spent a significant amount of time re-writing various APIs used by the 
application because the RedBox ones we had access to simply didn't work.

We won't go into the facts that every Windows font size is *exactly* 33% bigger 
than they are on the Mac (Windows is 96 dpi, Mac is based on 72 dpi: 96/72 = 
4/3). Or that a mouse on Windows was less precise but targets were smaller. Or 
the myriad of other "issues" that make a Windows app just "feel different."

I've written apps in Qt, and it does make the cross-platform app development 
process "easier" - but that's much more from a Windows-centric (or 
Linux-centric) viewpoint. The same is true for WxWidgets. Qt also has a pretty 
significant up-front cost in time and money (WxWidgets is open-source, but 
still has the time investment).

-- 
Glenn L. Austin, Computer Wizard and Race Car Driver <><



___

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

Please do not post admin requests or moderator comments to the list.
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 Cocoa

2019-10-12 Thread Glenn L. Austin via Cocoa-dev 
> On Oct 11, 2019, at 11:17 PM, Charles Srstka via Cocoa-dev 
>  wrote:
> 
>> On Oct 11, 2019, at 5:29 PM, tblenko--- via Cocoa-dev 
>>  wrote:
>> and the maturity of the compilers available, there is any need for Swift. 
>> But there it is. Or, there they are. Perhaps this is the way the younger 
>> generation overtthrows the older? Or not, but I’m pretty sure there is no 
>> compelling business argument for it.
> 
> 
> Holy hell, Swift isn’t perfect, but I’d rather use it over C++ a thousand 
> times over.


It feels to me that Swift is to LLVM as C++ was to gcc.

-- 
Glenn L. Austin, Computer Wizard and Race Car Driver <><


___

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

Please do not post admin requests or moderator comments to the list.
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: Questions regarding release

2019-09-26 Thread Glenn L. Austin via Cocoa-dev 
> On Sep 26, 2019, at 9:47 AM, Gabriel Zachmann  wrote:
> 
>> 
>> I don’t believe that’s entirely true. “make” methods return a +0 value.
>> 
>> The issue in the below code to my eye is that you allocate a path with 
>> CGPathCreateWithRect (+1) but then don't release it.
>> 
> 
> In that case, I am wondering:
> doesn't ownership pass to the textlayer ?
> If yes, shouldn't textlayer release the path when it gets destroyed by the 
> ARC?
> 
> Best regards, Gabriel
> 

Setting the value will retain it for itself.

--
Glenn L. Austin, Computer Wizard and Race Car Driver     <><
<http://www.austinsoft.com>

> 
>> Mike.
>> 
>>> On 26 Sep 2019, at 17:16, Glenn L. Austin via Cocoa-dev 
>>>  wrote:
>>> 
>>> The analyzer is great at what it does but it can't be omniscient about your 
>>> code.
>>> 
>>> When you start a method name with "make" or "new" or "create" it assumes 
>>> that you're returning a +1 value.
>>> 
>>> --
>>> Glenn L. Austin, Computer Wizard and Race Car Driver <><
>>> <http://www.austinsoft.com>
>>> 
>>>> On Sep 26, 2019, at 6:05 AM, Gabriel Zachmann via Cocoa-dev 
>>>>  wrote:
>>>> 
>>>> 
>>>>> 
>>>>> The Xcode "analyze" step should check for errors of this kind. I have 
>>>>> xcode set to analyze on every build, since it's usually not too slow.
>>>> 
>>>> Thanks a lot for the hint!
>>>> 
>>>> I tried it and it works pretty well.
>>>> I actually found 2 (small) leaks.
>>>> 
>>>> There is one place in my code (different from my OP),
>>>> where I get a "leaked" warning from the Analyzer, but I am not sure why 
>>>> that is.
>>>> 
>>>> Here is what the function basically does:
>>>> 
>>>> - (void) makeTextLayerRectangle: (CATextLayer*) textlayer fontsize: 
>>>> (float) fontsize text: (NSString*) text
>>>> {
>>>> ...
>>>>  textlayer.bounds = CGRectMake( 0.0, 0.0, string_rect.width, 
>>>> string_rect.height );
>>>>  textlayer.shadowPath = CGPathCreateWithRect( textlayer.bounds, NULL );
>>>> }
>>>> 
>>>> 
>>>> But I get the warning
>>>> "Object leaked: allocated object of type 'CGPathRef _Nonnull' is not 
>>>> referenced later in this execution path and has a retain count of +1"
>>>> 
>>>> Note that text layer is a call-by-reference var.
>>>> 
>>>> Is that just a bug in the Analyzer? Am I missing something?
>>>> 
>>>> 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/glenn%40austinsoft.com
>>>> 
>>>> This email sent to gl...@austinsoft.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/mabdullah%40karelia.com
>>> 
>>> This email sent to mabdul...@karelia.com
>> 
> 



signature.asc
Description: Message signed with OpenPGP
___

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

Please do not post admin requests or moderator comments to the list.
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: Questions regarding release

2019-09-26 Thread Glenn L. Austin via Cocoa-dev 
The analyzer is great at what it does but it can't be omniscient about your 
code.

When you start a method name with "make" or "new" or "create" it assumes that 
you're returning a +1 value.

--
Glenn L. Austin, Computer Wizard and Race Car Driver <><


> On Sep 26, 2019, at 6:05 AM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> 
>> 
>> The Xcode "analyze" step should check for errors of this kind. I have xcode 
>> set to analyze on every build, since it's usually not too slow.
> 
> Thanks a lot for the hint!
> 
> I tried it and it works pretty well.
> I actually found 2 (small) leaks.
> 
> There is one place in my code (different from my OP),
> where I get a "leaked" warning from the Analyzer, but I am not sure why that 
> is.
> 
> Here is what the function basically does:
> 
> - (void) makeTextLayerRectangle: (CATextLayer*) textlayer fontsize: (float) 
> fontsize text: (NSString*) text
> {
>   ...
>textlayer.bounds = CGRectMake( 0.0, 0.0, string_rect.width, 
> string_rect.height );
>textlayer.shadowPath = CGPathCreateWithRect( textlayer.bounds, NULL );
> }
> 
> 
> But I get the warning
> "Object leaked: allocated object of type 'CGPathRef _Nonnull' is not 
> referenced later in this execution path and has a retain count of +1"
> 
> Note that text layer is a call-by-reference var.
> 
> Is that just a bug in the Analyzer? Am I missing something?
> 
> 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/glenn%40austinsoft.com
> 
> This email sent to gl...@austinsoft.com



signature.asc
Description: Message signed with OpenPGP
___

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

Please do not post admin requests or moderator comments to the list.
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: Cocoa window messages in app being ported from Carbon

2019-08-10 Thread Glenn L. Austin via Cocoa-dev 
> On Aug 10, 2019, at 10:20 PM, Kurt Bigler via Cocoa-dev 
>  wrote:
> 
> On 8/10/19 3:04:13 PM, Rob Petrovec wrote:
>>> On Aug 10, 2019, at 3:38 PM, Uli Kusterer  
>>> wrote:
>>> 
 On 10. Aug 2019, at 19:03, Rob Petrovec via Cocoa-dev 
 mailto:cocoa-dev@lists.apple.com>> wrote:
 
> On Aug 10, 2019, at 12:24 AM, Kurt Bigler via Cocoa-dev 
> mailto:cocoa-dev@lists.apple.com>> wrote:
> 
> The NSView subclasses involved are receiving drawRect: messages but are 
> not receiving mouseDown:.
You need to implement NSView -hitTest: to get mouseDown events.
>>> 
>>> 
>>> No, the default implementation does all you need and is perfectly fine.
>>  I’ll repeat myself, the OP is not getting mouseDown on his NSView 
>> subclass.  So it isn’t perfectly fine in this case.  If he wants mouseDown 
>> events in his NSView subclass he needs to override hitTest to return self, 
>> or whatever subview he wants to get mouseDown.  There is no avoiding it.
>>  The default implementation of NSView hitTest just loops through it’s 
>> visible subviews and calls hitTest on each one that the passed in point is 
>> inside.  It is obviously recursive.  If any of the subviews return a valid 
>> view from their implementations of -hitTest: then that valid view is 
>> returned up the call stack. Whatever view is returned from -hitTest: at the 
>> top of the call stack will get first crack at the mouseDown event.  Since 
>> NSViews don’t have subviews by default, let alone one that returns a valid 
>> view from hitTest, then the default implementation of an NSView -hitTest 
>> will return nil.  Semantics, I know...
>>  Either way, instead of going back & forth on this, why don’t you try 
>> implementing an NSView subclass without hitTest returning self and see if 
>> that view gets -mouseDown:.  Then override -hitTest in the view to return 
>> self and see that the view does get -mouseDown.  Then you will see that I am 
>> correct.  Thanks.
> 
> It is always worth trying something trivial regardless of arguments.
> 
> I implemented hitTest to return self in my NSView subclass.  It made no 
> difference.
> 
> After that, I tried having hitTest call the super method to see what it 
> returned.  For the simpler version of my window nib with only one view the 
> super method was returning self.  For the more complex version of the window 
> nib with 3 views (of the same class), my NSView subclass's hitTest got called 
> 4 times. In 2 cases the super method returned self; in 2 other cases the 
> super method returned 0.  I did not look at further details but it seems 
> likely that the default implementation actually checks whether the location 
> is in the view and returns 0 otherwise.
> 
> -Kurt

Personally, I'd check to make sure that the coordinate system for that view (or 
the underlying layer) isn't resetting it's internal origin to something other 
than {0,0}. While that shouldn't necessarily affect hit testing, there's 
something unusual about that view -- origin is offset, view is disabled, view 
doesn't accept user interaction...?

-- 
Glenn L. Austin, Computer Wizard and Race Car Driver <><


___

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

Please do not post admin requests or moderator comments to the list.
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: Cocoa window messages in app being ported from Carbon

2019-08-10 Thread Glenn L. Austin via Cocoa-dev 
> On Aug 10, 2019, at 2:02 PM, Kurt Bigler via Cocoa-dev 
>  wrote:
> 
> On 8/10/19 2:16:41 AM, Uli Kusterer wrote:
>> The Cocoa event handling code uses CarbonEvents under the hood. AFAIR, you 
>> can switch to the Cocoa event loop right away, and Carbon windows will just 
>> keep working.
> 
> You're saying some interesting things.  Given the demise of 32-bit, if this 
> is still true, maybe the rumored internal 64-bit Carbon implementation might 
> be deployed behind the scenes to support any portions of Cocoa that still 
> depend on Carbon.  None of that matters for now since obviously I'm doing the 
> port on an older macOS.

"Carbon" seems to have split pretty early-on in the transition to Cocoa-only 
into what I personally called "Core" and "HIToolbox." Most of the 
underpinnings, such as CF, events, and menus, were brought up to 64-bit as a 
part of "Core," it was the main parts of HIToolbox around windows, controls, 
and views that directly "competed" with AppKit and never made the full 
transition to 64-bit. I *suspect* that underlying the Cocoa window system sat 
on top of the Carbon window system until the Metal version was available.

If you send a CarbonEvent that corresponds to a Cocoa event, the Cocoa event 
"engine" will accept and handle it - vice versa with Cocoa events and 
CarbonEvents.  NSRunLoop is sitting on top of CFRunLoop - so if your Carbon 
event code ever calls CFRunLoopStop, your entire event engine will just stop. 
Never call CFRunLoopStop unless you want to quit - or you've nested the runloop 
inside of another - like for modal dialogs.

I did much of the porting of a major application to a mixed Carbon and Cocoa 
application and spent a lot of time working on getting events, menus, views, 
and windows to "just work." They did, but there was a *lot* of code to 
implement work-arounds for the most egregious of Carbon/Cocoa interaction 
issues.


-- 
Glenn L. Austin, Computer Wizard and Race Car Driver <><



___

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

Please do not post admin requests or moderator comments to the list.
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