kicad-developers team mailing list archive

[jp charras <jp.charras@xxxxxxxxxx>]

Le 23/12/2016 à 00:30, Dino Ghilardi a écrit :
> 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.

Yes, the undo/redo on multiple sheets is very tricky, mainly because usually you are not expecting
this command made in a given sheet changes something in an other sheet.

Your remark about synchronizing the undo/redo between all sheets shows very well the problem.
This is the reason the clearing annotation command is not undo-able, and some changes when
generating a netlist clears the undo/redo stack..

I am not sure this is only a matter of code (it could be fixed), but this is a matter of usability:
Is it really possible to safely undo a "global" command from a sheet, after a lot of other edition
commands made in other sheets.
How to remember or accept all commands to undo/redo in other sheets?

Remark:
>From my point of view, the value of the reference field should be *not modifiable* because:
1) changing this values usually breaks the board.
2) in complex hierarchies, this is not the value of the reference, only the value currently
displayed on screen.
3) the ref and the unit number and closely associated in multiple units per package components.

-- 
Jean-Pierre CHARRAS