Parameters to filters

[Inge Wallin]

On Thursday, August 23, 2012 09:39:29 Boudewijn Rempt wrote:
> On Wednesday 22 August 2012 Aug, Inge Wallin wrote:
> > I would like to add the ability to parameters to filters. My usecase is
> > that I want the user to be able to specify a path to a book cover image
> > (normally an SVG file) and have the epub filter add that to the epub
> > file.
> > 
> > I wonder if anybody else have thought about this and maybe even has a
> > design thought out already.  The problem is slightly complex, involving
> > at least the
> > 
> > following aspects:
> >  - In the general case we can have a whole chain of filters and it's
> >  possible
> > 
> > that more than one filter wants an option with the same name. So we need
> > to be able to specify which filter should receive each parameter.
> > 
> >  - We may want to send several different data types. I guess the most
> >  common
> > 
> > one would be a string or a number but in the general case it could be
> > anything. So I think a QVariant should be involved somewhere (but see
> > below).
> > 
> >  - We need some code in calligraconverter to parse command line options
> >  and
> > 
> > create parameters. This would speak against using anything but strings.
> 
> I would suggest to create xml-based files that contain the settings for a
> filter and pass that file's name to calligraconverter, instead of
> specifying all params on the commandline.

While this is good for default values when a value *has* to be provided, it's 
perhaps not so good for values that are optional.  Consider (syntax is not 
finalized of course):

# calligraconverter --parameter:cover-image=./cover.svg book.odt book.epub

Now, if cover-image is not given the next time the converter is run, it means 
"do not put a cover image in the file" rather than "use the same cover image 
as the last time".

And even if it was a setting we still need to provide a way to set the value 
the first time so we still need to parse command line options.

> >  - We need to be able to create a UI using tools or general dockers so
> >  the
> > 
> > user can control the parameters from the applications. The values need
> > then be transferred to the filters somehow.
> 
> For krita, the filter dialogs themselves make their settings persistent.
> Choose a quality percentage in the jpeg filter and it will get saved in
> the kritarc config file and restored when the dialog shows up again. Like
> this:
> 
> ExportConfiguration-TIFF=<!DOCTYPE params>\n<params>\n <param
> name="alpha">false</param>\n <param name="compressiontype">0</param>\n
> <param name="deflate">6</param>\n <param name="faxmode">0</param>\n <param
> name="flatten">true</param>\n <param name="pixarlog">6</param>\n <param
> name="predictor">0</param>\n <param name="quality">80</param>\n</params>\n
> 
> This is done using a serializable properties class we use everywhere in
> Krita.

Ah, so the filters open the dialog.  How do you handle --batch?

The properties class seems useful. But I seem to remember something called 
KoProperties... Is that more or less the same? Or what is that used for.