>>> 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
