Better undo/redo for Krita
Open, Needs TriagePublic

Description

  1. Snapshot Docker.
    1. Users should be able to save the current state of document as a snapshot. Use KisDocument::clone() to obtain a (relatively) shallow copy of the document.
    2. The docker should display a list of snapshots (shallow copies) of the document, and allow users to replace the current document with any of the snapshots taken.
    3. A user manual should be written on how to use this docker. After finishing the docker, a tutorial video should be recorded.
  2. Copy-on-Write Vector Layers.
    1. Current implementations of vector layers:
      1. Data are stored using d-pointers that are not shared
      2. Subclasses’ d-pointers are inherited from those of the parent class
      3. Have at least two constructors for each class to prevent creating multiple data instances
        1. ChildClass() : ParentClass(new ChildClassPrivate(this))
        2. ChildClass(ChildClassPrivate * dd) : ParentClass(dd)
      4. All shapes are descended from KoShape, including KisShapeLayer itself
    2. Possible implementations:
      1. Similar implementation to the one in KisTile, which manually calls KisTileData::acquire() when an edit is needed.
      2. Qt’s implicit sharing, using the Qt class QSharedDataPointer. This class is reentrant (guaranteed to be safe when different threads access different instances). This is the preferred method. However, this is not thread-safe and may cause problems if the same instance is accessed from multiple threads. More work needs to be done to ensure thread-safety.
      3. C++11’s shared_ptr, as demonstrated by Sean Parent. However, in KDE guidelines, Qt libraries are preferred over std. This should be attempted only if QSharedDataPointer cannot work.

Timeline

Week 1-4 (May 27 - June 23)
Write core code to replace the current document with another KisDocument
Unit test for replacing the current document with another KisDocument
This involves emitting signals to GUI
Probably begin writing the snapshot docker

Week 5 (June 24 - June 30)
Snapshot Docker
Write user manuals
Make a tutorial/demo video

Week 6 (July 1 - July 7)
Build a testing release, and collect feedback from the community
Possible questions:
Is snapshot taking helpful to your workflow?
Is it efficient?
Other features wanted?
Improve the docker using the feedback

Week 7-8 (July 8 - July 21)
Start working on Copy-on-Write vector layers
The re-written classes should have the same API as the old ones, where possible.
Start using implicit sharing for members of KoShapePrivate
What have been stored using pointers may be now stored using shallow copies, for example, QSharedPointer<KoShapeStrokeModel> stroke could be replaced with KoShapeStrokeModel stroke
Make api documents on how implicit-sharing works for these components, and possibly a “guideline” or example on how to use implicit sharing in other classes.

Week 9-10 (July 22 - August 4)
Implicit sharing for the KoShape hierarchy
According to the discussion above, I may need to replace Qt’s macro with code written by myself in all descendents
Write and run unit tests
Try to merge the changes into master

Week 11 (August 5 - August 11)
Write undo commands that switch between states to replace the original ones that stores actions

Week 12 + Remaining 1 day (August 12 - August 19)
Used for buffering

Related Objects

StatusAssignedTask
Opentusooaw
Resolvedtusooaw
tusooaw created this task.May 8 2019, 4:42 PM
tusooaw updated the task description. (Show Details)May 8 2019, 4:45 PM

Discussion on q-pointers.

The KoShapePrivate hierarchy uses q-pointers, which is a barrier to making it derive from QSharedData. (because the data are shared by many KoShapes and we do not know which one we are calling from)

Possible solutions:

  • Refactor out all the q-pointers and pass the KoShape pointer every time we call a function in KoShapePrivate
  • Refactor out all the q-pointers and put all methods using q-pointers into KoShape class
  • Make the shared data an inner layer of KoShapePrivate and access properties using d->s->propertyName (what if a descendent class accesses the d-pointers?)

Discussion on derived d-pointers.

Currently the KoShape hierarchy uses derived d-pointers. E.g. KoShapeContainerPrivate is derived from KoShapePrivate. Since there is public inheritance, it makes it possible for KoShapeContainer class to access things declared in KoShapePrivate class (should this be allowed?).

Do we really need derived d-pointers? Would it be better to let the derived classes have their own d-pointers? There does not seem to be any benefit to use the derived ones, except for saving some memory. And yet, using multiple d-pointers seems to allow less deep-copying.

About q-pointers.

The basic idea of Qt's d/q-pointers is to avoid private members and methods being exposed in a header file (and, therefore in a class' binary representation). It provides us with two features:

  1. binary backward compatibility (we can update private methods without breaking ABI)
  2. reduce compilation time (we don't need to recompile library (and client) code when changing private members

In our case point 1) is of no importance to us. Point 2) is interesting, but is not a "must have".

Looking at the real code, we have very few private methods in KoShapePrivate and its descendants, so I guess we can just refactor out q-pointers completely, that is:

Refactor out all the q-pointers and put all methods using q-pointers into KoShape class

Discussion on derived d-pointers.

Deriving d-pointers is also a part of "binary compatibility" and "private members exposure" problem. Basically, it is a tricky way to support 'protected' members and methods in an environment where you cannot write into a header. If all the private members are derived, then it is enough to have only one Private *p_ptr in a header, and all the descendants will happily use it. But it they are not derived, then every class of hierarchy will have to expose its own Private member.

Would it be better to let the derived classes have their own d-pointers?

I'd say, it is possible. In Krita (not Ko) code we use exactly this way. We declare QScopedPointer<Private> m_d on every level of class hierarchy and expose protected methods via a header. It is not much binary compatible, but we don't care.

Do we really need derived d-pointers?

The only benefit is a little bit better compilation time, so, no, there is no strong requirement on keeping d-pointers derived. The only trouble is, it might be a bit complicated to refactor all these classes. If you manage to do that, that would be very good :)

On KoShapeController:

Currently the methods return a KUndo2Command that will do the changes. However, it should be possible to make them only do the changes, by taking a clone of the active layer before making undoable changes to it.

The original approach looks like:

KUndo2Command *command = shapeController->addShape(...);
doc->addCommand(command);

The new approach should look like:

KisNodeSP originalState = currentNode->clone();
shapeController->addShape(...);
// currentNode has been modified now

// KisNodeReplaceCommand is a post-exec command
// to avoid multiple kundo2_i18n`s we probably want to make a factory method for it?
KUndo2Command *cmd = new KisNodeReplaceCommand(kundo2_i18n(...), currentNode, originalState);
doc->addCommand(cmd);

A note on KisNode::copyFromNode():

We are probably currently unable to "remove then add a copy" because the "original state" has to be a clone of the layer in the working document -- that will mess up with previous undo commands in the history because they cannot find the correct node.

copyFromNode() function should be no longer required as we get rid of undo commands--at that time the whole document will be replaced. See https://invent.kde.org/tusooaw/krita/commit/7c77e99a3c5037e49a44fbf033da6fdec84ed68a