|
GLSL in exported Cocoawell this is another post where I ask for advice about exporting quartz in cocoa, I had an issue with the way my application runs, the screen would be running on in interface builder's preview but after building the app would go black and not respond. Now, after a day of taking stuff in and out of quartz I know it is because of GLSL shader and grid. I tried to add the Open GL framework in xcode project but didn't help. Any ideas what framework I'm missing or is it not a framework missing? I attach the preview and the built app screens After all the helpfull tips I received from Kineme folk, I am thinking of making a small retention center of Quartz to Cocoa advice when I finish my exams.
|
Same problem here on 10.6.1 Building an qtz-based app where the qtz contains a glsl shader will nuke the app. (when using a QCPatchController in the NIB, which contains the qtz)
I also tried to use it in QCView upload only, no luck
Does the problem happen on 10.6.0, 10.6.2, or 10.6.3? 10.5.x?
Does anything get printed to the logs?
Can you provide a small sample app that fails? (or file a bug report at http://bugreporter.apple.com)
I'll send a full app soon, it happens on snow leopard.
Here is a test app for your consideration: based on Xcode template QC application, put the apple GLSL example Vertex Noise in a QC patch controller, linked to QC view. Run OK in QC, OK in IBcocoaSimulator, but not when compiled.
I'm on 10.6.1 / Xcode 3.2
And the logs say: 2010-06-11 17:02:08.661 GLSL_bug[43415:a0f] Error loading /Library/ScriptingAdditions/Adobe Unit Types.osax/Contents/MacOS/Adobe Unit Types: dlopen(/Library/ScriptingAdditions/Adobe Unit Types.osax/Contents/MacOS/Adobe Unit Types, 262): no suitable image found. Did find: /Library/ScriptingAdditions/Adobe Unit Types.osax/Contents/MacOS/Adobe Unit Types: no matching architecture in universal wrapper GLSL_bug: OpenScripting.framework - scripting addition "/Library/ScriptingAdditions/Adobe Unit Types.osax" declares no loadable handlers.
WTF does this have to do with Adobe ?
looks like this is an interface builder bug. When compiling, I get the following on the console:
Because of that, I'm guessing that IB is generating an incomplete NIB, so QC doesn't load anything (because the composition isn't there). If you load the NIB manually, it should work.
Please file a bug using this example -- be sure to remove the build directory first.
Nothing. that error happens because Adobe decided to not make a 64bit build of their Unit Types plugin. anything that loads it while running in 64bit mode will emit that message (I'm guessing some plugin or extension indirectly tries to load that)
http://forums.adobe.com/thread/486208
looks like an OSAScript plugin might cause that to happen.
and some adobe forum perusing turns up this: http://kb2.adobe.com/cps/516/cpsid_51615.html -- should make that go away (an updated build from adobe)
Did you ever file a bug for this? If not, please do so, and post the bug ID number so I can make sure it gets added to our pool.
Bug ID# 8143836
awesome, thanks :)
i truly hope this one will get fixed anytime soon, as it is pretty handicapping my workflow. What's the workaround you were mentionning ? How do i manually make a NIB ?
As a sidenote, i encounter lots of bugs these days with GLSL patch.
I can't say what the estimates are for a fix, unfortunately (this one's actually really complex, so I'm still researching the root cause).
There isn't a known workaround -- the thing I posted on the mailing list was to unset a private preference that the user likely set in Leopard (when it worked), and carried forward to Snow Leopard (where it doesn't). That's an unrelated issue that I was aware of before I came here :)
You can't manually create a nib, as far as I know -- however, it may be possible to create your nib normally, but with a "stub" composition (one that doesn't have any GLSL patches inside) -- then, using Property List Editor, you can find where the nib stores the serialized composition, remove it, and add in the intended composition. This may involve doing some NSArchiver tricks though...
When you encounter bugs, please file radars on them -- inside Apple, the only thing that gets work done is radars. Notes on forums, or on the mailinglist, are unfortunately forgotten. (Yes, apple engineers constantly beg for radars; yes, apple engineers constantly don't provide meaningful feedback on their timelines. I know that's annoying on both fronts :/)