Indeed, there are totally times when the custom view apparatus is necessary, and that some combinations of settings may be mutually exclusive, so having the custom view makes total sense. I just try to avoid it as much as possible to keep things as inter-operable as possible. My point to Milton was that his possible catch-22 could be avoided by forgo-ing the Settings view completely and providing input ports for the settings he exposed there, should that be a reasonable approach and not cause confusion or a loss of functionality. Additionally, for preview output, just supply a secondary QCPluginOutputImageProvider output port. This would let app developers provide custom preview controls using his plugin for the DFG or what not device.
Personally, the reason I use Quartz now and not other tools like Max/ MSP/Jitter is mostly for the Quartz Composer Application interface. Its amazingly powerful. The settings UI is one of those weird things that sits on the sideline and can make some options odd.
This has been discussed into the ground over the past few years (perhaps mostly off-list/on kineme forums? I don't recall), and I think you skipped over one crucial detail.
First off, I mostly agree that the settings panel is horrifyingly bad, and quite annoying (especially when it's seemingly nonsensical, like the antialias input on the sprite, or the various font settings on the image with string patch, or stacks/slices on the quadratics). HOWEVER: there are times where it's quite elegant and solves a legitimate problem:
That time is when the data entered there can/will modify ports on the patch.
Let that sink in for a few seconds.Let's take the multiplexer as an example: its settings panel lets you Add or Remove inputs (and change their type, which is the same as adding/removing ports). If that value (the number of inputs/outputs) were exposed to the QC graph, a composition could disconnect all its noodles, and outside of QC nothing could be done to fix it. That's pretty lame, and absolutely useless. There's no reason to want to dynamically change the number of ports on a multiplexer on the fly (since noodles cannot be added or removed outside of the editor) -- none. There are exactly zero useful things gained by making the port count/type modifiable by the composition itself (because it would immediately knock the patch off the graph).
Javascript's source code input could be a large string port (ick, possible, but ick.). However, that can change ports dynamically as well. Ditto for GLSL, CoreImage filters, CL stuff, and a handful of other patches.
Under those circumstances, I disagree that Settings panels should be abolished. However, I think their use should be fiercely criticized until they make sense (removing stacks/slices from quadratics, removing all non-port-affecting options, etc).
-- [ christopher wright ] [email protected] http://kineme.net/
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Do not post admin requests to the list. They will be ignored. Quartzcomposer-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com This email sent to [email protected]
