ArduPilot / ArduPilot/MissionPlanner
Mission Planner destroys the window it was invoked from
- Dominant language
- C#
- Stars
- 2.4k
- Forks
- 2.9k
- Avg merge
- 19h 16m
- Merged PRs (30d)
- 4
Description
#### Issue details
At startup, on my platform, Mission Planner typically destroys the window it was invoked from. I am running on a Win10 platform. If I start MP from a cmd window, MP starts (and brings up the logo'd MP window) and then destroys the cmd window and then brings up the MP screen users use. If I start MP from an Ubuntu window (this environment is also known as WSL, or Windows Subsystem for Linux), the terminal window Ubuntu provides *typically* dies in the same manner as the cmd window - right before the usable MP screen appears. I say "typically", because, well, sometimes, the Ubuntu terminal window does stick around and is therefore usable. If I start MP from a Cygwin window, all is OK (but the Cygwin environment lacks tools the Ubuntu environment has, which is why I prefer Ubuntu).
In any event, destroying another apps window seems wildly unfriendly and is, I believe, a bug.
A typescript.txt file is attached to this note; please ignore it. I thought it might be useful for this discussion, but I am wrong...the file continues to be generated even after the window disappears.
[typescript.txt](https://github.com/ArduPilot/MissionPlanner/files/2873481/typescript.txt)
#### Version
1.3.62.0
#### Platform
[ ] All
[ ] AntennaTracker
[ X] Copter
[ ] Plane
[ ] Rover
[ ] Sub
#### Airframe type
N/A as MP hasn't connected yet.
#### Hardware type
N/A as MP hasn't connected yet.
#### Logs
N/A
Contributor guide
No contributing guide indexed for this repository
Research direction
No source file, test, or entry point is named. Start by reproducing the startup behavior on Windows 10 from cmd, WSL Ubuntu, and Cygwin, then trace Mission Planner's launch and window lifecycle. Done means Mission Planner starts without closing the terminal or other window that invoked it.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp
- Domain
- desktop
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100