mavlink
Add automatic mission start/resume popups setting
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:
- [x] Review Contribution Guidelines.
- [X] Review Code of Conduct.
- [X] 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.
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.
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.
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.
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.
I've changed my mind on this. Fine with the setting, but don't want to expose it in the ui. Also can you explain why you want/need this? Do you have some scenario where it's not valid. Want to understand if there is some usability problem here.
I've changed my mind on this. Fine with the setting, but don't want to expose it in the ui. Also can you explain why you want/need this? Do you have some scenario where it's not valid. Want to understand if there is some usability problem here.
This makes sense for a mission-centric operation, and admittedly some of our clients just fly missions in full Auto, but most take-off and fly on Cruise or Guided until its time to land. Since of course there's still a mission loaded (the landing sequence) this popup shows up despite being irrelevant for this use case, and the action to launch it is quite accessible anyway. It just felt pointless for most of our clients' use cases.
Since of course there's still a mission loaded (the landing sequence) this popup shows up despite being irrelevant for this use case
Hmm, ok. That's just a crappy experience then. I would say that should be fixed somehow for everyone. For a fixed wing, it should be pretty straightforward to know if the mission has no takeoff in it. And then in that case, don't start Start Mission. Would that cover your usage?
Since of course there's still a mission loaded (the landing sequence) this popup shows up despite being irrelevant for this use case
Hmm, ok. That's just a crappy experience then. I would say that should be fixed somehow for everyone. For a fixed wing, it should be pretty straightforward to know if the mission has no takeoff in it. And then in that case, don't start Start Mission. Would that cover your usage?
Would cover part of it but not all, because another common use case in my experience is to take off in a mission to navigate somewhere else, perform the manual operation (pausing the mission), then resuming the mission to come back. Right now the design sort of assumes that if you've "paused" the mission in any way (changing mode, clicking "Go here", using the Pause action) you're going to be resuming it right away, which more often than not isn't the case.
Right now the design sort of assumes that if you've "paused" the mission in any way (changing mode, clicking "Go here", using the Pause action) you're going to be resuming it right away, which more often than not isn't the case.
The I would say given that explanation, that is wrong as well. When you pause the Continue thing is crappy user experience as well for most users. Especially given it's trivial to go back into mission mode.
What I would say is only auto-pop start mission if there is a Takeoff (for FW/MR/VTOL). And then on a pause don't auto-pop anything. For folks that that get flight modes, Continue Mission should still be in the Actions button.
Another question: Is a problem with these popups also that the take up visual real estate from the map/video display when they are shown. Hence in the cases where they might not be quite correct, they are doubly annoying?
Another question: Is a problem with these popups also that the take up visual real estate from the map/video display when they are shown. Hence in the cases where they might not be quite correct, they are doubly annoying?
Not really, despite the fact that we use pretty small screens. IMO it's just the fact that it pops up. A common pattern in avionics displays is that stuff only pops up or changes on its own if something's wrong. Obviously this is an user facing app but I feel like it's still a valuable general philosophy.
A common pattern in avionics displays is that stuff only pops up or changes on its own if something's wrong.
Seems reasonable. But this pops up in response to a mission being uploaded. I get what you are saying, but if you take that to the extreme you end up with a interface which is harder to use for consumers with varying levels of experience.
I'll merge this once the conflicts are resolved
As is? Or should I remove the GUI code? Also, if you prefer some of the behavior changes you suggested I can easily add them.