GUI - List item selection not working in Definitions Editor #66

New Issue

Rusfort · 2025-05-13T13:06:45+02:00

Rusfort commented

2025-05-13 13:06:45 +02:00

Affected File: gui/definitions_editor_dialog.py

Problem Description:
User mouse clicks on items within the QListWidget instances (for Asset Types, File Types, and Suppliers) in the Definitions Editor dialog do not trigger item selection or the currentItemChanged signal. The first item is selected by default and its details are displayed correctly. Programmatic selection of items (e.g., via a diagnostic button) does correctly trigger the currentItemChanged signal and updates the UI detail views. The issue is specific to user-initiated mouse clicks for selection after the initial load.

Debugging Steps Taken & Findings:

Initial Analysis:
- Reviewed GUI internals documentation (Documentation/02_Developer_Guide/06_GUI_Internals.md) and gui/definitions_editor_dialog.py source code.
- Confirmed signal connections (currentItemChanged to display slots) are made.
Logging in Display Slots (_display_*_details):
- Added logging to display slots. Confirmed they are called for the initial (default) item selection.
- No further calls to these slots occur on user clicks, indicating currentItemChanged is not firing.
Color Swatch Palette Role:
- Investigated and corrected QPalette.ColorRole for color swatches (reverted from Background to Window). This fixed an AttributeError but did not resolve the selection issue.
Robust Error Handling in Display Slots:
- Wrapped display slot logic in try...finally blocks with detailed logging. Confirmed slots complete without error for initial selection and signals for detail widgets are reconnected.
Diagnostic Lambda for currentItemChanged:
- Added a lambda logger to currentItemChanged alongside the main display slot.
- Confirmed both lambda and display slot fire for initial programmatic selection.
- Neither fires for subsequent user clicks. This proved the QListWidget itself was not emitting the signal.
Explicit setEnabled and setSelectionMode on QListWidget:
- Explicitly set these properties. No change in behavior.
Explicit setEnabled and setFocusPolicy(Qt.ClickFocus) on tab_page (parent of QListWidget layout):
- This change allowed programmatic selection via a diagnostic button to correctly fire currentItemChanged and update the UI.
- However, user mouse clicks still did not work and did not fire the signal.
Event Filter Investigation:
- Filter on QListWidget: Did NOT receive mouse press/release events from user clicks.
- Filter on tab_page (parent of QListWidget's layout): Did NOT receive mouse press/release events.
- Filter on self.tab_widget (QTabWidget): DID receive mouse press/release events.
- Modified self.tab_widget's event filter to return False for events over the current page, attempting to ensure propagation.
- Result: With the modified tab_widget filter, an event filter re-added to asset_type_list_widget did start receiving mouse press/release events. However, asset_type_list_widget still did not emit currentItemChanged from these user clicks.
DebugListWidget (Subclassing QListWidget):
- Created DebugListWidget overriding mousePressEvent with logging.
- Used DebugListWidget for asset_type_list_widget.
- Initial user report indicated that DebugListWidget.mousePressEvent logs were NOT appearing for user clicks. This means that even with the QTabWidget event filter attempting to propagate events, and the asset_type_list_widget's filter (from step 8) confirming it received them, the mousePressEvent of the QListWidget itself was not being triggered by those propagated events. This is the current mystery.

Current Status:

Programmatic selection works and fires signals.
User clicks are received by an event filter on asset_type_list_widget (after QTabWidget filter modification) but do not result in mousePressEvent being called on the QListWidget (or DebugListWidget) itself, and thus no currentItemChanged signal is emitted.
The issue seems to be a very low-level event processing problem specifically for user mouse clicks within the QListWidget instances when they are children of the QTabWidget pages, even when events appear to reach the list widget via an event filter.

Next Steps (When Resuming):

Re-verify the logs from the DebugListWidget.mousePressEvent test. If it's truly not being called despite its event filter seeing events, this is extremely unusual.
Simplify the _create_tab_pane method drastically for one tab:
- Remove the right-hand pane.
- Add the DebugListWidget directly to the tab_page's layout without the intermediate left_pane_layout.
Consider if any styles applied to QListWidget or its parents via stylesheets could be interfering with hit testing or event processing (unlikely for this specific symptom, but possible).
Explore alternative ways to populate/manage the QListWidget or its items if a subtle corruption is occurring.
If all else fails, consider replacing the QListWidget with a QListView and a QStringListModel as a more fundamental change to see if the issue is specific to QListWidget in this context.

**Affected File:** [`gui/definitions_editor_dialog.py`](gui/definitions_editor_dialog.py) **Problem Description:** User mouse clicks on items within the `QListWidget` instances (for Asset Types, File Types, and Suppliers) in the Definitions Editor dialog do not trigger item selection or the `currentItemChanged` signal. The first item is selected by default and its details are displayed correctly. Programmatic selection of items (e.g., via a diagnostic button) *does* correctly trigger the `currentItemChanged` signal and updates the UI detail views. The issue is specific to user-initiated mouse clicks for selection after the initial load. **Debugging Steps Taken & Findings:** 1. **Initial Analysis:** * Reviewed GUI internals documentation ([`Documentation/02_Developer_Guide/06_GUI_Internals.md`](Documentation/02_Developer_Guide/06_GUI_Internals.md)) and [`gui/definitions_editor_dialog.py`](gui/definitions_editor_dialog.py) source code. * Confirmed signal connections (`currentItemChanged` to display slots) are made. 2. **Logging in Display Slots (`_display_*_details`):** * Added logging to display slots. Confirmed they are called for the initial (default) item selection. * No further calls to these slots occur on user clicks, indicating `currentItemChanged` is not firing. 3. **Color Swatch Palette Role:** * Investigated and corrected `QPalette.ColorRole` for color swatches (reverted from `Background` to `Window`). This fixed an `AttributeError` but did not resolve the selection issue. 4. **Robust Error Handling in Display Slots:** * Wrapped display slot logic in `try...finally` blocks with detailed logging. Confirmed slots complete without error for initial selection and signals for detail widgets are reconnected. 5. **Diagnostic Lambda for `currentItemChanged`:** * Added a lambda logger to `currentItemChanged` alongside the main display slot. * Confirmed both lambda and display slot fire for initial programmatic selection. * Neither fires for subsequent user clicks. This proved the `QListWidget` itself was not emitting the signal. 6. **Explicit `setEnabled` and `setSelectionMode` on `QListWidget`:** * Explicitly set these properties. No change in behavior. 7. **Explicit `setEnabled` and `setFocusPolicy(Qt.ClickFocus)` on `tab_page` (parent of `QListWidget` layout):** * This change **allowed programmatic selection via a diagnostic button to correctly fire `currentItemChanged` and update the UI**. * However, user mouse clicks still did not work and did not fire the signal. 8. **Event Filter Investigation:** * **Filter on `QListWidget`:** Did NOT receive mouse press/release events from user clicks. * **Filter on `tab_page` (parent of `QListWidget`'s layout):** Did NOT receive mouse press/release events. * **Filter on `self.tab_widget` (QTabWidget):** DID receive mouse press/release events. * Modified `self.tab_widget`'s event filter to return `False` for events over the current page, attempting to ensure propagation. * **Result:** With the modified `tab_widget` filter, an event filter re-added to `asset_type_list_widget` *did* start receiving mouse press/release events. **However, `asset_type_list_widget` still did not emit `currentItemChanged` from these user clicks.** 9. **`DebugListWidget` (Subclassing `QListWidget`):** * Created `DebugListWidget` overriding `mousePressEvent` with logging. * Used `DebugListWidget` for `asset_type_list_widget`. * **Initial user report indicated that `DebugListWidget.mousePressEvent` logs were NOT appearing for user clicks.** This means that even with the `QTabWidget` event filter attempting to propagate events, and the `asset_type_list_widget`'s filter (from step 8) confirming it received them, the `mousePressEvent` of the `QListWidget` itself was not being triggered by those propagated events. This is the current mystery. **Current Status:** - Programmatic selection works and fires signals. - User clicks are received by an event filter on `asset_type_list_widget` (after `QTabWidget` filter modification) but do not result in `mousePressEvent` being called on the `QListWidget` (or `DebugListWidget`) itself, and thus no `currentItemChanged` signal is emitted. - The issue seems to be a very low-level event processing problem specifically for user mouse clicks within the `QListWidget` instances when they are children of the `QTabWidget` pages, even when events appear to reach the list widget via an event filter. **Next Steps (When Resuming):** 1. Re-verify the logs from the `DebugListWidget.mousePressEvent` test. If it's truly not being called despite its event filter seeing events, this is extremely unusual. 2. Simplify the `_create_tab_pane` method drastically for one tab: * Remove the right-hand pane. * Add the `DebugListWidget` directly to the `tab_page`'s layout without the intermediate `left_pane_layout`. 3. Consider if any styles applied to `QListWidget` or its parents via stylesheets could be interfering with hit testing or event processing (unlikely for this specific symptom, but possible). 4. Explore alternative ways to populate/manage the `QListWidget` or its items if a subtle corruption is occurring. 5. If all else fails, consider replacing the `QListWidget` with a `QListView` and a `QStringListModel` as a more fundamental change to see if the issue is specific to `QListWidget` in this context.

Rusfort added the

bug

label 2025-05-13 13:06:45 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Rusfort/Asset-Frameworker#66