Re: problem with NSWorkspace running apps
On Sep 4, 2014, at 10:25 PM, Jens Alfke j...@mooseyard.com wrote: I think what's actually going on is that the app doesn't show up as running until it's gotten far enough into its launch process to check in with the WindowServer. You're dealing with a multi-threaded system, so it makes total sense that an app hasn't shown up a microsecond after you told the system to launch it. No, it's running and processing events. If I single-step in the debugger, I can even bring the app to the front after launching, do things in it, switch back to my app in the debugger, get the list of apps, and it's not listed. -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ 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: problem with NSWorkspace running apps
On Sep 4, 2014, at 11:22 PM, Ken Thomases k...@codeweavers.com wrote: -[NSWorkspace launchApplicationAtURL:options:configuration:error:] directly returns the NSRunningApplication that it launched. You can get the URL using -URLForApplicationWithBundleIdentifier: in order to work from a bundle identifier, similarly to -launchAppWithBundleIdentifier:. I'd missed URLForApplicationWithBundleIdentifier in the docs. That's exactly what I need. In fact, if I have the URL, I don't even need the NSRunningApplication, so one way or or the other, that will do it for me. -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ 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
button in the class which inherit from UIView
I wirte a class which inherit from UIView to show the view.This view include a button.And how can i implement the respond method of this button.UIView class can’t respond button respond method. ___ 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: Checking security settings?
On Thursday, September 4, 2014, Britt Durbrow bdurb...@rattlesnakehillsoftworks.com wrote: I need to verify that the user has a login password set; and to verify that they have a screensaver turned on with a password requirement (I’m trying to make sure that the workstation is HIPAA compliant before launching my app). I don’t need to actually fetch the password or change the system settings; just make sure that they exist. Is there an API for this? (I’d much rather not try to go spelunking around in prefs files myself… and I’d like to keep my app sandbox friendly as well) I don't know if there's an API, but I can tell you that it is extremely unlikely that it will be sandbox compatible. Unless I am severely mistaken, sand boxing is not designed to let you see details like that because whether or not the user has a password is of no concern to an app in the Mac App Store. You may be able to get what you need through the defaults system, particularly in regards to the screensaver... you will very likely need temporary entitlements though. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com javascript:;) 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/sevenbitstech%40gmail.com This email sent to sevenbitst...@gmail.com javascript:; ___ 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: button in the class which inherit from UIView
On Friday, September 5, 2014, bigpig bigpig1...@gmail.com wrote: I wirte a class which inherit from UIView to show the view.This view include a button.And how can i implement the respond method of this button.UIView class can’t respond button respond method. To do it programmatically, you call -setAction: on the desired button and pass to that function the selector of the method to call when it is pressed. I suggest that you check out a tutorial on the basics of Cocoa and iOS development before moving forward. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com javascript:;) 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/sevenbitstech%40gmail.com This email sent to sevenbitst...@gmail.com javascript:; ___ 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: Checking security settings?
It might be better to make your app itself enforce the HIPAA requirements — for example, blank the application's windows after a period of no activity, and require a passcode to un-blank them. That won't involve any sandboxing issues. —Jens ___ 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: Checking security settings?
If I can’t find an officially supported way to do this, then yeah - that’s what I figure I’ll have to do. I was trying to avoid it due to user experience issues; requiring a second login, etc is cumbersome every time somebody wants to record something in the app… sigh Oh well... On Sep 5, 2014, at 8:59 AM, Jens Alfke j...@mooseyard.com wrote: It might be better to make your app itself enforce the HIPAA requirements — for example, blank the application's windows after a period of no activity, and require a passcode to un-blank them. That won't involve any sandboxing issues. —Jens ___ 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: Checking security settings?
On Sep 5, 2014, at 10:15 , Britt Durbrow bdurb...@rattlesnakehillsoftworks.com wrote: If I can’t find an officially supported way to do this, then yeah - that’s what I figure I’ll have to do. I was trying to avoid it due to user experience issues; requiring a second login, etc is cumbersome every time somebody wants to record something in the app… sigh Oh well... It was never a workable idea, though. It’d be just as bad for a user to set a password of ‘123456’ as having no password, for example, and there’d never be an API that *told* you what the password was so you could check if it was good enough. Similarly, you’d never have a way of checking that the current screensaver actually *obscured* the screen contents. Given the rumors floating around about next week’s grand revelation event, you might also want to hold off making any decisions until you see what Apple will have to offer. With Health Kit, Home Kit, wearables and payments being bruited, there might turn out to be something secure that would ease the second-login problem. ___ 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: Checking security settings?
On Friday, September 5, 2014, Quincey Morris quinceymor...@rivergatesoftware.com wrote: On Sep 5, 2014, at 10:15 , Britt Durbrow bdurb...@rattlesnakehillsoftworks.com javascript:; wrote: If I can’t find an officially supported way to do this, then yeah - that’s what I figure I’ll have to do. I was trying to avoid it due to user experience issues; requiring a second login, etc is cumbersome every time somebody wants to record something in the app… sigh Oh well... It was never a workable idea, though. It’d be just as bad for a user to set a password of ‘123456’ as having no password, for example, and there’d never be an API that *told* you what the password was so you could check if it was good enough. Similarly, you’d never have a way of checking that the current screensaver actually *obscured* the screen contents. That's very true - my current screensaver for example applies visual effects to my screen - it distorts, but does not obscure, my screen contents. Under HIPAA your idea was never workable due to practical limitations. Given the rumors floating around about next week’s grand revelation event, you might also want to hold off making any decisions until you see what Apple will have to offer. With Health Kit, Home Kit, wearables and payments being bruited, there might turn out to be something secure that would ease the second-login problem. Second. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com javascript:;) 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/sevenbitstech%40gmail.com This email sent to sevenbitst...@gmail.com javascript:; ___ 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
dispatch_sync(dispatch_get_main_queue() UI weirdness
This is for MacOS not iOS.
If your running code on a GCD queue
dispatch_sync(dispatch_get_main_queue(), ^{
//do UI stuff
});
is pretty much the way to do UI stuff on the main thread/queue which seems to
work well for iOS. MacOS seems to be a different story. Try this for a simple
example
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification
{
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT,
0), ^{
// So my app is doing some background stuff
// and I need a file from the user so
// code blah blah code
dispatch_sync(dispatch_get_main_queue(), ^{
NSOpenPanel *op = [NSOpenPanel openPanel];
[op runModal];
});
// resume code blah blah code
});
}
when the NSOpenPanel opens all kinds of weirdness is going on. The scroll views
scroll very erratically if at all and the directories don't list properly. I'm
just using the NSOpenPanel here as an example, this also happens with any view
that contains a scroll view (so I've tested so far). Is this a bug? Are others
seeing this or is it just me and is there another preferred way of doing this?
___
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: dispatch_sync(dispatch_get_main_queue() UI weirdness
On Sep 5, 2014, at 11:44 AM, Jonathan Guy jonathan...@mac.com wrote: when the NSOpenPanel opens all kinds of weirdness is going on. The scroll views scroll very erratically if at all and the directories don't list properly. Well, you've blocked one of the threads that services the global dispatch queue — it's stuck in a dispatch_sync call that won't return until the user dismisses the open panel. I don't know exactly what kinds of problems blocking the queue will cause, but it's definitely not a good idea. (The problems you report sound more severe than what I would guess would happen, but I definitely don't know how concurrent dispatch queues are implemented.) You should rewrite your code to use dispatch_async instead. Then when the modal session completes, call back to the global dispatch queue to finish running your code. (And the whole scenario you're giving sounds like bad UI design — your code shouldn't suddenly pop up a modal panel just because you need a file from the user. The user should be in control of tasks like opening files. But you may have created an unrealistic scenario just as an example…) —Jens ___ 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: dispatch_sync(dispatch_get_main_queue() UI weirdness
I’m using a third party c library that requires registering a callback which
gets called if the operation encounters an invalid server certificate (should i
accept or reject the cert). The callback needs to return yes or no, which I
need to get via a UI prompt so the prompt needs to block so I can return
appropriately from the callback. So my initial thoughts are “present the cert
in a modal window”. So I put the cert in a SFCertificateView in a scroll view
and present it in a modal window but it could not be scrolled up and down which
was the initial problem. I also tried the SFCertificatePanel with the same
problem. After testing I found I couldn’t scroll any scroll view so I knocked
up that small bit of code to show as an example. I tried using
performSelectorOnMainThread and waiting until completion and this funnily
enough works fine in terms of absolutely no UI weirdness but I can’t get a
return value from that plus there were other issues.
There could be any number of operations running concurrently and any one could
require validation at any time.
The callback is basically structured like this
__block BOOL accept;
if ([NSThread isMainThread]) {
accept = [[Controller sharedController] shouldIAccept:certInfo];
}
else {
dispatch_sync(dispatch_get_main_queue(), ^{
accept = [[Controller sharedController]
shouldIAccept:certInfo];
// This is where UI starts playing up when the
controller shows the cert
});
}
return accept;
So the shouldIAccept method needs to block hence runModal. I also just threw
the window up and created my own modal loop but same problem.
On 5 Sep 2014, at 19:59, Jens Alfke j...@mooseyard.com wrote:
On Sep 5, 2014, at 11:44 AM, Jonathan Guy jonathan...@mac.com wrote:
when the NSOpenPanel opens all kinds of weirdness is going on. The scroll
views scroll very erratically if at all and the directories don't list
properly.
Well, you've blocked one of the threads that services the global dispatch
queue — it's stuck in a dispatch_sync call that won't return until the user
dismisses the open panel. I don't know exactly what kinds of problems
blocking the queue will cause, but it's definitely not a good idea. (The
problems you report sound more severe than what I would guess would happen,
but I definitely don't know how concurrent dispatch queues are implemented.)
You should rewrite your code to use dispatch_async instead. Then when the
modal session completes, call back to the global dispatch queue to finish
running your code.
(And the whole scenario you're giving sounds like bad UI design — your code
shouldn't suddenly pop up a modal panel just because you need a file from
the user. The user should be in control of tasks like opening files. But you
may have created an unrealistic scenario just as an example…)
—Jens
___
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: dispatch_sync(dispatch_get_main_queue() UI weirdness
On Sep 5, 2014, at 13:31 , Jonathan Guy jonathan...@mac.com wrote:
The callback is basically structured like this
__block BOOL accept;
if ([NSThread isMainThread]) {
accept = [[Controller sharedController] shouldIAccept:certInfo];
}
else {
dispatch_sync(dispatch_get_main_queue(), ^{
accept = [[Controller sharedController]
shouldIAccept:certInfo];
// This is where UI starts playing up when the
controller shows the cert
});
}
return accept;
So the shouldIAccept method needs to block hence runModal. I also just threw
the window up and created my own modal loop but same problem.
It seems to me you’re *still* abusing the main thread. A dispatch_sync blocks
the main thread, so it can’t be allowed to do anything that run asynchronously
on the main thread (such as displaying a dialog) since that won’t complete.
I suggest you approach this by denying yourself the use of dispatch_sync. I
don’t know if Jens will have a better approach, but I’d be inclined to do it
with a semaphore (dispatch_semaphore_t) protecting the ‘accept’ variable, and a
dispatch_async to the main queue to ask the user what to do. GCD semaphores are
incredibly easy to use.
___
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: dispatch_sync(dispatch_get_main_queue() UI weirdness
Difficult to know exactly what's happening in your situation, but I’d be
inclined to try something like:
dispatch_time_t duration = dispatch_walltime(DISPATCH_TIME_NOW,
offset_nsec);
dispatch_after(duration, dispatch_get_main_queue(), ^{
});
where offset_nsec is long enough to allow the app to complete it’s start-up
process
Sandy
On Sep 5, 2014, at 10:31 PM, Jonathan Guy jonathan...@mac.com wrote:
I’m using a third party c library that requires registering a callback which
gets called if the operation encounters an invalid server certificate (should
i accept or reject the cert). The callback needs to return yes or no, which I
need to get via a UI prompt so the prompt needs to block so I can return
appropriately from the callback. So my initial thoughts are “present the cert
in a modal window”. So I put the cert in a SFCertificateView in a scroll view
and present it in a modal window but it could not be scrolled up and down
which was the initial problem. I also tried the SFCertificatePanel with the
same problem. After testing I found I couldn’t scroll any scroll view so I
knocked up that small bit of code to show as an example. I tried using
performSelectorOnMainThread and waiting until completion and this funnily
enough works fine in terms of absolutely no UI weirdness but I can’t get a
return value from that plus there were other issues.
There could be any number of operations running concurrently and any one
could require validation at any time.
The callback is basically structured like this
__block BOOL accept;
if ([NSThread isMainThread]) {
accept = [[Controller sharedController] shouldIAccept:certInfo];
}
else {
dispatch_sync(dispatch_get_main_queue(), ^{
accept = [[Controller sharedController]
shouldIAccept:certInfo];
// This is where UI starts playing up when the
controller shows the cert
});
}
return accept;
So the shouldIAccept method needs to block hence runModal. I also just threw
the window up and created my own modal loop but same problem.
On 5 Sep 2014, at 19:59, Jens Alfke j...@mooseyard.com wrote:
On Sep 5, 2014, at 11:44 AM, Jonathan Guy jonathan...@mac.com wrote:
when the NSOpenPanel opens all kinds of weirdness is going on. The scroll
views scroll very erratically if at all and the directories don't list
properly.
Well, you've blocked one of the threads that services the global dispatch
queue — it's stuck in a dispatch_sync call that won't return until the user
dismisses the open panel. I don't know exactly what kinds of problems
blocking the queue will cause, but it's definitely not a good idea. (The
problems you report sound more severe than what I would guess would happen,
but I definitely don't know how concurrent dispatch queues are implemented.)
You should rewrite your code to use dispatch_async instead. Then when the
modal session completes, call back to the global dispatch queue to finish
running your code.
(And the whole scenario you're giving sounds like bad UI design — your code
shouldn't suddenly pop up a modal panel just because you need a file from
the user. The user should be in control of tasks like opening files. But
you may have created an unrealistic scenario just as an example…)
—Jens
___
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/mcguffogl%40gmail.com
This email sent to mcguff...@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: dispatch_sync(dispatch_get_main_queue() UI weirdness
On Sep 5, 2014, at 1:48 PM, Quincey Morris quinceymor...@rivergatesoftware.com wrote: It seems to me you’re *still* abusing the main thread. A dispatch_sync blocks the main thread, so it can’t be allowed to do anything that run asynchronously on the main thread (such as displaying a dialog) since that won’t complete. Why not? I assume Jonathan's -shouldIAccept: is running a nested event loop for the modal panel, since it doesn't return till the user dismisses it. (Whether it's a dispatch_sync or a dispatch_async doesn't matter; the main thread will be blocked for as long as the block takes to run.) I still think the problem is that you're blocking the dispatch-queue's thread for a long time. Try pausing the app while the dialog is up and looking at what the various threads are doing. —Jens ___ 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: Modal sheet, full screen swipe instability
Dear All, I have issues with a fullscreen app. Wh a sheet is open (beginSheet:modalForWindow:modalDelegate:didEndSelector:contextInfo:), and I swipe to Desktop and then swipe back to the app, the screen remains for 2 seconds on the app and then swipes again back to Desktop without my interaction. Then, if I swipe back to the app a second time, it correctly remains there. Also, if after swiping back I immediately select a field in the sheet, I don’t get the problem anymore. Is it a focus-related problem ? Is it possible to detect when the screen is swiped-back to my application, so that I can give focus to a control ? Thanks for your help. ___ 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: Checking security settings?
Heh… fortunately I’m *very* early in the design of this, so yeah… nothing is set in stone yet. :-) On Sep 5, 2014, at 11:20 AM, SevenBits sevenbitst...@gmail.com wrote: On Friday, September 5, 2014, Quincey Morris quinceymor...@rivergatesoftware.com wrote: On Sep 5, 2014, at 10:15 , Britt Durbrow bdurb...@rattlesnakehillsoftworks.com javascript:; wrote: If I can’t find an officially supported way to do this, then yeah - that’s what I figure I’ll have to do. I was trying to avoid it due to user experience issues; requiring a second login, etc is cumbersome every time somebody wants to record something in the app… sigh Oh well... It was never a workable idea, though. It’d be just as bad for a user to set a password of ‘123456’ as having no password, for example, and there’d never be an API that *told* you what the password was so you could check if it was good enough. Similarly, you’d never have a way of checking that the current screensaver actually *obscured* the screen contents. That's very true - my current screensaver for example applies visual effects to my screen - it distorts, but does not obscure, my screen contents. Under HIPAA your idea was never workable due to practical limitations. Perhaps… most of the time there’s no data displayed onscreen; but there is an NSStatusItem that I need to keep “unauthorized” persons from interacting with… Also, there are distributed notifications that I can trap to lock any data display windows that do happen to be up when the screen locks. IANAL, but my understanding was that the quality of a user’s password was not a HIPAA requirement, just that there needed to be some method of user authentication (not that accepting ‘123456’, ‘monkey’, etc. is a good idea; just that it’s not **legally** required). Given the rumors floating around about next week’s grand revelation event, you might also want to hold off making any decisions until you see what Apple will have to offer. With Health Kit, Home Kit, wearables and payments being bruited, there might turn out to be something secure that would ease the second-login problem. Second. I doubt that there will be any new APIs announced at that event… but even so, um, yeah… :-) I wonder if we’ll ever get TouchID on the desktop? ___ 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: dispatch_sync(dispatch_get_main_queue() UI weirdness
My take on this is that you shouldn’t be blocking an AppKit callback
(applicationDidFinishLaunching:). I can’t say definitively if this particular
callback is problematic. But I’ve had problems like this in past where the
delegate is called on the main thread and the delegate doing a blocking call on
the main queue will block much of AppKit. I’ve basically come to the conclusion
that you shouldn’t do it.
One technique I use to handle this is to wrap the dispatch_sync with a
dispatch_async, such as:
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0),
^{
dispatch_sync(dispatch_get_main_queue(),
^{
// Do your NSOpenPanel or other UI
});
});
This way, you can still execute your UI code synchronously on the main queue
but you don’t block AppKit in your callback.
Good luck!
Doug Hill
On Sep 5, 2014, at 1:49 PM, Sandy McGuffog mcguff...@gmail.com wrote:
Difficult to know exactly what's happening in your situation, but I’d be
inclined to try something like:
dispatch_time_t duration =
dispatch_walltime(DISPATCH_TIME_NOW, offset_nsec);
dispatch_after(duration, dispatch_get_main_queue(), ^{
});
where offset_nsec is long enough to allow the app to complete it’s start-up
process
Sandy
On Sep 5, 2014, at 10:31 PM, Jonathan Guy jonathan...@mac.com wrote:
I’m using a third party c library that requires registering a callback which
gets called if the operation encounters an invalid server certificate
(should i accept or reject the cert). The callback needs to return yes or
no, which I need to get via a UI prompt so the prompt needs to block so I
can return appropriately from the callback. So my initial thoughts are
“present the cert in a modal window”. So I put the cert in a
SFCertificateView in a scroll view and present it in a modal window but it
could not be scrolled up and down which was the initial problem. I also
tried the SFCertificatePanel with the same problem. After testing I found I
couldn’t scroll any scroll view so I knocked up that small bit of code to
show as an example. I tried using performSelectorOnMainThread and waiting
until completion and this funnily enough works fine in terms of absolutely
no UI weirdness but I can’t get a return value from that plus there were
other issues.
There could be any number of operations running concurrently and any one
could require validation at any time.
The callback is basically structured like this
__block BOOL accept;
if ([NSThread isMainThread]) {
accept = [[Controller sharedController] shouldIAccept:certInfo];
}
else {
dispatch_sync(dispatch_get_main_queue(), ^{
accept = [[Controller sharedController]
shouldIAccept:certInfo];
// This is where UI starts playing up when the
controller shows the cert
});
}
return accept;
So the shouldIAccept method needs to block hence runModal. I also just threw
the window up and created my own modal loop but same problem.
On 5 Sep 2014, at 19:59, Jens Alfke j...@mooseyard.com wrote:
On Sep 5, 2014, at 11:44 AM, Jonathan Guy jonathan...@mac.com wrote:
when the NSOpenPanel opens all kinds of weirdness is going on. The scroll
views scroll very erratically if at all and the directories don't list
properly.
Well, you've blocked one of the threads that services the global dispatch
queue — it's stuck in a dispatch_sync call that won't return until the user
dismisses the open panel. I don't know exactly what kinds of problems
blocking the queue will cause, but it's definitely not a good idea. (The
problems you report sound more severe than what I would guess would happen,
but I definitely don't know how concurrent dispatch queues are implemented.)
You should rewrite your code to use dispatch_async instead. Then when the
modal session completes, call back to the global dispatch queue to finish
running your code.
(And the whole scenario you're giving sounds like bad UI design — your code
shouldn't suddenly pop up a modal panel just because you need a file from
the user. The user should be in control of tasks like opening files. But
you may have created an unrealistic scenario just as an example…)
—Jens
___
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: dispatch_sync(dispatch_get_main_queue() UI weirdness
Why not? I assume Jonathan's -shouldIAccept: is running a nested event loop
for the modal panel, since it doesn't return till the user dismisses it.
(Whether it's a dispatch_sync or a dispatch_async doesn't matter; the main
thread will be blocked for as long as the block takes to run.)
I still think the problem is that you're blocking the dispatch-queue's thread
for a long time. Try pausing the app while the dialog is up and looking at
what the various threads are doing.
—Jens
___
Don’t think it’s the dispatch thread, they are quite capable of being out of
action for ages.
It is however quite easy to show this happening. Stick the code at the bottom
in the AppDelegate of a fresh OSX Cocoa app from the template, drag out 3
buttons and hook them up to pushOne . . etc.
Hit button one and it just pops up the open panel from the button click - works
fine
Hit button two and it dispatches sync onto the main thread and does the same
thing, it’s terrible, scrolling doesn’t work properly .. mess
Hit button three and it does a perform selector on the main thread with the
same code and waits for it and that .. works properly
The stack traces are very similar, after the runModal they’re the same, as
you’d expect. So the only difference between the the cases is that if you
performSelector the original main runloop is in
.._IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION .. and from there it runs the
model dialog.
In the case of dispatching onto the main dispatch queue the runloop was
.._SERVICING_THE_MAIN_DISPATCH_QUEUE.. when it goes into the runModal code.
I can only think that ‘state’ of the main runloop when runModal is called makes
a difference and being in the ‘haven’t finished dispatching main dispatch
events’ state causes it to have trouble servicing the runModal runloop. Not
that it’s doing anything, the whole machine is idle, but they are likely two
quite different states/stages of the runloop cycle.
Rarely do I suggest performSelector: but it happens to work here. I’d love to
know more about why dispatch doesn’t work so well however.
#import AppDelegate.h
@interface AppDelegate ()
-(IBAction)pushOne:(id)sender;
-(IBAction)pushTwo:(id)sender;
-(IBAction)pushThree:(id)sender;
@end
static BOOL flag1 = NO;
static BOOL flag2 = NO;
@implementation AppDelegate
-(void)doNothing
{
int count = 0;
while( count 100 )
{
[ NSThread sleepForTimeInterval:1 ];
NSLog( @%d, count );
count++;
if( flag1 )
{
flag1 = NO;
dispatch_sync( dispatch_get_main_queue(), ^{
[ self doTheOpenPanelThing ];
} );
}
if( flag2 )
{
flag2 = NO;
[ self performSelectorOnMainThread:@selector(
doTheOpenPanelThing ) withObject:nil waitUntilDone:YES ];
}
}
}
-(void)doTheOpenPanelThing
{
NSOpenPanel *panel = [ NSOpenPanel openPanel ];
[ panel runModal ];
}
-(void)pushOne:(id)sender
{
NSLog( @One Pushed );
[ self doTheOpenPanelThing ];
}
-(void)pushTwo:(id)sender
{
NSLog( @Two Pushed );
flag1 = YES;
}
-(void)pushThree:(id)sender
{
NSLog( @Three Pushed );
flag2 = YES;
}
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
// Insert code here to initialize your application
dispatch_async( dispatch_get_global_queue(
DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
[ self doNothing ];
} );
}
- (void)applicationWillTerminate:(NSNotification *)aNotification {
// Insert code here to tear down your application
}
@end
___
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
Generating Core Data classes in Swift
Say my app is called MyGreatApp, and I have a Core Data entity named Entity. Per instructions, I namespace the class associated with the entity and call it MyGreatApp.Entity. When I use Create NSManagedObject Subclasses and tell it to generate Swift files, I get a class called MyGreatApp that contains the attributes from Entity. Is this known broken? Workaround other than hand-tweaking the class? I have the current Xcode beta. Thanks! ___ 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: Generating Core Data classes in Swift
On 2014 Sep 05, at 20:22, Jim Geist velocity...@rodentia.net wrote: Workaround other than hand-tweaking the class? You could use mogenerator instead of Xcode to generate your Core Data classes. Although I’ve not tried it yet, supposedly mogenerator now has a —-swift option. https://github.com/rentzsch/mogenerator The latest pre-built binary download, mogenerator 1.27, does not support Swift. You will therefore need to clone and build mogenerator from source. But I just did that the other day and it worked perfectly. In case you’re not familiar with mogenerator, here is a good sales pitch… https://github.com/rentzsch/mogenerator ___ 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: Generating Core Data classes in Swift
Correct link to mogenerator good sales pitch… http://raptureinvenice.com/getting-started-with-mogenerator/ ___ 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: dispatch_sync(dispatch_get_main_queue() UI weirdness
On Sep 5, 2014, at 1:44 PM, Jonathan Guy jonathan...@mac.com wrote:
This is for MacOS not iOS.
If your running code on a GCD queue
dispatch_sync(dispatch_get_main_queue(), ^{
//do UI stuff
});
is pretty much the way to do UI stuff on the main thread/queue which seems to
work well for iOS. MacOS seems to be a different story. Try this for a simple
example
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification
{
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT,
0), ^{
// So my app is doing some background stuff
// and I need a file from the user so
// code blah blah code
dispatch_sync(dispatch_get_main_queue(), ^{
NSOpenPanel *op = [NSOpenPanel openPanel];
[op runModal];
});
// resume code blah blah code
});
}
when the NSOpenPanel opens all kinds of weirdness is going on. The scroll
views scroll very erratically if at all and the directories don't list
properly. I'm just using the NSOpenPanel here as an example, this also
happens with any view that contains a scroll view (so I've tested so far). Is
this a bug? Are others seeing this or is it just me and is there another
preferred way of doing this?
This is an issue I have encountered before. NSOpenPanel does certain
operations, like loading the icons for files, asynchronously in the background.
Then, when those background operations are completed, it updates the dialog by
submitting tasks to the main dispatch queue. However, the main dispatch queue
is a serial queue. It is currently monopolized by your block which has called
into -runModal. It won't execute any more tasks until that block completes.
So, the panel's asynchronous background work can't complete.
It doesn't matter whether your block was submitted to the main queue with
dispatch_sync() or dispatch_async(). I agree with others that, in general, you
should structure your code to submit blocks asynchronously whenever possible
(regardless of which queue you're submitting them to). Similarly, you should
avoid blocking whenever possible, preferring asynchronous, callback-based APIs.
However, none of that affects this issue.
It's simply the case that NSOpenPanel can't be run, directly or indirectly,
from a block submitted to the main dispatch queue.
You can use -performSelectorOnMainThread:… just fine. That is not a serialized
mechanism. If the run loop is in the middle of performing a selector and is
re-entered (as for the modal event loop run for a modal dialog), it can still
run other submitted dispatch tasks and performed selectors.
Because of this, I consider it a bug that NSOpenPanel uses GCD rather than
-performSelectorOnMainThread:… or a similar non-serial mechanism for getting
its updates back to the main thread. And everybody else using GCD should
carefully consider this issue in their own designs. (Note that it also doesn't
matter whether NSOpenPanel has submitted its updates from the background to the
main thread synchronously or asynchronously. If it submits it asynchronously,
the background thread can continue, but it will just have an opportunity to
queue more things on the main queue that will never get run. If it submits
synchronously, it will block, but that's just as well.)
Frankly, Apple should add a new dispatch queue that is serviced by the main
thread but which is technically not a serial queue. It won't be quite a fully
concurrent queue, since it would only be serviced by one thread, but it would
allow blocks to be serviced in a nested fashion if one of those blocks runs the
run loop. Basically, it would work just like -performSelectorOnMainThread:…
does.
Regards,
Ken
___
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
