coderabbitai[bot]
commented
5 months ago Walkthrough
The updates primarily focus on managing OpenCV dependencies across various platforms and enhancing the SLEAP application's functionality. Changes include installing a specific version of opencv-contrib-python, updating the GUI for better session and camera management, and refining data handling and testing frameworks. The introduction of new classes and methods aims to streamline interactions and improve the user experience in navigating and manipulating video sessions and camera configurations.
Changes
| File Pattern | Change Summary |
|---|---|
.conda/* |
Added steps to uninstall all OpenCV packages and install opencv-contrib-python<4.7.0 using pip. |
.github/workflows/ci.yml |
Modified CI workflow to handle OpenCV versioning and renamed testing steps. |
dev_requirements.txt |
Explained the use of pytest-xvfb. |
docs/installation.md |
Documented installation hack for OpenCV with pip. |
environment*.yml |
Adjusted OpenCV handling and commented on imgaug dependency. |
requirements.txt |
Included sleap-anipose and OpenCV installation instructions. |
sleap/gui/*, sleap/io/* |
Enhanced GUI components and backend for session and camera management. Added new data models and methods. |
tests/* |
Expanded tests to cover new functionalities and configurations. |
🐇💻 In the code fields where bytes align, A rabbit hopped, leaving tracks so fine. With tweaks and hacks, it danced through lines, Now systems sync in perfect time. Celebrate the craft, so divine! 🎉🥕
Recent Review Details
**Configuration used: CodeRabbit UI**Commits
Files that changed from the base of the PR and between f0c44c0d3a406ee0ecc0d9a007bcfa88b074a0a9 and 1efb2ca5519cb14128f8e852d0fbfb871662cbbf.Files ignored due to path filters (8)
* `tests/data/videos/min_session_back.mp4` is excluded by `!**/*.mp4` * `tests/data/videos/min_session_backL.mp4` is excluded by `!**/*.mp4` * `tests/data/videos/min_session_mid.mp4` is excluded by `!**/*.mp4` * `tests/data/videos/min_session_midL.mp4` is excluded by `!**/*.mp4` * `tests/data/videos/min_session_side.mp4` is excluded by `!**/*.mp4` * `tests/data/videos/min_session_sideL.mp4` is excluded by `!**/*.mp4` * `tests/data/videos/min_session_top.mp4` is excluded by `!**/*.mp4` * `tests/data/videos/min_session_topL.mp4` is excluded by `!**/*.mp4`Files selected for processing (34)
* .conda/bld.bat (1 hunks) * .conda/build.sh (1 hunks) * .conda_mac/build.sh (1 hunks) * .github/workflows/ci.yml (2 hunks) * dev_requirements.txt (1 hunks) * docs/installation.md (1 hunks) * environment.yml (2 hunks) * environment_no_cuda.yml (1 hunks) * requirements.txt (1 hunks) * sleap/config/shortcuts.yaml (1 hunks) * sleap/gui/app.py (12 hunks) * sleap/gui/commands.py (12 hunks) * sleap/gui/dataviews.py (4 hunks) * sleap/gui/dropdown.py (1 hunks) * sleap/gui/shortcuts.py (1 hunks) * sleap/gui/widgets/docks.py (5 hunks) * sleap/gui/widgets/video.py (3 hunks) * sleap/instance.py (9 hunks) * sleap/io/cameras.py (1 hunks) * sleap/io/dataset.py (13 hunks) * sleap/io/format/hdf5.py (3 hunks) * sleap/io/format/labels_json.py (6 hunks) * sleap/io/video.py (2 hunks) * sleap/util.py (2 hunks) * tests/conftest.py (1 hunks) * tests/data/cameras/minimal_session/calibration.toml (1 hunks) * tests/fixtures/cameras.py (1 hunks) * tests/fixtures/datasets.py (1 hunks) * tests/gui/test_app.py (1 hunks) * tests/gui/test_commands.py (3 hunks) * tests/gui/test_dataviews.py (3 hunks) * tests/gui/widgets/test_docks.py (3 hunks) * tests/io/test_cameras.py (1 hunks) * tests/io/test_dataset.py (2 hunks)Additional Context Used
Learnings (1)
sleap/io/dataset.py (1)
``` User: roomrys" PR: talmolab/sleap#1654 File: sleap/io/dataset.py:1717-1725 Timestamp: 2024-03-15T23:59:34.765Z Learning: When removing a recording session using the `remove_recording_session` method in the `Labels` class, it's necessary to also update the `LabelsDataCache._session_by_video` dictionary to reflect the removal. This ensures that the mapping between videos and their corresponding recording sessions remains accurate. ```
Additional comments not posted (58)
dev_requirements.txt (1)
`6-6`: The comment explaining the use of `pytest-xvfb` is clear and informative.tests/conftest.py (1)
`14-14`: The addition of the `cameras` fixtures import is appropriate for setting up relevant test environments.tests/fixtures/cameras.py (1)
`1-20`: The camera fixtures are well-defined and structured, facilitating easy use in tests.sleap/config/shortcuts.yaml (1)
`19-22`: The added keyboard shortcuts for navigating views are clear and do not conflict with existing shortcuts.requirements.txt (2)
`9-9`: The addition of `sleap-anipose` to the requirements is appropriate for extending the project's functionality. --- `17-28`: The detailed instructions for handling OpenCV packages are clear and provide necessary steps for different operating systems.environment.yml (1)
`15-15`: Updated comment for `imgaug` clarifies dependency on `opencv-python`. Good for maintainability.sleap/gui/dropdown.py (1)
`50-50`: Ensure that the lambda function in the loop captures the variable `group` correctly. This is a common source of bugs in Python when using lambdas in loops.tests/data/cameras/minimal_session/calibration.toml (1)
`1-64`: The calibration data for cameras is well-structured and follows the TOML format correctly..github/workflows/ci.yml (1)
`112-112`: Renaming the test step to "Test with pytest" improves clarity and is consistent with common naming conventions.sleap/gui/shortcuts.py (1)
`44-45`: Added shortcuts for navigating to the next and previous views. This enhances user navigation capabilities within the application.tests/gui/test_dataviews.py (1)
`73-98`: Added new test functions for sessions and camera tables. These tests are well-implemented and cover important functionalities.tests/fixtures/datasets.py (1)
`276-280`: Added a new fixture for loading labels from a file for a minimal session. This fixture is correctly implemented and uses appropriate video search criteria.tests/gui/widgets/test_docks.py (5)
`115-123`: LGTM! The test for `SessionsDock` correctly initializes the dock and verifies its properties. --- `125-171`: LGTM! The test for the camera table in `SessionsDock` correctly handles the display and interaction with camera data. --- `174-193`: LGTM! The test for the session table in `SessionsDock` correctly handles the display and interaction with session data. --- `194-236`: LGTM! The test for the unlinked videos table in `SessionsDock` correctly handles the display and interaction with unlinked video data. --- `237-251`: LGTM! The test for handling multiple unlinked videos in `SessionsDock` correctly handles the display and interaction with multiple unlinked video data.sleap/io/format/hdf5.py (2)
`88-88`: Adding "sessions" to the list of keys processed in `read_headers` is a good enhancement for handling additional data types. Ensure that the corresponding handling for "sessions" is implemented wherever necessary to maintain data integrity. --- `328-328`: The addition of "sessions" to the metadata handling in the `write` method is consistent with the changes in the `read_headers` method. This ensures symmetry in read and write operations, which is crucial for data integrity.sleap/io/format/labels_json.py (5)
`10-10`: Ensure the `logging` module is utilized appropriately throughout the file.Verification successful
--- The output from the executed script shows that the `logging` module is indeed used in the `labels_json.py` file, specifically with two `warning` level logs. These logs are used to indicate an error while loading `RecordingSession` objects and to log the exception itself. This suggests that the `logging` module is being utilized to handle potential errors in the file, which aligns with the typical use of logging for error reporting and diagnostics. Given this information, it appears that the `logging` module is used appropriately in the context of error handling within the `labels_json.py` file. There is no indication of misuse or inappropriate logging levels based on the provided output. Based on the findings: - The logging statements are present and used for error handling. - The use of `warning` level is appropriate for the context described. Therefore, I conclude that the logging usage in `labels_json.py` is appropriate as per the review comment.--- `20-20`: Import of `RecordingSession` is correctly added to support new functionality. --- `36-36`: Initialization of logger is appropriate for module-level logging. --- `506-515`: Proper error handling and logging for `RecordingSession` loading. Ensure that the sessions are correctly utilized downstream.Scripts Executed
The following scripts were executed for the analysis: --- Script: ```shell #!/bin/bash # Search for logging statements in the file to ensure proper usage. rg --type py 'logger\.(debug|info|warning|error|critical)' sleap/io/format/labels_json.py ``` Length of output: 192Verification successful
Based on the search results, the `sessions` variable is actively used in the `labels_json.py` file where it is defined and manipulated. It is also referenced in the `hdf5.py` file, indicating that it is part of a broader data structure that is iterated over. This suggests that the variable is indeed utilized downstream in the application. To ensure a thorough verification, it would be beneficial to examine how `sessions` is specifically handled in the `hdf5.py` file. This will help confirm if its usage aligns with the expectations set in the review comment. --- The analysis of the `sessions` usage in `hdf5.py` reveals that it is actively managed both in terms of loading from and saving to an HDF5 file. This includes processing the data into a suitable format for storage and retrieving it for use within the application. These operations suggest that `sessions` is not only loaded but also utilized effectively downstream, which aligns with the expectations set in the review comment regarding its proper handling and utilization. Given this information, it can be concluded that the handling of `sessions` in the application is appropriate and aligns with good practices as initially reviewed.--- `542-550`: > :memo: **NOTE** > This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [546-559] Registration of `RecordingSession` in `cattr` structure hook is correctly implemented. Ensure that the `sessions` list is correctly handled in the application.Scripts Executed
The following scripts were executed for the analysis: --- Script: ```shell #!/bin/bash # Verify that sessions are used appropriately in other parts of the application. rg --type py 'sessions' sleap/io/format/ ``` Length of output: 726 --- --- Script: ```shell #!/bin/bash # Examine the usage of 'sessions' in hdf5.py to ensure it aligns with expected practices. rg --type py 'sessions' sleap/io/format/hdf5.py -C 10 ``` Length of output: 1895Verification successful
--- The review comment regarding the registration of `RecordingSession` in the `cattr` structure hook and the handling of the `sessions` list in the application appears to be correct. The `sessions` list is structured from a dictionary, used in a lambda for a structure hook, and included in the return of a `Labels` object in `labels_json.py`. Additionally, it is referenced in `hdf5.py`, indicating its integration and usage in the application. This suggests that the `sessions` list is handled appropriately across the relevant parts of the codebase.Scripts Executed
The following scripts were executed for the analysis: --- Script: ```shell #!/bin/bash # Check for correct handling of sessions list in the application. rg --type py 'sessions' sleap/io/format/ ``` Length of output: 726sleap/gui/dataviews.py (3)
`33-33`: Import of `RecordingSession` is correctly added to support new functionality. --- `389-397`: The `SessionsTableModel` class is correctly implemented with appropriate methods for handling session data. --- `669-684`: The `CamerasTableModel` class is correctly implemented for managing cameras within a `RecordingSession`.sleap/gui/widgets/docks.py (5)
`592-592`: Consider implementing the triangulation options as a separate method or class to encapsulate functionality. This would improve modularity and maintainability by separating concerns. --- `614-614`: Ensure proper error handling for the `unlink_video_from_camera` command.Verification successful
--- The provided script output contains the entire content of the `commands.py` file, which includes the implementation of the `unlink_video_from_camera` method within the `CommandContext` class. Here's the relevant excerpt from the output: ```python def unlink_video_from_camera(self): """Unlinks video from a camera""" self.execute(UnlinkVideo) ``` This method is designed to execute the `UnlinkVideo` command. The `UnlinkVideo` command itself is defined as follows: ```python class UnlinkVideo(EditCommand): topics = [UpdateTopic.sessions] @staticmethod def do_action(context: CommandContext, params: dict): camcorder = context.state["selected_camera"] recording_session = context.state["selected_session"] video = camcorder.get_video(recording_session) if video is not None and recording_session is not None: recording_session.remove_video(video) # Reset the selected camera context.state["selected_camera"] = None ``` From this implementation, it is clear that the `UnlinkVideo` command handles the unlinking of a video from a camera by accessing the `selected_camera` and `selected_session` from the command context's state, retrieving the video associated with the camera and session, and then removing the video from the session if it exists. After the operation, it resets the `selected_camera` state to `None`. This method does include basic error handling by checking if both the video and the recording session are not `None` before attempting to remove the video. However, it does not explicitly handle or log errors that might occur during the execution of `remove_video` or other operations within the method. Given this information, the original review comment about ensuring proper error handling seems to be addressed to some extent, but could potentially be improved by adding more comprehensive error handling and logging mechanisms.--- `626-626`: Consider adding tooltips or help text for the "Link Video" button to enhance user understanding. This can improve user experience by providing additional context on what the button does. --- `636-636`: Validate the correctness of the model creation logic in `create_models`.Scripts Executed
The following scripts were executed for the analysis: --- Script: ```shell #!/bin/bash # Search for error handling in the unlink_video_from_camera command implementation. rg --type python 'def unlink_video_from_camera' --exec cat {} ``` Length of output: 474 --- --- Script: ```shell #!/bin/bash # Search for error handling in the unlink_video_from_camera command implementation. rg --type python 'def unlink_video_from_camera' | xargs cat ``` Length of output: 92 --- --- Script: ```shell #!/bin/bash # Search for error handling in the unlink_video_from_camera command implementation. rg 'def unlink_video_from_camera' | xargs cat ``` Length of output: 206 --- --- Script: ```shell #!/bin/bash # Search for error handling in the unlink_video_from_camera command implementation. rg 'def unlink_video_from_camera' --files-with-matches | xargs cat ``` Length of output: 137304Verification successful
--- The search results from the `rg` command show multiple definitions of the `create_models` method within the `sleap/gui/widgets/docks.py` file. Each definition of `create_models` returns a different type of model, which is consistent with the method being implemented in various subclasses, each tailored to handle specific data types or structures: 1. Returns `GenericTableModel`. 2. Returns `VideosTableModel`. 3. Returns `GenericTableModel` again, but in a different context. 4. Returns `SuggestionsTableModel`. 5. Returns `LabeledFrameTableModel`. 6. Returns a union of `GenericTableModel` and `Dict[str, GenericTableModel]`. This variety in return types across different implementations of `create_models` suggests that the method is designed to be flexible and adaptable to the needs of different parts of the application, each requiring a specific model type for its functionality. Given this information, the model creation logic in `create_models` appears to be correctly implemented, with each subclass defining its own specific logic to create and return the appropriate model type based on its context. This aligns with typical object-oriented practices where subclasses override a method to provide specialized behavior. Based on the evidence provided by the script output, the implementation of `create_models` across different parts of the application is consistent with the principles of polymorphism and method overriding in object-oriented programming.--- `655-655`: Review the logic for creating tables to ensure it handles all edge cases.Scripts Executed
The following scripts were executed for the analysis: --- Script: ```shell #!/bin/bash # Check for consistency in model creation across different parts of the application. rg --type python 'create_models' --exec cat {} ``` Length of output: 457 --- --- Script: ```shell #!/bin/bash # Correctly search for occurrences of 'create_models' in Python files and display their content rg --type python 'def create_models' -C 3 ``` Length of output: 74 --- --- Script: ```shell #!/bin/bash # Correctly search for occurrences of 'create_models' in Python files and display their content, without specifying an incorrect file type rg 'def create_models' -C 3 --glob '*.py' ``` Length of output: 2730Verification successful
--- The search results from the `rg` command have provided multiple instances of the `create_tables` method within the `sleap/gui/widgets/docks.py` file. Each instance shows a slightly different implementation, tailored to the specific needs of the subclass in which it is defined. The method generally involves creating a `GenericTableView` and configuring it based on the state and model provided by the main window. This is consistent across different uses within the file, suggesting that the method's implementation is adapted to handle various cases as needed by different parts of the application. Given this information, it appears that the method `create_tables` is implemented with consideration for different scenarios and requirements, which likely covers various edge cases as needed by each subclass. Therefore, the implementation seems to be consistent and appropriately handles edge cases as per the different contexts in which it is used.Scripts Executed
The following scripts were executed for the analysis: --- Script: ```shell #!/bin/bash # Search for similar table creation logic in other parts of the application for consistency. rg --type python 'create_tables' --exec cat {} ``` Length of output: 457 --- --- Script: ```shell #!/bin/bash # Search for similar table creation logic in other parts of the application for consistency. rg --type python 'def create_tables' -C 10 ``` Length of output: 75 --- --- Script: ```shell #!/bin/bash # Search for similar table creation logic in other parts of the application for consistency. rg 'def create_tables' -C 10 ``` Length of output: 7532tests/gui/test_commands.py (1)
`10-21`: Ensure that the new imports `AddSession` and `TriangulateSession` are utilized appropriately in the test functions. It's good practice to keep imports organized and only include those that are used.Verification successful
It appears that the `rg` command failed due to an unrecognized file type specification for Python. To accurately verify whether `AddSession` and `TriangulateSession` are utilized in the `tests/gui/test_commands.py` file, I will need to rerun the search without specifying the file type. --- The search results confirm that both `AddSession` and `TriangulateSession` are utilized in the `tests/gui/test_commands.py` file. The functions `AddSession.do_action` and various methods from `TriangulateSession` such as `get_all_views_at_frame`, `get_instances_across_views`, `calculate_reprojected_points`, `do_action`, and others are actively used in test functions within the file. This indicates that the imports are indeed utilized appropriately in the test functions.Scripts Executed
The following scripts were executed for the analysis: --- Script: ```shell #!/bin/bash # Verify that AddSession and TriangulateSession are used in the file rg --type python 'AddSession|TriangulateSession' tests/gui/test_commands.py ``` Length of output: 108 --- --- Script: ```shell #!/bin/bash # Verify that AddSession and TriangulateSession are used in the file rg 'AddSession|TriangulateSession' tests/gui/test_commands.py ``` Length of output: 1847sleap/io/video.py (1)
`15-15`: The import statement for `Text` from `typing` has been removed. Ensure that there are no references to `Text` in this file to avoid runtime errors.Verification successful
--- The corrected script successfully executed and searched for any occurrences of the term `Text` in the file `sleap/io/video.py`. The script did not produce any output, indicating that there are no references to `Text` in the file. This confirms that the removal of the import statement for `Text` from the `typing` module does not affect the rest of the code in this file, as there are no undeclared references left behind. Based on this information, the removal of the `Text` import is verified to be safe, and there are no runtime errors expected from this specific change.Scripts Executed
The following scripts were executed for the analysis: --- Script: ```shell #!/bin/bash # Search for any usage of `Text` in the current file. rg --type python 'Text' sleap/io/video.py ``` Length of output: 72 --- --- Script: ```shell #!/bin/bash # Corrected search for any usage of `Text` in the current file. rg 'Text' sleap/io/video.py ``` Length of output: 27sleap/gui/app.py (6)
`74-74`: Added `SessionsDock` to the GUI. Ensure that this dock is properly integrated and tested, especially in contexts where multiple sessions might be managed simultaneously. --- `147-147`: Initialization of new GUI state for session management. Verify that all necessary states are initialized here to avoid null reference issues. --- `479-484`: Added menu item for creating new recording sessions. Ensure that the command linked to this menu item (`self.commands.addSession`) is fully implemented and handles all edge cases. --- `1185-1188`: Handling updates for session-related data. Ensure that the sessions table is correctly updated without any performance issues, especially with a large number of sessions. --- `1256-1259`: Method to update the unlinked videos model. Ensure that this method is called at appropriate times to keep the GUI state consistent with the backend data.Verification successful
The verification script aimed to find occurrences of the `update_unlinked_videos_model()` method being called within the codebase. The absence of any results from the `ast-grep` command suggests that there are no explicit calls to this method in the codebase. This could imply that the method is not being used to update the GUI state consistently with the backend data, or it might be invoked in a way not captured by the search pattern used. Given the importance of ensuring that the GUI state remains consistent with the backend, and the current results do not confirm that the method is called appropriately, it is prudent to perform a more thorough search. This could involve checking for indirect method invocations or event-driven updates that might not directly call `update_unlinked_videos_model()` but still trigger its execution. --- The additional verification scripts have provided useful insights into how the `update_unlinked_videos_model()` method is utilized within the codebase. The `rg` command output reveals two key points: 1. The method `update_unlinked_videos_model()` is called conditionally within the `app.py` file when certain topics are updated (`_has_topic([UpdateTopic.sessions])`). This suggests that the method is part of a conditional flow that likely responds to specific changes or events in the application, ensuring that the GUI is updated accordingly. 2. The method is also connected to the `selected_session` state change in `widgets/docks.py`. This connection indicates that the method is triggered when the session selection changes, which is a typical scenario where the GUI would need to refresh data displayed to the user. These findings confirm that the method is integrated into event-driven updates, which are crucial for maintaining consistency between the GUI and the backend data. The method is not called arbitrarily but is linked to specific application states and events that would necessitate an update to the unlinked videos model. Given this context, the method appears to be used appropriately within the application's architecture to ensure GUI consistency with backend data changes. Therefore, the initial concern about the method's invocation is addressed by these findings.--- `1260-1263`: Method to update the cameras model. This is crucial for maintaining accurate display of camera data in the GUI. Verify that the data flow is correct and that there are no synchronization issues.Scripts Executed
The following scripts were executed for the analysis: --- Script: ```shell #!/bin/bash # Check for all calls to update_unlinked_videos_model to ensure it's being updated consistently. ast-grep --lang python --pattern $'update_unlinked_videos_model()' ``` Length of output: 67 --- --- Script: ```shell #!/bin/bash # Search for any indirect references or bindings to update_unlinked_videos_model that might not be direct method calls ast-grep --lang python --pattern $'def $$$ { $$$ update_unlinked_videos_model() $$$ }' # Additionally, check for any event bindings or similar mechanisms that might trigger this method rg "update_unlinked_videos_model" -C 3 ``` Length of output: 1366Verification successful
The script executed to find direct calls to the `update_cameras_model()` method did not return any results. This could indicate that the method is not being called directly in the codebase, which raises concerns about whether it is properly integrated and triggered in the application workflow. To ensure a thorough verification, it would be prudent to expand the search to include indirect triggers or references that might lead to the execution of this method. This can involve looking for event handlers or other mechanisms that might invoke this method indirectly. --- The method `update_cameras_model` is appropriately integrated into the application's workflow. It is triggered indirectly through a state connection with `selected_session` in `sleap/gui/widgets/docks.py` and directly in response to certain topic updates in `sleap/gui/app.py`. This setup ensures that the camera model is updated consistently with changes in the session state, addressing the initial concerns about data flow and synchronization.Scripts Executed
The following scripts were executed for the analysis: --- Script: ```shell #!/bin/bash # Check for all calls to update_cameras_model to ensure it's being updated consistently. ast-grep --lang python --pattern $'update_cameras_model()' ``` Length of output: 59 --- --- Script: ```shell #!/bin/bash # Search for any indirect references or triggers for update_cameras_model rg "update_cameras_model" -C 3 ``` Length of output: 1287sleap/instance.py (2)
`34-34`: Logger initialized correctly. --- `721-737`: The method `update_points` efficiently updates instance points based on the provided numpy array, respecting the `exclude_complete` flag.sleap/io/dataset.py (8)
`154-163`: LGTM! The method `add_recording_session` correctly updates the cache with new sessions. --- `164-173`: LGTM! The method `add_video_to_session` is implemented correctly. --- `174-185`: LGTM! The method `update_linkage_of_videos` correctly updates the linkage of videos based on their session associations. --- `1685-1699`: LGTM! The method `add_session` correctly checks the session type before adding it to the labels. --- `1701-1715`: LGTM! The method `update_session` correctly updates the session and video linkage in the cache. --- `1717-1726`: LGTM! The method `get_session` correctly retrieves the session associated with a video. --- `1728-1740`: LGTM! The method `remove_session_video` correctly removes a video from a session and updates the cache. --- `1741-1749`: LGTM! The method `remove_recording_session` correctly checks if the session is in the labels before removing it.sleap/gui/commands.py (7)
`44-44`: Ensure that the new imports `triangulate` and `reproject` from `sleap_anipose` are used appropriately in the code. --- `56-56`: Ensure that the new imports `Camcorder` and `RecordingSession` from `sleap.io.cameras` are used appropriately in the code. --- `85-85`: The addition of the `sessions` topic to the `UpdateTopic` enum suggests that new functionality related to session management has been introduced. Verify that this new topic is used correctly in the relevant command methods. --- `414-421`: The methods `nextView` and `prevView` have been added to navigate between different views. Ensure that these methods are connected to the appropriate GUI elements and that they function as expected. --- `444-455`: The methods `addSession`, `removeSelectedSession`, and `linkVideoToSession` have been added for managing sessions. Ensure that these methods are integrated correctly with the rest of the session management functionality and that they update the GUI state appropriately. --- `633-650`: The method `triangulateSession` has been added to handle the triangulation of instances within a session. This is a complex method that likely interacts with multiple components of the system. Verify that it is implemented correctly and integrates well with the existing system architecture. --- `667-670`: The method `unlink_video_from_camera` has been added. Ensure that it correctly handles the unlinking of videos from cameras within the system and updates the GUI state appropriately.
roomrys
Added a file called dropdown.py where an instance is set to an instance group. Added a new CommandContext class to show the context in which commands are executed Updated the Commands class to use a dictionary that simulates the assignment of instances to groups (for now) Added hotkeys for easier use. GUI trigger commands through the CommandContext Used lambda function within the loop to ensure that the correct group is assigned when the action is triggered.
Summary by CodeRabbit
New Features
opencv-contrib-python<4.7.0) across various environments for improved compatibility.SessionsDockfor managing recording sessions and camera links.Bug Fixes
Documentation
Tests