[GEM-dev] setting multiple parameters at once

[Mathieu Bouchard]

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