You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
All actions follow a consistent pattern defined in `base.py`:
@@ -48,7 +38,7 @@ class MyAction(ABAction):
48
38
1.**Declarative** - Icon, text, and tooltip defined as class attributes
49
39
2.**Callable arguments** - Arguments can be functions (evaluated at runtime)
50
40
3.**Qt integration** - Can be converted to QAction or QPushButton
51
-
4.**Exception handling** - Optional decorator for error dialogs
41
+
4.**Exception handling** - Always add `@exception_dialogs`decorator for user-facing errors
52
42
5.**Flexible invocation** - Triggered from menus, buttons, shortcuts
53
43
54
44
## Usage
@@ -99,18 +89,4 @@ When adding new actions:
99
89
100
90
## Signal Integration
101
91
102
-
Actions should emit signals when they modify application state:
103
-
104
-
```python
105
-
from activity_browser import app
106
-
107
-
classMyAction(ABAction):
108
-
@staticmethod
109
-
defrun():
110
-
# Perform operation
111
-
...
112
-
# Emit signal
113
-
app.signals.database_changed.emit()
114
-
```
115
-
116
-
This ensures other components can react to state changes without tight coupling.
92
+
**Actions should not emit signals themselves** That being said, actions should only emit signals when they modify state in a way that Brightway2 does not automatically notify the UI about. See e.g. parameter_group_delete.py for an example of emitting a signal after deleting a parameter group.
Copy file name to clipboardExpand all lines: activity_browser/app/dialogs/README.md
+5-112Lines changed: 5 additions & 112 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,117 +4,10 @@ Dialog windows for user interactions throughout Activity Browser.
4
4
5
5
## Overview
6
6
7
-
This directory contains modal and non-modal dialog windows used for various user interactions such as data entry, configuration, selection, and information display.
7
+
This directory contains modal and non-modal dialog windows used for various user interactions such as data entry, configuration, selection, and information display. Dialogs in the app directory are there because they are tightly integrated with Brightway2 or depend on the application for other reasons.
8
8
9
-
## Purpose
9
+
- Generally, action specific dialogs are located alongside the corresponding action in the `actions/` directory.
10
+
- Dialogs than can be applied more widely and are not intimately tied with either actions or Brightway2 are located in the `ui/dialogs/` directory.
11
+
- Only if the above two locations are not appropriate should a dialog be placed here.
10
12
11
-
Dialogs provide focused interfaces for:
12
-
- User input and data entry
13
-
- Configuration and settings
14
-
- Selection of items (activities, methods, databases)
15
-
- Information display and confirmations
16
-
- Multi-step workflows (see also `ui/wizards/`)
17
-
18
-
## Common Dialog Types
19
-
20
-
### Input Dialogs
21
-
- Text input fields
22
-
- Numeric value entry
23
-
- Date/time selection
24
-
- Multi-line text editing
25
-
26
-
### Selection Dialogs
27
-
- List/tree item selection
28
-
- Database/activity pickers
29
-
- Method selection
30
-
- File/directory choosers
31
-
32
-
### Configuration Dialogs
33
-
- Settings editors
34
-
- Preference panels
35
-
- Option configuration
36
-
37
-
### Information Dialogs
38
-
- Progress indicators
39
-
- Status messages
40
-
- Warnings and errors
41
-
- About/help information
42
-
43
-
## Design Guidelines
44
-
45
-
Dialogs in Activity Browser should:
46
-
47
-
1.**Be modal when appropriate** - Block parent window for critical decisions
48
-
2.**Provide clear actions** - OK/Cancel, Accept/Reject, or custom actions
49
-
3.**Validate input** - Check data before accepting
50
-
4.**Give feedback** - Show errors, warnings, progress
51
-
5.**Be responsive** - Use threading for long operations
52
-
6.**Follow Qt conventions** - Inherit from QDialog, use standard buttons
53
-
54
-
## Usage Pattern
55
-
56
-
```python
57
-
from qtpy.QtWidgets import QDialog, QDialogButtonBox
58
-
59
-
classMyDialog(QDialog):
60
-
def__init__(self, parent=None):
61
-
super().__init__(parent)
62
-
self.setup_ui()
63
-
64
-
defsetup_ui(self):
65
-
# Build dialog UI
66
-
pass
67
-
68
-
defaccept(self):
69
-
# Validate and process input
70
-
ifself.validate():
71
-
super().accept()
72
-
```
73
-
74
-
## Integration with Actions
75
-
76
-
Dialogs are typically opened via actions:
77
-
78
-
```python
79
-
from activity_browser.app.actions.base import ABAction
80
-
81
-
classOpenMyDialog(ABAction):
82
-
@staticmethod
83
-
defrun():
84
-
dialog = MyDialog()
85
-
if dialog.exec_() == QDialog.Accepted:
86
-
# Process result
87
-
pass
88
-
```
89
-
90
-
## Threading Considerations
91
-
92
-
Long-running operations in dialogs should use worker threads:
93
-
94
-
```python
95
-
from activity_browser.ui.core.threading import ABThread
96
-
97
-
classMyDialog(QDialog):
98
-
defperform_long_operation(self):
99
-
worker = ABThread(self.expensive_task)
100
-
worker.finished.connect(self.on_complete)
101
-
worker.start()
102
-
```
103
-
104
-
## Signal Emission
105
-
106
-
Dialogs should emit signals to notify the application of changes:
107
-
108
-
```python
109
-
from activity_browser import app
110
-
111
-
classMyDialog(QDialog):
112
-
defaccept(self):
113
-
# Save changes
114
-
self.save_data()
115
-
# Notify application
116
-
app.signals.data_changed.emit()
117
-
super().accept()
118
-
```
119
-
120
-
This ensures the rest of the application can react to changes made in dialogs without tight coupling.
13
+
What qualifies to be put in this directory is somewhat subjective, but the guiding principle is that these dialogs are core to the functioning of Activity Browser and are not easily reusable outside of it.
0 commit comments