Add automatic mission start/resume popups setting

[rubenp02]

Add automatic mission start/resume popups setting

Description

Added a FlyView setting to control whether mission start/resume popups appear automatically. This option is enabled by default to match the previous behavior.

Checklist:

• Review Contribution Guidelines.
• Review Code of Conduct.
• I have tested my changes.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[Copilot]

Pull request overview

This PR adds a new FlyView setting to control whether mission start/resume confirmation popups appear automatically. The setting (enableAutomaticMissionConfirmPopups) is enabled by default to preserve existing behavior. The implementation follows QGC's Settings Framework pattern by adding the setting definition in the header, implementation file, and JSON metadata, then exposing it in the UI and using it to conditionally show popups in the GuidedActionsController.

Key Changes:

• Added enableAutomaticMissionConfirmPopups boolean setting to FlyViewSettings (default: true)
• Created UI toggle in FlyViewSettings.qml for user control
• Modified GuidedActionsController.qml to conditionally show mission start/resume popups based on the setting

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
src/Settings/FlyViewSettings.h	Adds DEFINE_SETTINGFACT macro for the new setting
src/Settings/FlyViewSettings.cc	Adds DECLARE_SETTINGSFACT macro for the setting implementation
src/Settings/FlyView.SettingsGroup.json	Adds JSON metadata defining the setting's properties (type, description, default value)
src/UI/AppSettings/FlyViewSettings.qml	Adds UI checkbox control to allow users to toggle the setting
src/FlightDisplay/GuidedActionsController.qml	Uses the setting to conditionally show confirmation popups for mission start/resume actions

Critical Issues Found:

• The property name in GuidedActionsController.qml is incorrect (enableAutomaticConfirmPopups instead of enableAutomaticMissionConfirmPopups), which will cause the feature to fail at runtime
• The Fact's value is not being accessed properly (missing .rawValue accessor)
• Minor naming inconsistency and redundant property declaration in FlyViewSettings.qml

[Copilot]

This property declaration is redundant since _enableAutomaticConfirmPopups is already defined as a property at line 42 with the same value (_flyViewSettings.enableAutomaticMissionConfirmPopups). The redundant declaration inside the FactCheckBoxSlider should be removed to follow the pattern used by other similar controls in this file (e.g., line 115 for showJoystickIndicatorInToolbar, which directly uses _flyViewSettings.showJoystickIndicatorInToolbar without a local property).

Suggested change

	fact: _enableAutomaticMissionConfirmPopups
	visible: _enableAutomaticMissionConfirmPopups.visible
	property Fact _enableAutomaticMissionConfirmPopups: _flyViewSettings.enableAutomaticMissionConfirmPopups
	fact: _flyViewSettings.enableAutomaticMissionConfirmPopups
	visible: _flyViewSettings.enableAutomaticMissionConfirmPopups.visible

[rubenp02]

Not sure how you want this, @DonLakeFlyer? I did it this way for consistency with the other settings.

[DonLakeFlyer]

There should be a property Fact at the root level if that specifci Fact ends up being referenced by more than one control. If only reference by a single control then it should be be defined in that control.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated no new comments.

[DonLakeFlyer]

I've been kinda heading towards the fact that QGC exposes way to many configurable settings to the user. It's just a massive set of stuff. I'm fine with the ability of the new setting to be controlled from a custom build which wants this off all the time. But I'm not sold and this setting being exposed to the user in regular QGC.

[DonLakeFlyer]

But I'm not sold and this setting being exposed to the user in regular QGC.

Happy to be convinced otherwise if there is a compelling reason.

[rubenp02]

I've been kinda heading towards the fact that QGC exposes way to many configurable settings to the user. It's just a massive set of stuff. I'm fine with the ability of the new setting to be controlled from a custom build which wants this off all the time. But I'm not sold and this setting being exposed to the user in regular QGC.

Mostly agree, the settings GUI is getting cluttered. That said, I don’t think there’s really such a thing as "too much user customization". I personally view the base QGC as the complete distribution that should include everything for every possible use case, and it's the forks and custom builds' job to tone that down.

One possible solution would be to offer "basic" and "advanced" modes for the app settings. Not the current "advanced mode", which is barely a thing in base QGC and is mostly used by custom builds to hide options (that one might be better named "full mode"). I’m thinking more of a simple, global dropdown in the app settings GUI that toggles the visibility of the more "weirdly specific" settings such as this.

Another solution would be to document how to manually edit the config. files to access settings that cannot be found in the GUI, so that at least there aren't features that are implemented but not available to the user at all. If something is only there to be taken advantage of by custom builds, it might as well be fully implemented in the custom build only.

In the meantime, or if you're not convinced, I'm happy to remove the GUI side of this PR.

[DonLakeFlyer]

One possible solution would be to offer "basic" and "advanced" modes for the app settings.

Ok, let me think about that a bit. For now this is fine then after the dual prop fixes.