Add diff highlighting for proof step differences in the graph view by Kitsunp · Pull Request #435 · zxcalc/zxlive

Kitsunp · 2026-02-17T08:39:53Z

Addresses #190
Adds visual highlighting of vertices and edges that will change between
proof steps. When navigating to a step in proof mode, elements affected
by the next rewrite are highlighted with coloured outlines and tinted
fills, making it easy to spot the difference without manual comparison.

What it does:

Vertices that will be removed get a crimson outline and tinted fill
Vertices whose type or phase will change get an orange outline and tinted fill
Edges that will be removed or change type are highlighted similarly
Only semantically meaningful changes are shown (type, phase, structural);
cosmetic changes like repositioning are excluded to avoid visual noise

How to test:

Open a proof, apply a few rewrites
Click on any step that is not the last one
The nodes/edges that change in the next step should be visibly highlighted
Clicking the last step clears all highlights

Files changed:

settings.py — diff colour scheme + toggle setting
settings_dialog.py — checkbox for "Highlight proof step differences"
vitem.py — diff highlight rendering for vertices
eitem.py — diff highlight rendering for edges
graphscene.py — highlight_diff() and clear_diff_highlights() methods
proof.py — calls highlighting in move_to_step()

Leverages the existing pyzx.graph.diff.GraphDiff already used in
GraphScene.update_graph(). No new dependencies. Toggleable via Settings.

boldar99 · 2026-02-17T15:24:51Z

Hi, thanks for the PR. I have started testing it, and it seems that incorrect vertices and edges are being highlighted with simple rewrites:

Screen.Recording.2026-02-17.at.15.18.56.mov

Kitsunp · 2026-02-17T16:50:27Z

Thanks for catching this @boldar99! I tracked down the root cause.
The issue is that ProofModel.get_graph() uses BaseGraph.copy() to return graphs, and .copy() renumbers vertex IDs to be consecutive (its own docstring says: "The copy will have consecutive vertex indices, even if the original graph did not"). When a rewrite removes a vertex (creating a gap in the IDs, e.g. {0, 1, 3, 4}), each call to .copy() compacts them independently — so the same logical vertex ends up with different numeric IDs in each copy. Since GraphDiff compares by vertex ID, it sees almost every vertex as "changed" even though nothing actually changed.
The fix in move_to_step():

Display graph: replaced get_graph() with copy.deepcopy() which preserves the original vertex IDs exactly (consistent with how every other graph-copy in the codebase works).
Next-step graph (for diff computation): access self.model().steps[index].graph directly instead of copying — GraphDiff only reads from it, never modifies it, so no copy is needed. This also avoids any performance concern since it's zero-cost.

boldar99 · 2026-02-18T14:25:55Z

Thanks for the update. It seems you have accidentally run some automated formatting on the entire codebase. Please undo this.

I have done some more testing. Fusion definitely looks a lot nicer, but it is still a bit odd. In particular, when two spiders are fused, it is the nodes and the connecting edge that should be highlighted. Same when un-fusing, then the spider that is being transformed.

Screen.Recording.2026-02-18.at.14.21.56.mov

Kitsunp · 2026-02-19T15:01:16Z

@boldar99

lia-approves · 2026-02-23T18:15:15Z

Hi @Kitsunp, in addition to the request to revert all unnecessary formatting changes to unrelated files to this issue, I tested both the fusion and the "Unfuse spider" rules in your latest commit and found the highlighting to still not be as intended. As Boldi described above:

In particular, when two spiders are fused, it is the nodes and the connecting edge that should be highlighted.

and likewise for the "Unfuse spider" rule.
Let us know if you have any questions.

Kitsunp · 2026-02-23T20:44:02Z

@lia-approves Currently, the latest changes are specific to the code. I did not rewrite the format. The previous formatting correction I had made was expressed so that what is currently visible refers to the current code, and I relied on mypy for some corrections, but I will also look into the mentioned issue.

RazinShaikh · 2026-02-25T10:30:54Z

Hi @Kitsunp unfortunately there are many changes not related to the issue. For you convenience, I have highlighted some of them below.

RazinShaikh · 2026-02-25T10:31:22Z

test/test_update_checker.py

-import pytest
+# import pytest
 from datetime import datetime, timedelta
-from unittest.mock import Mock, patch


why are these lines commented out?

RazinShaikh · 2026-02-25T10:31:49Z

zxlive/animations.py

                                             QEasingCurve(QEasingCurve.Type.OutQuad))

-    return anim_before, anim_after
+    return anim_before, anim_after


blank line removed here

RazinShaikh · 2026-02-25T10:32:16Z

zxlive/common.py

+        if _type is bool:
            val = str(val) == "True" or str(val) == "true"
-        if _type == int:
+        if _type is int:
            val = int(str(val))
-        if _type == float:
+        if _type is float:


why do you change "==" to "is"?

RazinShaikh · 2026-02-25T10:33:39Z

zxlive/custom_rule.py

all the changes in this file are not related to the diff highlighting for proof steps

RazinShaikh · 2026-02-25T10:33:56Z

