1. Messages
  2. FileTransform interface changes

Re: FileTransform interface changes

Malcolm Humphreys <malcolmh...@...>
 

Hi,

The shaper interpolation should be what we agreed.

Interpolation FileTransform::getShaperInterpolation() const;
void FileTransform::setShaperInterpolation(Interpolation interp);
bool FileTransform::hasShaper();

The normal interpolation should stay as it is.

Would FileTransform::setOptionString(...) introduce the same complexity?
 
It would be get to the same end, so yes it would be similar.

Say you wanted to create the OCIOFileTransform in nuke. In this
system, would you expect to see a single knob, 'optionString', or
multiple knobs (cccid, etc)? If a single knob is exposed, how would
the user know what to set? Would we just provide helptext which
documented the options?
 
That would be up to the client app to parse and display as it wishes, it would be nice in the nuke case to have multiple knobs.

What would the string format be? JSON/YAML?
 
I would go for something simple as it would be replaced in 2.0 anyway. I would go for a ';' separated list of key=value pairs.

What keys would be supported in 1.0? shaper interpolation + cccid?
How about normal interpolation?
 
For now it would be just be 'cccid'. This just allows to add additional options between 1.0 and 20 if it's needed with out changing the public interface.

.malcolm

-- Jeremy

On Fri, Sep 16, 2011 at 2:40 AM, Malcolm Humphreys
<malcolmh...@...> wrote:
>
> Could we find a halfway point?
> FileTransform::getOptionString()
> FileTransform::setOptionString(const char * id)
>
> This could take a 'token1=value1;token2=value2' string. This is a bit ugly
> but does allow for the interface to be not so format specific while also
> allowing to add other options if they are needed for fixing bugs on the path
> to 2.0.
>
> eg.
> FileTransform::setOptionString("CCCId=myfavshot;");
Join {ocio-dev@lists.aswf.io to automatically receive all group messages.