I would not recommend using those deprecated API. They are not long for this
world. With that said, I don’t have a better solution.
—Rob
> On Jul 25, 2019, at 7:03 PM, Dragan Milić via Cocoa-dev
> wrote:
>
>> On pet 26.10.2019,. at 02.37, Steve Mills via Cocoa-dev wrote:
>>
>> Use the sin
> On Aug 10, 2019, at 12:24 AM, Kurt Bigler via Cocoa-dev
> wrote:
>
> The NSView subclasses involved are receiving drawRect: messages but are not
> receiving mouseDown:.
You need to implement NSView -hitTest: to get mouseDown events.
—Rob
__
> On Aug 10, 2019, at 3:12 PM, Kurt Bigler wrote:
>
> On 8/10/19 10:03:00 AM, Rob Petrovec wrote:
>>> On Aug 10, 2019, at 12:24 AM, Kurt Bigler via Cocoa-dev
>>> wrote:
>>>
>>> The NSView subclasses involved are receiving drawRect: messages but are not
>>> receiving mouseDown:.
>
>> Y
> 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:coc
> Is it safe to do it after assigning the nsimage to the layer, but before
> deleting the layer?
I would think so, but it is hard to say without knowing what
convertToNSImage:withOrientation actually does under the hood. It likely
either retains or copies it. In either case, your relea
> On Sep 25, 2019, at 2:52 PM, Rob Petrovec via Cocoa-dev
> wrote:
>
>> Is it safe to do it after assigning the nsimage to the layer, but before
>> deleting the layer?
> I would think so, but it is hard to say without knowing what
> convertToNSImage:withOrie
> On Sep 26, 2019, at 5:20 PM, Gabriel Zachmann via Cocoa-dev
> wrote:
>
>> 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 ye
> On Sep 26, 2019, at 5:43 PM, James Walker via Cocoa-dev
> wrote:
>
> On 9/26/19 4:20 PM, Gabriel Zachmann via Cocoa-dev wrote:
>>> 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 wond
> On Oct 24, 2019, at 4:01 PM, Gabriel Zachmann via Cocoa-dev
> wrote:
>
>>>
>>>
>>>
>>> https://developer.apple.com/account/#/feedback-assistant
>>>
>>> https://developer.apple.com/account/#/forums
>>
>>
>> Good luck with that. I've been using OSX/macOS since the Panther days and
>> qui
> On Oct 24, 2019, at 4:50 PM, Stephane Sudre wrote:
>
> On Fri, Oct 25, 2019 at 12:38 AM Rob Petrovec via Cocoa-dev
> wrote:
>> If its a ranty bug report, which apparently happens a lot, it goes into a
>> black-hole never to see the light of day if it doesn’t just
> On Oct 24, 2019, at 5:16 PM, James Walker via Cocoa-dev
> wrote:
>
> On 10/24/19 3:57 PM, Rob Petrovec via Cocoa-dev wrote:
>>> On Oct 24, 2019, at 4:50 PM, Stephane Sudre wrote:
>>>
>>> On Fri, Oct 25, 2019 at 12:38 AM Rob Petrovec via Cocoa-dev
>
I wouldn’t be so pessimistic about macOS or even iOS update rates. Its
considerably quicker than you think. IMS, they announce upgrade rates during
public earnings report conference calls typically to brag about how well a new
OS is being received by the public over previous releases or compet
> On Nov 14, 2019, at 1:13 PM, Pier Bover wrote:
>
> > I wouldn’t be so pessimistic about macOS or even iOS update rates.
>
> According to StatCounter Mojave never went above 52% or market share, which
> means at its peak 48% of users were still on previous versions.
>
> https://gs.statcount
+1
Also, the reference docs can be toggled between Obj-C & Swift via the
“Language” popup at the top of the page.
—Rob
> On Nov 19, 2019, at 9:48 AM, Steve Mills via Cocoa-dev
> wrote:
>
> You should use an external poll site for this rather than filling the list
> with yet another thread
The sky is not falling. When/if Apple decides to deprecate Cocoa they will
announce it many years ahead of time, like they did for Carbon back in 2012
(which was only officially killed in 2019). They typically make announcements
like that at a WWDC. They aren’t going to stop supporting it and
> On Nov 19, 2019, at 6:24 PM, Pier Bover wrote:
>
> > When/if Apple decides to deprecate Cocoa they will announce it many years
> > ahead of time
>
> Like they did with 32 bits and OpenGL deprecation?
Yes, exactly. 32Bit was deprecated in 2012 and officially killed in
2019. OpenG
> On Nov 20, 2019, at 9:28 AM, Pier Bover wrote:
>
> > Its not Apples fault if you were not aware. They were both highly talked
> > about during their respective WWDC events.
>
> The vast majority of developers do not go to the WWDC and do not have time to
> watch the dozens (hundreds?) of
From
https://developer.apple.com/documentation/appkit/nsclipview/1532142-copiesonscroll?language=objc
copiesOnScroll
A Boolean value that indicates if the clip view copies rendered images while
scrolling.
Discussion
When the value of this property is YES, the clip view copies its existing
render
I honestly think this is fall out from copiesOnScroll being deprecated and the
clip view always behaving as if it was set to true. My guess is you will see
the same problems in your apps if you ran them on Mojave with copiesOnScroll
set to true. In which case you need to update your app to wor
t
curious.
—Rob
> On Dec 31, 2019, at 1:34 AM, Eyal Redler wrote:
>
>>
>> On 30 Dec 2019, at 2:09, Rob Petrovec via Cocoa-dev
>> mailto:cocoa-dev@lists.apple.com>> wrote:
>>
>> I honestly think this is fall out from copiesOnScroll being deprecat
> On Jan 10, 2020, at 6:36 AM, Gabriel Zachmann via Cocoa-dev
> wrote:
>
> Steve, thanks a lot for your response!
>
>>>
>>> In my screensaver, I try to search the Pictures directory in the user's
>>> home.
>>> It is OK - for now - if my app cannot access any .photoslibrary, but I'd
>>> lik
No you can’t one an NSOpenPanel on a secondary thread. UI elements must be on
the main thread.
—Rob
> On Mar 21, 2020, at 1:05 PM, Gabriel Zachmann via Cocoa-dev
> wrote:
>
> Is it possible to open an NSOpenPanel in a secondary thread?
>
> I create the thread like this:
>
>directo
I would not do this. It is widely documented that AppKit API that produce UI
elements, like NSOpenPanel, are _not_ thread safe. 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, bu
> On Mar 23, 2020, at 8:01 AM, Gabriel Zachmann via Cocoa-dev
> wrote:
>
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 threa
I assume you have iCloud enabled. If so, these three folders are ’special’.
Try logging out of iCloud & rebooting and see if the problem persists.
I would also recommend filing a bug with Apple and include a sysdiagnose taken
while the problem was reproducing (sudo sysdiagnose). Or at least a
>> I think you are right about this being a permission / “sandbox” issue,
>> because the 3 folders in question are all folders that macOS 10.15 now
>> require special permission to read (even though in my case, I just request
>> their display name).
Yes, this is because of iCloud. Log o
If what you say is correct then everyone would be seeing a delay since most
people don’t have blazing fast internet connections. I do not think this is
the normal behavior. I think it is specific to your system, otherwise there
would be TONS of people complaining about slowness. A couple seco
> On Apr 23, 2020, at 9:10 AM, Allan Odgaard via Cocoa-dev
> wrote:
>
> On 23 Apr 2020, at 21:15, Rob Petrovec wrote:
>
>> If what you say is correct then everyone would be seeing a delay since most
>> people don’t have blazing fast internet connections. I do not think this is
>> the norma
> On Apr 23, 2020, at 7:30 PM, Allan Odgaard via Cocoa-dev
> wrote:
>
> On 24 Apr 2020, at 2:18, Rob Petrovec wrote:
>
>> I get a 1 second time for the first run and then a much quicker time for the
>> second. I did some sampling and the longer time due to is Apple’s check for
>> malware o
> On Apr 23, 2020, at 8:35 PM, Allan Odgaard via Cocoa-dev
> wrote:
>
> On 24 Apr 2020, at 2:28, Gabriel Zachmann via Cocoa-dev wrote:
>
>>> I believe that is why you are supposed to staple notarization tickets to
>>> your apps.
>> Then, why would it "phone home" in case there is an internet
I thought when everything goes wonky you zap the PRAM and rebuild the Desktop?
—Rob
> On Apr 29, 2020, at 3:45 PM, Carl Hoefs via Cocoa-dev
> wrote:
>
> When everything goes wonky... it's time to reinstall all of Xcode...!
>
> *sigh*
> -Carl
>
>
> __
Have you considered using a workspace to handle building all of your individual
projects? That should solve your file path & linking problem.
btw, the 28 character string is a UUID. I’m not sure about its lifetime.
—Rob
> On May 7, 2020, at 9:57 PM, Richard Charles via Cocoa-dev
> wrote:
>
> On May 8, 2020, at 12:19 PM, Jens Alfke via Cocoa-dev
> wrote:
>
>
>
>> On May 8, 2020, at 9:53 AM, Gabriel Zachmann via Cocoa-dev
>> wrote:
>>
>> So, I was thinking, maybe it helps to load the next image concurrently,
>> while the current one is still being displayed.
>
> Sure. Just
I’ve had a lot of success with Instruments leaks traces. In the retain/release
world we live in, knowing the backtrace to where the object was created isn’t
enough. Instruments gives a nice UI to walk the retain/release history of an
object, and the backtrace of each retain/autorelease/release
Yes, there is more than one way to skin a cat. Use whatever methods work for
you. But keep in mind that your experiences may not be the same as others
because your code base is obviously going to be different. So I would not
recommend avoiding one tool over another just because it didn’t work
> On May 22, 2020, at 8:42 AM, Allan Odgaard via Cocoa-dev
> wrote:
>
> On 23 Apr 2020, at 21:15, Rob Petrovec wrote:
>
>> If what you say is correct then everyone would be seeing a delay since most
>> people don’t have blazing fast internet connections. I do not think this is
>> the norma
I have never used AppleGlot. However, I’m curious why you don’t set up a
.lproj for each localization you support containing .strings files with your
translated strings inside?
—Rob
> On May 27, 2020, at 10:04 AM, Eyal Redler via Cocoa-dev
> wrote:
>
> Hi,
>
> It looks like Apple has drop
> On May 27, 2020, at 1:08 PM, Gabriel Zachmann via Cocoa-dev
> wrote:
>
>>>
>>> I've just had a crash in
>>> CGImageSourceCreateThumbnailAtIndex( new_image, 0, imageOpts );
>>
>> We went through this quite a while ago in private emails.
>> CGImageSourceCreateThumbnailAtIndex is fine to use
Auto layout (not auto-resizing) is independent of localization. You don’t need
to switch to auto layout to support Base localization. So you can convert your
nibs over to Base Localization with a couple clicks in Xcode, and then you just
need .strings and .stringdict files in your .lprojs inst
> On May 27, 2020, at 2:37 PM, Martin Wierschin wrote:
>
>> Auto layout (not auto-resizing) is independent of localization. You don’t
>> need to switch to auto layout to support Base localization
>
> It's true that autolayout has many benefits aside from localization. But I'd
> say it's onl
I don’t have an answer to your question, but to add some clarity Points are
scale factor independent unit of measurement. On a retina display there are 2
pixels per point. On a non-retina display there is 1 pixel per point. Say
Apple comes out with a display with a scale factor of 17. That w
You want LSCopyApplicationURLsForBundleIdentifier
—Rob
> On Jul 16, 2020, at 6:24 AM, Gabriel Zachmann via Cocoa-dev
> wrote:
>
> Is there a way to find the paths/URLs to all app bundles that have the same
> bundle ID?
>
> I have a user who likes to make duplicates of my app (it does make s
I don’t know the answer to your question. However,I would move your time table
up significantly on testing your app with Big Sur if I were you. There are a
lot of changes in Big Sur that will definitely effect your app. Most notably
drastic UI changes, not to mention the API & behavior change
As was pointed out by an earlier reply, even if you use -layout or
setAutoresizingMask you are still using auto layout. The frame changes get
converted to auto layout constraints under the hood. If you said “without
using Autolayout API” that would be more correct.
—Rob
> On Oct 17, 2020, at
> On Oct 26, 2020, at 10:00 PM, Steven Mills via Cocoa-dev
> wrote:
>
>
>> On Oct 26, 2020, at 17:49:59, James Walker via Cocoa-dev
>> wrote:
>>
>> I don't see any "Download Debug Symbols" in the Organizer. I don't think it
>> exists for macOS apps.
>>
>> However, one can right-click on
PLEASE PLEASE PLEASE don’t put up a modal dialog in the middle of a drag. All
drags are done on the main thread. This includes calls to NSDraggingSource,
NSDraggingDestination, NSFilePromiseProvider, NSFilePromiseReceiver methods and
drag methods from NSTableView/NSOutlineVIew & NSCollectionVie
Check out NSTableViewStylePlain
—Rob
> On Nov 5, 2020, at 12:28 PM, Dragan Milić via Cocoa-dev
> wrote:
>
> Hi all,
>
> What would be the best approach to set custom insets of the contentView
> (NSClipView) of a NSScrollView? I’ll try to describe the problem in more
> details…
>
> I’m tr
No problem. Looks like a bug about to clarify the documentation is in order.
—Rob
> On Nov 5, 2020, at 2:35 PM, Dragan Milić via Cocoa-dev
> wrote:
>
>> čet 05.11.2020., at 20:57, Rob Petrovec wrote:
>>
>> Check out NSTableViewStylePlain
>
> Yes Rob, that was it, thanks a lot!! And now I
Yes, Ben is correct. One thing to note, when you report the bug if you can
supply a test project showing the behavior in Obj-C and another project showing
the behavior in Swift that would likely give this bug a lot more traction.
Good luck.
—Rob
> On Nov 22, 2020, at 2:08 PM, Ben Kennedy vi
That error message is less than helpful. Does the current user have
permissions to write to that directory, let alone to the file being replaced?
if not, no amount of entitlements will let you do what you want.
—Rob
> On Mar 14, 2021, at 3:43 AM, Allan Odgaard via Cocoa-dev
> wrote:
>
>
Don’t forget to include a sample app that demonstrates the problem.
—Rob
> On Mar 26, 2021, at 12:02 PM, Gary L. Wade via Cocoa-dev
> wrote:
>
> Try surrounding the call with beginEditing and endEditing on the text
> storage. If it still happens, submit a feedback to Apple with the full cra
AppKit is pretty good at logging failures like this. I would look for messages
in the system.logs (or better yet from a sysdiagnose archive) from your process
as well as com.apple.appkit.xpc.openAndSavePanelService (the process that
actually shows the open/save panel). See if there are any log
To trigger a sysdiagnose:
- reproduce the problem
- Hold down Shift-Control-Option-Command-‘.’ (period) for a few seconds
- After a couple minutes a Finder window will appear with a
“sysdiagnose….tar.gz" archive pre-selected. You want that archive.
- Once you have the archive, uncompress it and
> (It goes without saying that on my system everything runs fine, both on macOS
> 10.15.4 and macOS 11.3.1.)
Since the problem appears to happen on 10.15.0, but not 10.15.4 and
newer, I would just chalk it up to a bug in the OS and ask your customer to
update to at least 10.15.4. I’m no
You are using deprecated cell based table views/API. I would advise switching
to view based API (available in macOS 10.7 and newer). Cell based was
deprecated in 10.10 back in 2014.
With that said, I would create an NSTextFieldCell subclass (if you haven’t
already) and stuff it into the text f
> On Jun 25, 2021, at 2:40 PM, Andreas Falkenhahn via Cocoa-dev
> wrote:
>
> On 25.06.2021 at 18:54 Carl Hoefs wrote:
>
>> So I think it's safe to say that something has changed, and you're not
>> fighting fantoms...
>
> Do you think this should be reported to Apple or will nobody care beca
The text in an error dialog is typically a washed down version of the actual
error. See if you can get the user to give you a sysdiagnose log, taken just
after reproducing the problem, so you can check out the .logarchive to see what
the actual error was from the system. It should provide more
Quit Xcode, delete the DerivedData directory for your project and re-open your
project. That should trigger a re-index and a full rebuild of your product.
The default location for the DerivedData directory is in
~/Library/Developer/Xcode/DerivedData/-. You can also configure it to be in your s
Accessibility for NSControls is handled by the NSCell inside it, not the
NSControl. Good luck.
—Rob
> On Mar 13, 2022, at 7:55 AM, Eyal Redler via Cocoa-dev
> wrote:
>
> Hi,
>
> I'm having trouble getting a custom NSControl subclass properly visible with
> regards to accessibility.
>
> I
> On Mar 18, 2022, at 8:47 AM, Gabriel Zachmann via Cocoa-dev
> wrote:
>
> I am trying to build my app for macOS 10.12 (Sierra).
>
> First of all, is it correct that I need to build it for "My Mac" , not do a
> niversal build (Any Mac)?
If you are only building to debug it then My Ma
> On Mar 18, 2022, at 1:11 PM, Gabriel Zachmann wrote:
>
>>> I am trying to build my app for macOS 10.12 (Sierra).
>>>
>>> First of all, is it correct that I need to build it for "My Mac" , not do a
>>> niversal build (Any Mac)?
>> If you are only building to debug it then My Mac is fine
> On Mar 20, 2022, at 9:09 AM, Gabriel Zachmann wrote:
>
> I have now the crash report.
>
> Apparently, this caused it:
>
> Symbol not found: _AVAudioSessionInterruptionNotification
>
> Yes, I am using that function, and yes, it seems to be available only on
> macOS 11 and higher.
>
> My
> On Mar 20, 2022, at 11:41 AM, Quincey Morris
> wrote:
>
> (Resending because I forgot to cc the list)
>
> On Mar 20, 2022, at 08:09, Gabriel Zachmann via Cocoa-dev
> wrote:
>>
>> Apparently, this caused it:
>>
>> Symbol not found: _AVAudioSessionInterruptionNotification
>>
>> Yes, I am
> On Apr 19, 2022, at 5:26 PM, Sean McBride via Cocoa-dev
> wrote:
>
> On 19 Apr 2022, at 18:47, Saagar Jha wrote:
>
>> If Thread Sanitizer says your code has a race, it almost certainly has a
>> race.
>
> Yeah, that's been my general experience until now.
>
>> Your simple code seems OK su
Is it always going to be the same search? If so, you could create a Saved
Search in the Finder and include it with your app. Then when you want to bring
up the search you can open the Saved Search bundle and it will open in the
Finder. Hope that helps.
—Rob
> On Dec 13, 2022, at 1:10 PM, T
Yes, this is a bug that started in 11.7 that doesn’t appear to have been fixed
yet in 11.7.2.
Have you tried the arguably more robust and less error prone runtime checks of:
Swift
if #available(macOS 10.16, *) {
// macOS 10.16 or later code path
} else {
// code for earlier than 10.1
NSCollectionView, like NSTableView/NSOutlineView, will reuse existing views
instead of recreating them when it can to speed up the UI. This is most
commonly used during scrolling where views that scroll out of view will be
reused with new data and scrolled into view. It will call -prepareForReus
This sounds like Abandoned Memory, not a leak. Abandoned memory is a retain
cycle somewhere. Best/easiest way to find those is with a memgraph. Click the
little sideways V icon in Xcode’s debugger when the problem is reproducing.
Or run ‘leaks MyApp --outputGraph ~’ in Terminal when the prob
Hey,
Since you have unbounded memory growth, you will likely have one or
more object types with a TON of instances in the list on the left. They are
likely the source, or part of a chain of objects eating your memory.
MallocStackLogging doesn’t show more info about a possible cause. On
ory
>> with no pointer to it.
>>
>> If you want, we could do a video meeting and I could guide you through it.
>>
>> Will reply with the memory querying function.
>>
>> Cheers,
>> Alex Zavatone
>>
>> Sent from my iPhone
>>
>
number of objects. That
might narrow down what object(s) are eating your memory. Good luck.
—Rob
> On Apr 30, 2023, at 12:31 PM, Rob Petrovec via Cocoa-dev
> wrote:
>
> Hey,
> Since you have unbounded memory growth, you will likely have one or
> more object types with
> On May 1, 2023, at 5:04 AM, Gabriel Zachmann wrote:
>
> Thanks so much again!
>
> I tried, and it didn't give me a good clue, though.
> What I got as output is:
> All zones: 1466 nodes malloced - Sizes: 117040KB[25] 96KB[25] 8KB[2] 5.5KB[1]
> 5KB[1] 4KB[2] 3KB[3] 2.5KB[2] 2KB[4] 1.5KB[4] 65
The order of the screens can change under various user scenarios. One easy one
is simply re-arranging the displays, or even moving the menu bar thing from one
display to another in the Arrange UI Displays prefs pane. Obviously plugging &
unplugging displays or closing a laptop with an external
Yeah, you might be able to send out a distributed notification and have the
menuling listen for it. When it receives it it can kill itself or go through
the normal teardown/quit procedure.
—Rob
> On Jul 25, 2023, at 6:15 AM, Alex Zavatone via Cocoa-dev
> wrote:
>
> What if you called a meth
NSDistributedNotificationCenter is a way to send a notification out across the
system. Only processes that are listening for the notification will receive it
and have a chance to do something with it. It’s like yelling out in a crowded
room to tell a single person something. Everyone will hear y
CGImageForProposedRect returns an autoreleased CGImageRef, so your
CFRelease(imageRef) is an overrelease and likely the cause of your problem.
The rest of the code looks fine, including the release of subImageRef (if it
was uncommented).
—Rob
> On Aug 23, 2023, at 4:47 PM, JPH via Cocoa-dev
ARC only affects Objective-C objects. It has no effect on CF objects like
CGImageRefs, CFArrayRefs, CFDictionaryRefs etc. If you play with CF objects in
an ARC app you still need to release them. You don’t need to release Obj-C
objects and the compiler will warn you if you try to.
—Rob
> On
To be clear, CGImageForProposedRect doesn’t have ‘Create’ in the name. So the
'Create Rule' doesn’t apply. But it is an easy thing to overlook.
—Rob
> On Aug 24, 2023, at 2:35 AM, JPH wrote:
>
> Thanks to all of you
> The CFRelease(imageRef); was the problem and the CFRelease(subImageRef);
Are you overriding NSOpenSavePanelDelegate -panel:shouldEnableURL:? If so,
make sure your code isn’t inadvertently disabling the folder for some reason.
Doing those steps in TextEdit works fine for me. Maybe ask the user to try the
same steps with TextEdit Open dialog and see if the behavior i
79 matches
Mail list logo
