[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-kimageshop
Subject:    Updated Undo/Redo document
From:       Michael Koch <m_koch () bigfoot ! de>
Date:       1999-08-20 14:07:06
[Download RAW message or body]

Hi all,


here is an updated version of the undo/redo document. Please read and discuss
it.


Ciao,
Michael
 --
Michael Koch


KDE fan, enthusiast and developer

student of computer science at university of applied sciences of Darmstadt, Germany

koch@kde.org, m_koch@bigfoot.de, mkoch@mail.riednet.wh.tu-darmstadt.de
http://www.riednet.wh.tu-darmstadt.de/~mkoch

["undo_design.txt" (text/english)]

KImageShop Undo/Redo Concept
============================

Michale Koch mkoch@kde.org
last modified: 10. Aug 1999


Overall Undo/Redo concept of KImageShop:
----------------------------------------

The Undo/Redo-concept bases on the KOffice way of doing it.
Each action has it's own class for doing and undoing it.
This class is derived from KImageShopCommand (which is derived
from KoCommand). There is a list handling this commands of type
KoCommandHistory. This history manages all commands done and
can undo and redo all commands in the history. Furthermore it
manages that the name of the actual command, that can be
undone/redone, is displayed in the menu.

In then edit toolbar are three buttons, an undo- and a redo
button and undo/redo-dialog button. When you click on one of
the first two, the action will be executed immediatly. When you
click and hold the mouse button a little menu appears thats
shows the actions that can be made undone/redone. At maximum
ten entries are in one menu. When clicking on the third button
a dialog based on KFloatingDialog (like the layer dialog) appears
in which you can see all actions that can be made undone/redone.
Here you can select the entry and apply.



What can be undone:
-------------------

On principle all actions could be undone/redone. We should
implement command-classes for all possible actions.

Per default not all actions should go into the history, 
e.g. zooming, etc. This can be handled by the preferences
dialog, if all or only the common actions are in the history.

QUESTION: Should commands from the layer dialog (raising/
lowering of layers) create undo/redo entries ?

QUESTION: Handling of moving commands
When you move a layer several times multiple undo/redo entries
are created. Should all moving command be made undone by
one undo command or by several undo commands ?

Max undo depth:
---------------

We should provide an infinite number of undo-depth. The last
X commands are hold in memory, further commands are written
on the disk.

In the preferences dialog the user can choose the undo depth, 
he wants and how much commands are stored in memory.

Per default infinite depth is selected and a useful value for
commands-in-memory is set.



[prev in list] [next in list] [prev in thread] [next in thread]