show species we can show by linearview in tableview - #3177
Open
JanEisermann wants to merge 9 commits into
Open
Conversation
Prepares the table view for showing the exact data values at a waypoint. The values of a linear section are computed for interpolated points along the flight path, of which only a few coincide with a waypoint; values_at_waypoints() picks those, linear_data_columns() turns the WMS responses of the linear view into columns. The values are stored on the Waypoint objects, so that they stay at their waypoint when waypoints are inserted or deleted, and appended as read only columns behind the columns of TABLE_FULL. They are hidden until set_linear_data_visible(True) is called, hence the table view looks unchanged for now. Changes of the data are announced with the new linearDataChanged signal instead of dataChanged, as the data is not part of the flight plan: dataChanged triggers a redraw of the flight path (and thus a new WMS request) and an update of an MSColab operation. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Every plot of a linear section stores its values at the waypoints of the flight track, from where the table view can show them. Closing the linear view drops them again, as it is the source of these values. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The checkbox appends one column per layer plotted in the linear view of the same flight track, giving the exact value at each waypoint, e.g. the mole fraction of ozone. Waypoints for which the server has no data, e.g. because the aircraft is on the ground, stay empty. qt5/ui_tableview_window.py was regenerated with pyuic5 5.15.11. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Member
|
multiple selection is also working, nice 
|
ReimarBauer
requested changes
Sep 3, 2026
Activating another flight track hid the data columns of the linear view, even though the linear view had already stored its values for the new track: setFlightTrackModel() pushed the visibility flag of the new flight track into the checkbox, and that flag is off for a track that has not shown the columns yet. The flag has to live on the flight track, as the number of columns depends on it, but the checkbox is the wish of the user for this window. It therefore keeps its state now and is applied to the newly displayed flight track. Only the flight track the window starts with is adopted the other way around, so that a second table view of the same track does not switch its columns off. The change signals of the flight track that is not displayed any more are disconnected as well, they piled up with every switch. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The checkbox has no effect as long as no linear view provides data values for the active flight track, so disable and untick it in that case. The wish of the user is kept in show_linear_data_wanted, hence the columns come back on their own once the linear view has data for the flight track, which it retrieves asynchronously after a track switch. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The values of the flight track that is not plotted here any more were left on its model, so the table view showed them as if they belonged to the current plot -- even after this view was closed, as clearing on close only reaches the active flight track. Drop them on the switch instead. The WMS control also has to know the new flight track before the redraw in the base class asks it for a plot: that request is built from its waypoints model and described the previous track so far. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Purpose of PR?:
Fixes #2876
Does this PR introduce a breaking change?
If the changes in this PR are manually verified, list down the scenarios covered::
tests succeed
manually verified: -grey "show data" checkbox" and uncheck it if linear view has no data (since commit 6220b56)
-data is updated in tableview if the data changed in an other view (since commit b25b38b)
Additional information for reviewer? :
Mention if this PR is part of any design or a continuation of previous PRs
Does this PR results in some Documentation changes?
If yes, include the list of Documentation changes
Checklist:
<type>: <subject>with support by Claude