Fix spanners' visible property propagation to new segments in Spanner::add()

[ajuncosa]

Resolves: #33714

When an invisible tie is copied and pasted, the pasted tie loses its invisibility: it can't be toggled with the v key, and on save the <Tie> element is written with no <TieSegment> child (possibly the cause of it not rendering properly in musescore.com).

A tie tracks visibility in two places that are meant to stay in sync: the Tie (spanner) itself and its TieSegment. These are normally kept aligned by Spanner::setVisible, which writes both.

However, a SpannerSegment is layout-related, not durable. When a tie is added to a score (e.g. during paste, via undoAddElement -> eraseSpannerSegments), its segments are erased and re-generated from scratch during layout. When re-creating the segments (in Spanner::fixupSegments) we were not copying the tie's visible flag onto them, so the re-generated segments defaulted to visible, while the tie itself stayed invisible.

This lack of sync caused the following:

• While drawing, we read the visibility using getProperty(Pid::VISIBLE), which delegates to the Spanner, so the tie looked correct (i.e. grayed-out).
• The v shortcut (cmdToggleVisible) was not working because it uses the segment's own visible() flag, then writes through undoChangeProperty(VISIBLE), which delegates to the spanner (already invisible). The values match, so the change was ignored.
  • I have fixed this inconsistency in this specific place, but the visible()/setVisible() vs. getProperty()/setProperty() inconsisntencies may be present in other places throughout the code.
  • This value was properly restored when the "visible" checkbox from the properties panel is used because, again, it uses setProperty() (which delegates to the Spanner).
• On save, unless something else had changed, the tie segment reported itself as visible (through visible()), so isUserModified() was false and the <TieSegment> was never written.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 486e389b-d138-450d-a20a-8b780bc22591

📥 Commits

Reviewing files that changed from the base of the PR and between 4ecb007 and fa688e6.

📒 Files selected for processing (2)

• src/engraving/dom/spanner.cpp
• src/engraving/editing/cmd.cpp

---

📝 Walkthrough

Walkthrough

Two small visibility fixes in the engraving layer. In cmdToggleVisible(), the per-item visibility check is changed from calling the visible() method to reading the Pid::VISIBLE property via getProperty(Pid::VISIBLE).toBool(), while the surrounding control flow remains unchanged. In Spanner::add, after a SpannerSegment is added and its Z value is set, the code now also calls EngravingItem::setVisible(visible()) on the segment to propagate the parent spanner's current visibility state.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 50.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly states the main fix: propagating spanner visibility to new segments in Spanner::add().
Description check	✅ Passed	It includes the issue link and a solid problem/motivation summary, but omits the checklist section from the template.
Linked Issues check	✅ Passed	The changes address #33714 by preserving invisible ties through segment regeneration and fixing visibility toggling consistency.
Out of Scope Changes check	✅ Passed	The cmdToggleVisible() adjustment is directly related to the reported visibility bug and is not out of scope.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

Warning

Review ran into problems

🔥 Problems

Linked repositories: Your configuration references 1 linked repositories, but your current plan allows 0. Analyzed ``, skipped musescore/muse_framework.git.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}