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.