Krita/Recording and Collaborative working Design: Difference between revisions
(Created page with '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 ? = == Recording == It is the ability o...') |
Fruitywelsh (talk | contribs) (→What will be covered ?: added deprecation warning since this is no longer supported) |
||
| Line 2: | Line 2: | ||
= What will be covered ? = | = What will be covered ? = | ||
'''DEPRECATION WARNING:''' This feature has been disabled in the current Krita releases. | |||
== Recording == | == Recording == | ||
Revision as of 19:14, 10 March 2021
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 feature has been disabled in the current Krita releases.
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.
The Framework
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.