GroIMP wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
~~NOTOC~~
====== Redo ======

The log also keeps track of transactions that have been undone, enabling you to "redo" them if needed. Undo and redo operations can be performed in sequence (a "chain"), but once a new command is executed, the chain of possible redos is cleared. Thus, it is possible to re apply the transactions previously "undone". Yet, one a new transaction is performed (running a new RGG function, applying a modification through the attribute editor, adding an object through the menu, ...) the chain of transaction do not lead to the "redo" anymore. Thus, it is not possible to "undo" > apply new > "redo". 

======  ======

Once a new transaction is initiated (e.g. by):

  * Running an RGG function,
  * Modifying an object through the attribute editor,
  * Adding an object via the menu,

the previous redo history is **discarded**. That means GroIMP does **not** support branching histories like version control systems.

**Example of an unsupported sequence:** ❌ Undo → Apply new operation → Redo ❌


:!: Note: applying a transaction take some time. Clicking very fast between undo/redo, might trigger a transaction before the last one is properly performed. It usually lead to a NullPointerException.