Undo system for painterly paintops.

[Boudewijn Rempt]

On Wednesday 22 August 2007, Emanuele Tamponi wrote:
> Hello,
> I attached the patches that implements the method I thought for undoing
> painterly actions.
>
> Explanation of the problem:
> Actually, KisTransaction handles only one paint device at once.
> Painterly paintops change two paint devices at a time: the paint device
> onto they're putting colors, and the painterly overlay where they write
> painterly data.
>

Okay, just to make sure I get this, also in the light of putting the painterly 
overlay back into the paint device:

There are the following requirements:

* Using painterly paintop should not mean any changes of code in any painting 
tool
* A painterly paintop changes both the paint device and the painterly overlay, 
both changes should be part of one undo step
* A painterly paintop needs direct access to the paint device and the 
painterly overly it changes (for bidi transfer)

I would add:

* Paintops should work on KisPaintDevices, not KisLayers, otherwise we cannot 
use KisPainter anymore on paint devices that are not part of the image layere 
graph with all paintops we have.

Currently, the paintop gets a KisPainter and a KisPaintDevice (a change by 
Cyrille to make the duplicate paintop work).

So, if the painterly overlay is part of the paint device, not the layer, then 
we don't need to set the layer on the painter or on the paintop or the 
paintop settings: the painterly paintops can already access the source 
device.
	
(XXX and Note Bene: we have a setLayer in KisPaintopSettings which is only 
used by the filter paintop, and then only to get the source paint device. 
This needs to be changed to use the paint device directly.)

As for undo, there are three possibilities that I can see:

* use merge to merge the memento of the paint device and of the painterly 
overly in one KisTransaction
* use macros to join the transaction on the paint device and the transaction 
on the painterly overlay in one undo step
* make KisTransaction painterly overlay-aware, i.e, change the constructor of 
KisTransaction to look like:

KisTransaction::KisTransaction(const QString& name, KisPaintDeviceSP device, 
QUndoCommand* parent)
    : QUndoCommand(name, parent)
    , m_private( new Private() )
{
    m_private->device = device;

    m_private->memento = device->dataManager()->getMemento();
    if (device->hasPainterlyOverlay) m_private->painterlyOverlayMemento = 
device->painterlyOverlay()->dataManager()->getMemento();
    m_private->firstRedo = true;
}

That way, everything is done completely automatically and we don't have to 
change anything outside KisTransaction. But it is dependent on making the 
painterly overlay part of KisPaintPaintDevice, not KisPaintLayer.

My preference is for:

a) move KisPainterlyOverlay back from KisPaintLayer to KisPaintDevice
b) make KisTransaction painterly overlay-aware
c) make the painterly paintops use KisPaintDeviceSP KisPaintop::source() to 
get at the source paint device & overlay
d) remove set/get layer from KisPainter and KisPaintOpSettings and fix 
KisFilterOp

-- 
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: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20070823/37b04e02/attachment.pgp