Refactor Trajectory Tool as Docking Widget

[Joern Ungermann]

The Trajectory Tool has a rather complicated architecture as it ties into multiple views. Updating the Tool and the connected events consistently with appearing and disappearing Views is error-prone and causes in the failure case a crash of the application.

The tool is also inconsistent to the general usage pattern of opening Views and then "configuring" them using docking widgets. While the current Tool is more powerful and probably too big to be useful in the normal size for docking widgets, it will cause considerably less user-confusion as a docking widget, which can easily be "undocked" for an enlarged view.

Further, one might differentiate between a flight-track and a trajectory tool. While both use a common interface, and should use a common codebase, they are semantically different and add a lot of clutter to the Tree view. This would also allow some simplifications, as, for example, the top view can only plot lon/lat values, while only the TimeSeries accesses all the fine grained items.

[Marc R.]

I agree with splitting into flight-track and trajectory interfaces; this should be possible by having a parent class that implements the common functionality and then deriving for the two specific uses. I'm not sure about converting the trajectory functionality to dock widgets ... the power is that multiple views can be "fed" with the trajectory data, and if, e.g., a trajectory selection is changed all views are updated. That's why I originally put into the extra "Tools" menu, as the user interface is different from the dock widgets. I agree though that that could confuse a user; any ideas for how we could handle widgets that attach to multiple views in a more user-friendly way? Maybe allow for widgets where one instance can attach to multiple views and changes affect all attached views?

[Joern Ungermann]

I see the original intent behind it and the implementation is very nifty and powerful - once you figure out how to use it. However, I do not see that it is really needed. The major disadvantage would be the need to load in the trajectories multiple times - unless one somehow uses your idea of connecting the widgets/using a singleton. But maybe I still do not fully understand how it is properly used. One needs to manually add the selection for each view that it shall appear in. The thing that is automatically kept consistent across views are the lines styles/colours. Doing that manually will probably not be too bad if that leads to a more maintainable code with a GUI that is obvious how to use.

I'll prepare a draft for the change sometime in the future, starting with the NASA Ames flighttrack feature.

[Reimar Bauer]

the nasa ames file reader isn't yet refactored for py3

[Reimar Bauer]

we will remove the trajectory tool. It is since long time not maintained.