Fix: Ghosting effect on the flight path when dragging the takeoff point.

[Eureak-zon]

Description

Problem: While dragging the takeoff (Home) point, the flight path displayed a "ghosting" or overlapping effect. This was caused by redundant or improperly sequenced calls to _recalcAll during the coordinate update process, which failed to clear the old route buffer correctly while the user was actively moving the point.

Changes:

• Disconnected/Commented out the broad _recalcAll call on coordinateChanged for the settings item.
• Implemented a more targeted signal-slot connection: now updates the SimpleMissionItem coordinate and emits launchCoordinateChanged directly.
• This ensures the UI refreshes the specific flight segment synchronously with the drag action without triggering a full, messy recalculation of the entire mission path.

Type of Change

• Bug fix (non-breaking change that fixes an issue)

Testing

• Tested locally (Windows/Qt)
• Tested with simulator (SITL) - Confirmed smooth path updates during takeoff point displacement.

Platforms Tested

• Windows
• Linux
• macOS

Flight Stacks Tested

• PX4
• ArduPilot

Checklist

• I have read the Contribution Guidelines
• My code follows the project's coding standards
• New and existing unit tests pass locally

[Copilot]

Pull request overview

This PR fixes a ghosting effect when dragging the takeoff (home) point in the mission planner by refactoring how coordinate changes are handled.

Key Changes:

• Replaces automatic full mission recalculation with targeted coordinate updates when dragging the takeoff point
• Implements a lambda connection to synchronize the takeoff item coordinate with the launch coordinate and emit the appropriate signal

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
src/MissionManager/TakeoffMissionItem.cc	Adds a lambda to handle coordinate synchronization between settings item and takeoff item when the launch coordinate changes
src/MissionManager/MissionController.cc	Comments out the broad _recalcAll connection to prevent redundant full mission recalculations during coordinate updates

[Copilot]

The lambda capture [=] is deprecated in C++20 when capturing this implicitly. Use [this] instead to be explicit about capturing the object pointer. This matches the pattern used elsewhere in the codebase (see GeoFenceController.cc:108 and RallyPointController.cc:69 for examples).

Suggested change

	connect(_settingsItem, &MissionSettingsItem::coordinateChanged, this, [=](const QGeoCoordinate& coordinate) {
	connect(_settingsItem, &MissionSettingsItem::coordinateChanged, this, [this](const QGeoCoordinate& coordinate) {

[Copilot]

This commented-out code should be removed entirely rather than left as a comment. The disconnect for this connection in _deinitAllVisualItems (line 1916) should also be removed to maintain consistency.

Suggested change

//connect(_settingsItem, &MissionSettingsItem::coordinateChanged, this, &MissionController::_recalcAll);

[DonLakeFlyer]

I don't think this can be disconnected. I need to dig into the recalc code a bunch more. But the location of the home position drives things like mission status lengths/times and so forth. By disconnecting there is some info down deep in the bowels of MissionController that will be wrong now I believe. Gonna take a pile more review on my part to verify.

[DonLakeFlyer]

Getting a bit closer to re-educating myself on all of this. I think the coordinateChanged signal needs to be connected to the signal which recalcs just mission flight status instead. Not 100% sure yet. After being away from MissionController it's so dense to get back into! Could use a full re-write to make it more understandable.

[Copilot]

The lambda unconditionally updates the SimpleMissionItem coordinate when the settings item coordinate changes, without checking the _launchTakeoffAtSameLocation flag. This may cause the takeoff point to follow the launch point even when the user has configured them to be at different locations. Consider checking _launchTakeoffAtSameLocation before calling SimpleMissionItem::setCoordinate(coordinate), similar to the logic in TakeoffMissionItem::setCoordinate at lines 113-114.

Suggested change

	SimpleMissionItem::setCoordinate(coordinate);
	if (_launchTakeoffAtSameLocation) {
	SimpleMissionItem::setCoordinate(coordinate);
	}

[DonLakeFlyer]

This isn't correct either. In the fly view the home position which is kept in the settings items can differ from the takeoff coordinate. In the plan view it's the takeoff item job to drag the launch position along with it. So the user doesn't have the ability to move the home position if they are using a takeoff item. It's all ridiculously complicated.

[DonLakeFlyer]

And then for a fixed wing on PX4 it's all different!