Re: NSToolbar in Catalina
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 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 imageForResource > > image = [NSBundle imageForResource:imgName]; > > -Dave > > On 3/23/20, 1:10 PM, "Cocoa-dev on behalf of Tom Doan via > Cocoa-dev" on behalf of Cocoa-dev@lists.apple.com> wrote: > > 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 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 fine, some are > completely whited out, some are > almost completely whited out > with some odd colors added, usually pale > pink in an area which > has nothing to do with the original icon > appearance. The washed > out icons have nothing to do with them being > tagged > inactive---on my machine, inactive icons look correctly dimmed > > and the washed out ones are supposed to be active anyway. Does > anyone > have an idea what the problem might be? > > Best regards, > > > Tom Doan > Estima > --- > 2717 Harrison St > Evanston, IL > 60201 > USA > > > ___ > > > 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/tomd%40estima.co > m > > This email sent to t...@estima.com > > > --- > 2717 Harrison St > Evanston, IL 60201 > USA > > > ___ > > 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.stjohn%40x > erox.com > > This email sent to david.stj...@xerox.com > > --- 2717 Harrison St Evanston, IL 60201 USA ___ 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: NSToolbar in Catalina
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 imageForResource image = [NSBundle imageForResource:imgName]; -Dave On 3/23/20, 1:10 PM, "Cocoa-dev on behalf of Tom Doan via Cocoa-dev" wrote: 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 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 fine, some are completely whited out, some are > almost completely whited out with some odd colors added, usually pale > pink in an area which has nothing to do with the original icon > appearance. The washed out icons have nothing to do with them being > tagged inactive---on my machine, inactive icons look correctly dimmed > and the washed out ones are supposed to be active anyway. Does anyone > have an idea what the problem might be? > > Best regards, > > Tom Doan > Estima > --- > 2717 Harrison St > Evanston, IL 60201 > USA > > > ___ > > 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/tomd%40estima.com > > This email sent to t...@estima.com --- 2717 Harrison St Evanston, IL 60201 USA ___ 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.stjohn%40xerox.com This email sent to david.stj...@xerox.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: NSToolbar in Catalina
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 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 fine, some are completely whited out, some are > almost completely whited out with some odd colors added, usually pale > pink in an area which has nothing to do with the original icon > appearance. The washed out icons have nothing to do with them being > tagged inactive---on my machine, inactive icons look correctly dimmed > and the washed out ones are supposed to be active anyway. Does anyone > have an idea what the problem might be? > > Best regards, > > Tom Doan > Estima > --- > 2717 Harrison St > Evanston, IL 60201 > USA > > > ___ > > 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/tomd%40estima.com > > This email sent to t...@estima.com --- 2717 Harrison St Evanston, IL 60201 USA ___ 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?
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: Open a panel in secondary thread?
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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Open a panel in secondary thread?
> > 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. So, it is fine if the process stops while asking. > Is the user allowed to interact with the app while this is going on, No. 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Open a panel in secondary thread?
> 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 I thought. >>> As far as I understand, the dispatch_get_main_queue is executed by the main >>> thread, isn't it? >> Yes > > So, why is >dispatch_sync( dispatch_get_main_queue(), block opening a NSOpenPanel ) > a bad idea? I think it’s fine if the following is true… you are ok with blocking your secondary thread while the user interacts with the panel. > >>> >>> 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. >> >> This is all reasonable… I guess there may be two options, ask the user on >> the main thread, before you are on your background thread, > > Would be doable, but would complicate the code, because > > I would first need to scan the whole directory tree for aliases, I haven’t had much experience with needing to request permission to access files, but I thought you’d have to ask permission before scanning. Are you allowed to scan before you ask for permission? > get user permission , > then pass the array of directories to a secondary thread. > > Also, I would like to give the user progress info while the secondary thread > is collecting. Yes, understood. Does the user have to ask for this process to begin, or does it start automatically? Is the user allowed to interact with the app while this is going on, or does the UI just update with progress? Sandor > >> and only start the background thread after the user answers, or dispatch the >> UI work to the main thread from your background thread as your code sample >> showed. > > So my solution is viable ? > > > 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Open a panel in secondary thread?
> 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 thread, >>> or so I thought. >>> As far as I understand, the dispatch_get_main_queue is executed by the main >>> thread, isn't it? >> Yes > > So, why is > dispatch_sync( dispatch_get_main_queue(), block opening a NSOpenPanel ) > a bad idea? It’s not a bad idea. I misread the code. I didn’t see dispatch_get_main_queue. Sorry about that. This will invoke the open panel on the main thread and not return until the panel is dismissed. >>> 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. >> >> This is all reasonable… I guess there may be two options, ask the user on >> the main thread, before you are on your background thread, > > Would be doable, but would complicate the code, because I would first need to > scan > the whole directory tree for aliases, get user permission , then pass the > array of directories to a secondary thread. > > Also, I would like to give the user progress info while the secondary thread > is collecting. > >> and only start the background thread after the user answers, or dispatch the >> UI work to the main thread from your background thread as your code sample >> showed. > > So my solution is viable ? Yes. —Rob ___ 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
NSToolbar in Catalina
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 fine, some are completely whited out, some are almost completely whited out with some odd colors added, usually pale pink in an area which has nothing to do with the original icon appearance. The washed out icons have nothing to do with them being tagged inactive---on my machine, inactive icons look correctly dimmed and the washed out ones are supposed to be active anyway. Does anyone have an idea what the problem might be? Best regards, Tom Doan Estima --- 2717 Harrison St Evanston, IL 60201 USA ___ 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?
>>> 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? > Yes So, why is dispatch_sync( dispatch_get_main_queue(), block opening a NSOpenPanel ) a bad idea? >> >> 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. > > This is all reasonable… I guess there may be two options, ask the user on > the main thread, before you are on your background thread, Would be doable, but would complicate the code, because I would first need to scan the whole directory tree for aliases, get user permission , then pass the array of directories to a secondary thread. Also, I would like to give the user progress info while the secondary thread is collecting. > and only start the background thread after the user answers, or dispatch the > UI work to the main thread from your background thread as your code sample > showed. So my solution is viable ? 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Open a panel in secondary thread?
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 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? Yes > > >> 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. This is all reasonable… I guess there may be two options, ask the user on the main thread, before you are on your background thread, and only start the background thread after the user answers, or dispatch the UI work to the main thread from your background thread as your code sample showed. The fact you have to block (dispatch_sync) your background thread sort of leads me to think you could be avoiding the extra care needed to run things on the main thread by calling in before you start your background thread. Sandor > > 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/admin.szatmari.net%40gmail.com > > This email sent to admin.szatmari@gmail.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?
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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
