Slight note about: "but doing weird things to the rest of QC's runtime. Of course, its the plugins fault, but native api plugins could not do that,"
If a plugin doesn't disable stuff correctly, or manage context correctly, or does other stuff that I'm not aware of why the heck it does what it does :-) .... using the standard API, it can definitely do really funky stuff to QC that cause it not to be able to recover. That can happen from 1024's metaball, your glitch plugins, Mirek's Obj-C and Movie Exporters, among others. On Sun, Oct 30, 2011 at 11:39 AM, George Toledo <gtole...@gmail.com> wrote: > > > On Sun, Oct 30, 2011 at 11:16 AM, vade <dokt...@mac.com> wrote: > >> You are totally correct. >> >> I should have said its more the lack of documentation/examples/support/, >> which means you can do things you did not mean to do, and get into all >> kinds of additional trouble. Great power, responsibility, yadda yadda. But >> yes, you are 100% correct in that point. I guess what I am saying is I've >> seen some very strange behaviour that is attributed only to 3rd party skank >> SDK plugins, not *just* crashing, but doing weird things to the rest of >> QC's runtime. Of course, its the plugins fault, but native api plugins >> could not do that (the rendering to alpha issue with some Kineme plugins, >> etc). But yes, technically, it is the plugins fault, not the runtime as you >> said. I should have been more clear with what I meant. >> > > Yeah, that's exactly what I meant when I said "take dangerous liberties > with ports, etc." :-). Over-riding default port function, and/or adding > port types is problematic for several reasons, and will never be "quite > right" . This is arguable I guess, but I don't want to get into an argument > :-) My reasoning is, that I think that if one wants "alpha blend" one > should just code patches to have it, not try to shim the stock blend port, > that can change at any time and then break. Then, when making custom port > types, there's not going to be an insert splitter available for that type, > which will always result in problems. IMO, one should probably just use > Virtual port type instead, but I guess that presents another set of > problems (but at least it doesn't push a non existent patch type to the > editor). > > >> >> On Oct 30, 2011, at 1:34 AM, Jaymie Strecker wrote: >> >> I am tempted to take you to task about the 3rd party plugin API not being >>> 'stable' ? I've never seen a crash caused by the runtime... And have seen >>> plenty caused by skank SDk plugins ;) >>> >> >> I'm not sure exactly what you mean by "crash caused by the runtime". I >> could refer you to some standard API plugins that will crash QC, or just do >> horrible things to GL state. The same goes for someone using the skankySDK >> - they could code something that just isn't right. I don't think one is >> inherently less stable than the other, over the course of the past years. >> >> >> SkankySDK doesn't *do* anything. It's just headers. Just the private API >> from Apple (given a sexist nickname by an Apple employee). >> >> If a plugin crashes then that's fault of the plugin (or the QC >> framework), not the SkankySDK. >> >> >> >> _______________________________________________ >> 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: >> >> http://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: http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
