[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-kimageshop
Subject: paintopsettings refactoring
From: Boudewijn Rempt <boud () valdyas ! org>
Date: 2009-11-30 7:10:11
Message-ID: 200911300810.11184.boud () valdyas ! org
[Download RAW message or body]
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
_______________________________________________
kimageshop mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic