On Thu, 2 Dec 2010, Hans-Christoph Steiner wrote:
I think your interface questions will be much easier if you don't try to do everything in [pix_video]. I think [pix_video] is great as it is, its simple and straightforward, and most of the time people will just need to get video in without thinking about parameters. Adding all this stuff to [pix_video] will destroy that simplicity.
I think it can be fine to destroy some simplicities, as long as it doesn't make it harder for the user. In the end, making things easier for the user is a good reason to increase complexity. However, there are ways to achieve it that are better than some others.
Instead make a new über-pix_video object which has all of this option handling. Or even multiple objects if there are logical groupings, like if one interface or camera API always exposes the same parameters, make a custom object for that camera API and the object arguments can also be a way to set the parameters.
The way I made it in [#in], there's a single class that handles "open" and "close", with dynamic patching to instantiate a handler of image, movie, camera, live screenshots, or generic data files. Some of them have things in common. For example, «bang» is known to all of them as meaning «fetch me a frame», whereas «size» is known to all camera handlers, «seek» is known to all movie handlers (though it's missing from one help file), ...
(similar things happen with [#out]).
a class can be a rather complex arrangement of methods and it's normal that it's like that. It's good to break things into smaller components but it doesn't seem like the parameters are the right place to do this. Instead I made one component per API and arranged them so that they have as many methods (and conventions) in common as it makes sense to have ; and then I made a general frontend for inputs ([#in]) and a visual frontend for cameras ([#camera]) which detects which parameters exist in a certain object and colours gui objects accordingly :
http://gridflow.ca/gallery/%23camera-2010.png
(here you can see that channel/tuner/norm/frequency are greyed-out because they don't exist at all, and then you can see minsize and maxsize are black-on-grey because they are readonly).
(maybe I didn't understand what you mean)
Or you could follow gemwin-style, and have all of the parameters settable when the render is off, then they'll only take effect once render/create is set.
I always thought that this gemwin way of doing things is terrible. I don't think that any other classes should have similar behaviour. When I set a property of a window, I expect it to be applied right away (or within a reasonable amount of milliseconds). Having to do «destroy, create, 1» all of the time is wrong.
_______________________________________________________________________ | Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC