Re: NSOpenPanel runModal on a dispatch
On 17 Dec 2012, at 05:58, Tamas Nagy tamas.lov.n...@gmail.com wrote: It's a live video app, where rendering happening on a CVDisplayLink thread, so the app still running and do its job while an OpenPanel (or SavePanel) displaying. I just need to block the UI to make sure the users can't interact the app while an open panel displaying. But why? What's the issue with the user pausing a video while an open panel happens to be open? Thanks Tom Davie ___ 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: NSOpenPanel runModal on a dispatch
I really appreciate your continuous curiosity guys, but we just getting off-topic :) BTW, its a realtime graphics application, where UI events should not blocking rendering. Think about a concert where some videos projected behind the band, it would be bad if opening the next video - putting it into some kind of queue - blocks the rendering/displaying the current video. On Dec 17, 2012, at 10:06 AM, Tom Davie tom.da...@gmail.com wrote: On 17 Dec 2012, at 05:58, Tamas Nagy tamas.lov.n...@gmail.com wrote: It's a live video app, where rendering happening on a CVDisplayLink thread, so the app still running and do its job while an OpenPanel (or SavePanel) displaying. I just need to block the UI to make sure the users can't interact the app while an open panel displaying. But why? What's the issue with the user pausing a video while an open panel happens to be open? Thanks Tom Davie ___ 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: NSOpenPanel runModal on a dispatch
On 17 Dec 2012, at 09:26, Tamas Nagy tamas.lov.n...@gmail.com wrote: I really appreciate your continuous curiosity guys, but we just getting off-topic :) BTW, its a realtime graphics application, where UI events should not blocking rendering. Think about a concert where some videos projected behind the band, it would be bad if opening the next video - putting it into some kind of queue - blocks the rendering/displaying the current video. You're right, it would be bad… Surely that's a good reason why it would be bad that the user of such an app couldn't go oh crap, I forgot to start that fade, and start it, with the open panel for the next video open? Thanks Tom Davie ___ 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: NSOpenPanel runModal on a dispatch
The user is still able to control things like fading with a MIDI/OSC controller - they definitely do not do that with mouse. But there are things which only controllable with the UI, deleting layers for example. And there are some circumstances - for example, loading a whole project, where the app's state just reseted before displaying the open panel, and the loading process presume everything is clear when iterating thru the load data, so it could would be bad if the app's clear state can change when an open panel is opened. On Dec 17, 2012, at 10:29 AM, Tom Davie tom.da...@gmail.com wrote: On 17 Dec 2012, at 09:26, Tamas Nagy tamas.lov.n...@gmail.com wrote: I really appreciate your continuous curiosity guys, but we just getting off-topic :) BTW, its a realtime graphics application, where UI events should not blocking rendering. Think about a concert where some videos projected behind the band, it would be bad if opening the next video - putting it into some kind of queue - blocks the rendering/displaying the current video. You're right, it would be bad… Surely that's a good reason why it would be bad that the user of such an app couldn't go oh crap, I forgot to start that fade, and start it, with the open panel for the next video open? Thanks Tom Davie ___ 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: NSOpenPanel runModal on a dispatch
On 17 Dec 2012, at 09:42, Tamas Nagy tamas.lov.n...@gmail.com wrote: The user is still able to control things like fading with a MIDI/OSC controller - they definitely do not do that with mouse. But there are things which only controllable with the UI, deleting layers for example. And there are some circumstances - for example, loading a whole project, where the app's state just reseted before displaying the open panel, and the loading process presume everything is clear when iterating thru the load data, so it could would be bad if the app's clear state can change when an open panel is opened. Wouldn't the correct thing in this state be to create a new project window associated with the project document, and then fire of an open sheet for that window so that it's only modal for the window? Thanks Tom Davie ___ 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: NSOpenPanel runModal on a dispatch
There is a chance in the application where only one, borderless window displayed on the secondary screen, so there are possible circumstances where displaying a window-modal panel not quite useful. On Dec 17, 2012, at 10:50 AM, Tom Davie tom.da...@gmail.com wrote: On 17 Dec 2012, at 09:42, Tamas Nagy tamas.lov.n...@gmail.com wrote: The user is still able to control things like fading with a MIDI/OSC controller - they definitely do not do that with mouse. But there are things which only controllable with the UI, deleting layers for example. And there are some circumstances - for example, loading a whole project, where the app's state just reseted before displaying the open panel, and the loading process presume everything is clear when iterating thru the load data, so it could would be bad if the app's clear state can change when an open panel is opened. Wouldn't the correct thing in this state be to create a new project window associated with the project document, and then fire of an open sheet for that window so that it's only modal for the window? Thanks Tom Davie ___ 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: NSOpenPanel runModal on a dispatch
On 17 Dec 2012, at 10:11, Tamas Nagy tamas.lov.n...@gmail.com wrote: There is a chance in the application where only one, borderless window displayed on the secondary screen, so there are possible circumstances where displaying a window-modal panel not quite useful. Okay, but your example of when modality was required involved a project being in an inconsistent state, and requiring information from the open dialog before it was complete… In this scenario the open dialog can be attached to the inconsistent project's window. Or are you trying to assert that you can have the app sat there, doing nothing, with no significant windows open, yet in an inconsistent state, and requiring modal interaction to sort it out? If that's your assertion, then I'd suggest you have a deeper seated design bug. Thanks Tom Davie ___ 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: NSOpenPanel runModal on a dispatch
Yep, its a design bug for sure, which I should and will fix. On Dec 17, 2012, at 11:14 AM, Tom Davie tom.da...@gmail.com wrote: On 17 Dec 2012, at 10:11, Tamas Nagy tamas.lov.n...@gmail.com wrote: There is a chance in the application where only one, borderless window displayed on the secondary screen, so there are possible circumstances where displaying a window-modal panel not quite useful. Okay, but your example of when modality was required involved a project being in an inconsistent state, and requiring information from the open dialog before it was complete… In this scenario the open dialog can be attached to the inconsistent project's window. Or are you trying to assert that you can have the app sat there, doing nothing, with no significant windows open, yet in an inconsistent state, and requiring modal interaction to sort it out? If that's your assertion, then I'd suggest you have a deeper seated design bug. Thanks Tom Davie ___ 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: NSOpenPanel runModal on a dispatch
On Sun, 16 Dec 2012 21:46:14 -0800, Kyle Sluder said: Thanks Kyle. I know about beginWithCompletionHandler: , but I really need a modal window at that point my application opens the open panel. I have to ask, why? Sometimes it's appropriate. Apple seems to think so, as File Open shows a modal open panel. Cheers, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ 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: NSOpenPanel runModal on a dispatch
On Sun, 16 Dec 2012 11:45:29 +0100, Tamas Nagy said: I'm trying to display an NSOpenPanel on a dispatch, with half-luck. The panel displays, but no files going to be displayed - the circle just spinning on the bottom-left corner. Anyone have an idea what going wrong? Others have explained what's going on here. There is a UI workaround... if you switch between icon and list view, it prods the thing into working. I'll just add that my bug on this is radar://10614610. I consider it unlikely to get fixed given the time that's elapsed. In my case I was showing an openpanel during document opening (to prompt the user to find a file if an alias failed to resolve). Between 10.6 and 10.7, with all the doc architecture changes, an override point in NSDocument starting using GCD and suddenly modal openpanels become unsafe to use there. :( Cheers, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ 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: NSOpenPanel runModal on a dispatch
On 17 Dec 2012, at 17:15, Sean McBride s...@rogue-research.com wrote: On Sun, 16 Dec 2012 21:46:14 -0800, Kyle Sluder said: Thanks Kyle. I know about beginWithCompletionHandler: , but I really need a modal window at that point my application opens the open panel. I have to ask, why? Sometimes it's appropriate. Apple seems to think so, as File Open shows a modal open panel. For what it's worth, OS X v10.8 Mountain Lion finally fixes this by making open panels non-modal. I think apps do need to be built against the new SDK for it, rather than automatically switching over to such behaviour. ___ 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: NSOpenPanel runModal on a dispatch
On Mon, Dec 17, 2012, at 03:15 PM, Mike Abdullah wrote: On 17 Dec 2012, at 17:15, Sean McBride s...@rogue-research.com wrote: On Sun, 16 Dec 2012 21:46:14 -0800, Kyle Sluder said: Thanks Kyle. I know about beginWithCompletionHandler: , but I really need a modal window at that point my application opens the open panel. I have to ask, why? Sometimes it's appropriate. Apple seems to think so, as File Open shows a modal open panel. For what it's worth, OS X v10.8 Mountain Lion finally fixes this by making open panels non-modal. I think apps do need to be built against the new SDK for it, rather than automatically switching over to such behaviour. Is this true for all open panels, or only ones that use the new iCloud-aware open panel? --Kyle Sluder ___ 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: NSOpenPanel runModal on a dispatch
On Mon, 17 Dec 2012 23:15:15 +, Mike Abdullah said: For what it's worth, OS X v10.8 Mountain Lion finally fixes this by making open panels non-modal. I think apps do need to be built against the new SDK for it, rather than automatically switching over to such behaviour. In in 10.8.2 now, and in TextEdit they are app-modal. It's Info.list shows LSMinimumSystemVersion=10.8. Not the case for you? Cheers, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ 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: NSOpenPanel runModal on a dispatch
On Mon, Dec 17, 2012, at 03:25 PM, Sean McBride wrote: On Mon, 17 Dec 2012 23:15:15 +, Mike Abdullah said: For what it's worth, OS X v10.8 Mountain Lion finally fixes this by making open panels non-modal. I think apps do need to be built against the new SDK for it, rather than automatically switching over to such behaviour. In in 10.8.2 now, and in TextEdit they are app-modal. It's Info.list shows LSMinimumSystemVersion=10.8. Not the case for you? Certainly not app-modal on my 10.8.2 machine. Nor is it modal in Preview. --Kyle Sluder ___ 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: NSOpenPanel runModal on a dispatch
On 17 Dec 2012, at 23:29, Kyle Sluder k...@ksluder.com wrote: On Mon, Dec 17, 2012, at 03:25 PM, Sean McBride wrote: On Mon, 17 Dec 2012 23:15:15 +, Mike Abdullah said: For what it's worth, OS X v10.8 Mountain Lion finally fixes this by making open panels non-modal. I think apps do need to be built against the new SDK for it, rather than automatically switching over to such behaviour. In in 10.8.2 now, and in TextEdit they are app-modal. It's Info.list shows LSMinimumSystemVersion=10.8. Not the case for you? Certainly not app-modal on my 10.8.2 machine. Nor is it modal in Preview. Maybe you have to be setup with an iCloud account too for the new behaviour? Would be a bit odd if that were true though. ___ 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: NSOpenPanel runModal on a dispatch
On Dec 17, 2012, at 5:29 PM, Kyle Sluder k...@ksluder.com wrote: On Mon, Dec 17, 2012, at 03:25 PM, Sean McBride wrote: On Mon, 17 Dec 2012 23:15:15 +, Mike Abdullah said: For what it's worth, OS X v10.8 Mountain Lion finally fixes this by making open panels non-modal. I think apps do need to be built against the new SDK for it, rather than automatically switching over to such behaviour. In in 10.8.2 now, and in TextEdit they are app-modal. It's Info.list shows LSMinimumSystemVersion=10.8. Not the case for you? Certainly not app-modal on my 10.8.2 machine. Nor is it modal in Preview. On my 10.8.2 machine, it's app-modal in both apps. Charles ___ 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: NSOpenPanel runModal on a dispatch
On 16 Dec 2012, at 10:45, Tamas Nagy tamas.lov.n...@gmail.com wrote:
Hey,
I'm trying to display an NSOpenPanel on a dispatch, with half-luck. The panel
displays, but no files going to be displayed - the circle just spinning on
the bottom-left corner. Anyone have an idea what going wrong?
Thanks,
Tamas
dispatch_async(dispatch_get_main_queue(), ^{
NSOpenPanel *oPanel = [NSOpenPanel openPanel];
NSMutableArray *filetype = [NSMutableArray arrayWithCapacity:0];
[filetype insertObject:@txt atIndex:0];
[oPanel setAllowedFileTypes:filetype];
[oPanel setDirectoryURL:[NSURL URLWithString:NSHomeDirectory()]];
NSInteger returnCode = [oPanel runModal];
if (returnCode == NSOKButton) {
NSLog(@OK!);
} else {
NSLog(@Cancel!);
}
});
I can't see off the top of my head what's going wrong here, but I just thought
I'd comment that that looks like a pretty bizarre way of creating a constant
array.
1) You know exactly how big the array's going to be – 1 object, so why hint
that it's going to contain 0 objects?
2) Why use insertObject: atIndex:0 rather than addObject:
3) Why use a mutable array at all? You could just use a constant array –
NSArray *filetype = [NSArray arrayWithObject:@txt];
4) The above can then be further condensed with the new syntactic sugar for
arrays: NSArray *filetype = @[ @txt ];
Thanks
Tom Davie
___
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: NSOpenPanel runModal on a dispatch
Thanks for the suggestions Tom. I know about that things, but the original code
was a bit bigger, where I need a mutable array and other stuff, and just
trimmed out for the example.
But to back to on-topic: the code works fine on 10.6.8, the issue happens only
on 10.7.5 and 10.8.2. If I call the method with performSelectorOnMainThread…
instead of dispatching, everything works fine. Maybe I found a bug.
On Dec 16, 2012, at 4:32 PM, Tom Davie tom.da...@gmail.com wrote:
On 16 Dec 2012, at 10:45, Tamas Nagy tamas.lov.n...@gmail.com wrote:
Hey,
I'm trying to display an NSOpenPanel on a dispatch, with half-luck. The
panel displays, but no files going to be displayed - the circle just
spinning on the bottom-left corner. Anyone have an idea what going wrong?
Thanks,
Tamas
dispatch_async(dispatch_get_main_queue(), ^{
NSOpenPanel *oPanel = [NSOpenPanel openPanel];
NSMutableArray *filetype = [NSMutableArray arrayWithCapacity:0];
[filetype insertObject:@txt atIndex:0];
[oPanel setAllowedFileTypes:filetype];
[oPanel setDirectoryURL:[NSURL URLWithString:NSHomeDirectory()]];
NSInteger returnCode = [oPanel runModal];
if (returnCode == NSOKButton) {
NSLog(@OK!);
} else {
NSLog(@Cancel!);
}
});
I can't see off the top of my head what's going wrong here, but I just
thought I'd comment that that looks like a pretty bizarre way of creating a
constant array.
1) You know exactly how big the array's going to be – 1 object, so why hint
that it's going to contain 0 objects?
2) Why use insertObject: atIndex:0 rather than addObject:
3) Why use a mutable array at all? You could just use a constant array –
NSArray *filetype = [NSArray arrayWithObject:@txt];
4) The above can then be further condensed with the new syntactic sugar for
arrays: NSArray *filetype = @[ @txt ];
Thanks
Tom Davie
___
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: NSOpenPanel runModal on a dispatch
On 16 Dec 2012, at 10:45, Tamas Nagy wrote:
Hey,
I'm trying to display an NSOpenPanel on a dispatch, with half-luck. The panel
displays, but no files going to be displayed - the circle just spinning on
the bottom-left corner. Anyone have an idea what going wrong?
Thanks,
Tamas
dispatch_async(dispatch_get_main_queue(), ^{
NSOpenPanel *oPanel = [NSOpenPanel openPanel];
NSMutableArray *filetype = [NSMutableArray arrayWithCapacity:0];
[filetype insertObject:@txt atIndex:0];
[oPanel setAllowedFileTypes:filetype];
[oPanel setDirectoryURL:[NSURL URLWithString:NSHomeDirectory()]];
This line of code is your problem. +URLWithString: is not an appropriate way to
create a URL from a path. +fileURLWithPath:isDirectory: is what you want
instead.
+[NSSavePanel setDirectoryURL:] behaves oddly with non-existing paths, as
covered at http://www.mikeabdullah.net/pre-populating-nssavepanel.html
___
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: NSOpenPanel runModal on a dispatch
Unfortunately that doesn't help.
I think the issue should be related to dispatches, because it won't happen if I
just call performSelectorOnMainThread...
On Dec 16, 2012, at 6:05 PM, Mike Abdullah cocoa...@mikeabdullah.net wrote:
On 16 Dec 2012, at 10:45, Tamas Nagy wrote:
Hey,
I'm trying to display an NSOpenPanel on a dispatch, with half-luck. The
panel displays, but no files going to be displayed - the circle just
spinning on the bottom-left corner. Anyone have an idea what going wrong?
Thanks,
Tamas
dispatch_async(dispatch_get_main_queue(), ^{
NSOpenPanel *oPanel = [NSOpenPanel openPanel];
NSMutableArray *filetype = [NSMutableArray arrayWithCapacity:0];
[filetype insertObject:@txt atIndex:0];
[oPanel setAllowedFileTypes:filetype];
[oPanel setDirectoryURL:[NSURL URLWithString:NSHomeDirectory()]];
This line of code is your problem. +URLWithString: is not an appropriate way
to create a URL from a path. +fileURLWithPath:isDirectory: is what you want
instead.
+[NSSavePanel setDirectoryURL:] behaves oddly with non-existing paths, as
covered at http://www.mikeabdullah.net/pre-populating-nssavepanel.html
___
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: NSOpenPanel runModal on a dispatch
On Dec 16, 2012, at 2:45 AM, Tamas Nagy tamas.lov.n...@gmail.com wrote:
dispatch_async(dispatch_get_main_queue(), ^{
NSOpenPanel *oPanel = [NSOpenPanel openPanel];
*Bzzt!* Thou shalt not do UI work on a background thread. You cannot use
dispatch_async here.
--Kyle Sluder
___
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: NSOpenPanel runModal on a dispatch
On 16 Dec 2012, at 18:32, Kyle Sluder wrote:
On Dec 16, 2012, at 2:45 AM, Tamas Nagy tamas.lov.n...@gmail.com wrote:
dispatch_async(dispatch_get_main_queue(), ^{
NSOpenPanel *oPanel = [NSOpenPanel openPanel];
*Bzzt!* Thou shalt not do UI work on a background thread. You cannot use
dispatch_async here.
*Bzzt* he's not doing UI work on a background thread. In any normal app, this
is running the code on the main thread.
___
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: NSOpenPanel runModal on a dispatch
On 16 Dec 2012, at 17:20, Tamas Nagy wrote: Unfortunately that doesn't help. I think the issue should be related to dispatches, because it won't happen if I just call performSelectorOnMainThread... Can you post that variant of your code then, please? ___ 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: NSOpenPanel runModal on a dispatch
On Dec 16, 2012, at 10:39 AM, Mike Abdullah cocoa...@mikeabdullah.net wrote:
On 16 Dec 2012, at 18:32, Kyle Sluder wrote:
On Dec 16, 2012, at 2:45 AM, Tamas Nagy tamas.lov.n...@gmail.com wrote:
dispatch_async(dispatch_get_main_queue(), ^{
NSOpenPanel *oPanel = [NSOpenPanel openPanel];
*Bzzt!* Thou shalt not do UI work on a background thread. You cannot use
dispatch_async here.
*Bzzt* he's not doing UI work on a background thread. In any normal app, this
is running the code on the main thread.
Yeah. Um. Oops.
My apologies.
--Kyle Sluder
___
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: NSOpenPanel runModal on a dispatch
On Sun, Dec 16, 2012, at 10:40 AM, Mike Abdullah wrote:
On 16 Dec 2012, at 17:20, Tamas Nagy wrote:
Unfortunately that doesn't help.
I think the issue should be related to dispatches, because it won't happen
if I just call performSelectorOnMainThread...
Can you post that variant of your code then, please?
Now that I'm actually awake, I'm able to reproduce Tamas's issue with a
bare-bones Cocoa App on 10.7.5. Here's my app delegate:
@implementation AppDelegate
- (NSInteger)doOpenPanel:(id)unused;
{
return [[NSOpenPanel openPanel] runModal];
}
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification
{
#if 0
dispatch_async(dispatch_get_main_queue(), ^{
[self doOpenPanel:nil];
});
#else
[self performSelector:@selector(doOpenPanel:) withObject:nil
afterDelay:0];
#endif
}
@end
If you go with the dispatch approach, you get the eternal spinner, and
files never show up—or if they do, their QuickLook previews never show
up. Notably, you can still interact with the open panel. If you go with
-performSelector:::, it works fine.
My guess is that NSOpenPanel is doing some work on a background thread,
and that work is trying to use the main queue to inform the open panel
of its completion. By using the dispatch_async approach, the main queue
is blocked, and the background thread can't inform the open panel. The
-performSelector::: approach uses a timer, so the nested invocation of
the runloop that -runModal performs is still able to dequeue the
background task completion's block off the main queue.
--Kyle Sluder
___
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: NSOpenPanel runModal on a dispatch
On Sun, Dec 16, 2012, at 11:28 AM, Kyle Sluder wrote: My guess is that NSOpenPanel is doing some work on a background thread, and that work is trying to use the main queue to inform the open panel of its completion. By using the dispatch_async approach, the main queue is blocked, and the background thread can't inform the open panel. The -performSelector::: approach uses a timer, so the nested invocation of the runloop that -runModal performs is still able to dequeue the background task completion's block off the main queue. To follow up: In general, it's just a bad idea to block the main queue. It so happens that currently CFRunLoop is responsible for draining the main queue in a runloop-based app, so your app is able to hobble along firing timers and doing delayed-performs. But one can envision that dependency being inverted in a future release of OS X such that it's the main queue that's responsible for driving the runloop. At that point, blocking the main queue would cause deadlock when you tried to reentrantly run the runloop. In 10.6, NSOpenPanel and NSSavePanel gained a -beginWtihCompletionHandler: method that lets you run the panel as a non-modal window. Consider using that instead of -runModal. --Kyle Sluder ___ 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: NSOpenPanel runModal on a dispatch
Thanks for the approach Kyle, but dispatch_async performs asynchronously, so it should not block the main thread. I fallback to performSelectorOnMainThread: method in my app, but the dispatch way is a bit straightforward in my opinion. I'll fill a rdar on this. On Dec 16, 2012, at 8:39 PM, Kyle Sluder k...@ksluder.com wrote: On Sun, Dec 16, 2012, at 11:28 AM, Kyle Sluder wrote: My guess is that NSOpenPanel is doing some work on a background thread, and that work is trying to use the main queue to inform the open panel of its completion. By using the dispatch_async approach, the main queue is blocked, and the background thread can't inform the open panel. The -performSelector::: approach uses a timer, so the nested invocation of the runloop that -runModal performs is still able to dequeue the background task completion's block off the main queue. To follow up: In general, it's just a bad idea to block the main queue. It so happens that currently CFRunLoop is responsible for draining the main queue in a runloop-based app, so your app is able to hobble along firing timers and doing delayed-performs. But one can envision that dependency being inverted in a future release of OS X such that it's the main queue that's responsible for driving the runloop. At that point, blocking the main queue would cause deadlock when you tried to reentrantly run the runloop. In 10.6, NSOpenPanel and NSSavePanel gained a -beginWtihCompletionHandler: method that lets you run the panel as a non-modal window. Consider using that instead of -runModal. --Kyle Sluder ___ 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: NSOpenPanel runModal on a dispatch
Performing asynchronously and blocking the main *queue* are not related things. The main queue is a serial queue, it only executes one block at a time. At the moment, it's executing your block, stuck in your runModal call. That runModal call will not come off the stack, and the block finish executing until the open dialog is closed. If the openDialog methods dispatch to the main queue, their dispatches will not occur until the main queue is able to run another block, which won't happen until your block finishes. You are very much blocking the main queue. Thanks Tom Davie On 16 Dec 2012, at 20:04, Tamas Nagy tamas.lov.n...@gmail.com wrote: Thanks for the approach Kyle, but dispatch_async performs asynchronously, so it should not block the main thread. I fallback to performSelectorOnMainThread: method in my app, but the dispatch way is a bit straightforward in my opinion. I'll fill a rdar on this. On Dec 16, 2012, at 8:39 PM, Kyle Sluder k...@ksluder.com wrote: On Sun, Dec 16, 2012, at 11:28 AM, Kyle Sluder wrote: My guess is that NSOpenPanel is doing some work on a background thread, and that work is trying to use the main queue to inform the open panel of its completion. By using the dispatch_async approach, the main queue is blocked, and the background thread can't inform the open panel. The -performSelector::: approach uses a timer, so the nested invocation of the runloop that -runModal performs is still able to dequeue the background task completion's block off the main queue. To follow up: In general, it's just a bad idea to block the main queue. It so happens that currently CFRunLoop is responsible for draining the main queue in a runloop-based app, so your app is able to hobble along firing timers and doing delayed-performs. But one can envision that dependency being inverted in a future release of OS X such that it's the main queue that's responsible for driving the runloop. At that point, blocking the main queue would cause deadlock when you tried to reentrantly run the runloop. In 10.6, NSOpenPanel and NSSavePanel gained a -beginWtihCompletionHandler: method that lets you run the panel as a non-modal window. Consider using that instead of -runModal. --Kyle Sluder ___ 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/tom.davie%40gmail.com This email sent to tom.da...@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: NSOpenPanel runModal on a dispatch
Ahh, okay, thanks for the explanation Tom, now I got it. On Dec 16, 2012, at 9:21 PM, Tom Davie tom.da...@gmail.com wrote: Performing asynchronously and blocking the main *queue* are not related things. The main queue is a serial queue, it only executes one block at a time. At the moment, it's executing your block, stuck in your runModal call. That runModal call will not come off the stack, and the block finish executing until the open dialog is closed. If the openDialog methods dispatch to the main queue, their dispatches will not occur until the main queue is able to run another block, which won't happen until your block finishes. You are very much blocking the main queue. Thanks Tom Davie On 16 Dec 2012, at 20:04, Tamas Nagy tamas.lov.n...@gmail.com wrote: Thanks for the approach Kyle, but dispatch_async performs asynchronously, so it should not block the main thread. I fallback to performSelectorOnMainThread: method in my app, but the dispatch way is a bit straightforward in my opinion. I'll fill a rdar on this. On Dec 16, 2012, at 8:39 PM, Kyle Sluder k...@ksluder.com wrote: On Sun, Dec 16, 2012, at 11:28 AM, Kyle Sluder wrote: My guess is that NSOpenPanel is doing some work on a background thread, and that work is trying to use the main queue to inform the open panel of its completion. By using the dispatch_async approach, the main queue is blocked, and the background thread can't inform the open panel. The -performSelector::: approach uses a timer, so the nested invocation of the runloop that -runModal performs is still able to dequeue the background task completion's block off the main queue. To follow up: In general, it's just a bad idea to block the main queue. It so happens that currently CFRunLoop is responsible for draining the main queue in a runloop-based app, so your app is able to hobble along firing timers and doing delayed-performs. But one can envision that dependency being inverted in a future release of OS X such that it's the main queue that's responsible for driving the runloop. At that point, blocking the main queue would cause deadlock when you tried to reentrantly run the runloop. In 10.6, NSOpenPanel and NSSavePanel gained a -beginWtihCompletionHandler: method that lets you run the panel as a non-modal window. Consider using that instead of -runModal. --Kyle Sluder ___ 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/tom.davie%40gmail.com This email sent to tom.da...@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: NSOpenPanel runModal on a dispatch
On Sun, Dec 16, 2012, at 12:04 PM, Tamas Nagy wrote:
Thanks for the approach Kyle, but dispatch_async performs asynchronously,
so it should not block the main thread. I fallback to
performSelectorOnMainThread: method in my app, but the dispatch way is a
bit straightforward in my opinion. I'll fill a rdar on this.
It's not the dispatch_async() call that's blocking the main thread. It's
the block you've enqueued.
Imagine that instead of -runModal, we had this:
void DoTheThing() {
dispatch_async(dispatch_get_main_queue(), ^{
/* Let's call this POINT A. */
int result = GetTheResult();
/* Let's call this POINT C. */
NSLog(@Result: %ld, result);
});
}
int GetTheResult() {
/* We've got to do some prep work which will take a long time. Let's
show a spinner. */
ShowTheSpinner();
/* But we want to let the user interact with the dialog while we're
doing the prep work, so let's do it on a background queue. */
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT,
0),^{
DoABunchOfWork();
/* We're done! We need to hide the spinner from the main thread */
dispatch_async(dispatch_get_main_queue(), ^{
/* Let's call this POINT B. */
HideTheSpinner();
});
}
/* While the work is being done in the background, run the main
thread's runloop reentrantly until the user dismisses the dialog. We
don't return from this function until the user chooses one of those
buttons. */
while (TheUserHasntHitCancelOrOk)
[[NSRunLoop currentRunLoop] runMode:NSRunLoopCommonModes
beforeDate:[NSDate distantFuture]];
return UserCanceled ? 0 : 1;
}
As you can see, POINT B needs to happen on the main thread, so it is
wrapped inside a block that's enqueued on the main queue. But because
GetTheResult() doesn't return until the user clicks Cancel or OK, POINT
B can't execute because POINT A is still executing! The very nature of
queues says we need to get to POINT C before POINT B can execute.
--Kyle Sluder
___
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: NSOpenPanel runModal on a dispatch
On Sun, Dec 16, 2012, at 12:04 PM, Tamas Nagy wrote: Thanks for the approach Kyle, but dispatch_async performs asynchronously, so it should not block the main thread. I fallback to performSelectorOnMainThread: method in my app, but the dispatch way is a bit straightforward in my opinion. I'll fill a rdar on this. By the way, I've just filed a radar asking for -[NSOpenPanel runModal] to be deprecated: rdar://problem/12889956 -beginWithCompletionHandler: is a far better user experience, and it's immune to this problem. Use that. --Kyle Sluder ___ 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: NSOpenPanel runModal on a dispatch
On 16 Dec 2012, at 20:04, Tamas Nagy wrote: Thanks for the approach Kyle, but dispatch_async performs asynchronously, so it should not block the main thread. I fallback to performSelectorOnMainThread: method in my app, but the dispatch way is a bit straightforward in my opinion. I'll fill a rdar on this. Possibly you could still use a block-based API but that uses -performSelector… under the hood, such as https://github.com/karelia/KSThreadProxy ___ 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: NSOpenPanel runModal on a dispatch
On Dec 16, 2012, at 9:05 AM, Mike Abdullah cocoa...@mikeabdullah.net wrote:
On 16 Dec 2012, at 10:45, Tamas Nagy wrote:
Hey,
I'm trying to display an NSOpenPanel on a dispatch, with half-luck. The
panel displays, but no files going to be displayed - the circle just
spinning on the bottom-left corner. Anyone have an idea what going wrong?
Thanks,
Tamas
dispatch_async(dispatch_get_main_queue(), ^{
NSOpenPanel *oPanel = [NSOpenPanel openPanel];
NSMutableArray *filetype = [NSMutableArray arrayWithCapacity:0];
[filetype insertObject:@txt atIndex:0];
[oPanel setAllowedFileTypes:filetype];
[oPanel setDirectoryURL:[NSURL URLWithString:NSHomeDirectory()]];
This line of code is your problem. +URLWithString: is not an appropriate way
to create a URL from a path. +fileURLWithPath:isDirectory: is what you want
instead.
+[NSSavePanel setDirectoryURL:] behaves oddly with non-existing paths, as
covered at http://www.mikeabdullah.net/pre-populating-nssavepanel.html
On 10.7.4 (or there abouts) and up -setDirectoryURL will spew in the
console if you pass it a non-file URL or a nonexistent URL. It must have the
“file://“ scheme. It will also spew out the directory it will use instead,
which is usually the directory the user last visited with the app, the last
valid directory passed to -setDirectoryURL:, or ~/Documents.. The spew would
be something like this:
Invalid URL passed to an open/save panel: '/Users/rob/Desktop'. Using
'file:///Users/rob/Documents/' instead
—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
Re: NSOpenPanel runModal on a dispatch
Thanks Kyle. I know about beginWithCompletionHandler: , but I really need a modal window at that point my application opens the open panel. On Dec 16, 2012, at 9:39 PM, Kyle Sluder k...@ksluder.com wrote: On Sun, Dec 16, 2012, at 12:04 PM, Tamas Nagy wrote: Thanks for the approach Kyle, but dispatch_async performs asynchronously, so it should not block the main thread. I fallback to performSelectorOnMainThread: method in my app, but the dispatch way is a bit straightforward in my opinion. I'll fill a rdar on this. By the way, I've just filed a radar asking for -[NSOpenPanel runModal] to be deprecated: rdar://problem/12889956 -beginWithCompletionHandler: is a far better user experience, and it's immune to this problem. Use that. --Kyle Sluder ___ 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: NSOpenPanel runModal on a dispatch
On Sun, Dec 16, 2012, at 09:43 PM, Tamas Nagy wrote: Thanks Kyle. I know about beginWithCompletionHandler: , but I really need a modal window at that point my application opens the open panel. I have to ask, why? If you want to block interaction with a document, you can use -beginSheetModalForWindow:completionHandler:. What circumstances could arise that would require you to block access to the entire app? --Kyle Sluder ___ 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: NSOpenPanel runModal on a dispatch
It's a live video app, where rendering happening on a CVDisplayLink thread, so the app still running and do its job while an OpenPanel (or SavePanel) displaying. I just need to block the UI to make sure the users can't interact the app while an open panel displaying. On Dec 17, 2012, at 6:46 AM, Kyle Sluder k...@ksluder.com wrote: On Sun, Dec 16, 2012, at 09:43 PM, Tamas Nagy wrote: Thanks Kyle. I know about beginWithCompletionHandler: , but I really need a modal window at that point my application opens the open panel. I have to ask, why? If you want to block interaction with a document, you can use -beginSheetModalForWindow:completionHandler:. What circumstances could arise that would require you to block access to the entire app? --Kyle Sluder ___ 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
