Krita/Recording and Collaborative working Design

Talk about those two functions are put together in the wiki as the core of their working is essentially the same.

What will be covered ?

DEPRECATION WARNING: This is outdated and no longer in use, please refer to docs.krita.org instead!

Recording

It is the ability of recording all actions done in krita, and replay them later.

Full History

It's usefull for creating tutorials (that would be replayed in front of the user), allow automation and also a much more complete undo stack.

Summary in metadata

Some metadata engine offers to store an history of changes made to a file, it should be pluggable to this framework (see Krita/Metadata). And generate a summary of change like "The user has apply invert, blur and auto-contrat filters".

Generating scripts and macros

The history can be used to generate macros for a future KOffice2/Qt4 version of the KoMacro framework or to generate ruby/python/js scripts.

Crash reporting

It would be interesting to try to dump the action history after a crash. Sometimes users don't know exactly what they have done, and backtrace isn't allways meaningfull.

Collaborative working

It is the ability to work on the same document on two different computer, in fact there are two aspects to this: working at the same time and see the changes in real time, and asynchronous work and the need to merge documents, only the first aspect is addressed by this document.

One of the problem is if the two users don't have the same set of installed plugins (it could be check at the beginning of the session, and the plugins can then be disabled (or if we get an automatic way to install plugins, we can offer to install them)).

Action Recording Framework

The shema below how various elements fit together:

Various Ideas

Recording input events

The first idea is to track and record all input (keyboard, mouse) events and replay them, it's pretty easy to do. But, it is very weak, from one version of Krita to an other GUI items might have move, and even from one setup of Krita to an other, shortcuts might be different, the size of the window... There is probably a solution to this problem, but it's very likely to be hacky.

Higher level of description of KisCommand

The second solution requires much more work, KisCommand keeps a good track of what changes occur to a document, so the solution could be to record the list of KisCommand. The problem is that currently, for operations that changes pixels, KisCommand keeps a copy of the tiles that were affected, it's fast for undo/redo, but not only, it takes a lot of memory but it's not a viable solution for automation, it can only works for collaborative edition with a fast connection ! So the idea is to also store high level information along with KisCommand (like the brush, the selected paintop, the tool, positions, or the filter that was used and its parameter ) and to only transmit/save that information.

Problems

Resources

Resources are quiet a problem. If they are referenced only by names in the XML it's possible that the content of the resource will be different from one computer to an other.

Difference between version in Krita

An other problem can appeared due to differences of results if version of Krita are different.

See also

Collaboration Usecases.