zxlive/edit_panel.py

all the changes in this file are not related to the diff highlighting for proof steps

RazinShaikh · 2026-02-25T10:34:17Z

zxlive/eitem.py


        if self.refresh:
-            self.it.refresh()
+            self.it.refresh()


new line at the end of file removed

RazinShaikh · 2026-02-25T10:36:31Z

zxlive/graphscene.py

+    @staticmethod
+    def _phases_semantically_equal(old_phase: object, new_phase: object) -> bool:
+        """Check whether two phase values represent the same rotation.
+
+        ``GraphDiff`` compares phases with Python's ``!=`` operator which
+        is sensitive to representation: ``Fraction(1, 4) != 0.25`` is
+        ``True`` even though both encode the same angle.  This helper
+        converts both values to ``float`` and compares with a small
+        tolerance so that purely representational differences (e.g.
+        ``Fraction`` vs ``float``) do not produce false‑positive
+        highlights.
+
+        For symbolic phases (``Poly`` objects or other non‑numeric types)
+        the function falls back to exact equality, which is the correct
+        behaviour since we cannot numerically evaluate free variables.
+        """
+        try:
+            return abs(float(old_phase) - float(new_phase)) < 1e-12  # type: ignore[arg-type]
+        except (TypeError, ValueError):
+            # Symbolic / non-numeric phases — fall back to exact equality
+            return old_phase == new_phase


I don't think this is necessary and it's best handled by PyZX rather than ZXLive. In ZXLive, we do not use float angles, they are always converted to Fractions.

RazinShaikh · 2026-02-25T10:38:52Z

zxlive/rewrite_data.py

all the changes in this file are not related to the diff highlighting for proof steps

Kitsunp · 2026-02-26T18:53:58Z

Thanks for the feedback @RazinShaikh, @lia-approves ! I've updated the PR with the following changes:

Reverted unnecessary formatting changes: Restored the original state of unrelated files (zxlive/custom_rule.py, zxlive/edit_panel.py, zxlive/rewrite_data.py, test_update_checker.py, etc.) to keep the PR focused.
Fixed Fusion/Unfusion Highlighting: I updated the logic in highlight_diff (zxlive/graphscene.py) to correctly identify and highlight the structurally affected "survivor" nodes and connecting edges during both the Fusing and Unfusing spider rules. It now limits the highlight correctly without bleeding into unaffected external neighbors.

Let me know if everything looks good now!

boldar99 · 2026-02-27T18:00:12Z

Hi again,

Thanks for cleaning up the rest of the project.
I have tried it and fusion and un-fusion are still not as they should be. It should only highlight the two spiders that are being fused, and the connecting edges, noting else. See the video for reference.

Screen.Recording.2026-02-27.at.17.58.16.mov

Kitsunp · 2026-02-28T14:20:06Z

@boldar99

RazinShaikh · 2026-02-28T14:27:31Z

I have not had a look at the recent changes but I wanted to suggest if you could work on making it look pretty. It should have better colours and it should look good in light mode, dark mode and all the color schemes.

Add diff highlighting for proof step differences in the graph view

d824587

Kitsunp added 2 commits February 17, 2026 10:04

update

5de9293

update

5ba1d39

Kitsunp and others added 3 commits February 17, 2026 23:40

update

7d635c1

update

8a0d97e

Merge branch 'master' into master

5536d75

Kitsunp force-pushed the master branch from 249d71d to 5536d75 Compare February 19, 2026 13:33

update

26dbd9a

lia-approves mentioned this pull request Feb 23, 2026

Highlight difference in rewrite steps #445

Open

RazinShaikh requested changes Feb 25, 2026

View reviewed changes

Kitsunp added 3 commits February 26, 2026 12:14

update

2014aed

update

ea0eb0d

update

30f7f6f

Kitsunp requested a review from RazinShaikh February 27, 2026 12:24

Kitsunp and others added 7 commits February 28, 2026 06:09

Merge branch 'master' into master

a2d1148

update

ff643d0

Merge branch 'master' of https://github.com/Kitsunp/zxlive

c8b5fb6

update

17708f4

update

f3d5691

update

da48b6f

update

364f0c2

Kitsunp added 2 commits February 28, 2026 09:01

update

1b86d16

update

f561d64

Conversation

Kitsunp commented Feb 17, 2026

Uh oh!

boldar99 commented Feb 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Kitsunp commented Feb 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

boldar99 commented Feb 18, 2026

Uh oh!

Kitsunp commented Feb 19, 2026

Uh oh!

lia-approves commented Feb 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Kitsunp commented Feb 23, 2026

Uh oh!

RazinShaikh commented Feb 25, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Kitsunp commented Feb 26, 2026

Uh oh!

boldar99 commented Feb 27, 2026

Uh oh!

Kitsunp commented Feb 28, 2026

Uh oh!

RazinShaikh commented Feb 28, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

boldar99 commented Feb 17, 2026 •

edited

Loading

Kitsunp commented Feb 17, 2026 •

edited

Loading

lia-approves commented Feb 23, 2026 •

edited

Loading