[scribus-dev] UndoState::transactionCode ?!

[JLuc]

I thereafter correct some typos in the explanations.
JL

Le 22/10/2015 11:25, JLuc a écrit :
> undstate.h is pretty well documented.
> UndoState is the main class and defines trasactionCode as allways 0.
> TransactionState is a subclass that provides a container where multiple UndoStates can be stored.
>
> The states are stored chronologicaly when the action is created : order is meaningfull.
>
> TransactionState::undo() and redo() defines the values

of trasactionCode

> for the stored UndoStates
> so as to manage selection and display refresh.
>
> For redo, order is the same as action creation order (see undostate.cpp 310)
trasactionCode value becomes :
> 0 in case there is only one element (AMOF, in sucha a case class could be plain UndoState)
> 1 when dealing with the first chronologicaly stored UndoState
> 2 when dealing with the last chronologicaly stored UndoState
> 3 when dealing with other stored UndoStates
>
> For undo scribus begins with the last chronologicaly created state,
> hence, the
trasactionCode
> values are opposite regarding 1 and 2 (see undostate.cpp 290)
> (but the same regarding "only one state" or "intermediate state" actions.
>
> That's because there are special consequences when undoing or redoing the last undoState.
>
> No screen refresh is required for most of the intermediate states,
> refresh is only required for the last step, that's when Code == 2
> and of course also when there is only one state (Code == 0)
> (see pageitem.cpp 5496, 7023, 7059)
>
> A special case is for creating elements :
> the last existing object part has to be unselected before its creation is undone
> that is before it is deleted. (scpage.cpp 337)
>
>
> This explanation comes from looking at the source (I'm no core dev).
> Hope it helps.
>
> Undo and redo scribus management still features quite a lot of bugs
> so its great if you can understand how it works and fix some of them.
>
> JL
>
>