On looking at the particulars of the icons that are working and those
that are not, it looks like anything that has a high resolution (128 x
128) is displaying wrong, while the ones that I never updated from
48 x 48 work correctly.
> I had a similar problem with .icns files showing weird
I had a similar problem with .icns files showing weird graphics but on Mojave
and earlier they were fine. I resolved the issue by using Icon Composer (on
macOS 10.10) to extract the '.icns' file(s) to iconsets and then importing them
into an Asset Library.
The NSImage creation changed to use
To provide a bit of additional information, the toolbar icons are
fetched with
image = [[NSImage alloc]
initByReferencingFile:[mainBundle
pathForResource:identifier ofType:@"icns"]];
> I'm having a very odd problem. I use NSToolbar/NSToolbarItem to
> manage toolbars in my
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.
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
>
> Yes, understood. Does the user have to ask for this process to begin, or
> does it start automatically?
The user starts the process by opening a directory.
Then, when the process hits an alias pointing to some other directory, the
process will ask the user again to open that directory.
> On Mar 23, 2020, at 10:01 AM, Gabriel Zachmann 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 thread,
>>> or so
> 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
I'm having a very odd problem. I use NSToolbar/NSToolbarItem to
manage toolbars in my application. Under Catalina (and apparently
only under Catalina), some of our users (only a few, and not me on
my development machines) end up with toolbar items that have a
very odd appearance---some are
>>> 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
Gabriel,
> On Mar 23, 2020, at 8:54 AM, 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
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
12 matches
Mail list logo
