kicad-developers team mailing list archive

[Dino Ghilardi <dino.ghilardi@xxxxxxxx>]

Il 22/12/2016 13:03, Nox ha scritto:
> Hello Dino,
>
> Afaik the undo/redo system of Eeschema does not support "batching" of 
> changes natively. Generally speaking the undo/redo system of Eeschema 
> could need some attention but I do not know how worthwhile it is 
> considering the announced refac. There is a way to archive it iirc 
> (PICKED_ITEMS_LIST) but a general "changes batching" approach would be 
> very helpful as it would help to keep the undo/redo more consistent 
> and maybe even avoid the annoying "undo/redo list wipes". I was 
> thinking of something like the PICKED_ITEMS_LIST approach. Maybe one 
> could add a facultative "commit" parameter to every undo/redo related 
> function so one would be abled to provide a container for batching 
> operations. I would give it a try and work on it if this approach 
> would be in principle approved. But I did not dig to deep into 
> Eeschema to really be sure about my claims.
>
> best regards,
>
> Nox
Hi Nox,

The problem I see is when you use the component-spreadsheet tool to do a 
single operation on items from different sheets. Since the undo/redo 
operation is based on a
list got from the current screen with

 PICKED_ITEMS_LIST* List = GetScreen()->PopCommandFromUndoList();

some strange situations may happen:
Example:
1 Suppose you change component R1 of sheet 1 and R2 of sheet 2 at once 
using component spreadsheet tool selecting both of them.
2 Then change R2 again on sheet 2 using the normal 'edit' function for 
the schematic
3 Then go to sheet 1 and undo the last operation (that for that sheet is 
the 'block' edit made in component-spreadsheet): that block operation is 
the last in sheet 1 but not the last in sheet 2.
4 undoing that block operation reverts also R2 to the value at the 
beginning of operations, loosing the changes made in 2, without any 
warning from the program.
so a clean 'undo' of a block operation seems tricky at first sight.


A "quick and dirty" workaround should be add the 'block undo' for the 
components in the same sheet in the correct list, but to undo an 
operation made on all sheets ad once it would be needed to browse into
all the schematic hierarchy. Also this makes the 'ctr-z' used in the 
compo spreadsheet window having a strange behaviour (similar to the 
current one), undoing only the operations for the current sheet).

In the "not-yet-released" version of my tool the undo data is placed in 
the correct list (centering under the cursor the component to be changed 
before putting the data on the undo list.-not optimized since it redraws 
the screen every time a component is modified and then centered under 
the cursor-).

Also since the undo/redo is a very important function in a program like 
this I'm still reluctant in changing it since the risk is to end up in 
something that brakes some other features.

A possible (still simple) solution to this problem could be:
1) add support for a 'multiple undo' on a list (something like putting 
on the undo stack a new operation like 'undo the previous n steps'). 
When undoing this part of the list should be reordered so that on top of 
the redo stack we'll have "Redo the next n steps".
2) when the undo requires an operation on multiple sheets first verify 
that on top of the 'undo' stack there is the same 'block operation' on 
all sheets and issue a warning asking user interaction to undo manually 
the required operations on the sheets that are not aligned, this should 
require to add to the new command also an unique id to identify it also 
in the other lists (can be done with a counter).

Note that here I'm just "brainstorming" and I do not know (yet) if those 
features yet exist in the eeschema undo-redo (I still have to look 
in-deep into the code).


Best regards,
Dino.