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.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add
CamerasTable
toSessionsDock
#1671Add
CamerasTable
toSessionsDock
#1671Changes from 10 commits
d681075
33c4bcb
d482bb4
7f74a8b
3bb071f
e24edc9
88cd019
a728dd4
f1b6b1b
548caf5
33d2754
f414abb
dd3daae
45974e3
4f40b6e
47dfe95
20d3e60
ba0f556
c493fd6
907f873
c287df2
45efdab
cd8662e
25e848c
236d044
4ecbb95
77283d0
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The method
create_models
returns a dictionary instead of aGenericTableModel
instance. This does not align with the expected return type for model creation methods in dock widgets. Ensure consistency in return types across the application.Committable suggestion
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like your idea of using a dictionary to describe the models that are returned. Let's just update the typehinting:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@roomrys: Acknowledged. Updating the type hinting as suggested introduces flexibility in handling multiple models within dock widgets, which can be particularly useful for complex interfaces. It's important to ensure that other parts of the application that interact with these models are compatible with this approach. This includes reviewing methods like
create_tables
and any other functionality that relies on the output ofcreate_models
to handle both a single model and a dictionary of models seamlessly. Additionally, documentation and possibly some internal logic may need updates to align with this change. If you've considered these aspects and are comfortable with the implications, this update can enhance the application's architecture by accommodating more complex data management scenarios.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The method
create_tables
returns a dictionary instead of aGenericTableView
instance, which is inconsistent with the expected return type for table creation methods in dock widgets. Adjust to return the table directly.Committable suggestion
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do like how you used this in the
_on_data_update
callback... could you at least update the type hinting for the return on this function:There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@roomrys: Absolutely, updating the type hinting for the
create_tables
method to accurately reflect its return type asGenericTableView
makes perfect sense, especially given its usage in the_on_data_update
callback. This will enhance code readability and maintainability. Thank you for pointing this out!There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The test
test_camera_table
uses a hardcoded value forrowCount()
assertion, which might lead to test fragility if the test data changes. Consider deriving the expected row count directly from the test data to make the test more robust.Committable suggestion
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The loop for verifying removed camcorders iterates over the original number of rows minus 3, assuming specific camcorders are removed. This approach is fragile and may not accurately reflect the GUI's state after removals. Ensure the test dynamically adjusts based on the actual state of the GUI and the session object.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this is testing what you think it is testing (that cameras are removed from table) as the table model is not automatically updated if we just use API calls. Since we are just testing the Table (without the entire SessionsDock - which has the
UnlinkVideo
button), we can just do the data update ourselves with:Also! I would like a test that all the
Camcorder
s in theRecordingSession
are displayed (regardless of linkedVideo
), but only linkedVideo
s have a path displayed - otherwise just an empty string for theVideo
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lint with
black test/gui/test_dataview/py
or set-up black to formatOnSave in vscodeThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The tests for
SessionsDock
do not verify the GUI's response to the unlink video action, such as checking if the UI correctly disables/enables buttons based on the state. Ensure tests cover the full range of expected GUI behavior to provide comprehensive coverage.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed on adding a check that the unlink video button is properly disabled.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@roomrys: To add a check for the "unlink video" button being properly disabled, you'll want to extend the
test_sessions_dock
function with assertions that verify the button's enabled state at key points in your test flow. Here's a general approach:main_window.sessions_dock.camera_table.selectRow(i)
), assert that the "unlink video" button becomes enabled.You can access the button's enabled state using a property or method specific to the GUI framework you're using. For example, if using PyQt or PySide, you might check the button's
isEnabled()
method. Here's a simplified example:Make sure to adjust the example to fit your application's structure and the way you access UI elements. This will ensure your tests accurately reflect the intended user interactions and UI behavior.