logisim-evolution icon indicating copy to clipboard operation
logisim-evolution copied to clipboard

Do/Un-Do/Re-Do not positioning properly

Open miczac opened this issue 1 year ago • 9 comments

In v3.8 a Do/Do/Undo/Undo/Re-Do/Re-Do sequence the last Re-Do messes up the circuit. I can provide a screen recording and an example file. (.zip) move_ctrl_z_bug.zip This is on Mac OS 10.14.6. Thanks a lot, Michael.

miczac avatar Feb 05 '24 16:02 miczac

Just checked on an up-to-date Arch Linux w/ Cinnamon: behaves exactly the same.
HTH, Michael.

miczac avatar Feb 05 '24 16:02 miczac

Thank you for the report. I can reproduce the problem. I ran into a similar issue a week or so ago and I was trying to figure out what is happening.

I suspect it has to do with the fact that selection / deselection is not actually recorded in the undo stack, but some actions that are recorded apply to the selected objects. This will require more research and careful thinking.

davidhutchens avatar Feb 05 '24 17:02 davidhutchens

Thanks for the quick response! It appears the issue with what's recorded to the stack is more complex. In this example, I just stumbled upon, moving a freshly pasted object gets skipped in the undo queue. (if I put this correctly) You can see, move doesn't appear in the undo-menu. A second move got recorded though.

https://github.com/logisim-evolution/logisim-evolution/assets/1922103/f7323a8f-fd28-4167-ae0a-4fbfbf09edf8

miczac avatar Feb 06 '24 03:02 miczac

@miczac: I don't think that the paste drag behavior is a problem. The paste puts a selected object on the screen, but doesn't actually attach it. That way, you can drag it to where you want it without it grabbing a wire by accident and causing it to deform. It isn't until you drop it that the "paste" is actually attached to the diagram. Of course, if you do something to deselect it where it pasted, it would be attached at that point. Given that behavior, it would actually be a problem to undo the move without undoing the paste since that would attach it where it was never attached before.

davidhutchens avatar Feb 07 '24 02:02 davidhutchens

I agree with @davidhutchens analysis. Based on the screen recording, the behaviour seems to be correct and intentional. @BFH-ktt1: Do you agree?

If yes, I think that this issue can be marked as invalid and closed as won't fix.

maehne avatar Aug 15 '24 14:08 maehne

The second issue is intended behavior. But the original issue is a bug in the interaction of selection and undo. I haven't yet come up with a clean way to fix it however.

davidhutchens avatar Aug 16 '24 02:08 davidhutchens

Thanks for the clarification @davidhutchens! Then, let‘s leave this issue open.

maehne avatar Aug 16 '24 04:08 maehne