filters and their config

[Boudewijn Rempt]

On Tuesday 02 August 2005 17:14, Casper Boemann wrote:

> - a config widget that can configure the filter

More precisely, a config widget that create a configuration object.

It is fairly easy to create a class that dynamically creates a complex 
configuration widget based on a sufficiently detailedly described 
configuration widget -- but it's hard to make it also have a beautiful 
layout. I've done this quite often before. If we can make this work, then a 
simple description of the filter configuration parameters together with a few 
hints about grouping would be enough, and in the best of all possible worlds 
we would never have to code a filter widget again.

(Although, given that we're not in the best of all possible worlds, we might 
need to allow a filter plugin to override this behaviour.)

We need to add to the requirements:

* The filter configuration must be serializable and deserializabe. Preferably 
into a text-based format with proper type-checking. So I'm going for XML with 
a proper DTD here -- that's well-supported by Qt. Paintshop Pro uses Python
as the filter config format, which is cool -- but XML should do.
* It must be possible to initialize the configuration with default values 
without the config widget being called.
* The config widget should always include a button to enable/disable automatic 
previews.
* Given a dynamically created widget, all filter config widgets should make 
automatic previews possible.

> Ideally the filter and configWidget should have nothing in common except
> the config class. This is like the MVC pattern. So the
> KisFilter::createConfigurationWidget() must go. On the other hand is it
> quite nice to have the widget being able to create a correct widget without
            did you mean^filter^here?
> too much trouble

Ideally, we wouldn't have a configwidget for every filter :-).

So, I propose something like

* A DTD for filter configurations
* A parser/generator to create/parse the relevant XML
* A generic filter widget that creates itself based on the XML, and returns 
the XML but with attributes filled in.
* A setConfiguration method on the filter that takes the XML document to
  configure itself.

Another approach would be to create a FilterConfig object that basically knows 
how to load & save itself and how to create a FilterConfigWidget -- but 
that's quite closely coupled.

We might simplify by creating a dictionary on QVariant's that contain the 
filter properties -- so the filter just has to set & get values -- but the 
config widget should ideally be able to create itself based on a hieararchy 
(like grouping certain widgets.)

-- 
Boudewijn Rempt 
http://www.valdyas.org/fading/index.cgi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20050802/d0326f85/attachment.pgp