paintopsettings refactoring

[Boudewijn Rempt]

We had a discussion this Sunday on what to do with the problem that paintop 
settings and their widgets are so very closely tied together. We came to the 
following redesign (which I'll also put on the wiki, but I cannot reach that 
at the moment):

We had an idea toremove the KisPaintOpSettings class and put the paintop 
options and custom options directly inside the paintop. But I'm not sure how 
that works if we look at the flow when selecting a preset and starting to 
paint:

select a preset
fill the settings widget with the current settings
mouse down: create a paintop from the current settings
mouse move: paint, serialize the current settings/info
mouse up: finish the stroke
mouse down: create a paintop from the current settings

etc.

Sven, can you comment on this?

----------

Ascii class diagram:

KisPaintOpPreset::KoResource

   - name
   - KisPaintOp ID
   
    -> to/from XML
    -> preview
    -> create KisPaintop, which contains settings:
      - bool, int, etc
      - one or more KisPaintOpOption
           -> serializeto/from XML
           -> algorithm
           -> sensor

-------------------------

KisPaintOpSettingsWidget::QWidget  
	There will be one KisPaintOpSettingsWidget per paintop per view.

   - paintop
   -> load/save(KisPaintOp)
   -> as KisPaintOpOptionsWidgets as the paintop has KisPaintOpOptions
        load/save from KisPaintOpOptions

-- 
Boudewijn Rempt | http://www.valdyas.org