<html>
<head>
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">The behavior that you describe seems
similar to that described in:<br>
<br>
<a class="moz-txt-link-rfc2396E" href="http://stackoverflow.com/questions/10508522/nsopenpanel-doesnt-show-when-i-call-runmodal"><http://stackoverflow.com/questions/10508522/nsopenpanel-doesnt-show-when-i-call-runmodal></a><br>
<br>
where the problem apparently had to do with (lack of proper)
"entitlements". (The owner of the<br>
appliance - quaintly referred to as the "user" in some documents -
might try to access the filesystem<br>
on their "computer" otherwise.)<br>
<br>
I have no idea why this would work on some systems that support
sandboxing and not on others,<br>
but I confess that I had some difficulty parsing your message.
(There's more reason to think that<br>
this is a Lion problem than that it's a Mountain Lion problem, but
I don't know how anyone would<br>
know for sure.)<br>
<br>
There's no reason to think that this is not a CCL problem.
There's no reason to think that it is a<br>
CCL problem, either. If a sandboxed ObjC program with exactly the
same entitlements behaved<br>
differently, then there'd at least be some reason to wonder why
Cocoa methods called from CCL behave<br>
differently than they do when called by that ObjC program. My
model of things is that those Cocoa methods<br>
don't know or care what programming language their callers were
compiled in, and I don't know of any <br>
reason to think of that model as being incorrect.<br>
<br>
Googling for "sandbox NSOpenPanel" indicates that many people have
found that these things don't<br>
interact as people expect them to and as the documentation
suggests that they should, and that this<br>
is often due to bugs in the underlying technology. Some messages
that one can easily find via that<br>
Google search suggest that the forums on Apple's developer site
offer a better explanation of what works<br>
and what doesn't than one can easily find elsewhere.<br>
<br>
<br>
On 5/2/13 3:32 PM, Michael Minerva wrote:<br>
</div>
<blockquote cite="mid:44E154B1-327C-45C9-8529-EFC5AD11E6F8@agentsheets.com" type="cite">
<div>We are experiencing another strange issue, this time it is
related to Lion and Sandboxing. We initially noticed the issue
when we tried to test a sandboxed version of our app on Lion.
Every time we would try and launch an NSOpenPanel, it would
stall for about 10 seconds, nothing would come up and then the
program would resume. The call to runModal returns without ever
bringing up the window and there is no error in the console. In
order to try and dissect this problem a little further, we
downloaded a fresh copy of the release version of CCL and
sandboxed both the 32bit and 64bit versions of CCL, when we
fired up these apps on Lion and simply tried to open a file
(command O or open… from the File menu) the same behavior we saw
in our app occurs in the sandboxed CCL I.E. the File menu is
highlighted and stalled for 10 seconds, no file chooser comes up
and then it returns without ever showing the chooser. We have
also tried this same experiment with the most recent trunk of
CCL and it exhibits the same behavior. </div>
<div><br>
</div>
<div>A few Notes:</div>
<div>• This occurs only on Mountain Lion we have tested versions
10.7.2 and 10.7.5 and it occurs on both</div>
<div>• We have tested on Mountain Lion and Snow Leopard and this
problem does not occur (even with the sandboxed versions)</div>
<div>• We have tried sandboxing with a valid certificate like
this: codesign -s "Developer ID Application: AgentSheets, Inc."
-f --entitlements /Users/Mike/Desktop/AgentCubes\
1.02-Lite/AgentCubes32bit.app/Contents/AgentCubes.entitlements
/Users/Mike/ccldev15801/Clozure\ CL32.app </div>
<div>• We have also tried sandboxing with no certificate like:
codesign -s - -f --entitlements
/Users/Mike/Desktop/AgentCubes\
1.02-Lite/AgentCubes32bit.app/Contents/AgentCubes.entitlements
/Users/Mike/ccldev15801/Clozure\ CL64.app </div>
<div>• Both the code signed and non code signed sandboxed apps
exhibit the issue</div>
<div>• We have examined the code signed app with spctl to verify
that it is code signed with a valid certificate </div>
<div><br>
</div>
<div>Here is a link to a sandboxed version of CCL 1.9 release:</div>
<div><br>
</div>
<div><a moz-do-not-send="true" href="http://www.cs.colorado.edu/%7Eralex/temp/SandboxedCCL1.9-Release.zip">SandboxedCCL1.9-Release.zip</a></div>
<div><br>
</div>
<div>When we open this version in Lion and goto File-> Open it
exhibits the issue (no file chooser comes up and the File menu
stalls blue for ~10 seconds). Could anyone else running Lion
verify that they see the same issue? Anyone have any clues
about what could be going on here? </div>
<div><br>
</div>
<div>--Mike</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Openmcl-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openmcl-devel@clozure.com">Openmcl-devel@clozure.com</a>
<a class="moz-txt-link-freetext" href="http://clozure.com/mailman/listinfo/openmcl-devel">http://clozure.com/mailman/listinfo/openmcl-devel</a>
</pre>
</blockquote>
<br>
</body>
</html>