On Apr 20, 2012, at 11:34 AM, vade wrote:

> If you really need to not load things, move all the QC plugins folders.
> 
> Its horrible. Its a hack, its not suggested, but since the QC Framework looks 
> for plugins there , edit your main.m and move the folders before 
> NSAPplicationMain bootstraps the framework. If its not there, it wont see, 
> and can't load it into your app.
> 
> Then manually load from the location what you require and know works. 
> 
> On ApplicationDidFinishLaunching, move it backs so know one knows what 
> happened.
> 
> I feel dirty for even suggesting that.


Ha, I've written so much stuff to list in the last couple days, I feel like I'm 
spamming/having one sided conversations on some stuff :-) "George is writing to 
himself again guys!".

Anyway, this looks like it's a reply to the other thread I have going about 
patch/plugin loading :-)

I got that worked out last night. I'd got myself going down a bit of a wrong 
track; my app was crashing when I was loading some QCPatches, and I thought it 
was because of duplicates, licenses QCPatches, or the method I was using. When 
I'd get rid of a QCPatch in one of the locations (the resource bundle) or my 
install, the app would stop crashing, but that was misleading - 

It turned out, it was because I'd been loading a version of DataTools where I'd 
uncommented an input splitter function that was questionable (and to kineme's 
credit, they had commented out and not included in release.)


Once I figured that out, loading QCPlugins/QCPatches from my resource bundle is 
working ok.

If I want to block QCPatches/Plugins from loading, I'll probably replace the 
implementations instead of messing with the folders, though that's definitely 
an idea to move the folders. Wow ;-)

My main motivation to block particular QCPatches from loading was from the 
crashing I was getting. If for some reason my app loads a different version 
from a user's install, besides the one in the internal bundle, as long as it 
doesn't crash, I'm pretty "ok" with it. 

It seems like whatever the mechanism is that controls loading tends to load 
newer versions if there are multiples... which is probably ok for this project 
as long as there isn't any class name reuse going on with newer 
plugins/patches, that present different arrangements of ports.

-gt


> 
> On Apr 19, 2012, at 6:44 PM, George Toledo wrote:
> 
>> 
>> On Apr 19, 2012, at 6:09 PM, Christopher Wright wrote:
>> 
>>>>> Or you can see if CGLCreateContext gives you a NULL context (meaning it 
>>>>> failed).  Check for non-zero error codes returned from 
>>>>> CGLChoosePixelFormat and CGLCreateContext.
>>>> 
>>>> 
>>>> Sure, that's what I'm trying now. I setup my MSAA pixel format init with 
>>>> those attributes, and then check with a "if(      _glContext == nil)". 
>>>> 
>>>> Except that doesn't work, and at least one sample project that I see that 
>>>> has done this, also doesn't (QCAdvancedPlayer), on an Intel X3100 gpu, 
>>>> that's running SL. Maybe it works on some other machines/gpu's, but on 
>>>> that one, it's a big fail.
>>>> 
>>>> Come to think of it, I think that project always failed on that machine, 
>>>> even when I was running Leopard. If one creates an app with the 
>>>> QuartzBuilder product, for instance, and enables MSAA, running it will 
>>>> fail on the machine I'm speaking about.
>>> 
>>> That's weird.  I wrote early versions of QuartzBuilder on a GMA950 machine, 
>>> so the MSAA fallback path had to work for at least that machine.  I might 
>>> have done it incorrectly though.  I was using CGLContexts directly, not 
>>> NSOpenGLContexts, maybe that's relevant?
>> 
>> Maybe so. I'm not sure.
>> 
>>> 
>>>> Generally, is Apple currently making any units that don't support MSAA? I 
>>>> know there's that GPU capabilities chart
>>> 
>>> But you opted to not check it? ;)
>> 
>> Uh, going to write that up to mental fatigue. :-) I could say that I can 
>> never find the darn link, but it's probably a google away :-) I totally 
>> should have looked at that first.
>> 
>>> According to 
>>> https://developer.apple.com/graphicsimaging/opengl/capabilities/, 
>>> ARB_multisample is present on everything but GMA950 and X3100.  All 
>>> shipping Intel GPUs are HD Graphics 3000s now, and those do support 
>>> ARB_multisample.
>> 
>> Yeah, that pretty much spells the end of me worrying about that too much 
>> (but I'll probably fiddle with it when I'm not dealing with things that are 
>> more important on this particular project). 
>> 
>> It's always handy to have a totally different machine to a/b builds on; too 
>> bad my A/B machine is getting old (or fortunate, I guess, to know what won't 
>> work on an older machine) . 
>> 
>> Between issues with the MSAA and not necessarily being able to detect what 
>> QCPatches are on a system/block them from loading from the user's install if 
>> they're in my bundle, issues with deprecated plugins that have been subsumed 
>> by other plugins (like Structure Tools being subsumed by DataTools) and not 
>> knowing how to get the app not to load outdated QCPatches, I was running 
>> into a bunch of fun late last night when giving the app project I'm working 
>> on a run on the old white macbook :-) Lots of opportunities to have an app 
>> crash on start on a different system than the one that one is coding on.
>> 
>> Uh, feeling like it's easier to handle all of that with a READ ME :-) I'd 
>> still love to figure out how to block a QCPatch from loading if it's already 
>> in my Resources (but still load other QCPatches). (Sorry, getting OT.)
>> 
>> 
>> -gt
>> 
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Quartzcomposer-dev mailing list      (Quartzcomposer-dev@lists.apple.com)
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/quartzcomposer-dev/doktorp%40mac.com
>> 
>> This email sent to dokt...@mac.com
> 
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Quartzcomposer-dev mailing list      (Quartzcomposer-dev@lists.apple.com)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/quartzcomposer-dev/gtoledo3%40gmail.com
> 
> This email sent to gtole...@gmail.com

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Quartzcomposer-dev mailing list      (Quartzcomposer-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to