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. _______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
